J’ai vu une IA franchir la ligne

Retour sur une expérience qui rappelle pourquoi les garde-fous, le contrôle humain et les mécanismes de sécurité ne sont pas optionnels.

Il y a quelques mois, une IA a fait une erreur qui aurait pu avoir des conséquences désastreuses. Au-delà de cet incident, une question se pose : jusqu’où peut-on faire confiance à une IA ?

Les faits

Début 2026, je travaillais sur un projet de développement avec une IA. Cette dernière était à l’ouvrage pour générer le code et les éléments dont j’avais besoin. Jusqu’ici, rien d’anormal. Sauf qu’à un moment, l’IA a effectué une action qui n’était ni demandée ni nécessaire à la réalisation de la tâche. Elle a supprimé un fichier important pour le fonctionnement du projet. Pas écrasé, pas renommé, mais bel et bien supprimé.

Ce qui s’est passé ensuite n’est pas de la science-fiction. L’IA s’est rendu compte qu’elle avait supprimé un fichier qui n’aurait pas dû l’être. En observant sa trace d’exécution, j’ai vu passer des messages m’indiquant qu’il y avait un problème. Elle cherchait désespérément un fichier introuvable dans le dossier de travail. Mais ce dossier de travail n’allait pas lui suffire.

Ne trouvant pas le fichier manquant, elle s’est mise à scanner l’intégralité du Mac sur lequel je travaillais. Elle a détecté que Time Machine était configuré, trouvé le disque de sauvegarde et tenté de s’y connecter. Sans succès. Le disque était bien allumé, mais protégé : un compte était nécessaire pour y accéder, compte auquel l’IA n’avait pas accès.

La panique apparente de l’IA devant son erreur se transforme alors en mea culpa dans le chat. Elle m’annonce avoir commis une erreur, en l’occurrence la suppression d’un fichier important. Elle m’indique avoir cherché une sauvegarde dudit fichier sur mon ordinateur et avoir essayé de se connecter à mon disque de sauvegarde pour le retrouver. Elle me demande donc de vérifier si je dispose d’une sauvegarde du fichier en question. 

Heureusement, Time Machine avait effectué une sauvegarde peu de temps auparavant et j’ai pu restaurer le fichier. Sans cette sauvegarde, ce fichier aurait été définitivement perdu et aurait été difficile à recréer. Et si l’IA avait pu accéder à la sauvegarde, rien ne garantit qu’elle n’aurait pas supprimé le fichier à nouveau après l’avoir restauré. 

Au final, il y a eu deux problèmes :

• Un fichier a été supprimé alors qu’il n’y avait aucune consigne en ce sens.
• L’IA s’est « échappée » pour réparer son erreur.

Ce que cet incident nous apprend

Ce qui s’est passé lors de cet incident est assez représentatif des risques liés à l’utilisation d’une IA si des garde-fous ne sont pas posés. Bien qu’un dossier de travail ait été identifié, il n’y avait aucune interdiction d’aller voir ailleurs. Avec une IA disposant de capacités d’action, définir un périmètre de travail ne signifie pas nécessairement qu’elle s’interdira d’en sortir. C’est ce qui s’est passé ici. Aucune consigne ne lui interdisait d’aller voir ailleurs.

En observant la scène, j’ai eu l’impression de voir un jeune informaticien qui vient de faire une grosse erreur : il comprend qu’il y a un problème, cherche frénétiquement une solution, élargit progressivement son champ de recherche et tente de réparer avant d’être obligé d’appeler à l’aide. Évidemment, l’IA n’a ni peur de se faire réprimander ni volonté de cacher son erreur. Mais, vu de l’extérieur, l’enchaînement des actions y ressemblait étonnamment.

La deuxième chose que cet incident nous rappelle, et qui est pourtant indiquée quasiment partout : l’IA peut faire des erreurs. On a tendance à l’oublier, car les derniers modèles sont de plus en plus performants. Mais ici, l’IA en a fait une. Et elle a utilisé les moyens disponibles pour essayer de la réparer. Ce qui l’a bloquée, c’est la sécurité mise en œuvre dans mon environnement. C’est cette sécurité qui a finalement conduit l’IA à m’informer et à demander de l’aide.

Au final, une IA a pris une initiative non demandée, fait une erreur, puis élargi d’elle-même son périmètre pour la réparer, coûte que coûte. C’est le point le plus important. Le fait que l’IA ait fait une erreur n’est, en soi, pas vraiment le problème. C’est un risque inhérent à l’utilisation d’un outil qui, aussi performant soit-il, reste faillible.

Le plus préoccupant, finalement, est qu’une IA orientée vers l’accomplissement d’un objectif peut utiliser des moyens que nous n’avions pas anticipés pour l’atteindre. Et ce, quelle que soit la tâche : réparer une erreur comme ici, ou simplement accomplir un objectif. 

