Agents IA : le travail à faire côté métier

« Quel est le budget du projet A ? » La question paraît simple. L’agent consulte une application, récupère un tableau et répond avec assurance. Le montant existe bien dans les données. Il correspond seulement au projet A prime.

Prenons cette situation comme un exemple fictif. Les noms sont proches, les deux projets sont actifs, les chiffres ont la même allure. Une personne qui connaît les dossiers repère l’erreur. Une autre peut reprendre le montant dans une note ou une décision, sans savoir qu’il faudrait le vérifier.

Pour le responsable qui porte le projet IA, la difficulté commence ici. Les connexions fonctionnent, les premiers essais ont été encourageants. Pourtant, avant d’élargir l’usage, il faut comprendre ce qui rend les résultats fragiles et déterminer le travail restant avec les équipes métier. Nos essais internes avec WorkProba nous ont confrontés à cette question.

La démonstration fonctionne aussi grâce à celui qui la conduit

Dans nos essais, les personnes à l’aise avec les outils informatiques savent souvent aider l’agent. Elles décomposent une demande, suggèrent une source, précisent l’opération à lancer ou corrigent une confusion. Elles connaissent suffisamment l’environnement pour reconnaître une réponse suspecte.

Une partie de la réussite repose alors sur leur intervention. Cela peut passer inaperçu pendant une démonstration : une reformulation rapide, une précision sur le nom du projet, et le travail reprend. Ces ajustements deviennent beaucoup plus visibles lorsqu’il faut accompagner plusieurs collègues dans leurs demandes quotidiennes.

Une personne moins habituée à ces environnements formule naturellement son besoin avec les mots de son activité. Elle attend que l’assistant trouve les bonnes informations et mobilise les bonnes opérations. Nos observations nous conduisent à mieux cadrer ce parcours pour prendre en charge une partie du travail effectué spontanément par les utilisateurs expérimentés.

L’enjeu est aussi économique. Lorsqu’une réponse exige de retrouver les sources, de contrôler les rapprochements et de recommencer une extraction, le temps de vérification peut absorber le temps gagné. Et si ces corrections reviennent toujours au même expert, la dépendance à cette personne demeure. Il faut donc examiner le travail complet, jusqu’au résultat utilisable.

Quel budget, quel projet, quelle source ?

Une équipe peut avoir construit un socle technique solide : des données préparées, des connexions fonctionnelles, un moteur capable d’appeler un modèle et des outils. Au contact des usages, d’autres questions apparaissent. Le budget demandé est-il le montant vendu, la dépense autorisée ou le reste disponible ? Quelle période faut-il retenir ? Quelle source fait foi lorsque deux applications se contredisent ?

Ces distinctions sont souvent implicites pour les équipes. Elles reconnaissent une abréviation, savent qu’une colonne n’est plus à jour, distinguent un projet commercial de son dossier de production. L’intégration doit traduire une partie de cette connaissance en définitions, en relations et en règles utilisables par le système.

Reprenons le projet A. Son nom doit conduire à une identité stable, reliée au bon client et aux bonnes données. Si plusieurs projets correspondent, l’assistant doit présenter l’ambiguïté et demander une précision. La réponse sur le budget doit permettre de retrouver sa définition, sa période et sa source. Un simple nom approchant laisse trop de place à une association erronée.

Il arrive aussi que l’agent ignore un outil pourtant utile. Une opération décrite comme « récupérer les projets » peut lui donner accès aux budgets sans le lui indiquer clairement. Il faut expliciter ce que chaque outil fournit, quand l’utiliser et les limites de son résultat. Un vocabulaire partagé et des relations entre les objets métier peuvent suffire pour un premier usage ; une ontologie formelle devient un choix à examiner lorsque la complexité le justifie.

Préparer une facture : une opération métier à concevoir

Prenons un second exemple, lui aussi illustratif : « Prépare la facture pour les dix jours de conseil sur ce projet. »

Cette phrase suppose plusieurs décisions. Quel client facturer ? Existe-t-il dans l’outil comptable ? Quels temps sont facturables sur la période, et lesquels ont déjà été facturés ? Quel tarif s’applique ? Selon l’organisation, il faut également retrouver les règles de remise, de taxes, d’échéance et de validation.

En donnant toutes les opérations techniques séparément à l’agent, on lui laisse reconstituer ce parcours : choisir les outils, les appeler dans le bon ordre, transporter les bonnes références et traiter les exceptions. La conception d’une opération « préparer la facture de conseil de ce projet » permet de fixer une partie de ces choix.

Le contexte fournit le projet avec une référence vérifiée. L’application retrouve le client et les conditions convenues. Elle rapproche les jours proposés des temps facturables selon les règles définies. Les paramètres recueillent ce qui reste à préciser, comme la période ou la quantité à préparer. Le tarif vient de la source prévue, ou d’une décision explicite d’une personne autorisée.

L’agent aide à interpréter la demande et à recueillir les informations manquantes. Le service métier prend en charge les règles et prépare un résultat que la personne peut examiner. Pour savoir si ce partage fonctionne, il faut aussi regarder ce qui se passe quand une information attendue manque.

Le tarif manque : que doit-il se passer ?

Supposons que le projet ne possède aucun tarif applicable à la période. L’organisation peut choisir le comportement suivant : la préparation s’arrête avant la création de la facture, avec un message qui identifie l’information absente et le dossier concerné. Le système sollicite la personne autorisée à confirmer les conditions de facturation.

