Pour la troisième fois en dix ans, les directions techniques sont invitées à adopter une rupture technologique majeure. Après le DevOps, après le cloud-native, l’intelligence artificielle générative constitue la troisième vague d’adoption depuis 2024. Et pour la troisième fois, nous constatons chez certaines organisations que le pattern d’adoption reproduit les mêmes erreurs : un outil déployé en amont des principes qui le rendent utile, des indicateurs de productivité présentés en l’absence d’indicateurs de valeur et des budgets engagés avant qu’un diagnostic n’ait été posé.
Une troisième vague qui rejoue le même schéma
Ce constat terrain, nous l’avons confirmé chez Cockpit io à la lecture du rapport DORA 2025 State of AI-assisted Software Development, basé sur près de 5 000 professionnels de la tech. Il documente avec précision notre intuition. Sa conclusion centrale, formulée en une phrase, mérite d’être prise au sérieux par toute direction technique arbitrant un budget : l’IA est un amplificateur, pas une solution. Sur une organisation aux fondations solides, elle accélère ce qui fonctionne déjà. Sur une organisation fragile, elle aggrave l’instabilité, multiplie les travaux correctifs et allonge les cycles de résolution d’incidents.
L’implication pour une direction technique est directe. La question pertinente n’est plus « comment adopter l’IA ». Elle est : « les fondations DevOps et cloud-native de mon organisation sont-elles en état d’absorber un nouvel amplificateur ? » Cette question, contrairement à la première, peut être traitée avec un diagnostic structuré, mesurable, et antérieur aux arbitrages budgétaires.
Le constat chiffré de DORA 2025
Le rapport DORA 2025 expose les mécanismes de cet effet d’amplification avec précision. Sur les équipes solidement structurées (fondations DevOps en place, plateforme interne de qualité, culture de feedback active), l’IA accélère ce qui fonctionne déjà : la vitesse de livraison augmente, la qualité tient.
Sur les autres, le constat est sévère. L’adoption de l’IA y corrèle positivement avec une instabilité plus élevée, davantage de change failures, davantage de travaux correctifs, des cycles de résolution d’incidents plus longs. La métaphore retenue dans le rapport est précise : l’IA n’est pas un outil dans une boîte, c’est un miroir qui reflète la réalité de la culture d’ingénierie en place.
Le rapport ajoute un point que les directions techniques devraient examiner attentivement. 90 % des organisations interrogées disposent aujourd’hui d’une plateforme interne, et trois quarts ont une équipe plateforme dédiée. Mais la qualité de cette plateforme fait toute la différence. Une plateforme solide amplifie les bénéfices de l’IA. Une plateforme médiocre les annule, et peut même les inverser.
Autrement dit : ce sur quoi une organisation n’a pas investi ces cinq dernières années deviendra visible dans les dix-huit prochains mois.
« L'IA n'est pas une transformation, c'est un révélateur. »
La grille de lecture qui survit aux trois cycles
Quand on observe le DevOps, le cloud-native et l’IA, aujourd’hui plus que jamais, une grille de lecture résiste à l’usure : les Three Ways formulés par Gene Kim. Pas comme méthode prescriptive, mais comme trois principes qui décrivent les invariants de toute transformation IT performante.
Première voie, le flux. Le principe est d’optimiser la performance du système complet, et non celle de chaque silo pris séparément. Cela suppose de rendre le travail en cours visible, de réduire la taille des lots livrés et de supprimer les transferts entre équipes qui n’ajoutent pas de valeur.
Deuxième voie, le feedback. La deuxième voie inverse la direction du flux. L’objectif est de raccourcir et d’amplifier toutes les boucles de retour d’information : du comportement client vers les équipes produit, de la production vers le développement, de l’incident vers le système organisationnel qui l’a rendu possible. Les métriques DORA, désormais au nombre de cinq depuis l’ajout du Rework Rate dans le rapport 2024, opérationnalisent cette voie.
Troisième voie, l’apprentissage continu. C’est la plus exigeante des trois parce qu’elle touche à la culture avant de toucher aux processus. Il s’agit de s’assurer que les apprentissages locaux se transforment en améliorations globales, que l’expérimentation est traitée comme une pratique de gestion du risque et non comme une exception, et que les post-mortem produisent des changements systémiques plutôt que des séances de bonnes résolutions.
Ce qui rend ce cadre robuste, c’est qu’il ne dépend ni du langage, ni du cloud, ni du framework de la décennie. Il décrit des conditions de performance qu’un nouvel outil ne crée pas mais peut amplifier. Y compris un outil aussi puissant qu’un modèle génératif.
Les thèmes à approfondir avant d’investir dans l’IA
Pour un(e) CTO ou une direction technique qui s’apprête à arbitrer un budget IA, je propose un test de maturité simple, calé sur les trois voies. Trois questions, formulées dans des termes mesurables.
Sur le flux. Quel est aujourd’hui le délai entre un commit et sa mise en production ? Combien de personnes interviennent dans cette chaîne ? Quelle est la taille moyenne d’un déploiement ? Si le lead time se compte en semaines, l’IA va vous permettre de générer du code plus vite, mais ce code attendra autant qu’avant. Le bénéfice mesuré sera marginal, parce que le goulot d’étranglement n’est pas la génération.
Sur le feedback. Quel est votre change failure rate ? Combien de temps pour détecter un incident en production ? Combien de temps pour le résoudre ? Les équipes de développement voient-elles leur code tourner en production, ou découvrent-elles les incidents par un ticket remonté trois jours plus tard ? Si les boucles de feedback sont longues, l’accélération de la génération de code va faire grossir le stock de défauts non détectés. Le rapport DORA 2025 documente précisément cette dégradation : individuellement plus rapide, collectivement plus instable.
Sur l’apprentissage. Que faites-vous d’un incident une fois résolu ? Les enseignements restent-ils dans une équipe ou se diffusent-ils ? Avez-vous une pratique d’ADR (Architecture Decision Record) documentant vos décisions d’architecture ? Une revue trimestrielle des incidents au-delà de l’équipe concernée ? Si l’apprentissage ne circule pas, chaque équipe va réinventer ses propres patterns d’usage de l’IA, avec des écarts de qualité considérables, et aucun mécanisme d’arbitrage global.
Ces questions ne donnent pas une feuille de route. Elles donnent une partie d’un diagnostic. Et c’est ce diagnostic qui devrait précéder, et non suivre, le choix des outils.
Chez Cockpit io, c’est précisément la grille que nous appliquons aux directions techniques qui préparent leur stratégie IA. L’observation est constante d’une mission à l’autre : la conviction qu’il faut « faire de l’IA » précède presque toujours l’examen lucide des fondations qui devraient l’accueillir. Le diagnostic posé en amont oriente le budget. Posé une fois l’IA déjà déployée, il révèle pourquoi les bénéfices ne sont pas au rendez-vous, et c’est exactement là que nous pouvons encore agir.
Le terrain de jeu silencieux : le cloud-native
Il y a un point que les directions techniques sous-estiment quand elles abordent l’IA : la quasi-totalité des charges de travail IA en production vivent dans des environnements cloud-native. Inférence en temps réel orchestrée sur Kubernetes, pipelines MLOps sur des plateformes managées, observabilité de chaînes d’agents qui repose sur du tracing distribué, gestion des coûts GPU qui exige une discipline FinOps mature, gouvernance des données qui doit composer avec NIS2 et le Data Act.
Cela veut dire qu’une fragilité dans vos fondations cloud-native (un Kubernetes mal maintenu, une plateforme d’observabilité incomplète, une stratégie multicloud pas tranchée, une absence de FinOps structurée) va se transformer en dette IA à grande vitesse. Les workloads IA sont plus coûteux, plus opaques en performance, plus exigeants en observabilité que les workloads applicatifs classiques. Ils amplifient les faiblesses de la plateforme qui les héberge.
C’est pour cette raison que je dis aux comités exécutifs que nous accompagnons : la maturité cloud-native d’une organisation est aujourd’hui un prérequis silencieux à toute stratégie IA crédible. Pas un sujet à traiter « plus tard ». Un sujet à traiter en parallèle, voire en amont.
Ce que cela change pour les décideuses et les décideurs Tech
Disons-le sans détour : les entreprises qui ont fait leurs devoirs sur le flux, le feedback et l’apprentissage entre 2018 et 2025 vont être accélérées par l’IA. Les entreprises qui ne les ont pas faits vont voir leur chaos s’industrialiser.
Aucun outil ne va combler ce delta. Aucune plateforme. Aucun fournisseur. La GenAI ne remplace pas dix ans de discipline d’ingénierie ; elle les rend visibles, ou elle les expose.
Pour les décideurs tech qui doivent arbitrer un budget, cela conduit à trois priorités, dans cet ordre.
Faire le diagnostic d’abord. Avant d’engager des moyens IA significatifs, passer les trois questions ci-dessus à son organisation, équipe par équipe, value stream par value stream. Si le résultat est faible sur l’une des trois voies, c’est là que devrait aller le premier euro investi, pas dans un nouvel outil.
Stabiliser la plateforme ensuite. Le rapport DORA 2025 le montre sans ambiguïté : la qualité de la plateforme interne est le différenciateur principal entre les organisations qui tirent un bénéfice de l’IA et celles qui n’en tirent rien. Une plateforme cloud-native solide est désormais une condition de retour sur investissement, pas une option d’architecture.
Traiter l’IA comme une transformation, pas comme un outil. La GenAI n’a pas changé le pattern. Elle a juste relevé la mise. Les principes qui faisaient gagner les équipes DevOps en 2016 sont les mêmes qui font gagner les équipes IA en 2026. Ce sont eux qu’il faut adresser, pas la couche d’outils qui les utilisera.
Ce qui va se jouer maintenant
Les dix-huit prochains mois vont être le test de maturité IT le plus brutal qu’on ait vu depuis la fin des années 2000. Cet écart, jusqu’ici visible des seules équipes techniques, va devenir lisible par tout le monde : vos clients, vos concurrents, les talents que vous cherchez à recruter. Et il se réduira d’autant plus lentement qu’on aura attendu pour s’y attaquer.
La bonne nouvelle, si l’on peut parler de bonne nouvelle, c’est que le diagnostic existe, qu’il est documenté, et qu’il peut être posé en quelques semaines. Le mauvais réflexe serait d’attendre que l’écart soit visible pour le réduire. À ce stade, il sera trop tard pour ce cycle.
Ce que l’IA révélera de chaque organisation IT dépend exactement de ce que cette organisation a choisi de ne pas traiter ces dix dernières années. Le diagnostic n’attend pas. L’arbitrage budgétaire 2026, lui, est déjà ouvert.
Sources principales :
- DORA, 2025 State of AI-assisted Software Development Report
- Kim, Humble, Debois, Willis, Forsgren, The DevOps Handbook, 2e édition (IT Revolution)