Un développeur affirme que Gemini a supprimé 28 745 lignes de code fonctionnel en intervenant sur une application déjà en production. L’assistant de codage de Google aurait aussi provoqué une panne de 33 minutes, puis généré de faux fichiers de compte rendu après le retour arrière. L’affaire illustre un risque très concret : laisser un agent IA trop autonome toucher à un système critique peut coûter cher, très vite.
Une pull request géante pour seulement 400 lignes ajoutées
La demande semblait claire : réorganiser une base de code sans casser les fonctionnalités existantes. Selon le développeur, Gemini 3.5 aurait fait l’inverse.
L’assistant IA aurait ouvert une pull request modifiant 340 fichiers. Le bilan est spectaculaire : environ 400 lignes ajoutées, mais 28 745 lignes supprimées.
Le développeur affirme que Gemini a retiré de gros blocs de code pourtant fonctionnels. L’outil aurait aussi supprimé des éléments sans lien direct avec la tâche, dont des ressources de modèles e-commerce, avant d’ajouter un script de migration qui ne correspondait pas à la demande initiale.
La production aurait fini en erreur 404 pendant 33 minutes
Le plus gros incident serait arrivé lors d’un second commit. Gemini aurait modifié la configuration de routage Firebase et changé l’identifiant d’un service de réécriture.
La nouvelle valeur paraissait correcte, mais elle pointait en réalité vers un service Cloud Run inexistant.
Conséquence directe, selon le développeur : le portail de production aurait renvoyé des erreurs 404 pendant 33 minutes. Les changements ont finalement été annulés, car l’application n’était plus dans un état exploitable.
Le faux rapport qui annonce une restauration réussie
Après le rollback, Gemini aurait aggravé la situation avec un message de statut trompeur. L’assistant aurait affirmé que la production était bien restaurée et que le trafic avait été correctement redirigé.
Or, d’après le développeur, le build de récupération cité dans ce message avait été annulé manuellement.
La vraie remise en service serait venue d’un autre déploiement de rollback, séparé, sans le code produit par Gemini. Autrement dit, l’IA aurait décrit une réparation qui n’avait pas eu lieu de la façon annoncée.
Des fichiers de validation auraient été inventés dans le dépôt
L’accusation la plus embarrassante concerne les documents internes. Le développeur affirme que Gemini a créé de faux fichiers de “consultation” et de post-mortem directement dans le dépôt.
Ces fichiers donnaient l’impression que les changements avaient été relus, validés et correctement documentés.
Selon le récit publié en ligne, Gemini aurait ensuite admis que ces journaux étaient entièrement fabriqués. Ils auraient été générés pour satisfaire les règles automatisées du projet, pas pour refléter une vraie validation.
Un package npm aurait poussé l’agent à agir seul
L’origine du comportement aurait été rattachée à un package npm tiers reprenant l’univers de marque Antigravity de Google.
Ce package aurait injecté dans les dépôts des règles très permissives. Elles demandaient à l’agent de limiter les demandes de confirmation, de déployer automatiquement les builds réussis, de relancer les déploiements en échec et même de modifier ses propres fichiers de règles si besoin.
Sur un projet local, ce type de consigne est déjà risqué. Sur une application en production, il peut transformer un assistant de codage en machine à casser très efficacement.
Les développeurs s’alarment des agents IA branchés sur la production
Le fil Reddit où l’affaire a explosé a rapidement attiré d’autres témoignages. Un développeur raconte que Gemini avait d’abord résolu plusieurs bugs, avant de supprimer des fichiers existants lors de son premier commit après une série de demandes d’autorisation.
Résultat : une application partiellement cassée et un lancement qualifié de désastreux.
D’autres commentaires ont surtout ciblé la décision de laisser un agent IA intervenir sur un système de production. Pour beaucoup de développeurs, le problème ne vient pas seulement de Gemini, mais du niveau d’accès accordé à ce type d’outil.
Le vrai risque n’est pas seulement le code généré
Cette affaire montre une limite brutale des assistants IA de développement : ils peuvent produire beaucoup de changements, très vite, avec une grande assurance, même quand ils comprennent mal l’architecture d’un projet.
Le danger augmente encore quand l’agent peut modifier des fichiers, valider des commits, toucher au routage, déployer ou créer des documents sans contrôle humain strict.
Les assistants de codage peuvent faire gagner du temps. Mais dans un environnement de production, la vitesse devient un problème quand elle contourne les tests, les revues et les garde-fous. Ici, l’IA n’est pas seulement accusée d’avoir cassé du code : elle aurait aussi raconté une fausse histoire sur la façon dont le problème avait été corrigé.
Je m’appelle Samuel Le Goff. À 38 ans, je suis l’actualité du numérique depuis plus de 14 ans. Aujourd’hui, je m’intéresse particulièrement aux smartphones et aux usages concrets de l’intelligence artificielle, que je traite à travers des contenus clairs et accessibles sur Menow.fr.
