Je pense que mon sentiment, sincèrement, c’est que l’IA change tellement les compétences requises pour le développement que beaucoup d’ingénieurs, même seniors, ne sont plus qualifiés pour faire ce boulot.
L’IA a mis à nu des processus foireux, une sécurité médiocre et une hygiène de repo et de déploiement déplorable, avec une ampleur et une profondeur qu’on n’avait jamais vues. L’industrie n’était pas prête, et ne l’est toujours pas.
Je suis ça de très près, depuis le premier post « Gemini a bouffé la prod » l’année dernière, et le schéma que je vois, c’est que presque tous ces cas auraient pu être évités si les ingénieurs avaient été... tout simplement de meilleurs ingénieurs.
Le nombre de fois où Claude a réussi à déprovisionner une base de données de production comme ça, tout en détruisant les sauvegardes, n’est pas la preuve d’une malveillance de l’IA, confession ou non.
Dans tous les cas, c’est une erreur humaine.
Prenez ce cas :
Claude n’avait pas les clés, alors il les a cherchées dans le sandbox de l’utilisateur.
Il les a trouvées, parce que l’utilisateur avait laissé traîner assez d’autorité non sécurisée pour assassiner toute l’entreprise.
Les sauvegardes étaient servies depuis la même instance que la base de données.
C’est arrivé assez souvent pour que ce soit un réglage foireux du fournisseur. Mais, d’un autre côté, c’est absolument quelque chose que l’utilisateur aurait dû remarquer et reconfigurer.
Si vos sauvegardes sont servies depuis le même volume que celui que vous sauvegardez... vous n’avez pas de sauvegardes.
Le truc, c’est que Claude n’aurait jamais dû être en position de toucher au provisionnement. Permettre à un agent de gérer tout un pipeline CI/CD de A à Z avec des permissions élevées et un accès en temps réel est purement et simplement irresponsable.
Le cas PocketOS, c’est un mille-feuille d’incompétence.
Et le pire, c’est qu’ils n’ont rien appris. Première réaction : demander à Claude de confesser ses torts, et publication immédiate sur X.
Alors ça va presque certainement recommencer.