Une image publiée est une image copiée. Protéger ses images de l’entraînement IA ne revient donc jamais à rattraper ce qui circule déjà : il s’agit de rendre les copies suivantes moins exploitables par un modèle.
La nuance a l’air théorique. Elle décide pourtant de tout, parce qu’elle sépare les dispositifs qui peuvent encore agir de ceux qui arrivent après la bataille.
Agir sur le fichier ou agir sur l’accès
Deux familles coexistent, et elles n’interviennent pas au même endroit de la chaîne.
- Les protections sur le fichier : on modifie l’image avant diffusion, pour qu’un modèle qui l’ingère en tire une représentation fausse ou inutilisable.
- Les protections sur l’accès : on ne touche pas au fichier, on refuse ou on empêche la collecte, au niveau du serveur qui sert l’image.
Les deux partagent une frontière nette : elles ne valent que pour ce qui n’est pas encore parti. Une photo en ligne depuis trois ans a déjà été aspirée, republiée, recompressée, archivée par des acteurs dont vous ignorez jusqu’au nom. Aucun traitement appliqué aujourd’hui au fichier d’origine n’ira modifier ces copies, et aucun réglage serveur non plus.
Un créateur qui attend d’un outil qu’il nettoie son catalogue déjà en ligne sera déçu. Ce qui se protège, c’est la publication de demain.
La recherche a déjà tranché sur les filtres anti-IA
La perturbation adverse ajoute à l’image un bruit calculé, invisible à l’œil, conçu pour décaler la façon dont un modèle encode ce qu’il voit. L’humain voit un portrait, le modèle enregistre autre chose : un style qui n’est pas le vôtre, une texture qui n’existe pas.
L’empoisonnement pousse la logique plus loin. Il ne se contente pas de brouiller une image : il vise à corrompre l’association entre un concept et sa représentation, pour que l’entraînement sur un lot suffisant d’images traitées dégrade le modèle lui-même. C’est le principe des outils du SAND Lab de l’université de Chicago, toujours maintenus : Nightshade a reçu une mise à jour en avril 2026.
Leur robustesse, elle, a été évaluée ailleurs, et le verdict est sévère. Robert Hönig, Javier Rando, Nicholas Carlini et Florian Tramèr, dans un travail présenté à l’ICLR 2025 (arXiv 2406.12027), concluent que ces protections offrent surtout un faux sentiment de sécurité : agrandir l’image suffit déjà à les dégrader. Dans la foulée, LightShed, présenté à USENIX Security 2025, annonce 99,98 % de détection des images traitées par Nightshade, et fonctionne aussi contre Glaze.
L’asymétrie est structurelle et vaut pour toute la catégorie. La protection est figée le jour de la publication ; l’attaque, elle, continue de progresser. Vous posez un verrou dont la clé sera publiée plus tard, dans un article de conférence, en accès libre.
Quatre vérifications avant d’appliquer un filtre
Tout dispositif appliqué au fichier arbitre entre deux exigences contradictoires. Le bruit doit être assez fort pour désorienter un modèle, assez faible pour rester invisible. Sur une illustration très détaillée, l’arbitrage passe souvent inaperçu. Sur un aplat, un dégradé doux, un trait propre ou une peau en lumière rasante, il se voit.
S’ajoute un effet que les démonstrations montrent rarement : les plateformes réencodent. Redimensionnement, conversion, compression avec pertes, génération de vignettes. Chaque passage érode une partie du signal qui portait la protection, alors qu’il laisse intacte la valeur esthétique de l’image pour un collecteur.
Avant d’adopter quoi que ce soit, quatre vérifications tiennent en quelques minutes :
- Le résultat reste-t-il acceptable à 100 % d’affichage, sur vos images les plus exigeantes, pas sur l’exemple fourni par l’éditeur ?
- Survit-il à un export tel que votre plateforme de diffusion le pratique ?
- L’efficacité annoncée repose-t-elle sur une évaluation indépendante et publiée, ou sur la documentation de l’outil ?
- Le modèle de menace est-il énoncé ? Un dispositif efficace contre un entraînement naïf ne dit rien de sa tenue face à un adversaire qui sait qu’il existe.
Un outil qui échoue à ces quatre vérifications relève de la dissuasion, ce qui reste honorable tant qu’on ne le prend pas pour une protection.
Le robots.txt sépare enfin indexation et entraînement
Le centre de gravité du sujet s’est déplacé vers l’accès, et c’est là que la situation a réellement bougé. Cloudflare distingue depuis juillet 2026 trois comportements de robots, Search, Training et Agent, puis a ajouté en septembre un réglage de refus d’entraînement : la préférence est publiée dans le robots.txt du site et honorée par les crawlers qu’il classe « Accountable ». Apple, Google et Microsoft y figurent, la prise en charge par Bingbot étant annoncée pour début 2027.
Le gain porte sur la granularité. Refuser l’entraînement sans se couper de l’indexation relevait jusqu’ici d’un choix binaire déguisé : on gardait la visibilité ou on la perdait. Séparer les usages rend la déclaration compatible avec le fait d’exister dans un moteur de recherche.
Google avait ouvert une voie voisine dès 2023 avec son jeton Google-Extended, qui exclut un site de l’entraînement de Gemini sans toucher à son classement. La comparaison montre la limite du procédé : ce jeton ne couvre pas les AI Overviews, alimentés par Googlebot, si bien qu’un éditeur n’en sort qu’en quittant l’index.
Reste ce que la granularité ne règle pas. Un robots.txt est une déclaration d’intention lue par ceux qui veulent bien la lire. Il ne bloque rien par lui-même : il informe. La partie contraignante, c’est le filtrage au niveau du réseau, qui identifie le robot et refuse la requête. Déclaration et blocage sont deux briques différentes, et confondre l’une avec l’autre revient à croire qu’un panneau vaut une serrure.
Deuxième limite, tout aussi importante : cette mécanique ne couvre que ce que vous hébergez. Les images déposées sur une plateforme tierce relèvent des conditions d’utilisation de cette plateforme, pas de votre configuration.
Cinq gestes classés par effet réel
Par ordre d’effet décroissant, voilà ce qui tient debout.
Reprendre la main sur son propre domaine. Publier ses originaux sur un site qu’on contrôle, y déclarer le refus d’entraînement et y ajouter un filtrage des robots au niveau du réseau. C’est le seul levier qui empêche effectivement une collecte plutôt que de la décourager.
Traiter les plateformes tierces comme un territoire perdu. Ce qui part sur un réseau social suit les règles de ce réseau. Puisqu’on n’y échappe pas, la décision se limite à ce qu’on y dépose : une résolution de diffusion, jamais un fichier de travail.
Séparer le master de la copie publique. Une version web à la définition juste suffisante, un original qui ne quitte pas le poste. Cela ne bloque personne, mais cela limite ce qu’un collecteur récupère.
Miser sur la traçabilité plutôt que sur le blindage. Signature d’authenticité, métadonnées de paternité, registre de dépôt. Rien de tout cela n’empêche la copie ; tout cela sert à prouver l’antériorité le jour où la discussion devient juridique. Et c’est sur ce terrain, pas sur celui du pixel, que les créateurs obtiennent aujourd’hui gain de cause.
Ranger les filtres sur fichier à leur place. Une gêne supplémentaire, à coût nul si le rendu reste bon, et jamais un argument pour publier une image qu’on n’aurait pas publiée sans eux. La littérature scientifique reproche précisément cette substitution à toute la catégorie.
En un an, le débat a changé de terrain. Rendre une image toxique pour un modèle reste un pari de laboratoire. Refuser le collecteur de façon lisible et vérifiable est devenu une opération de routine, à la portée de n’importe quel site. Ce refus vaudra ce que vaudront ses effets : le nombre d’acteurs qui l’honorent, et la facture pour ceux qui l’ignorent.
Questions frequentes
Peut-on retirer une image déjà utilisée pour entraîner un modèle ?
Non par un moyen technique appliqué au fichier : un modèle entraîné ne stocke pas les images, et les copies déjà diffusées échappent à toute modification ultérieure. Le seul recours passe par une demande de retrait auprès de l’éditeur du jeu de données ou par la voie juridique.
Les outils qui ajoutent un bruit invisible aux images fonctionnent-ils ?
Leur efficacité est contestée par la recherche revue par les pairs. Les travaux présentés à l’ICLR 2025 (arXiv 2406.12027) concluent que ces protections créent surtout un faux sentiment de sécurité, et LightShed, présenté à USENIX Security 2025, annonce 99,98 % de détection des images ainsi traitées.
Le robots.txt suffit-il à empêcher l’entraînement sur ses images ?
Non, c’est une déclaration et non un blocage : seuls les crawlers qui choisissent de la lire et de la respecter s’y conforment. Pour contraindre réellement la collecte, il faut y ajouter un filtrage des robots au niveau du réseau.
Peut-on refuser l’entraînement IA tout en restant indexé dans les moteurs de recherche ?
Oui depuis que les grands services de diffusion distinguent les usages. Cloudflare sépare ainsi l’indexation pour la recherche, l’entraînement des modèles et les agents, ce qui permet de refuser le second sans renoncer au premier.
Un filigrane protège-t-il de l’entraînement ?
Non. Un filigrane, comme les métadonnées de paternité, sert à prouver l’origine d’une image et non à empêcher sa collecte ou son ingestion par un modèle.
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 16 évaluations
Faire appel à mes services →
