Compound Engineering : comment chaque cycle rend le suivant plus facile

Le paradoxe du prompt vide : pourquoi votre IA recommence toujours de zéro

Imaginez embaucher un développeur senior chaque matin, lui expliquer l'intégralité de votre projet, vos conventions, votre architecture, vos décisions passées — puis le voir partir à 17h sans laisser la moindre note. Le lendemain, vous recommencez. Absurde ? C'est pourtant exactement ce que vivent la plupart des équipes qui travaillent avec des agents IA aujourd'hui.

Patrick Debois, l'inventeur du DevOps, résume ce paradoxe avec une formule qui fait mouche : « Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir. »

Et pourtant, les équipes s'obstinent. Elles perfectionnent leurs prompts, cherchent la formulation magique, optimisent l'interaction du moment — sans jamais s'attaquer au problème de fond : l'absence d'infrastructure contextuelle persistante. Une étude portant sur 283 sessions de développement assisté par IA révèle que la grande majorité du travail réel se fait avant le prompt lui-même. L'infrastructure contextuelle représente désormais 24,2 % de la documentation totale dans les projets bien organisés. Ce chiffre, anodin en apparence, cache une révolution silencieuse dans la façon de concevoir le développement logiciel.

C'est dans ce contexte que s'impose un nouveau paradigme : le Context Engineering. Et à SFEIR, nous sommes convaincus qu'il constitue l'un des leviers de transformation les plus sous-estimés de la software factory moderne.

Prompt Engineering vs Context Engineering : un changement de civilisation

Le Prompt Engineering est l'art de formuler la bonne question. C'est utile, parfois décisif, mais fondamentalement limité : il optimise une interaction isolée, dans une session éphémère, selon une logique artisanale dont le retour sur investissement est linéaire — voire dégressif à mesure que la complexité du projet augmente.

Le Context Engineering, lui, opère à un niveau supérieur. Il ne s'agit plus d'optimiser ce qui est dit à l'agent, mais de construire l'environnement cognitif dans lequel il opère. La mémoire devient persistante, cross-sessions. L'approche devient industrielle. Et surtout, le retour sur investissement devient composé — chaque effort de structuration du contexte bénéficie à tous les cycles suivants.

Ce basculement peut sembler subtil. Il est en réalité radical. Dans un modèle de Prompt Engineering, un développeur qui quitte l'équipe emporte avec lui sa connaissance des "bons prompts". Dans un modèle de Context Engineering, cette connaissance est externalisée, versionnée, partageable — et surtout, elle s'accumule.

Pour les équipes engineering que nous accompagnons chez SFEIR, c'est précisément là que se joue la compétitivité à moyen terme : non pas dans la qualité des instructions ponctuelles données à un LLM, mais dans la richesse et la rigueur du contexte qu'on lui construit.

L'architecture en 3 tiers : structurer la mémoire de vos agents

Construire du contexte, soit. Mais comment ? Les travaux de Vasilopoulos proposent une architecture en trois niveaux qui offre un cadre opérationnel particulièrement efficace pour les équipes produit et engineering.

Tier 1 — Hot Memory : la constitution de l'agent

C'est le contexte toujours chargé, présent à chaque interaction sans exception. On y trouve les conventions fondamentales du projet : style de code, principes d'architecture, règles métier non négociables, ton attendu, contraintes de sécurité. C'est la "culture d'entreprise" de l'agent — ce qu'il doit savoir par cœur pour ne jamais produire quelque chose d'incohérent avec l'environnement dans lequel il opère.

Dans la pratique, pour un projet chez l'un de nos clients bancaires par exemple, la Hot Memory pourrait inclure : les patterns d'architecture hexagonale adoptés par l'équipe, les conventions de nommage, les règles de gestion des erreurs, et les contraintes réglementaires structurantes. Ce socle ne dépasse généralement pas quelques centaines de tokens — mais son absence se paie à chaque session.

Tier 2 — Warm Memory : les experts à la demande

