Automatiser le contenu : de l’exécution ponctuelle au pipeline qui publie tout seul

Une passe unique de diagnostic et de correction sert une fois. Un playbook, ce sont les mêmes étapes câblées pour tourner seules, sur un calendrier ou un déclencheur, jusqu’à l’article publié. Voici comment cela fonctionne sous le capot.

~7 min de lecture . Automatisation

Exécuter analyze_content, puis optimize_content, puis publier le résultat une fois, c’est utile. Faire tourner cette même séquence chaque semaine, pour chaque nouveau brouillon, sans que vous ouvriez l’outil à chaque fois, c’est de l’automatisation. Les playbooks d’AdAstra transforment une exécution ponctuelle en pipeline : un graphe d’étapes avec branchements, reprises et calendrier, qui se termine là où vous voulez voir atterrir le contenu fini.

De l’exécution ponctuelle au pipeline

Un playbook est un graphe orienté de nœuds et d’arêtes : des appels d’outils (analyze_content, optimize_content, optimize_headline, generate_keyword_ideas et les autres) reliés par des nœuds de contrôle de flux qui décident de la suite. Un playbook ne change rien à ce que fait un outil ; il change quand il s’exécute, dans quel ordre, et ce qu’il advient de sa sortie. La même séquence analyse puis optimisation que vous exécuteriez à la main devient une exécution que vous lancez une fois et réutilisez indéfiniment.

Sous le capot, une exécution parcourt le graphe depuis ses nœuds racines, exécute chacun d’eux et suit ses arêtes sortantes vers la suite. Chaque nœud rapporte son propre statut, ok ou erreur, et sa sortie ; les nœuds en aval référencent directement cette sortie, si bien qu’une étape ultérieure lit exactement ce qu’a produit un appel d’outil antérieur, sans que vous copiez des valeurs à la main.

Playbooks et contrôle de flux

Quatre types de nœuds donnent à un playbook une vraie logique au lieu d’une ligne droite. Un nœud if évalue un ensemble de conditions et envoie l’exécution dans sa branche vraie ou fausse. Un nœud switch vérifie une liste de règles nommées dans l’ordre et suit la première qui correspond, ou retombe sur une branche par défaut si aucune ne correspond. Un nœud filter vérifie une condition et soit laisse l’exécution continuer (pass), soit la branche s’arrête simplement là, sans rien en aval. Un nœud loop parcourt un tableau, soit élément par élément (each), soit par groupes de taille fixe (batch), en exécutant son corps une fois par élément ou par groupe, jusqu’à un nombre maximal d’itérations configuré.

Les conditions elles-mêmes sont partout la même brique : comparer une valeur à une autre avec des opérateurs comme égal à, contient, supérieur à, est vide ou correspond à une regex, combinés par ET ou OU. Un nœud avec deux branches entrantes ou plus, un losange où deux chemins se rejoignent, attend chaque branche qui va réellement s’exécuter avant de continuer, pour qu’une branche rapide ne prenne jamais de l’avance sur une plus lente encore en vol.

Les échecs sont gérés par nœud d’outil, pas par playbook. Chaque appel d’outil porte une politique de reprise, un nombre maximal de tentatives et une attente entre elles, soit un délai fixe, soit un backoff exponentiel qui double à chaque fois. Seules les erreurs classées comme transitoires, par exemple une panne passagère, ou comme limitation de débit sont réessayées ; une erreur permanente, comme une entrée invalide, échoue immédiatement. Une fois les reprises épuisées, le réglage onError du nœud décide de la suite : arrêter toute l’exécution, continuer quand même sur le chemin normal, ou continuer sur une branche d’erreur dédiée.

Planification et déclencheurs

Un playbook peut démarrer de trois façons. Un déclencheur manuel le lance à la demande, comme un outil exécuté à la main. Un déclencheur webhook donne au playbook sa propre URL protégée par jeton, pour qu’un système externe, ou vous, puisse lancer une exécution par une requête. Un déclencheur cron exécute le playbook sur un calendrier récurrent, défini comme une expression cron avec son propre fuseau horaire.

cron: "0 8 * * 1"
timezone: "Europe/Berlin"
# illustrative: every Monday at 08:00, Europe/Berlin

C’est un calendrier illustratif, pas une valeur par défaut figée : toute expression cron valide est acceptée, et elle est validée à l’enregistrement du déclencheur plutôt que découverte comme une surprise à l’exécution. La prochaine exécution d’un déclencheur cron est calculée à partir de l’expression et du fuseau horaire ensemble, si bien qu’un calendrier continue de vouloir dire « huit heures du matin » lors d’un changement d’heure au lieu de dériver d’une heure.

