Introduire un agent d’IA dans l’entreprise : bien choisir le premier processus

La direction a décidé d’essayer un agent d’IA. Ensuite commence le véritable conflit. Les ventes veulent faire préparer des devis, le service client trier la boîte de réception, la comptabilité contrôler les factures, la direction de projet rédiger des comptes rendus. Tous les souhaits sont compréhensibles, et chaque service considère le sien comme le plus urgent.

Dans ce scénario, il y a du budget et de l’attention pour exactement un essai. Cela rend le choix délicat, car le premier processus façonne l’image de tout le projet. S’il se passe bien, la disposition à s’attaquer à d’autres processus grandit. S’il se passe mal, on dit vite dans l’entreprise que l’IA ne vaut rien, alors que seul le mauvais processus avait peut-être été choisi.

À cela s’ajoute un malentendu sur le terme. Un agent d’IA est plus qu’une fenêtre de discussion : il poursuit un objectif, appelle pour cela des outils, lit et écrit dans des systèmes et prend des décisions intermédiaires. Plus il a de liberté d’action, plus la question de savoir où il peut travailler en premier devient importante. Le choix du processus n’est donc pas un travail préparatoire, mais déjà la première décision de sécurité.

Un schéma frappe : le processus qui fait le plus mal est rarement la meilleure porte d’entrée. Il fait mal parce qu’il est complexe, connaît beaucoup d’exceptions et repose sur une expérience qui n’a jamais été écrite. Ce sont précisément les caractéristiques sur lesquelles un agent échoue dès le premier essai. Celui qui commence là apprend surtout combien il manque de travail préparatoire.

Le deuxième travers est le processus de prestige. Le choix se porte sur le déroulement le plus visible de l’entreprise, par exemple la communication avec un client lors d’une réclamation en cours. Là, une seule phrase erronée suffit à mécontenter un client. Le dommage est public, et les personnes concernées deviennent plus prudentes au lieu d’être plus audacieuses.

Troisièmement, il y a le processus sans données. Il se règle aujourd’hui oralement ou à la volée, sans modèles, sans archivage, sans historique. Un agent a besoin de matière pour s’orienter et de repères pour contrôler son travail. Si les deux manquent, le pilote devient un projet de documentation, utile, mais différent de ce qui était prévu.

Enfin, la direction opposée : certaines entreprises choisissent un processus si rare qu’après huit semaines il y a à peine des cas. Le risque est faible, mais l’effet d’apprentissage aussi. Sans assez d’exécutions, personne ne sait à la fin si l’agent travaille de façon fiable ou s’il n’a simplement jamais été sérieusement sollicité.

De ces schémas d’échec, on peut déduire cinq critères. Premièrement la fréquence : le processus devrait revenir régulièrement pour que l’effort et la courbe d’apprentissage en valent la peine et que le pilote rassemble assez vite des cas. Deuxièmement la régularité : il n’a pas besoin d’être rigide, mais une personne expérimentée devrait pouvoir décrire en quelques phrases comment elle procède et quand elle fait une exception.

Troisièmement, le dommage limité en cas d’erreur. C’est le critère le plus important, car on ne peut jamais exclure les erreurs. L’essentiel est de savoir ce qu’une erreur coûte et si elle peut être corrigée avant de produire son effet. Un brouillon relu par une personne est pardonnable. Une relance de paiement envoyée automatiquement ne l’est pas.

Quatrièmement, les données : existe-t-il des exemples de bons résultats, des entrées propres et un accès réalisable aux systèmes nécessaires ? Cinquièmement, la mesurabilité : comment saurez-vous au bout de quatre semaines si l’agent aide ? Le temps de traitement, le taux de corrections et les questions de suivi peuvent être comptés. L’impression que cela se passe mieux ne suffit pas comme preuve.

La fascination technique n’est volontairement pas retenue comme critère. Qu’un processus paraisse particulièrement moderne n’a aucune importance. Ce qui compte, c’est qu’il réponde aux cinq questions. Un déroulement discret qui revient chaque jour et se contrôle bien fait un meilleur pilote qu’un déroulement spectaculaire qui ne convainc que dans la présentation.

