Le constat : quand un premier projet d'agent IA s'enlise en PME, la cause est rarement le modèle, la donnée ou le budget. C'est le périmètre. On a demandé à un premier agent de faire le travail de trois.
Un dirigeant qui investit dans l'IA veut un retour visible. La logique paraît imparable : si on déploie un agent IA métier, autant qu'il traite les devis, le support et la relance client — sinon l'effort n'en vaut pas la peine. Cette logique est la première cause d'échec des projets IA en PME. Voici pourquoi, et comment cadrer un premier périmètre qui tient.
1. Le réflexe du périmètre large, et ce qu'il coûte
Le raisonnement est économique et il se défend : un projet IA demande du cadrage, de l'accès aux données, de la conduite du changement. Si tout cet effort ne sert qu'à automatiser une seule tâche, le rapport effort/bénéfice semble mauvais. Alors on élargit : « tant qu'on y est, qu'il traite aussi les relances », « et le support niveau 1, c'est le même genre de travail ».
Le problème, c'est que la complexité d'un agent ne croît pas linéairement avec son périmètre. Chaque processus ajouté apporte ses propres règles métier, ses exceptions, ses interlocuteurs, ses systèmes à connecter et ses critères de réussite. Deux processus dans un même agent, ce n'est pas deux fois le travail : c'est le travail des deux, plus celui de gérer leurs interactions et leurs cas limites communs.
« Un agent qui fait une chose et la fait bien est en production en quelques semaines. Un agent qui doit tout faire reste en test pendant des mois — et finit par être abandonné avant d'avoir prouvé quoi que ce soit. »
Le coût réel n'est pas le budget dépensé. C'est le temps pendant lequel l'entreprise n'a aucun résultat à montrer. Un projet qui traîne perd son sponsor interne, épuise la patience des équipes et grille la crédibilité de l'IA dans l'entreprise pour longtemps. Le deuxième projet est toujours plus dur à financer quand le premier n'a rien produit.
2. Ce qu'un périmètre serré permet vraiment
Restreindre le premier agent à un seul processus n'est pas une prudence timide. C'est ce qui rend possible une série de choses impossibles autrement.
Un critère de réussite qu'on peut écrire en une phrase
Sur un processus unique, la question « est-ce que ça marche ? » a une réponse. « L'agent produit un devis conforme à partir d'une demande client, sans reprise humaine, dans les cas standards. » On sait le tester, on sait le mesurer, on sait quand c'est atteint. Sur un périmètre large, personne n'arrive à dire si le projet est réussi, et le débat reste subjectif.
Une charge de validation supportable
Un agent en montée en charge produit des résultats qu'un humain doit relire. Si l'agent couvre un processus, cette relecture incombe à l'équipe concernée et reste tenable. S'il couvre quatre processus, quatre équipes doivent relire en parallèle, souvent sans avoir été impliquées dans le cadrage. La validation devient une corvée subie, et la qualité du retour s'effondre.
Une décision de poursuite fondée sur du réel
Après un premier processus en production, l'entreprise dispose d'éléments concrets : le temps réellement gagné, les cas que l'agent ne sait pas traiter, la réaction des équipes, la qualité effective des données. Ces éléments valent infiniment plus que n'importe quelle projection faite avant le démarrage — et ils orientent le deuxième déploiement bien mieux qu'une étude préalable.
Ce que le périmètre serré vous achète
- Un résultat démontrable pendant que le sponsor est encore mobilisé
- Une charge de validation qui tient dans le quotidien d'une seule équipe
- Des données réelles pour arbitrer la suite au lieu de projections
- Un droit à l'erreur : un périmètre étroit qui rate coûte peu et enseigne beaucoup
3. Comment choisir le processus de départ
Tous les processus ne se valent pas comme point d'entrée. Quatre critères permettent de trancher rapidement, et ils comptent davantage que l'importance stratégique du processus.
1. Il est répétitif et fréquent
Un processus qui revient plusieurs fois par jour génère assez de volume pour que le gain soit visible en quelques semaines. Un processus mensuel, même pénible, mettra des mois à démontrer quoi que ce soit — et vous n'aurez pas assez de cas pour corriger l'agent efficacement.
2. Son résultat est vérifiable rapidement
Un devis, une fiche candidat qualifiée, une réponse de premier niveau : on voit en quelques secondes si c'est bon ou non. À l'inverse, un processus dont la qualité ne se juge qu'après plusieurs semaines (une recommandation stratégique, un scoring dont on ne connaîtra l'issue qu'au closing) rend l'amélioration de l'agent très lente.
3. Une erreur y est rattrapable
Pour un premier déploiement, privilégiez un processus où une erreur détectée avant envoi ne cause aucun dommage. On évite pour un premier agent tout ce qui déclenche un engagement contractuel, un mouvement financier ou une communication irréversible vers un client sans relecture.
4. Quelqu'un dans l'entreprise le connaît par cœur
C'est le critère le plus sous-estimé. Un agent IA métier encode des règles de métier, y compris celles que personne n'a jamais écrites. S'il n'existe pas, en interne, une personne capable de dire « non, dans ce cas-là on fait autrement, et voilà pourquoi », l'agent sera construit sur des suppositions. Choisissez un processus dont l'expert est disponible et impliqué.
4. Les faux « processus uniques »
Un piège fréquent : croire qu'on a restreint le périmètre alors qu'on a simplement donné un nom générique à un ensemble de processus distincts.
« Automatiser le support client » ressemble à un processus. C'en est au moins quatre : répondre à une question documentée, diagnostiquer un problème technique, traiter une réclamation commerciale, et router ce qui n'entre dans aucune de ces cases. Ces quatre activités mobilisent des données différentes, des tons différents et des niveaux de risque différents.
Le test est simple : si vous ne pouvez pas décrire l'entrée et la sortie du processus en une phrase, ce n'est pas un processus, c'est une catégorie. « À partir d'un email client contenant une question sur une commande existante, produire une réponse citant le statut réel de la commande » — ça, c'est un processus. On sait exactement ce qui entre, ce qui sort, et ce qui est hors périmètre.
Catégorie ou processus ? Trois exemples
- « Automatiser le recrutement » → catégorie. « Pré-qualifier les CV reçus sur une offre donnée » → processus
- « Gérer l'administratif » → catégorie. « Générer un devis à partir d'une demande entrante » → processus
- « Exploiter nos données » → catégorie. « Répondre à une question interne en citant le document source » → processus
5. Élargir : quand, et dans quel ordre
Un premier agent en production n'est pas une fin. C'est ce qui rend le deuxième déploiement rapide — à condition d'élargir dans le bon ordre.
D'abord la profondeur, ensuite la largeur
Une fois le processus traité dans ses cas standards, le premier réflexe utile n'est pas d'ajouter un processus voisin : c'est d'absorber les exceptions du processus existant. Les cas particuliers représentent souvent une part significative du volume et c'est là que se trouve le temps réellement perdu par les équipes. Un agent qui passe des cas standards aux cas complets sur un même processus apporte généralement plus qu'un deuxième agent médiocre sur un autre sujet.
Ensuite, les processus qui partagent la même donnée
Le deuxième processus le moins coûteux à déployer est celui qui s'appuie sur les mêmes sources que le premier. Les connexions sont déjà en place, les droits d'accès validés, la qualité des données connue. C'est là que la connexion des outils à l'IA commence à payer : le coût d'intégration s'amortit sur plusieurs agents.
Et l'orchestration, seulement après
Faire coopérer plusieurs agents sur une chaîne complète est une étape qui a du sens — mais après, pas avant. Une architecture multi-agents se construit sur des agents unitaires dont on connaît le comportement réel. Orchestrer des composants dont on n'a jamais mesuré la fiabilité individuelle, c'est empiler de l'incertitude.
6. Comment on cadre ça chez Lewis
Sur un premier déploiement, le travail de cadrage compte davantage que le travail technique. Concrètement, la démarche tient en quelques étapes.
On part du quotidien réel des équipes plutôt que d'une liste de cas d'usage IA. Ce qui nous intéresse, ce sont les tâches que les gens décrivent spontanément comme fastidieuses et répétitives — elles sont généralement le meilleur point d'entrée, parce que l'équipe y est demandeuse plutôt que méfiante.
On écrit ensuite le périmètre sous forme d'entrée/sortie, avec ce qui est explicitement hors sujet. Cette liste d'exclusions est aussi importante que le périmètre lui-même : c'est elle qui protège le projet des élargissements successifs en cours de route.
On définit le critère d'arrêt avant de commencer : à quoi ressemble un agent qu'on peut mettre en production. Sans ce critère écrit à l'avance, un projet IA peut rester indéfiniment « presque prêt ». Et on prévoit dès le départ où l'humain valide — un point qu'on développe dans notre article sur le fonctionnement des agents IA métiers.
Cette approche est aussi ce qui permet de tenir des délais courts : déployer un agent en deux semaines n'a rien d'irréaliste sur un processus unique bien cadré. C'est en revanche impossible sur un périmètre ouvert.