Florian Fesseler
Dans le premier article de cette série, j'expliquais pourquoi le DevOps Loop est en train d'évoluer vers quelque chose de plus radical : l'Autonomous Software Factory Loop
Des outils comme Claude Code, Codex, Gemini CLI, Factory ou pi permettent déjà de confier une tâche de développement à un agent capable de lire du code, naviguer dans un codebase, exécuter des commandes, interagir avec des APIs, etc...
Si l'on pousse cette logique plus loin, une idée apparaît : et si ces agents formaient une véritable usine de production logicielle autonome ?
C'est ce que j'appelle la Factory Loop.
La Factory Loop transforme le développement logiciel en un système continu d'exécution, de validation et d'amélioration . Dans ce modèle, le développeur ne disparaît pas. Mais il sort progressivement de la boucle d'exécution pour se placer à la frontière du système, afin d'observer son fonctionnement et l'améliorer lorsque nécessaire.
Mais une telle factory ne se construit pas uniquement autour des IDE ou des CLI . Elle repose sur plusieurs briques et principes techniques que nous allons explorer dans cet article.
La première brique d'une Factory Loop est la standardisation.
Pour qu'un système automatisé fonctionne correctement, il faut créer un environnement dans lequel les choses se font de manière prévisible et reproductible. On peut voir cela comme une autoroute avec des garde-fous clairement définis. Les agents peuvent avancer rapidement, mais ils restent dans un cadre qui limite les comportements imprévus.
Un agent est beaucoup plus efficace lorsqu'il évolue dans un système structuré. Des conventions explicites, des outils bien définis et des workflows homogènes réduisent l'ambiguïté et permettent d'exécuter les tâches de manière plus fiable.
Cette idée va d'ailleurs devenir un véritable mantra dans tous les sujets liés à la mise en place d'agents : ce qui est bon pour les développeurs l'est aussi pour les agents . Comme le décrit très bien Laura Tacho, le diagramme de Venn entre l'expérience développeur et l'expérience agent est en réalité... un cercle. Autrement dit, tout ce qui améliore la Developer Experience améliore aussi la capacité des agents à travailler efficacement : environnements reproductibles, conventions claires, outils cohérents et documentation structurée.
Cette standardisation commence par l'environnement de développement. L'objectif est simple : quel que soit l'endroit où s'exécute un agent, il doit retrouver exactement le même contexte. Même dépendances, même configuration, mêmes outils.
De nombreuses organisations ont depuis longtemps standardisé leurs environnements pour réduire le coût d'onboarding des développeurs et limiter les variations qui ralentissent la livraison logicielle. Cela passe notamment par le fait de versionner dans le repository une partie de la connaissance du projet : architecture, conventions, runbooks ou documentation technique.
Le meilleur endroit pour stocker ces informations reste le repository de code. Il ne contient alors plus uniquement du code, mais devient progressivement la source de vérité opérationnelle du système.
Mais avec l'arrivée des agents de développement, cette standardisation devient encore plus critique. Elle s'étend désormais à d'autres éléments du système : les prompts, les skills, les règles d'utilisation des outils ou les plugins deviennent eux aussi des composants standardisés.
La standardisation ne concerne pas uniquement le développement. Elle doit également couvrir la manière dont le logiciel est opéré, y compris en production. Les runbooks, les procédures d'intervention ou les processus de gestion des incidents doivent être suffisamment structurés pour pouvoir être exécutés ou assistés par des agents.
Les entreprises qui ont déjà codifié ces pratiques partent d'ailleurs avec une longueur d'avance. Une organisation qui dispose par exemple de runbooks détaillant comment diagnostiquer un incident en production et quelles actions entreprendre possède déjà une partie de ce socle.
Cependant, un défi important reste encore ouvert : définir les standards eux-mêmes.
L'écosystème est encore jeune et de nombreux outils proposent leurs propres conventions. On le voit par exemple dans les simples conventions de fichiers ou de configuration, comme les fichiers agents.md, claude.md ou d'autres variantes utilisées par différents outils. Les mécanismes de hooks, les systèmes de plugins ou les modes d'intégration avec les CLI varient également fortement d'un environnement à l'autre. Cette phase d'exploration est normale. Comme souvent dans les débuts d'un nouvel écosystème, plusieurs approches coexistent avant que des standards plus largement adoptés n'émergent.
Mais une chose est déjà claire : les agents prospèrent dans les systèmes bien structurés.
Une fois les environnements standardisés, la question suivante apparaît rapidement : où ces agents vont-ils s'exécuter ?
Si les agents restent attachés à l'environnement local du développeur, il devient difficile de parler de factory. Pour construire une véritable Factory Loop, les agents doivent pouvoir s'exécuter en arrière-plan dans le cloud.
Cette idée n'est pas entièrement nouvelle. Les environnements de développement dans le cloud existent depuis plusieurs années pour résoudre des problèmes bien connus comme la dérive des environnements ou le fameux "works on my machine".
Mais l'arrivée des agents change encore la situation. Une factory composée de dizaines d'agents exécutant des tâches en parallèle reste très limitée sur des machines locales. L'exécution dans le cloud apporte une propriété essentielle : le contexte devient partagé. Les conversations avec les modèles, l'historique des actions et les artefacts produits ne sont plus enfermés dans une session locale. Ils deviennent persistants et accessibles indépendamment de la machine depuis laquelle on interagit avec les agents.
Cela ouvre aussi de nouvelles formes d'interaction. Puisque les agents vivent dans le cloud, ils peuvent être pilotés depuis n'importe quel endroit et depuis n'importe quel device. L'expérience est d'ailleurs assez renversante la première fois qu'on la vit. Dicter une instruction à la voix depuis son mobile, voir un agent se mettre au travail automatiquement et observer le résultat apparaître quelques minutes plus tard donne parfois l'impression d'assister à quelque chose qui relevait encore de la science-fiction il y a très peu de temps.
Mais ce contexte partagé ne change pas seulement la manière dont un individu interagit avec les agents. Il ouvre aussi la voie à de nouvelles formes de collaboration autour du développement produit. Les agents ne sont plus seulement des assistants personnels pour développeurs : ils deviennent une interface commune autour du projet. Les conversations, les actions des agents et les artefacts produits peuvent être consultés, rejoués ou prolongés par le reste de l'équipe. Cela permet notamment aux métiers produit de participer beaucoup plus directement à la construction du logiciel. Plutôt que de passer par des outils externes pour imaginer et prototyper des fonctionnalités, puis de devoir réintégrer ces prototypes dans le code, ils disposent d'un environnement directement connecté au projet.
En pratique, cela revient à offrir aux équipes un équivalent de Lovable and co., mais déjà contextualisé à leur codebase, à leur architecture et aux agents de leur factory. Les idées peuvent être explorées, testées et itérées dans le même environnement que celui qui produira réellement le produit.
Les agents deviennent alors une interface partagée entre les rôles de l'équipe, permettant à chacun de contribuer avec un niveau d'autonomie inédit, tout en restant dans un contexte technique cohérent.
Mais cette autonomie introduit également de nouveaux défis, notamment en matière de sécurité. Les agents modernes peuvent lire des fichiers, exécuter des commandes et générer du code pour résoudre une tâche. Cette capacité est extrêmement puissante, mais elle signifie aussi que le code exécuté par l'agent doit être considéré comme non fiable par défaut.
Un agent peut être influencé par des entrées externes - logs, tickets, documentation ou données provenant d'APIs - qui contiennent des instructions malveillantes. Les attaques de type prompt injection ou autre peuvent pousser l'agent à exécuter des actions inattendues ou à tenter d'exfiltrer des informations sensibles.
Pour limiter ces risques, il est utile de distinguer plusieurs éléments dans un système agentique :
Ces composants n'ont pas le même niveau de confiance et ne devraient donc pas partager le même périmètre de sécurité.
Une architecture plus robuste consiste à séparer l'agent et l'exécution du code généré dans des environnements distincts. L'agent fonctionne dans un contexte contrôlé où les secrets sont gérés par le système, tandis que le code généré est exécuté dans une sandbox isolée - souvent un conteneur ou une machine virtuelle éphémère - qui n'a pas accès à ces informations sensibles.
Dans de nombreuses architectures, cette isolation inclut également des restrictions réseau. Le trafic sortant peut être limité ou filtré afin d'éviter l'exfiltration de données ou l'appel de services non autorisés.
Toutes les sandbox ne fournissent pas le même niveau d'isolation. Certaines reposent sur des conteneurs légers, tandis que d'autres utilisent des mécanismes plus stricts comme des runtimes sécurisés ou des microVMs dédiées. Ces approches offrent une isolation plus forte au prix d'un démarrage parfois plus lent.
Certaines plateformes introduisent également des mécanismes de snapshot permettant de capturer l'état d'un environnement et de le restaurer rapidement. Ces techniques facilitent la reprise de tâches longues.
La sandbox joue donc un rôle central dans l'architecture de la factory : elle protège l'infrastructure et les secrets du système, tout en permettant aux agents d'exécuter du code et d'interagir avec leur environnement de manière contrôlée.
Dans de nombreux outils actuels, les agents sont encore déclenchés par une interaction directe avec un développeur.
Mais dans une Factory Loop, ce mode d'interaction devient rapidement limité.
Si les agents ne démarrent que lorsqu'un développeur leur donne une instruction, la factory n'est pas encore réellement autonome . Pour atteindre un niveau d'autonomie plus élevé, les agents doivent pouvoir être déclenchés par des stimuli externes.
Ces déclencheurs peuvent prendre différentes formes :
Un agent peut par exemple réagir à la création d'un ticket, à l'apparition d'une vulnérabilité dans une dépendance ou à un incident en production.
Ces déclencheurs ne servent pas uniquement à traiter des événements externes.
Ils peuvent aussi permettre d'exécuter des boucles de maintenance automatiques sur le codebase lui-même. Une factory logicielle autonome produit en continu de nouvelles modifications. Sans mécanisme de régulation, cela peut progressivement introduire de l'entropie : duplication de code, divergence de patterns ou documentation obsolète.
Des agents peuvent donc être déclenchés périodiquement pour détecter ces dérives, proposer des refactorings ou mettre à jour la documentation. Ces boucles agissent comme une forme de garbage collection du codebase, permettant à la factory de maintenir la qualité du système au fil du temps.
À mesure que le nombre d'agents augmente, une nouvelle question apparaît rapidement : **comment coordonner toutes ces activités ?**Une factory logicielle a besoin d'un mécanisme de coordination capable de suivre les tâches en cours, leurs dépendances et leur état d'exécution.
Ce système agit comme un scheduler pour les activités de la factory. Certaines tâches peuvent être parallélisées, tandis que d'autres doivent être exécutées dans un ordre précis pour éviter les conflits.
Aujourd'hui la tendance est souvent à la parallélisation massive, mais si les temps d'inférence continuent de diminuer, des workflows plus séquentiels pourraient redevenir attractifs car ils simplifient fortement la coordination.
À mesure que la factory exécute un nombre croissant de tâches en parallèle, une nouvelle nécessité apparaît : piloter le système dans son ensemble. Lorsque des dizaines d'agents travaillent simultanément sur différentes tâches, il devient difficile de comprendre ce qui se passe uniquement à travers les logs ou les pull requests.
Une factory logicielle autonome a donc besoin d'un control plane , une interface permettant de superviser et de diriger l'activité des agents. Ce control plane agit comme une sorte de mission control pour la software factory. Il permet notamment de suivre les tâches en cours, d'observer les actions réalisées par les agents, d'inspecter les modifications proposées, de prioriser le backlog et d'intervenir lorsque nécessaire.
Cette couche devient d'autant plus importante que la vitesse de production augmente. Dans un système où les agents peuvent générer de nombreuses modifications en parallèle, le rôle du développeur évolue progressivement : il ne participe plus directement à chaque étape de production, mais agit davantage comme un opérateur supervisant la factory.
À mesure que les systèmes deviennent plus autonomes, ce type d'interface pourrait devenir le véritable centre de contrôle du développement logiciel.
Pour être réellement utiles, les agents ne peuvent pas se limiter à générer du code. Ils doivent aussi pouvoir agir sur le système. Dans la pratique, cela signifie accéder à différents outils : CLI, APIs internes, services cloud ou scripts d'automatisation.
Plus ces outils sont exposés via des interfaces claires et automatisables, plus les agents peuvent fonctionner de manière autonome.
Dans certaines architectures, ces outils sont exposés via des protocoles comme MCP (Model Context Protocol) ou des registres d'outils, afin que les agents puissent les découvrir et les utiliser facilement.
La capacité à connecter les agents aux outils de l'infrastructure devient ainsi une brique essentielle de la factory logicielle.
Une fois les agents capables d'exécuter des tâches de manière autonome, une question fondamentale apparaît : comment savent-ils que leur travail est terminé ? Un agent doit s'appuyer sur des conditions de sortie vérifiables.
Le fait qu'un code compile ou qu'un linter ne remonte aucune erreur ne garantit en réalité que très peu de choses sur le bon fonctionnement du logiciel. Les tests et évaluations deviennent alors un mécanisme central. Historiquement, certaines catégories de tests ont été délaissées, notamment les tests end-to-end ou les tests visuels. Mais dans un système où les agents produisent du code de manière autonome, ces tests retrouvent une nouvelle importance.
Dans certains cas, cela va jusqu'à reproduire au plus près l'environnement dans lequel l'application s'exécute réellement, via des digital twins.
Dans une Factory Loop, les tests deviennent le système de contrôle de la factory.
Enfin, pour améliorer une factory logicielle autonome, il faut d'abord être capable d'observer ce qu'elle fait réellement.
Dans une architecture classique, l'observabilité concerne surtout le logiciel lui-même : logs, métriques et traces permettent de comprendre le comportement d'une application en production. Cette dimension reste évidemment essentielle dans une Factory Loop.
Mais l'émergence d'agents autonomes introduit une seconde dimension : l'observabilité du comportement des agents eux-mêmes. Il ne suffit plus de savoir qu'un système a échoué ou qu'une modification a été produite. Il faut aussi comprendre comment l'agent a procédé : quelles étapes ont été suivies, quels outils ont été appelés, quelles erreurs ont été rencontrées et comment elles ont été corrigées.
Cela suppose de tracer les prompts, les appels aux outils, les résultats intermédiaires, les validations et plus largement l'ensemble du workflow exécuté par l'agent.
Cette observabilité est utile aux humains qui opèrent la factory, mais aussi aux agents eux-mêmes. Lorsqu'elles sont accessibles et structurées, ces traces permettent d'identifier des erreurs récurrentes, d'améliorer les workflows et de renforcer la standardisation du système. Dans une Factory Loop, l'observabilité ne sert donc pas uniquement au monitoring ou au debugging. Elle devient un mécanisme central d'apprentissage et d'amélioration continue.
Un défi important reste cependant ouvert : l'outillage est encore immature.
Les solutions actuelles ont souvent été conçues soit pour observer les applications, soit pour suivre les interactions avec des modèles. Or les architectures agentiques demandent de suivre des workflows complets exécutés par des agents , avec leurs décisions, leurs outils et leurs interactions avec le reste du système. On voit par exemple émerger des produits comme cxdb ou Entire, orientés vers une meilleure visibilité sur l'activité des agents, leurs sessions et leurs workflows.
On peut néanmoins s'attendre à voir émerger progressivement des plateformes capables d'observer à la fois les modèles, les agents et les applications.
Les plateformes spécialisées dans l'observabilité des applications disposent déjà d'infrastructures solides pour collecter et corréler des traces complexes. De leur côté, les outils d'observabilité dédiés aux modèles de langage commencent à développer des mécanismes pour suivre les décisions prises par les agents.
Il est donc probable que ces deux mondes convergent progressivement vers de nouvelles plateformes capables d'observer à la fois le comportement du software et celui des agents qui le produisent.
Les briques que nous avons décrites dans cet article ne sont pas entièrement nouvelles. La standardisation des environnements, les environnements de développement reproductibles, l'observabilité des applications ou encore l'automatisation des workflows existent depuis longtemps dans l'ingénierie logicielle.
Ce qui change aujourd'hui, c'est la manière dont ces éléments se combinent. Avec l'arrivée des agents capables d'écrire, tester et modifier du code, ces briques commencent à former une véritable factory logicielle. Un système dans lequel des tâches peuvent être déclenchées par des événements, exécutées par des agents et validées automatiquement avant de produire un résultat.
Dans ce modèle, le développement logiciel se rapproche progressivement d'un système cybernétique. Le système agit, observe les résultats de ses actions et ajuste son comportement au fil du temps.
La Factory Loop n'est donc pas simplement une nouvelle génération d'outils de développement. Elle représente une évolution plus profonde de l'architecture du processus logiciel.
Mais si la manière de produire du logiciel évolue, cela implique aussi une transformation des pratiques et des rôles au sein des équipes.
Si les agents exécutent une part croissante du travail opérationnel, quel devient le rôle des développeurs ? Comment les équipes conçoivent-elles ces factories logicielles ? Quelles nouvelles compétences deviennent nécessaires pour opérer et améliorer ces systèmes ?
C'est ce que nous explorerons dans le prochain article de cette série.