wp_kses_post nettoie la sortie d’un LLM avant toute publication

Que se passe-t-il quand un modèle de langage, invité à reformuler un texte, décide d’ajouter une balise <script> parce qu’un exemple de sa base d’entraînement en contenait une dans un contexte proche ? La réponse dépend entièrement de ce que le plugin fait de cette sortie avant de l’enregistrer dans la base de données WordPress.

Un modèle de langage, contrairement à un champ de formulaire classique, ne respecte aucune contrainte de balisage sauf si on le lui impose explicitement dans le prompt, et même dans ce cas rien ne garantit un respect strict de la consigne. Traiter sa sortie comme une entrée utilisateur non fiable, au même titre qu’un commentaire de visiteur, constitue donc une précaution nécessaire plutôt qu’excessive.

La fonction à connaître

La fonction wp_kses_post(), native au cœur de WordPress, filtre une chaîne de texte en n’autorisant que les balises et attributs permis aux rôles éditoriaux standards : les balises de mise en forme courantes, les liens, les listes, mais ni <script>, ni <iframe>, ni un attribut onclick quelconque.

$texte_genere = mon_projet_appeler_llm( $prompt );

$texte_propre = wp_kses_post( $texte_genere );

wp_update_post( array(
    'ID'           => $post_id,
    'post_content' => $texte_propre,
) );

Cette seule ligne suffit à neutraliser la quasi-totalité des sorties HTML non maîtrisées observées en pratique : balises de script, iframes indésirables, attributs de style inline injectés sans raison apparente par le modèle.

Adapter la fonction de nettoyage au champ cible

• Contenu principal d’un article : wp_kses_post() convient dans la majorité des cas, car il autorise la mise en forme éditoriale standard.
• Titre d’article : préférer sanitize_text_field(), qui retire toute balise HTML, un titre ne devant jamais contenir de mise en forme.
• Texte alternatif d’image : également sanitize_text_field(), pour la même raison.
• Champ personnalisé destiné à un usage plus permissif (par exemple un extrait de code affiché dans un bloc dédié) : utiliser wp_kses() avec un tableau de balises autorisées personnalisé, si wp_kses_post() se révèle trop restrictif.

Un cas rencontré en pratique

Sur un projet de génération de résumés d’articles, un modèle de langage a renvoyé un résumé contenant une balise <div style="color:red"> autour d’un passage qu’il jugeait important, une pratique de mise en forme visiblement apprise de pages web mal formées présentes dans son corpus d’entraînement. Sans filtrage, cette balise aurait été enregistrée telle quelle, cassant potentiellement la mise en page du thème.

Ce que wp_kses_post ne remplace pas

Ce filtre protège contre l’injection de balises indésirables, mais ne garantit en rien l’exactitude factuelle du texte généré. Un contenu parfaitement propre au sens du balisage peut malgré tout contenir une information inventée ou erronée : la vérification factuelle reste un sujet distinct, à traiter par une relecture humaine.

Le repère qu’on retient : chaque sortie d’un modèle de langage destinée à la base de données passe par une fonction de nettoyage adaptée au champ cible, sans exception, même quand la sortie semble propre à l’œil nu.

En résumé

Traiter la sortie d’un LLM comme une donnée non fiable, au même titre qu’une saisie de formulaire public, évite une classe entière de problèmes de sécurité simples à corriger mais faciles à oublier. wp_kses_post() couvre la majorité des besoins pour du contenu éditorial ; le choix de la fonction exacte dépend surtout du champ de destination et du niveau de mise en forme réellement nécessaire.

Un dernier réflexe à prendre : ne jamais faire confiance à un exemple de code trouvé sur un forum qui désactiverait ce filtrage « pour gagner du temps » ou « parce que ça bloque une balise utile ». Si une balise légitime est bloquée par wp_kses_post(), la bonne réponse consiste à étendre la liste des balises autorisées via wp_kses() avec un tableau explicite, jamais à supprimer purement et simplement toute étape de filtrage sur une sortie de modèle de langage.

Cette discipline, une fois intégrée à la routine de développement, ne coûte quasiment rien en temps de mise en œuvre et referme durablement une porte d’entrée que beaucoup d’extensions grand public laissent encore ouverte par simple méconnaissance du problème.