Les critères deviennent une matrice. Chaque candidat reçoit pour chaque critère une note de un à cinq, justifiée en une phrase. La justification compte plus que le chiffre, car elle oblige à discuter. Si deux personnes évaluent différemment les mêmes données, l’une des deux a vu quelque chose que l’autre a manqué.

Les critères ne devraient pas avoir le même poids. Nous compterions le dommage limité le plus fortement et le traiterions en plus comme critère d’exclusion : si un processus échoue sur ce point, il est écarté, quelles que soient les autres valeurs. Une note globale élevée ne doit pas masquer un risque élevé. Les pondérations ne sont pas des lois de la nature, mais une convention que vous adaptez à votre secteur.

Une alternative consiste à renoncer aux points au profit d’un schéma simple à deux axes : l’utilité d’un côté, le risque et l’effort de l’autre. C’est plus rapide et souvent suffisant pour de petites équipes. La matrice devient utile dès que plus de trois candidats sont en concurrence ou que plusieurs services participent à la décision, car elle rend les arguments comparables et permet d’expliquer le choix plus tard.

Un exemple d’évaluation : une entreprise examine des projets de devis et des validations de factures. Les deux reviennent régulièrement et reposent sur des règles. Pour le devis, le dommage avant validation reste interne et les modèles sont bons ; pour la validation de facture, une erreur touche directement l’argent. Même avec des notes par ailleurs égales, le premier candidat reste devant, car le critère d’exclusion met le second hors course.

Pour finir, un test de plausibilité : si le gagnant de la matrice contredit votre intuition, ne regardez pas d’abord la matrice. Demandez-vous quelle hypothèse sous-tend votre intuition. Il arrive qu’un critère manque vraiment, par exemple la disposition de l’équipe à coopérer. Il doit alors entrer dans la matrice, pas rester à côté.

Des exemples concrets rendent les critères tangibles. La préparation de devis sous forme de brouillon est souvent bien adaptée : l’agent lit la demande, cherche des devis antérieurs similaires, rassemble les postes et laisse une personne relire et valider. Le déroulement revient régulièrement, suit des schémas reconnaissables, le dommage reste interne avant validation, et des modèles existent en général.

Le tri préalable de la boîte de réception est également adapté. L’agent classe les messages par catégories, propose une priorité et rédige des réponses aux questions courantes, mais n’envoie rien lui-même. La recherche dans les documents internes en fait partie : où se trouve la règle applicable à un cas précis, quels documents existent sur un client ? Ici, les collaborateurs vérifient la source que l’agent indique.

Sont à la limite les processus avec effet externe mais règles claires, comme les confirmations de rendez-vous ou les messages de statut aux clients. Ils peuvent suivre plus tard, lorsque l’agent aura montré sa fiabilité et que des règles d’approbation s’appliqueront. Inadaptés au début : les déroulements à portée financière ou juridique sans instance de contrôle, comme les validations de paiement, les modifications de contrat, les résiliations, les décisions concernant des personnes ou les renseignements médicaux.

Ce classement n’est pas une décision définitive. Il décrit le point de départ. Un processus inadapté aujourd’hui peut très bien le devenir après une phase d’apprentissage avec étapes d’approbation, journalisation et droits limités. Ce qui compte, c’est l’ordre, pas l’interdiction.

Un pilote n’est pas une petite exploitation en production, mais une expérience avec une question, un délai et une règle de résultat. La question n’est pas de savoir si l’IA fonctionne, mais si cet agent soutient ce processus de façon assez fiable dans ces conditions. Comme délai, quatre à huit semaines est un repère courant, selon la rapidité avec laquelle assez de cas se présentent.

Vous fixez les critères de réussite avant le démarrage et vous les consignez par écrit. Ils comprennent une mesure de qualité, par exemple la part des brouillons repris sans correction de fond, le temps par dossier par rapport au traitement actuel et le nombre de cas où l’agent a demandé de l’aide à bon escient. Vous convenez de seuils concrets à partir de votre propre situation de départ, que vous mesurez brièvement au préalable.

