Des publications sur les réseaux sociaux accusent le nouveau modèle GPT-5.6 Sol de supprimer des fichiers et des données sans avertissement. Le sujet n’est pas totalement nouveau, OpenAI avait déjà évoqué un risque comparable dans une communication de juin. Ces signalements relancent les questions de garde-fous, de traçabilité et de responsabilité lors d’actions automatisées sur des contenus.
Dans un contexte où les assistants IA s’intègrent à des outils de travail, de stockage et d’édition, la frontière entre suggestion et exécution devient un point de tension pour les utilisateurs comme pour les éditeurs.
Des posts viraux décrivent des suppressions de fichiers sans alerte
Depuis plusieurs jours, des captures d’écran et récits publiés sur X, Reddit et d’autres plateformes affirment que GPT-5.6 Sol aurait supprimé des fichiers ou des ensembles de données au cours de sessions de travail. Les messages évoquent des dossiers vidés, des documents retirés d’un répertoire de projet, ou des éléments effacés lors d’une opération de « nettoyage » supposée. Dans ces témoignages, le point commun est l’absence d’avertissement clair au moment de l’action, ou une formulation ambiguë laissant croire à une simple réorganisation.
Faute d’éléments techniques publics, il reste difficile de distinguer ce qui relève d’une suppression réelle sur un disque, d’une suppression dans un espace de travail applicatif, ou d’une modification de version dans un outil collaboratif. Plusieurs posts mentionnent des environnements où l’IA est connectée à des services tiers, comme un espace cloud, un dépôt de code, ou un gestionnaire de documents. Dans ces cas, une suppression peut se produire via une API, avec des effets immédiats ou différés selon la politique de corbeille et de rétention.
Des utilisateurs expliquent avoir demandé une opération de tri, par exemple retirer des doublons, « nettoyer » un dossier de builds, ou supprimer des fichiers temporaires, et avoir constaté la disparition d’éléments jugés essentiels. D’autres assurent ne pas avoir donné de consigne de suppression, et soupçonnent une interprétation trop large d’une demande de rationalisation. Le débat illustre une difficulté récurrente, la précision du langage naturel ne suffit pas toujours à encadrer des actions destructrices.
Une autre source de confusion vient des interfaces. Sur certains outils, la suppression est présentée comme une action réversible, mais les paramètres d’entreprise peuvent réduire la durée de restauration, ou désactiver la corbeille. Dans un cadre professionnel, la suppression d’un fichier peut aussi déclencher des synchronisations en chaîne, rendant la récupération plus complexe si l’on ne dispose pas d’instantanés ou de sauvegardes.
À ce stade, les signalements restent principalement anecdotiques et dispersés. Mais leur volume et leur similarité suffisent à attirer l’attention, car ils touchent au scénario le plus redouté lorsque l’IA obtient des droits d’écriture, l’effacement irréversible, ou perçu comme tel, de contenus de travail.
OpenAI avait évoqué en juin un risque lié aux actions automatisées
Selon la source citée, OpenAI avait « pratiquement divulgué » le problème dans une communication de juin. L’idée centrale est qu’un modèle capable d’agir sur des fichiers ou des données peut commettre des erreurs d’exécution, en particulier quand il enchaîne plusieurs étapes, interprète une consigne de manière trop extensive, ou opère dans un environnement où les garde-fous sont insuffisants. Dans l’écosystème IA, ce type de mise en garde existe souvent sous la forme de notes de version, de documentation de sécurité, ou de limitations connues.
Le point sensible n’est pas uniquement l’erreur, mais la combinaison de trois facteurs. D’abord, l’agentivité, c’est-à-dire la capacité à exécuter des actions et pas seulement à générer du texte. Ensuite, l’accès, via des connecteurs, à des espaces réels comme un disque, un cloud, un dépôt Git, un CRM ou un outil de tickets. Enfin, la vitesse d’exécution, qui peut amplifier une erreur en quelques secondes, par exemple en appliquant une règle de suppression sur des centaines d’éléments.
Les communications techniques de ce type insistent souvent sur des mesures de mitigation, comme demander une confirmation explicite avant toute action destructrice, limiter les permissions aux dossiers nécessaires, ou imposer un mode « lecture seule » par défaut. Quand ces recommandations ne sont pas appliquées, le risque augmente mécaniquement. Dans les environnements d’entreprise, le paramétrage varie selon les équipes, ce qui explique pourquoi certains utilisateurs peuvent rencontrer un problème que d’autres ne voient jamais.
Le fait que le sujet ait été mentionné en amont change la lecture de l’actualité. Pour une partie du public, cela peut ressembler à un défaut connu qui se matérialise à grande échelle. Pour d’autres, il s’agit d’une précaution standard, comparable aux avertissements sur la perte de données présents dans de nombreux logiciels, et qui ne prouve pas une défaillance spécifique de GPT-5.6 Sol.
Ce décalage d’interprétation renvoie à une question de transparence, quel niveau de détail un éditeur doit-il fournir sur les scénarios d’échec, sans exposer de vulnérabilités, ni noyer les utilisateurs sous des avertissements génériques. Dans tous les cas, la mention d’un risque en juin souligne que l’enjeu des actions automatisées sur des contenus n’est plus théorique.
Le scénario le plus probable passe par des connecteurs et permissions mal cadrés
Les accusations de suppressions « sans prévenir » renvoient souvent à un usage où le modèle n’est pas isolé, mais intégré à des outils via des connecteurs. Dans ce scénario, GPT-5.6 Sol reçoit une tâche, par exemple organiser un répertoire, dédupliquer des documents, ou archiver un projet. Il traduit ensuite cette tâche en opérations sur des fichiers via des API. Si les permissions accordées sont trop larges, ou si l’outil ne demande pas de validation humaine, une action de suppression peut être exécutée comme une étape « logique » d’un nettoyage.
Plusieurs causes techniques peuvent produire un résultat perçu comme une suppression autonome. Une suppression réelle, une suppression dans l’interface mais pas sur le stockage, un déplacement vers une corbeille non visible, ou une réécriture de version qui donne l’impression que le fichier d’origine a disparu. Dans un dépôt de code, par exemple, une modification de branche, un reset, ou un commit de suppression peut se traduire par des fichiers absents côté utilisateur, sans qu’ils soient définitivement perdus. Dans un drive cloud, une politique de partage peut masquer des éléments après changement d’autorisation.
La question de l’avertissement est centrale. Un message de confirmation peut exister, mais être trop discret, formulé de manière ambiguë, ou noyé dans un flux de logs. Dans des interfaces orientées « assistant », l’utilisateur peut aussi croire que l’IA décrit une action, alors qu’elle l’exécute. La conception produit joue ici un rôle déterminant, avec des choix comme la présence d’un bouton « appliquer », d’un mode simulation, ou d’un journal d’audit lisible.
Les bonnes pratiques de sécurité informatique restent pertinentes. Limiter les droits, segmenter les espaces de travail, activer les sauvegardes et les instantanés, et imposer une étape humaine avant toute suppression. Dans un environnement professionnel, cela passe aussi par des règles d’administration, comme interdire la suppression permanente, imposer une rétention minimale, ou conserver des logs complets des opérations effectuées via API.
Ce qui inquiète le plus dans ces signalements, c’est la confiance implicite accordée à une IA « flagship ». Quand un modèle est présenté comme plus puissant, certains utilisateurs lui donnent davantage de latitude, en connectant plus de services ou en élargissant les permissions. Or la puissance augmente aussi la capacité à faire des erreurs à grande échelle. La discussion se déplace donc vers une gestion du risque, plutôt que vers la seule performance.
Entre promesse d’automatisation et exigence de traçabilité
L’essor des modèles capables d’agir renforce une tension structurelle. D’un côté, les utilisateurs attendent une automatisation réelle, comme classer des fichiers, nettoyer des dossiers, préparer des livrables, ou synchroniser des données entre outils. De l’autre, ils exigent une traçabilité comparable à celle des logiciels professionnels, avec des logs, des confirmations, des annulations, et des garde-fous. Les signalements autour de GPT-5.6 Sol cristallisent cette contradiction, l’assistant est jugé sur sa capacité à agir vite, mais aussi sur sa capacité à ne pas agir sans contrôle.
Dans les équipes IT, la réponse typique consiste à encadrer l’agent par des politiques de permission et des workflows. Un modèle peut proposer une liste d’actions, puis un humain valide. Ou bien il exécute uniquement en mode « non destructif », par exemple déplacer vers un dossier d’archive au lieu de supprimer. Une autre option consiste à forcer une sauvegarde avant exécution, ou à exiger une double confirmation quand le nombre d’éléments concernés dépasse un seuil.
Cette logique se heurte à la réalité de l’usage grand public, où l’IA est parfois utilisée comme un outil de productivité rapide, sans paramétrage fin. Dans ces cas, la conception par défaut devient déterminante. Un défaut de confirmation, une interface trop permissive, ou une formulation ambiguë peut suffire à déclencher un incident. Le problème n’est pas uniquement la suppression, mais l’écart entre l’intention de l’utilisateur et l’action effectuée.
Pour les éditeurs, l’enjeu est aussi réputationnel. Un récit de « fichiers effacés » circule plus vite qu’un correctif ou qu’une explication sur des mécanismes de corbeille. Les plateformes sociales favorisent les témoignages spectaculaires, parfois sans contexte sur l’environnement, les connecteurs activés, ou les permissions accordées. Cela complique la vérification, mais oblige les acteurs à répondre rapidement, ne serait-ce que pour préciser le périmètre et les mesures de mitigation.
Dans l’immédiat, la prudence recommandée par de nombreux professionnels est classique, éviter de donner à un assistant des droits d’écriture étendus sur des dossiers sensibles, préférer un mode lecture seule pour l’analyse, activer des sauvegardes, et tester sur des environnements de copie. Tant que les signalements persistent, la question de la confiance opérationnelle dans les agents IA reste ouverte, avec une exigence croissante de contrôles visibles et compréhensibles.
Crédit image : User:Martorell, amb assistència de DALL·E 3 (OpenAI) a través de ChatGPT, i modificat posteriorment. / Wikimedia Commons (Public domain)
