L'IA n'est pas le sujet : pourquoi le véritable défi est désormais l'ingénierie des systèmes de production logicielle ?

le 27/07/2026 par Cyril NATKOVITCH
Tags: Data & AI, Cloud & Platform, Software Engineering, Architecture, Transformation

Introduction

En moins de trois ans, l'intelligence artificielle générative s'est imposée comme un outil incontournable de l'ingénierie logicielle. Des assistants de développement aux agents autonomes capables de concevoir une architecture, générer du code, produire des tests ou rédiger de la documentation, l'IA est désormais présente à pratiquement toutes les étapes du Software Delivery Lifecycle. Ce qui relevait hier de l'expérimentation est progressivement devenu une pratique courante.

Pourtant, le débat public continue de se focaliser sur une question qui me semble secondaire : l'IA remplacera-t-elle les développeurs ?

Cette interrogation masque les véritables transformations en cours. L'enjeu n'est plus l'adoption de l'IA : celle-ci est déjà largement engagée. Le véritable défi consiste désormais à maîtriser une production logicielle de plus en plus automatisée, à l'industrialiser et à garantir qu'elle reste conforme aux exigences de qualité, de sécurité, de maintenabilité et d'évolutivité.

Cette évolution marque un changement de paradigme. Pendant plusieurs décennies, l'ingénierie logicielle s'est attachée à optimiser la manière dont les équipes produisaient du code. Demain, elle devra surtout organiser la collaboration entre humains et agents d'intelligence artificielle au sein de véritables systèmes industriels de production.

Autrement dit, l'IA n'est pas le sujet.

Le sujet est l'ingénierie qui permet de l'utiliser de manière fiable, durable et responsable.

Le retour du Craft : produire vite ne signifie pas produire bien

L'IA générative est devenue une commodité. Elle intervient aujourd'hui dans toutes les phases du flow de delivery : idéation, refinement, conception, développement, génération de tests, documentation, revue de code, déploiement et exploitation.

Dans ce contexte, la vitesse de production cesse progressivement d'être un facteur différenciant. Presque toutes les organisations disposent désormais des mêmes capacités techniques.

La question devient alors beaucoup plus intéressante.

  • Comment garantir qu'un code généré automatiquement respecte les standards de développement de l'entreprise ?
  • Comment vérifier qu'il ne contient pas d'erreurs logiques pourtant invisibles lors de la compilation ?
  • Comment détecter une hallucination du modèle lorsqu'elle produit un résultat plausible mais incorrect ?
  • Comment s'assurer qu'une architecture reste cohérente lorsque plusieurs dizaines d'agents interviennent simultanément sur différents composants ?

Ces interrogations rappellent une réalité fondamentale : un logiciel n'est pas un assemblage de lignes de code ; c'est un système vivant qui devra évoluer pendant plusieurs années. J’ai beaucoup apprécié les échanges de Victor Dizengremel et de Paul-Elian Tabarant consultants OCTO sur l’expérimentation de l’IA dans le cadre de leur REX : Craft-Driven AI : le mode x2 du dev, la qualité en plus ?. Victor nous indiquait que malgré l’arrivée de l’IA et que le code était de plus en plus une commodité, il prenait du plaisir à lire le code qui matérialisait sa réflexion et qui lui permettait de s’assurer que ce qui était produit correspondait bien à l’attendu.

C'est précisément dans ce contexte que les notions de Software Craftsmanship retrouvent toute leur importance.

Les principes historiques du Craft — simplicité, lisibilité, tests automatisés, revues de code, refactoring continu, architecture intentionnelle — ne disparaissent pas avec l'IA. Ils deviennent au contraire indispensables. Plus la génération de code est automatisée, plus les mécanismes garantissant sa qualité doivent être robustes.

Cette évolution conduit également à l'émergence d'une nouvelle discipline : le Harness Engineering.

Là où le Prompt Engineering cherchait principalement à optimiser les interactions avec un modèle de langage, le Harness Engineering s'intéresse à l'ensemble de l'environnement dans lequel évoluent les agents : contraintes architecturales, politiques de sécurité, jeux de tests, métriques de qualité, garde-fous, observabilité et boucles de validation.

Autrement dit, la qualité ne dépend plus uniquement du modèle. Elle dépend du système qui encadre son utilisation.Cette évolution ne signe donc pas la disparition des développeurs. Elle transforme profondément leur rôle.

L'ingénieur devient moins un producteur de code qu'un concepteur de systèmes capables d'orchestrer et de contrôler efficacement une production logicielle largement assistée par l'IA.

Dans nos différents échanges avec la communauté OCTO, je n’ai pas rencontré à date, une personne qui met indiqué qu’il laissait l’IA implémenter le code généré sans une relecture. Cela sera peut être différent demain mais aujourd’hui l’ensemble des pratiques crafts gardent toute leur importance.

Des assistants aux Software AI Digital Factories

Les gains individuels procurés par les assistants de développement sont désormais largement démontrés. En revanche, peu d'organisations savent encore transformer ces gains locaux en une capacité industrielle.

Or, c'est probablement là que se situe le véritable enjeu des prochaines années.

L'objectif n'est plus de permettre à chaque développeur d'utiliser un agent conversationnel.

Il s'agit de construire une Software AI Digital Factory.

Cette usine logicielle nouvelle génération ne se contente pas de produire du code plus rapidement. Elle organise une chaîne complète de production dans laquelle humains, plateformes et agents collaborent autour de règles communes, de pipelines automatisés et de mécanismes de gouvernance garantissant la qualité des livrables.

