Patrick Debois, fondateur de Tessl et figure historique du mouvement DevOps, développe dans cet article le concept de « Context Flywheel » — un volant d'inertie contextuel qui crée un avantage compétitif cumulé pour les équipes de développement utilisant des agents IA.
L'article s'appuie sur le Context Development Lifecycle (CDLC) introduit dans un billet précédent, un cycle en quatre phases : Générer, Évaluer, Distribuer, Observer. Le CDLC traite le contexte non comme de la documentation statique, mais comme un artefact d'ingénierie versionné et testé.
Context Flywheel
La thèse centrale est que la valeur ne réside pas dans un seul passage du cycle, mais dans sa répétition. La première itération capture des conventions et identifie des lacunes. La deuxième corrige ces lacunes et révèle des problèmes plus subtils. À la dixième itération, un basculement s'opère : les agents ne suivent pas simplement mieux les instructions — c'est l'ensemble de l'équipe qui code différemment, plus vite, plus cohérent, avec moins de corrections.
Debois identifie quatre retours sur investissement simultanés pour chaque cycle. Premièrement, la qualité des agents s'améliore dans tous les domaines. Deuxièmement, l'ingénieur senior qui encode son expertise la clarifie et l'approfondit. Troisièmement, les développeurs juniors peuvent lire les skills et absorber les patterns, contraintes et raisonnements. Quatrièmement, l'organisation converge vers une terminologie partagée qui traverse les frontières d'équipes.
L'argument stratégique fort est que le véritable fossé concurrentiel n'est ni dans les outils ni dans les modèles — qui se commoditisent et convergent respectivement — mais dans la connaissance produit accumulée. Une organisation qui fait tourner ce volant pendant deux ans développe une compréhension que les concurrents ne peuvent pas répliquer : cas limites catalogués, besoins utilisateurs cartographiés, raisonnement domaine encodé et accessible aux agents.
Debois conclut en insistant sur la nécessité d'un ownership explicite du contexte. Sans propriétaire désigné — qu'il s'agisse d'une équipe DevEx, platform team ou d'ingénieurs contexte intégrés — le contexte pourrit inévitablement. L'ownership repose sur trois piliers : la maintenance (revue de fraîcheur, résolution de conflits, retrait de l'obsolète), l'enablement (contribution facilitée via CLI et évaluations en CI), et la gouvernance (seuil de qualité via évaluations, détection de conflits, politiques de dépréciation). L'analogie historique est explicite : l'industrie a déjà appris cette leçon avec la documentation, l'infrastructure et la sécurité.