D'abord en observant comment la boucle DevOps commence à évoluer vers une boucle plus autonome, dans laquelle la production et l'amélioration du logiciel ne sont plus deux sujets séparés. Puis en regardant les briques qui rendent cette factory possible : standardisation, agents en arrière-plan, sandbox, orchestration, connectivité aux outils, etc.

Mais il y a une autre conséquence, probablement plus directe pour nous : si le système change, le rôle de ceux qui travaillent dans ce système change aussi.

C'est le sujet de cet article.

Je ne vais pas essayer ici de faire une liste des compétences à apprendre, ni de prédire précisément quels profils seront les plus recherchés dans quelques années. Ce serait probablement trop ambitieux, et assez vite faux. L'idée est plutôt de regarder ce qui est déjà en train de bouger dans le rôle de software engineer, avec une vue assez court / moyen terme, disons les 12 à 18 prochains mois, au doigt mouillé.

On ne parlera pas non plus vraiment du marché de l'emploi actuel, de la question de ceux qui entrent sur ce marché, etc... qui mérite un article en soi. Ici, je veux surtout regarder le déplacement du centre de gravité.

Parce que la Software Factory n'est pas seulement un accélérateur de delivery. C'est aussi une forme de mécanisation plus poussée du métier. On le voit déjà très clairement avec la génération de code. Une partie du travail qui reposait avant sur l'exécution directe par le développeur est maintenant transférée vers des outils capables de produire, modifier, tester ou documenter du logiciel à partir d'une intention.

Plus la factory devient capable d'exécuter une partie du travail opérationnel, plus la valeur humaine se déplace ailleurs : dans la formulation des problèmes, la définition des contraintes, la conception des boucles, la supervision du système, et probablement aussi dans la capacité à faire travailler d'autres métiers avec cette nouvelle capacité de production logicielle.

C'est assez confortable à certains endroits, et beaucoup moins à d'autres. C'est ce qu'on va essayer de dérouler.

Ce qui a déjà changé (et pourquoi)

Si on simplifie un peu, le travail de développement local peut se découper en deux grandes phases. D'un côté, la recherche: comprendre un problème, explorer des solutions, debugger, construire un plan, etc... De l'autre, la production: écrire du code, ajouter des tests, documenter, faire les ajustements, etc...

Ce découpage n'a jamais été parfaitement net, mais il est utile pour comprendre ce qui est en train de bouger, parce que l'IA vient accélérer les deux.

Sur la partie production, le changement est assez visible. On écrit presque plus de code soi-même. On passe plus de temps à décrire ce qu'on veut faire, à corriger, à itérer sur quelque chose qui a déjà été généré. Même chose pour les tests, la documentation, ou certains refactorings. Tout ce qui est assez "mécanique" devient beaucoup plus rapide.

Mais la partie recherche est elle aussi accélérée. On debug plus vite. On trouve plus rapidement des pistes. On arrive plus vite à une première version d'un plan, même imparfaite. Là où on passait parfois du temps à explorer sans trop de direction, on a maintenant un point de départ presque immédiat. Ça ne veut pas dire que la réflexion disparaît (c'est tentant pourtant). Mais le temps pour arriver à quelque chose d'exploitable est largement réduit.

Et tout ça repose sur deux mécanismes assez simples.

Le premier, c'est la génération de texte, que ce soit le code ou autre chose. On délègue une partie de la production à des systèmes capables de transformer une intention en quelque chose de concret.

Le second, c'est l'accès à la connaissance.

Avant, quand tu tombais sur un sujet, un concept que tu ne maîtrisais pas, il fallait passer par plusieurs étapes: chercher des ressources, tomber sur des articles de qualité variable, essayer de comprendre ce qui est vraiment important, recouper les informations, puis reconstruire une vision cohérente adaptée à ton contexte. C'était un travail à part entière, et parfois assez long.

Aujourd'hui, tu peux directement poser ton contexte, décrire ton problème, et obtenir une synthèse déjà structurée, avec des exemples, des compromis, et souvent une première implémentation. Tu peux aussi adapter la réponse à ce dont tu as besoin : un résumé rapide, une explication plus détaillée, un schéma, quelque chose de très concret ou au contraire plus conceptuel. Ce n'est pas parfait, mais c'est déjà super-quali, c'est immédiatement exploitable et ça permet d'avancer beaucoup plus vite.

