La livraison native IA est un changement de modèle opérationnel, pas une mise à niveau d'outils

Le piège : des dactylos plus rapides dans un processus inchangé

Le scénario le plus courant consiste à garder le processus existant et à accélérer une seule étape. Les développeurs écrivent du code plus vite. Tout le reste ne change pas : la même qualité d'exigences, le même processus de revue, la même approche de tests, les mêmes étapes d'approbation des mises en production.

Le résultat est prévisible. Le travail s'accumule devant les étapes qui n'ont pas changé. Les réviseurs sont débordés. Les testeurs trouvent plus de défauts, pas moins, parce qu'il arrive plus de code. Les leaders voient l'activité augmenter, le délai de livraison bouger à peine, et concluent que l'IA est surestimée.

L'outil a fonctionné. C'est le modèle opérationnel qui n'a pas changé autour de lui.

Ce qui change vraiment

Quand j'ai travaillé en mode natif IA, quatre choses ont changé plus que je ne l'avais prévu.

• La spécification devient le produit. Un agent construit exactement ce que vous décrivez, y compris les trous. Des exigences floues qu'un développeur d'expérience aurait comblées discrètement avec son jugement sont plutôt comblées par des suppositions plausibles. Dans mes projets, le temps passé à écrire une intention claire, des contraintes et des critères d'acceptation a été le temps le mieux investi de tout l'effort. Quand je l'ai sauté, je l'ai payé en reprises.
• La revue devient la compétence centrale. Quand un agent peut produire une fonctionnalité qui marche en quelques minutes, la compétence rare n'est plus d'écrire du code. C'est de lire du code avec un œil critique, de repérer ce qui est subtilement faux et de savoir quand « ça marche » ne veut pas dire « c'est correct ».
• Les tests deviennent des contrats. Les tests automatisés étaient un filet de sécurité. Dans un flux natif IA, c'est la façon de dire à l'agent ce que veut dire correct, et de savoir qu'il n'a rien brisé d'autre en chemin.
• Les personnes approuvent plutôt que produire. Le rôle humain se déplace vers la décision : quoi bâtir, quelle approche accepter, ce qui peut être mis en production en toute sécurité. C'est un autre métier, et ce ne sont pas tous qui voudront le faire ou qui y seront bons tout de suite.

Ce qui ne change pas

Il est tout aussi important d'être clair sur ce qui reste pareil.

• L'imputabilité. Un agent ne peut pas être responsable d'un incident en production. Une personne nommée doit encore l'être.
• L'architecture. Les agents sont bons pour les décisions locales et moins bons pour la forme à long terme d'un système. Les décisions coûteuses à renverser ont encore besoin de personnes d'expérience.
• La compréhension des affaires. La partie la plus difficile de la plupart des projets n'a jamais été de taper le code. C'était de savoir ce dont l'organisation a vraiment besoin. Ça n'est pas devenu plus facile.

Ce que ça veut dire pour les leaders de livraison

Si l'AN-SDLC est un changement de modèle opérationnel, il faut le mener comme tel. Voici ce que je ferais en premier :

1. Commencer avec une équipe et un vrai produit, pas un déploiement d'outils pour tout le monde. Vous concevez une nouvelle façon de travailler, et vous avez besoin d'un endroit pour apprendre.
2. Redéfinir « terminé » avant de mesurer quoi que ce soit. Écrire ce qu'un humain doit réviser, ce qui doit être testé automatiquement et qui approuve une mise en production.
3. Mesurer le flux, pas la production. Les lignes de code et les demandes de fusion par jour vont augmenter et ne vous apprendront rien. Suivez le délai entre l'idée et la production, les défauts qui se rendent en production et les reprises.
4. Investir dans les compétences qui deviennent rares : écrire des spécifications claires, réviser avec un œil critique et concevoir de bons tests.
5. Le traiter comme un changement pour les personnes, pas seulement pour le processus. Les rôles, l'identité et les incitatifs bougent tous. C'est de là que viendra la plus grande partie de la résistance, et c'est là que se trouve la plus grande partie du travail de leadership.

Si vous voyez déjà cette résistance, Pourquoi de bonnes personnes résistent à de bons changements présente les cinq raisons que je vois le plus souvent, et ce qui aide pour chacune.

La question à poser

Si vous voulez savoir si votre organisation avance vraiment vers une livraison native IA, ne demandez pas combien de personnes ont accès aux outils. Demandez :

« Dans chaque phase de notre cycle, qui décide, et comment sait-on que le travail est correct? »

Si la réponse est la même qu'il y a deux ans, vous avez de nouveaux outils et un vieux modèle opérationnel.

L'IA peut rendre le travail plus rapide. Seules les personnes peuvent décider de ce que le travail devrait être.