Florian Fesseler
L'intelligence artificielle ne transforme pas seulement la manière dont nous écrivons du code. Elle transforme la manière dont nous concevons, produisons et améliorons les produits.
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 :
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.
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.
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 :
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.
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 :
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.
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 :
À 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.