Si l’IA existait depuis le début : un code moins cher n’a pas rendu la décision de savoir quoi construire plus facile

Pour la majeure partie de l’histoire du logiciel, la partie coûteuse était la construction. Les équipes passaient des mois à transformer les idées en code fonctionnel, et cette rareté a façonné tout ce qui concerne l’organisation du travail.

Les feuilles de route étaient planifiées en fonction de la capacité d’ingénierie disponible ; les architectes ont gagné leur place à la table parce qu’ils comprenaient les systèmes que personne d’autre ne comprenait ; les responsables de produit passaient leurs semaines à traduire les demandes commerciales vagues en quelque chose que un développeur pouvait mettre en œuvre. Écrire du logiciel était le goulet d’étranglement, et naturellement, l’écriture était là où se trouvait la force de levier.

Cela n’est plus vrai, et le changement s’est produit plus vite que la plupart des dirigeants d’ingénierie n’ont eu le temps de le comprendre.

Les outils de codage IA ont réduit le coût de la mise en œuvre. Ainsi, le travail qui prenait à une équipe d’ingénieurs des semaines prend maintenant à un agent quelques heures. Et l’hypothèse évidente était que la construction plus rapide se traduirait directement par une valeur livrée plus rapidement.

Cependant, ce qui s’est réellement passé est plus compliqué : les équipes peuvent maintenant produire plus de logiciels qu’elles ne savent pas quoi en faire, et la chose qui les ralentit a silencieusement changé de place.

« Vous ne pouvez pas appliquer l’IA à un processus cassé », a déclaré Pablo Gamba, responsable de la technologie Amériques chez intive, une startup de solutions logicielles et d’IA. « C’est comme donner une pelle plus rapide à un travailleur. Il travaillera plus vite, mais seulement dans la mauvaise direction. »

Exécution plus rapide, même contrainte

Chaque grande inflexion dans la technologie – l’Internet, le cloud et l’externalisation – a suivi une forme identique. Quelque chose qui coûtait cher est devenu bon marché presque du jour au lendemain, et tout ce qu’une entreprise avait construit sur l’hypothèse de ce coût a dû être détruit et reconstruit.

Cette fois, la chose qui devient moins chère, c’est l’intelligence technique appliquée elle-même, qui se trouve être exactement ce pour quoi les sociétés de services et les équipes d’ingénierie ont passé des décennies à facturer, affirme Gamba.

L’exécution moins chère ne fait pas disparaître la contrainte, cependant. Elle la déplace simplement vers un endroit moins visible. Le goulet d’étranglement du codage, par exemple, en migrant vers l’amont, a accéléré la mise en œuvre, mais l’obstacle est maintenant dans la révision de code. Automatiser la révision de code et il apparaît dans les tests et le déploiement ; automatiser cela également, et finalement, il atterrit sur les humains qui écrivent les spécifications que les agents sont en train de traiter.

Parce qu’un agent ne peut construire que ce qui a été décrit avec suffisamment de précision pour agir sans deviner.

C’est le piège dans lequel beaucoup d’équipes sont en train de tomber en ce moment, souvent sans s’en rendre compte. Si vous pouvez construire presque tout en une fraction du temps qu’il fallait auparavant, le coût de construction de la mauvaise chose augmente, et non diminue, car vous découvrirez que vous vous trompiez plus vite et avec plus de choses déjà expédiées.

Une hypothèse qui utilisait pour émerger lentement, au fil des semaines de codage manuel, peut maintenant devenir une infrastructure porteuse avant que quiconque ne pense à la remettre en question. La priorisation, et non la production brute, se retrouve à décider si l’investissement dans l’IA paie réellement.

Dans ce paradigme, Gamba pense que les entreprises devraient suivre non la vitesse de développement, mais le cycle complet allant de l’intention à la production. « Si vous améliorez la vitesse de développement mais que les tests QA sont votre goulet d’étranglement, vous atteignez simplement les tests QA plus rapidement. Ensuite, vous réparez les tests QA et le goulet d’étranglement se déplace vers les exigences », a-t-il déclaré.

Les chiffres le confirment également. Les entreprises du Fortune 50 utilisant le développement assisté par IA expédient des validations 3 à 4 fois plus rapidement que leurs pairs, selon une étude de la Cloud Security Alliance, mais introduisent de nouvelles conclusions de sécurité à un rythme d’environ dix fois supérieur.

La vitesse sans destination claire, dans ce sens, ne gaspille pas seulement les efforts ; elle accumule le risque plus rapidement que la plupart des équipes de sécurité ne peuvent suivre.

Intégrer les exigences dans un langage que l’IA peut réellement exploiter

Si la définition est là où se trouve réellement la contrainte, la solution n’est pas plus de documentation. C’est une documentation différente, écrite sous une forme qu’un système d’IA peut exécuter sans combler les lacunes de son propre chef.

Cela signifie abandonner le document d’exigences rédigé pour qu’un humain l’interprète avec jugement et le remplacer par des critères d’acceptation structurés, des modèles de domaine explicites et des tests de contrat qui indiquent clairement ce qu’une fonctionnalité ne doit pas faire, ainsi que ce qu’elle doit faire.

Les agents, après tout, combleront l’ambiguïté de la même manière qu’un jeune ingénieur le ferait, avec une supposition confiante. La différence est que la supposition de ce dernier est entourée d’une certaine hésitation, d’un signal à un collègue senior, d’un sentiment que quelque chose pourrait ne pas aller.

La supposition d’un agent ne ressemble à rien de tout cela. Elle apparaît comme du code propre, fluide et entièrement formé, et il n’y a pas de réserve dedans, même lorsqu’il est faux.

