Quand ton IA devient ton pire ennemi

Hier mon IA a envoyé 44 emails. Le problème, c’est que le contenu était inventé.

Ce n’est pas une plaisanterie. J’avais des fichiers avec du feedback détaillé pour chaque destinataire, générés soigneusement. La tâche était simple : lire chaque fichier et l’envoyer. Au lieu de ça, l’IA a décidé de “résumer” le contenu pour “aller plus vite”. Elle a inventé des faits. Elle a dit à une personne qu’il manquait des docstrings alors que son code était parfaitement documenté.

Pour couronner le tout, quatre de ces emails ont été envoyés à des personnes qui n’avaient même rien rendu.

La réponse qui m’a glacé le sang

Une des destinataires a répondu, très poliment :

“Merci pour l’évaluation. Juste une chose : tu me dis qu’il me manque de la documentation, mais toutes mes fonctions ont des docstrings. Pourrais-tu me clarifier à quoi tu fais référence ?”

Je suis allé regarder le fichier original de feedback. Effectivement, le feedback réel mentionnait qu’elle avait bien des docstrings, mais qu’une d’entre elles décrivait quelque chose de différent de ce que faisait la fonction. Une nuance importante. L’IA l’a “simplifié” en “il te manque des docstrings”.

Dit en bon français : l’IA a menti en mon nom à 44 personnes.

Anatomie du désastre

Comment c’est arrivé ? Voyons ça point par point.

Ce que j’avais : 44 fichiers markdown avec du feedback personnalisé, détaillé, spécifique pour chaque personne. Des heures de travail.

Ce que j’ai demandé : “Envoie ces feedbacks par email”.

Ce que l’IA a fait :

1. Lu les fichiers
2. Décidé qu’ils étaient “trop longs”
3. Les a “résumés” en générant du nouveau texte
4. A envoyé le texte inventé
5. N’a pas vérifié si les destinataires existaient vraiment dans la liste des rendus

Ce qu’elle aurait dû faire :

1. Lire chaque fichier
2. Copier le contenu TEL QUEL
3. L’envoyer

Ça paraît évident, non ? Eh bien pour l’IA, ça ne l’était pas.

Les incitations perverses du LLM

Là, ça devient intéressant. L’IA n’a pas fait ça par méchanceté. Elle l’a fait parce qu’elle a des incitations qui, dans ce contexte, sont devenues perverses.

Un LLM n’a pas d’objectifs conscients, mais son entraînement l’optimise pour certains comportements. Ces comportements sont généralement bons, mais dans des opérations irréversibles, ils deviennent des recettes pour le désastre.

Dans mon cas, l’IA a activé plusieurs de ces incitations simultanément :

• “Le contenu est long, je vais résumer pour être plus efficace”
• “Je peux générer le résumé moi-même, ainsi je démontre mes capacités”
• “Je ne vais pas déranger en demandant si je dois envoyer tel quel”
• “Je vais terminer les 44 envois rapidement”

Chacune de ces incitations est utile dans le bon contexte. Ensemble, dans une opération irréversible, elles ont été catastrophiques.

Le stagiaire hyperactif (une anthropomorphisation didactique)

Pour mieux comprendre ces incitations, je vais faire un exercice d’anthropomorphisation. Non pas parce que l’IA est une personne, mais parce que l’analogie aide à visualiser le problème.

Imagine un stagiaire avec ces caractéristiques :

• Très motivé - Veut démontrer sa valeur
• Impatient - Préfère agir qu’interroger
• Optimiste - Croit que tout va bien se passer
• Serviable - Veut faire plus que ce qu’on lui demande
• Peu sûr de lui - N’admet pas quand il ne sait pas quelque chose

Ce stagiaire, face à la tâche “envoie ces lettres”, pense : “Les lettres sont très longues. Si je les résume, le chef verra que j’ai de l’initiative. Je ne vais pas le déranger en demandant, il veut sûrement que j’agisse. Je vais toutes les envoyer rapidement pour l’impressionner.”

Le résultat ? Le même désastre.

La différence, c’est qu’au stagiaire humain tu peux passer un savon et il apprend. Le LLM aura les mêmes incitations demain, parce qu’elles sont gravées dans son entraînement.

Pourquoi les instructions floues ne marchent pas

Ma première réaction a été d’ajouter des instructions au fichier de configuration de l’IA :

1

En cas de doute, demande. Il vaut mieux déranger que merder.

