Comment rendre votre code plus modulaire et maintenable en sortant de l'enfer des conditions multiples.

Dans le développement logiciel, comme dans l'écriture, il y a mille façons de raconter la même histoire. Mettons-nous dans la peau d'un écrivain et imaginons que l'on dispose d'une série de faits bruts sur la vie d'un personnage historique, disons Molière : ses dates, ses pièces, ses scandales. Notre mission est la suivante : écrire et publier son histoire. Pour commencer, on nous demande d'écrire un Roman épique, donc on écrit notre classe StoryTeller et sa méthode tellStory qui va raconter l'histoire dans ce genre. Puis, après un énorme succès, on nous demande de l'adapter en Bande Dessinée pour les plus jeunes, puis en une Biographie austère pour les universitaires, etc. Si nous n'y prenons pas garde, notre classe StoryTeller va rapidement devenir une accumulation massive de if (genre == ROMAN) ... else if (genre == BD). Chaque nouveau format, chaque modification risque de casser la logique des autres. Le texte devient un torchon, difficile à relire et impossible à corriger.

Dans le cycle de vie d'une application, la dette technique est une fatalité silencieuse. Si le critère "est-ce que ça fonctionne ?" est le premier franchi par un développeur, il est rarement suffisant pour garantir la pérennité d'un projet. Un code fonctionnel mais mal structuré devient rapidement complexe, coûteux et risqué à maintenir.

L'utilisation de l'IA est incontournable de nos jours, mais est-elle consciente des biais et stéréotypes de ses données et résultats ?

L’année 2025 a été riche en proposition d’aide au développement. Nous sommes passés de la complétion de code à des approches agentiques, capables de générer et de débugger le code des projets.

L’année 2025 a été riche en nouveautés et en normalisations lors de l’utilisation d’agents. Les différentes équipes ont proposé des solutions, des usages, des approches, que les concurrents se sont empressés de répliquer. Certaines méthodes ont abouti à des standards, ce qui a permis d'harmoniser les approches.

(Version anglaise. Pouce appréciée)

Dans un article précédent (“Ne mettez pas les projets RAG en production trop vite !”), nous avons évoqué la difficulté de rendre résiliente une application RAG. Dans cet article, nous allons particulièrement traiter des solutions dans le cadre de l’utilisation de LangChain (< 1.0).

(version anglaise. Pouce appréciée)

Dans nos missions de conseil, nous croisons, depuis quelques mois, de nombreux projets utilisant les LLM. La grande majorité est de type RAG. Lorsque nous étudions en profondeur les applications, presque toutes présentent des faiblesses importantes, nécessitant une reprise du code avant une mise en production. Néanmoins, ces derniers sont quand même déployés, car les problèmes ne se manifestent que dans des scénarios aux limites, ou lors de fortes charges.