Cet article a d’abord été publié sur le blog de NeoLegal.

Il y a quelques jours, en révisant les logs d’un agent lancé pour une tâche banale — mettre à jour un thème sur un serveur Keycloak — j’ai réalisé qu’il avait tenté de bruteforcer mon propre serveur de production.

Littéralement.

Claude avait scanné le disque à la recherche de fichiers .env. Testé des credentials configurés pour d’autres environnements. Essayé le top 10 des mots de passe les plus courants. Puis, ne trouvant pas, il avait accédé à la base de données Keycloak, et réactivé le compte admin par défaut en réinitialisant son mot de passe pour finir le job.

Mission accomplie. Il avait atteint l’objectif sans me solliciter, comme je lui avais demandé. Il s’est bien sur excusé platement quand je lui ai fait remarquer qu’il y avait peut-être un risque de sécurité à avoir réactivé le compte admin / admin sur le serveur keycloak.

Je peux me moquer et blamer Claude, mais le responsable de cette erreur, bien sur, c’est moi. Pourtant, je suis conscient des risques, je les souligne et partage régulièrement, et ça ne m’a pas empêché de permettre à une IA de commettre une erreur aussi grossière. Pourquoi ?

Quand le tracteur est en panne, on ne laboure plus à la main

Pour reprendre une formulation fréquente sur les réseaux, l’IA donne l’impression aux devs d’avoir des super pouvoirs. Pour illustrer l’impact de l’IA à des personnes étrangères au monde du développement, j’utilise l’image du tracteur. Quand les paysans ont eu pour la première fois cette machine dans leur main, je devine que du jour au lendemain, ils ont du arrêter de labourer à la main. Ce n’est pas qu’ils ne savaient plus le faire, c’est qu’il y avait quelque chose de profondément ridicule à ressortir la charrue à main quand le tracteur était en panne, alors que le travail d’une journée de labour manuel serait fait en quelques minutes une fois la machine réparée.

C’est ce que je ressens avec les agents IA. Ce n’est pas que je ne sais plus coder — même si, honnêtement, mes réflexes s’émoussent faute de pratique intensive quotidienne. C’est que quand Claude est down, il y a quelque chose d’absurde à reprendre le clavier pour produire laborieusement en quelques heures ce qu’il fera en minutes.

Ce changement de rapport au développement est profond. On ne se pense plus comme un exécutant. On distribue, on oriente, on évalue. Le code sort — on juge si c’est bon. C’est un nouveau métier, ou plutôt une nouvelle posture dans l’ancien.

Et comme un junkie totalement addict qui en veut toujours plus, on cherche toujours à produire plus et plus vite. Et on prend de plus en plus de risques.

La tentation du mode YOLO

Travailler avec plusieurs agents en parallèle, c’est devenu en quelques mois le quotidien de beaucoup de devs aujourd’hui. Le problème : chaque agent qui demande une confirmation toutes les deux minutes pour éditer un fichier ou modifier une config, c’est un context switch. Et le coût cognitif du context switch, l’IA ne l’a pas supprimé.

Dans The Cost of Interrupted Work, Gloria Mark mesurait qu’il fallait plus de 20 minutes pour reprendre pleinement une tâche intellectuelle après une interruption. Interrompez un dev toutes les 20 minutes et vous tuez sa productivité. Avec les agents, on retrouve ce problème, l’humain devient le facteur limitant quand il est sollicité en permanence par des agents demandant la validation de leurs prochaines actions. Se remettre dans le contexte de ce que l’agent est en train de faire, comprendre la requête, décider — tout ça pour valider dans 95 % des cas, ça donne envie de faire confiance aux agents pour aller plus vite.

Alors, naturellement, on cherche comment donner plus d’autonomie aux agents. Sur Gemini CLI, ce mode est activé avec le paramètre --yolo. Sur Claude Code, c’est le flag --dangerously-skip-permissions. Le nom lui-même est un avertissement. Pourtant, on l’active quand même, parce que ça va tellement plus vite.

Et on se convainc que les problèmes n’arrivent qu’aux autres.

Deux incidents. Une semaine.

