Notre chaîne de publication : du brief à l’article en ligne, pannes comprises.

01Avant le projet.

Le contexte.

Un blog ne compte que s’il est tenu dans la durée : écrire, mettre en forme, publier, vérifier, chaque semaine. Chez OTTOPILOTE, ces gestes sont confiés à une chaîne automatique, qui publie les articles d’ottopilote.com et ceux de blogs clients.

Une chaîne comme celle-là échoue rarement d’un bloc : elle échoue en silence, à un endroit qu’on ne regarde pas. Cette étude la raconte avec ses pannes, datées, parce que ce sont elles qui ont fait la version d’aujourd’hui.

02Le périmètre livré.

Ce qu’on a construit.

1. 01

   Le plan

   Chaque article a sa date et son heure de publication, fixées à l’avance.

2. 02

   La rédaction

   La nuit, l’article est rédigé ou mis en forme par IA, dans une copie à part du site, puis proposé à la relecture.

3. 03

   Les contrôles

   Le site entier est contrôlé avant chaque mise en ligne ; quand plusieurs articles modifient les mêmes listes du site, leurs changements sont conciliés un par un.

4. 04

   La relecture

   Pour un blog client : relecture par l’agence, puis validation du gérant depuis son espace. Pour le nôtre, la chaîne refuse, en le motivant, un article qui n’apporte rien au top 10.

5. 05

   La publication

   Une minuterie passe toutes les 15 minutes : un article programmé à 12 h 00 part au plus tard à 12 h 15.

6. 06

   La vérification

   Chaque matin, Cockpit vérifie en ligne les articles parus ; un échec crée une notification.

03Ce qu’il y a dessous.

La stack.

• CockpitLe plan de publication et les notifications d’échec
• IA (Claude)La rédaction ou la mise en forme des articles
• GitHubLe code du site, et chaque article proposé à la relecture avant sa mise en ligne
• Notre serveurLes minuteries : rédaction la nuit, publication toutes les 15 minutes
• VercelL’aperçu de chaque article, puis la mise en ligne
• AstroLe site ottopilote.com, statique

04Daté, incidents compris.

Le déroulé, daté.

1. 18/08/2026, 1 h

   L’accès à GitHub expire

   L’accès de la chaîne à GitHub expire, GitHub refuse la connexion, et l’outil qui garde les identifiants efface son propre fichier. Les scripts se terminent pourtant comme après un passage réussi, même après un échec total : 7 alertes restent non lues pendant 8 jours, et aucun article ne paraît après celui du 16/08/2026. Rattrapage : 5 articles.

2. 11/09/2026

   Trois articles prêts, un publié

   Les articles modifient 4 listes communes du site : en publier plusieurs demande de concilier leurs changements, un article après l’autre. L’outil qui les conciliait enregistrait son travail là où le contrôle suivant ne regardait pas : chaque tentative échouait.

3. 16/09/2026

   Neuf erreurs dans un article d’essai

   Essai à blanc d’un article fiscal pour un blog client, rédigé par un outil d’IA puis mis en forme par Claude : la relecture trouve 9 erreurs factuelles, dont un lien mort vers service-public, une affirmation non sourcée, deux prestations absentes du site et une phrase en double. Les cases du formulaire fiscal étaient justes. Depuis, l’agence relit avant le client.

4. 22/09/2026

   À l’heure près

   La publication passe à une minuterie de 15 minutes : un article programmé à 12 h 00 part au plus tard à 12 h 15. Le changement de la base de données a été répété deux fois à blanc avant d’être appliqué.

5. 02/10/2026

   54 enregistrements pour un article

   Pour un article d’un blog client, le contrôle recréait un fichier à chaque passage, et la chaîne enregistrait tout ce qui avait changé : 54 enregistrements « image », et autant de notifications d’échec. Corrigé : la chaîne n’enregistre plus que les deux fichiers voulus, et une même notification ne part plus qu’une fois par jour.

6. 02/10/2026

   Moins d’articles, et le droit de refuser

   Six articles de septembre sont jugés sans élément propre. Le rythme passe à 2 articles par semaine, et la chaîne refuse, en le motivant, un article qui n’apporte rien au top 10.

05Mesurés ou vérifiables.

Les résultats, mesurés.

06Le retour d’expérience.

Ce qu’on referait différemment.

1. 01

   Un script qui échoue doit le dire

   En août, une panne totale est passée pour un succès, et 7 alertes sont restées non lues pendant 8 jours. Dès le premier script, on ferait signaler tout échec comme un échec, et on enverrait l’alerte à quelqu’un plutôt que de la laisser dans une liste.

2. 02

   Tester le garde-fou sur un vrai cas

   Le contrôle ne regardait pas là où l’outil précédent enregistrait son travail : il a bloqué toutes les publications groupées. Un essai sur un vrai cas l’aurait montré le premier jour.

3. 03

   Ne jamais laisser un automate enregistrer « tout »

   Un fichier recréé à chaque passage a donné 54 enregistrements. Un automate enregistre les fichiers qu’il a voulu changer, et eux seuls.

4. 04

   Une relecture humaine avant le client, dès le premier article

   Neuf erreurs factuelles dans un article d’essai : on mettrait l’agence entre l’IA et le client dès le départ, pas après un essai.

5. 05

   Le droit de refuser, dès le départ

   13 articles publiés en septembre, dont six sans élément propre. Une chaîne qui ne peut pas refuser publie aussi ce qu’elle n’aurait pas dû.

07Avant de nous écrire.

Pour qui ce type de projet est pertinent.

Pour un blog alimenté chaque semaine, voyez notre offre SEO et GEO. Si c’est un autre processus que vous voulez automatiser, notre guide sur l’automatisation des processus explique par où commencer, et la fiche automatisation en donne le vocabulaire.