Le développement assisté par IA ajoute du travail de correction

Les gains de productivité liés à l’IA rendent visibles les coûts de gouvernance

Une productivité d’ingénierie plus élevée peut s’accompagner de coûts plus importants pour la gouvernance logicielle : examiner, approuver et maintenir les logiciels qu’une organisation utilise. Les recherches d’ActiveState ont montré que 93 % des répondants signalaient une amélioration de la productivité de l’ingénierie, tandis que 83 % indiquaient que la productivité des développeurs progressait plus vite que la gouvernance. Pour les responsables technologiques qui évaluent le développement assisté par l’IA, la question financière est de savoir où se reporte le travail supplémentaire, car la sécurité, la conformité et les opérations peuvent absorber des coûts qui n’apparaissent pas dans un calcul de productivité de l’ingénierie.

Cette recherche provient d’ActiveState, qui a un intérêt commercial à ce que les organisations investissent dans la gouvernance de l’open source : la gestion de logiciels dont le code est accessible à d’autres pour être utilisé et modifié. Intitulée « AI software development adds hidden governance costs », elle a interrogé 307 responsables de la sécurité, de la gouvernance, des plateformes et de l’ingénierie, et comprenait 10 entretiens approfondis avec des praticiens. Elle portait sur des organisations de 1 000 employés ou plus en Amérique du Nord et en Europe occidentale, ce qui définit le cadre organisationnel de ses conclusions.

Dans ce cadre, la confiance dans la montée en charge reste élevée : 71 % des répondants à l’enquête d’ActiveState estimaient que leur approche actuelle pouvait passer à l’échelle. Pourtant, cette confiance peut coexister avec une pression sur la gouvernance, car produire davantage de logiciels et en gérer les conséquences exigent des capacités distinctes. Évaluer le retour du développement assisté par l’IA suppose donc de relier la production de l’ingénierie au travail qui en découle.

Un développement plus rapide augmente le volume de dépendances

Le travail de gouvernance supplémentaire commence avec les composants que les développeurs sélectionnent. Une dépendance est un composant logiciel externe qu’une application utilise, et 94 % des répondants dans l’étude d’ActiveState ont déclaré que l’IA avait accru leur consommation de logiciels open source. Davantage de composants signifie davantage de décisions en matière de sécurité, d’approbation et de maintenance ; ainsi, une génération de code plus rapide augmente aussi le volume de logiciels que les équipes doivent gouverner.

Les alertes de sécurité déclenchent souvent ces décisions : ActiveState a constaté que 63 % traitent les vulnérabilités open source seulement après qu’un scanner ou un outil de sécurité les a identifiées. Un composant entre dans le développement, un outil détecte ensuite une faiblesse, puis une équipe revient pour la corriger. L’examen peut aussi prendre du retard sur le déploiement, la moitié des répondants indiquant que de nouvelles dépendances peuvent atteindre la production, l’environnement dans lequel les applications s’exécutent, sans examen ni approbation préalables.

Ces pratiques créent deux problèmes de contrôle : les équipes doivent corriger des faiblesses dans des composants déjà sélectionnés, et certains composants atteignent des applications en cours d’exécution avant que quiconque décide de les accepter ou non. ActiveState soutient que l’IA accélère à la fois la génération de code et l’acheminement des composants open source vers la production, alors que la gouvernance dépend encore largement d’un scan ultérieur. Le développement peut donc progresser avant que l’examen et la correction n’aient lieu.

Les reprises consomment des capacités sur des budgets distincts

Lorsque l’examen intervient plus tard, certaines conséquences apparaissent sous forme de reprises côté ingénierie. ActiveState estime que le développement assisté par l’IA génère plus de 13 900 heures de reprise d’ingénierie par an dans les grandes entreprises, chaque ingénieur consacrant au moins 139 heures par an à corriger ou revisiter un travail assisté par l’IA. Son exemple d’une main-d’œuvre de 100 ingénieurs situe la charge de travail annuelle à environ sept équivalents temps plein. Cela mesure une capacité d’ingénierie consommée ; cela ne représente pas un besoin réel de recrutement, une dépense comptabilisée ou une économie garantie.

