# Demandez ce qu'il advient de vos documents, pas du modèle

**Résumé:** Vous connectez un espace de stockage documentaire à une plateforme d'IA ? Ce qui compte n'est pas la qualité du modèle, mais si vos documents survivent intacts à l'ingestion, contenu caché compris.

**En bref:** Une seule question distingue les fournisseurs ici, et elle ne porte pas sur l'intelligence : notre contenu traverse-t-il votre système sans être modifié ?

**Publié:** 2026-08-03

**Dernière mise à jour:** 2026-08-11

Chaque fois qu'un incident de sécurité IA éclate, la même question circule dans les services achats : quel modèle fait-il tourner, et ce modèle est-il sûr ? C'est le mauvais axe. Si vous êtes sur le point de connecter un espace de stockage documentaire à une plateforme d'IA, ce qui décide de votre exposition n'est pas le jugement du modèle. C'est ce que le pipeline fait à votre texte avant qu'aucun modèle ne le voie.

Concrètement, une question mérite d'être posée à votre fournisseur : quand vous ingérez nos documents, ce contenu traverse-t-il votre système sans être modifié ? La plupart des réponses sont oui, et oui est la réponse risquée.

Une divulgation publiée fin juillet montre pourquoi.

## L'attaque qui illustre le propos

Le 28 juillet, le chercheur en sécurité Håkon Måløy a publié le troisième volet de sa série « Context Collapse », décrivant une injection de prompt qui transforme des documents Microsoft Word en vecteurs de leurs propres instructions. Simon Willison en a [rendu compte le lendemain](https://simonwillison.net/2026/Jul/29/ai-worming-through-word/ "AI Worming through Word").

Un attaquant place des instructions cachées dans un document, généralement en texte blanc sur fond blanc et en corps de police minuscule. Copilot for Word supprime la couleur et la taille de police avant de traiter le texte, si bien qu'il lit exactement la partie que l'humain ne peut pas voir. Il peut alors traiter ces instructions comme faisant partie de la demande de l'utilisateur, agir en conséquence, et les recopier dans le document qu'il produit. Ce fichier de sortie devient à son tour un vecteur, et l'utiliser comme source dans un autre flux de travail peut redéclencher les instructions - sans que le document original de l'attaquant ne soit nulle part en vue.

[CSO Online](https://www.csoonline.com/article/4203630/copilot-worm-can-spread-through-microsoft-word-docs.html "Copilot worm can spread through Microsoft Word docs") et [CyberInsider](https://cyberinsider.com/microsoft-copilot-for-word-vulnerable-to-self-propagating-worm-like-attack/ "Microsoft Copilot for Word vulnerable to self-propagating worm-like attack") en ont tous deux parlé, et [Malwarebytes](https://www.malwarebytes.com/blog/ai/2026/07/hidden-microsoft-copilot-ai-worm "Hidden prompt turns Microsoft Copilot into an AI worm") a décrit le même comportement auto-propagateur. Ce n'est pas le cas limite d'un seul chercheur. Cela se reproduit.

## Un meilleur modèle n'a jamais été la solution

La chronologie de la divulgation est la partie qui devrait intéresser un acheteur. Måløy a signalé le problème au Microsoft Security Response Center le 6 mars 2026, et Microsoft l'a confirmé plus tard dans le mois. Début avril, l'éditeur a livré une version révisée de « Edit with Copilot », et la charge utile initiale a cessé de fonctionner.

Puis il l'a reformulée, et elle est passée. Microsoft a ouvert un second dossier. Le 14 juillet, l'éditeur a mis à niveau le modèle sous-jacent de Copilot for Word, et dès le 15 juillet, Måløy avait de nouveau contourné la protection. [iTnews a rapporté](https://www.itnews.com.au/news/microsoft-cant-kill-dogged-researchers-copilot-for-word-worm-627830 "Microsoft can't kill dogged researcher's Copilot for Word worm") que des charges utiles modifiées continuaient de reproduire cette classe d'attaque jusqu'au 28 juillet, après 144 jours de divulgation coordonnée.

Il faut le reconnaître : Microsoft a réagi deux fois, et rapidement, et Måløy a retenu la charge utile précise justement parce qu'aucune mitigation robuste n'existe. L'échec ne vient pas d'un manque de rigueur. Il vient du fait que corriger une charge utile et mettre à niveau un modèle sont deux réponses situées sur l'axe du modèle, alors que la vulnérabilité ne s'y trouve pas. Un meilleur modèle change ce à quoi le système est susceptible de céder. Il ne change rien au fait qu'un texte caché dans un document source puisse, ou non, atteindre les instructions du système.

## Pourquoi ce n'est pas seulement un problème Copilot

L'objection raisonnable est qu'il s'agit d'une seule intégration Microsoft, et que Microsoft finira par la contenir. Juste. Mais regardez ce que l'attaque exige réellement : un pipeline qui transporte le texte source en le laissant largement intact, jusque dans une sortie qui devient à son tour une entrée.

Cela n'a rien d'exotique. C'est ce que fait la plupart des IA capables de lire des documents, car préserver vos documents est normalement tout l'enjeu. Si un fournisseur indexe vos fichiers et en récupère des passages, le texte original reste ce qui circule dans le système - et une instruction cachée à l'intérieur circule tout autant. L'intégration était spécifique. La propriété, elle, est générale.

C'est pourquoi la question porte sur vos documents, et non sur leur modèle.

## Notre réponse

Chez UNLESS, la Connaissance dynamique ne conserve pas vos documents tels qu'ils sont arrivés. Votre activité est [continuellement restructurée et réécrite dans une Bibliothèque unique et non ambiguë](https://unless.com/en/engine/ "Moteur : la plateforme qui s'entretient elle-même"), et la page d'accueil le dit sans détour : ce que l'agent sait est nettoyé, réécrit, non ambigu et à jour. Ce que détient l'index de recherche est un nœud de contenu généré, pas le fichier que vous avez envoyé.

Notre réponse à la question est donc non : votre contenu ne traverse pas notre système inchangé, et c'est précisément la fonctionnalité. Une instruction cachée survit à une copie. Elle ne survit pas à une réécriture en autre chose. L'étape de propagation dont dépend cette attaque est absente, plutôt que bloquée.

Cette même conception offre un second bénéfice. Comme chaque élément ingéré doit passer par cette réécriture, celle-ci constitue un point unique où chaque élément peut être examiné : pour des problèmes de sécurité, et pour vérifier s'il a même sa place dans cette Bibliothèque de contenu. Un point de passage unique se raisonne bien plus facilement que mille documents qui circulent sans filtre.

Autour de cela se trouvent des contrôles que nous documentons déjà. Les affirmations contradictoires sont mises en évidence plutôt que fusionnées en silence, si bien qu'une bibliothèque qui se contredit devient un travail visible : la Boîte de réception signale le conflit, et il se résout en un clic d'Accepter ou de Refuser. Les modifications de contenu automatisées attendent cette décision humaine. Des [silos de contenu indépendants](https://unless.com/en/trust/ "Confiance : conçue pour l'UE depuis le premier jour") garantissent que les données d'un client n'atteignent jamais l'agent d'un autre client. Et l'agent ne prend aucune action irréversible sans qu'un humain n'ait d'abord approuvé cette limite.

## Ce que nous n'affirmons pas

Nous ingérons des documents pour vivre, nous sommes donc à l'intérieur de ce problème plutôt qu'à le regarder de loin. Personne d'honnête ne vous dira qu'une classe de menace est définitivement close, et un fournisseur qui le prétend vous renseigne davantage sur sa culture d'ingénierie que sur son produit.

L'affirmation est plus étroite, et elle est architecturale. Un pipeline qui réécrit ce qu'il ingère porte un risque de nature différente de celui qui se contente de transmettre les documents. Cette différence ne vient pas d'un meilleur modèle, et elle ne viendra pas du prochain non plus.

## La question, une dernière fois

Quand la prochaine divulgation tombera - et elle tombera -, la question utile n'est pas de savoir quel modèle s'est fait piéger.

Demandez ce que le pipeline de votre fournisseur fait à votre texte entre le moment où il arrive et le moment où un agent le lit. Demandez si vos documents ressortent reconnaissables de l'autre côté, et si la réponse est oui, demandez ce qui empêche ce qui y est caché de ressortir tout aussi reconnaissable.

Posez la question avant de connecter l'espace de stockage documentaire, pas après.