Workflow éditorial IA : 7 contrôles avant de publier

Une automatisation éditoriale ne devrait pas avoir pour objectif de publier. Elle devrait avoir pour objectif de produire un contenu publiable, puis de s’arrêter si une preuve, une règle ou un contrôle échoue.

Le workflow décrit ici est celui que j’utilise sur ce site. Au début de cette exécution, le validateur a contrôlé 189 fichiers de source, dont 49 articles tous statuts confondus. La suite de tests du site a exécuté 119 tests répartis dans 20 fichiers. Ces chiffres ne prouvent pas la qualité des textes. Ils prouvent seulement que des contrats explicites existent et qu’ils ont été exécutés.

La décision éditoriale reste humaine. Les scripts empêchent surtout une mauvaise version de se glisser silencieusement en production.

Réponse en bref

Mon workflow éditorial assisté par IA comporte sept contrôles :

1. preuve et intention ;
2. schéma des métadonnées ;
3. règles éditoriales et confidentialité ;
4. tests et contrôle du code ;
5. build de production ;
6. schémas, liens, sitemap et RSS ;
7. rendu puis vérification en production.

Chaque contrôle doit pouvoir bloquer la suite. Un avertissement ignoré n’est pas un gate.

L’IA peut aider à inventorier, comparer, chercher, structurer et reformuler. Elle ne décide pas qu’un client peut être identifié, qu’un résultat est vrai, qu’une source soutient une affirmation ou qu’une page mérite d’être publiée.

Pourquoi j’ai construit ce pipeline

Une cadence de contenu crée trois tentations.

La première consiste à choisir un sujet parce qu’il manque une publication. La deuxième consiste à allonger un texte pour atteindre une longueur supposée favorable. La troisième consiste à considérer qu’un build réussi valide aussi les faits.

Google indique au contraire qu’un contenu utile doit apporter une information, une recherche ou une analyse originale. Sa documentation demande aussi de regarder qui a créé le contenu, comment il a été produit et pourquoi il existe. La politique contre l’abus de contenu à grande échelle vise les pages nombreuses, peu originales et créées principalement pour manipuler les résultats, quelle que soit la combinaison d’automatisation et de travail humain.

Le pipeline répond donc à une autre question :

Quelles preuves indépendantes faut-il obtenir avant d’autoriser le passage à l’étape suivante ?

Le mot « preuve » change selon le gate. Il peut s’agir d’une source primaire, d’un fichier conforme à un schéma, d’un test vert, d’une page rendue, d’une réponse HTTP ou d’une relecture de confidentialité.

Le point de départ mesuré

Avant d’écrire les trois contenus de cette exécution, j’ai lancé deux contrôles.

Le validateur éditorial a renvoyé :

• 189 fichiers publics et sources inspectés ;
• 49 articles ;
• 15 faits canoniques ;
• 8 affirmations enregistrées ;
• aucun échec.

La suite Vitest a ensuite renvoyé :

• 20 fichiers de tests réussis ;
• 119 tests réussis ;
• aucun test en échec.

Ce point de départ est important. Si le dépôt échoue déjà avant une modification, il faut distinguer le problème antérieur du problème introduit. À l’inverse, un état vert avant et rouge après réduit fortement la zone de recherche.

Le dépôt contenait aussi des changements en cours qui n’appartenaient pas à cette publication. Ils ont été laissés hors du périmètre du commit. Un pipeline éditorial doit contrôler le contenu, mais aussi la portée de la livraison.

Contrôle 1 : preuve et intention

Le premier gate se déroule avant la rédaction. Il répond à quatre questions.

1. Quelle requête principale cette page doit-elle servir ?
2. Quelle personne a besoin de cette réponse ?
3. Quel élément original justifie une nouvelle URL ?
4. Quelle action devient possible après lecture ?

Pour cette exécution, l’élément original devait être une donnée collectée, un protocole exécuté, une erreur documentée, un livrable ou une comparaison vérifiable. Un guide générique ne passait pas.

L’inventaire a inclus les articles publiés, en revue et en brouillon, ainsi que les offres et les formations. Les sujets ont été comparés sur l’intention, la promesse, le persona, la thèse, les H2/H3, le vocabulaire et la prochaine action.

Ce contrôle a produit trois objets différents :

• un audit de cannibalisation sur 49 contenus ;
• une analyse de 24 programmes et 119 objectifs ;
• le présent retour d’expérience sur le workflow.

Ils ne ciblent pas le même lecteur et ne demandent pas la même décision. Si deux plans avaient dépassé le seuil interne d’environ 30 %, l’un des angles aurait été réécrit ou abandonné.

Ce que l’automatisation peut faire

Un script peut extraire les métadonnées, compter les mots, comparer les plans, calculer une proximité lexicale et rechercher les paragraphes identiques.

Ce qui reste une décision

Le score ne sait pas si deux pages accompagnent deux étapes différentes. Une personne doit lire les promesses, les exemples et les actions. Le calcul est un détecteur, pas un arbitre.

