vendredi 25 septembre 2026

À propos

Contact

Accessibilité

Antipatterns d’agents IA en admin : republier du contenu sans alerte accessible

Un agent IA branché sur l'administration republie des articles pour corriger du SEO ou reformuler un texte. Sans garde-fou, il peut détruire de l'accessibilité déjà acquise.

Par Clément Hadrot • 16 mars 2026 • 4 min de lecture • Aucun commentaire
Antipatterns d'agents IA en admin : republier du contenu sans alerte accessible

Un client dont l’équipe éditoriale est réduite a mis en place un agent IA chargé de retravailler ses anciens articles : reformulation de titres pour le SEO, ajout de liens internes, mise à jour de paragraphes datés. L’agent tourne la nuit, republie ses corrections, et personne ne relit systématiquement chaque changement le lendemain matin. Douze articles plus tard, un audit de routine a mis au jour un problème net.

Ce billet décrit ce qu’on observe sur ce type de dispositif, pourquoi il représente un risque réel pour l’accessibilité, et ce qu’il faut mettre en place avant de laisser un agent republier du contenu sans supervision humaine systématique.

Ce qu’on voit

L’agent, configuré pour reformuler les paragraphes jugés trop longs ou datés, a purement et simplement supprimé, dans plusieurs articles, la légende qui accompagnait des images explicatives — jugée redondante avec le texte reformulé selon sa propre logique. Sur un article contenant une vidéo intégrée, il a également retiré le paragraphe de transcription qui précédait le lecteur, considéré comme un doublon inutile du contenu audio.

Pourquoi c’est un problème

L'essentiel à retenir : Un agent qui réécrit un texte peut supprimer une transcription ou un texte alternatif sans le signaler ; La republication automatique doit déclencher le même contrôle qu'une publication humaine ; Un journal d'action lisible reste la meilleure protection contre les régressions invisibles

Un agent de reformulation optimise généralement pour la lisibilité et la densité d’un texte pensé pour un lecteur voyant. Il n’a aucune notion native de ce qui, dans le contenu existant, sert justement de canal alternatif pour un utilisateur qui ne peut pas voir l’image ou entendre le son. Une légende ou une transcription lui apparaissent comme redondantes, alors qu’elles sont la seule voie d’accès au contenu pour une partie des visiteurs.

Le second problème, presque plus grave que la suppression elle-même, tient à l’absence totale d’alerte : la republication s’est faite silencieusement, sans distinguer un changement cosmétique d’un changement qui touche à l’accessibilité du contenu. Personne n’a été prévenu qu’une transcription venait de disparaître.

Le faux réconfort du contenu « avant/après » figé

Certaines équipes pensent se protéger en conservant un historique de révisions WordPress classique. C’est utile pour revenir en arrière, mais insuffisant comme garde-fou préventif : personne ne consulte l’historique de révision d’un article qui semble avoir été « juste amélioré » par l’agent, tant qu’aucune alerte ne signale un changement sensible.

Quoi faire

Trois mesures ont été mises en place avec ce client à la suite de l’incident :

  • Une liste d’éléments protégés — attributs alt, transcriptions, légendes, étiquettes de formulaire — que l’agent n’est plus autorisé à supprimer ou modifier sans validation humaine explicite
  • Une comparaison automatique du contenu avant et après passage de l’agent, avec un rapport de diff envoyé par courriel à un humain avant toute republication
  • Un délai de mise en file d’attente : l’agent prépare ses modifications, mais ne les publie plus directement ; elles restent en brouillon jusqu’à validation

Un script de vérification simple

Un script exécuté avant chaque republication compare le nombre d’attributs alt et de blocs de transcription présents avant et après la modification proposée par l’agent :

function wp_moderne_verifier_regression_accessibilite( $contenu_avant, $contenu_apres ) {
    $alt_avant  = substr_count( $contenu_avant, 'alt=' );
    $alt_apres  = substr_count( $contenu_apres, 'alt=' );

    if ( $alt_apres < $alt_avant ) {
        return new WP_Error(
            'regression_accessibilite',
            'La révision proposée réduit le nombre d’attributs alt présents.'
        );
    }

    return true;
}

Ce que ce script ne couvre pas

Ce contrôle reste rudimentaire : il détecte une suppression, pas une dégradation de qualité d’un texte alternatif remplacé par une valeur vide ou générique. Il constitue un premier filet, pas une garantie complète, et n’exempte pas d’une revue humaine régulière du contenu republié par l’agent.

Un agent qui republie sans jamais s’arrêter finit toujours par optimiser une métrique au détriment d’une autre qu’il ne mesure pas. L’accessibilité, invisible dans son tableau de bord, est la première candidate à disparaître.

En résumé

Confier la republication de contenu à un agent IA sans garde-fou dédié à l’accessibilité revient à parier que l’agent ne touchera jamais aux éléments qui comptent le plus pour les utilisateurs les plus dépendants du texte alternatif. Ce pari se perd régulièrement. Une liste d’éléments protégés, un rapport de diff avant publication et une file de validation humaine restent les trois protections minimales à mettre en place.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi