Un ordonnanceur n’est pas un rédacteur autonome
« Prends le Markdown d’origine, corrige-le et publie-le. »
Sur le papier, c’est presque trivial.
Puis on automatise.
Il faut lire le Markdown, décider s’il est prêt, vérifier 12 langues, supprimer des titres parasites, contrôler les liens, publier, ouvrir la vraie page, revenir en arrière si quelque chose casse, trouver la cause, corriger, relancer et vérifier que la correction n’a rien cassé ailleurs.
La chaîne de production vient soudain d’être promue rédactrice en chef.
Le problème n’est pas que Cloudflare Workers, les tâches planifiées ou GitHub Actions soient mauvais.
Ils sont conçus pour un autre type de travail.
L’automatisation classique excelle à répéter des procédures connues. Une chaîne de contenu reçoit au contraire des textes différents et des erreurs différentes. Il faut parfois lire, comprendre, corriger et vérifier.
C’est davantage un problème d’agent qu’un problème de cron.
1. Le même pipeline ne signifie pas le même travail
Une usine d’articles ressemble à une production en série.
Entrée : Markdown. Sortie : article publié.
On imagine donc volontiers le même processus répété cent fois.
Mais un texte n’est pas une vis standardisée.
L’article A a un mauvais titre. Le B n’a que 11 langues sur 12. Le C est traduit, mais utilise des mots que personne ne chercherait localement. Le D a publié une note SEO interne. Le E possède un lien d’affiliation valide placé à un endroit éditorialement absurde. Le F a bien été publié, mais son état reste « en cours ».
Tout s’est produit dans le même pipeline.
Mais les réparations sont différentes.
Quand l’entrée change à chaque fois, la forme de l’échec change aussi.
2. Les ordonnanceurs sont excellents pour exécuter du travail connu
GitHub Actions exécute des workflows définis à l’avance lors d’événements, d’un déclenchement manuel ou selon un calendrier.[1]
ChatGPT Scheduled Tasks lance également des tâches à une heure donnée ou lors d’événements pris en charge.[2]
Cloudflare Workers est très efficace pour traiter des requêtes, exécuter des tâches périodiques et orchestrer des services.
Ces systèmes répondent très bien à :
« Quand faut-il démarrer ? » « Quel script faut-il lancer ? » « La commande a-t-elle réussi ? » « Que faire si cette condition est vraie ? »
Mais ce ne sont pas les mêmes questions que :
« Ce titre ressemble-t-il trop à une traduction automatique ? » « Cette section est-elle correcte mais inutile au lecteur ? » « Le lien fonctionne, mais pourquoi est-il ici ? » « L’échec d’aujourd’hui est-il vraiment le même qu’hier ? »
Un ordonnanceur a une horloge.
Il n’a pas automatiquement l’intuition d’un éditeur.
3. Le plus difficile est de fermer toute la boucle d’amélioration
Le problème n’est pas simplement de modifier quelque chose.
Il faut :
détecter l’échec, diagnostiquer la cause, corriger, relancer, vérifier le résultat réel, chercher les effets secondaires, et essayer une autre hypothèse si la première était fausse.
Un humain fait cela presque naturellement.
En automatisation, chaque transition doit être pensée.
Les cas les plus pénibles sont les demi-succès.
La page est publiée, mais l’état n’a pas été mis à jour.
La traduction est terminée, mais une langue est vide.
Le dépôt a changé, mais la production n’a pas suivi.
Relancer aveuglément peut créer des doublons.
Une automatisation robuste ne vise donc pas seulement « ne jamais échouer ».
Elle vise :
pouvoir rejouer sans abîmer le résultat final.
Cloudflare Workflows propose des étapes durables, la persistance des résultats et des mécanismes de nouvelle tentative, avec des recommandations pour que les opérations restent sûres lorsqu’elles sont répétées.[3][4]
4. Cloudflare sait récupérer un processus, mais récupérer n’est pas juger un texte
Cloudflare Workflows peut conserver l’état d’un traitement en plusieurs étapes, rejouer la partie qui a échoué et reprendre après les étapes déjà terminées.[3]
Cloudflare Queues peut retenter des messages et envoyer les échecs répétés vers une Dead Letter Queue.[5]
C’est parfait pour :
une panne réseau temporaire, un appel API qui échoue, un délai dépassé, un message qui refuse de passer, un traitement à reprendre plus tard.
Mais un autre problème ressemble à ceci :
« L’espagnol est compréhensible, mais personne ne chercherait cette formulation. »
« Le contenu est juste, mais ce sous-titre rend l’article moins bon. »
Passer de trois à dix tentatives ne crée pas de jugement éditorial.
On risque simplement de reproduire dix fois la même erreur avec une belle régularité.
Réessayer n’est pas réfléchir.
5. GitHub Actions est un excellent établi, pas un rédacteur autonome
GitHub Actions est très bon pour les tâches déterministes.
Lancer des tests. Vérifier des fichiers. Construire. Déployer selon des règles claires. Exécuter un script à intervalles réguliers.
C’est son terrain.[1]
Mais Actions ne lit pas un article en se disant :
« En fait, le problème n’est pas le titre, c’est l’introduction. »
On peut bien sûr appeler une IA depuis un workflow.
Mais le vrai problème devient alors :
quel contexte fournir, ce que l’IA a le droit de modifier, comment vérifier le résultat, et comment reprendre après un échec.
Demander à une perceuse électrique de présider la réunion éditoriale, puis lui reprocher son silence, serait légèrement injuste.
6. Mieux vaut séparer le chemin normal et les exceptions que poursuivre 100 % d’automatisation
Une chaîne réaliste a besoin de deux voies.
Voie normale : automatiser ce qui est vérifiable
La machine peut contrôler :
- présence des fichiers obligatoires
- 12 langues disponibles
- champs non vides
- format des URL
- identifiants uniques
- succès de la commande de publication
- accessibilité de la page finale
Workers, scripts et Actions sont très bons pour cela.
Voie d’exception : isoler l’échec et continuer
Un article défectueux ne devrait pas arrêter tout le lot.
Enregistrer la raison. Mettre l’article de côté. Passer au suivant.
Par exemple :
- langue manquante
- structure invalide
- lien défectueux
- échec de publication
- révision sémantique nécessaire
- cause inconnue
Si 90 articles sur 100 passent automatiquement, publiez les 90.
Inutile de mettre 90 articles sains au piquet parce que dix traversent une crise existentielle.
Ignorer l’exception et continuer.
7. Confier les exceptions à un agent capable de lire le dépôt
Les exceptions ont souvent besoin de lecture, de raisonnement, d’édition et de vérification.
C’est là qu’un agent de programmation devient utile.
La documentation de Codex Cloud décrit des tâches effectuées dans un environnement de projet préparé, avec investigation de bugs, modification de code, exécution de tests et poursuite d’une même tâche cloud depuis des appareils pris en charge.[6]
Dans une usine de contenu, l’agent devient l’atelier de réparation :
prendre l’article en échec, lire le Markdown d’origine, examiner la sortie, lire le journal de l’échec, regarder le code si nécessaire, corriger, lancer les contrôles, republier, et vérifier la vraie page.
Il n’est pas nécessaire de dépenser du raisonnement avancé sur chaque succès banal.
La machine gère le routinier.
L’agent gère l’étrange.
8. Quand une exception devient fréquente, la transformer en règle automatique
La voie des exceptions ne doit pas devenir une décharge permanente.
Si le même problème revient souvent, ce n’est plus une exception. C’est un motif.
Si une langue manque régulièrement, ajoutez un contrôle automatique.
Si le même sous-titre indésirable apparaît souvent, ajoutez un validateur.
Si la publication réussit mais que l’état se met mal à jour, vérifiez la production puis réparez automatiquement l’état.
L’ordre sain est :
faire tourner l’usine, collecter les vrais échecs, laisser l’agent réparer les cas rares, repérer les motifs, automatiser seulement les motifs récurrents.
Essayer de prévoir tous les échecs avant la première publication est un excellent moyen de construire l’usine éternellement sans jamais produire.
Conclusion : l’ordonnanceur est le convoyeur, l’agent est l’atelier
Cloudflare, les tâches planifiées et GitHub Actions paraissent décevants lorsqu’on attend d’eux le comportement d’un rédacteur autonome.
Mais les rôles sont différents.
Le système planifié doit :
démarrer, faire des contrôles objectifs, faire avancer les cas normaux, isoler les échecs, et garder la ligne en mouvement.
L’agent doit répondre :
« Pourquoi cet article est-il bizarre ? » « Que faut-il corriger ? » « La correction a-t-elle vraiment fonctionné ? »
L’architecture pratique est simple :
Automatiser le chemin facile. Ne pas laisser une exception bloquer le lot. Envoyer les exceptions à l’agent. Transformer plus tard les exceptions répétées en règles automatiques.
L’usine de contenu n’avait pas besoin d’un convoyeur capable de penser à tout.
Elle avait besoin d’un convoyeur qui ne s’arrête pas et d’un atelier intelligent pour les cartons sortis de la ligne.
Références (6)
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