Contrôle 2 : schéma des métadonnées

Chaque article appartient à une collection Astro validée par un schéma. Le frontmatter exige notamment :

• un titre ;
• une description ;
• une catégorie ;
• un statut ;
• une décision d’indexation ;
• une date de mise à jour ;
• un auteur ;
• une valeur originale ;
• au moins une source ;
• au moins une entrée de changement.

Un article publié doit aussi posséder publishedAt et verifiedAt. Un contenu non publié doit rester hors index. Une image de couverture exige un texte alternatif.

Ce contrôle empêche les incohérences faciles à rater dans une relecture visuelle. Par exemple, une page peut sembler complète dans le fichier tout en n’ayant aucune date de vérification utilisable par le template.

La documentation Astro précise que les schémas de collection rendent les données prévisibles et bloquent les entrées qui ne correspondent pas à la forme attendue. Le schéma ne juge pas la vérité. Il garantit que la place prévue pour la preuve, la date ou le statut existe.

Contrôle 3 : règles éditoriales et confidentialité

Le validateur de contenu parcourt les sources publiques et les contenus. Il recherche notamment :

• un secret probable ;
• un marqueur de travail ;
• un texte de remplissage ;
• une promesse interdite ;
• un H1 ajouté dans le MDX alors que le template en possède déjà un ;
• une section obligatoire absente ;
• une section de sources dupliquée dans le corps ;
• un historique technique rendu visible ;
• un statut incompatible avec une date de publication ;
• une attribution provisoire ;
• un tiret cadratin interdit par la convention du site.

Les études de cas ajoutent des contrôles plus stricts. Un cas publié doit décrire un projet réel, une intervention, un protocole de mesure, une limite, une autorisation et une revue du risque de réidentification. Chaque résultat doit avoir une période, une source, une méthode de calcul et une référence de preuve. Une estimation doit expliquer sa méthode.

Un nom, un domaine, une URL, une capture identifiable ou une requête de marque d’un client ne doit jamais entrer dans la version publique. L’autorisation de publier un résultat ne vaut pas autorisation d’identifier l’organisation.

Un échec réel

Le 29 juillet, trois brouillons de contenus fondés sur des projets réels ont été préparés. Le premier contrôle a trouvé 69 marqueurs de preuves manquantes. Après ajout d’informations autorisées, 54 marqueurs non chiffrés restaient.

Deux études de cas ont finalement obtenu des preuves et une anonymisation suffisantes. La troisième demandait un véritable rapport d’audit. Ce rapport n’existait pas. Le contenu est resté en brouillon et hors index.

Aucun texte n’a été inventé pour compléter le quota. C’est exactement ce qu’un échec fermé doit produire.

Contrôle 4 : tests et contrôle du code

Le site exécute deux familles de contrôles complémentaires.

astro check examine les erreurs de type, les composants et l’intégration Astro. Vitest exécute la suite de tests. Au point de départ du run, 119 tests ont réussi.

Ces tests couvrent plusieurs surfaces du site, pas seulement les articles. Il serait trompeur de présenter « 119 tests » comme 119 contrôles éditoriaux. Leur intérêt est systémique : une publication ne doit pas casser le catalogue, le contact, les pages de service, l’interface ou les règles de confidentialité.

Un test de régression est ajouté lorsqu’une erreur durable a été corrigée. Par exemple, après le rejet d’un ton trop robotique dans les études de cas, le validateur bloque désormais une section autonome « Limites » dans ce type de contenu et les tableaux centrés sur des métriques absentes.

La règle est simple :

• une préférence éditoriale durable devient une convention ;
• une convention vérifiable devient un test ;
• le test empêche le retour silencieux de l’erreur.

Tout ne peut pas être testé. Le ton, la pertinence d’un exemple et le risque de réidentification par combinaison demandent encore une relecture.

Contrôle 5 : build de production

Un fichier MDX valide peut encore échouer au rendu. Le build de production vérifie que :

• les collections se chargent ;
• les routes publiques sont générées ;
• les contenus non publiés restent absents ;
• les images sont accessibles au générateur ;
• les composants rendent le corps ;
• les pages d’index intègrent les nouvelles entrées ;
• le sitemap et le RSS sont produits.

Le build de ce site fonctionne en mode fail-closed pour le lancement. La variable de préparation au lancement doit être explicitement activée. Une erreur arrête la commande.

Après le build, le générateur crée une image Open Graph pour chaque article publié à partir du titre, de la catégorie, de la date et du portrait public. Une image manquante n’est donc pas découverte après le déploiement.

Le build n’est pas une preuve d’indexation. Il prouve seulement que l’artefact attendu existe localement.

Contrôle 6 : schémas, liens, sitemap et RSS

Trois validateurs lisent le résultat construit.

Données structurées

Le validateur JSON-LD ouvre chaque page HTML, parse les blocs et vérifie les identifiants HTTPS. Pour un article, le template produit un BlogPosting avec :

