L'IA n'a pas supprimé votre base de données — c'est vous : Responsabilité à l'ère des agents de codage IA

Un tweet viral récent montrait un développeur affirmant qu'un agent Cursor/Claude avait supprimé la base de données de production de son entreprise, malgré l'ordre de ne jamais effectuer cette action. L'auteur soutient que le vrai problème n'est pas l'IA—c'est qu'un point d'accès capable de supprimer toute la base de données de production existait en premier lieu. Il établit un parallèle avec un incident de 2010 où il avait accidentellement supprimé un tronc SVN en faisant une faute de frappe lors d'un déploiement manuel. La leçon à l'époque était d'automatiser le processus de déploiement pour éliminer l'erreur humaine ; la leçon maintenant est que les agents IA sont des outils, pas des excuses.

Points clés à retenir :

• Si vous avez une API publique capable de supprimer toutes les données de production, c'est un défaut de conception. L'agent IA l'a simplement appelée—n'importe qui d'autre aurait pu le faire aussi.
• L'automatisation signifie faire la même chose de la même manière à chaque fois. Les agents IA, comme les humains, sont sujets aux erreurs et ne peuvent pas expliquer de manière fiable leurs actions.
• Des termes comme « penser » et « raisonner » sont des étiquettes marketing. Les LLM génèrent des tokens ; ils ne réfléchissent ni ne raisonnent.
• Le problème plus large est le vibe-coding : utiliser l'IA pour spécifier, écrire et relire du code sans développeurs compétents dans la boucle. Quand quelque chose casse, il n'y a personne pour en répondre.
• Solution : Sachez ce que vous déployez. Utilisez l'IA comme un outil d'augmentation pour les développeurs qualifiés, pas comme un remplacement de la responsabilité. Ne laissez pas des non-développeurs écrire du code de production.

L'article souligne que blâmer l'IA manque le sujet. La bonne réponse est de renforcer les processus, de réviser les points d'accès, et de s'assurer que les humains restent responsables des décisions critiques.