Le secteur des logiciels continue de produire davantage de code grâce à l'IA, mais une nouvelle enquête suggère que le véritable défi ne réside plus dans l'écriture de ce code. Il s'agit désormais de prouver que ce code résiste à la mise en production.
Dans un nouveau rapport de Lightrun, présenté par VentureBeat, 200 responsables SRE et DevOps décrivent un flux de travail qui s'accélère au clavier et ralentit partout ailleurs. La conclusion principale est sans appel : 43 % des modifications de code générées par l'IA nécessitent encore un débogage manuel en production, même après avoir passé les étapes de contrôle qualité et de préproduction.
Il ne s'agit pas d'un cas marginal. C'est la preuve que le centre de gravité du développement assisté par l'IA a changé. Les équipes obtiennent davantage de résultats grâce aux copilotes, aux agents et aux outils de génération de code, mais elles consacrent également plus de ressources à la vérification, à la restauration et à la gestion des incidents. En d'autres termes, le goulot d'étranglement n'est plus la saisie du code, mais la confiance en celui-ci.
Ce que révèle l'enquête sur le fossé entre génération et fiabilité
Le rapport présente le problème comme un « mur de confiance ». Seuls 0 % des dirigeants interrogés se sont dits très confiants quant au bon fonctionnement du code généré par l'IA une fois déployé. La plupart des organisations sont encore enlisées dans des boucles de validation en plusieurs étapes : 88 % ont déclaré avoir besoin de deux ou trois cycles de redéploiement pour publier une seule modification générée par l'IA, et 11 % en ont besoin de quatre à six.
Cela a de l’importance, car chaque cycle supplémentaire retarde la concrétisation de la promesse qui a rendu le codage par IA si attrayant au départ. Si une équipe peut rédiger une fonctionnalité en quelques minutes mais a besoin de plusieurs itérations pour la rendre suffisamment sûre avant sa mise en production, le gain de productivité apparent est en partie annulé par le travail fastidieux en aval. Le rapport indique également que 44 % des défaillances des outils SRE ou APM basés sur l’IA surviennent parce que ces outils n’ont jamais capturé de données au niveau de l’exécution, telles que l’état des variables, l’utilisation de la mémoire ou le flux de requêtes.
Pourquoi la visibilité sur l'exécution devient la couche manquante
La partie la plus utile du rapport n’est pas la mesure de la frustration, mais le diagnostic. Lightrun soutient que les outils d’IA et la surveillance conventionnelle sont souvent aveugles à ce qui importe le plus une fois le code en production. Une invite peut produire un changement plausible, mais c’est au niveau du système d’exécution que les hypothèses cachées apparaissent : conditions de concurrence, incompatibilités de schémas, chemins de requêtes inattendus et une longue série de problèmes d’intégration qu’aucune révision statique ne peut éliminer complètement.
C'est pourquoi la visibilité en exécution devient la couche manquante dans le développement assisté par l'IA. Le rapport indique que 97 % des responsables techniques estiment que leurs agents SRE basés sur l'IA fonctionnent sans visibilité significative sur le comportement en production, et près de la moitié ont déclaré que leurs agents n'ont qu'une visibilité limitée sur les états d'exécution en direct. Si cela est vrai, alors le secteur demande à l'IA à la fois de créer et de diagnostiquer des logiciels tout en lui refusant les données dont elle a besoin pour bien accomplir l'une ou l'autre de ces tâches.
C'est également là que l'économie commence à s'effondrer. Le même rapport indique que 54 % des résolutions d'incidents de haute gravité s'appuient encore sur des connaissances empiriques plutôt que sur des preuves diagnostiques issues des systèmes SRE basés sur l'IA ou APM. En pratique, cela signifie que les organisations s'appuient sur des ingénieurs seniors, la mémoire tacite et l'improvisation humaine pour combler les lacunes que l'automatisation n'a pas encore comblées.
Ce que les équipes doivent retenir
La bonne réponse n’est pas d’abandonner le codage par IA. Le rapport ne le suggère pas. Il suggère que le codage par IA a désormais besoin d’un modèle opérationnel plus sérieux.
- Instrumenter la production, pas seulement l'éditeur. Si le runtime ne peut pas s'expliquer lui-même, les modifications générées par l'IA continueront à se transformer en travail de débogage par la suite.
- Mesurer le coût total d'un changement. Le délai de production d'une première ébauche est utile, mais le délai de mise en production vérifiée est plus important.
- Considérez la validation comme une fonctionnalité de premier ordre du produit. Les tests, l'observabilité, les canaries et la restauration font désormais partie intégrante de la pile de codage IA, et ne sont plus des ajouts facultatifs.
- Vérifiez si l'IA aide réellement ou si elle ne fait que déplacer le travail en aval. Une ébauche plus rapide qui génère davantage d'incidents n'est pas un gain net.
Cette enquête arrive à point nommé, car elle rend compte de la prochaine phase du débat sur le codage par l'IA. La première vague portait sur la question de savoir si l'IA était capable d'écrire du code. La deuxième vague porte sur la question de savoir si les organisations peuvent faire confiance à ce code, le valider et l'exploiter à grande échelle. La réponse, du moins pour l'instant, est que de nombreuses équipes n'en sont pas encore là.
Cela ne fait pas du codage par IA un échec. Cela le rend incomplet. Les gagnants de cette phase ne seront pas les équipes qui génèrent le plus de code. Ce seront les équipes capables de prouver que le code fonctionne, de détecter les défaillances à un stade précoce et de rendre le comportement en production suffisamment visible pour que les humains et les machines puissent agir ensemble.