Mis ensemble, ces deux éléments accélèrent à la fois la production et la phase de recherche. Le temps pour passer d'un problème à une première solution exploitable se réduit fortement, même quand le sujet est nouveau.

Un terrain de jeu plutôt agréable

Dit comme ça, ça peut donner l'impression d'un changement assez abstrait. Mais dans la pratique, ce nouveau terrain de jeu est plutôt agréable. En tout cas, il doit sûrement l'être pour tous ceux qui cherchent à résoudre des problèmes avant tout et qui ont enfin fait le deuil d'une bonne partie de leurs compétences.

On passe moins de temps sur des tâches rébarbatives. Tests, documentation, certains refactorings, ou même des choses toutes simples comme corriger des erreurs de syntaxe... tout ça devient plus fluide. Ce ne sont pas des activités qui disparaissent, mais elles demandent moins d'effort, donc on les intègre plus facilement.

Le cycle de feedback s'accélère aussi. On peut passer plus vite d'une idée à quelque chose de concret, tester, ajuster, recommencer. Le coût d'expérimentation baisse, donc on explore plus.

Et, de manière assez simple, il y a ce sentiment d'aller plus vite. Moins de friction, moins d'attente, et aussi moins de situations où quelqu'un vient te relancer régulièrement pour savoir si c'est bientôt fini. Les choses avancent plus vite, donc cette pression-là se fait moins sentir.

Premières fractures dans le métier

Jusqu'ici, on est surtout sur quelque chose d'assez positif. Mais cette évolution commence déjà à créer des déséquilibres assez visibles. Certains profils sont plus directement impactés que d'autres.

Le premier, c'est le développeur dont le plaisir est l'écriture du code avant tout. Un profil souvent très attaché à la résolution de problèmes proches de la technique, à la qualité du code en lui-même, à sa structure, à son élégance. Et parfois moins intéressé par la valeur produite derrière ou par l'impact côté produit.

Ce profil disparaît clairement et doit probablement se remettre en question fortement. Aujourd'hui, écrire du code n'est plus vraiment le point de friction principal. Dans beaucoup de cas, ce n'est même plus là que se joue la valeur. Le ratio vitesse / qualité face aux outils de génération, et à ceux qui les exploitent, est difficile à soutenir, même pour de très bons développeurs. Ce n'est pas tellement une question de niveau individuel, c'est surtout que la nature du travail change.

Il reste évidemment des cas où écrire à la main garde du sens : garder un minimum de maîtrise pour ne pas être complètement dépendant, concevoir certaines interfaces où le fait de passer par une écriture manuelle aide à mieux percevoir leur usabilité, les points de friction potentiels, et les implications des choix faits, ou simplement aller plus vite que le LLM sur des ajustements simples. Mais ça devient une partie plus réduite du travail.

Pour ces profils, il existera toujours un espace où l'écriture de code principalement manuelle garde une place importante, mais il sera fera probablement dans des contextes non lucratifs : des projets personnels, de l'open source, ou des contextes où la contrainte de vitesse et d'efficacité est moins forte.

Un effet collatéral assez intéressant, c'est la perte d'attachement au code. Quand tu n'es plus celui qui écrit chaque ligne, tu t'y attaches moins. C'est plus facile de jeter, de refaire, de repartir de zéro. On avait déjà vu ça avec le formatting automatique : moins de débats, moins d'ego sur la forme. Là, le phénomène est le même, mais à une échelle plus large. Le code devient plus interchangeable, et ça change la relation qu'on a avec ce qu'on produit.

Dans la même veine, il y a un autre type de profil qui commence à être mis sous tension : ceux qui se définissent principalement par leur stack ou par une couche technique. Le classique "Senior .NET developer", "React expert", "Backend engineer", etc.

Pendant longtemps, c'était une manière assez logique de se positionner. La complexité des outils, la profondeur des écosystèmes, mais aussi l'accumulation de connaissances nécessaires faisaient que se spécialiser pouvait avait du sens. Se former sur une stack représentait un investissement important, que ce soit pour l'entreprise, en temps de formation et d'onboarding, ou pour le développeur lui-même. Mais avec l'accès à la connaissance qui devient quasi instantané et beaucoup plus contextualisé, cette barrière-là se réduit vite. Être productif sur une nouvelle stack prend beaucoup moins de temps qu'avant. Là où il fallait plusieurs mois pour être réellement à l'aise, cette phase se raccourcit fortement. Du coup, se définir uniquement par ça devient rapidement limité.

