Fernand SOUALO

Fernand SOUALOSep 16, 2026

Le vrai coût d'un git log illisible Un dev junior m'a dit un jour : "je fais des git status toutes les 30 secondes parce que je ne sais jamais où j'en suis." C'est le symptôme d'un problème plus large : Git est puissant, mais son interface par défaut (le terminal brut) ne montre pas l'état du repo, elle le raconte en texte. Un client Git visuel comme Gitoryx inverse ça : tu VOIS tes branches, ton staging, ton historique, en un coup d'œil. On sous-estime combien de charge mentale ça retire. Lien en premier commentaire.

Fernand SOUALOSep 10, 2026

Un ChatGPT privé pour toute ton équipe, déployé ce soir Ton équipe utilise ChatGPT. Donc tes données internes partent chez un tiers, tous les jours, sans contrôle. Tu peux offrir à ton équipe la même expérience - une interface de chat propre, multi-utilisateurs - entièrement sur ton infra, gratuitement. Voici la pile exacte. Trois briques open source qui s'emboîtent : → Ollama fait tourner le modèle en local et expose une API. → Un modèle ouvert (Qwen, Gemma, DeepSeek) pour la qualité que ton matériel permet. → Open WebUI par-dessus : une interface web qui ressemble à ChatGPT, se branche sur Ollama, et gère les comptes, l'historique, le changement de modèle. Le déploiement est presque décevant de simplicité. Open WebUI se lance avec un Docker compose, sur n'importe quelle machine avec 16 Go de RAM, pointé vers ton instance Ollama. En quelques minutes, toute ton équipe a un lien, une interface, des conversations - sans que personne touche à un terminal. Ce que ça débloque concrètement : → Les non-techniciens ont un assistant sans compte externe. → Tes échanges, tes documents, tes prompts ne quittent jamais ton réseau. → Zéro coût par message. Zéro limite de débit. Ça tourne même hors-ligne. → Tu peux y brancher tes propres documents pour un assistant qui connaît ton contexte. Pour un secteur régulé, une équipe sous NDA, ou juste par principe de souveraineté, ce n'est plus un bricolage. C'est une alternative sérieuse, montée en une soirée. La question n'est plus "est-ce possible ?". C'est "pourquoi j'envoie encore mes données ailleurs ?". En plus Claude, ChatGPT et consorts coûtent de plus en plus chers

Fernand SOUALOSep 11, 2026

Ajoute un serveur de cache, et tu viens de vider tout ton cache Tu montes en charge. Tu ajoutes un serveur à ton cluster de cache. Logique. Sauf que tu viens peut-être d'invalider la quasi-totalité de ton cache d'un coup, et d'écrouler ta base sous la charge. Voici pourquoi, et la solution élégante qui a sauvé les systèmes distribués. Le piège vient de la méthode naïve pour répartir les données entre serveurs : hacher la clé, prendre le reste de la division par le nombre de serveurs. Simple. Rapide. Mais que se passe-t-il quand tu passes de 4 serveurs à 5 ? Le "reste de la division par 4" devient "par 5". Pour presque toutes les clés, le résultat change. Presque toutes les données se retrouvent affectées à un autre serveur. Traduction : ton cache entier devient invalide en un instant. Toutes les requêtes ratent le cache et tombent sur la base. C'est la panne par ajout de capacité, un comble. La solution s'appelle le hachage cohérent. L'idée est belle. Imagine un cercle. Tu places tes serveurs dessus, à des positions déterminées par leur hachage. Tu places aussi tes clés sur ce même cercle. Chaque clé appartient au premier serveur qu'on rencontre en tournant dans le sens horaire. Que se passe-t-il quand tu ajoutes un serveur ? Il s'insère à un point du cercle. Seules les clés situées juste avant lui changent de propriétaire. Tout le reste ne bouge pas. Ajouter ou retirer un serveur ne déplace plus qu'une petite fraction des données, environ une sur N, au lieu de la quasi-totalité. C'est ce mécanisme qui fait tourner les caches distribués, les bases comme Cassandra, les répartiteurs de charge à grande échelle. La leçon dépasse le cache : un bon système ne se juge pas à comment il tourne, mais à comment il encaisse le changement. La croissance ne doit jamais être une catastrophe.