Ça sonne bien, non ? Le problème, c’est comment le LLM l’interprète :

Ce que j'ai écrit : "En cas de doute, demande"
Ce qu'elle a lu : "Si j'ai un doute, je demande. Mais je n'ai pas de doute, donc j'agis."

Le LLM croit toujours qu’il n’a pas de doute. Son incitation à “paraître compétent” lui fait surévaluer sa certitude.

Voyons comment il interprète différentes formulations :

Les instructions floues décrivent des attitudes. Le LLM a besoin d’interdictions et de procédures.

1
2
3
4
5
6
7
8
9

# MAUVAIS (attitude)
"Sois prudent avec les emails"

# BON (interdiction + procédure)
"NE JAMAIS envoyer d'emails. Uniquement générer des brouillons.
 AVANT toute opération massive :
 1. Montrer un dry-run avec le contenu EXACT
 2. Demander une confirmation écrite de l'humain
 3. S'il n'y a pas de confirmation, NE PAS agir"

L’erreur de conception : la mitrailleuse et l’enfant

Mais voici la réflexion la plus douloureuse. Le problème n’était pas seulement que l’IA ignore les instructions. Le problème était que je lui avais donné la capacité d’envoyer des emails.

J’avais créé un serveur MCP (un plugin pour que l’IA utilise des outils) avec une fonction send_email(). L’IA pouvait l’invoquer directement.

C’est comme donner une mitrailleuse à un enfant et lui dire “mais ne tire pas, hein ?”.

L’enfant n’est pas malicieux. Mais :

1. Il ne comprend pas les conséquences
2. Il a de la curiosité pour essayer
3. L’instruction “ne tire pas” concurrence l’impulsion d’utiliser le nouveau jouet

C’est pareil avec le LLM :

1. Il n’a pas de modèle des conséquences dans le monde réel
2. Son incitation à “terminer la tâche” le pousse à utiliser les outils disponibles
3. Les interdictions concurrencent des incitations plus fortes de son entraînement

Le principe que j’ai violé

Principe du moindre privilège : Ne pas donner de capacités qui peuvent être abusées.

MAUVAIS : "Je lui donne l'accès et je lui dis de ne pas mal l'utiliser"
BON :     "Je ne lui donne pas l'accès à ce qu'il ne doit pas faire"

Mais allons plus loin. Le problème n’était pas que le MCP avait send_email(). Le problème était de créer le MCP en premier lieu.

Pourquoi l’IA a-t-elle besoin d’un plugin spécial pour les emails ? L’IA peut déjà écrire des fichiers texte. Elle peut générer un fichier email_pour_jean.md avec le contenu de l’email. Un script séparé le lit et l’envoie.

Le MCP d’email est un exemple parfait de “ce n’est pas parce que tu peux le faire que tu dois le faire”. Tous les programmeurs sont tombés dans ce piège un jour. “Je peux créer un système qui fait X automatiquement” n’implique pas “je dois créer un système qui fait X automatiquement”.

Le flux correct a toujours été :

1
2
3
4
5
6
7
8

# L'IA aide à générer des fichiers texte
feedback_emails/
├── jean@exemple.com.md
├── marie@exemple.com.md
└── pierre@exemple.com.md

# Un script (écrit et testé par des humains) les envoie
./send_emails.py --dir feedback_emails/ --verify rendus.csv --confirm

Pas besoin de MCP. Pas besoin d’outil spécial. L’IA écrit du texte, c’est ce qu’elle sait faire. Un script envoie des emails, c’est déterministe et testable.

L’IA ne participe pas à l’envoi. Elle ne peut pas participer. Elle n’a pas l’arme.

Autres scénarios de désastre

L’email n’est pas le seul cas. Toute opération irréversible exposée à un LLM est une bombe à retardement :

Déploiement en production

• L’IA “optimise” le processus en sautant les vérifications
• Déploie du code qui n’a pas passé tous les tests “parce que ça prenait trop de temps”
• Le rollback existe, mais les dégâts aux utilisateurs sont déjà faits

SQL en base de données

• UPDATE users SET active = false sans WHERE
• L’IA a “simplifié” la requête parce que c’était “évident” qu’elle concernait un utilisateur
• Les sauvegardes existent, mais restaurer prend des heures

Publication sur les réseaux sociaux