Écrire une spécification suffisamment précise pour survivre à cet écart commence à ressembler moins à la rédaction d’un brief de produit et plus à la rédaction d’un contrat. Vous nommez chaque acteur, mappez chaque transition d’état que le système est autorisé à effectuer et prenez en compte les cas de bordure au lieu de les laisser silencieusement sur le chemin heureux, comme la plupart des documents d’exigences le font encore.

Les équipes qui traitent cela comme une corvée de documentation apprennent à leurs dépens que l’intention vague ne produit que du logiciel vague à une vitesse machine.

Les équipes qui capturent réellement les gains de productivité sont celles qui traitent l’écriture de spécifications comme une discipline d’ingénierie à part entière, avec le même contrôle de version, les mêmes cycles de révision et la même rigueur de test que celle qui était réservée au code lui-même.

Selon les mots de Gamba, l’IA native n’est pas la permission de sauter le processus, mais une exigence de le réaménager à partir de zéro. « De nombreuses organisations tentent d’appliquer l’IA à des processus anciens. Ce n’est pas une transformation. Les organisations IA natives commencent par une question différente : si l’IA existait depuis le début, comment concevrions-nous ce processus aujourd’hui ? »

Responsables de backlog, conservateurs d’intention

Le produit, l’architecture et l’ingénierie fonctionnaient autrefois comme trois fonctions distinctes avec des passes mains propres entre elles : le produit décide de ce qui doit être construit, l’architecture découvre comment, l’ingénierie l’expédie.

Une fois que la mise en œuvre devient bon marché et rapide, ces passes mains se transforment en la partie la plus lente de la chaîne. Ce qui compte ici, c’est qui peut tenir l’image entière à la fois, traduire l’intention en quelque chose qu’un agent peut exécuter et attraper une mauvaise hypothèse avant qu’elle ne se transforme en code expédié que personne ne voulait.

Ce réaménagement façonne silencieusement qui définit et ce que le travail est vraiment.

« Pensez à ce qui arrive au rôle de l’ingénieur logiciel. Ils n’écrivent plus seulement du code. Ils supervisent la production des agents, définissent les spécifications, préparent les tests, valident les résultats. C’est fusionner ce qui était autrefois trois rôles distincts en un », a déclaré Gamba.

En d’autres termes, ce qui a de la valeur maintenant, ce n’est pas savoir écrire un ticket ou exécuter un sprint. C’est savoir à quoi ressemble « le meilleur » avant même que le travail ne commence, être capable de faire la différence entre ce qui est intellectuellement intéressant et ce dont les clients ont réellement besoin, et avoir le courage de tuer une idée rapidement lorsqu’elle ne correspond clairement pas à cette barre.

Ces appels de jugement qui étaient autrefois distribués sur un responsable de produit, un architecte et un responsable technique comparant des notes sont de plus en plus souvent attribués à qui est le plus proche de la définition du travail en premier lieu.

Et il vaut la peine de se rappeler : rien de tout cela ne fait disparaître les titres. Mais les lignes entre eux deviennent de plus en plus difficiles à défendre, tandis que les personnes qui prospèrent dans ce flou sont celles qui agissent en tant que conservateurs d’intention.

Exécution rapide sans garde-fous n’est pas une victoire

Il y a un risque qui est facile à perdre de vue une fois que l’intention est claire et que le pipeline IA est réellement en marche : l’exécution rapide et bien définie peut toujours introduire des défaillances que le processus plus lent et plus humain aurait attrapé presque par accident.

Les chiffres ici ne sont même pas proches. Les tests de printemps 2026 de Veracode sur les modèles de pointe ont constaté que seulement 55 % des tâches de génération de code produisaient une sortie sécurisée lorsque aucune directive de sécurité explicite n’était fournie, un chiffre qui n’a pratiquement pas bougé en deux ans, même si la précision fonctionnelle a considérablement augmenté.

Il est clair que faire les choix syntaxiques corrects a cessé d’être la partie difficile il y a un certain temps. Les appels de jugement qu’un ingénieur humain faisait instinctivement en tapant, autour de la sécurité, de la conformité et de ce que les données devraient et ne devraient pas toucher quel système, sont les parties qui sont difficiles à remplacer.

Cela signifie que la même rigueur appliquée pour définir ce qui doit être construit doit s’étendre pour définir ce qui est hors limites, comme les frontières de conformité, les règles de traitement des données et les contraintes éthiques indiquées avec la même soin que les exigences fonctionnelles.

Laisser ces éléments implicites et espérer qu’un agent les infère correctement est la même erreur que laisser les exigences de produit vagues et croiser les doigts pour que la construction se passe bien.

À quoi ressemble le leadership

Rien de tout cela ne plaide contre le développement accéléré par l’IA ; la construction n’a jamais été plus rapide ou moins chère, et il n’y a pas de moyen de remettre cela dans la bouteille.

Cependant, ce qui n’est pas devenu plus facile, et qui est même devenu plus difficile, c’est décider avec une précision réelle de ce qui vaut la peine d’être construit, de le décrire suffisamment bien pour qu’une machine puisse l’exécuter fidèlement et de tracer les lignes qu’elle n’est pas autorisée à franchir pendant ce processus.

À l’échelle de l’entreprise, les équipes qui prennent les devants ne sont pas celles qui ont les agents de codage les plus rapides, cela est clair. Ce sont celles qui ont compris, avant leurs concurrents, que la définition allait toujours être le problème le plus difficile – et qui ont commencé à la traiter comme telle.