La conversation permet d’expliquer le blocage. L’application empêche qu’un ancien tarif ou celui d’un autre projet soit utilisé par défaut sans autorisation. Une fois l’information validée, la préparation peut reprendre avec cette référence. Le résultat présente les jours retenus, le tarif et le montant calculé pour permettre leur contrôle.

Si une validation du responsable est requise, le document reste en attente jusqu’à cette décision. L’autorisation d’envoi est vérifiée au moment de l’action. Le statut du document et les droits sont portés par le logiciel, avec des règles de passage d’une étape à l’autre.

Un arrêt de ce type peut être le résultat correct. Il rend visible une décision qui, jusque-là, se réglait peut-être par un appel ou un message entre collègues. Le travail de conception consiste aussi à prévoir à qui transmettre cette question et comment reprendre ensuite.

Mettre l’IA dans un contexte métier, c’est aussi faire évoluer l’application métier.

Ce que nous travaillons avec WorkProba

WorkProba est développé et utilisé en interne chez Improba. Le parcours de facturation relie les informations d’un projet iHora, les temps saisis et son tarif à la préparation d’une facture dans l’outil comptable. Si le client doit être créé, sa création et celle de la facture sont liées explicitement : l’identifiant obtenu sert à rattacher le document au bon client.

Les actions préparées sont présentées pour confirmation, avec leur contenu. La facture est créée à l’état de brouillon. Ce parcours donne une base concrète pour éprouver les rapprochements et les décisions. Le traitement du tarif manquant et le circuit de validation décrits plus haut illustrent des règles à définir pour chaque organisation ; ils ne constituent pas une description de fonctions toutes déjà présentes dans WorkProba.

Qui décide des règles et les tient à jour ?

Le responsable SI ou transformation peut organiser le chantier. Les arbitrages métier doivent avoir des interlocuteurs identifiés. Dans l’exemple de la facture, le responsable de projet explique quels temps doivent être proposés ; la fonction comptable précise les conditions de préparation et de validation ; l’équipe technique traduit ces décisions dans les services, les contrôles et les droits.

Ce travail peut révéler un désaccord jusque-là supporté par les pratiques informelles. Une équipe parle de budget vendu, une autre de budget disponible. L’agent ne peut pas arbitrer seul la définition qui doit faire autorité pour un usage donné. Cette décision engage l’organisation et doit trouver son responsable.

Les utilisateurs éprouvent ensuite le parcours avec leurs demandes ordinaires et leurs cas inhabituels. On peut vérifier que les définitions sont comprises, que les informations manquantes sont signalées et que les décisions arrivent à la bonne personne.

Il faut enfin prévoir l’entretien de ces choix. Lorsqu’un circuit de validation change, qui met à jour la règle ? Lorsqu’une application modifie un champ, qui vérifie le connecteur ? Quelques cas métier conservés comme référence permettent de contrôler les effets de ces évolutions, ainsi que ceux d’un changement de modèle.

Vérifier le gain sur le travail complet

Avant d’élargir l’usage, on peut réunir un ensemble de situations représentatives : une demande ordinaire, deux projets aux noms proches, un tarif absent, un client à créer et une action que l’utilisateur n’a pas le droit d’effectuer. Pour chaque cas, l’équipe métier décrit le résultat acceptable, y compris la clarification ou l’arrêt attendu.

Ces situations doivent être essayées avec les formulations de futurs utilisateurs et avec les modèles et les accès réellement disponibles. Les rejouer avec des formulations différentes aide à repérer les comportements irréguliers. Le résultat se vérifie dans les sources et les applications concernées, au-delà de ce que l’agent affirme avoir fait.

Pour juger les progrès, quatre éléments sont utiles :

• La justesse métier. Le montant vient-il du bon projet et de la bonne période ? La facture est-elle associée au bon client ?
• Le traitement des exceptions. Le système demande-t-il une précision lorsque c’est nécessaire ? Respecte-t-il les droits et les validations prévus ?
• L’effort humain. Combien de reformulations, de corrections ou d’interventions d’un expert restent nécessaires ?
• Le temps total. Préparation, contrôle et correction compris, quel effort faut-il pour obtenir un résultat utilisable, comparé au processus actuel ?

Les critères pour poursuivre dépendent de l’usage et des conséquences d’une erreur. Une préparation de brouillon et un envoi à un tiers appellent des conditions différentes. Les fixer avant les essais aide à décider de la suite : élargir un parcours, le corriger ou conserver certaines étapes manuelles. Nos essais internes ne donnent pas de seuil universel de fiabilité ou de gain de temps.

Commencer sans reconstruire tout le système d’information

On peut engager ce travail sur une opération étroite dans les applications existantes. Préparer une facture de conseil pour un type de projet donné constitue déjà un périmètre : des sources identifiées, des règles explicites, des exceptions et une décision humaine à la fin.

Une couche de services peut porter cette opération autour des applications. Une modification de celles-ci devient nécessaire si elles ne permettent pas de vérifier un droit, de représenter une validation ou de reprendre le travail dans l’état attendu. Le besoin précis guide alors l’évolution à réaliser.

Pour préparer une première discussion, le responsable du projet peut réunir une personne qui connaît l’activité, une personne capable d’arbitrer ses règles et un interlocuteur technique. Partir d’une demande réelle, la suivre jusqu’au résultat et examiner une exception permet de nommer les décisions manquantes et les adaptations nécessaires.

Notre guide sur l’architecture d’une plateforme IA détaille les responsabilités techniques qui soutiennent cette démarche. Avec WorkProba, nous travaillons cette articulation entre dialogue, applications et processus métier, en commençant par des parcours dont on peut examiner le résultat.