Ce deuxième niveau regroupe des agents spécialisés ou des blocs de contexte thématiques, invoqués en fonction de la nature de la tâche. Vasilopoulos recommande une composition à dominante factuelle : environ 50 % de faits, peu de directives générales. L'idée est de donner à l'agent une expertise ciblée quand il en a besoin, sans surcharger chaque interaction avec l'intégralité du savoir disponible.

Concrètement : un agent dédié aux tests unitaires, un autre à la revue de sécurité, un troisième à la génération de documentation API. Chacun est activé selon le contexte de la tâche, apportant une profondeur de connaissance que la Hot Memory ne peut pas seule fournir.

Tier 3 — Cold Memory : la base de connaissance de référence

C'est le savoir de référence massif : spécifications techniques, documentation existante, historique des décisions d'architecture, tickets résolus. Il n'est pas chargé par défaut — il est tiré au besoin, via des mécanismes de retrieval (RAG ou équivalents). Son rôle est de permettre à l'agent de trouver la bonne réponse précise sans saturer le contexte avec des informations non pertinentes.

Cette architecture en 3 tiers répond à une contrainte réelle : les fenêtres de contexte des LLMs, aussi grandes soient-elles, ne sont pas infinies, et la qualité de la réponse se dégrade quand le contexte est trop dense ou mal structuré. Savoir quoi charger, quand et à quel niveau, est une compétence d'ingénierie à part entière.

Le CDLC : quand le DevOps rencontre l'ingénierie du contexte

Si le Context Engineering définit ce que l'on construit, le Context Development Lifecycle (CDLC) définit comment on le maintient dans le temps. C'est, en quelque sorte, le DevOps de l'IA — une boucle continue de génération, d'évaluation, de distribution et d'observation.

Générer : rendre l'implicite explicite

La première étape est souvent la plus difficile : mettre des mots sur ce que l'équipe sait tacitement. Les conventions qui "vont de soi", les décisions prises "parce qu'on l'a toujours fait comme ça", les contraintes métier que tout le monde connaît mais que personne n'a jamais formalisées. Ce travail de cristallisation du savoir implicite est le fondement de tout système de Context Engineering efficace.

Évaluer : le TDD du contexte

Le CDLC emprunte au Test-Driven Development une idée fondatrice : un échec d'évaluation n'est pas un défaut de l'agent, c'est une spécification non écrite. Si votre agent produit systématiquement des réponses inadaptées sur un sujet donné, la bonne question n'est pas "comment améliorer le modèle ?" mais "qu'est-ce que le contexte ne dit pas encore ?"

Cette inversion est puissante. Elle transforme chaque erreur de l'IA en signal d'amélioration du système, et non en frustration à l'égard de la technologie. Comme le formule Debois avec une clarté désarmante : si vous devez expliquer deux fois la même chose, c'est un bug de documentation.

Distribuer : le contexte comme dépendance logicielle

Une fois le contexte produit et validé, il doit être distribué de manière fiable et reproductible. Le CDLC traite le contexte comme un package versionné, à l'image d'une dépendance npm ou maven. Cela implique gestion des versions, changelog, compatibilité, et surtout : une forme de gouvernance claire sur qui peut modifier quoi.

Cette approche résout un problème organisationnel souvent sous-estimé : dans les équipes qui n'ont pas de gestion formelle du contexte, chaque développeur maintient sa propre version des "bons prompts" dans un coin de son éditeur. La connaissance est silotée, non partageable, et s'évapore avec les départs. Versionner le contexte, c'est transformer un actif individuel en actif collectif.

Il faut également souligner la dimension sécurité : le contexte constitue une surface d'attaque non négligeable. Il peut contenir des informations sensibles sur l'architecture, les règles métier ou les contraintes de conformité. Audit, contrôle d'accès et gouvernance ne sont pas des options — ils sont structurants.

Observer : la boucle de feedback comme radar

La dernière étape ferme la boucle : observer le comportement de l'agent en production pour détecter les lacunes du contexte. Les hésitations, les reformulations répétées, les erreurs récurrentes sur un même type de tâche — tous ces signaux indiquent des zones du contexte à enrichir. L'observation transforme le système de contexte en organisme vivant, capable d'apprendre de son propre déploiement.

Le Compound Engineering : l'inversion de la complexité