Dans certaines expériences passées, je privilégiais déjà des profils plus généralistes, sans prérequis sur la stack technique utilisée. Le coût d'onboarding pouvait être un peu plus élevé au départ, mais il était amorti assez rapidement. Aujourd'hui, avec les outils actuels, cet amortissement est encore plus rapide.

Dans ce contexte, afficher une spécialisation forte dans son positionnement devient un signal assez faible désormais. Dans certains cas, ça montre surtout que le développeur n'a pas vraiment pris la mesure des transformations en cours.

On pousse donc assez naturellement vers des profils plus généralistes. Des profils capables de naviguer entre plusieurs stacks ou couches sans trop de friction, mais surtout capables de deep dive rapidement sur des sujets qu'ils ne maîtrisent pas, en sachant poser les bonnes questions et aller chercher les bonnes personnes pour compléter leur compréhension.

La spécialisation ne disparaît pas complètement pour autant. Elle reste pertinente dans certains cas, mais plutôt sous forme d'expertises plus profondes, souvent sur des sujets moins facilement capturables par des LLM, mais ça devient plus l'exception que la norme.

Rien ne reste stable

Jusqu'ici, on a surtout regardé des profils qui se retrouvent directement sous pression. Mais ça ne veut pas dire que pour les autres, le métier va rester tel quel.

Même pour ceux qui s'adaptent bien à ces changements, le rôle continue d'évoluer, et probablement assez vite. Il y a au moins deux dynamiques de fond qui sont en train de redessiner le périmètre du métier, et qui vont avoir un impact bien au-delà de quelques profils spécifiques.

1 - La software factory

La première, c'est l'industrialisation du processus de développement. Ce que j'appelle l'autonomous factory loop devient progressivement un enjeu central pour les boîtes produit. L'idée n'est plus seulement d'accélérer la production, mais de structurer une boucle complète, capable de produire, tester, mesurer et s'améliorer avec un minimum d'intervention humaine.

Cette logique n'est pas complètement nouvelle. On retrouvait déjà des préoccupations similaires dans certaines organisations avec plusieurs équipes, autour de la standardisation, de la DevEx, ou de l'outillage interne. Mais ces rôles arrivaient souvent assez tard. Dans mon expérience, il était rare de voir apparaître ce type de sujet avant d'avoir au moins 3 ou 4 équipes de développement en interne.

Ce qui change aujourd'hui, c'est que cette logique arrive beaucoup plus tôt. On ne produit plus seulement pour des humains, mais aussi pour des systèmes capables de générer, modifier et exécuter du code, ce qui demande un niveau de structuration plus élevé dès le départ.

La question, derrière, c'est de savoir si ça devient une spécialité à part entière ou simplement un prérequis pour les développeurs. Probablement un peu des deux, mais dans tous les cas, ça déplace une partie de la valeur vers la capacité à standardiser, à structurer des workflows, et à rendre le système exploitable par des agents.

On commence aussi à voir apparaître des problématiques proches de celles du machine learning : définir des objectifs, des métriques, encadrer les comportements, évaluer les résultats, améliorer progressivement le système. L'idée n'est plus seulement d'écrire du code, mais de concevoir des boucles qui peuvent tourner de manière relativement autonome.

Concrètement, ça peut prendre des formes assez simples au départ. Par exemple, l'analyse des incidents de production peut devenir une boucle en elle-même : un incident est détecté, analysé, une hypothèse de correction est proposée, testée, puis intégrée, avec un suivi pour vérifier qu'il n'y a pas de régression. Avec le temps, cette boucle peut s'améliorer, devenir plus fiable, plus rapide, et couvrir de plus en plus de cas sans intervention directe.

On retrouve la même logique sur les skills des agents. Quand un agent est capable de réaliser certaines tâches comme modifier du code, ajouter des tests, refactorer, il faut être capable d'évaluer ce qu'il produit dans la durée. Une modification peut fonctionner localement, mais introduire des régressions ailleurs, ou dégrader progressivement certaines propriétés du système. L'enjeu devient alors de construire des boucles qui permettent d'observer ces effets, de les mesurer, et d'améliorer ces skills au fil du temps.

