Le problème du 80/80 : pourquoi j’écris mes automatisations comme si je briefais un stagiaire

Avant, je pensais que « laisser l’IA s’en occuper » était tout l’intérêt de l’automatisation. Puis j’ai vu une demande parfaitement raisonnable se transformer en agenda rempli de trains imaginaires, de correspondances impossibles et de créneaux de trajet qui avaient l’air sûrs d’eux… et qui étaient complètement faux.

C’est la vraie leçon d’un appel avec Nikki, qui habite à Fontainebleau et a des rendez-vous partout dans Paris. Son problème a l’air simple : chaque fois qu’une réunion est ajoutée ou déplacée, son agenda devrait bloquer automatiquement le bon temps de trajet. En pratique, c’est le genre de workflow qui révèle toutes les faiblesses de l’automatisation « l’IA d’abord ».

Le piège du « l’IA va me le construire »

Voici ce que Nikki avait déjà essayé avant notre appel : elle avait demandé à une IA de générer l’automatisation de bout en bout. Le résultat avait l’air soigné, mais il inventait des horaires de train et faisait une erreur classique : il programmait un train retour en plein milieu de sa journée de travail.

Quand tu demandes à une IA de « construire l’automatisation », tu lui demandes en fait de faire deux métiers à la fois. D’abord, comprendre tes règles et tes cas particuliers. Ensuite, traduire ces règles en un système qui fonctionne, avec des déclencheurs, de la récupération de données et des effets corrects.

J’ai appris à mes dépens que chacun de ces deux métiers est en général juste à environ quatre-vingts pour cent. Et quatre-vingts pour cent de quatre-vingts pour cent, ce n’est pas « plutôt bien ». C’est pile ou face.

C’est pour ça que je vais continuer à répéter le même conseil ennuyeux : ne sous-traite pas la logique. Maîtrise la logique, puis utilise l’IA pour l’exécuter.

Le vrai cas d’usage : des créneaux de trajet entre Fontainebleau et Paris

Les exigences de Nikki étaient strictes, et pour une bonne raison. Il n’y a qu’un train par heure entre Fontainebleau et Paris, donc se tromper de vingt minutes n’est pas « un peu agaçant » : ça veut dire rater le train et faire dérailler le reste de la journée.

Dans Paris, les règles s’inversent. Parfois, le plus rapide, c’est le métro. Parfois, c’est la marche. Parfois, c’est un taxi. Elle veut simplement l’itinéraire le plus rapide pour arriver à l’heure à la réunion suivante.

Ajoute maintenant le détail le plus humain de tous : son planning change sans arrêt. Des réunions bougent la veille. Des lieux sont ajoutés au dernier moment. Des adresses manquent. L’automatisation ne peut donc pas tourner deux fois par jour en espérant que tout se passe bien. Elle doit réagir à la réalité au fur et à mesure qu’elle change.

La seule approche fiable que j’ai trouvée : des prompts structurés que tu écris toi-même

Quand nous avons construit le workflow ensemble, nous n’avons pas essayé d’obtenir un générateur d’automatisations à coups de prompts. Nous avons fait quelque chose de plus mécanique et, franchement, de plus ennuyeux.

Nous avons écrit un prompt structuré dans Notion et utilisé un déclencheur d’agenda qui se lance chaque fois qu’un événement est créé ou modifié. Le prompt, c’est le cahier des charges. L’automatisation, c’est l’exécution.

Je structure ces prompts de la même façon à chaque fois, parce que ça oblige à être clair et que ça empêche l’IA d’improviser quand elle ne devrait pas.

Objectif

J’écris un paragraphe qui décrit en langage courant ce que l’automatisation doit faire, comme si je briefais un stagiaire brillant. Pas un développeur. Pas un devin. Un stagiaire.

Ici : agir comme un assistant de planification des trajets qui ajoute, met à jour ou supprime des créneaux dans l’agenda, pour que Nikki ait toujours le bon temps de trajet entre chez elle, ses réunions et le retour à la maison.

Processus

