Vingt-deux pour cent des réponses d’un agent chargé de proposer un titre, un extrait et trois étiquettes échouaient à l’analyse automatique, sur un échantillon de cinq cents générations en texte libre reparsé ensuite par une expression régulière. Le même agent, contraint à une sortie JSON validée par un schéma strict, est tombé à moins d’un pour cent d’échec sur un échantillon comparable.
Cet écart mérite d’être détaillé, car il touche directement la fiabilité d’un agent censé écrire seul dans une base de données WordPress. Une sortie qui échoue à l’analyse n’est pas seulement gênante : elle peut, si elle n’est pas correctement gérée, provoquer l’écriture d’un contenu tronqué ou mal formé.
Le texte libre reparsé : une approche fragile par construction
La première approche consistait à demander au modèle de répondre selon un format texte convenu, par exemple une ligne « Titre : … » suivie d’une ligne « Extrait : … », que le code PHP analysait ensuite à l’aide d’expressions régulières pour en extraire les champs attendus.
preg_match( '/Titre\s*:\s*(.+)/', $reponse, $matches_titre );
preg_match( '/Extrait\s*:\s*(.+)/', $reponse, $matches_extrait );Cette approche fonctionne tant que le modèle respecte scrupuleusement le format demandé. Le problème vient de sa fragilité : une reformulation mineure, un retour à la ligne supplémentaire, ou l’ajout d’une phrase d’introduction non demandée par le modèle suffit à casser l’expression régulière, sans qu’aucune erreur explicite ne remonte au code appelant.
Ce que le schéma JSON strict impose
La seconde approche s’appuie sur un mode de sortie structurée proposé par les principaux fournisseurs de modèles depuis 2023, où l’on fournit un schéma JSON précis que la réponse du modèle doit respecter, sous peine de rejet côté fournisseur avant même que la réponse ne soit renvoyée à l’application.
{
"type": "object",
"properties": {
"titre": { "type": "string", "maxLength": 80 },
"extrait": { "type": "string", "maxLength": 200 },
"etiquettes": {
"type": "array",
"items": { "type": "string" },
"minItems": 3,
"maxItems": 3
}
},
"required": ["titre", "extrait", "etiquettes"]
}Comparatif chiffré sur l’échantillon testé
| Critère | Texte libre reparsé | JSON contraint par schéma |
|---|---|---|
| Taux d’échec de parsing | 22 % | moins de 1 % |
| Champs manquants détectés a posteriori | fréquents | rares |
| Complexité de rédaction du prompt | faible | modérée |
| Nécessité d’une validation PHP supplémentaire | forte | réduite mais toujours utile |
Un cas limite : la sortie partiellement valide
Un cas plus délicat que le simple échec total mérite d’être mentionné : une sortie JSON syntaxiquement correcte, mais dont un champ dépasse la longueur maximale imposée par le schéma. Selon le fournisseur et le mode de validation choisi, ce dépassement est soit rejeté avant l’envoi de la réponse, soit tronqué silencieusement, ce qui impose de tester précisément le comportement retenu avant de considérer le schéma comme une garantie absolue.
Sur nos tests, nous avons choisi de traiter tout rejet de schéma comme un échec complet de la génération, en relançant l’appel une seconde fois plutôt que d’accepter une sortie partiellement conforme récupérée par un contournement applicatif. Cette règle simple évite d’introduire, par la bande, le même genre de fragilité que celle observée avec le texte libre reparsé.
Ce que le schéma ne dispense pas de faire
Un schéma JSON strict garantit la forme de la réponse, pas sa pertinence : un modèle peut parfaitement renvoyer un titre respectant la longueur maximale mais sans rapport avec le contenu réel de l’article. La validation de forme via le schéma doit donc rester complétée par une validation de fond côté code, notamment sur les champs qui alimentent directement une publication.
- Le schéma garantit la structure, pas la pertinence du contenu
- Une validation métier complémentaire reste nécessaire côté PHP
- Le schéma réduit le risque d’échec de parsing, pas le risque d’erreur factuelle
Sur nos projets, le passage au JSON contraint par schéma a réduit le nombre de tickets de support liés à des articles mal formés de façon plus nette que n’importe quelle amélioration du prompt en texte libre.
Notre verdict
Le texte libre reparsé conserve un intérêt pour un prototype rapide ou une sortie destinée à un affichage brut sans écriture automatisée en base. Dès qu’un agent doit écrire directement dans WordPress sans supervision systématique, la sortie JSON contrainte par un schéma strict s’impose comme la seule option raisonnable, au prix d’un prompt légèrement plus long à rédiger.