Dans ce contexte, le rôle du développeur se rapproche de plus en plus de celui de quelqu'un qui définit les règles du jeu : quels sont les objectifs, quelles sont les limites, quelles sont les métriques qui comptent, quels types d'actions sont autorisés, dans quels environnements, avec quels niveaux de risque. Ça implique aussi des sujets plus concrets : sandboxing, gestion des credentials, sécurité, isolation des environnements, contrôle des actions des agents... toute une couche de "risk engineering" qui devient beaucoup plus centrale.

Avoir une double compétence software engineering / machine learning devient clairement un avantage dans ce contexte.

2 - La démocratisation de la production logicielle

La deuxième dynamique, c'est la démocratisation de la production logicielle.

Une partie de l'implémentation devient accessible à des profils qui n'étaient pas, jusqu'ici, dans le périmètre direct de l'engineering. Et ça ne concerne pas uniquement les équipes Tech Product. On commence déjà à voir ce mouvement dans des équipes marketing, sales, ou même à des niveaux plus stratégiques.

Côté Tech Product, la barrière d'entrée baisse assez nettement. La combinaison d'outils qui simplifient l'infrastructure de base pour construire un produit, l'accès à des agents capables de produire du code, et l'accès à la connaissance font que produire quelque chose de fonctionnel devient beaucoup plus accessible.

La software factory va un cran plus loin. Elle ne se contente pas de faciliter la création de code, elle permet de le faire directement dans l'infrastructure existante de l'application. On ne parle plus seulement de prototypes isolés, mais de contributions qui peuvent s'insérer dans le produit réel, avec moins de friction et moins de handoffs.

Des profils produit peuvent montrer des prototypes interactifs directement en code, proposer des premières versions de fonctionnalités, tester des améliorations d'UI/UX, ou corriger des bugs simples sans forcément passer par une équipe engineering. Le bottleneck classique côté développement commence à disparaître sur toute une catégorie de sujets.

Pour les développeurs, ça change assez brutalement la position dans la chaîne. On est en bout de chaîne et soyez-en sûr, si une partie du travail peut être absorbée en amont, elle le sera. Il n'y a pas vraiment de raison organisationnelle pour conserver une étape intermédiaire si elle n'apporte pas de valeur claire. Ça réduit les coûts, ça accélère les cycles, et ça simplifie la structure.

Le risque, c'est donc de se retrouver progressivement dépossédé d'une partie du périmètre sans vraiment s'en rendre compte. Ça commence par des choses simples : des prototypes faits côté produit, des petites features implémentées sans passer par engineering, des corrections mineures faites directement là où le besoin apparaît. Et puis petit à petit, une partie du travail disparaît du scope des développeurs.

En parallèle, la relation au produit évolue. Ceux qui étaient déjà éloignés du business deviennent encore plus périphériques. Et même pour les autres, il y a un risque de voir certaines discussions se déplacer ailleurs. Moins de specs, plus de prototypes. Moins de cadrage en amont, plus de choses déjà "concrètes" quand ça arrive côté engineering.

Une partie du rôle des développeurs se transforme alors en un travail d'industrialisation de ces prototypes ou de fonctionnalités. Il faut les rendre compatibles avec la stack, les intégrer dans une architecture existante, gérer les contraintes de performance, de sécurité, de scalabilité.

Dans certains cas, on se retrouve à faire du reverse-engineering d'un proto pour produire quelque chose de similaire fonctionnellement, mais propre du point de vue technique. Les choix ont déjà été faits, les cas d'usage ont déjà été explorés, l'interactivité est déjà là. La partie visible et valorisée du travail a été captée en amont.

Si on reste dans cette position, le rôle se réduit progressivement à une forme d'exécution contrainte, avec moins de prise sur les décisions et moins de visibilité sur l'impact produit. La question devient donc assez simple : soit on accepte ce déplacement et on subit cette évolution, soit on s'en sert pour redéfinir sa place dans le cycle.

Parce que cette transformation ne fait pas que réduire le périmètre. Elle crée aussi de nouveaux espaces, mais ils ne sont pas forcément là où on regardait avant.

