Les nouveaux risques de l'ingénierie logicielle face à l'essor des agents autonomes

Une étude Harness relayée par IT Pro chiffre l'un des corollaires directs de cette transition: 87 % des équipes d'ingénierie ont subi un incident de sécurité lié à un agent au cours des douze derniers mois. Le décalage entre confiance affichée et réalité opérationnelle devient mesurable, et il dépasse le cadre du débat de productivité.

L'inventaire qui ne tient pas

Sur l'échantillon Harness, 77 % des répondants se disent confiants de disposer d'un inventaire complet de chaque agent, serveur MCP et LLM en production. Seulement 44 % parviennent à le vérifier réellement. L'écart est similaire sur la sécurité de bout en bout: 75 % se déclarent confiants, pourtant le taux d'incident dans ce sous-ensemble atteint 88 %, contre 87 % sur la population globale. La confiance n'a donc quasiment aucun lien avec la résilience effective.

Keith Mann, Field CTO et Head of Research chez Harness, rapproche ce schéma de ce qui s'est produit à l'aube du mobile et du cloud: une phase où la gouvernance tarde à rattraper l'adoption. Il insiste sur un point structurel qui change la donne: un agent ne reste pas stable comme un serveur traditionnel. Un contrôle validé en test peut laisser passer une action dangereuse en production, parce que le comportement agentique n'est pas reproductible à l'identique. La vérification doit donc porter sur la variabilité de l'agent, pas sur la simple existence formelle du contrôle.

Gouvernance: les contrôles critiques restent absents

Trois angles morts opérationnels se dégagent du rapport. Sur la prévention: 74 % des équipes estiment que leurs tests détecteraient une défaillance impactant la production, mais 19 % seulement disposent d'un gate automatisé pour bloquer la promotion du code fautif. Sur la réaction: 76 % pensent pouvoir désactiver un agent défectueux en moins de quinze minutes, contre un tiers environ ayant réellement déployé un kill switch. Sur l'impact global: 58 % observent une hausse des incidents en production depuis le déploiement d'agents.

Ce tableau valide la lecture d'Orosz sur la charge croissante des ingénieurs: la surface de contrôle s'élargit sans que l'outillage de gouvernance suive le rythme. Pour les équipes DevSecOps, chaque agent doit être traité comme un composant critique distinct, avec son propre contrat de sécurité, son instrumentation de variabilité et son point de coupure documenté.