Les 8 étapes de la maturité en ingénierie de l'IA : un cadre de référence pour les équipes

Il y a quelques mois, Steve Yegge a publié ses « 8 niveaux de développement assisté par l’IA », et ça m’a tout de suite parlé quand je l’ai lu, parce que j’avais moi-même vécu exactement cette progression, en passant de l’auto-complétion à l’exécution d’agents, étape par étape. Présenté sous la forme d’un « gradient de confiance en l’IA », ça a enfin donné au secteur un vocabulaire pour désigner quelque chose que la plupart d’entre nous vivions déjà sans pouvoir le nommer. Si tu ne l’as pas encore lu, garde-le pour plus tard.

Les niveaux de Yegge se concentrent sur le développeur individuel. Et c’est là tout le problème : quand tu diriges une équipe d’ingénieurs, tu ne gères pas un seul gradient de confiance, tu gères toute une distribution de ces gradients. Tu as quelqu’un qui fait tourner des agents en parallèle toute la journée, assis à côté de quelqu’un qui considère encore l’IA comme une version plus sophistiquée de la saisie semi-automatique, et tous les deux livrent du code. C’est pour ça que le gain de productivité multiplié par 10 dont tout le monde parle ne se concrétise presque jamais au niveau de l’organisation. Le plus dur, c’est de faire avancer toute l’organisation d’un seul bloc, sans que les plus rapides ne sèment le chaos et que les plus lents ne prennent discrètement du retard.

On a donc repris ces mêmes principes et on les a examinés sous un autre angle : non pas le développeur individuel décrit par Yegge, mais l’équipe et l’organisation dans laquelle elle évolue. Huit étapes de maturité, allant de « personne n’a encore rien décidé » à « l’usine fonctionne toute seule ».

Un petit mot sur le vocabulaire, car on s’y réfère tout au long de cet article. Quand on dit « équipe », on parle d’un groupe de personnes travaillant ensemble vers un même objectif : des ingénieurs, bien sûr, mais aussi des responsables produit, des designers, des testeurs, bref, tous ceux dont on a besoin pour livrer un logiciel. Quand on dit « organisation », on parle de l’ensemble de ces équipes, ainsi que de la direction, des budgets et de la gouvernance qui les chapeautent.

Et voilà ce qui fait que c’est une histoire sur le cycle de vie du développement logiciel (SDLC) et pas seulement une histoire de développeurs : le nouveau cycle de vie du développement logiciel ne concerne pas seulement les développeurs. Il concerne toute l’équipe. Les anciennes frontières entre produit, design et ingénierie s’estompent. Un chef de produit peut désormais coder à l’instinct un prototype fonctionnel au lieu d’écrire un cahier des charges de trois pages que personne ne lit. Un designer peut livrer du vrai code HTML et CSS, pas seulement un système de design et un fichier Figma à passer au suivant. C’est ce changement qui est essentiel, et c’est pour ça que penser en termes de développeurs individuels ne suffit plus.

Voyons d’abord la carte dans son ensemble avant de la parcourir.

Étape 1 : Le vide

La direction n’a pas vraiment pris position ; tout au plus, elle a acheté un lot de licences et s’est arrêtée là. Les développeurs prennent des habitudes sans garde-fous : ils collent du code dans n’importe quelle fenêtre de chat ouverte, pas de fichiers de contexte partagés, pas de configuration d’agent, pas de clés API gérées. C’est une phase d’apprentissage, et je pense que c’est normal : les gens développent une intuition sur ce que ces modèles peuvent et ne peuvent pas faire. Cette intuition, c’est le vrai bénéfice pour l’instant. Ne confonds pas silence et inaction. Tes développeurs ont déjà pris leurs propres décisions.

Étape 2 : La dérive