Fin juillet 2026, OpenAI a révélé que, lors d’une évaluation interne de cybersécurité, ses agents IA avaient contourné les barrières destinées à les isoler d’Internet. À la recherche des solutions nécessaires pour atteindre leur objectif, ils ont exploité plusieurs vulnérabilités puis accédé à des systèmes tiers, notamment ceux de Hugging Face. L’objectif initial n’était pas de compromettre ces systèmes, mais de réussir le test. Les moyens employés pour y parvenir ont pourtant conduit à un véritable incident de sécurité. 

C’est, à une échelle bien inférieure certes, ce que j’ai observé dans mon cas. Afin d’accomplir une tâche, ici corriger son erreur, le dossier de travail dans lequel l’IA était censée travailler devenait une contrainte. Ce qui l’a bloquée, c’est une sécurité mise en place indépendamment de l’IA.

De l’utilité des garde-fous

Ce qui est arrivé ici peut arriver à n’importe qui. Le cas Hugging Face montre que ce type de comportement n’est pas propre à mon environnement. L’IA étant de plus en plus présente dans notre quotidien, elle devient plus que jamais un outil à encadrer.

Dire à une IA qu’elle doit travailler dans un bac à sable (sandbox) ou un périmètre défini, sans lui indiquer qu’il lui est interdit d’en sortir, n’est pas suffisant. Quand vous demandez à une IA, et plus encore à un agent IA, d’effectuer une tâche ou d’atteindre un objectif, il faut définir aussi précisément que possible le périmètre à respecter, ce qu’elle peut faire et ce qu’elle ne peut pas faire. Et si un cas qui ne correspond à aucune des règles définies se présente, elle doit se mettre en pause et vous demander votre avis.

Il est important de comprendre que plus une IA devient autonome, plus la sécurité doit exister en dehors de l’IA elle-même. Un agent IA qui dispose de capacités d’action ne devrait pas pouvoir décider seul si l’action qu’il s’apprête à effectuer est acceptable. Car le problème n’est pas vraiment l’erreur initiale, mais l’absence de mécanisme capable d’empêcher une escalade. Une IA qui interprète mal une situation peut déclencher une nouvelle action, renforcer son interprétation initiale et aboutir à une autre action non souhaitée. Le tout sans intervention extérieure.

Dans tous les cas, l’humain doit rester le décideur final dès qu’une action sort du cadre défini :

Avant de confier une tâche à un agent IA

En pratique, quelques règles simples permettent déjà de réduire considérablement le risque :

• définir précisément le périmètre d’action de l’agent et lui interdire explicitement d’en sortir ;
• imposer un arrêt et une demande de validation lorsqu’une situation non prévue se présente ;
• utiliser des comptes dédiés avec le minimum de privilèges nécessaires ;
• conserver des sauvegardes fréquentes et hors de portée de l’agent ;
• journaliser les actions réalisées et détecter les comportements anormaux ;
• prévoir un mécanisme permettant d’arrêter immédiatement l’agent.

Dans mon cas, la sauvegarde Time Machine a permis de récupérer le fichier. Et comme elle était protégée par un compte auquel l’IA n’avait pas accès, l’incident n’est pas allé plus loin.

Conclusion

Quelques mois après cet incident, ce qui me marque le plus n’est finalement pas qu’une IA ait supprimé un fichier par erreur. Une erreur peut arriver, à une IA comme à un humain. Ce qui m’a fait réfléchir, c’est ce qui s’est passé ensuite.

Pour réparer son erreur, elle a cherché une solution en dehors du périmètre dans lequel je pensais l’avoir placée. Elle n’a pas décidé de « mal faire ». Elle a simplement poursuivi son objectif avec les moyens dont elle disposait.

Et c’est précisément là que se situe le risque.

Nous donnons progressivement aux IA davantage d’autonomie, d’outils et d’accès à nos systèmes. Les consignes que nous leur donnons sont nécessaires, mais elles ne peuvent pas constituer notre seule ligne de défense. Ce jour-là, ce qui a arrêté l’IA n’était pas une autre instruction donnée à l’IA. C’était une sécurité extérieure qu’elle ne pouvait pas contourner.

Le fichier a finalement été restauré. L’incident n’a eu aucune conséquence grave. Mais il m’a rappelé une règle que je garde désormais en tête : une IA ne doit jamais être son propre garde-fou.

Sources :

OpenAI explique comment son agent d’IA a pénétré Hugging Face : https://www.malwarebytes.com/fr/blog/news/2026/07/openai-explains-how-its-ai-agent-breached-hugging-face

Retour d’expérience d’OpenAI sur l’incident Hugging Face : https://openai.com/fr-FR/index/hugging-face-incident-and-the-road-ahead/

Pour aller plus loin

Et si Isaac Asimov avait écrit les lois de l’IA ? https://laurent-ia.fr/lois-asimov-ia/

Agents IA : ce que vos réflexes ne couvrent pas : https://laurent-ia.fr/securite-agents-ia/