Le CDLC : traiter le contexte comme une dépendance logicielle

Le paradoxe du prompt vide : quand 80 % du travail se passe avant d'écrire

Vous avez probablement déjà vécu cette situation : un développeur passe une heure à peaufiner un prompt, obtient un résultat médiocre, reformule, recommence, et finit par se demander si l'IA tient vraiment ses promesses. Ce que cette personne ignore souvent, c'est que le problème n'est pas dans les mots qu'elle choisit — il est dans tout ce qu'elle n'a pas dit.

Une étude analysant 283 sessions de travail avec des agents IA révèle quelque chose de contre-intuitif : 80 % du travail se fait avant même d'écrire le prompt. Et si l'on regarde la documentation produite dans ces projets, l'infrastructure contextuelle représente désormais 24,2 % du total. Pendant ce temps, la grande majorité des prompts humains font moins de 100 mots.

Nous nous sommes collectivement focalisés sur la mauvaise variable.

Patrick Debois, l'inventeur du DevOps et l'un des pionniers de la réflexion sur les agents IA, résume le problème avec une image saisissante : "Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir." Un LLM ne se souvient pas de la décision d'architecture prise il y a trois semaines. Il ignore que votre équipe a une convention de nommage spécifique. Il ne sait pas que ce client déteste les tableaux dans ses livrables. Chaque interaction recommence à zéro.

C'est le paradoxe fondamental de l'IA en entreprise : des outils extraordinairement capables, rendus ordinaires par l'absence d'un environnement qui les nourrit correctement. La réponse à ce paradoxe s'appelle le Context Engineering.

Du Prompt Engineering au Context Engineering : un changement de paradigme industriel

Le Prompt Engineering, tel qu'il est pratiqué aujourd'hui, ressemble à l'artisanat logiciel des années 80 : chaque interaction est optimisée individuellement, de manière isolée, avec une mémoire éphémère limitée à une session. Le retour sur investissement est linéaire — vous passez du temps, vous obtenez un résultat, la connaissance s'évapore.

Le Context Engineering représente le passage à l'ère industrielle. Il ne s'agit plus d'optimiser une requête, mais de construire et maintenir l'environnement cognitif dans lequel l'agent évolue. La mémoire devient persistante et traverse les sessions. L'approche est systématique, versionnée, gouvernée. Et le retour sur investissement devient composé — chaque effort de documentation amplifie les suivants.

Cette distinction n'est pas sémantique. Elle change profondément la façon dont une équipe d'ingénieurs doit penser son rapport aux outils IA. Un bon ingénieur IA de demain ne sera pas nécessairement celui qui écrit les prompts les plus élégants — ce sera celui qui aura su construire le meilleur contexte pour son domaine.

Chez SFEIR, nous observons ce glissement chez nos clients les plus avancés sur leurs usages IA : les équipes qui obtiennent les meilleurs résultats ne sont pas nécessairement celles qui ont les modèles les plus puissants. Ce sont celles qui ont investi dans la structuration de leur contexte métier.

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

Comment structure-t-on concrètement ce contexte ? Les travaux de Vasilopoulos proposent une architecture en trois niveaux, chacun ayant un rôle distinct et une fréquence de chargement différente.

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

Ce premier niveau est toujours chargé, quelle que soit la tâche demandée. Il contient ce que l'on pourrait appeler la "culture d'entreprise" de l'agent : ses conventions fondamentales, ses valeurs, ses règles non négociables. Dans un contexte de développement logiciel, cela peut inclure les principes d'architecture choisis par l'équipe, le style de code imposé, ou encore les contraintes de sécurité absolues. Dans un contexte rédactionnel, c'est le ton de marque, les termes à éviter, la structure type des livrables.

Ce niveau est court, dense en directives, et ne change que rarement. C'est la colonne vertébrale de l'agent.

Tier 2 — Warm Memory : les experts spécialisés

Le deuxième niveau contient des agents spécialisés invoqués à la demande selon le contexte de la tâche. Un agent "sécurité" chargé lors d'une revue de code, un agent "réglementaire RGPD" activé lors de la conception d'un formulaire, un agent "style editorial" déclenché pour une production de contenu. La composition de ce niveau est importante : environ 50 % de faits et de connaissances, peu de directives comportementales — contrairement au Tier 1.