Un tick d’arrière-plan énumère tous les playbooks dus maintenant et exécute chacun à son tour, dans son propre domaine d’erreur et de délai, pour qu’une exécution bloquée ne fige pas le reste du lot. Le plus important est ce qui se passe si un playbook tourne encore quand son créneau suivant arrive : AdAstra réserve chaque exécution de façon atomique avant de la démarrer, de sorte qu’un playbook déjà en cours ne peut pas être déclenché une seconde fois par-dessus lui-même. Un créneau cron qui tombe en pleine exécution est enregistré comme ignoré, pas démarré comme une exécution qui se chevauche. Seule une exécution déclenchée par cron fait avancer le calendrier ; une exécution manuelle ne consomme jamais le créneau cron suivant.

Publier dans WordPress

La publication WordPress n’est pas un nœud du graphe de playbook ci-dessus : le registre d’outils dans lequel puise un playbook ne contient aucun outil WordPress, donc aucun nœud tool_call ne peut porter la sortie d’une exécution directement vers un site. Elle passe par une seconde surface d’automatisation, distincte. Demander à AdAstra d’automatiser la publication, tous les jours, toutes les semaines, toutes les deux semaines ou tous les mois, enregistre une tâche récurrente sur un profil WordPress connecté, indépendante du planificateur par graphe présenté plus haut.

Cette tâche s’authentifie comme partout ailleurs dans AdAstra : face au point d’entrée JWT du site (wp-json/jwt-auth/v1/token) avec vos identifiants WordPress, puis elle utilise le jeton obtenu pour créer l’article via l’API REST standard de WordPress (wp-json/wp/v2/posts), avec titre, contenu, étiquettes et, si elle est fournie, une image mise en avant téléversée d’abord dans la médiathèque. Vous choisissez le statut de l’article obtenu comme vous le feriez en publiant à la main : en ligne immédiatement, ou en brouillon pour qu’un humain relise d’abord.

Les garde-fous

L’automatisation ne désactive pas les contrôles qui s’appliquent partout ailleurs dans AdAstra. Une exécution planifiée ou déclenchée par webhook appelle les mêmes outils analyze_content, optimize_content et optimize_headline traités ailleurs : le même diagnostic en trois thèmes, les mêmes chiffres Google Ads ancrés, aucune donnée de mots-clés inventée pour remplacer une requête qui a échoué. Un échec dans un playbook n’est pas non plus un saut silencieux : il est enregistré sur le nœud avec sa classe d’erreur, et il arrête l’exécution ou emprunte le chemin d’erreur que vous avez configuré.

La prévention des exécutions en double compte surtout comme garde-fou, pas comme confort. Sans réservation atomique de chaque exécution, un déclencheur qui se chevauche pourrait lancer une deuxième passe sur un contenu qu’une première n’a pas fini d’optimiser, ou publier un brouillon en double depuis une exécution qui aurait dû être ignorée. Réserver l’exécution avant que le moindre outil ne tourne, c’est ce qui rend un pipeline planifié sûr à laisser sans surveillance.

En résumé

• Un playbook est un graphe d’appels d’outils et de nœuds de contrôle de flux ; il change quand et dans quel ordre les outils s’exécutent, pas ce que fait un outil donné.
• Les nœuds if, switch, filter et loop donnent à un playbook branchements, règles nommées, conditions d’abandon et itération par élément ou par groupe, tous pilotés par les mêmes lignes de conditions ET/OU.
• Chaque nœud d’outil porte sa propre politique de reprise (délai fixe ou backoff exponentiel, erreurs transitoires et de limitation de débit uniquement) et un réglage onError : arrêter, continuer normalement, ou continuer sur une branche d’erreur.
• Les playbooks démarrent depuis une exécution manuelle, un webhook protégé par jeton, ou un calendrier cron avec son propre fuseau horaire ; seule une exécution déclenchée par cron fait avancer ce calendrier.
• Une réservation atomique empêche un playbook de tourner deux fois à la fois ; un créneau cron qui tombe en pleine exécution est enregistré comme ignoré plutôt que démarré comme une seconde exécution qui se chevauche.
• La publication WordPress est une automatisation distincte, fondée sur une cadence, et non une étape de playbook : une tâche récurrente publie sur un site connecté via l’authentification JWT et l’API REST standard, en article en ligne ou en brouillon à relire.
• Les exécutions automatisées n’ont aucune exception sur la qualité des données : le même diagnostic ancré et les mêmes contrôles d’optimisation s’appliquent, et les échecs sont enregistrés et routés, jamais ignorés en silence.