[ IA · Automatisation des processus ]
Intégrer un agent IA dans un workflow métier : méthode et exemples
Un agent IA ne devient pas utile parce qu’il sait discuter. Un agent est ici un outil capable d’interpréter un objectif, d’utiliser des sources ou des outils et d’enchaîner plusieurs étapes dans un périmètre défini. Il devient utile lorsqu’il s’insère dans un processus que l’entreprise connaît déjà : répondre à une demande, retrouver une information, qualifier un dossier, préparer un message ou rapprocher deux données.
La différence est importante. Une PME n’a pas forcément besoin de reconstruire son CRM, son outil de support ou sa messagerie. Elle peut commencer par confier à un agent une partie bien délimitée d’un workflow existant, puis mesurer ce qui fonctionne réellement.
Cette approche est moins spectaculaire qu’une démonstration où un agent pilote toute une entreprise. Elle est souvent plus contrôlable, plus facile à tester et plus compatible avec les contraintes d’un projet réel.
Les exemples cités ci-dessous proviennent principalement de communications d’entreprises ou de fournisseurs. Les chiffres sont donc à considérer comme des résultats déclarés dans leur contexte, et non comme des performances indépendamment auditées ou directement transposables à une PME.
Partir du workflow, pas de l’outil
Avant de choisir un modèle ou une plateforme, il faut décrire le processus actuel.
Prenons l'exemple d'une demande -ticket- de Support Client reçue par e-mail :
1. le message arrive dans une boîte ou un outil de ticketing ; 2. une personne identifie le client ; 3. elle recherche les échanges précédents ; 4. elle consulte une documentation ; 5. elle prépare une réponse ; 6. elle escalade les cas particuliers ; 7. elle clôture ou suit la demande.
Un agent IA peut intervenir à plusieurs endroits, mais pas de la même manière. Il peut rechercher une information, résumer un historique, proposer une réponse ou modifier le ticket. Ces actions n’ont ni le même intérêt ni le même niveau de risque.
La première question n’est donc pas : « Quel outil agentique devons-nous acheter ? » C’est plutôt : « Quelle étape répétitive voulons-nous améliorer, avec quelles données et quelle responsabilité ? »
Une méthode en quatre niveaux
1. Lecture : l’agent IA observe et prépare une information
Au premier niveau, l’agent ne modifie rien. Il recherche dans des sources autorisées, résume un dossier, classe une demande ou signale une information manquante.
C’est le niveau le plus simple pour commencer. Il permet de mesurer la qualité des réponses sans exposer immédiatement le CRM, la messagerie ou la facturation à des actions automatiques.
Exemples :
- retrouver les articles de documentation correspondant à une demande
- résumer un historique client
- extraire les informations d’un formulaire
- classer une demande par type ou urgence
- repérer les dossiers incomplets
2. Préparation : l’agent propose une action
L’agent rédige un brouillon, prépare une fiche ou suggère une prochaine étape. Une personne vérifie le résultat avant l’exécution.
Ce niveau est souvent pertinent pour une PME : l’organisation bénéficie de l’automatisation de la recherche et de la préparation, tout en conservant une décision humaine.
3. Action limitée : l’agent exécute une opération bornée
L’agent peut créer un ticket, affecter une demande, ajouter une information non critique ou envoyer une réponse validée. Les actions autorisées doivent être précisément définies, avec des paramètres contrôlés et des conditions d’arrêt.
4. Orchestration : l’agent enchaîne plusieurs outils
L’agent choisit certaines étapes et coordonne plusieurs systèmes. Ce niveau est plus flexible, mais peut être plus coûteux en intégration, supervision et maintenance, plus difficile à tester et plus sensible aux erreurs de contexte.
Il ne doit pas constituer le point de départ par défaut. Une PME a intérêt à démontrer la valeur d’un workflow simple avant de lui donner davantage d’autonomie.
Cartographier le processus avant de le connecter
Une cartographie utile du process tient sur quelques éléments :
- le déclencheur du workflow
- les étapes actuelles
- les outils utilisés
- les données consultées ou modifiées
- les règles métier
- les exceptions
- les personnes responsables
- le délai attendu
- le coût ou le temps consacré
- le résultat considéré comme acceptable
Cette étape fait parfois apparaître un problème plus important que l’absence d’IA : une règle métier non documentée, une information est dupliquée dans des outils différents -avec parfois versions différentes- ou personne ne sait qui valide une exception.
Automatiser un processus mal défini ne le rend pas meilleur. L’agent risque surtout de rendre ses incohérences plus rapides et plus difficiles à repérer.
Exemple 1 : deux agents de support chez mobilezone
Microsoft décrit le cas de mobilezone, une entreprise de télécommunications qui a déployé deux agents avec Copilot Studio, Dynamics 365 et Power Platform. Mia intervient côté client et Supporto côté support informatique interne. La source évoque environ 1 600 conversations mensuelles, réparties entre ces deux usages.
L’intérêt du cas ne réside pas seulement dans le nom de l’outil. Le workflow reste relié aux systèmes et aux règles existants. Les agents répondent à certaines demandes, améliorent la qualité des tickets et organisent l’escalade des cas qui sortent de leur périmètre.
Microsoft rapporte notamment une réduction du temps d’attente ou de résolution pour les incidents IT internes. Ces résultats sont publiés par le fournisseur et doivent être replacés dans leur contexte : volume, période comparée, périmètre exact et niveau d’intervention humaine. Ils ne permettent pas d’affirmer une baisse générale des transferts du service client.
Pour une PME, l’enseignement raisonnable est plus limité : commencer par une base documentaire et quelques catégories de demandes bien identifiées, puis mesurer le taux de transfert et le taux de correction des réponses.
Exemple 2 : le recouvrement chez Microsoft
Microsoft présente également un système d’assistance par IA pour ses opérations de recouvrement. Avant le projet, les gestionnaires recherchaient manuellement les factures, les échanges précédents et le prochain interlocuteur dans plusieurs systèmes.
Le workflow a été rapproché de SAP et Dynamics 365. L’IA aide à identifier le bon interlocuteur, router des exceptions, résumer les interactions, rapprocher des paiements et des factures, suggérer des réponses et prioriser le travail. La source ne suffit pas à conclure précisément sur les modèles prédictifs de retards ou de litiges.
Les gestionnaires restent responsables des décisions et de la relation avec les clients. Microsoft annonce notamment 40 % de temps de préparation en moins, un doublement des rapprochements automatiques et une résolution des demandes 2,5 fois plus rapide. Il s’agit d’un retour d’expérience interne, sans publication détaillée du coût complet ni audit indépendant des résultats.
Le point transposable à une PME n’est pas le niveau de performance annoncé. C’est la préparation nécessaire : données consolidées, règles de rapprochement claires, intégration aux outils existants et maintien d’un responsable humain.
Exemple 3 : le support téléphonique de DoorDash
AWS décrit une solution de support vocal mise en place pour DoorDash. Le dispositif combine un centre de contact, un système de dialogue vocal, un modèle d’IA et une base documentaire. Les demandes concernent notamment l’application, l’inscription et les paiements.
Avant, un serveur vocal et des parcours de self-service orientaient les livreurs. Après, l’agent répond aux questions courantes et transfère les situations non résolues au centre de contact.
AWS rapporte une baisse de 49 % des transferts, une hausse de 12 % de la résolution au premier contact et 3 millions de dollars d’économies annuelles. Ces chiffres sont annoncés par AWS et DoorDash, dans le contexte d’un centre de contact à très gros volume et sans validation indépendante publiée. Ils ne sont pas transposables directement à une PME.
L’exemple montre néanmoins une règle utile : un agent peut être intégré dans un centre de contact sans supprimer le traitement humain. Le transfert n’est pas un échec ; il fait partie du workflow prévu pour les cas ambigus ou sensibles.
Exemple 4 : le support de Checkmarx
Salesforce présente un déploiement d’Agentforce chez Checkmarx, une entreprise de cybersécurité. La première étape n’est pas un agent public qui répond à toutes les demandes. Les équipes support utilisent l’IA pour résumer les tickets, rapprocher les cas similaires, analyser le sentiment et repérer les escalades.
La trajectoire décrite par Salesforce et Checkmarx va de l’assistance interne vers la connaissance et le self-service client. Cette progression est intéressante : elle commence par une assistance aux équipes, avant d’exposer davantage le système à l’extérieur.
Entre mars et août 2025, Salesforce et Checkmarx rapportent une résolution au premier contact passée de 18 % à 30 % et un délai moyen de résolution passé de 9,5 à 5,6 jours. Ces données restent auto-déclarées et liées à la phase décrite. Elles illustrent une trajectoire prudente, pas une garantie de résultat pour tout service support.
Exemple 5 : le service client de Klarna
Klarna a annoncé en 2024 un assistant intégré à son application pour traiter des demandes de service client liées notamment aux retours, remboursements, litiges et paiements. L’entreprise a communiqué sur 2,3 millions de conversations et deux tiers des chats au cours du premier mois.
Ce cas doit être interprété avec prudence. Les chiffres sont publiés par Klarna et ne constituent pas un audit indépendant. Ils concernent une entreprise disposant d’un volume très important, d’une application propriétaire et de moyens d’intégration importants. La trajectoire a par ailleurs évolué vers un modèle plus hybride, avec un retour d’agents humains après des critiques sur la qualité du service.
L’enseignement utile n’est donc pas qu’un agent peut remplacer un service client. C’est qu’un agent peut prendre en charge certaines demandes répétitives, à condition de conserver une possibilité d’escalade et de mesurer la qualité réelle des réponses.
Définir les permissions avant le pilote
Un agent doit disposer d’une identité technique dédiée et de permissions limitées. Il ne devrait pas utiliser le compte personnel d’un salarié ni recevoir un accès administrateur « pour simplifier l’intégration ».
Séparer autant que possible :
- les droits de lecture
- les droits de préparation
- les droits d’écriture
- les actions soumises à validation
- les actions interdites
Un agent chargé de qualifier une demande n’a pas besoin de supprimer un client, de modifier un contrat ou d’effectuer un paiement. Les permissions doivent correspondre à la tâche, pas à la liste complète des fonctions disponibles dans l’outil.
Prévoir le contrôle, les traces et la reprise
Avant le pilote, définir ce qui doit être conservé :
- la demande initiale
- les données et documents consultés
- les outils appelés
- les champs préparés ou modifiés
- la validation humaine
- le résultat
- l’erreur éventuelle
- la durée d’exécution
- l’identifiant du dossier
Ces journaux peuvent contenir des données personnelles ou commerciales. Leur accès et leur durée de conservation doivent donc être maîtrisés.
Il faut aussi prévoir une reprise : dossier en échec, détection des doublons, action idempotente, possibilité d’annuler, retour au traitement manuel et personne responsable en cas d’incident.
Une panne ou un délai réseau ne doit pas provoquer deux remboursements, deux messages ou deux créations de ticket.
Mesurer le coût complet
Le coût d’un agent ne se limite pas au tarif du modèle. Il faut aussi considérer :
- l’intégration aux outils existants
- la préparation et la qualité des données
- les licences
- la supervision
- les tests
- les journaux et leur conservation
- la maintenance des connecteurs
- la formation des équipes
- le traitement des exceptions
Avant de lancer un pilote, mesurer une situation de référence pendant quelques semaines : volume de dossiers, temps moyen, taux d’erreur, escalades, satisfaction et coût par dossier.
Le pilote doit ensuite comparer ces indicateurs, et pas uniquement le nombre de tâches traitées par l’agent. Un agent qui répond deux fois plus vite mais génère davantage de reprises ou d’incidents n’a pas nécessairement amélioré le processus.
Une feuille de route indicative
Pour une PME, une démarche en quatre étapes peut constituer un point de départ. Le calendrier réel dépend de la qualité des données, des achats, des validations de sécurité et de la complexité des intégrations :
1. Première phase : choisir un workflow, le cartographier et mesurer la situation de référence ; 2. Deuxième phase : limiter l’agent à la lecture, préparer les données et tester les cas limites ; 3. Troisième phase : passer à la préparation avec validation humaine sur un périmètre restreint ; 4. Après le pilote : autoriser seulement certaines actions bornées, après mesure des erreurs, des coûts et des reprises.
Les opérations financières, juridiques, irréversibles ou fortement sensibles doivent conserver une validation humaine proportionnée à leur impact.
Conclusion
Intégrer un agent IA dans un workflow existant ne consiste pas à ajouter une conversation au-dessus d’un outil métier. Il faut cartographier le processus, choisir une étape limitée, définir les droits, mesurer le résultat et organiser la reprise lorsque l’agent échoue.
Les cas de Klarna, DoorDash, Microsoft, mobilezone et Checkmarx montrent des déploiements réels ou documentés par leurs fournisseurs, mais leurs chiffres restent liés à des contextes particuliers. Ils doivent servir à comprendre des méthodes d’intégration, pas à promettre les mêmes résultats.
Pour une PME, le meilleur premier cas est souvent une tâche répétitive, mesurable et réversible : rechercher une information, résumer un dossier, qualifier une demande ou préparer une réponse. L’autonomie vient ensuite, si les données, les contrôles et les responsabilités sont suffisamment solides.