Partir d’un process qui existe déjà

Le meilleur premier agent automatise une tâche que quelqu’un de votre équipe fait déjà chaque semaine, à la main, avec un résultat que l’on sait juger. Vous connaissez les étapes, vous savez à quoi ressemble un bon résultat, et vous avez un point de référence pour comparer. Un agent construit sur un process que personne ne fait encore n’a rien de tout cela : quand il échoue, impossible de savoir si l’agent se trompe ou si c’est le process.

Avant d’écrire la moindre instruction, je fais donc trois choses : choisir la tâche, écrire comment elle se fait aujourd’hui, et définir ce qu’est un résultat terminé dans des termes qu’un contrôleur peut appliquer.

Choisissez la tâche avec une grille de score

Notez chaque tâche candidate de 1 à 3 sur cinq critères, puis additionnez. Au-dessus de 12, vous tenez un bon premier agent.

Critère	1	3
Fréquence	Quelques fois par an	Chaque semaine ou plus
Volume par passage	Un seul élément	Des dizaines ou des centaines
Résultat contrôlable	Seul un expert peut juger	Une règle ou un échantillon suffit
Coût d’une erreur	Public, cher, difficile à rattraper	Repéré avant de sortir de la maison
Savoir-faire existant	Dans la tête d’une seule personne	Écrit quelque part, même mal

Prenons un éditeur de logiciel de paie qui vend aux PME françaises, dont le commercial passe chaque lundi matin à qualifier les inscrits à l’essai gratuit de la semaine passée : vérifier l’entreprise, estimer sa taille, décider qui mérite un appel. C’est hebdomadaire, cela fait 50 à 100 lignes, un responsable commercial juge un échantillon en dix minutes, et une mauvaise étiquette coûte un appel manqué, pas une erreur publique. Le score est élevé.

Écrire vos posts LinkedIn obtient un score plus bas sur le coût d’une erreur, puisque tout est public. Cela peut marcher, comme le montre le chapitre 16, mais cela demande plus de contrôles qu’un premier projet ne devrait en porter.

Si vous ne savez pas quelle tâche choisir, cherchez le goulot. La méthode pour trouver le goulot du funnel s’applique ici : automatisez là où l’on perd du temps sur l’étape qui limite la croissance.

Écrivez comment elle se fait aujourd’hui

Asseyez-vous à côté de la personne qui fait la tâche, ou enregistrez une session, et notez chaque étape telle qu’elle la fait réellement. Pas telle que la fiche process la décrit. C’est dans l’écart entre les deux que l’agent échouera.

Pour chaque étape, notez cinq choses : ce qui entre, ce qu’elle regarde, ce qu’elle décide, ce qui sort, et les exceptions qu’elle gère sans y penser. Les exceptions comptent le plus. « Si l’e-mail est une adresse Gmail, je cherche la personne sur LinkedIn » est exactement le genre de règle que personne n’écrit et dont tout agent a besoin.

Voici à quoi ressemble cette fiche pour l’exemple des inscrits.

process: qualify_trial_signups
owner: SDR team
frequency: weekly, Monday
input: signups.csv  # email, name, company field, signup_date
steps:
  - id: 1
    do: Get the company domain from the email
    exception: free email provider -> search the name + company field
  - id: 2
    do: Look up headcount and country from a company data source
    exception: no match -> mark "unknown", never guess
  - id: 3
    do: Check the ICP (France, 10 to 250 employees, no payroll provider in-house)
    decision: fit | maybe | no_fit
  - id: 4
    do: Write one line on why
output: signups_qualified.csv  # adds fit, reason, source_url
time_today: about 2 hours per week

Regardez ce qui s’y trouve déjà : d’où viennent les faits (une source de données, jamais la mémoire), la porte de sortie unknown, et le temps passé aujourd’hui. Cette dernière ligne est votre point de référence. Sans elle, vous ne saurez jamais si l’agent a fait gagner quoi que ce soit.

Découpez ensuite les étapes selon l’outil que chacune demande, comme l’explique le chapitre sur les outils. Ici, l’étape 1 est un script, l’étape 2 un outil de données, et seules les étapes 3 et 4 ont besoin d’un modèle.

Définissez ce qu’est un bon résultat

« Bien qualifier les inscrits » ne donne rien à appliquer à un contrôleur. Écrivez une définition qu’un contrôleur, humain ou machine, peut appliquer sans vous demander.

Écrivez-la en trois couches.

Couche	Exemple	Contrôlée par
Format	Chaque ligne a fit, reason, source_url ; fit prend l’une de trois valeurs	Un script
Contenu	reason cite un fait trouvé dans la source, pas une supposition	Un relecteur ou un juge indépendant
Qualité	Sur un échantillon de 30 lignes, le responsable commercial valide au moins 27 étiquettes	Un humain, chaque semaine au début

Les seuils de la troisième ligne sont à vous de les fixer, avant le premier passage. Si vous les fixez après avoir vu les résultats, vous les calerez sur ce que l’agent a obtenu.

Rassemblez aussi de vrais exemples dès maintenant : cinq lignes bien étiquetées, et trois lignes où une personne pressée se tromperait. Ils deviendront les exemples du fichier d’instructions, traité dans le chapitre suivant, puis les cas de test figés que vous relancez après chaque modification.

Laissez les étapes humaines à leur place

Cartographier le process montre aussi quelles étapes doivent rester humaines. Dans le plugin d’outbound que j’ai publié pour Claude Code, le flux suit les étapes que toute personne qui fait de l’outbound connaît déjà : import, enrichissement, message, séquence, envoi dans l’outil, puis revue hebdomadaire des réponses. L’agent fait la plupart d’entre elles. Pour la séquence, il conseille la structure et livre le contenu, et la personne monte la séquence dans son outil d’envoi. L’envoi vers l’outil comporte un contrôle qui refuse d’écraser un lead déjà présent dans une campagne active. Chacun de ces choix répond à la même question : que coûte une erreur à cette étape, et qui la remarquerait ?

Faites de même sur votre carte. Marquez chaque étape « l’agent fait », « l’agent propose, un humain valide » ou « humain seulement ». Commencez avec plus de validations que nécessaire, et retirez-les quand l’échantillon hebdomadaire ne trouve plus d’erreurs.

Décidez à l’avance quand arrêter

Une définition du résultat demande aussi une condition d’échec. Écrivez ce qui vous ferait arrêter : l’accord sur l’échantillon reste sous votre seuil après trois semaines de corrections, ou le temps gagné part dans la relecture. Arrêter est un résultat valable. Sur le marketing de Derrick, qui tourne sur des agents (j’ai cofondé Derrick), un levier Reddit a été lancé puis abandonné en octobre 2026. Un arrêt s’accepte facilement quand ses motifs étaient écrits avant le départ.

Prochaine étape : notez trois tâches candidates avec la grille, prenez la gagnante, et écrivez sa fiche process et sa définition du résultat en trois couches. Chronométrez le prochain passage manuel, pour avoir un point de référence avant que l’agent existe.