Ce coût en capacité peut coexister avec une productivité plus élevée, car les ingénieurs peuvent produire davantage avec l’assistance de l’IA tout en passant aussi du temps à corriger le résultat. Une évaluation de l’ingénierie doit donc prendre en compte à la fois la production initiale et l’effort nécessaire pour rendre le travail exploitable. La reprise constitue une partie de cet équilibre ; la sécurité, la conformité et les opérations assument des responsabilités supplémentaires sur leurs propres budgets.

Abby Kearns, Chief Executive Officer chez ActiveState, relie ces budgets distincts à la difficulté de voir le coût total. Elle préconise de prendre les décisions d’acceptation au moment où les composants entrent dans la base de code, l’ensemble du code utilisé pour créer et maintenir une application. Sa recommandation s’aligne également sur l’intérêt commercial d’ActiveState à stimuler la demande en gouvernance de l’open source.

« L’IA devient un élément permanent de la manière dont les logiciels sont développés, mais notre recherche a montré que les ingénieurs passent un temps considérable à corriger ou à revisiter un travail assisté par l’IA. Ce n’est que la part de l’ingénierie. La sécurité, la conformité et les opérations paient le reste sur leurs propres budgets, de sorte que la facture complète reste cachée. Pour préserver les gains, il faut gouverner l’open source dès son entrée dans la base de code », a déclaré Kearns.

Les conclusions d’ActiveState sur l’estimation des coûts montrent comment les organisations prennent actuellement en compte le risque plus large : seules 31 % avaient formellement quantifié le coût du risque open source non géré, tandis que 47 % disposaient d’une estimation informelle. Ces pourcentages décrivent la manière dont les coûts sont évalués. Ils ne mesurent pas les montants dépensés. La quantification formelle et les estimations informelles donnent également aux dirigeants des niveaux de détail différents lorsqu’ils décident de l’allocation des ressources.

La portée de ces estimations est importante, car le risque open source non géré dépasse les reprises liées au développement assisté par l’IA. Une évaluation combinée doit relier les coûts entre l’ingénierie, la sécurité, la conformité et les opérations tout en maintenant ces catégories distinctes. Les dirigeants peuvent alors évaluer les coûts d’exploitation sans attribuer chaque problème open source à l’IA ni considérer les seules reprises d’ingénierie comme le bilan global de productivité.

Les défaillances des dépendances affectent la livraison, la conformité et la sécurité

Les conséquences opérationnelles signalées rendent plus claire la nécessité de relier ces budgets. ActiveState a constaté que 76 % des répondants avaient subi un retard de livraison logicielle causé par des dépendances open source non gérées au cours de l’année écoulée. La gestion des dépendances influe donc sur le moment où les équipes peuvent livrer des logiciels, ce qui étend son impact métier au-delà des heures passées à écrire et à revisiter du code.

Parallèlement aux retards de livraison, le travail de conformité mobilise lui aussi du temps des équipes. Dans l’enquête d’ActiveState, 58 % ont déclaré avoir reçu une observation de conformité ou d’audit liée à la gouvernance de l’open source. Le traitement de ces constats implique des équipes chargées de vérifier si le développement respecte les exigences de l’organisation ; ainsi, le travail découlant de logiciels créés par les ingénieurs peut relever du budget d’un autre département.

Les incidents de sécurité ajoutent une autre conséquence opérationnelle : 32 % des répondants à l’enquête d’ActiveState ont confirmé un incident au cours des deux dernières années pouvant être attribué à une dépendance non gérée. Séparément, 83 % ont déclaré que le coût global de gestion du risque open source augmentait. Cette mesure du coût suit l’évolution des dépenses de gouvernance, tandis que le constat précédent sur la productivité concerne la vitesse à laquelle la gouvernance suit le rythme du développement.

Chaque mesure décrit une partie différente de l’environnement opérationnel dans lequel l’IA introduit davantage de dépendances. Les retards de livraison couvrent l’année écoulée, les incidents de sécurité couvrent les deux dernières années, et les constats de conformité constituent une mesure distincte. Maintenir ces catégories séparées en préserve le sens : elles décrivent des conséquences existantes en matière de livraison, de conformité et de sécurité, tandis que l’IA augmente le flux de composants nécessitant une attention.

Des contrôles plus précoces modifient le moment où les dépendances sont acceptées