La première passe par l'acceptation que la production de logiciel ne soit plus une chasse gardée des développeurs. À partir de là, il y a un rôle à jouer pour structurer cet espace. D'un point de vue technique, ça passe par la mise en place de guardrails : définir des cadres, des conventions, des outils qui permettent à d'autres profils de produire sans créer de dette ou de rework en permanence. Sans ce cadre, une partie du travail consiste à corriger en continu des choses mal intégrées. Et assez vite, le rôle peut se réduire à retaper des implémentations bancales en boucle, sans jamais vraiment avancer. Ce n'est pas seulement un problème d'efficacité, c'est aussi une manière assez directe de se retrouver enfermé dans une partie du métier dont la valeur ne sera jamais vraiment visible.

Il y a aussi un rôle plus humain. Transmettre des réflexes, expliquer des contraintes ou des concepts, aider à comprendre comment fonctionne un système logiciel. C'est une forme de mentorat transverse qui va prendre de plus en plus de place.

L'accélération du cycle de production a un autre effet. Si la capacité de delivery augmente, il faut être capable d'alimenter ce rythme. Dans certaines situations, les équipes produit deviennent à leur tour le bottleneck.

Ça ouvre un espace pour les développeurs qui souhaitent remonter dans la chaîne et prendre une part plus active dans la définition du produit. On parle de plus en plus de convergence entre les rôles de product manager, product designer et engineer, vers des profils plus hybrides, parfois appelés "product builders". Ceux qui ne vont pas dans cette direction laisseront mécaniquement de la place à d'autres.

Dans le même temps, le coût de production logicielle baisse, ce qui remet au goût du jour certaines logiques d'internalisation. On le voit avec la remise en question de la logique SaaS et la volonté de reconstruire des outils en interne. Là où certaines entreprises faisaient le choix d'acheter, il devient à nouveau envisageable de construire. Créer devient plus accessible, mais maintenir reste un sujet. Pour certaines entreprises, il pourra devenir pertinent d'avoir un ingénieur dédié à la création et à la maintenance de cet ensemble d'outils internes, presque comme un "OS" de l'entreprise.

Dans la même logique, des rôles de support transverse peuvent émerger pour accompagner les autres équipes dans leur utilisation de ces capacités : aider à faire les bons choix techniques, éviter les dérives, structurer ce qui est produit.

Dans ce contexte, les développeurs qui avaient déjà une appétence pour les sujets produit ou business sont naturellement mieux positionnés. Ce sont souvent ceux qui peuvent s'insérer le plus facilement dans ces nouvelles zones, simplement parce qu'ils ont déjà l'habitude de raisonner en termes d'usage, de valeur et de priorisation, et pas uniquement en termes de solution technique.

Il reste malgré tout une limite assez structurelle. Sans expérience en engineering, il est difficile de construire des systèmes complexes, de gérer leur scalabilité, leur robustesse, ou certaines contraintes d'architecture. Sur ces sujets, les développeurs avec de l'expérience gardent un rôle central.

Mais cette position devient elle aussi moins confortable qu'avant. Ce qui était auparavant différenciant, savoir concevoir des systèmes, gérer la complexité, tend progressivement à devenir un prérequis. Le design de systèmes, la compréhension des architectures, la gestion des compromis techniques deviennent maintenant "table stakes". Autrement dit, ces compétences restent indispensables, mais elles ne suffisent plus à elles seules à sécuriser une position ou à se différencier durablement.

Conclusion

Au final, le point commun de tout ça, c'est un déplacement assez net de la valeur. Moins dans la production elle-même, qui devient de plus en plus accessible et mécanisée. Plus dans la manière dont on structure, oriente et exploite cette capacité de production.

Et selon la manière dont on se positionne, ça ouvre des trajectoires assez différentes :