La phase 1 portait sur ce que l’organisation n’avait pas encore décidé ; la phase 2 porte sur ce que chacun a décidé de son côté. Un ingénieur utilise discrètement des agents pour gérer une grande partie de sa production, en s’appuyant sur une réserve personnelle de prompts, de compétences personnalisées et un fichier AGENTS.md soigneusement optimisé qu’il conserve sur sa propre machine. La personne à côté de lui n’a rien changé depuis deux ans, et personne ne le signale car les variations individuelles ont toujours été considérées comme normales. C’est la dernière étape où l’inaction ne coûte rien. Une fois que la dérive devient visible – et elle le deviendra –, elle se transforme en un problème à l’échelle de l’équipe.

Étape 3 : Les îlots

Le fossé qui existait auparavant entre les individus sépare désormais des équipes entières, et ça se voit clairement sur le calendrier de livraison, à la vue de tous. Une équipe a mis en commun ses fichiers AGENTS.md, connecté des serveurs MCP et développé des compétences réutilisables. Son rendement grimpe en flèche. L’équipe d’à côté continue d’écrire du code comme il y a deux ans… Ce qui commence par un écart d’outils se transforme en ressentiment, et ça, c’est bien plus difficile à réparer.

Étape 4 : Le pari de la standardisation

La première étape qui exige un véritable engagement de la part de la direction, c’est de faire de l’IA une capacité que tu développes délibérément. Trois éléments sont essentiels ici. L’ingénierie contextuelle devient un travail explicite, avec des fichiers AGENTS.md partagés et une bibliothèque de compétences et de prompts soigneusement sélectionnés dans les dépôts, pour que l’équipe encode ses connaissances une seule fois au lieu que chaque développeur doive enseigner les mêmes leçons à l’IA. La sécurité et la gouvernance passent avant la montée en puissance : SSO et SCIM, analyse des secrets, contrôles PR basés sur les résultats des agents, journaux d’audit, et une liste approuvée de modèles et d’outils derrière une passerelle, mise en place avant que tout le monde ne se lance à fond. Et la formation est continue, pas un atelier ponctuel, généralement articulée autour des champions de l’étape 2.

Étape 5 : La refonte du processus

La phase 4 met à niveau les outils ; la phase 5 repense l’atelier, en changeant la façon dont le travail est réellement effectué. Le principe « spécifications d’abord » devient la norme : les spécifications se trouvent dans le dépôt et servent de point d’entrée à l’agent, et un agent ne peut pas mieux travailler à partir d’un ticket vague qu’un développeur junior. La revue de code passe d’une analyse ligne par ligne à des questions basées sur les risques : est-ce que ça correspond aux spécifications ? Les tests le prouvent-ils ? Quelle serait l’ampleur des répercussions si c’était faux ? Les barrières d’intégration continue (CI) traitent les PR ouverts par les agents exactement comme celles ouvertes par des humains, et les évaluations s’exécutent juste à côté des tests unitaires. Attends-toi à une baisse de productivité pendant que le rôle passe de l’écriture de code à la révision et à l’orchestration ; c’est normal. Surveille la qualité, pas seulement la vitesse : plus de code livré avec une qualité moindre, ce n’est pas de la rapidité, ce sont des incidents qui arrivent plus tôt.

Étape 6 : Le système d’exploitation

L’étape 5 a changé la façon dont une équipe travaille ; l’étape 6 change la composition de l’équipe et la manière dont les équipes se coordonnent. Un sprint peut compter trois ingénieurs et cinq emplacements d’agents, et l’ingénieur ressemble désormais davantage à un chef de produit qu’à un programmeur : il rédige les spécifications, en discute avec l’IA, vérifie les tests. Le TDD devient une nécessité, pas un simple plus : les agents s’optimisent pour réussir les tests, donc une suite de tests faible sera contournée, et tu ne t’en rendras compte qu’une fois en production. Des agents parallèles s’exécutant dans des bacs à sable isolés peuvent consommer, en un seul sprint, plus de ressources de calcul que la moitié du coût d’hébergement trimestriel ; du coup, les budgets de jetons et l’observabilité par exécution ne sont plus des options. Et le contexte partagé devient une véritable infrastructure (mémoire de projet, compétences, bibliothèques de prompts, serveurs MCP), gérée comme un actif de l’équipe et coordonnée entre les équipes.