Nous arrivons au cœur du sujet — et à ce qui rend cette approche véritablement transformatrice pour les équipes engineering modernes.

Dans le développement logiciel traditionnel, la complexité est croissante : chaque nouvelle feature s'appuie sur un empilement de code existant, génère de la dette technique, crée des effets de bord imprévus. Les premières itérations d'un projet sont rapides et légères ; les suivantes sont lentes et lourdes. C'est la loi de gravité de l'ingénierie classique.

Le Compound Engineering inverse cette dynamique. En capitalisant systématiquement le contexte produit à chaque cycle, chaque feature rend la suivante plus facile et non plus difficile. Les décisions sont documentées, les patterns sont codifiés, les erreurs passées deviennent des garde-fous. La courbe d'effort, au lieu de monter, descend progressivement.

La répartition du temps selon Shipper & Klaassen

Ce changement de dynamique ne s'opère pas par magie. Il repose sur une discipline de travail spécifique, formalisée par Shipper et Klaassen en quatre phases :

• Plan (Enseigner au système) : avant d'exécuter, structurer le contexte que l'agent va consommer. C'est un investissement, pas une perte de temps.
• Work (Exécution) : la phase d'exécution elle-même — paradoxalement la plus courte dans ce modèle.
• Assess (Évaluation multi-axes) : valider non seulement le résultat, mais la qualité du contexte qui l'a produit. La validation prend du temps — et c'est normal. Shipper et Klaassen estiment que si l'exécution représente environ 10 % du cycle, la validation en représente environ 40 %.
• Compound (Stockage des leçons) : l'étape "magique". Chaque bug résolu, chaque insight produit, chaque décision prise est documenté et intégré au contexte pour les cycles futurs.

C'est cette dernière étape qui fait toute la différence. Sans elle, le système travaille dur mais n'apprend pas. Avec elle, chaque cycle enrichit le substrat cognitif de l'agent — et le prochain cycle démarre plus haut, plus vite, avec moins de friction.

La convergence des trois visions

Ce qui rend le Compound Engineering particulièrement solide, c'est qu'il est la synthèse de trois approches complémentaires :

• L'architecture de Vasilopoulos : un contexte bien structuré en 3 tiers accélère toutes les features adjacentes en créant un socle réutilisable.
• La méthodologie de Debois : le "Context Flywheel" crée une boucle vertueuse où chaque output enrichit l'input du cycle suivant.
• La pratique de Shipper : l'étape "Compound" transforme la documentation — souvent perçue comme une corvée — en carburant productif directement bénéfique à l'auteur lui-même.

Ce dernier point mérite qu'on s'y arrête. L'un des obstacles majeurs à la documentation dans les équipes engineering est l'absence d'incitation directe : je documente pour mes collègues, pour les futurs arrivants, pour la postérité — mais rarement pour moi, maintenant. Le Compound Engineering renverse cette logique : documenter aide directement l'auteur, car c'est lui qui travaillera avec cet agent demain, après-demain, et dans six mois. L'incitation égoïste et l'intérêt collectif convergent enfin.

Le SDLC augmenté : recomposer le cycle de développement logiciel

Ces trois concepts — Context Engineering, CDLC, Compound Engineering — ne sont pas des outils isolés. Ils s'inscrivent dans une vision plus large que nous appelons chez SFEIR le SDLC Augmenté : un cycle de développement logiciel repensé de fond en comble pour tirer parti des agents IA de manière systémique et durable.

Dans ce modèle, les phases traditionnelles du SDLC (conception, développement, test, déploiement, maintenance) sont chacune enrichies d'une couche de production et de consommation de contexte. La conception produit des spécifications lisibles par les agents. Le développement s'appuie sur un contexte riche pour accélérer l'exécution. Les tests alimentent le CDLC en signaux d'amélioration. Le déploiement intègre la distribution de packages de contexte versionnés. Et la maintenance devient l'occasion de raffiner et d'enrichir le substrat pour les prochains cycles.

