IA & développement / Claude, ChatGPT, LLM en équipe
Utiliser des LLM pour coder en équipe peut accélérer énormément… ou générer une dette technique massive si on ne met aucune règle.
Coder avec des LLM en équipe : le nouveau chaos organisé
Aujourd’hui, Claude, ChatGPT et les autres LLM sont déjà dans les équipes, officiellement ou non. Ils génèrent du code plus vite, des tests plus rapidement et des refactors audacieux.
Mais ils génèrent aussi autre chose : du code que personne ne comprend vraiment, des patterns incohérents et une dette technique silencieuse. Le problème n’est pas l’IA, c’est l’absence de règles collectives.
Un LLM ne code pas “bien” : il code “probable”
Un LLM ne comprend pas votre produit, votre historique ou vos compromis. Il génère ce qui est statistiquement plausible. Cela signifie :
des abstractions parfois inutiles
des patterns copiés hors contexte
du code qui marche… mais qui vieillit mal
Sans garde-fous, l’IA amplifie les défauts existants du projet au lieu de les corriger.
Pourquoi la dette technique explose avec l’IA
Avant, écrire du mauvais code prenait du temps. Aujourd’hui, c’est instantané. En équipe, ces problèmes se multiplient si la code review ne s’adapte pas : duplication de logique, incohérences de nommage et sur-abstraction prématurée deviennent la norme.
Règle n°1 : le code généré par un LLM n’est jamais “hors review”
“C’est l’IA qui l’a écrit” n’est pas une excuse. En code review, le code généré doit être considéré comme du code écrit par un profil junior : rapide, mais naïf, et à challenger systématiquement. Si personne n’est capable d’expliquer le code en review, il ne doit pas passer.
Règle n°2 : interdire les abstractions générées sans usage réel
Les LLM adorent les factories, les helpers génériques et les couches “au cas où”. En review, une question simple doit suffire : “Combien de fois cette abstraction est-elle utilisée aujourd’hui ?” Si la réponse est “une seule fois”, c’est de la complexité anticipée, pas une abstraction.
Règle n°3 : refuser le code que personne n’ose modifier
Le pire code généré par IA est celui que plus personne ne veut toucher par peur de tout casser. En review, posez toujours ces questions :
Est-ce lisible par quelqu’un d’autre ?
Est-ce cohérent avec le reste du projet ?
Est-ce que je saurais le modifier dans 6 mois ?
Si la réponse est non, il faut simplifier, même si “ça marche”.
Règle n°4 : documenter les décisions, pas le code généré
Inutile de documenter chaque ligne produite par l’IA. Il vaut mieux documenter les intentions : pourquoi cette solution a été choisie, quelles alternatives ont été écartées et quels compromis sont assumés. La vraie dette technique vient des décisions non explicitées.
Règle n°5 : aligner les prompts avec les conventions du projet
Laisser chacun prompter “à sa sauce” est une erreur. Les bonnes pratiques incluent des prompts partagés dans le repo, des rappels des conventions de nommage et des patterns d’architecture explicités. Un LLM bien cadré est beaucoup plus utile qu’un LLM “libre”.
Règle n°6 : l’IA accélère, la responsabilité reste humaine
L’usage de l’IA ne transfère aucune responsabilité. Dans une équipe mature : l’IA propose, l’humain décide et l’équipe assume. C’est cette discipline qui permet de bénéficier de la vitesse de l’IA sans en subir les effets secondaires.
Conclusion
Les LLM sont des accélérateurs incroyables, mais ils amplifient ce qui existe déjà. Sans règles de code review adaptées, l’IA ne réduit pas la dette technique : elle la génère plus vite. En tant que CTO, le vrai enjeu est de structurer son usage pour qu’elle serve le produit, et non l’inverse.
