Il est 9h30. Rétrospective hebdomadaire. L'équipe signale que la migration des pipelines dans Azure DevOps a été plus lente que prévu. Quelqu’un mentionne que la documentation couvrait bien le YAML, mais que personne n’a expliqué pourquoi certaines étapes étaient manuelles. Un nouveau développeur demande pourquoi certains microfrontends ne doivent jamais communiquer directement. Silence gêné. Le tech lead répond : « Cela a toujours été ainsi. »
Ce n’est pas un cas isolé. Dans les projets d’entreprise réels, la dette technique est visible : code obsolète, dépendances, refontes en attente. Mais la dette de connaissance — le pourquoi derrière les décisions, les règles non écrites, la mémoire institutionnelle — n’émerge que lorsque l’organisation change, que l’IA entre en jeu ou qu’une nouvelle personne arrive.
La dette technique : ce qui se voit et se paie
Pendant des années, l’industrie du logiciel a traité la dette technique comme l’ennemi principal : code legacy, tests absents, dépendances cassées. Elle se paie par des refontes, des sprints qualité, des migrations. Elle est tangible, mesurable, budgétable. Les équipes la reconnaissent lors des rétrospectives, la discutent en grooming, la priorisent (ou non) dans la feuille de route.
Mais l’arrivée de l’IA a changé la donne. Désormais, la dette technique n’est plus le seul goulet d’étranglement. L’IA peut automatiser des refontes, suggérer des migrations, détecter des motifs obsolètes. Pourtant, quand l’IA échoue, c’est rarement à cause d’un bug technique. C’est parce qu’il lui manque du contexte.
La dette de connaissance : ce que l’IA révèle
La dette de connaissance est plus insidieuse. Elle vit dans la tête des seniors, dans des fils Slack, dans des conventions non écrites. Personne ne la voit jusqu’à ce qu’elle manque. L’IA l’expose immédiatement : elle génère du code correct mais qui enfreint les conventions, automatise des pipelines mais omet des exceptions critiques, reproduit des configurations standard mais ignore des règles métier qui n’existent que dans la mémoire institutionnelle.
Exemple concret : une équipe avec 12 microfrontends. L’IA génère un nouveau module, mais personne n’a documenté les règles de communication entre domaines. Résultat : intégration cassée, bugs subtils, frustration. Autre cas : migration de pipelines dans Azure DevOps. L’IA automatise 80 %, mais les 20 % critiques dépendent de règles tacites non écrites. L’onboarding d’un développeur senior : il apprend la stack en trois jours, mais met trois semaines à comprendre les règles non écrites.
Tension organisationnelle : ce qui n’est pas écrit n’existe pas
La tension est claire : la dette technique se paie avec des refontes ; la dette de connaissance se paie avec des incidents, un onboarding lent, des erreurs répétées. L’IA est un miroir : elle amplifie ce qui est explicite et expose ce qui manque. L’onboarding humain est une osmose ; l’onboarding de l’IA est un parsing. Ce qui n’est pas écrit n’existe pas pour l’IA.
Dans les systèmes legacy, la dette technique est évidente. Mais la dette de connaissance est critique : personne ne se souvient pourquoi certains modules existent, quelles dépendances sont réellement nécessaires, quels processus ne peuvent pas être modifiés sans casser le métier. Lorsque l’IA entre en jeu, l’écart devient explicite : résultats médiocres, erreurs répétées, frustration vis-à-vis de l’outil.
Modèles et anti-modèles : documenter le pourquoi
Modèle récurrent : documenter le « quoi » et le « comment », mais jamais le « pourquoi ». L’IA peut reproduire des actions, mais pas des décisions. Anti-modèle : des refontes massives sans cartographier les dépendances cognitives. Le code s’améliore, mais la connaissance se perd. Autre anti-modèle : se fier à la mémoire institutionnelle pour les décisions critiques. Quand l’équipe change, l’IA et les nouveaux arrivants échouent de la même manière.
La documentation générée automatiquement (Swagger, YAML, etc.) est utile pour l’intégration, mais inutile pour les décisions architecturales. La valeur réside dans la documentation du critère, pas seulement de l’action.
Vers une gestion duale de la dette
La gestion moderne de la dette dans les organisations prêtes pour l’IA nécessite d’auditer les deux fronts : technique et cognitif. Les refontes et migrations ne suffisent pas. Un cadre est nécessaire pour visibiliser et réduire la dette de connaissance : architecture decision records, graphes de connaissances internes, documentation vivante, processus d’onboarding qui priorisent le « pourquoi ».
De nouvelles métriques émergent : délai d’onboarding, incidents dus au manque de contexte, erreurs répétées par l’IA. La résilience organisationnelle ne dépend plus seulement du code, mais de la qualité de la connaissance explicite.
Conclusion : le nouvel avantage concurrentiel
L’IA ne crée pas de nouveaux problèmes. Elle change ce qui est rare et ce qui est abondant. La capacité à produire du code devient une commodité. Le critère architectural, la connaissance explicite et la gestion rigoureuse de la dette de connaissance deviennent le véritable avantage concurrentiel.
Les organisations qui transformeront leur connaissance tacite en connaissance explicite — documentée, versionnée, consommable par les humains et les machines — bénéficieront d’un avantage composé croissant. Celles qui ne le feront pas accumuleront une dette de plus en plus coûteuse.
L’ère du context engineering n’est pas optionnelle. Elle est le socle des organisations prêtes pour l’IA.