Ensuite, je décris comment elle doit se comporter quand elle s’exécute. Pour Nikki, le détail le plus important, c’est qu’elle doit prendre en compte toute la journée, pas une réunion isolée.

Quand une réunion est modifiée, l’automatisation doit regarder toutes les réunions de la journée, comprendre où se situe la réunion modifiée dans l’enchaînement, et créer ou ajuster le créneau entre cette réunion et la destination pertinente suivante.

Règles

C’est ici qu’on tue l’ambiguïté. Qu’est-ce qui compte comme « la maison » ? Quand impose-t-on les transports en commun ? Et si l’adresse manque ? Et si c’est la dernière réunion ? Et si c’est la première ?

Pour Nikki, nous avons encodé la logique ainsi : la première réunion de la journée part de la maison, la dernière a la maison pour destination, et les réunions intermédiaires calculent l’itinéraire de la réunion modifiée vers la suivante. Nous lui avons aussi fait ignorer les événements sans adresse, parce que deviner est pire que ne rien faire.

Connaissances

Enfin, tu donnes à l’automatisation les faits stables qu’elle ne devrait pas avoir à deviner. L’adresse de Nikki. L’adresse de la gare. Toutes les préférences qui ne changent pas d’un jour à l’autre.

Cette section paraît évidente, mais c’est de là que viennent beaucoup de « ratés de l’IA ». Les gens s’attendent à ce que le modèle se souvienne de choses qu’ils n’ont jamais écrites.

Les déclencheurs comptent plus qu’on ne le croit

Une petite décision, mais importante : nous avons utilisé un déclencheur sur la création ou la modification d’un événement plutôt qu’un planning.

Les plannings rassurent, mais c’est de la paresse. Ils partent du principe que le monde se met à jour à ton rythme.

Ce n’est pas le cas de l’agenda de Nikki. Le changement a lieu quand la réunion bouge, c’est-à-dire exactement quand l’automatisation doit s’exécuter. Déclencher sur les événements d’agenda, c’est ce qui permet de garder des créneaux de trajet justes sans « reconstruire la journée » en permanence.

La limite que nous avons rencontrée : durée totale du trajet et planification des trains, ce n’est pas pareil

Nous avons testé le workflow et les bases fonctionnaient : l’intégration renvoyait des temps de trajet raisonnables et l’automatisation créait les créneaux.

Puis nous sommes tombés sur le cas limite qui compte vraiment : le résultat transports en commun de Google Maps nous donnait la durée totale du trajet, pas le détail train par train avec les horaires de départ exacts.

Si tu prends le train deux fois par jour sur une ligne à forte fréquence, tu peux t’en accommoder. Si tu as exactement un train par heure, non.

Nous nous sommes donc mis d’accord sur un contournement un peu bricolé, mais pratique : considérer la gare comme « la maison », puis ajouter une marge pour tenir compte du court trajet en voiture entre la vraie maison et la gare.

Comme ça, l’automatisation optimise la partie que nous savons calculer de façon fiable, et nous arrêtons de faire semblant d’avoir des données que nous n’avons pas.

Le principe que je veux que tu me voles

Si tu ne retiens qu’une chose de cette histoire, que ce soit celle-ci : ne demande pas à l’IA d’inventer ton workflow.

Écris le workflow comme un cahier des charges. Rends le déclencheur explicite. Énonce tes règles comme si tu te disputais avec ton futur toi. Puis laisse l’IA faire ce qu’elle fait bien : traduire ton intention en actions cohérentes.

C’est comme ça que tu sors de la zone du pile ou face.

Et oui, cette automatisation de trajets est « assez compliquée ». Je ne prétends pas qu’elle soit parfaite dès le premier jour. Mais c’est aussi la pire version qu’elle aura jamais. Chaque limite que nous rencontrons devient soit une meilleure intégration, soit une meilleure brique produit, soit un meilleur modèle de prompt réutilisable.

C’est ça, le jeu : construire quelque chose de réel, le regarder casser, puis transformer la casse en plan de construction.