Context Flywheel

Qu'est-ce que le Context Flywheel ?

Le Context Flywheel (volant d'inertie du contexte) désigne la boucle par laquelle le contexte fourni aux agents de codage s'améliore à chaque tâche. Patrick Debois, créateur du terme DevOps, la résume en trois phrases dans son billet du 26 février 2026 sur le blog de Tessl : Better context produces better agent output. Better agent output generates better signals. Better signals produce better context. Chaque session laisse derrière elle des conventions, des specs et des leçons ; la session suivante démarre avec ce capital, et le volant prend de la vitesse.

Le point de départ est un constat du même auteur : un agent de codage repart de zéro à chaque session, comme un nouvel employé sans mémoire des décisions passées. Ce que l'équipe ne consigne pas dans le contexte structuré est perdu à la fermeture de la fenêtre. Le flywheel est la réponse organisationnelle à cette amnésie : consigner, évaluer, redistribuer, observer, puis recommencer.

D'où vient le terme

Debois publie deux billets à une semaine d'intervalle sur tessl.io. Le premier, le 19 février 2026, décrit le Context Development Lifecycle et ses quatre étapes (Generate, Evaluate, Distribute, Observe). Le second, le 26 février 2026, s'intitule The Context Flywheel: Why the Best AI Coding Teams Will Win on Context et décrit ce que produit ce cycle quand on le répète. Le CDLC décrit une itération ; le flywheel décrit ce que dix itérations produisent.

La synthèse Context Engineering : l'art de nourrir les agents IA, publiée par Didier Girard en mars 2026 à partir de 34 fiches de veille couvrant mai 2025 à février 2026, range le flywheel parmi trois visions convergentes : l'architecture du contexte à trois étages d'Aristidis Vasilopoulos, la méthodologie de Debois, et la pratique du compound engineering de Shipper et Klaassen chez Every.

Comment ça marche

Une itération du volant suit les quatre temps du CDLC :

• Generate : l'équipe rend explicite ce qui était implicite (conventions, contraintes, décisions d'architecture) et l'écrit dans le contexte, à l'étage de mémoire adapté (chaude, tiède ou froide).
• Evaluate : l'équipe teste le contexte comme du code. Un échec d'évaluation signale une spécification non écrite.
• Distribute : le contexte est versionné et distribué comme une dépendance logicielle, pour que chaque développeur et chaque agent partent du même état.
• Observe : les hésitations, erreurs et demandes de clarification de l'agent en production désignent les trous du contexte, que l'itération suivante comble.

Ce que dix itérations produisent

Debois situe le basculement autour de la dixième itération : la première capture les conventions ; à la dixième, toute l'équipe code différemment, plus vite et avec moins de corrections. Le retour se lit sur quatre fronts : la qualité des sorties de l'agent, l'expertise du senior qui codifie son savoir, la montée en compétence des juniors qui le lisent, et l'alignement de l'organisation sur un vocabulaire commun. Son argument concurrentiel tient en une phrase : le contexte, contrairement aux modèles, ne se commoditise pas.

Chez Every, Klaassen pose l'axiome du compound engineering dans son guide du 9 février 2026 : chaque unité de travail d'ingénierie devrait rendre les suivantes plus faciles. La synthèse de mars 2026 chiffre l'entretien du volant à une ou deux heures par semaine pour un système qui s'améliore seul, et la vélocité d'un développeur bien outillé à cinq fois celle d'un développeur traditionnel, chiffres de Shipper et Klaassen à lire comme un ordre de grandeur d'auteurs, pas comme une mesure indépendante.

Erreurs courantes

• Laisser le contexte sans propriétaire. Debois est catégorique : sans équipe ou rôle désigné pour la maintenance, l'enablement et la gouvernance, le contexte pourrit comme la documentation avant lui, et le volant s'arrête.
• Garder une spec périmée. Elle induit l'agent en erreur avec assurance ; une spec fausse fait plus de dégâts qu'une spec absente.
• Expliquer deux fois la même chose à l'agent sans l'écrire. La synthèse de mars 2026 le formule ainsi : c'est un bug de documentation.
• Oublier que le contexte distribué est une surface d'attaque. Debois demande pour lui l'audit et le contrôle d'accès qu'on applique aux dépendances de code.

Ce que SFEIR en fait

Dans le SDLC augmenté de SFEIR, le volant a deux points d'ancrage : les phases Compound-1 (leçons statiques avant livraison) et Compound-2 (leçons runtime après mise en production), dont les règles sont rechargées au Plan du cycle suivant. Chaque phase a un responsable (le tech lead avant livraison, les Ops et le lead en production) et un livrable. La mesure de première main publiée en juin 2026 avec le cycle à 11 phases : environ 30 % d'itérations de correction en moins après dix cycles, à modèle constant, la baisse venant des règles consignées à chaque cycle et rechargées au suivant.

La présentation AI for IT : la stratégie du 10x (Didier Girard, février 2026) en fait la cinquième étape de son workflow, après Plan, Work, Review et Compound : Repeat, chaque cycle informant le suivant. Elle pose une règle d'or, versionner le contexte dans Git comme un actif vivant, et une cible, 80 % du temps sur le plan et la revue, 20 % sur l'exécution du code.