Comment documenter un processus marketing pour qu’une IA puisse l’exécuter ?
Une IA n’exécute pas un métier parce qu’on lui donne une procédure de 40 pages. Elle a besoin d’entrées définies, de règles observables, d’une sortie vérifiable et d’un chemin pour les exceptions.
Nathalie StaelensGhostwriter et Rédactrice web
« On fait toujours comme ça. »
La phrase fonctionne très bien tant que la personne qui sait « comme ça » est dans la pièce.
Elle devient un problème le jour où l’on veut déléguer à une nouvelle recrue, à un prestataire — ou à un agent IA. Soudain, le métier se révèle rempli de petites décisions jamais écrites : « sauf si », « normalement », « tu verras », « dans ce cas-là on appelle le client ».
Pour qu’une IA puisse exécuter un processus marketing, il faut transformer le savoir tacite en règles observables : ce qui déclenche le travail, quelles entrées sont nécessaires, quelles étapes s’enchaînent, comment vérifier la sortie et dans quels cas l’agent doit s’arrêter et demander.
1. Commencez par le déclencheur
Quand le processus commence-t-il exactement ?
« Quand un client demande un post » est déjà mieux que « création de contenu ».
Le déclencheur peut être : formulaire reçu, Mission créée, date atteinte, statut modifié, document ajouté.
Sans déclencheur clair, l’agent ne sait pas quand il doit agir.
2. Listez les entrées obligatoires
Un processus marketing ne doit pas produire à partir du vide.
Pour un post : marque, objectif, offre, cible, réseau, format, sujet, deadline.
Définissez le comportement si une entrée manque : demander, utiliser une valeur par défaut autorisée, ou bloquer.
L’important est d’éviter l’invention silencieuse.
3. Écrivez les décisions comme des règles
« Choisir le meilleur format » est trop vague.
« Si objectif = pédagogie et le sujet nécessite au moins 4 étapes, préférer carrousel ; si le canal ne supporte pas le format, proposer série de posts » devient testable.
Une règle n’a pas besoin d’être mathématique. Elle doit rendre le raisonnement visible.
4. Donnez des exemples et contre-exemples
Une règle de ton devient plus claire avec deux textes acceptés et un texte refusé.
Un critère de lead qualifié devient plus clair avec trois cas.
L’exemple est particulièrement utile lorsque la frontière est difficile à décrire complètement.
5. Définissez les outils et permissions
L’agent peut-il lire Drive ? Modifier le CRM ? Envoyer un e-mail ? Publier ? Supprimer ?
Le processus doit préciser :
- outil ;
- action autorisée ;
- action interdite ;
- données accessibles ;
- validation requise.
Le principe du moindre privilège évite qu’une tâche simple dispose d’un pouvoir inutile.
6. Décrivez la sortie
Une sortie n’est pas « contenu créé ».
Elle peut être : « post LinkedIn de 1 500 caractères maximum, avec source des chiffres, CTA validé, statut à contrôler ».
Plus la sortie est observable, plus la QA devient possible.
7. Construisez la QA
8. Documentez les exceptions
Le client demande une urgence. Le format prévu n’est pas disponible. Une source se contredit. Le produit a changé de prix.
Ne cherchez pas à prédire l’univers entier.
Définissez plutôt les grandes catégories d’exception et la règle : bloquer, proposer une alternative, escalader.
9. Donnez un chemin d’escalade
Un processus sans escalade pousse l’agent à improviser.
Écrivez :
- pourquoi il bloque ;
- quelles informations il transmet ;
- à qui ;
- quel statut prend la Mission ;
- comment elle reprend après décision.
L’escalade doit être rapide pour l’humain.
10. Testez les cas qui cassent la procédure
Ne testez pas seulement le brief parfait.
Essayez : donnée manquante, conflit de règles, mauvais format, client non reconnu, deadline impossible, API indisponible.
Un bon processus n’est pas celui qui réussit le scénario idéal. C’est celui qui échoue proprement.
Transformez les corrections en règles
Chaque correction récurrente peut enrichir le playbook.
« Ne jamais promettre X. »
« Dans ce secteur, toujours demander Y. »
« Si le client refuse Z, proposer A. »
L’organisation devient progressivement plus explicite.
Où Alfie Suite utilise cette logique
Une Mission possède un contexte ; les agents ont des rôles ; les playbooks définissent les règles et préférences ; la QA vérifie avant livraison.
L’objectif n’est pas de donner à l’IA une encyclopédie de procédures. C’est de lui donner la tranche de processus nécessaire au bon moment.
Documenter pour l’IA est finalement un exercice de management. On découvre que ce que l’on appelait « expérience » est souvent une longue liste de décisions utiles qui n’avaient simplement jamais été écrites.