La réunion de rétro dure vingt minutes. À un moment donné, quelqu'un prononce la phrase : "C'est que Copilot ne sert à rien pour un projet comme le nôtre." Des têtes qui opinent. Le tech lead ajoute qu'ils ont testé Cursor et qu'il "ne comprend pas non plus nos conventions". L'engineering manager prend note : Outils IA — revoir l'investissement Q3. Personne ne demande pourquoi. Le diagnostic est posé : l'IA ne fonctionne pas pour l'entreprise.
J'ai entendu cette conversation — avec quelques variantes — dans cinq projets d'entreprise différents au cours de l'année écoulée. Angular avec micro-frontends. .NET avec APIM. Monorepos Azure DevOps avec pipelines personnalisés. Dans chaque cas, le verdict était le même : l'outil ne fonctionne pas.
Dans aucun de ces cinq cas, le problème ne venait de l'outil.
Ce que l'IA ne peut pas compenser
Il y a une chose que j'observe de manière répétée dans les projets d'entreprise de plus de deux ans avec des équipes de plus de dix personnes : un pourcentage énorme des informations nécessaires pour travailler sur ce projet n'est écrit nulle part.
Les conventions de naming. Les raisons derrière les décisions architecturales. Les modèles utilisés et ceux qui ont été écartés. La séparation des responsabilités entre les modules. Les règles de gestion des erreurs (error handling). L'utilisation spécifique des middlewares. Comment et pourquoi les pipelines sont structurés ainsi.
Rien de tout cela n'est documenté. Tout cela existe — mais réside dans la tête de personnes précises. Dans la mémoire institutionnelle. Dans les revues de code passées. Dans la tradition orale de l'équipe.
Les humains compensent. Ils posent des questions. Ils observent. Ils absorbent par osmose. Un senior qui travaille sur le projet depuis trois ans sait, sans consulter aucun document, qu'il ne faut pas toucher à la configuration du reverse proxy de production car il y a dix-sept mois, un incident a mis quatre heures à être résolu. Un nouveau développeur l'apprend lors de sa troisième semaine, quand quelqu'un le mentionne au passage lors d'une revue de PR.
L'IA ne pose pas de questions. L'IA n'absorbe pas par osmose. L'IA n'a pas trois semaines devant elle ni de capital social pour poser des questions bêtes.
Ce que l'IA reçoit est ce qui est écrit. Et ce qui n'est pas écrit n'existe pas pour elle.
Quand vous dites "Copilot ne comprend pas notre projet", ce que vous dites sans le savoir, c'est : "notre projet contient des informations critiques qui n'existent de manière explicite nulle part." L'IA n'a pas créé ce vide. Elle l'a rendu impossible à ignorer.
Le miroir
Il m'est utile de penser à l'IA comme à un miroir.
La qualité du résultat de n'importe quel outil d'IA est un reflet direct de la qualité du contexte explicite de votre projet. Si vous lui demandez de générer un intercepteur Angular en suivant vos conventions et qu'elle produit un intercepteur générique de tutoriel, ce n'est pas que l'outil est mauvais. C'est que vos conventions ne figurent nulle part où elle puisse les lire.
Un résultat médiocre n'est pas un échec. C'est un diagnostic.
Avant l'IA, le coût de l'information implicite était diffus. Il se manifestait par un onboarding lent — trois ou quatre semaines avant qu'une nouvelle recrue ne "comprenne" les conventions. Des incohérences graduelles entre ce qu'écrivaient les seniors et les nouveaux arrivants. Une frustration sourde que personne ne nommait parce que "ça a toujours été comme ça". Un Bus factor très élevé qui ne devenait préoccupant que lorsque quelqu'un quittait l'équipe.
Des coûts réels, mais invisibles. Distribués. Normalisés.
Désormais, les coûts sont immédiats. Vous demandez quelque chose à l'IA. Le résultat est inutilisable. Temps perdu. Frustration concrète. Et surtout : c'est visible pour toute l'équipe. Ce n'est plus un coût diffus qu'on peut ignorer — c'est un résultat qui ne passe pas la revue de code, aujourd'hui, devant tout le monde.
L'IA n'a pas créé le problème. Elle a supprimé la possibilité de ne pas le voir.
Cinq types de dettes que l'IA révèle
Quand je parle de ce que l'IA rend visible, je ne parle pas seulement de dette technique au sens classique. Il y a au moins cinq types de dettes qui se manifestent lorsque vous introduisez des outils d'IA dans un projet d'entreprise mature. Ils sont classés du plus reconnaissable au plus invisible — et les plus dommageables sont ceux qui ne sont jamais nommés.
1. Dette technique classique
Celle que tout le monde connaît. Le code legacy. Les abstractions qui ont cassé il y a deux ans et que personne n'a réparées. Trois styles différents pour faire la même chose selon l'époque où le code a été écrit.
Comment l'IA la révèle-t-elle ? Si votre base de code contient des services Angular écrits avec RxJS en 2021, avec NgRx en 2023 et avec des signals en 2025, l'IA générera un quatrième style qui sera un hybride incohérent des trois — parce que statistiquement, aucun modèle ne domine. Le modèle ne sait pas lequel est "le bon", car aucun ne l'est de manière claire. L'incohérence accumulée dans le code produit une incohérence amplifiée dans le résultat.
Avant : l'incohérence était inconfortable mais tolérable. Maintenant : l'incohérence se multiplie à chaque interaction avec l'IA.
2. Dette de connaissance
C'est celle que je considère comme la plus dommageable et la moins citée.
La dette de connaissance est la différence entre ce que le code fait et pourquoi il a été fait ainsi. Le code est visible. Les raisons derrière le code sont invisibles. Et l'IA ne peut opérer qu'avec le visible.
Exemple concret : un service .NET gérant l'authentification avec APIM n'utilise pas de cache de jetons. Un nouveau développeur — ou une IA — regarde cela et pense : "optimisation évidente : ajouter un cache". Mais il y a une raison pour laquelle on n'utilise pas de cache. Il y a deux ans, il y a eu un bug critique de cohérence des données lorsqu'un jeton révoqué restait actif en cache pendant la fenêtre TTL. L'équipe a passé trois jours sur un post-mortem et a décidé explicitement de ne pas mettre en cache les jetons pour ce service.
Où cette décision est-elle documentée ? Dans la tête du senior qui l'a vécue. Dans un fil Slack archivé que personne ne cherchera. Nulle part où l'IA puisse le lire.
L'IA suggère joyeusement d'ajouter un cache. Le développeur junior implémente la suggestion. Le bug revient. Et alors quelqu'un dit : "C'est déjà arrivé. Personne ne s'en souvenait ?"
La dette de connaissance, c'est cela : des raisons, des contraintes, un contexte métier, des leçons apprises — tout ce qui explique le "pourquoi" — qui n'existe que de manière tacite. Chaque personne qui quitte l'équipe en emporte une partie. Et désormais, chaque interaction avec l'IA expose exactement quelle part de cette connaissance n'a jamais été rendue explicite.
3. Dette de documentation
Je ne parle pas seulement d'absence de documentation. Je parle de quelque chose de pire : une documentation qui ment.
Le README qui indique "gestion d'état avec Redux" alors que l'équipe a migré vers SignalStore il y a huit mois. Le wiki Confluence qui décrit l'architecture de la v1 qui a cessé d'exister en 2024. Le schéma C4 qui montre des services qui ont fusionné il y a un an.
Une IA peut lire la documentation. Si cette documentation est obsolète, l'IA la suit fidèlement. Elle n'a pas la capacité de douter. Elle ne se dit pas "ça sent l'obsolescence". Elle lit et elle agit.
J'ai vu un cas où l'IA générait systématiquement du code avec un modèle obsolète. L'équipe blâmait le modèle. Il leur a fallu deux semaines pour découvrir qu'un README que personne ne lisait — mais qui était dans le contexte de l'IDE — décrivait des conventions d'il y a un an. L'IA le lisait religieusement. C'était sa source de vérité. Et cette source mentait.
Une documentation obsolète n'est pas une documentation neutre. C'est une documentation activement nuisible — et avec l'IA dans le flux de travail, nuisible de manières concrètes et répétables.
4. Architectures implicites
Dans tout projet d'entreprise mature, il existe une architecture réelle et une architecture documentée. Avec un peu de chance, elles se ressemblent. La plupart du temps, seule la réelle existe — et elle vit dans la pratique quotidienne de l'équipe.
La séparation entre libs/shared/ui et libs/shared/utils dans un monorepo Nx. Quand est-ce que quelque chose va dans UI et quand va-t-il dans utils ? Il y a une logique. Tout le monde la respecte. Personne ne l'a écrite.
Le routage entre micro-frontends et comment il est résolu dans le Nginx de l'environnement de staging versus production. Quelle est la règle ? Les personnes qui ont configuré les blocs location le savent. Les autres appliquent par imitation.
Les limites (boundaries) entre domaines dans un backend .NET : quel service peut en appeler un autre, quelles données franchissent les limites et lesquelles ne le font pas. Existe-t-il un schéma ? Non. Existe-t-il une règle ? Oui — dans la tête de ceux qui ont conçu la séparation originale.
L'IA n'a accès à rien de tout cela. Elle génère du code qui viole les limites silencieusement. Elle mélange les responsabilités entre les modules. Elle place des fichiers dans les mauvais dossiers. Non pas parce que c'est un mauvais outil — mais parce que rien ne définit les limites de manière lisible.
Chaque violation de limite que l'IA commet est un indicateur que cette limite n'existe pas de manière explicite. C'est inconfortable. Mais c'est une information.
5. Conventions non documentées
"Ici, on fait comme ça."
Des schémas de naming spécifiques. Le format exact des messages de commit. Le modèle de gestion d'erreurs avec un ErrorHandler personnalisé qui enveloppe les appels HTTP d'une manière particulière. Le style de test : description par méthode publique, mocks avec ng-mocks, assertions avec un helper personnalisé.
Rien de tout cela n'est dans un .eslintrc. Il n'y a pas d'ADR qui le formalise. Il n'y a pas de linter qui le force. On l'apprend par la revue de code. On le corrige par des commentaires dans les PR. On le transmet du senior au junior lors de sessions de pair programming.
L'IA suit les conventions les plus courantes d'internet. Celles de votre équipe lui sont invisibles.
J'ai vu des équipes où le modèle de gestion d'erreurs mettait deux sprints à être compris par une nouvelle recrue. Deux sprints de corrections dans les PR, de "ici on fait ça différemment", de "regarde comment fait cet autre service". Si un humain a besoin de deux sprints pour absorber une convention tacite, comment espérez-vous que l'IA la devine sans aucun input ?
Ce que j'ai vu dans des projets réels
Ce n'est pas de la théorie. Je l'ai vu se répéter dans de multiples projets avec un schéma si cohérent qu'il en devient prévisible.
Le monorepo Angular avec micro-frontends. Équipe de quinze personnes. Six micro-frontends, bibliothèques partagées, un design system interne. La plainte : "Copilot ne respecte pas la séparation entre domaines." Diagnostic réel : la séparation entre domaines n'a jamais été documentée. Elle existait par convention et se transmettait lors des premières PR de chaque nouveau développeur. L'IA générait des imports croisés entre domaines parce qu'il n'y avait rien — ni un fichier, ni un commentaire, ni une règle de lint — qui stipulait que ces imports ne pouvaient pas exister.
Lorsque l'équipe a écrit un document de dix lignes décrivant les limites entre domaines, les résultats de l'IA se sont améliorés immédiatement. Non pas parce que l'outil avait changé. Mais parce que l'information existait pour la première fois sous une forme lisible.
Les pipelines Azure DevOps. Templates personnalisés réutilisables. Variables par environnement dans des variable groups spécifiques. Étapes conditionnelles selon la branche. Un système sophistiqué construit pendant un an et demi par le DevOps lead. L'IA générait du YAML générique qui n'utilisait pas les templates, ne référençait pas les variable groups, ne suivait pas la structure des étapes de l'équipe. Le diagnostic de l'équipe : "L'IA ne comprend pas Azure DevOps avancé." Correction : il n'y a rien qui explique le fonctionnement de votre configuration de pipelines. Le DevOps lead a tout en tête. S'il quitte l'équipe demain, non seulement l'IA sera perdue — mais l'équipe entière le sera.
L'API .NET avec APIM. Modèle de versionnage des points de terminaison. Convention de naming des contrôleurs. Middleware personnalisé pour la corrélation des requêtes. Politiques APIM avec des fragments partagés. Douze conventions qui n'étaient pas écrites mais transmises par revue de code. L'IA générait des contrôleurs techniquement corrects mais qui ne suivaient aucune des douze règles. L'équipe corrigeait manuellement — exactement comme elle corrigeait chaque nouvelle recrue durant ses premières semaines. Exactement le même type de corrections. Exactement les mêmes erreurs. L'IA expérimentait l'onboarding raté que l'équipe avait normalisé.
Le schéma est toujours le même : ce qui ressemble à un échec de l'IA est un indicateur direct d'une information qui n'existe pas de manière explicite. Et ce qui est révélateur, c'est que dans chaque cas, les humains de l'équipe compensaient cette absence — silencieusement, inconsciemment, à un coût que personne ne mesurait car il était réparti entre les onboardings lents, les corrections dans les PR et les réunions d'alignement.
L'IA comme nouvel employé infiniment littéral
Il y a une analogie qui m'est utile. L'IA fonctionne comme un nouvel employé doté de deux caractéristiques extrêmes : il est infiniment littéral et infiniment infatigable.
Un nouveau développeur arrive dans l'équipe et, durant ses premières semaines, commet des erreurs qui révèlent les conventions tacites : il utilise un mauvais naming, place des fichiers dans le mauvais dossier, utilise un modèle obsolète. L'équipe corrige dans les PR. Le développeur absorbe. En un mois, il a "compris".
L'IA commet exactement les mêmes erreurs. Mais elle n'apprend pas entre les interactions (du moins pas de manière permanente). Et contrairement au nouvel employé, elle n'a pas la discrétion de poser une question à un senior par message privé — son résultat est visible immédiatement.
Ce que l'IA expose, c'est exactement ce qu'un nouvel employé découvrirait s'il était extrêmement littéral et n'avait pas honte de se tromper en public. Chaque erreur de l'IA correspond à une part de connaissance tacite que l'équipe n'a jamais formalisée.
Et voici l'insight inconfortable : si votre équipe met quatre semaines pour faire l'onboarding complet d'un développeur compétent, vous avez quatre semaines de conventions qui n'existent pas de manière explicite. Ces quatre semaines sont de la pure dette de connaissance. L'IA vous le dit simplement en face au lieu de l'absorber en silence.
"Oui, mais..."
Si votre réaction à tout cela est une variante de "oui, mais dans notre cas c'est différent" — vous êtes probablement sur le point d'utiliser l'un des arguments que j'entends le plus fréquemment. Ce sont des objections légitimes à l'origine mais incorrectes dans leur conclusion.
"L'outil est limité, ce n'est pas la faute de notre projet."
Oui. Les outils ont des limitations réelles. Des fenêtres de contexte finies, des hallucinations, la méconnaissance d'API récentes. Tout cela est légitime. Mais si le même outil fonctionne de manière acceptable sur un projet neuf ou bien documenté et produit des déchets sur le vôtre, la variable différentielle n'est pas l'outil — c'est l'état de votre projet. Les deux choses peuvent être vraies simultanément : l'IA a des limitations ET votre projet a une dette de connaissance. Ce n'est pas l'un ou l'autre.
"On a toujours fonctionné comme ça et ce n'était pas un problème."
Vous fonctionniez. Mais ce n'était pas gratuit. Le coût se manifestait par : un onboarding de trois à quatre semaines au lieu d'une seule. Des réponses répétées aux mêmes questions sur Slack. Des incohérences graduelles entre ce qu'écrivait chaque sous-équipe. Un bus factor dont personne ne parlait mais que tout le monde craignait quand le senior parlait de changer de travail. Ce n'était pas une absence de problème — c'était un problème distribué et invisible. L'IA ne l'a pas créé. Elle lui a ôté son invisibilité.
"C'est juste une excuse pour demander du temps pour la documentation."
Je comprends la fatigue. L'industrie a un long historique d'initiatives de documentation qui produisent des wikis abandonnés de deux cents pages que personne ne consulte. Ce n'est pas de cela qu'il s'agit. Je ne parle pas de tout documenter. Je parle de rendre explicites les dix ou quinze choses qu'un senior de votre équipe a en tête et dont toute l'équipe a besoin — y compris l'IA — pour fonctionner correctement. C'est vingt lignes. Quarante tout au plus. C'est un investissement avec un ROI mesurable en jours, pas en mois.
"Nous n'avons pas le temps de résoudre cette dette."
Il ne s'agit pas de "tout résoudre". Il s'agit de diagnostiquer quelle dette cause 80 % des problèmes avec l'IA et de s'attaquer à ces 20 % en priorité. Si l'IA génère systématiquement des services avec le mauvais modèle, documenter le bon modèle en cinq lignes résout 80 % du problème avec un investissement de quinze minutes. Nous ne parlons pas de mois de refactoring. Nous parlons de rendre explicite ce qui est critique.
Et il y a un coût à ne pas le faire : une adoption ratée de l'IA aujourd'hui se traduit par un désavantage concurrentiel demain. Les équipes qui résolvent cela maintenant accumulent un avantage composé chaque semaine.
L'audit involontaire
Je veux proposer un recadrage qui change la perspective de "nous avons un problème" à "nous avons une information".
Chaque résultat médiocre d'un outil d'IA est un diagnostic gratuit. Il vous dit, de manière concrète et identifiable, exactement ce qui manque à votre projet pour être exploitable de manière efficace — tant par les outils que par les nouvelles recrues.
L'IA génère un service avec un mauvais naming → indicateur que votre convention de naming est implicite.
L'IA viole une limite entre modules → indicateur que vos limites ne sont pas définies de manière lisible.
L'IA suggère un modèle que vous avez écarté → indicateur que la décision de l'écarter n'est pas enregistrée.
L'IA génère un pipeline qui ne fonctionne pas → indicateur que votre configuration de CI/CD réside dans la tête d'une personne.
Vous pouvez continuer à blâmer l'outil. Ou vous pouvez utiliser chaque erreur comme un scanner qui vous indique où se trouvent vos dettes les plus coûteuses.
C'est comme une analyse de sang. Les chiffres ne créent pas les maladies. Mais une fois que vous les voyez, vous pouvez agir. Ignorer les résultats ne les change pas — cela vous enlève seulement la possibilité d'agir à temps.
Et la puissance de ce recadrage est que résoudre la dette que l'IA signale n'améliore pas seulement l'IA. Cela améliore tout le reste :
- Un onboarding plus rapide (les nouveaux lisent la même chose que l'IA)
- Moins d'incohérences (les conventions sont explicites, pas dans la mémoire de quelqu'un)
- Un bus factor réduit (la connaissance survit aux personnes)
- Une meilleure qualité de code (des standards définis et vérifiables)
- Des discussions d'architecture plus productives (il y a une base commune documentée)
L'IA est l'excuse, pas l'objectif. L'objectif réel est de transformer la connaissance tacite en connaissance explicite. L'IA a simplement imposé un coût immédiat et visible au fait de ne pas le faire.
Nommer le problème
Il y a un pouvoir dans le fait de nommer les choses.
"Dette technique" a été un concept qui a transformé notre façon de parler du code imparfait. Avant que Ward Cunningham ne lui donne un nom, les entreprises accumulaient simplement du code problématique sans avoir le langage pour en discuter ou justifier sa remédiation. Nommer la "dette technique" a donné aux équipes un outil rhétorique pour négocier du temps pour l'amélioration.
Je crois que nous avons besoin du même type de nomination pour ce qui se passe actuellement. "Dette de connaissance" — l'écart entre ce qu'un projet nécessite pour être exploitable et ce qui est documenté de manière explicite. Ce n'est pas une dette technique (le code peut être bon). Ce n'est pas une dette de documentation générique (il peut y avoir des documents). C'est spécifiquement l'absence de connaissance opérationnelle critique sous forme explicite.
Une fois que vous pouvez dire "nous avons une dette de connaissance" dans une conversation avec votre équipe, votre manager, ou les parties prenantes — vous pouvez commencer à l'aborder. Sans nom, le problème est diffus. Avec un nom, il devient diagnostiquable, priorisable et remédiable.
Et l'IA vous donne les métricas gratuitement. Chaque résultat qui ne passe pas la revue de code pour des raisons de contexte est une donnée supplémentaire sur l'ampleur de votre dette de connaissance.
La première étape n'est pas un refactoring
Si vous êtes arrivé jusqu'ici et que cela décrit ce que vous voyez dans votre projet, la tentation est de penser à de grandes initiatives. "Nous avons besoin d'un sprint de documentation." "Il faut créer un wiki complet." "Nous devrions faire une session de transfert de connaissances."
Non.
La première étape est un fichier. Un seul fichier qui capture les cinq, dix, quinze décisions les plus importantes qui vivent dans la tête de votre équipe. Ce qu'un senior dirait à un nouveau développeur lors de son premier jour complet — compressé, structuré, lisible tant par les humains que par les LLM.
Il n'a pas besoin d'être parfait. Il n'a pas besoin de tout couvrir. Il doit simplement exister.
J'ai écrit sur ce sujet en détail dans un autre article — comment un architecture.md vaut mieux que cent prompts magiques pour améliorer les résultats de l'IA dans les projets d'entreprise. C'est le premier pas concret : transformer quarante lignes de connaissance tacite en connaissance explicite.
Mais au-delà du fichier, le changement de mentalité importe plus que l'artefact. Le changement est le suivant : cesser de traiter l'adoption de l'IA comme un problème d'outils et commencer à la traiter comme un problème d'information. Vous n'avez pas besoin de meilleurs outils. Vous avez besoin de rendre explicite ce qui est implicite.
Les équipes qui font cela aujourd'hui — pas dans six mois, aujourd'hui — construisent un avantage composé. Chaque semaine qui passe avec une connaissance explicite est une semaine de meilleurs résultats de l'IA, d'onboarding plus rapide, de moins d'incohérences. Et cet avantage s'accumule.
L'IA ne va pas attendre que votre équipe décide que c'est important. Mais la bonne nouvelle est que le premier pas est petit, le ROI est immédiat, et le coût de ne pas commencer croît chaque semaine.
La dette que l'IA révèle a toujours été là.
Maintenant, vous pouvez la voir.
Ce que vous en ferez dépend de vous.
Étape suivante
Si cet article décrit quelque chose que vous reconnaissez dans votre équipe, chaque semaine je publie des analyses sur la manière dont les équipes d'entreprise peuvent mieux travailler avec l'IA. Sans hype. Sans promesses. En diagnostiquant des problèmes réels et en proposant des solutions concrètes pour les architectes et les tech leads qui construisent des systèmes complexes.
Si vous voulez commencer aujourd'hui : lisez comment un architecture.md change les résultats de l'IA en entreprise. C'est le premier pas pratique pour éponger la dette que nous venons de diagnostiquer.
Publié : Mai 2026