Avant de construire, il faut poser une question que l’enthousiasme du moment fait souvent oublier : est-ce que ça vaut le coup ? Un agent IA coûte du temps, de l’argent et de la maintenance. Il doit rapporter plus que ce qu’il consomme. Cette question, posée honnêtement, évite la moitié des échecs, parce qu’elle écarte les projets qui n’auraient jamais dû commencer.
Le réflexe courant est inverse. On part d’une technologie, on cherche un cas d’usage, et on trouve toujours un cas d’usage, parce que l’envie fait voir des besoins qui n’existent pas. C’est la bonne recette pour construire un agent qui impressionne en interne et que personne n’utilise. La bonne méthode consiste à partir du travail réel, à regarder où il est répétitif et mesurable, et à n’utiliser l’IA que là.
Il existe trois conditions, cumulées de préférence, qui disent si un agent mérite d’être construit : le volume, la répétabilité, la mesurabilité. Chacune mérite d’être regardée de près, parce que chacune élimine une catégorie entière de faux projets.
Le volume : pas d’agent sur trois emails par semaine
Un agent ne se justifie que si la tâche se répète souvent, des dizaines ou des centaines de fois par jour. C’est une évidence, et c’est pourtant la première chose qu’on oublie. On voit une tâche pénible, on se dit qu’un agent la ferait bien, sans regarder à quelle fréquence elle arrive.
Prenons une tâche qui revient trois fois par semaine. L’effort pour la faire à la main est modeste. L’effort pour construire un agent, l’intégrer, le superviser, le corriger, est sans commune mesure. L’agent ne se rentabilise jamais, et on a transformé un petit désagrément en un gros chantier.
Le calcul simple est celui du point de bascule : à partir de combien d’occurrences par jour la machine gagne-t-elle sur l’humain ? Si la réponse est « jamais dans mon cas », la conclusion est simple, et il faut avoir le courage de la tirer. C’est une des rares situations où renoncer à un projet IA est un succès, pas un échec.
La répétabilité : la règle doit exister
La deuxième condition est plus subtile. Une tâche à fort volume ne se prête à l’automatisation que si elle suit des règles, même compliquées. Si chaque cas demande un jugement totalement nouveau, si la bonne réponse dépend d’un contexte impossible à formaliser, l’agent va halluciner ou dériver.
Il faut donc chercher la règle avant de chercher la machine. Y a-t-il une façon de décrire, même laborieusement, ce qu’est une bonne réponse ? Si oui, on peut construire un agent et surtout l’évaluer. Si non, l’agent ne fera que produire des réponses plausibles, et des réponses plausibles fausses sont exactement ce qu’on veut éviter.
C’est aussi une façon de découvrir, en amont, que le problème n’est pas technique mais organisationnel : une tâche qui n’a pas de règle est une tâche qui n’a pas de processus, et aucun agent ne remplacera un processus qui n’existe pas.
La mesurabilité : sans evals, pas de pilotage
La troisième condition découle de la deuxième : il faut pouvoir dire ce qu’est une bonne réponse, sinon on ne peut pas mesurer l’agent, et sans mesure on pilote à l’aveugle. C’est la différence entre un agent qu’on surveille et un agent qu’on espère.
La mesurabilité exige des cas de référence, des réponses attendues, un taux de réussite. C’est le travail d’évaluation, souvent négligé parce qu’il est moins gratifiant que la construction. C’est pourtant lui qui permet de dire « l’agent est bon » ou « l’agent dérive » avec des chiffres, et de corriger le tir avant l’incident.
Une tâche qu’on ne peut pas mesurer est une tâche qu’on ne peut pas confier à une machine en confiance. On la confie à un humain, qui assume, qui s’explique, qui peut être tenu responsable. C’est une frontière saine à respecter.
Les cas où il ne vaut pas le coup
Trois situations ressortent, et il faut savoir les reconnaître. La tâche à faible enjeu et faible volume, d’abord : l’intégration dépasse le gain, et le retour à la simplicité est la meilleure décision. La décision sensible sans filet, ensuite : un agent qui valide des remboursements ou trie des candidatures sans humain dans la boucle est un risque, pas un gain. Le cas où une règle suffit, enfin : beaucoup de « besoins IA » se résolvent par un simple script déterministe, plus fiable et moins cher, et il faut avoir l’honnêteté de le dire.
Dans ces trois cas, la meilleure réponse est de ne pas construire. C’est une position impopulaire, mais c’est celle qui protège les budgets et les équipes des projets qui ne devaient jamais exister.
L’accompagnement Agenticiel pour décider avant de construire
Cette décision, la prendre seul est difficile, parce qu’on est juge et partie. C’est là qu’un regard extérieur, technique et désintéressé, fait la différence. Agenticiel aide les entreprises à trancher la question du « est-ce que ça vaut le coup » avant d’engager le moindre budget de développement.
Le point de départ est un audit simple : on regarde la tâche, son volume, sa répétabilité, sa mesurabilité, et on vous dit si un agent se justifie, ou si un script suffit, ou s’il ne faut rien faire du tout. Quand l’agent se justifie, on le construit sur ces bases, avec des evals dès le premier jour, pour que la rentabilité se mesure et pas seulement s’espère.
Ce travail est mené par des développeurs offshore francophones, à Madagascar. La sous-traitance de développement permet d’itérer sur un agent sans grever le budget, dans votre langue et sur des fuseaux compatibles, ce qui est précieux quand on veut tester une idée avant de s’engager plus loin.
Notre approche consiste à poser la question de la rentabilité avant celle de la faisabilité : on ne construit que ce qui mérite de l’être, et on vous le dit franchement quand ce n’est pas le cas.