Cette page est en noindex, les liens sont nofollow et l’article n’est lié depuis aucune page du site.
Avant de choisir un agent d’intelligence artificielle, une PME gagne à dresser la liste de ce qui restera entre des mains humaines. Cet exercice, plus utile que la liste de ce qu’on voudrait confier à la machine, fixe le périmètre, le budget et la manière de juger le projet.
Un périmètre trop large rend l’agent impossible à tester
Le scénario revient souvent. Un dirigeant assiste à une démonstration et imagine un assistant qui répondrait aux e-mails, qualifierait les prospects, mettrait à jour le CRM (le logiciel de gestion de la relation client), relancerait les devis et résumerait les réunions. Sur le papier, c’est un projet. En pratique, ce sont cinq métiers, chacun avec ses propres sources d’information.
Le premier obstacle est le test. Un agent se valide sur des cas concrets : telle demande arrive, voici ce qu’il doit faire. Pour une seule tâche, quelques dizaines de cas réels couvrent la plupart des situations. Pour cinq, les combinaisons se multiplient, et ce sont souvent les cas à la frontière qui posent problème. Un client écrit pour passer commande et se plaindre d’une livraison dans le même message : qui s’en occupe, le traitement des commandes ou le service client ?
Chaque accès supplémentaire, qu’il s’agisse de la messagerie, du CRM ou de la facturation, représente aussi une porte de plus à sécuriser. Il vaut mieux démarrer avec une tâche, un canal d’entrée et un résultat attendu, puis élargir une fois que ce premier périmètre tient.
Trois critères pour trier une tâche
Le premier critère est la fréquence. Une tâche qui revient deux fois par mois ne justifie presque jamais un agent, car le temps passé à le construire, le tester et le maintenir dépasse ce qu’il fera gagner. Une tâche qui revient plusieurs fois par jour change l’équation, et fournit assez de cas pour tester avant le lancement.
Le deuxième est la stabilité des règles. Il suffit de demander à la personne qui fait la tâche aujourd’hui si elle peut expliquer en une page comment elle décide. Si la réponse commence par « ça dépend » et se poursuit par dix minutes d’exceptions, la règle n’existe pas encore, et l’agent reproduira ce flou.
Le troisième est le coût d’une erreur. La question n’est pas de savoir si l’agent se trompera, mais ce qui se passe quand il se trompe. Un e-mail mal classé coûte quelques minutes. Un mauvais prix annoncé à un client ou un rendez-vous enregistré au mauvais jour coûtent bien plus, et ne se rattrapent pas toujours. Si l’erreur peut être repérée avant de sortir de l’entreprise, l’automatisation est envisageable. Sinon, l’agent prépare et un humain valide l’envoi.
Lorsque l’agent s’adresse directement au public, une obligation légale s’ajoute. L’article 50 du règlement européen sur l’IA, applicable depuis le 2 août 2026, impose que les personnes sachent qu’elles échangent avec une IA, sauf si cela est évident dans le contexte.
Choisir l’outil, puis suivre l’agent
Pour des tâches courantes, comme la prise de rendez-vous, le tri d’une boîte de réception ou le compte rendu de réunion, des logiciels maintenus par leur éditeur et facturés au mois existent déjà. Le réflexe raisonnable consiste à en tester un sur de vrais cas pendant quelques semaines. Le sur mesure se justifie lorsque la tâche dépend d’outils que le marché ne sait pas relier, lorsque les règles font partie du savoir-faire de l’entreprise, ou lorsque les données ne peuvent pas être confiées à une plateforme tierce.
Un prestataire qui traite des données personnelles pour le compte de l’entreprise est un sous-traitant au sens du RGPD. L’article 28 prévoit que ce traitement soit « régi par un contrat ou un autre acte juridique ». Ce contrat doit être demandé avant tout branchement, tout comme il faut savoir ce qui se passerait si l’éditeur changeait ses prix ou fermait le service.
Une fois l’agent en service, chaque demande traitée doit laisser une trace, et une relecture hebdomadaire de ce journal, pendant le premier mois, montre vite où l’agent hésite. Les fournisseurs de modèles font aussi évoluer leurs versions, et un agent peut changer de comportement sans qu’on ait rien modifié. Conserver une série de cas réels anonymisés et la rejouer après chaque changement permet de le vérifier. Enfin, le contrat doit préciser à qui appartiennent le code, les consignes et les scénarios d’automatisation, et la documentation doit permettre à un autre prestataire de reprendre l’agent.