Ce n'est pas une révolution cosmétique. C'est une restructuration profonde des rôles, des responsabilités et des livrables attendus de chaque phase. Dans un SDLC Augmenté, le tech lead n'est plus seulement garant de la qualité du code — il est aussi architecte du contexte. Le développeur n'est plus seulement exécutant — il est aussi producteur de connaissance structurée. Et l'équipe dans son ensemble construit, cycle après cycle, un avantage compétitif qui s'accumule et se capitalise.

Les données disponibles suggèrent que cet effort vaut largement l'investissement. Shipper et Klaassen estiment qu'un développeur équipé d'un système de Context Engineering mature peut être équivalent à cinq développeurs travaillant sans infrastructure contextuelle. Le coût de maintenance d'un tel système ? De l'ordre d'une à deux heures par semaine — pour un système qui s'améliore de lui-même à chaque cycle.

Ce que cela change concrètement : retours du terrain SFEIR

Chez SFEIR, nous accompagnons depuis plusieurs mois des équipes engineering dans la mise en place de ces principes sur des projets réels — dans les secteurs bancaire, industriel, et des médias notamment. Quelques observations concrètes issues de ces missions :

Le premier obstacle est culturel, pas technique. La plupart des équipes savent, intuitivement, que "mieux documenter le contexte" serait utile. Ce qui bloque, c'est l'absence de processus formalisé et d'incitation directe. Dès lors qu'on leur montre que l'étape "Compound" leur fait gagner du temps à eux dès le sprint suivant, l'adhésion vient naturellement.

La Hot Memory est sous-estimée. La tentation est de tout mettre dans le contexte — par exhaustivité. C'est une erreur. Un contexte trop dense dégrade la qualité des réponses autant qu'un contexte insuffisant. Le vrai travail est de distiller l'essentiel : quelles sont les cinq à dix choses que l'agent ne doit jamais ignorer sur ce projet ? Cette discipline de synthèse est en elle-même un exercice architectural précieux.

Le vieillissement du contexte est un risque réel. Comme Vasilopoulos le souligne, une spécification périmée est pire que pas de spécification : elle induit l'agent en erreur de manière active. Les équipes qui réussissent sont celles qui traitent la maintenance du contexte comme une dette technique — à adresser régulièrement, avec la même rigueur que la dette de code.

Les gains se mesurent sur la durée. Les premières semaines d'adoption du Compound Engineering sont souvent légèrement plus lentes — le temps d'établir les rituels, de structurer la Hot Memory initiale, de mettre en place le CDLC. C'est l'investissement de démarrage. À partir du deuxième ou troisième cycle, la vélocité monte de manière perceptible, et continue de monter. C'est la nature même de l'effet composé.

Conclusion : le contexte est un actif stratégique

Il y a une formule, issue des travaux que nous avons explorés dans cet article, qui résume peut-être mieux que tout ce que signifie cette transition : le contexte est un actif, pas une dépense.

Pendant des années, la documentation, la transmission du savoir, la formalisation des conventions ont été perçues comme des activités à valeur ajoutée faible — nécessaires, mais pas glorieuses. Le Compound Engineering renverse radicalement cette perception. Dans un SDLC Augmenté, le contexte que vous construisez aujourd'hui est du capital productif qui travaille pour vous demain, après-demain, et à chaque cycle futur.

L'ingénieur de demain ne sera pas nécessairement celui qui écrit le meilleur code. Ce sera celui qui structure le meilleur contexte — celui qui sait rendre ses agents plus intelligents, plus autonomes et plus alignés avec les besoins réels de son projet, itération après itération.

Chez SFEIR, nous croyons profondément que cette compétence — l'architecture du contexte, la maîtrise du CDLC, la discipline du Compound Engineering — est appelée à devenir aussi fondamentale que la maîtrise des patterns d'architecture ou des pratiques CI/CD l'ont été dans les décennies précédentes. Et comme pour ces dernières, les équipes qui l'adoptent tôt prendront une avance qui sera difficile à rattraper.

Si vous souhaitez explorer comment ces principes s'appliquent à votre contexte spécifique — votre stack, votre organisation, vos enjeux produit — nos équipes sont là pour en discuter. C'est précisément le type de transformation que nous accompagnons au quotidien.