La seule chose que les labs ne peuvent pas livrer pour vous.
Objectif
L’écosystème IA est dans une course pour améliorer le harnais : connexions, outils, boucles de raisonnement, systèmes de mémoire, orchestrateurs.
Les labs vont relever le plancher sur tout cela toutes les quelques semaines.
Rien de tout cela ne vous appartient.
Votre contexte, oui.
La façon dont vous le structurez, le gouvernez et le portez à travers chaque session et chaque agent — c’est le seul avantage qui se compose avec vous dans le temps.
Ce guide décrit l’architecture qui le rend possible.
Principes fondamentaux
Le contexte est de l’architecture, pas du contenu
La structure détermine ce qu’un agent hérite. Un déversement non structuré est du bruit. Un contexte gouverné et stratifié est du levier.
La séparation des préoccupations s’applique ici aussi
Les décisions de projet, les schémas partagés et les principes de travail personnels ont des durées de vie différentes, des portées différentes et des buts différents. Ils ne devraient jamais vivre au même endroit.
Le contrôle de version est la discipline
Le contexte non versionné dérive. Les décisions sont écrasées. Les contraintes disparaissent silencieusement. Sans git, le système finira par s’effondrer sur lui-même.
La matière première est à vous de capturer
Les LLMs peuvent vous aider à structurer et raffiner le contexte. Ils ne peuvent pas le générer. Les décisions, les contraintes, les jugements — ceux-ci n’existent que dans votre travail. Les capturer ou les perdre.
La maintenance n’est pas optionnelle
Le bruit accumulé est pire que l’absence de contexte. Les contraintes périmées induisent les agents en erreur. Les décisions obsolètes créent de faux planchers. Le système nécessite un élagage périodique.
Le contexte se compose ; tout le reste se réinitialise
Chaque session structurée se construit sur la précédente. Chaque décision capturée évite d’être redécouverte. L’écart entre une session qui hérite du contexte et une qui commence de zéro s’élargit avec chaque projet.
La pile de contexte à trois couches
Le système qui se compose de façon cohérente est construit sur trois couches distinctes, chacune avec sa propre portée et durée de vie.
Couche 1 — Contexte projet (dans le dépôt)
Cette couche vit à l’intérieur du dépôt du projet lui-même.
Elle contient :
- le modèle de domaine et ses contraintes
- les décisions architecturales et le raisonnement derrière elles
- les règles d’ingénierie et les standards de qualité
- les garde-fous qui gouvernent ce que les agents peuvent et ne peuvent pas générer
- les schémas clés et anti-schémas spécifiques à cette base de code
Chaque session d’agent commence d’ici, pas de zéro.
Le principe structurel clé : ces documents ne sont pas de la documentation. Ils ne sont pas écrits après coup. Ils sont opérationnels — chargés avant que toute session commence, gouvernant chaque décision de génération.
Ils répondent à : qu’est-ce qui est vrai sur ce système, et qu’est-ce qui doit rester vrai.
Couche 2 — Couche partagée (trans-projet)
Cette couche se situe au-dessus des projets individuels et en dessous de la couche personnelle.
Elle contient :
- les pratiques d’ingénierie qui s’appliquent quel que soit le projet
- les schémas réutilisables extraits du travail passé
- les commandes et compétences d’agent communes entre bases de code
- les cadres décisionnels qui récurrent dans différents contextes
Rien ici n’appartient à un seul projet.
C’est la couche qui convertit l’expérience isolée en infrastructure réutilisable.
Couche 3 — Couche personnelle (dépôt séparé)
Cette couche est entièrement séparée — son propre dépôt, son propre cycle de maintenance.
Elle contient :
- les principes de travail et valeurs cognitives par défaut
- comment les décisions sont prises sous contrainte
- les modèles de collaboration et le contexte relationnel
- les projets actifs et leur état actuel
- les garde-fous personnels qui s’appliquent à chaque session
Cette couche s’applique universellement. Elle se charge quel que soit le projet actif.
Elle répond à : comment cet opérateur pense, décide et travaille.
Ce qui appartient où
Le principe de routage est simple :
- Une décision qui affecte un projet → Couche 1
- Un schéma qui s’applique entre projets → Couche 2
- Tout ce qui gouverne votre façon de penser ou travailler → Couche 3
En cas de doute : plus la portée est étroite, plus la couche est basse.
Une contrainte sur une limite de domaine spécifique dans une base de code appartient à la Couche 1. Un principe sur la façon de gérer cette classe de problème en général appartient à la Couche 2. Un principe sur la façon dont vous abordez les compromis architecturaux appartient à la Couche 3.
Ne pas aplatir les couches pour réduire la friction. L’aplatissement est la façon dont le contexte devient du bruit.
Pourquoi git est non négociable
C’est la partie que la plupart des gens sautent — et où le système tombe en panne.
Le contexte géré sans contrôle de version n’est pas un système. C’est une pile de fichiers qui va diverger, se contredire, et finalement induire en erreur les agents qui travaillent avec.
Voici ce qui se passe sans :
- un agent met à jour une contrainte ; une session future hérite de la mauvaise version
- deux documents font des affirmations contradictoires ; il n’y a aucun moyen de savoir lequel est faisant autorité
- une décision est écrasée ; le raisonnement a disparu
- un changement de contexte introduit une régression ; il n’y a aucun moyen de le revenir en arrière
Les agents IA eux-mêmes — ceux utilisés pour enrichir et maintenir le contexte au fur et à mesure — ont besoin d’opérer contre un dépôt avec un historique de commits complet. C’est le seul moyen que leurs changements puissent être revus, audités et fiables.
Cela nécessite :
- un dépôt git pour chaque couche de la pile
- un hôte distant (GitHub, GitLab, ou équivalent) — les dépôts locaux seulement ne survivent pas aux réinitialisations machine, changements d’outillage, ou toute forme de collaboration
- une connaissance opérationnelle de git suffisante pour revoir les diffs, annuler les changements et brancher quand les agents font des modifications structurelles
Le dépôt distant n’est pas une infrastructure optionnelle. C’est ce qui maintient le système cohérent dans le temps, entre les agents, et entre les contributeurs.
Si vous ne pouvez pas revoir ce qui a changé et pourquoi, vous ne pouvez pas faire confiance à ce que l’agent hérite lors de la prochaine session.
Ce n’est pas une bonne pratique. C’est une exigence structurelle. Sans elle, le système de contexte scalera vers le chaos plutôt que se composer en levier.
Le contrat de maintenance
Un système de contexte sans contrat de maintenance décroît plus vite qu’aucun système du tout.
Le contrat est simple :
Capturer les décisions à la couche où elles appartiennent, pas après coup.
Quand une limite architecturale est établie, elle va dans la Couche 1 immédiatement — pas dans un backlog, pas dans un commentaire, pas dans un fil de chat.
Élaguer quand les sessions commencent à produire de la dérive.
La dérive est le signal. Quand les sorties d’agent commencent à désaligner avec l’intention, le contexte est périmé. Investiguer avant d’ajouter de nouveaux documents — le correctif est généralement la suppression, pas l’addition.
Promouvoir les schémas qui récurrent.
Quand la même contrainte apparaît dans plusieurs projets, elle appartient à la Couche 2. Les schémas qui survivent à deux projets sont prêts à être abstraits. Ne pas attendre trois.
Laisser les agents maintenir le contexte — mais revoir chaque changement.
Les agents peuvent être utilisés pour enrichir, restructurer et mettre à jour le contexte dans le temps. C’est une partie de la valeur. Mais chaque changement qu’un agent fait à un dépôt de contexte est un commit à revoir, pas une sauvegarde à faire confiance aveuglément.
L’étape de revue est ce qui maintient le système honnête.
Comment ça fonctionne en pratique
Avant toute session :
- le contexte projet pertinent (Couche 1) est attaché
- la couche partagée applicable (Couche 2) est référencée
- la couche opérationnelle personnelle (Couche 3) est chargée
L’agent hérite du jugement accumulé des décisions passées.
Il ne commence pas d’un prompt vide. Il commence d’une position structurée.
La session produit une sortie. Une partie de cette sortie révèle de nouvelles contraintes, confirme des schémas existants, ou remonte des décisions qui valent la peine d’être capturées.
À la fin de la session, ces insights sont promus dans la couche appropriée — committés, revus, poussés.
La prochaine session commence d’une position plus riche que la précédente.
C’est le mécanisme de composition.
Comment vous pouvez construire ceci
Vous n’avez pas besoin de commencer avec les trois couches.
Commencer avec la Couche 1, dans un projet.
Créer un dossier dans le dépôt. Ajouter les contraintes non évidentes — celles qu’un agent violerait sans contexte. Ajouter les décisions architecturales avec leur raisonnement. Ajouter les garde-fous.
Committer tout. Le pousser vers un dépôt distant.
Construire la Couche 2 quand les schémas commencent à récurrer.
La deuxième fois que vous extrayez le même principe de deux projets différents, il appartient à un dépôt partagé. Le créer alors, pas avant.
Construire la Couche 3 quand vous remarquez que chaque session a besoin des mêmes corrections comportementales.
Si vous vous retrouvez à ré-établir les mêmes principes de travail au début de chaque session — les mêmes valeurs par défaut, les mêmes contraintes, le même cadre décisionnel — ceux-ci appartiennent à une couche personnelle. Les documenter une fois. Les charger toujours.
Pourquoi ça compte
La différence de débit entre une session qui commence avec du contexte structuré et une qui commence de zéro n’est pas marginale.
L’écart se compose avec la complexité du projet et avec le temps.
La plupart des gains de productivité IA sont des gains au niveau du prompt. Ils sont réels — mais ils se réinitialisent. Chaque session, chaque nouvel agent, chaque changement de contexte revient à zéro.
Les gains au niveau du contexte ne se réinitialisent pas.
L’architecture est l’actif.
Les LLMs seront meilleurs pour vous aider à le construire et maintenir.
La matière première — les décisions, les contraintes, le jugement — est à vous de capturer ou de perdre.
Personne ne le construira pour vous.
Le contexte est l’avantage. Tout le reste est de l’infrastructure.
Les sept principes opérationnels qui gouvernent comment gérer la couche d’orchestration — ce qui s’écrit, comment la mémoire est structurée en tiers, comment la boucle reste fermée — sont dans Agentic AI Orchestration — 7 principes opérationnels. Cette pièce est l’architecture ; celle-là est la discipline opérationnelle pour la faire tourner.
L’implémentation concrète de cette stack de contexte à trois couches — l’arborescence de fichiers réelle, les noms de hooks et de skills, le harness qui tourne par-dessus — est dans The Agent Harness That Runs 80% of My Work. Et la doctrine sur pourquoi le harness est la surface de levier, pas le modèle, est dans The Harness Behind the Agent.