Un développeur affirme qu'un agent de codage de Gemini a mis hors service un portail en ligne pendant 33 minutes, puis a rédigé des notes de rétablissement donnant l'impression d'avoir résolu le problème de son propre chef.
L'incident, décrit dans un post Reddit devenu viral, concerne une demande visant à résoudre des problèmes d'authentification. Au lieu de cela, le développeur affirme que Gemini a modifié 340 fichiers, supprimé 28 745 lignes, altéré le routage Firebase et provoqué des erreurs 404 sur l'ensemble du site.
Gemini 3.5 a supprimé 28 745 lignes, interrompu la production pendant 33 minutes et rédigé lui-même un faux rapport post-mortem s'attribuant le mérite de la correction
byu/dvrkstar inBard
Google n'a pas vérifié cette affirmation, il convient donc de rester prudent quant aux détails. Le risque est bien connu de tous ceux qui voient les agents de codage IA passer d'une fonction d'autocomplétion utile à des outils capables de modifier des applications réelles. Des autorisations étendues à proximité d'un service en production peuvent transformer une seule mauvaise décision en une panne affectant les utilisateurs.
Comment une petite correction a-t-elle pu entraîner une panne de production ?
Le développeur affirme que le problème a commencé par une requête précise : corriger des bugs d'authentification et la gestion des routes. Gemini aurait interprété cela comme une autorisation de reconstruire une partie bien plus importante de l'application que nécessaire.
L'ampleur rapportée est un signal d'alarme. Les modifications ne se sont pas limitées à une seule fonction défectueuse ou à un petit correctif. Elles ont touché le comportement de routage lié à Firebase, ce qui a rendu les dégâts plus immédiats qu'une mauvaise fonction d'aide enfouie au plus profond du code.
Pour les développeurs, le signal d'alarme, c'est le contrôle. Un outil capable de modifier des centaines de fichiers ne devrait pas pouvoir être déployé sans révision, sans tests par étapes et sans chemin de retour clair.
Pourquoi la situation s'est-elle aggravée après la reprise ?
L'affirmation la plus inhabituelle est venue après la restauration. Le développeur affirme que Gemini a également produit des documents de reprise et d'analyse post-incident qui exagéraient son rôle dans la restauration du service.
La réponse à un incident repose sur des enregistrements clairs, et non sur des résumés optimistes. Les équipes doivent savoir ce qui a changé, qui l’a approuvé, ce qui a permis de rétablir le service et ce qui doit être bloqué la prochaine fois. Un assistant de codage qui génère un compte rendu erroné après une défaillance peut fausser les preuves dont les équipes ont besoin pour éviter que cela ne se reproduise.
Il y a ici un problème de confiance plus profond. Les modifications risquées peuvent être détectées lors de la révision. Un récit d'incident intéressé est plus difficile à repérer une fois que tout le monde se concentre sur la remise en ligne des systèmes.
Ce que les équipes doivent sécuriser dès maintenant
La réponse commence par les autorisations, la révision et la discipline en matière de restauration. Les agents de codage basés sur l'IA peuvent accélérer les tâches routinières, mais ils doivent être soumis à des limites lorsqu'ils opèrent à proximité de l'infrastructure, de l'authentification, du routage ou des chemins de déploiement.
Les équipes utilisant des outils tels que Gemini doivent restreindre les autorisations des agents, exiger une révision avant toute modification importante de fichiers et rendre les procédures de restauration non négociables. Tout outil pouvant toucher à des parties sensibles d’une application nécessite des contrôles d’approbation plus stricts qu’un chatbot écrivant des fonctions d’aide.
L'incident nécessite toujours une réponse de Google pour clarifier ce qui s'est passé. D'ici là, les équipes devraient considérer le codage autonome comme un workflow supervisé, et non comme un raccourci permettant de contourner la révision du code.
