Pourquoi le HTML brut séduit les outils d’IA
Un modèle peut reproduire rapidement une capture en générant un grand fragment HTML. Le navigateur l’affiche et donne l’impression que le travail est terminé. WordPress, lui, ne voit qu’un bloc opaque difficile à modifier, réutiliser ou valider.
Le coût apparaît plus tard : les corrections d’accessibilité se répètent, les médias deviennent fragiles et une évolution globale doit combattre chaque fragment.
Choisir les blocs natifs lorsque le contenu possède un sens standard
Un titre doit être un bloc Titre, une liste un bloc Liste, une photographie légendée un bloc Image et une FAQ un bloc Détails. theme.json et un CSS bien délimité peuvent donner une identité forte sans détruire la sémantique éditoriale.
Employer les compositions pour les assemblages réutilisables
Une introduction de service, un chapitre d’étude de cas, un dossier fondateur ou un appel à l’action sont de bonnes compositions. Elles fournissent un point de départ sûr tout en laissant le contenu éditable.
Verrouillez uniquement ce qui protège la marque ou l’accessibilité. Trop de verrouillage transforme WordPress en formulaire caché; trop peu invite la dérive.
Réserver les blocs dynamiques aux comportements gouvernés
Une navigation adaptée à la langue, un formulaire sécurisé, une mesure respectueuse du consentement ou un module construit depuis des métadonnées appartient au code applicatif. Le rendu serveur peut imposer validation, permissions et échappement sans masquer le contenu ordinaire.
Appliquer le test de l’éditeur
Ouvrez chaque page dans l’éditeur et demandez à une personne non développeuse de remplacer un titre, un lien, une image, une étape et une réponse de FAQ. L’arborescence doit rester intelligible et l’aperçu fidèle.
Une exception HTML doit expliquer sa raison, son échappement, son comportement accessible et la condition qui permettrait de la rendre native. Un contrôle automatisé doit empêcher ces exceptions de se multiplier.
