Monorepo et contexte partagé : l'infrastructure du Compound Engineering
L'ingénierie logicielle à l'ère des agents : un changement de paradigme silencieux
Il se passe quelque chose d'intéressant dans les équipes de développement qui travaillent sérieusement avec des agents IA. Celles qui obtiennent les meilleurs résultats ne sont pas forcément celles qui maîtrisent le mieux les modèles de langage. Ce sont celles qui ont compris que le vrai travail se fait avant le prompt.
Cette intuition, confirmée par les travaux de Vasilopoulos, Debois, Shipper et Klaassen sur la période 2025-2026, est au cœur d'un mouvement qu'on commence à appeler le Compound Engineering. Et pour le mettre en œuvre concrètement dans une organisation, l'infrastructure de monorepo et de contexte partagé joue un rôle central.
Explorons pourquoi, et surtout comment.
Le paradoxe du prompt vide : pourquoi 100 mots ne suffisent plus
Une étude portant sur 283 sessions de travail avec des agents IA révèle un chiffre contre-intuitif : 80% du travail effectif se fait avant le prompt. Et pourtant, la grande majorité des prompts humains font moins de 100 mots. Il y a là une contradiction fondamentale.
Patrick Debois, l'inventeur du DevOps, formule cette tension de façon particulièrement frappante :
"Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir."
C'est précisément le problème. Un agent IA, aussi puissant soit-il, commence chaque interaction sans aucune connaissance du contexte projet, des conventions de l'équipe, des décisions architecturales passées, ou des erreurs déjà commises. Si vous ne lui fournissez pas ces éléments de façon explicite et structurée, il les invente — ou pire, il applique des patterns génériques qui entrent en conflit avec votre réalité.
La réponse historique à ce problème a été le Prompt Engineering : affiner, itérer, optimiser chaque instruction pour obtenir le meilleur résultat possible d'une interaction isolée. C'est une approche artisanale, avec un retour sur investissement linéaire au mieux.
Le Context Engineering représente un changement de logique fondamental. On ne cherche plus à optimiser une interaction, mais à construire l'environnement dans lequel toutes les interactions futures se dérouleront. La mémoire devient persistante, l'approche devient industrielle, et le retour sur investissement devient composé — chaque effort s'appuie sur les précédents.
C'est une distinction qui peut sembler subtile, mais ses implications pratiques sont considérables. Et l'infrastructure qui la rend possible, c'est souvent un monorepo bien pensé, avec un contexte partagé versionné.
L'architecture en 3 tiers : structurer ce que l'agent doit savoir
Avant de parler de monorepo, il faut comprendre comment organiser le contexte lui-même. Vasilopoulos propose une architecture en trois tiers qui structure la connaissance fournie aux agents selon sa fréquence d'utilisation et sa nature.
Tier 1 : Hot Memory (La Constitution)
C'est le contexte toujours chargé. Il contient les conventions fondamentales, les principes non-négociables, la "culture d'entreprise" de l'agent. C'est ce qu'on pourrait appeler l'ADN du projet : les choix de stack, les règles de nommage, les patterns architecturaux adoptés, les contraintes de sécurité incontournables.
Dans un monorepo, ce tier correspond typiquement à des fichiers comme AGENTS.md, .cursor/rules, ou des fichiers de configuration d'agent placés à la racine. Ils sont courts, stables, et chargés à chaque session sans exception.
Tier 2 : Warm Memory (Les Experts Spécialisés)
Ce sont des agents ou des modules de contexte invoqués à la demande, selon la nature de la tâche. Un contexte spécifique au module de facturation, un autre aux APIs d'authentification, un autre aux conventions de test. Ce tier est composé à environ 50% de faits factuels et peu de directives.
Dans un monorepo, ces contextes vivent naturellement près du code qu'ils décrivent — dans les sous-répertoires de chaque module ou package. Leur proximité avec le code source est une force : ils sont plus faciles à maintenir, et les développeurs qui modifient le code pensent naturellement à mettre à jour le contexte associé.
Tier 3 : Cold Memory (La Base de Connaissance)
C'est le savoir de référence massif : spécifications, documentation technique, historique de décisions architecturales (ADRs), runbooks. Ce contenu est volumineux et n'est tiré qu'au besoin, généralement via une recherche sémantique ou une référence explicite.
Un monorepo est particulièrement bien adapté à la gestion de cette couche, car il centralise naturellement toute la documentation de référence en un seul endroit, versionné avec le code qu'il décrit.
Pourquoi le monorepo est l'infrastructure naturelle du contexte partagé
La question de l'outillage n'est pas anodine. Le contexte IA, pour être utile, doit être versionné, partagé, maintenu et distribué — exactement comme du code. Et l'infrastructure qui réunit ces propriétés pour un ensemble de projets liés, c'est le monorepo.
Le contexte comme dépendance logicielle
L'une des idées les plus puissantes du Context Engineering est de traiter le contexte comme un package versionné, au même titre qu'une dépendance npm ou maven. Si votre agent doit connaître les conventions de votre API REST interne, cette connaissance est une dépendance — elle peut être importée, versionnée, mise à jour, et retirée.
Dans un monorepo, cette métaphore devient concrète. On peut imaginer un package @monorepo/context-api-conventions qui contient les règles de design d'API, référencé dans les configurations d'agents de tous les modules qui exposent des endpoints. Quand les conventions évoluent, on met à jour le package, on bump la version, et tous les consommateurs peuvent adopter la mise à jour de façon contrôlée.
Ce n'est pas de la théorie. Des équipes chez nos clients commencent à structurer leurs règles Cursor ou leurs fichiers de contexte Claude comme de véritables packages internes, avec leur propre cycle de vie.
La colocation code-contexte
Dans un polyrepo classique, la documentation et les règles de contexte ont tendance à dériver vers des wikis externes, des Notion, des Google Docs — des endroits déconnectés du code qui évoluent indépendamment et finissent par diverger.
Un monorepo encourage la colocation : le contexte vit là où vit le code. Quand un développeur modifie un module, il voit immédiatement les fichiers de contexte associés. La pull request qui ajoute une nouvelle fonctionnalité peut — et devrait — inclure la mise à jour du contexte correspondant.
C'est un changement culturel autant que technique, mais l'infrastructure du monorepo le facilite considérablement.
La surface d'attaque et la gouvernance
Un point souvent négligé : le contexte fourni aux agents représente une surface d'attaque potentielle. Un fichier de contexte qui contient des informations sensibles (credentials, données clients, logique métier critique) et qui est accessible à tous les agents sans contrôle d'accès est un vecteur de risque.
Le monorepo, combiné aux outils de gestion des accès (CODEOWNERS, permissions par répertoire, secrets management), permet d'implémenter une gouvernance fine. On peut définir qui peut lire, modifier, ou approuver les changements sur les fichiers de contexte sensibles — avec les mêmes mécanismes que ceux utilisés pour le code de production.
Le CDLC : quand DevOps rencontre l'ingénierie de contexte
Si le monorepo est l'infrastructure, le Context Development Lifecycle (CDLC) en est le processus. Patrick Debois, fort de son expérience fondatrice du mouvement DevOps, a transposé les principes DevOps à la gestion du contexte IA. Le résultat est un cycle en quatre phases qui structure la vie du contexte de sa création à son amélioration continue.
Générer : rendre l'implicite explicite
La première phase est souvent la plus difficile. Il s'agit d'extérioriser la connaissance tacite qui existe dans les têtes des développeurs, dans les discussions Slack, dans les revues de code. Cette connaissance est précieuse, mais elle est invisible pour un agent.
Concrètement, cela peut prendre la forme d'ateliers de capture de contexte, d'analyses de code existant pour en extraire les patterns implicites, ou simplement d'une discipline d'écriture : "si j'explique ce principe pour la deuxième fois, je l'écris dans le fichier de contexte."
Évaluer : le TDD du contexte
L'une des idées les plus stimulantes du CDLC est d'appliquer la logique du Test-Driven Development au contexte. Un échec de l'agent n'est pas un défaut de l'agent — c'est une spécification non écrite. Si l'agent produit du code qui ne respecte pas vos conventions, ce n'est pas qu'il est "bête" : c'est que personne ne lui a dit que ces conventions existaient.
Cette inversion de perspective est libératrice et responsabilisante. Elle transforme la frustration ("l'IA ne comprend pas ce que je veux") en action ("je dois mieux documenter ce que je veux"). Et dans un monorepo, cette documentation prend la forme de fichiers de contexte versionnés, révisables, testables.
Distribuer : le package versionné
Une fois le contexte créé et validé, il faut le distribuer de façon contrôlée. Dans un monorepo avec un outillage adapté (Nx, Turborepo, Bazel), cette distribution peut être automatisée : les pipelines CI/CD valident les fichiers de contexte, vérifient leur cohérence, et les rendent disponibles aux bons endroits.
Observer : la boucle de feedback
La phase finale — et celle qu'on oublie le plus souvent — est l'observation en production. Les hésitations de l'agent sont des signaux. Quand un agent demande des clarifications répétées sur le même sujet, quand il produit systématiquement du code qui nécessite correction dans un domaine particulier, c'est une lacune de la spec qui se manifeste.
Instrumenter cette observation est encore un domaine émergent, mais des approches comme l'analyse des logs de sessions, le tracking des corrections manuelles post-génération, ou simplement une rétrospective hebdomadaire sur les "bugs de documentation" permettent de fermer la boucle.
Le Compound Engineering : l'inversion de la complexité
Voilà le concept le plus ambitieux — et le plus séduisant — de tout cet écosystème. Dans l'ingénierie traditionnelle, la complexité croît. Chaque nouvelle fonctionnalité s'appuie sur une base de plus en plus complexe, alourdie par la dette technique, les dépendances, les effets de bord. La dixième fonctionnalité est plus difficile à développer que la première.
Le Compound Engineering inverse cette dynamique. Avec un contexte bien structuré et continuellement enrichi, chaque fonctionnalité développée rend la suivante plus facile. Les patterns appris sont documentés. Les erreurs commises ne se reproduisent pas. Les décisions architecturales sont explicites et réutilisables. L'agent s'améliore — non pas parce que le modèle évolue, mais parce que l'environnement dans lequel il opère devient plus riche et plus précis.
La répartition du temps selon Shipper et Klaassen
Shipper et Klaassen proposent une répartition du temps qui illustre concrètement ce changement de philosophie :
- PLAN : Enseigner au système — structurer le contexte avant d'exécuter
- WORK : Exécution — le travail proprement dit, qui devient rapide (~10% du temps)
- ASSESS : Évaluation multi-axes — la validation est longue (~40% du temps)
- COMPOUND : Stockage des leçons — chaque bug et insight est documenté pour les cycles futurs
Ce qui frappe dans cette répartition, c'est la place donnée à l'évaluation et à la capitalisation. L'exécution n'est que 10% du temps. L'essentiel est dans la préparation et dans l'apprentissage. C'est une rupture profonde avec le modèle "code vite, debug longtemps" qui caractérise une grande partie du développement traditionnel.
L'étape "Compound" : la magie opère ici
L'étape COMPOUND est décrite comme "l'étape magique" — et pour cause. C'est elle qui transforme un investissement puntuel en actif durable. Documenter un bug résolu n'est plus une corvée administrative : c'est alimenter un système qui vous fera gagner du temps sur tous les bugs similaires à venir. L'incentive est aligné avec l'intérêt immédiat du développeur.
Dans un monorepo, cette étape se traduit concrètement par : une PR qui résout un bug inclut une mise à jour du fichier de contexte expliquant pourquoi ce pattern était problématique et quelle approche est préférée. Trivial à mettre en place, puissant sur la durée.
Mise en œuvre pratique : ce que nous voyons chez nos clients
Chez SFEIR, nous accompagnons des équipes de toutes tailles dans l'adoption de ces pratiques. Quelques patterns concrets que nous observons et recommandons :
Démarrer avec un fichier AGENTS.md à la racine
La première étape, souvent la plus impactante, est simplement de créer un fichier de contexte à la racine du monorepo. Ce fichier (souvent appelé AGENTS.md, CLAUDE.md, ou .cursor/rules selon l'outillage) contient les règles fondamentales : stack technique, conventions de nommage, patterns architecturaux, contraintes de sécurité. C'est le Tier 1 (Hot Memory) de Vasilopoulos.
Ce fichier doit être court. Court et précis vaut mieux que long et vague. Un contexte de 200 lignes bien écrit surpasse un contexte de 2000 lignes dilué. Commencer petit, enrichir au fil des sessions.
Instrumenter la boucle de feedback dès le début
Mettre en place un rituel simple : en fin de sprint, identifier les 2-3 sujets sur lesquels l'agent a eu le plus de difficultés ou produit le plus de corrections. Pour chacun, écrire une règle de contexte. C'est le début du CDLC.
Le coût marginal est faible — les études citées par Shipper et Klaassen suggèrent qu'une à deux heures de maintenance par semaine suffisent à faire fonctionner ce système de façon autonome et croissante.
Traiter les ADRs (Architecture Decision Records) comme du contexte de premier ordre
Les Architecture Decision Records sont une pratique bien établie, mais ils sont souvent sous-exploités dans le contexte IA. Un ADR bien structuré est un contexte parfait pour le Tier 3 (Cold Memory) : il explique non seulement ce qui a été décidé, mais pourquoi, et quelles alternatives ont été écartées. Cette information de contexte décisionnel est extrêmement précieuse pour un agent qui doit prendre des décisions cohérentes avec l'histoire du projet.
Gouvernance et revue des fichiers de contexte
Un point que nous insistons particulièrement : les fichiers de contexte doivent passer par le même processus de revue que le code. Une règle de contexte mal formulée ou obsolète peut induire l'agent en erreur de façon systématique — bien plus dangereuse qu'une absence de règle. Comme le soulignent les travaux de référence : "une spec périmée est pire que pas de spec : elle induit l'agent en erreur activement."
Désigner un ou plusieurs responsables de la qualité du contexte, intégrer sa revue dans les processus de PR, et traquer activement le "context rot" — la dégradation naturelle du contexte au fil du temps — sont des pratiques de gouvernance essentielles.
Vers une nouvelle définition de l'excellence en ingénierie logicielle
Les travaux que nous avons explorés convergent vers une conclusion qui peut sembler provocatrice mais qui est de plus en plus partagée dans les équipes les plus avancées :
L'ingénieur de demain ne sera pas celui qui écrit le meilleur code, mais celui qui structure le meilleur contexte.
Cette formulation ne dévalorise pas les compétences techniques traditionnelles — elles restent fondamentales pour évaluer la qualité du code produit, concevoir les architectures, et valider les décisions. Mais elle ajoute une nouvelle compétence critique : la capacité à externaliser et structurer la connaissance de façon à ce qu'un agent puisse la consommer et la réutiliser.
Les trois visions qui convergent dans le Compound Engineering illustrent bien cette complémentarité :
- Vasilopoulos (Architecture) : Un contexte bien structuré en 3 tiers accélère toutes les fonctionnalités adjacentes. C'est un investissement en infrastructure.
- Debois (Méthodologie) : Le "Context Flywheel" crée une boucle vertueuse où l'output enrichit l'input. C'est une pratique organisationnelle.
- Shipper et Klaassen (Pratique) : L'étape "Compound" transforme la documentation en carburant productif. C'est un changement de comportement individuel.
Ces trois niveaux — infrastructure, organisation, individu — doivent être adressés ensemble pour que le Compound Engineering déploie tout son potentiel. Et l'infrastructure de monorepo avec contexte partagé est le socle qui rend possible l'articulation des trois.
La promesse, pour les équipes qui franchissent ce pas ? Une vélocité de développement significativement amplifiée, des incitations enfin alignées entre intérêt individuel et bénéfice collectif, et un système qui s'améliore de lui-même — non pas parce que les modèles deviennent plus intelligents, mais parce que l'environnement dans lequel ils opèrent devient plus riche, plus précis, et plus vivant.
Chez SFEIR, nous sommes convaincus que cette transition vers le Context Engineering et le Compound Engineering n'est pas une mode passagère, mais un changement structurel dans la façon dont les équipes d'ingénierie créent de la valeur. Nos consultants accompagnent cette transformation — de l'audit des pratiques actuelles à la mise en place des infrastructures de contexte partagé, en passant par la formation des équipes aux nouveaux paradigmes. Si ces sujets résonnent avec vos enjeux, nous serions ravis d'en discuter.