• URL canonique ;
• titre ;
• description ;
• date de publication ;
• date de modification ;
• auteur ;
• image ;
• section ;
• langue ;
• relation avec le site.

La documentation de Google indique que les données structurées Article, NewsArticle ou BlogPosting peuvent aider à comprendre la page et ses informations de titre, d’image, d’auteur et de date. Elles ne garantissent aucun affichage.

Liens internes

Le validateur parcourt les href internes du HTML construit. Un lien relatif doit correspondre à un fichier ou à une route générée. Ce contrôle évite de publier un article dont la prochaine étape renvoie vers une page inexistante.

Les liens externes exigent une lecture différente : une réponse HTTP ne suffit pas toujours à conclure. Le protocole d’audit des liens externes et des sources SEO détaille le contrôle de 189 URL, les redirections et la distinction entre blocage automatisé et disparition réelle.

Découverte

Le contrôle final vérifie la présence du sitemap et l’absence des parcours privés. Les nouveaux articles publiés doivent apparaître dans le sitemap, le RSS, l’index de recherche et l’index des articles.

Google précise qu’un sitemap est un signal de découverte, pas une garantie de crawl ou d’indexation. La valeur lastmod doit correspondre à une modification significative. Le workflow ne change donc pas les dates pour simuler une fraîcheur.

Contrôle 7 : rendu et production

Une page peut réussir tous les contrôles statiques et rester pénible à lire. La QA rendue ouvre donc les nouveaux articles sur ordinateur et mobile.

Elle vérifie :

• absence de débordement horizontal ;
• titres lisibles ;
• tableaux utilisables ;
• liens cliquables ;
• images présentes ;
• contenu non tronqué ;
• absence d’erreur console.

Le commit est ensuite limité aux fichiers du run. Un dry-run de déploiement construit l’archive depuis le commit, pas depuis les modifications non committées du dossier de travail. Le déploiement crée une sauvegarde distante avant synchronisation.

Après mise en ligne, chaque URL doit répondre en HTTP 200 et présenter :

• la canonical attendue ;
• une directive d’indexation autorisée ;
• le titre et un passage distinctif ;
• un BlogPosting ;
• une image Open Graph en HTTP 200 ;
• une entrée dans le sitemap ;
• une entrée dans le RSS.

Ce dernier contrôle transforme un déploiement réussi en publication vérifiée. Sans lui, une erreur de cache, de chemin ou de synchronisation peut rester invisible.

Répartir le travail entre code, IA et humain

Acteur	Travaux adaptés	Travaux à ne pas lui déléguer seul
code déterministe	schémas, formats, doublons exacts, routes, liens, statuts, secrets probables	pertinence, vérité d’un fait non structuré, risque de réidentification
IA	inventaire, comparaison, recherche préparatoire, synthèse, reformulation, génération de cas de test	autorisation client, preuve d’un résultat, décision de publier
humain responsable	intention, sources décisives, conflit d’intérêts, ton, confidentialité, arbitrage	contrôle répétitif qui peut être codé de façon fiable

La bonne architecture n’oppose pas les trois. Elle place chacun au niveau où son erreur peut être détectée.

Le pipeline minimal pour commencer

Une équipe n’a pas besoin de reproduire tout ce dépôt. Elle peut commencer avec trois gates.

Gate A : contrat éditorial

Exiger pour chaque page : intention, public, valeur originale, source, auteur, date et prochaine action.

Gate B : validation locale

Bloquer les statuts incohérents, liens cassés, marqueurs de travail, secrets probables et métadonnées manquantes. Construire la page dans les mêmes conditions que la production.

Gate C : vérification live

Après déploiement, contrôler HTTP, canonical, robots, contenu distinctif, image et découverte. Conserver le résultat dans un journal de run.

Quand une erreur réelle survient, ajouter un test précis. Éviter les règles vagues qui ne peuvent pas produire un diagnostic exploitable.

Limites

Ce workflow est adapté à un site Astro versionné dans Git. Un CMS, une équipe distribuée ou une plateforme propriétaire demanderont d’autres points d’intégration.

Les 119 tests couvrent le site dans son ensemble. Ils ne prouvent ni l’exactitude de toutes les phrases, ni la qualité pédagogique, ni l’indexation. Le nombre de tests n’est pas un score de confiance.

Le détecteur de secrets utilise des motifs prudents. Il peut manquer une donnée sensible qui ne ressemble pas à une clé. La confidentialité exige une revue du contexte et des combinaisons d’informations.

Enfin, une page peut respecter le schéma, les liens et le rendu tout en restant inutile. Le premier gate, celui de la preuve et de l’intention, demeure le plus important.

Prochaine étape

Prenez une publication récente qui a posé problème et transformez cette erreur en contrat vérifiable. Commencez par le statut, les sources, les liens et la preuve distinctive. L’article prompt ou workflow aide à choisir le bon niveau d’automatisation ; la politique éditoriale explique les décisions qui restent humaines.