Ce niveau permet de ne pas surcharger le contexte permanent avec des informations pertinentes seulement dans certaines situations.

Tier 3 — Cold Memory : la base de connaissances

Le troisième niveau est le savoir de référence massif — spécifications techniques, documentation produit, historique de décisions, tickets résolus — qui est tiré uniquement au besoin, généralement via un mécanisme de RAG (Retrieval-Augmented Generation). Ce niveau peut être volumineux sans poser de problème, précisément parce qu'il n'est pas chargé en permanence.

Cette architecture en tiers répond à une contrainte technique réelle : les fenêtres de contexte des LLMs ont des limites. Tout charger en permanence est inefficace et coûteux. Tout omettre prive l'agent des informations dont il a besoin. L'architecture 3 tiers est un compromis élégant entre richesse contextuelle et efficacité opérationnelle.

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

Si le contexte est un actif logiciel — et nous allons voir pourquoi cette analogie est profondément juste — alors il mérite d'être traité avec les mêmes rigueurs que le code : versionnement, tests, déploiement, surveillance. C'est précisément l'objet du Context Development Lifecycle (CDLC), une adaptation du SDLC classique à la réalité des systèmes IA.

Le CDLC se décompose en quatre phases itératives :

• Générer : rendre l'implicite explicite. Cette phase consiste à extraire et formaliser toute la connaissance tacite qui existe dans les têtes des experts métier, dans les échanges informels, dans les décisions jamais documentées. C'est souvent la phase la plus difficile, parce qu'elle exige de verbaliser ce qui "va de soi".
• Évaluer : le TDD du contexte. Avant de déployer un nouveau bloc de contexte, on le teste. Un échec d'évaluation n'est pas un défaut de l'agent — c'est une spécification non écrite. Si vous devez expliquer deux fois la même chose à votre agent, vous avez un bug de documentation, pas un bug de modèle.
• Distribuer : le package versionné. Le contexte se traite exactement comme une dépendance logicielle — à la manière d'un package npm ou Maven. Il est versionné, publié, consommé explicitement. Une équipe peut dépendre de context-securite@2.1.0 et choisir délibérément de ne pas migrer vers la version 3.0 tant que les tests ne passent pas.
• Observer : la boucle de feedback. En production, les hésitations de l'agent — les réponses vagues, les demandes de clarification répétées, les erreurs récurrentes sur un domaine précis — sont des signaux précieux. Ils indiquent les lacunes de la spécification contextuelle et alimentent le cycle de génération suivant.

Cette approche résout un problème que beaucoup d'équipes vivent sans pouvoir le nommer : le contexte pourrit. Comme le code, le contexte entre en conflit avec lui-même au fil du temps, devient obsolète, contredit les nouvelles réalités du projet. Et une spécification périmée est pire que pas de spécification : elle induit activement l'agent en erreur, avec une fausse assurance.

Le CDLC apporte une réponse structurelle à cette entropie. Il transforme la maintenance du contexte d'une activité informelle et réactive en une discipline d'ingénierie à part entière. C'est le SDLC augmenté — non pas remplacé, mais enrichi d'une nouvelle dimension de gestion des actifs cognitifs.

Sécurité et gouvernance : le contexte comme surface d'attaque

Traiter le contexte comme une dépendance logicielle implique également d'adopter les pratiques de sécurité associées. C'est un aspect souvent négligé dans les discussions sur le Context Engineering, mais crucial en environnement professionnel.

Un contexte mal gouverné représente une surface d'attaque réelle. Imaginons un agent de support client qui aurait accès, via son contexte, à des informations sur la stratégie tarifaire interne, les marges négociées avec certains clients, ou les procédures d'escalade confidentielles. Si ce contexte est mal contrôlé, il peut être extrait, manipulé, ou simplement exposé dans une réponse inadaptée.

La distribution du contexte comme package versionné offre une réponse naturelle à ce défi : chaque composant contextuel peut être soumis à un audit, associé à des droits d'accès différenciés, et tracé dans son cycle de vie. On sait quelle version du contexte était active lors d'un incident. On peut identifier qui a modifié quel bloc de connaissance et quand.