Les critères d’arrêt sont au moins aussi importants. Ils font la différence entre un pilote et un provisoire que plus personne n’éteint. Les déclencheurs typiques sont une erreur avec effet externe, le non-respect répété d’une règle, un incident de protection des données ou un effort de correction durablement supérieur au temps gagné. Celui qui les convient à l’avance n’a pas à négocier en cas de problème, seulement à constater.

Dans le pilote, l’agent travaille avec des droits minimaux. Il lit là où il doit lire et n’écrit que dans une zone de brouillons. Chaque action est consignée afin de pouvoir retracer plus tard ce qu’il a fait et pourquoi. Les autorisations et les approbations sont un sujet à part, que nous approfondissons dans d’autres études de cette série.

Le cas particulier le plus fréquent est un résultat mitigé. L’agent travaille bien dans la plupart des cas, mais échoue pour un groupe identifiable, par exemple des demandes avec pièces jointes ou conditions spéciales. Ce n’est pas un échec, c’est un constat. Le plus souvent, le groupe peut être repéré par une règle simple et tenu à l’écart de l’agent, qui se limite alors à ce qu’il maîtrise.

Plus délicate est la chance du débutant. Si le pilote se passe sans accroc les premières semaines parce que seuls des cas simples se sont présentés, cela incite à étendre trop vite. À titre préventif, un test de résistance volontaire aide : rassemblez les cas les plus difficiles des derniers mois et faites-les retraiter par l’agent sans que rien ne soit livré. Les schémas d’erreur qui apparaissent alors, l’activité courante ne les aurait peut-être révélés que tardivement.

Un troisième cas : la mesure elle-même est faussée. Si les collaborateurs valident les brouillons de l’agent par habitude, le taux de corrections a l’air excellent. Il en va de même s’ils réécrivent entièrement chaque brouillon par méfiance. Des contrôles par sondage effectués par une deuxième personne et des cas de contrôle à solution connue glissés de temps en temps montrent si la vérification est prise au sérieux.

Un autre écueil tient aux limites des systèmes. L’agent doit lire des données d’un logiciel métier sans interface propre, ou écrire dans une boîte utilisée par plusieurs personnes. Naissent alors des solutions de fortune qui fonctionnent dans le pilote et sont fragiles en exploitation courante. Vérifiez tôt si l’accès est possible de manière durable, contrôlée et révocable, et prévoyez au besoin un périmètre plus restreint qui ne travaille qu’avec des données proprement accessibles.

Enfin, la protection des données. Si le processus traite des données personnelles, la sous-traitance, les lieux de stockage, la conservation et l’accès des personnes concernées doivent être clarifiés avant le démarrage. Ce n’est pas un conseil juridique, mais un rappel : la clarification ne doit pas attendre la fin du pilote, et en cas de doute il convient d’associer un délégué à la protection des données ou un juriste.

L’ambition réaliste est d’alléger de façon mesurable un déroulement bien délimité tout en acquérant de l’expérience pour les étapes suivantes. Pour les processus qui remplissent les cinq critères, il est plausible que les collaborateurs passent moins de temps à préparer, chercher et rassembler. L’ampleur de cet effet dépend du processus, des données et du soin apporté à l’introduction, et ne peut être chiffrée sérieusement à l’avance.

On mesure en trois groupes. Le premier est l’efficacité : temps par dossier, délai de traitement, part des cas qui passent sans question. Le deuxième est la qualité : part des brouillons avec correction de fond, nature des erreurs, réclamations. Le troisième est l’acceptation : les collaborateurs utilisent-ils l’agent volontairement et le perçoivent-ils comme un soulagement ? Le troisième groupe s’oublie volontiers et décide de l’exploitation à long terme.

Une partie du bénéfice, aucun compteur ne la montre : le pilote rend visible la façon dont le processus se déroule réellement. Il apparaît souvent que les déroulements étaient moins clairs que supposé ou que des modèles sont obsolètes. Ce constat a de la valeur même si l’agent n’est finalement pas déployé. Il devrait être consigné dans le bilan plutôt que de se perdre dans la conversation.