• Une première consiste à aller vers la structuration du système lui-même. Travailler sur les boucles, les outils, les guardrails, tout ce qui permet à la production de s'exécuter de manière fiable et répétable. C'est une continuité assez naturelle pour ceux qui s'intéressaient déjà à la DevEx, à l'infrastructure ou à l'automatisation, avec une dimension plus marquée autour des agents et de l'amélioration continue.
• Une autre consiste à remonter vers le produit. Prendre une part plus active dans la définition des fonctionnalités, dans les arbitrages, dans la compréhension des usages. Là, la frontière entre engineering, product et design devient plus floue, et on voit émerger des profils capables de couvrir une partie plus large du cycle.
• Il y a aussi une voie plus transverse, qui consiste à accompagner les autres métiers dans leur capacité à produire du logiciel. Mettre en place des cadres, éviter les dérives, transmettre des réflexes. C'est un rôle moins visible, mais avec un impact organisationnel assez fort.
• Certains peuvent aussi choisir de rester sur des sujets plus techniques, autour du design de systèmes, de la performance, de la sécurité, ou de problématiques difficiles à standardiser. Mais même dans ce cas, ces compétences deviennent de plus en plus des prérequis plutôt que des éléments différenciants.
• Enfin, il y a une voie plus entrepreneuriale. Le fait que la production soit plus accessible permet à certains de construire seuls des produits ou des outils, là où il fallait auparavant s'entourer d'autres profils.

Aucune de ces trajectoires n'est nouvelle en soi. Ce qui change, c'est qu'elles deviennent plus marquées, et surtout plus difficiles à éviter. Rester uniquement dans une logique d'exécution devient une position de plus en plus fragile. À l'inverse, se positionner sur ces nouvelles zones demande de faire évoluer son rôle et parfois assez drastiquement.

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.

Standardisation

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.

Background agents

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.

Sandbox

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 :

• l'agent lui-même
• les secrets nécessaires au fonctionnement du système
• le code généré et exécuté par l'agent
• l'environnement d'exécution

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.

Event-driven agents

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 :

• cron
• webhooks
• appels API
• événements système

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.

Orchestration

À 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.

Tool connectivity

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.

Verifiable outputs

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.

Observability

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.

Conclusion

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.

Ce changement ne se limite pas à l'adoption de nouveaux outils, il redéfinit le cycle de vie lui-même.

Dans cette série de cinq articles, je propose d'explorer cette évolution de manière structurée :

1. Du DevOps Loop à l'Autonomous Software Factory Loop : Comment le SDLC évolue structurellement.
2. Les enablers de la nouvelle Software Factory : Les composants qui rendent ce modèle possible.
3. L'évolution des pratiques et des paradigmes : Certaines sont renforcées, d'autres deviennent peu à peu obsolètes et des changements majeurs sont encore à prévoir.
4. L'évolution des rôles Produit Tech : Comment les responsabilités et les équilibres se redessinent.
5. L'accélération de la boucle de feedback utilisateur : Comment cette nouvelle factory permet d'apprendre plus vite du marché.

L'Autonomous Software Factory Loop

En 2026, le cycle de vie logiciel entre dans une nouvelle phase d'évolution.

Spécification, implémentation, tests, déploiement, observabilité,... : chaque étape peut être instrumentée, augmentée, et partiellement automatisée. Ce mouvement ne se résume pas à une accélération de la livraison, il modifie la dynamique interne du système.

Là où le DevOps avait industrialisé la continuité du delivery, une nouvelle configuration émerge : un Autonomous Software Factory Loop, dans lequel la production est accélérée et l'amélioration du système progressivement instrumentée.

De nombreuses expérimentations sont en cours et la forme finale de cette factory reste encore loin d'être stabilisée. Mais les contours du modèle apparaissent déjà clairement : un système de production logiciel progressivement instrumenté, dans lequel une part croissante du travail opérationnel et de l'amélioration du système est prise en charge par des agents.

La boucle DevOps

Revenons d'abord (un peu) en arrière. Depuis une 15aine d'années, la représentation dominante du cycle de vie logiciel a été la boucle DevOps.

Elle décrit un flux continu allant de la planification à la production : planification, développement, tests, déploiement, exploitation et monitoring.

L'objectif principal de cette boucle est simple : réduire le temps entre l'idée et son utilisation par les utilisateurs .

Plus le cycle est rapide, plus l'organisation peut apprendre du marché et ajuster son produit.

Les pratiques DevOps, combinées à l'automatisation CI/CD, ont ainsi permis d'industrialiser la livraison logicielle et de rendre ce flux de production continu.

L'amélioration continue : optimiser la boucle

Une fois cette boucle installée, l'enjeu devient naturellement son amélioration.

Dans la plupart des organisations, cette amélioration repose sur des boucles humaines d'analyse et de décision. Les équipes observent les frictions du système, identifient les points de blocage et cherchent à fluidifier le flux.