Sur ce point, l'analogie avec la gestion des dépendances logicielles est particulièrement féconde. Tout comme une organisation mature maintient un catalogue de dépendances approuvées et surveille les vulnérabilités (CVE), elle doit maintenir un catalogue de contextes approuvés et surveiller leur intégrité. C'est un chantier que nous accompagnons régulièrement chez SFEIR dans le cadre des missions de mise en production d'agents IA pour nos clients.

Le Compound Engineering : quand chaque feature rend la suivante plus facile

L'ingénierie logicielle traditionnelle souffre d'une loi de gravité cruelle : chaque nouvelle fonctionnalité est plus difficile que la précédente. La base de code grossit, les interdépendances se multiplient, la dette technique s'accumule. La vélocité diminue mécaniquement avec le temps.

Le Compound Engineering, tel que formalisé par Shipper et Klaassen, propose une inversion de cette courbe. Dans un système où le contexte est correctement géré, chaque fonctionnalité développée enrichit la base de connaissance disponible pour les suivantes. L'agent comprend mieux le domaine. Les patterns récurrents sont documentés. Les erreurs passées sont explicitement encodées pour ne pas être répétées. La complexité effective diminue avec le temps.

La méthode se structure autour de quatre phases de répartition du temps :

• Plan (Enseigner au système) : avant d'exécuter une tâche, on produit du contexte structuré que l'agent peut consommer. On ne démarre pas en mode "prompt and pray" — on prépare l'environnement cognitif.
• Work (Exécution) : la phase d'exécution elle-même, rendue plus rapide et plus fiable par le contexte préparé en amont.
• Assess (Évaluation multi-axes) : contre-intuitivement, cette phase est proportionnellement plus longue que l'exécution. L'évaluation rigoureuse du résultat sur plusieurs dimensions — qualité technique, conformité aux spécifications, cohérence avec le contexte existant — est ce qui permet d'alimenter correctement la phase suivante.
• Compound (Stockage des leçons) : c'est "l'étape magique". Chaque bug résolu, chaque insight généré, chaque décision prise est documenté de manière structurée pour les cycles futurs. Ce n'est pas de la documentation pour la documentation — c'est du carburant productif.

Les gains observés sont significatifs. Shipper et Klaassen avancent qu'un développeur bien outillé en contexte peut équivaloir à cinq développeurs traditionnels en termes de vélocité. Et le coût de maintenance de ce système — environ une à deux heures par semaine selon leurs estimations — est remarquablement faible au regard des bénéfices.

Ce qui rend ce modèle particulièrement intéressant d'un point de vue organisationnel, c'est qu'il résout un problème classique de l'ingénierie : l'alignement des incitations. Dans un système traditionnel, documenter son travail profite à l'équipe mais coûte du temps à l'individu. Dans le modèle Compound, documenter aide directement l'auteur lors de ses prochaines sessions de travail. La connaissance partagée sert l'intérêt "égoïste" du développeur — ce qui est peut-être la meilleure façon de s'assurer qu'elle sera effectivement partagée.

La convergence des trois visions : architecture, méthodologie, pratique

Ce qui rend le cadre du Context Engineering particulièrement robuste, c'est qu'il émerge de la convergence de trois perspectives complémentaires, chacune apportant une couche de cohérence à l'ensemble.

L'architecture proposée par Vasilopoulos — les trois tiers de mémoire — n'est pas seulement une solution technique élégante. Elle reflète une intuition profonde sur la manière dont la connaissance doit être organisée pour être utile : certaines vérités sont toujours vraies et doivent toujours être présentes (Hot), d'autres sont pertinentes dans des contextes spécifiques (Warm), d'autres encore sont des références que l'on consulte ponctuellement (Cold). Cette structure accélère mécaniquement les features adjacentes parce qu'elle évite la redondance et la contradiction.

La méthodologie développée par Debois autour du "Context Flywheel" formalise la dynamique de capitalisation. L'output d'une session enrichit l'input de la suivante. Ce n'est pas une métaphore — c'est un mécanisme opérationnel concret : chaque interaction avec l'agent génère des signaux (hésitations, erreurs, demandes de clarification) qui sont réinjectés dans le contexte via le CDLC. La roue tourne, et elle accélère.

