Note d'architecture
Gouvernance IA Multi-Repo
Contexte d'architecture
Échec observé

J'ai passé des semaines à construire des fichiers de contexte pour l'IA. La moitié mentaient.
Pas intentionnellement. Les fichiers étaient exacts au moment où je les ai écrits. Puis les choses ont changé — mises à jour de stack, migrations de schéma, pivots métier — et personne n'a mis à jour la documentation.
L'IA continuait à lire l'ancien contexte. Je continuais à recevoir des réponses assurées mais erronées.
Le pire : je ne m'en suis pas rendu compte immédiatement. Les résultats semblaient raisonnables. Les erreurs étaient subtiles. Le temps que je les repère, j'avais déjà construit sur une base fausse.
C'est l'échec dont personne ne parle. Pas "l'IA a halluciné" — ce n'était pas le cas. Elle a lu exactement ce que je lui ai donné. Le problème, c'est que ce que je lui ai donné était périmé.
Je menais cinq projets en parallèle à l'époque — un site d'hôtellerie, une application de gestion financière, un site d'entreprise, un pitch deck, un portfolio personnel. Chacun avait son propre contexte IA. Chacun dérivait à son propre rythme. Aucun système ne reliait tout cela.
La première chose que j'ai construite était la mauvaise : plus de documentation.
Plus de détails, plus de structure, plus de couverture. Cela a aidé pendant une semaine. Puis ces fichiers ont eux aussi commencé à dériver.
La deuxième chose que j'ai construite s'est rapprochée du but : une matrice de déclencheurs. Chaque type de changement — nouvelle route, mise à jour de schéma, nouvelle dépendance, changement de modèle économique — associé au document exact devant être mis à jour. Dans la même PR. Pas comme un suivi. La tâche n'est pas terminée tant que la documentation ne reflète pas la réalité.
Cela a stoppé la dérive sur les projets individuels.
Mais la propagation à cinq dépôts a révélé la faille suivante. Les règles génériques ne survivent pas au contact de domaines spécifiques. L'application financière avait besoin d'un document de modèle de données. Le site d'hôtellerie avait besoin d'une spécification de portail. Le pitch deck avait besoin d'une couche d'affirmations vérifiées — car un investisseur demandant « d'où vient ce chiffre ? » n'est pas le moment de découvrir que votre fichier de contexte était optimiste.
Ce que j'ai fini par comprendre : il existe deux types de contexte. Le contexte qui appartient à un modèle partagé — règles de base, patterns d'architecture, cadence des bilans de santé. Et le contexte qui appartient au dépôt — décisions de domaine, anomalies de données, affirmations vérifiées. Les mélanger casse les deux.
La plupart des personnes confrontées à ce problème pensent avoir besoin de meilleurs outils d'IA. Ce dont elles ont généralement besoin, c'est d'une meilleure discipline de maintenance.
Le fichier de contexte n'est pas de la documentation. C'est un contrat entre vous et le modèle. Quand il se rompt, le modèle ne vous prévient pas. Il continue, tout simplement.
Si vous construisez avec des assistants IA sur plus d'un projet, la question qui mérite d'être posée maintenant — avant qu'elle ne vous coûte cher — est : qui met à jour le contexte quand quelque chose change, et comment sait-on qu'il doit être mis à jour ?
Le template est open source — lien en commentaire.
Sources
- ai-product-architecture-template (open source, GitHub): https://github.com/gtcuco-personal/ai-product-architecture-template