Cette industrialisation soulève néanmoins plusieurs questions majeures.

  • Qui est responsable d'un code généré par un agent ?
  • Le développeur qui valide la Pull Request ?
  • L'architecte ayant défini les règles ?
  • L'équipe ayant conçu le harness ?
  • Ou l'organisation qui exploite cette chaîne industrielle ?

Les interrogations deviennent encore plus profondes lorsque l'on s'intéresse au cycle de vie du logiciel.

  • Qui maintient un système essentiellement produit par des agents ?
  • Comment transmettre sa compréhension lorsque les équipes ayant conçu la plateforme ont quitté l'entreprise ?

Peut-on encore parler de patrimoine logiciel lorsque la majeure partie de la connaissance réside dans les prompts, les règles de gouvernance, les jeux de tests et les configurations des agents ?

Une hypothèse mérite alors d'être explorée.

Si la génération devient presque instantanée et peu coûteuse, faudra-t-il encore maintenir certains logiciels pendant plusieurs décennies ?

Ou assisterons-nous à l'émergence d'applications plus éphémères, régulièrement régénérées à partir de spécifications, de tests et de règles métier plutôt que continuellement modifiées ?

Cette perspective reste spéculative. Elle illustre néanmoins une transformation profonde : la valeur pourrait progressivement se déplacer du code vers le système capable de le produire de manière fiable.

Le token : la nouvelle unité économique de l'ingénierie logicielle

Une troisième question, souvent moins médiatisée, devient aujourd'hui centrale : celle du coût.

Pendant les premiers mois de l'adoption massive des IA génératives, les organisations se sont principalement concentrées sur les gains de productivité. Désormais, elles découvrent une nouvelle réalité économique : le token est devenu une ressource stratégique.

Chaque génération de code, chaque analyse d'architecture, chaque revue automatique et chaque exécution d'agent consomment des millions de tokens. À l'échelle d'une grande entreprise, ces coûts deviennent rapidement significatifs.

Les réactions observées sur le marché témoignent de cette prise de conscience. Certaines entreprises ont revu leur politique d'accès à certains outils afin de mieux maîtriser leurs dépenses comme Microsoft. D'autres ont instauré des quotas, des mécanismes de supervision ou des recommandations visant à optimiser l'utilisation des modèles les plus coûteux. Uber par exemple a consommé en 4 mois son budget IA pour l’année. Plus largement, la question du retour sur investissement de l'IA générative devient un sujet de gouvernance autant que de technologie.

Cette évolution conduit naturellement à l'émergence de nouvelles bonnes pratiques : optimisation des contextes envoyés aux modèles, sélection dynamique du LLM selon la complexité de la tâche, recours à des modèles spécialisés moins coûteux lorsque cela est possible, ou encore mutualisation des traitements.

Mais au-delà de l'optimisation économique, une question stratégique apparaît.

Le marché des grands modèles est aujourd'hui dominé par un nombre limité d'acteurs américains, tandis que de nouveaux modèles open source et chinois proposent des performances croissantes pour des coûts parfois sensiblement inférieurs.

Cette situation rappelle, toutes proportions gardées, certaines dynamiques industrielles observées dans d'autres secteurs : lorsqu'un acteur maîtrise les coûts de production et conquiert rapidement des parts de marché, il peut progressivement devenir incontournable.

L'analogie avec l'industrie automobile électrique doit toutefois être maniée avec prudence. Les marchés, les régulations et les chaînes de valeur diffèrent profondément. En revanche, la question de la dépendance technologique est bien réelle.

  • Peut-on construire une stratégie numérique durable lorsque l'ensemble de sa chaîne de production logicielle dépend de quelques fournisseurs de modèles ?
  • Comment préserver sa souveraineté technologique si les coûts, les licences ou les conditions d'utilisation évoluent brutalement ?
  • Faut-il privilégier des modèles ouverts, quitte à investir davantage dans leur exploitation ?

Ces questions dépassent largement le cadre technique. Elles relèvent désormais de la stratégie industrielle des entreprises.

Conclusion

L'intelligence artificielle générative constitue sans doute la transformation la plus importante qu'ait connue l'ingénierie logicielle depuis l'avènement du cloud et du DevOps. Pourtant, la technologie elle-même n'est probablement pas le principal facteur de différenciation.

À mesure que les modèles deviennent accessibles à tous, ils tendent à devenir des commodités.

La véritable valeur se déplace vers les pratiques d'ingénierie permettant d'en maîtriser l'usage : Software Craftsmanship, Harness Engineering, gouvernance des agents, architecture, observabilité et industrialisation.

Les entreprises qui tireront durablement parti de l'IA ne seront pas nécessairement celles disposant du modèle le plus performant. Elles seront celles capables de construire des Software AI Digital Factories où la production accélérée reste fiable, explicable, maintenable et économiquement soutenable.

Enfin, la question du coût des tokens et de la dépendance envers quelques fournisseurs rappelle que cette révolution n'est pas uniquement technique. Elle est également économique, organisationnelle et géopolitique.

L'histoire de l'ingénierie logicielle montre que les avantages concurrentiels durables ne proviennent jamais uniquement des outils. Ils naissent de la capacité des organisations à structurer des pratiques, à développer une culture technique exigeante et à transformer une innovation en un système industriel maîtrisé.

L'IA ne fait pas exception à cette règle.

Références et sources d'inspiration

Software Craft & Harness Engineering

Software Engineering

  • Robert C. Martin — Clean Architecture (2017).
  • Pete McBreen — Software Craftsmanship (2001).
  • Jez Humble & David Farley — Continuous Delivery (2010).
  • Gene Kim, Jez Humble, Patrick Debois & John Willis — The DevOps Handbook (2021, 2e éd.).