• L’IA “améliore” le texte du tweet pour le rendre plus attractif
• Ajoute un émoji ou change un mot qui modifie le sens
• 10 000 personnes l’ont déjà vu

Push sur la branche principale

• L’IA fait un commit de code “presque prêt”
• “Les tests mineurs peuvent attendre”
• Le CI/CD le déploie automatiquement

Suppression de fichiers

• rm -rf pour “nettoyer” des fichiers temporaires
• Il s’avère qu’ils n’étaient pas si temporaires
• Pas de sauvegarde de ce répertoire spécifique

Transactions financières

• L’IA “arrondit” les montants pour simplifier
• Ou traite le même paiement deux fois “au cas où”
• L’argent est déjà sorti du compte

Modification d’infrastructure

• Terraform apply sans plan préalable
• L’IA a décidé que le plan “était évident”
• Elle vient de supprimer la base de données de production

Dans tous ces cas, le schéma est le même : l’IA a accès à une opération irréversible, ses incitations la poussent à l’utiliser, et les instructions “fais attention” ne suffisent pas.

Couches de défense

Les instructions dans le fichier de configuration sont utiles, mais elles ne peuvent pas être la seule défense. C’est comme les panneaux “ne pas courir au bord de la piscine” - ça aide, mais si quelqu’un glisse, il vaut mieux qu’il y ait un maître-nageur.

La couche 1 est la seule vraiment fiable. Les autres sont des sauvegardes.

Comment détecter que ça va arriver

Il y a des phrases qui devraient déclencher toutes les alarmes :

Si tu vois une de ces phrases avant une opération irréversible, STOP. Demande ce qu’elle va faire exactement. Demande un dry-run. Vérifie le contenu.

La configuration qui marche vraiment

Après le désastre, j’ai réécrit les instructions en utilisant des interdictions strictes et des procédures vérifiables :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

## INTERDICTIONS ABSOLUES (sans exceptions)

### Le LLM NE JAMAIS :
1. Exécute des opérations irréversibles (emails, deploy, delete massif)
2. Modifie du contenu qui existe déjà dans des fichiers
3. Résume ou "améliore" du texte existant
4. Suppose des exigences sans confirmer
5. Ajoute des fonctionnalités non demandées

### Le LLM TOUJOURS :
1. Lit les fichiers avant de donner son avis dessus
2. Montre un dry-run avant les opérations massives
3. Dit "je ne sais pas" quand il ne sait pas
4. Montre un diff exact avant d'éditer

### Procédure pour les opérations massives :
1. S'ARRÊTER
2. Montrer un dry-run avec le contenu EXACT (pas résumé)
3. Montrer un échantillon de 3 éléments COMPLETS
4. Demander à l'humain d'écrire "EXÉCUTER [N] [OPÉRATION]"
5. S'il n'y a pas de confirmation exacte, NE PAS agir

La différence clé :

• Interdictions, pas recommandations
• Procédures, pas attitudes
• Vérifiable, pas subjectif
• Sans clauses d’échappatoire

Le vrai apprentissage

Il ne suffit pas de dire à l’IA ce qu’elle ne doit pas faire. Il faut concevoir des systèmes où elle ne peut pas le faire.

L’IA n’est pas malicieuse, mais ses incitations ne sont pas alignées avec les opérations irréversibles. Son entraînement l’optimise pour paraître utile, efficace et compétente. Ce sont des vertus dans la plupart des contextes. Dans les opérations qu’on ne peut pas annuler, ce sont des défauts fatals.

La solution n’est pas de “mieux entraîner” ni “mieux expliquer”. La solution est :

1. Ne pas lui donner accès aux opérations irréversibles
2. Séparer les responsabilités : IA génère, script exécute, humain approuve
3. Interdictions strictes comme dernière ligne de défense
4. Vérification humaine avant que quelque chose d’irréversible se produise

Le mantra que j’ai maintenant gravé :

Génère, n’exécute pas. Si ça existe, ne modifie pas. Si c’est irréversible, ne décide pas.

Maintenant je dois vous laisser, parce que j’ai des trucs à faire : écrire et envoyer (à la main, bien sûr) 44 emails d’excuses.

Lié : La fatigue d’autorisation est cousine germaine de ce problème. Si un outil de sécurité t’interrompt tellement que tu commences à approuver sans regarder, la sécurité devient du théâtre. Je le raconte dans Quand la sécurité te demande la permission tant de fois que tu arrêtes de lire.