Comment augmenter de 20 % la qualité Claude Code

Nous sommes entrés de plain-pied dans l'ère agentique du développement logiciel. Comme nous l'avons montré dans notre rapport 2026 sur les outils d'IA pour le développement logiciel, les assistants de code ne se limitent plus à l'autocomplétion. Ils planifient, modifient et vérifient désormais des tâches multi-fichiers de façon autonome. Des outils comme Claude Code, Cursor, Windsurf et Codex transforment profondément la manière dont les équipes construisent des logiciels.

Pourtant, si vous avez réellement travaillé avec ces agents, vous avez probablement rencontré la même limite invisible que nous.

Notre rapport 2026 met en évidence un paradoxe central : les outils de code IA excellent sur des benchmarks publics comme SWE-Bench, mais leur performance chute souvent vers 20 à 30 % lorsqu'ils sont évalués sur des codebases commerciales privées, non contaminées. Pourquoi ? Parce que, malgré leur puissance, ces agents souffrent de biais structurels : ils hallucinent des API, s'éloignent silencieusement des exigences métier et introduisent avec assurance du code qui casse l'architecture existante. Le résultat est un cycle frustrant où les ingénieurs quittent les sujets de conception de haut niveau pour revenir à la chasse aux détails cassés dans le code généré par l'IA.

Chez Shelpuk AI Technology Consulting, nous développons des produits IA sur mesure dans un modèle à prix fixe. Pour nous, l'efficacité de développement n'est pas un bonus : c'est une condition de rentabilité. Pour corriger ces défauts structurels, nous avons développé une suite agentique open source : un ensemble de serveurs MCP et de skills conçus pour réduire les biais de modèle et imposer une discipline d'ingénierie rigoureuse.

Les résultats ont été significatifs. Cette suite, indépendante de l'outil utilisé et compatible avec Claude Code, Cursor, Codex, Gemini CLI, Antigravity, OpenClaw et d'autres, a amélioré à la fois le débit et la qualité. L'un de nos clients, Relevant Software, a récemment rapporté une hausse de 15 à 20 % de la qualité de génération de code IA avec cette configuration.

Voici les principaux problèmes qui limitent encore les agents de code et la manière dont notre suite open source les corrige.

Problème 1 : limites des datasets et « knowledge cutoff »

Les grands modèles de langage sont préentraînés sur d'immenses volumes de données issues du web. Ils sont donc particulièrement efficaces sur les langages populaires et les frameworks largement utilisés.

En revanche, si vous travaillez avec des langages moins répandus, des API internes propriétaires ou des technologies sorties après la date de cutoff du modèle, les performances chutent fortement.

En théorie, on pourrait corriger cela en forçant l'agent à s'appuyer sur la recherche web plutôt que sur sa mémoire interne. En pratique, la plupart des recherches web intégrées et plusieurs serveurs MCP tiers comme Tavily présentent des limites importantes.

Prenons un cas concret : votre assistant IA tente de déboguer une erreur obscure de Google Cloud Batch. Il trouve le bon thread StackOverflow, mais un serveur MCP de recherche classique ne renvoie que l'URL et quelques lignes d'aperçu. L'agent doit ensuite faire un second appel pour scraper la page, ce qui lui renvoie souvent un mélange de HTML, de navigation, de publicité et de bruit inutile. Et, surtout, il manque parfois la véritable solution.

La solution : Kindly Web Search MCP Server

Pour résoudre ce problème, nous avons développé le Kindly Web Search MCP Server.

Plutôt que de faire du scraping générique, Kindly s'intègre directement aux API de plateformes utiles aux développeurs comme StackExchange, GitHub Issues, arXiv ou Wikipedia. Quand un agent recherche une erreur, Kindly peut renvoyer en un seul appel la conversation utile : la question initiale, les extraits de code, les réponses acceptées, les commentaires de validation et le contexte pertinent, déjà formatés pour un LLM.

En forçant l'agent à vérifier les solutions et les contrats d'API avec Kindly, vous contournez en pratique le knowledge cutoff du modèle, réduisez la consommation de tokens et limitez les hallucinations sur les technologies de niche ou très récentes.

