Lundi, 10h00. L'équipe d'architecture examine la dernière pull request générée par IA pour un microfrontend dans le monorepo principal. Le code est correct, mais quelque chose ne colle pas. Le pipeline Azure DevOps échoue sur une étape que personne ne se souvient avoir configurée. Le « gourou » de l'équipe, le seul qui comprend les triggers et les conditions, est en vacances. Personne ne sait si l'erreur est technique ou si une règle invisible a été enfreinte.
Ce n'est pas un incident isolé. Dans les systèmes enterprise ayant des années d'évolution, l'IA ne bute pas sur le code : elle bute sur les règles invisibles, les dépendances tacites, la mémoire institutionnelle. La promesse d'automatisation se heurte à la réalité d'architectures où la connaissance vit dans les têtes, les fils Slack et les accords verbaux jamais documentés.
Friction dans les systèmes complexes : scènes réelles
- Monorepo avec sept ans d'historique : la documentation couvre l'onboarding technique, mais personne n'a écrit pourquoi certains microfrontends ne doivent jamais partager d'état. L'IA génère du code qui brise des limites invisibles et déclenche des incidents en production.
- Pipelines legacy sur Azure DevOps : 1200 lignes de YAML, triggers et conditions que seul le « gourou » comprend. L'IA automatise les changements, mais supprime des étapes critiques parce qu'elles ne sont pas documentées.
- APIM avec des politiques héritées : l'IA réplique la politique standard, mais omet des exceptions métier qui n'existent que dans d'anciens emails.
- Nginx comme proxy interne : des règles de routage et de réécriture que personne n'ose toucher. L'IA suggère des changements qui semblent corrects, mais qui cassent des intégrations legacy à cause de dépendances cachées.
- Onboarding : un développeur senior apprend la stack en une semaine, mais met un mois à comprendre les règles non écrites sur le ownership et les conventions.
Contradictions et tensions organisationnelles
L'organisation investit dans l'IA en attendant de la vitesse, mais le manque de contexte explicite génère plus d'erreurs et de rework. Les équipes senior « savent » comment fonctionne le système, mais ne peuvent pas transférer cette connaissance à l'IA ni aux nouveaux membres. Chaque tentative de modernisation révèle des dépendances cachées et des règles invisibles que personne n'ose documenter de peur de casser quelque chose. La mémoire institutionnelle est un atout jusqu'à ce qu'elle devienne un piège.
Migrer vers l'IA sans cartographier la connaissance tacite, c'est comme automatiser une ville sans plan : les raccourcis tuent. La friction entre développement et exploitation s'intensifie : les premiers veulent automatiser, les seconds craignent de perdre le contrôle sur les règles tacites. Le résultat : incidents en production, cycles de rejet de responsabilité, paralysie face aux changements structurels.
Patrons, anti-patrons et conséquences pratiques
Patron : documenter le « quoi » et le « comment », mais jamais le « pourquoi ». L'IA peut répliquer des actions, mais pas des décisions. Anti-patron : migrer vers l'IA sans auditer la connaissance tacite. Le code s'améliore, mais la connaissance se perd. Autre anti-patron : se fier à la mémoire institutionnelle pour les décisions critiques. Lorsque l'équipe change, l'IA et les nouveaux é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. Dans le legacy, chaque décision non documentée est une mine qui attend d'exploser.
Vers le context engineering : de la friction à l'avantage
L'IA amplifie la dette de connaissance : ce qui n'est pas écrit n'existe pas. La gestion moderne des systèmes legacy nécessite d'auditer et de transformer la connaissance tacite en explicite : architecture decision records, documentation vivante, knowledge graphs, processus d'onboarding qui priorisent le « pourquoi ».
La résilience organisationnelle ne dépend plus seulement du code, mais de la qualité de la connaissance explicite. L'avantage concurrentiel n'est pas l'IA, mais la capacité à rendre explicite la connaissance dans les systèmes complexes. L'ère du context engineering n'est pas optionnelle : elle est le fondement des organisations AI-ready.