Vous avez des articles prêts. Ils sont écrits, relus, parfois validés, et ils attendent dans un document partagé que quelqu'un trouve une heure pour les mettre en ligne. La réaction habituelle est de vouloir produire plus vite, souvent avec l'IA. Avant ça, je regarde s'il ne faut pas plutôt automatiser la publication de contenu, parce qu'un texte qui dort dans un dossier ne sert à personne.
J'en parle parce que je l'ai vécu en mission : le goulot n'était pas l'écriture mais la mise en ligne, faite à la main. Depuis, mes machines de contenu publient elles-mêmes. Voici comment je repère ce goulot, dans quel ordre j'automatise, et ce que cette automatisation ne règle pas.
01Le goulot n'est pas toujours l'écriture
Quand une production de contenu ralentit, on accuse d'abord l'écriture : pas assez de rédacteurs, pas assez de temps, pas assez d'idées. Sur cette mission, l'écriture suivait. Ce qui ne suivait pas, c'était la mise en ligne, faite à la main, article par article.
Dans ce cas, ajouter des rédacteurs, humains ou non, ne fait qu'allonger la file. C'est la leçon que j'en garde : avant de produire plus, je mesure le stock d'articles prêts et pas encore en ligne. S'il augmente d'une semaine sur l'autre, c'est en aval de l'écriture que ça coince.
La question que je pose au client est simple : combien de textes terminés n'ont pas de date de publication ? Si la réponse fait hésiter, on a trouvé où travailler.
02Ce que publier veut dire, geste par geste
« Publier » a l'air d'un clic. En pratique, c'est une suite de petits gestes que personne n'a jamais écrits. Je propose de les lister avec la personne qui les fait, sur un article réel, en notant le temps de chacun. La liste ressemble souvent à celle-ci :
- coller le texte dans l'éditeur et refaire la mise en forme (intertitres, listes, gras) ;
- préparer l'image, la redimensionner, écrire son texte alternatif ;
- remplir le titre SEO, la description, l'extrait, le slug ;
- ajouter les liens internes et vérifier que les liens externes répondent ;
- choisir la catégorie, l'auteur, la date ;
- publier, puis attendre ou forcer le rafraîchissement du cache ;
- ouvrir la page publique pour vérifier qu'elle s'affiche ;
- mettre à jour le tableau de suivi.
Chaque geste prend peu de temps. Mis bout à bout, ils demandent un créneau et une personne qui connaît le CMS. C'est souvent cette dépendance qui crée le goulot, plus que la durée.
Une fois la liste écrite, je sépare deux familles. Ce qui se répète à l'identique (mise en forme, champs, cache, suivi) s'automatise. Ce qui demande du jugement (le titre, le choix de l'image, la relecture) reste humain, mais se prépare pour que la décision prenne une minute.
03Automatiser la publication, dans l'ordre
Je n'automatise pas tout d'un coup. Je suis un ordre qui ferme d'abord les étapes les plus longues et les plus risquées.
1. Écrire dans le CMS par son API
La plupart des CMS headless acceptent qu'un script crée ou modifie un contenu. Sur ce site, construit avec Next.js et Sanity, ma machine envoie l'article par l'API de mutations de Sanity. Elle est transactionnelle : un lot de modifications passe en entier ou pas du tout, ce qui évite une page à moitié remplie.
Le texte part dans un format structuré, pas en copier-coller. Les intertitres, les listes, la FAQ et les champs SEO arrivent à leur place. C'est le geste qui fait gagner le plus de temps.
2. Rafraîchir le cache de la page
Un site rapide sert souvent des pages mises en cache. Publier dans le CMS ne suffit donc pas : il faut dire au site que la page a changé. Next.js le prévoit avec revalidatePath, appelé depuis une route : la page est régénérée à la visite suivante. Ma publication appelle une route de revalidation protégée par un secret, puis charge la page une fois.
Dans la vidéo de Vercel qui présentait la revalidation à la demande, le problème est bien posé : un intervalle court régénère la page pour rien, un intervalle long fait attendre le lecteur. Mieux vaut régénérer quand la donnée change. La documentation de Vercel sur l'ISR précise un détail qui rassure : si la revalidation échoue, l'ancienne version reste servie et une nouvelle tentative a lieu 30 secondes plus tard.
3. Vérifier la page publique, comme un visiteur
C'est l'étape qu'on oublie. Un formulaire de CMS peut garder le contenu alors que rien n'est parti, et une page peut s'afficher pour l'équipe connectée mais pas pour les visiteurs, à cause du cache. Après chaque publication, je contrôle l'URL publique : réponse 200, image et texte alternatif présents, intertitres, FAQ, liens internes qui répondent, aucune adresse e-mail en clair.
Sur une mission, j'ai fait de ce contrôle la seule condition pour qu'une ligne du calendrier passe à « publié ». Tant qu'il n'est pas vert, l'article n'est pas considéré comme en ligne.
4. Mettre à jour le suivi automatiquement
Le calendrier de contenu doit refléter l'état réel. Le mien est un fichier versionné : la publication y inscrit le statut et la date. Si votre équipe pilote déjà tout dans Airtable, les automatisations d'Airtable fonctionnent avec un déclencheur, un enregistrement qui change de statut par exemple, et une ou plusieurs actions, dont un script ou un appel à une autre application. Zapier joue le même rôle entre des outils qui ne se parlent pas.
5. Prévoir les pannes
Une publication automatique doit pouvoir être relancée sans créer de doublon. Je journalise chaque étape, j'exporte l'ancien contenu avant de réécrire un article en ligne, et je ne fais jamais saisir d'identifiants par la machine. Quand la publication passe par le back-office d'un CMS piloté dans le navigateur, la session est vérifiée avant d'enregistrer ; si elle a expiré, le lot est sauté et le rapport me demande de me reconnecter.
04Garder une relecture humaine sans en faire le goulot
L'objection arrive vite : si tout part seul, qui relit ? J'ai choisi de ne pas attendre une validation humaine avant publication, parce que c'était justement le goulot. Un article qui passe le contrôle automatique est publié avec un statut « à relire ». Je le relis sur le site, puis je le passe à « Relu » dans le Studio, qui a une liste dédiée.
Ce choix ne tient que si le contrôle avant publication est sérieux. Le mien bloque ce qui se vérifie : structure, sources lues, liens, informations confidentielles, mots qui trahissent un texte généré. Je l'ai décrit dans l'article sur la relecture humaine d'une machine de contenu IA. La checklist de mise en production suit la même logique, côté projet.
Ce n'est pas une règle universelle. Pour les posts LinkedIn de Moonworkers, ma propre entreprise, je fais l'inverse : le post est créé en brouillon dans l'outil de planification, jamais programmé, parce que la date et le créneau ne m'appartiennent pas seuls. Le blog de Moonworkers, lui, publie deux articles par jour avec sa machine. La bonne frontière dépend de ce qu'une erreur coûte, et de qui doit décider.
05Ce que l'automatisation ne règle pas
Automatiser la publication rend plus rapide ce qui existe déjà. Si les articles sont faibles, ils seront en ligne plus vite, c'est tout. Google le dit sans détour dans ses consignes sur le contenu généré : produire beaucoup de pages qui apportent peu peut relever du contenu de masse, et il faut vérifier l'exactitude d'un texte généré avant de le publier.
Publier n'est pas non plus être indexé. Google rappelle, dans sa page sur les demandes d'exploration, que l'exploration peut prendre de quelques jours à quelques semaines et qu'une demande ne garantit rien. Je suis l'indexation à part, dans un reporting SEO qui part seul.
Enfin, ça coûte. Il faut un CMS qui expose une API, quelqu'un pour écrire et maintenir le script, et un contrôle qui évolue avec les erreurs rencontrées. Pour quatre articles par an, je ne le ferais pas : la liste de gestes écrite et une personne formée suffisent.
06Par où commencer lundi
Comptez les articles terminés qui ne sont pas en ligne, et notez depuis combien de temps chacun attend. Puis prenez le prochain et faites-le publier par la personne habituelle en notant chaque geste, avec sa durée.
Avec cette liste, vous saurez si le goulot est bien la mise en ligne, et quel geste automatiser en premier. Pour moi, c'est presque toujours l'envoi dans le CMS, puis le contrôle de la page publique. Si vous voulez qu'on regarde votre chaîne de publication ensemble, mes missions courtes de diagnostic et de construction sont faites pour ça, on peut en parler.