Ton équipe pousse du code avec quatre outils de code IA différents. Peut-être cinq. Le mec du back jure uniquement par Claude Code, l'équipe front vit dans Cursor, le stagiaire a découvert GitHub Copilot à la fac et n'en est jamais sorti, et quelqu'un en platform engineering a discrètement installé JetBrains AI. Tout le monde est productif. Le code compile. La CI passe. Personne ne remet en question l'arrangement.

Mais voilà le truc : ton codebase se lit maintenant comme un roman écrit par quatre nègres littéraires qui ne se sont jamais rencontrés. Chaque phrase est grammaticalement correcte. Le bouquin, dans son ensemble, n'a aucun sens.

La fracture est désormais officielle

Le 10 avril 2026, JetBrains a publié son enquête AI Pulse — plus de 10 000 développeurs professionnels, huit langages de programmation, statistiquement pondéré. Le chiffre clé qui compte ici : Copilot à 29 %, Claude Code et Cursor à égalité à 18 %, JetBrains AI à 11 %. Quatre-vingt-dix pour cent des développeurs utilisent au moins un outil IA au travail.

Ce n'est pas un outil qui gagne. C'est tous les outils qui gagnent au sein de la même organisation.

Et c'est là que ça devient intéressant : chaque outil a amené son propre fichier d'instructions — un document de configuration qui dit à l'IA comment écrire du code pour ton projet spécifique. Claude Code lit CLAUDE.md. Copilot lit copilot-instructions.md. Cursor lit .cursor/rules/*.mdc. Le Codex CLI d'OpenAI lit AGENTS.md (désormais sous la tutelle de la Linux Foundation, adopté par 60 000+ projets open-source). Windsurf lit .windsurf/rules/*.md. Gemini CLI lit GEMINI.md.

Six outils. Six formats de config. Chacun ignore silencieusement les autres. Comme TokenCentric l'a noté dans une comparaison de mars 2026 : « Un développeur travaillant sur cinq projets avec trois outils IA pourrait maintenir quinze fichiers de config. »

Comment quatre IA écrivent quatre codebases différentes

Chaque IA a sa personnalité. Claude Code privilégie la gestion explicite des erreurs et la composition fonctionnelle — petites fonctions, types clairs, verbeux mais prévisible. Copilot reflète la moyenne statistique de GitHub — il écrit du code comme la majorité du code open-source, ce qui veut dire moyen dans tous les sens du terme. Cursor route automatiquement entre les modèles (Claude, GPT, ses propres fine-tunes), mélangeant les styles en pleine pull request selon quel modèle a traité quel fichier.

Rien de tout ça n'est faux. C'est justement le problème. Un linter — un outil qui vérifie le code pour détecter les violations de style — attrape les coquilles et le formatage. Il n'attrape pas le fait que ton service d'authentification gère les erreurs avec des blocs try-catch, ton service de paiement utilise des Result types, et ton service de notifications retourne null. Trois approches, toutes valides, toutes passant la CI (Continuous Integration — les tests automatisés qui tournent avant le merge), toutes créant un codebase que personne ne peut naviguer sans carte.

L'étude la plus récente à grande échelle sur la qualité du code IA — le rapport CodeRabbit de décembre 2025, toujours les meilleures données disponibles quatre mois plus tard — a quantifié les dégâts sur 470 pull requests GitHub : le code généré par IA avait 1,7× plus de problèmes au total, 3× plus de problèmes de lisibilité, et 2,66× plus d'incohérences de formatage que le code humain. Et ça mesurait la sortie d'un seul outil. Les codebases multi-outils empilent ces incohérences les unes sur les autres.

La prise de conscience dont personne ne voulait

Le résultat, ce ne sont pas des bugs. Les bugs, on les trouve. Le résultat, c'est l'incohérence architecturale — un terme que Martin Fowler a cerné le 7 avril 2026 dans son essai sur le « harness engineering », où il a défini l'équation : Agent = Model + Harness. Le harness, c'est tout ce qui entoure le modèle IA — les fichiers de config, les garde-fous, les instructions. Fowler a admis : « Nous avons encore beaucoup à faire pour trouver de bons harnesses pour le comportement fonctionnel. »

Traduction : personne n'a résolu ça.

Greg Foster, CTO de Graphite, l'a formulé autrement dans un article Stack Overflow du 26 mars : les ingénieurs humains « absorbent implicitement le contexte du code base » en codant. Ils remarquent que le reste du service utilise des Result types, alors ils utilisent des Result types aussi. Les agents IA n'absorbent rien — ils suivent ce que leur fichier de config dit, ou pire, ce que leurs données d'entraînement suggèrent.

La note

Aucun outil existant ne détecte ça. ESLint vérifie la syntaxe. Prettier vérifie le formatage. La revue de code attrape les bugs. Aucun d'entre eux ne signale « ce fichier a clairement été écrit par une IA différente de celle du fichier d'à côté ».

Et n'espère pas que les éditeurs comblent le fossé de leur plein gré. Si Cursor rendait ses rules compatibles avec la config de Claude Code, ça faciliterait le changement d'outil. La fragmentation est un fossé défensif, même accidentel.

Des projets communautaires tentent de compenser. rule-porter, apparu sur GitHub en février 2026, convertit entre les formats de config ; rulesync, apparu à la même période, essaie de les unifier. Les deux rapportent environ 75 % de conversions propres. Les 25 % restants, c'est là que vit l'intention architecturale, et elle se perd dans la traduction.

Addy Osmani de Google a prévenu en février 2026 : « Plus ton architecture est propre, moins l'IA hallucine des abstractions bizarres. » L'inverse est aussi vrai : plus ton codebase multi-IA est bordélique, plus chaque contribution IA suivante devient étrange. L'entropie s'accumule.

Quoi faire

Si ton équipe utilise plusieurs outils IA — et statistiquement, c'est le cas — tu as besoin d'une seule chose : un document de style unique, agnostique de l'outil, que chaque IA lit. Pas six fichiers de config. Une source de vérité canonique sur la façon dont ton codebase gère les erreurs, structure les API, nomme les choses et organise les dépendances. Ensuite, un pre-commit hook — une vérification automatisée qui tourne avant que le code ne soit enregistré — qui impose ces patterns quel que soit l'IA qui a écrit le code.

Le standard AGENTS.md, désormais sous la Linux Foundation, est ce qui se rapproche le plus d'un format universel. Ce n'est pas parfait, mais c'est le seul avec un soutien multi-éditeur.

La nouvelle normalité

Ton codebase a maintenant plus d'auteurs IA que d'auteurs humains. Andrej Karpathy l'a dit sans détour le 26 janvier 2026 : « Tu n'écris pas le code directement 99 % du temps… tu orchestres des agents. » Très bien. Mais les orchestres ont besoin d'un chef, et ils ont besoin d'une partition. En ce moment, la plupart des équipes ont quatre musiciens jouant quatre partitions différentes dans quatre tonalités différentes — et le public entend « ça compile » et suppose que c'est de la musique.

Quelqu'un doit écrire la ligne éditoriale avant que le repo n'en écrive une à ta place. Ce ne sera pas joli.