Ces mécanismes prennent différentes formes :

• rétrospectives agiles
• post-mortems
• revues d'incidents
• revues de backlog de bugs
• discussions d'équipe sur la dette technique ou les outils

L'idée est toujours la même : identifier ce qui ralentit le système et décider des actions permettant de l'améliorer.

Dans la pratique, ces améliorations se traduisent souvent par des tâches planifiées dans le backlog ou la roadmap. Or ces initiatives entrent fréquemment en concurrence avec les priorités produit, ce qui rend leur mise en œuvre parfois difficile.

La boucle s'améliore donc, mais de manière intermittente et largement dépendante de l'analyse humaine.

L'émergence de l'Autonomous Software Factory Loop

Depuis un/deux ans, l'attention s'est beaucoup concentrée sur l'impact de l'IA dans l'écriture du code. Les gains de productivité liés aux assistants de développement sont désormais bien visibles.

Mais ces gains ne suffisent pas à transformer le débit global du système. Lorsque l'écriture du code devient plus rapide, les goulots d'étranglement se déplacent naturellement vers d'autres étapes du cycle : la spécification, le code review, la validation, l'analyse des incidents ou encore l'exploitation.

Autrement dit, améliorer une seule étape du flux ne suffit pas à accélérer l'ensemble du système. C'était vrai avant l'IA, ca l'est encore plus aujourd'hui.

C'est pourquoi la transformation en cours ne concerne pas seulement le développement lui-même, mais l'ensemble de la boucle de production logicielle.

Progressivement, des agents viennent s'intégrer à chaque étape du cycle :

• assistance à la spécification
• code reviews
• analyse d'incidents
• exploration des logs et du monitoring
• génération de documentation
• intégration design
• ...

L'objectif n'est plus seulement d'augmenter la productivité individuelle des développeurs, mais de réduire les frictions à l'échelle du système.

Peu à peu, les organisations cherchent ainsi à faire tomber les barrières qui ralentissent le flux. Or ces barrières sont le plus souvent humaines : analyse manuelle, production de tests, investigation d'incidents, documentation ou coordination.

En automatisant progressivement ces tâches grâce à des agents, la boucle DevOps évolue vers une Software Factory instrumentée, dans laquelle une partie croissante du travail opérationnel est prise en charge par le système lui-même.

L'automatisation de la boucle d'amélioration

Mais ce n'est pas tout. La transformation ne concerne pas seulement la production. Elle touche également la boucle d'amélioration continue elle-même.

Jusqu'ici, cette amélioration reposait essentiellement sur l'observation et l'analyse humaines. Avec l'instrumentation croissante des systèmes et l'usage d'agents, une grande partie de cette analyse peut également désormais être automatisée.

Les agents peuvent exploiter différents types de signaux :

• les échecs de build ou de déploiement
• les logs de monitoring
• les incidents en production
• les conversations entre développeurs et agents
• les patterns récurrents dans le code ou les tests

À partir de ces données, l'IA peut identifier des problèmes récurrents, proposer des corrections ou suggérer des améliorations du système.

Ces apprentissages peuvent ensuite être réinjectés directement dans la boucle de production . La factory n'est donc plus seulement un système de livraison continue,

elle devient progressivement un système capable d'améliorer son propre fonctionnement.

Dans ce contexte, la place du software engineer évolue également. Plutôt que d'intervenir dans chacune des étapes opérationnelles du cycle, il se déplace progressivement vers un rôle de supervision et d'orchestration du système.

L'enjeu devient alors de piloter la factory : ajuster les agents, superviser les décisions automatisées, et chercher en permanence à faire fonctionner la machine de manière plus fluide, plus rapide et sans accroc.

DevOps a en partie industrialisé la production du logiciel. L'IA nous pousse à l'industrialiser véritablement, y compris l'amélioration du système lui-même.

C'est cette évolution qui dessine progressivement une Autonomous Software Factory Loop, dans laquelle production et amélioration s'inscrivent dans un même flux.

Comprendre cette transformation nécessite toutefois d'aller au-delà du cycle lui-même. Elle repose sur un ensemble de briques techniques et organisationnelles qui rendent cette factory possible.

C'est précisément ce que nous explorerons dans le prochain article : les enablers et les composants de la nouvelle Software Factory.