Un dirigeant m'appelle parce que son équipe support croule sous les demandes. Il veut un agent qui réponde aux clients. On regarde ensemble comment les demandes arrivent aujourd'hui : trois adresses mail, un formulaire, un numéro de portable, et des messages LinkedIn qu'une seule personne consulte. Personne ne sait combien de demandes entrent par semaine. Personne ne sait lesquelles sont urgentes. Il n'y a pas de processus support, il y a des gens qui font de leur mieux.
Brancher une IA là-dessus n'aurait pas résolu le problème. Ça l'aurait rendu plus rapide et plus difficile à voir.
Le principe, formulé simplement
Une automatisation, quelle que soit sa technologie, prend un flux et le fait circuler plus vite. Elle ne juge pas la qualité de ce qu'elle transporte. Si le processus en amont est clair, l'accélération produit du volume utile. Si le processus est flou, l'accélération produit du flou industrialisé.
C'est valable pour un tableur mal fichu, pour un workflow n8n, et pour un agent branché sur un modèle de langage. La différence, c'est que l'IA rend l'effet beaucoup plus rapide et beaucoup plus convaincant. Une automatisation classique casse quand elle rencontre l'inattendu, et le bruit alerte. Un modèle de langage, lui, produit toujours quelque chose. Il ne s'arrête pas, il improvise, et il improvise dans un français impeccable. Le flou devient invisible.
Trois formes de flou reviennent chez presque tous les clients :
- Le flou de définition. Personne ne sait exactement ce qu'est un « dossier traité », un « lead qualifié », un « client actif ». Chacun a sa version, jamais écrite.
- Le flou de responsabilité. Une étape existe, mais son propriétaire change selon la charge du moment. Quand ça coince, on ne sait pas à qui poser la question.
- Le flou de règle. Les cas standards sont clairs, les exceptions sont gérées à l'instinct par deux ou trois personnes expérimentées, et cet instinct n'a jamais été explicité.
Une IA ne comble aucun de ces trois trous. Elle les remplit avec des réponses plausibles, ce qui est pire, parce qu'une réponse plausible ne déclenche pas de vérification.
D'où ça me vient
Vingt ans de product management m'ont appris que le travail utile arrive avant la construction. Chez Ippon Technologies, sur les missions La Poste Groupe, KPMG et Leroy Merlin, l'essentiel de la valeur se jouait dans les ateliers de discovery : comprendre le vrai flux, pas celui du schéma d'organisation.
Les trois années de coaching produit à beta.gouv.fr, l'incubateur de services numériques de l'État, ont durci cette conviction. Les Startups d'État qui réussissent ne sont pas celles qui construisent le plus vite. Ce sont celles qui ont compris précisément quel irritant elles traitent, pour qui, et comment elles sauront que c'est réglé. Les autres livrent beaucoup et ne changent rien.
Depuis que je fais de l'IA le sujet principal avec Grabloop, je vois le même schéma, mais en accéléré. La technologie ne pardonne pas moins qu'avant, elle pardonne différemment : elle donne l'illusion que ça marche pendant plusieurs semaines.
Ce que ça change dans une mission
Concrètement, ce principe déplace le centre de gravité du travail.
L'audit passe avant les prompts. Avant de parler d'outil, je cartographie le processus visé : les entrées réelles, les étapes, les décisions, les exceptions, les points de contrôle. Pas le processus officiel — celui qui se déroule vraiment. Cette étape n'a rien de spectaculaire, et c'est régulièrement là que le client apprend le plus sur sa propre entreprise.
On écrit les règles avant de les automatiser. Si personne ne sait formuler la règle en français, aucun agent ne saura l'appliquer. L'exercice est simple et souvent inconfortable :
Explique-moi ce que tu fais dans ce cas-là, comme si tu formais quelqu'un qui commence lundi. Sans dire « ça dépend ».
Quand la réponse arrive en trois phrases claires, le cas est automatisable. Quand elle prend dix minutes et cite six situations particulières, on tient soit un sujet à clarifier, soit une étape qui doit rester humaine.
On accepte que le livrable soit parfois un processus, pas un agent. Il m'arrive régulièrement de recommander de commencer par centraliser une source, nommer un responsable, ou supprimer une étape devenue inutile. Ça ne se vend pas bien, ça ne fait pas de démonstration, et ça débloque plus de valeur que la brique IA qu'on aurait posée dessus.
Et parfois, la recommandation est : pas d'IA
Ça arrive plus souvent qu'on ne le croit. Les cas typiques :
- Le volume ne le justifie pas. Douze dossiers par mois traités à la main, ça reste la bonne solution.
- Le processus change tous les trimestres. Tu passeras plus de temps à maintenir l'agent qu'à faire le travail.
- L'erreur coûte cher et la vérification humaine reste obligatoire. Le gain fond, et il ne reste que la complexité.
- La vraie cause est ailleurs : un logiciel métier inadapté, une règle commerciale illisible, un poste vacant depuis six mois.
Dire ça au client fait perdre une vente à court terme. Ça fait gagner une relation. Un dirigeant qui a entendu « ce n'est pas le moment » une fois revient avec des sujets plus mûrs, et il écoute autrement quand je dis « là, oui, allons-y ».
Le réflexe à garder
Avant de mettre de l'IA sur un processus, pose une seule question à l'équipe qui le fait tourner : est-ce qu'on saurait l'expliquer à un nouveau, par écrit, en une page ? Si oui, l'automatisation va démultiplier quelque chose de solide. Si non, tu viens de trouver le vrai chantier — et il ne coûte rien d'autre que de l'attention.