La pratique codifiée par Shipper et Klaassen transforme ces principes en habitudes de travail quotidiennes. Le Compound Engineering n'est pas une philosophie abstraite — c'est un workflow avec des phases, des livrables, des métriques. Il est adoptable par une équipe sans réorganisation profonde, simplement en changeant la façon dont le temps est alloué et la façon dont les apprentissages sont capturés.

Ensemble, ces trois dimensions — architecturale, méthodologique, pratique — forment un cadre complet pour penser l'IA en entreprise non plus comme un outil ponctuel, mais comme un système qui s'améliore dans le temps.

Ce que cela change concrètement pour vos projets IA

Adopter une approche CDLC ne nécessite pas de repartir de zéro. Dans les missions que nous menons chez SFEIR auprès de DSI, d'équipes produit et de directions data, nous observons que la transition peut se faire de manière incrémentale, en commençant par les points de douleur les plus visibles.

Un point de départ concret : auditer votre contexte existant. Si votre équipe utilise déjà des agents IA ou des assistants copilot, posez-vous ces questions : Où est stockée la connaissance que vous transmettez à ces agents ? Est-elle versionnée ? Qui peut la modifier ? Est-elle cohérente avec vos pratiques actuelles, ou contient-elle des informations périmées depuis la dernière réorganisation ?

Un deuxième point d'entrée : traiter le prochain bug récurrent comme un bug de documentation. La prochaine fois qu'un agent fait une erreur que vous avez déjà corrigée, avant de simplement reformuler votre prompt, demandez-vous : quelle règle ou quel principe manque dans mon contexte pour que cela n'arrive plus ? Encodez la réponse. Versionnez-la. Mesurez si le comportement change.

Un troisième levier : cartographier vos tiers de mémoire. Pour un cas d'usage IA précis dans votre organisation, identifiez ce qui appartient au Tier 1 (toujours vrai, toujours chargé), ce qui appartient au Tier 2 (pertinent dans certains contextes) et ce qui appartient au Tier 3 (référence consultable). Cet exercice seul révèle souvent des incohérences et des doublons qui dégradent silencieusement la qualité des résultats.

Sur ces trois axes — audit, capitalisation des erreurs, structuration de la mémoire — les équipes que nous accompagnons constatent des améliorations mesurables de la qualité et de la cohérence des outputs IA, sans nécessairement changer de modèle ou d'outil.

Conclusion : le contexte comme actif stratégique

Le titre de cet article n'est pas une métaphore — c'est une prescription opérationnelle. Traiter le contexte comme une dépendance logicielle, c'est lui appliquer toutes les pratiques qui ont permis à l'ingénierie logicielle de passer de l'artisanat à l'industrie : versionnement, tests, déploiement contrôlé, surveillance, gouvernance.

Le CDLC n'est pas une charge supplémentaire imposée à des équipes déjà surchargées. C'est un investissement qui, via la boucle du Compound Engineering, génère des rendements croissants. Une à deux heures de maintenance hebdomadaire pour un système qui s'améliore seul — le ratio est difficile à ignorer.

Plus profondément, le Context Engineering redéfinit ce qu'est la compétence en ingénierie à l'ère des agents IA. La question n'est plus seulement "sait-il écrire du bon code ?" mais "sait-il structurer de la bonne connaissance ?". Les deux sont liées — un excellent ingénieur qui sait formaliser son expertise dans un contexte riche sera démultiplié. Un ingénieur moins expérimenté, nourri d'un contexte riche et bien maintenu, montera en compétence beaucoup plus vite.

Dans un environnement où les capacités des modèles progressent à un rythme soutenu, le contexte devient le facteur différenciant durable. Les modèles sont disponibles pour tous. Le contexte métier — votre connaissance domaine, vos pratiques, votre historique de décisions — ne l'est que pour vous. C'est votre avantage concurrentiel. Encore faut-il savoir l'organiser, le maintenir et le distribuer.

C'est précisément le chantier sur lequel les équipes de SFEIR travaillent avec leurs clients : non pas seulement mettre en production des agents IA, mais construire les fondations contextuelles qui leur permettent de s'améliorer dans le temps. Parce que le meilleur agent n'est pas celui que vous déployez aujourd'hui — c'est celui que vous aurez dans six mois, si vous avez pris soin de son contexte.