Marketing ops as code : modéliser un événement comme une machine à états

Un événement marketing peut être décrit comme une suite de tâches, mais cette représentation reste souvent trop vague pour être automatisée proprement. « Préparer les invitations », « valider le contenu » ou « effectuer le suivi » ne disent pas précisément ce qui autorise le passage à l’étape suivante, ni quelle preuve doit être conservée.

Le sujet du marketing ops as code devient alors plus proche de la conception d’un workflow que de la simple gestion de projet. Dans son billet consacré à l’automatisation d’événements, GitHub présente l’idée selon laquelle un travail décrit peut devenir automatisable. Le dossier disponible ne fournit ni implémentation complète ni résultat mesuré. Il permet toutefois de retenir un principe de méthode : avant de demander à un agent ou à une action GitHub d’agir, il faut rendre le processus suffisamment explicite pour qu’une autre personne puisse le relire.

L’angle proposé ici est volontairement technique : représenter l’événement comme une machine à états, où chaque transition possède une condition, une sortie attendue et un niveau de validation. Il ne s’agit pas de prétendre qu’un événement réel a été automatisé, mais de fournir un modèle que l’équipe peut adapter et tester localement.

Pourquoi une liste de tâches ne suffit pas

Une liste décrit généralement ce qui doit être fait, pas le moment où une action devient légitime. Une tâche intitulée « publier la page de l’événement » peut dépendre d’un contenu relu, d’une date confirmée, d’un lien fonctionnel et d’une décision humaine. Si ces dépendances restent implicites, une automatisation peut détecter qu’une tâche est ouverte sans savoir si elle peut avancer.

La machine à états impose une distinction utile entre l’existence d’une tâche et son autorisation d’exécution. Une étape peut être présente dans le dépôt, mais bloquée parce qu’une entrée manque, qu’une validation n’a pas été enregistrée ou qu’une action précédente a échoué.

Cette représentation aide aussi à traiter les cas ordinaires que les workflows marketing masquent souvent :

• une information attendue n’est pas encore disponible ;
• une proposition a été préparée mais pas approuvée ;
• une action externe a été refusée ou annulée ;
• une étape terminée doit être vérifiée après exécution ;
• une modification rend une ancienne validation obsolète.

Définir les états avant de choisir l’automatisation

Le premier livrable ne devrait pas être un agent, un script ou une règle GitHub Actions. C’est une liste courte d’états compréhensibles par l’équipe. Pour un événement, un modèle de départ pourrait distinguer la demande initiale, la préparation, la validation, l’exécution et la vérification.

Chaque état doit répondre à trois questions : quelles informations sont disponibles, quelle action est permise et quelle preuve autorise la transition suivante ? Si la réponse reste ambiguë, l’étape doit être précisée avant toute automatisation.

Ce tableau ne constitue pas une recette universelle. Sa fonction est de rendre visibles les contrats entre les étapes. Une équipe peut supprimer un état, en ajouter un autre ou imposer une validation différente selon le risque de l’action.

Associer une transition à une preuve

Une transition ne devrait pas être déclenchée uniquement parce qu’un libellé a changé. Elle doit reposer sur une preuve adaptée à la tâche. Pour une préparation de contenu, la preuve peut être la présence d’un fichier relu. Pour une action externe, elle doit aussi préciser qui a autorisé l’exécution, sur quel périmètre et avec quelle règle de retour.

Cette logique évite de confondre trois événements distincts : une proposition a été produite, une proposition a été approuvée et une action a été exécutée. Une IA peut contribuer au premier événement. Elle peut éventuellement vérifier des conditions déterministes avant le second. La décision d’autoriser une action sensible doit rester attribuée à une personne ou à une règle explicitement définie par l’équipe.

Un format structuré peut aider à rendre ces transitions exploitables. Il peut contenir un identifiant d’événement, un état courant, les champs nécessaires, la preuve attendue, le rôle de validation et la date de la dernière modification. L’objectif n’est pas de créer un schéma complexe, mais d’empêcher qu’une phrase libre soit interprétée comme une permission.

Illustration : séparer proposition, approbation et exécution

Dans un scénario hypothétique, une règle détecte qu’une étape de préparation est complète. Elle crée alors une proposition dans une pull request ou une issue. Cette proposition contient les informations utilisées, la sortie attendue et les éléments manquants. Elle ne déclenche aucune action externe.

Une personne relit ensuite le périmètre. Elle peut approuver, demander une correction ou refuser la proposition. L’approbation ne vaut que pour les éléments décrits. Si le contenu, le destinataire ou l’action change, une nouvelle validation est nécessaire. Une étape séparée exécute ensuite l’action autorisée et conserve son résultat.

Ce découpage réduit le risque d’une automatisation qui transformerait une information incomplète en décision. Il facilite aussi le diagnostic : lorsque le workflow échoue, l’équipe peut identifier si le problème vient de la préparation, de la validation, de l’exécution ou de la vérification.

Concevoir des transitions qui peuvent être annulées

Un workflow versionné doit prévoir les retours en arrière avant sa première utilisation. Une transition peut être techniquement valide et pourtant produire un résultat indésirable. L’équipe doit donc savoir suspendre la règle, revenir à l’état précédent lorsque c’est possible et conserver la trace de l’incident.

1. Limiter chaque transition à une action clairement nommée.
2. Refuser le passage si un champ obligatoire ou une preuve manque.
3. Placer les actions externes derrière une validation distincte.
4. Enregistrer le résultat obtenu, y compris une erreur ou une annulation.
5. Prévoir un état de blocage qui n’est pas confondu avec un oubli.
6. Tester la désactivation du workflow avant de l’élargir.

Le retour arrière ne signifie pas forcément annuler une action déjà réalisée. Il peut consister à empêcher les doublons, désactiver une règle, restaurer une configuration précédente ou créer une tâche de correction. La possibilité réelle dépend du système concerné et doit être décrite sans promesse excessive.

Commencer par un contrat de transition

Un premier pilote peut se limiter à une seule transition sans effet externe : passer d’une fiche incomplète à une proposition prête pour revue. L’équipe peut alors vérifier que les champs sont compris, que les refus restent visibles et que les personnes savent reprendre le travail sans reconstruire le contexte.

Une fois ce contrat stabilisé, une étape de validation peut être ajoutée. L’exécution externe ne devrait venir qu’après l’observation de ces deux premières étapes. Cette progression distingue une méthode documentée d’un système réellement éprouvé : tant qu’aucun essai contrôlé n’a été exécuté, il faut parler de protocole proposé et non de résultat.

Pour conserver les décisions et les limites de chaque transition, l’équipe peut s’appuyer sur une documentation technique adaptée au changement IA. Si le workflow produit des données structurées, les règles de contrat et de validation doivent également être traitées comme des artefacts relisibles, plutôt que comme de simples consignes enfouies dans un prompt.

Le marketing ops as code devient ainsi une discipline de modélisation avant d’être une promesse d’autonomie. Une équipe ne cherche pas à automatiser tout l’événement d’un seul bloc. Elle décrit les états, borne les transitions, exige des preuves et augmente progressivement le niveau d’action autorisé.