AI a scellé le capot
Depuis l’avènement du moteur à combustion interne, les ateliers de réparation automobile pouvaient réparer presque n’importe quoi pour n’importe quelle marque avec des outils basiques. Puis est venue la modernisation : les moteurs à injection de carburant ont pris le relais.
De la même manière que les moteurs à injection de carburant ont remplacé les pistons, bougies d’allumage et carburateurs, garantissant que personne ne regarde sous le capot de sa voiture, le codage par IA remplace la possibilité de maintenance du code, et non son existence. Maintenant, personne ne regarde vraiment ses applications web.
Les risques associés
Le risque que du mauvais code apparaisse partout est un aspect du problème. Mais le risque plus profond est la perte des compétences fondamentales en matière de maintenance et de service du code. Il n’y a pas de composants remplaçables sur le terrain lorsque tout est une machine Rube Goldberg usée de fonctions et de bibliothèques logicielles qui peuvent fonctionner lors du déploiement, mais deviennent ensuite ingérables et difficiles à maintenir.
Les applications fonctionnent, mais de moins en moins de personnes savent vraiment pourquoi ou comment. Comme l’a exploré Pirsig dans son livre Zen and the Art of Motorcycle Maintenance, lorsque nous perdons notre relation avec la machinerie sous-jacente, nous perdons également notre connexion à la qualité elle-même. Cette perte de serviceabilité n’est pas seulement incommodante. C’est une nouvelle forme de risque.
Des preuves concrètes
Selon l’état de l’IA en sécurité et développement d’Aikido en 2026, une organisation sur cinq a déjà subi un incident sérieux dû à du code généré par IA. Près de 70 % ont découvert des vulnérabilités introduites par des assistants IA.
Lorsque l’IA introduit un défaut, personne ne sait qui porte la responsabilité. Lorsqu’on demande qui serait finalement responsable d’une violation causée par l’IA, les réponses sont partagées entre l’ingénierie, la sécurité et le fournisseur, signe clair que la gouvernance n’a pas suivi l’automatisation.
Implications pour les développeurs
Les ingénieurs en début de carrière travaillent désormais presque entièrement au niveau d’abstraction. Ils livrent du code plus rapidement, mais avec beaucoup moins d’exposition aux systèmes, réseaux ou modes de défaillance. Cela affaiblit le jugement humain nécessaire pour remettre en question la sortie de l’IA avant qu’elle n’atteigne la production.
Le code généré par l’IA est un amplificateur des valeurs fondamentales et de la culture de sécurité d’une organisation. Si l’organisation a un bon ADN de sécurité, les outils IA amélioreront cette culture. Mais si une organisation manque de discipline et de gestion des risques de base, le développement de logiciels autonomes reflétera cette culture de sécurité immature.
Quand les algorithmes échouent
Prenons l’exemple d’une entreprise de trading propriétaire qui commence une expérience de trading agentique. Lorsque l’algorithme échoue, l’entreprise perd de l’argent. Peu de discussions ont lieu parce qu’il s’agissait d’une expérience utilisant leur propre capital. Maintenant, augmentons les enjeux.
Une entreprise de santé donne des conseils via des cliniciens. Plus d’une organisation cherche à exploiter les LLM comme des personnages non-joueurs (NPC) chuchotant aux professionnels de santé lors des discussions d’admission des patients. On peut être sûr qu’il y aura des reproches lorsqu’un patient subit un résultat inattendu en partie dû à un algorithme non déterministe. Qui est responsable des blessures ou des pertes de vie ? L’entreprise qui a écrit l’algorithme ? L’équipe QA ? Le professionnel de santé ?
La question de l’assurance
Je n’ai entendu que des rires nerveux en mentionnant l’assurance pour les pertes causées par l’IA agentique. Pourtant, il semble logique pour les assureurs de créer une couverture pour la négligence, les violations de la propriété intellectuelle et les responsabilités réglementaires. L’assurance de responsabilité en IA devra croître à mesure que des incidents se produiront.
Nous sommes familiers avec les systèmes IVR nous demandant de “presser deux pour l’espagnol”. Maintenant, imaginez des systèmes demandant de “presser un pour tuer tout le monde”. L’industrie de l’assurance ne se calmera pas tant que des cas de violation des droits d’auteur ne seront pas jugés. Les LLM sont essentiellement une violation de droits d’auteur en tant que service.
La dégradation de la qualité du codage
Mais revenons à la racine de ce problème. Les développeurs juniors ne sont pas tant remplacés que leur travail change. Les analystes SOC débutants surveillent les algorithmes pour déterminer si les événements de journal sont malveillants. Les stagiaires en marketing produisent des présentations sans designers graphiques.
Le terme “slop” est appliqué aux sorties des LLM avec une intention péjorative. Pour le monde de l’art, cela doit sembler une insulte. L’art et le design existent dans un dialogue constant avec le passé, réagissant à des mouvements antérieurs avec un goût cultivé. Maintenant, les visualisations sont réduites à des esthétiques banales, produites sans effort et dépourvues de respect.
Nous assistons à l’équivalent en développement logiciel de cette même dégradation. Quelqu’un a écrit que nous pouvons être augmentés par l’IA ou nous y abdiquer. Mais l’abdication suggère de renoncer à un trône de responsabilité. Beaucoup d’utilisateurs de codage par IA n’ont jamais atteint cette position au départ.
Sprawl des outils
La recherche d’Aikido montre que les équipes ayant subi des incidents de sécurité utilisaient plus d’outils de fournisseurs que celles qui n’en ont pas. Pourtant, le cycle se répète : de nouveaux problèmes de sécurité sont inventés à résoudre. Certains outils sont le problème à votre problème. Certains remèdes sont pire que la maladie.
Je dis à mes étudiants en cybersécurité quelque chose d’hérétique : il existe deux types de professionnels de la sécurité. Certifiés et qualifiés. Avec une fine tranche de chevauchement dans le diagramme de Venn. Je préfère le talent qualifié. Beaucoup de certifiés ne comprennent pas comment l’internet fonctionne.
Le fossé entre la politique et la pratique
Un auditeur SOC2 recherche le delta entre la politique écrite et la technique pratiquée. Si vous publiez une politique stockant des données clients sur un bucket S3 accessible au public et que c’est ce que vous faites, alors il n’y a pas de scrupules de la part de l’auditeur. Pourquoi ? SOC2 n’est pas une certification. C’est l’opinion d’un comptable sur la question de savoir si vous suivez vos politiques.
Vous pouvez vous retrouver dans de beaux draps concernant vos politiques et procédures de deux manières : des politiques parfaites qui ne peuvent pas être appliquées ou aucune politique écrite du tout. De nombreuses entreprises passent de cette dernière à la première sans comprendre pourquoi elles ont tant de découvertes. Il faut donc se méfier de demander à un LLM d’écrire vos politiques, car elles peuvent souvent être “trop bonnes” ou avancées par rapport à votre technique et capacités d’application réelles.
Les questions que les conseils devraient poser
Les conseils devraient demander : “Pouvez-vous me montrer exactement où le code généré par l’IA fonctionne actuellement en production et qui est responsable de son comportement ?”
Les CISOs doivent répondre : “Nous pouvons identifier chaque instance de code généré par l’IA, suivre qui l’a approuvé, démontrer comment il a été examiné et expliquer quelles garde-fous l’ont empêché d’atteindre des systèmes à haut risque.”
Si vous ne pouvez pas répondre à cette question, vous n’avez pas de gouvernance. Vous avez de la fiction bien écrite.