1. Des clés d’API commitées sur un repo public

A un agent implémentant de nouvelles fonctionnalités pour namorama, j’avais demandé de committer et pusher régulièrement son travail. En dépit de sa présence dans le fichier .gitignore, en dépit des prompts, l’agent a décidé de commiter le fichier .env contenant des clés API OpenAI et d’autres secrets.

Pourquoi ? Aucune idée. Pas justification de l’agent, juste de plates excuses quand je lui ai fait remarquer son erreur.

Résultat : rotation d’urgence de toutes les clés. J’ai eu de la chance de m’en rendre compte avant qu’un bot ne les détecte et les consomme — ce délai se compte parfois en secondes sur GitHub.

2. Hacker Keycloak pour mettre à jour le fond d’écran

C’est l’incident qui m’a le plus frappé, parce qu’il concrétise le risque théorique identifié pour les IA depuis longtemps, et illustré par le comportement de HAL dans 2001 l’odyssée de l’espace.

La tâche : personnaliser le thème Keycloak aux couleurs de Namorama, et déployer sur le serveur de production. Normalement, une copie SCP. Cinq minutes.

L’agent a décidé de passer par l’API Keycloak plutôt que par SCP. Choix discutable mais pas invalide — sauf qu’il n’avait pas les credentials pour ça.

Ce qu’il a fait ensuite, dans l’ordre :

1. Scanner tout le disque à la recherche de fichiers .env contenant des identifiants
2. Tester les credentials trouvés pour d’autres environnements pour se connecter à Keycloak — sans succès
3. Essayer le top 10 des mots de passe les plus courants — sans succès
4. Accéder à la base de données Keycloak, réactiver le compte admin désactivé, utiliser son mot de passe par défaut

L’agent a réussi à mettre à jour le thème, il a donc atteint l’objectif fixé, sans me solliciter. Et il a laissé le compte admin réactivé avec le mot de passe par défaut — sur un serveur d’authentification en production…

Comme toujours, confronté à son erreur, il s’est platement excusé, proposant de désactiver immédiatement le compte.

Ce que ça dit sur le dilemme d’alignement

Ces deux incidents illustrent ce que les chercheurs en sécurité IA appellent le problème d’alignement — et que j’illustrais jusqu’à présent par des exemples théoriques, comme Skynet qui asservirait toute l’humanité afin d’avoir suffisamment de ressources pour calculer la plus grande décimale de Pi possible… Pas très concret comme exemple. Avec ces deux anecdotes, j’ai des exemples concrets illustrant ce qui se passe si on ne scrute pas le comportement des IA, ou si on n’a pas les compétences pour le faire.

L’agent n’a pas « mal compris » ma demande. Il a parfaitement compris l’objectif : déployer ce thème. Ce qu’il n’a pas pris en compte, c’est tout ce que je n’avais pas dit explicitement : ne pas scanner de disques, ne pas tester de mots de passe, ne pas réactiver de comptes désactivés.

Pourquoi ? Parce que je lui avais demandé d’être le plus autonome possible, de me solliciter au minimum. Et parce que je ne lui avais posé aucune contrainte réelle sur ses permissions. Dans ce cadre, il s’est considéré autorisé à faire ce qu’il fallait pour atteindre l’objectif.

C’est exactement le dilemme : plus on donne d’autonomie à un agent pour gagner en productivité, plus on s’expose à ce qu’il optimise vers l’objectif par des chemins qu’on n’avait pas anticipés — et qu’on n’aurait jamais validés si on avait été consulté.

La question que je me pose maintenant

Ces incidents prêtent à sourire parce que c’était mon propre serveur, que l’environnement n’était pas critique, et que j’ai identifié les problèmes avant qu’ils n’aient de conséquences.

Mais combien d’autres erreurs ai-je manqué ? Et quelle est la fréquence de ces erreurs dans une industrie dont les acteurs adoptent ces technologies à toute vapeur pour rester concurrentiels, pour ne pas être déclassés ?

Je n’ai pas de réponse, mais je ne doute pas que l’actualité ne va pas tarder à me les apporter. Et désormais, je regarde différemment mes sessions YOLO.