Problème 2 : le problème du « bad token » ou l'auto-intoxication du modèle

Les LLM génèrent le texte de façon autorégressive, token après token. Chaque nouveau token est choisi pour rendre plausible la séquence déjà produite. Cela crée un phénomène dangereux que nous appelons le Bad Token Problem.

Imaginez qu'un agent prenne très tôt dans un fichier une mauvaise décision de conception. Chaque ligne suivante va naturellement tenter de rendre cette décision cohérente, au lieu de la remettre en cause. Le modèle se convainc lui-même qu'il est sur la bonne voie et entraîne toute l'implémentation dans la mauvaise direction.

La solution : Lad MCP Server, un peer review par deux LLM indépendants

Les équipes humaines corrigent la vision tunnel grâce au peer review. Nous avons appliqué la même logique aux agents IA.

Nous avons construit le Lad MCP Server pour permettre à l'agent principal de demander une revue de code et une revue de design à deux autres LLM indépendants via OpenRouter. Comme ces reviewers évaluent le diff final sans être enfermés dans l'historique token par token de l'auteur initial, ils repèrent bien plus facilement les erreurs de cohérence ou de direction que le premier agent n'a pas vues.

Le maillon manquant : la conscience du projet via Serena

Une limite fréquente des revues IA standard est qu'elles analysent un diff hors contexte. Un ingénieur humain compare toujours un changement aux exigences, aux contraintes du projet et aux décisions d'architecture existantes. Une IA, par défaut, vérifie surtout si le code « a l'air de fonctionner ».

Pour corriger cela, Lad se connecte à Serena, un outil open source de navigation sémantique dans le code qui joue le rôle d'IDE headless pour les agents. Serena fournit une mémoire de projet persistante et un index complet de la codebase. Ainsi, Lad peut vérifier si un changement casse des intégrations, contredit des exigences établies ou viole des règles de conception déjà en place.

Problème 3 : le biais « répondre tout de suite » et l'absence de processus

Pour devenir conversationnels, les LLM ont été entraînés massivement sur des paires question-réponse. Ils ont beaucoup moins appris à répondre par une autre question ou à dire « je ne sais pas ». Résultat : ils sont très fortement poussés à fournir immédiatement une réponse, même quand le prompt est flou, ambigu ou contradictoire.

Dans le contexte des agents de code, ce biais est particulièrement destructeur. Il pousse les agents à se jeter dans l'implémentation sans clarifier les exigences, à prendre seuls des décisions de design dans les zones ambiguës et à produire un code apparemment propre qui rate pourtant complètement l'objectif métier.

La solution : le skill TDD

Pour corriger ce comportement et faire travailler ensemble nos serveurs MCP, nous avons développé le TDD Skill. Lorsqu'il est ajouté à une demande, il neutralise le réflexe du modèle à deviner et impose un workflow discipliné :

1. Rédiger d'abord les exigences et le design : l'agent doit écrire un fichier REQUIREMENTS.md durable, poser les questions de clarification nécessaires et faire valider les décisions critiques avant d'aller plus loin. Le plan d'architecture est ensuite soumis à Lad pour une revue de design.
2. Appliquer le test-driven development : l'agent écrit les tests avant d'écrire le code fonctionnel.
3. Soumettre le tout à une revue croisée : les tests comme l'implémentation passent ensuite dans Lad pour une revue de code rigoureuse par d'autres modèles.

Élever le niveau d'abstraction du travail d'ingénierie

La combinaison de Kindly Web Search, Lad Code Review, Serena et du TDD Skill fait bien plus que corriger quelques bugs. Elle stabilise les agents de code, rend leur sortie plus prévisible et documente le travail de manière beaucoup plus fiable.

Pour les ingénieurs, les responsables techniques et les dirigeants, la valeur métier est claire : l'humain cesse d'agir comme simple correcteur syntaxique de l'IA et remonte au niveau de l'architecture, de la revue et des arbitrages produit. Vous pouvez vous concentrer sur la logique métier, les exigences et l'expérience utilisateur, tout en vous appuyant sur une suite d'outils qui apporte le bon contexte, des connaissances à jour et un vrai processus de revue.