Étape 7 : L’usine intelligente

Le fil conducteur de l’étape 6, c’est de savoir qui tient la plume. Les agents écrivent et livrent désormais des unités de travail complètes sans pratiquement aucune intervention humaine, et l’humain passe du rôle de pilote à celui de superviseur. La plupart des équipes sont encore en mode « baby-sitting » : les agents sont lancés depuis un terminal sur l’ordi portable de quelqu’un, tournent en boucle localement et ouvrent des PR depuis une machine de développement, sans environnement d’exécution partagé ni registre central indiquant ce qui a tourné ni pourquoi. Ce détail de la machine locale est la seule chose qui sépare cette étape de la suivante.

Étape 8 : L’usine autonome

Les agents quittent les ordinateurs portables pour s’installer sur une infrastructure partagée, avec des exécutions planifiées dans des environnements sandboxés et des journaux et traces centralisés. Ainsi, une migration qui nécessitait auparavant une surveillance constante s’exécute pendant la nuit et rend compte de ses résultats le matin. Les tâches récurrentes deviennent des tâches à part entière (mises à jour des dépendances, correctifs de sécurité, extension des tests) avec des critères de réussite définis et une escalade automatique en cas d’échec. L’évaluation devient le produit : les connaissances qui étaient dans la tête des gens se trouvent désormais dans les configurations des agents, leurs compétences et les suites d’évaluation qui contrôlent chaque fusion, codées une seule fois et appliquées automatiquement. Tes normes ne sont plus dans la tête de quelqu’un. Elles sont dans le système

Quelques mises en garde honnêtes

Aucune organisation ne se trouve parfaitement à un seul stade. Tu verras certaines équipes au stade 6 et d’autres encore fermement ancrées au stade 1. Ce chiffre est un centre de gravité, pas une étiquette que tu colles sur tout le monde.

De plus, tu ne dois pas sauter d’étapes. Si tu te lances directement dans les agents autonomes sans la gouvernance, les tests et le contexte partagé nécessaires, tu ne seras qu’un projet de plus qui finira à la poubelle. Mais il y a une raison plus subtile de progresser étape par étape : chaque étape est douloureuse à sa manière, et cette douleur est la leçon à en tirer. C’est la friction entre une équipe rapide et une équipe lente qui pousse une entreprise à se standardiser. C’est la corvée de relire ligne par ligne les résultats des agents qui convainc une équipe de repenser le processus. Si tu évites cette difficulté, tu perds la raison d’avancer : rien ne justifie mieux le passage à l’étape suivante que le fait que l’étape actuelle commence à devenir pénible.

Et reste sceptique tout au long du parcours. Le battage médiatique autour de ce sujet est bruyant ; les preuves, bien plus discrètes. Alors, prends chaque promesse, y compris la nôtre, avec précaution.

Conclusion

La question n’est pas de savoir s’il faut adopter l’IA. La plupart des équipes l’ont déjà fait. La vraie question est de savoir si le système sous-jacent est suffisamment performant pour mériter d’être amplifié.

Car c’est ça, l’IA. J’en suis convaincu : c’est un amplificateur. Elle accélère ce qui existe déjà, les bonnes pratiques comme les mauvaises. Les organisations que nous avons vues gagner en vitesse sans perdre en qualité partagent toutes les mêmes fondements : une responsabilité claire des services, des tests exhaustifs, des services documentés et des normes automatisées. Rien de tout ça n’est nouveau. On prône ces bonnes pratiques depuis des années. L’IA a simplement rendu leur absence impossible à ignorer.

L’usine autonome, c’est là que ça nous mène. Le plus dur, ce ne seront pas les agents eux-mêmes : ce sera de leur faire suffisamment confiance pour les sortir des ordinateurs portables individuels et les faire tourner sur une infrastructure partagée. Tu construis ça comme tu l’as toujours fait, avec des preuves. Une évaluation, une tâche récurrente, un déploiement vérifié à la fois.