Dans ce contexte opérationnel, Kearns propose de déplacer les décisions d’acceptation au moment où l’open source entre dans le développement. Un examen plus précoce permet aux équipes de décider si un composant est acceptable avant qu’il ne progresse vers le déploiement. Cela modifie l’endroit où les contrôles s’exercent dans le processus de développement, tandis que les scans ultérieurs continuent de traiter les faiblesses découvertes après la sélection.

Les répondants à l’enquête d’ActiveState se sont également prononcés en faveur d’un effort accru de prévention avant le déploiement. Ils ont indiqué que 26 % de l’effort actuel de gouvernance de l’open source y était consacré, contre 37 % qu’ils jugent appropriés. Ces chiffres expriment leur allocation préférée de l’effort ; évaluer ce changement suppose d’examiner comment des décisions plus précoces affectent le travail d’examen, de correction et d’exploitation que les équipes réalisent actuellement.

Le problème de timing est également au cœur de l’explication de Jim Mercer, Program Vice President, Software Development, DevOps, and DevSecOps chez IDC. Le DevOps relie le développement aux opérations logicielles, tandis que le DevSecOps intègre la sécurité à ce travail. Mercer décrit comment un assistant IA peut sélectionner un composant, générer le code qui l’utilise et faire progresser le résultat vers le déploiement avant qu’un examen ultérieur ne le rattrape.

« Lorsqu’un assistant peut suggérer un package sécurisé, écrire le code qui l’appelle et l’acheminer vers la production en quelques minutes, une gouvernance fondée sur un scan statique a posteriori aura toujours un temps de retard », a déclaré Mercer. Sa référence à quelques minutes illustre la rapidité de cette séquence. Le scan statique examine le code sans l’exécuter ; son moment d’intervention détermine donc s’il éclaire la sélection du composant ou déclenche du travail une fois la sélection déjà effectuée.

Pour combler cet écart de timing, Mercer recommande de contrôler ce qui entre dans le pipeline, la séquence par laquelle le code progresse vers le déploiement : « Être capable de contrôler ce qui entre dans le pipeline est essentiel pour permettre aux organisations de faire passer à l’échelle le développement assisté par l’IA. » Comme Kearns, il place les décisions relatives aux dépendances plus tôt dans le développement. Les équipes peuvent évaluer ce changement en suivant le travail d’examen, de correction et d’exploitation requis après l’acceptation d’un composant.

Principaux enseignements pour les dirigeants

• Mesurer la productivité entre les fonctions : ActiveState a constaté que 93 % des répondants signalaient des gains de productivité de l’ingénierie, tandis que 83 % indiquaient que la productivité progressait plus vite que la gouvernance. Les CTO qui évaluent le retour de l’IA doivent inclure le travail qui en résulte dans l’ingénierie, la sécurité, la conformité et les opérations.
• Examiner l’augmentation du volume de dépendances : l’IA a accru la consommation d’open source pour 94 % des répondants, et la moitié a indiqué que de nouvelles dépendances pouvaient atteindre la production sans examen préalable. Les responsables des plateformes et de la sécurité peuvent utiliser les enregistrements d’approbation des dépendances pour identifier les points où des composants entrent en production sans contrôle.
• Prendre en compte les reprises sur l’ensemble des budgets : ActiveState estime que les ingénieurs consacrent au moins 139 heures par an à revisiter un travail assisté par l’IA. Les responsables financiers et de l’ingénierie doivent relier ce coût en capacité au travail de sécurité, de conformité et d’opérations financé séparément afin d’évaluer le retour complet.
• Suivre séparément les conséquences opérationnelles : des dépendances non gérées ont causé des retards de livraison pour 76 % des répondants au cours de l’année écoulée, tandis que 32 % ont signalé un incident de sécurité lié sur deux ans. Les responsables de la livraison et de la sécurité ont besoin de mesures distinctes pour ces résultats afin d’établir une base de référence à mesure que l’IA augmente le volume de dépendances.
• Avancer les décisions d’acceptation : les répondants ont alloué 26 % de l’effort de gouvernance à la prévention avant le déploiement, contre 37 % qu’ils jugeaient appropriés. Les responsables des plateformes peuvent tester un examen plus précoce des dépendances et suivre son effet sur le travail en aval de correction, d’approbation et d’exploitation.