Quand une équipe délègue sa réflexion technique à l'IA, elle risque de perdre quelque chose d'irremplaçable : la compréhension profonde de son propre système.
Une organisation qui délègue massivement à des outils IA sans cultiver la compréhension interne crée une dépendance dangereuse. Non pas une dépendance à un outil — les outils changent — mais une dépendance cognitive : les développeurs ne comprennent plus réellement le code qu'ils maintiennent. Cette perte de capitalisation des connaissances est silencieuse et cumulative.
Le symptôme classique : une équipe qui utilise Copilot intensivement produit du code fonctionnel rapidement, mais deux ans après, personne ne peut expliquer pourquoi certaines décisions architecturales ont été prises. La documentation fait défaut parce que le code a été généré trop vite pour être compris. Le bus factor — le nombre de personnes dont le départ mettrait le projet en péril — tombe à zéro, parce que la connaissance est dans le modèle, pas dans les cerveaux.
La solution n'est pas de rejeter l'IA, mais d'établir des pratiques de capitalisation explicites. L'ADR (Architecture Decision Record) documente les décisions importantes et leur raisonnement — indépendamment de qui ou quoi a produit le code. Les sessions de code walkthrough régulières forcent les développeurs à expliquer le code à leurs collègues. Le pair programming avec l'IA comme outil (pas comme pilote) préserve la compréhension humaine. Et les revues de code rigoureuses, même — surtout — pour le code généré, maintiennent la connaissance collective.
- Documentez les décisions architecturales dans des ADRs
- Organisez des sessions régulières de code walkthrough
- Utilisez l'IA comme outil, pas comme décideur
- Mesurez le bus factor de votre équipe régulièrement