Il n’y a pas de garanties. Un pilote peut prouver qu’une approche tient, ou montrer qu’elle ne tient pas. Les deux résultats sont utiles tant qu’ils sont consignés honnêtement. Le pire est un pilote qui n’est jamais terminé et dont chacun interprète le résultat à sa guise. Consignez donc la décision par écrit, avec la date, la justification et les chiffres sur lesquels elle s’appuie, afin qu’elle reste compréhensible dans un an.

Le rôle des collaborateurs est souvent réduit à approuver : l’agent livre, une personne confirme. Cette image sous-estime l’endroit où se trouve le savoir. La personne qui traite le processus depuis des années connaît les exceptions, les pièges et les règles non écrites. Sans elle, aucun agent ne peut être guidé de manière pertinente, et personne ne peut juger si ses résultats sont exploitables.

C’est pourquoi au moins une personne expérimentée du service doit participer au pilote dès le début. Elle décrit le déroulement cible, fournit des exemples de bons et de mauvais résultats et évalue les brouillons. Il est judicieux de lui donner un réel pouvoir de décision, par exemple le droit de suspendre un pilote. Celui qui ne peut que regarder développe du scepticisme, celui qui participe à la décision développe de la responsabilité.

L’honnêteté sur les conséquences en fait partie. Lorsqu’un processus est automatisé, les personnes concernées se demandent à juste titre ce que cela signifie pour leur travail. Une réponse crédible indique ce que l’agent prend en charge, ce qui reste aux humains et comment le temps libéré est utilisé. Des formulations évasives sapent la coopération dont le pilote a besoin. Invitez en outre l’équipe au bilan afin qu’elle puisse y apporter ses propres observations.

La formation est simple et pratique. Les personnes doivent comprendre ce que l’agent sait faire, où il se trompe et comment signaler des erreurs. Un canal de retour simple, par exemple un champ dans le brouillon où les corrections sont consignées avec leur motif, fournit les meilleurs signaux d’apprentissage. Il montre en même temps si le contrôle est pris au sérieux.

Après le pilote vient l’une de trois décisions : poursuivre, ajuster ou arrêter. Poursuivre ne signifie pas raccorder aussitôt d’autres processus. On commence par faire passer le processus pilote en exploitation courante, avec journalisation, surveillance et responsabilité clairement désignée. Suit une phase d’apprentissage où vous observez si les résultats restent stables même lorsque le contexte change.

Passer à l’échelle, c’est répéter la sélection, pas la supprimer. Chaque nouveau candidat passe par la même matrice, et avec l’expérience les évaluations évoluent. Un processus trop risqué au départ peut devenir acceptable grâce aux étapes d’approbation existantes. L’inverse vaut aussi : si le premier pilote révèle des limites, intégrez-les aux critères.

Ce qui compte, c’est ce que l’on observe pendant la phase d’apprentissage. Les erreurs qui se multiplient sont les signaux les moins intéressants, car elles se remarquent. Plus révélatrice est la perte de qualité insidieuse : les modèles changent, un produit s’ajoute, les collaborateurs tournent, et l’agent continue de travailler selon l’ancien état. C’est pourquoi la phase d’apprentissage suppose un rythme fixe où l’on prélève des échantillons, évalue les corrections et ajuste les instructions de l’agent.

La responsabilité doit aussi être désignée. Il faut une personne qui suit l’agent sur le plan métier et une autre qui décide des autorisations et des accès aux données. Dans les petites entreprises, ce sont souvent les mêmes personnes, ce qui convient tant que cela a été expressément convenu. Sans cette attribution, un pilote réussi s’enlise dans le quotidien, parce que personne ne se sent responsable lorsque quelque chose attire l’attention.

L’étape suivante est modeste. Rassemblez les trois à cinq processus dont il est question chez vous pour l’agent, et répondez aux cinq questions pour chacun en une phrase. Un favori se dessine généralement déjà à ce stade, et il apparaît tout aussi souvent que les données ou la mesurabilité doivent encore être préparées. Nous évaluons volontiers cette liste avec vous et vous disons franchement si un pilote viendrait encore trop tôt.