À partir du 2 août 2026, l’article 50 de l’EU AI Act s’applique : les images générées par IA ont besoin d’un marquage lisible par machine. De nombreux exploitants WordPress résolvent cela avec une extension de marquage dédiée — et conservent à côté leur extension d’optimisation d’image existante pour le WebP/AVIF. À première vue, une séparation propre des responsabilités. Mais techniquement, cela cache un problème qui devient rarement évident avant qu’il ne soit trop tard.

Où le marquage atterrit réellement

Un marquage lisible par machine selon l’article 50 est typiquement écrit comme marqueur de métadonnées dans le fichier image — par exemple comme DigitalSourceType IPTC ou entrée XMP propre. Le hic : ces métadonnées se trouvent dans le fichier concret, pas dans l’enregistrement WordPress. Dès qu’un nouveau format d’image est généré à partir de l’original — par exemple une version WebP ou AVIF pour des temps de chargement plus rapides —, un fichier entièrement nouveau est créé. Et les nouveaux fichiers n’ont d’abord aucune métadonnée, sauf si le programme qui les génère les écrit explicitement.

C’est le cœur du problème : une extension d’optimisation qui ignore tout de l’obligation de marquage n’a aucune raison de reprendre le marqueur dans le fichier WebP/AVIF qu’elle génère. Le marquage existe alors encore dans l’original JPEG/PNG sur le serveur — mais c’est justement cet original qu’aucun visiteur ne voit. C’est la version optimisée qui est livrée. Le marquage a de facto disparu pour le public, sans qu’aucun message d’erreur n’apparaisse nulle part.

Pourquoi ce n’est pas théorique

Ce problème n’est pas un cas marginal. Qui regarde les descriptions techniques des extensions de marquage actuelles tombe désormais sur des contre-mesures explicites pour cela — par exemple des commandes propres de « vérification » ou de « réparation » qui contrôlent après chaque passage d’optimisation si les métadonnées sont toujours là, et les réécrivent si nécessaire. C’est un contournement pour un problème structurel : deux extensions séparées avec des responsabilités séparées ne peuvent pas garantir que leurs résultats concordent.

Comment Img Performer résout cela

Img Performer détecte les images générées par IA à l’envoi et écrit le marquage — parce que le même logiciel génère aussi le fichier WebP/AVIF, le marqueur atterrit automatiquement dans les deux. Il n’y a jamais de moment où une optimisation se produit « après » et oublie le marquage au passage : conversion et marquage s’exécutent dans le même processus, pour le même fichier, sur chaque taille d’image générée.

Pour le cas pratique, cela signifie : qui utilise Img Performer n’a pas à se demander si le marquage est toujours là après la prochaine optimisation d’image. Il n’y a pas de « prochaine » optimisation d’image qui pourrait s’exécuter séparément.

En conclusion

Lors du choix d’un outil de marquage, une question concrète mérite d’être posée : que devient le marquage quand une autre extension régénère l’image plus tard — pour du WebP, de l’AVIF, un CDN ou une mise à jour de thème ? Si la réponse est « ça devrait normalement fonctionner », un test s’impose. Quand optimisation et marquage tournent dès le départ dans la même extension, la question ne se pose même pas.