Choisir un partenaire pour le développement d’agents IA : questions au-delà de la démonstration.

Une démonstration peut paraître parfaite jusqu’au moment où elle est confrontée à un environnement professionnel réel. Dans un cas typique, un agent trouve des informations, rédige une réponse et met à jour un enregistrement en moins d’une minute, ce qui donne l’impression que tout est prêt pour être mis en œuvre. Puis des problèmes pratiques apparaissent : que se passe-t-il si l’enregistrement est incomplet ? L’agent pourrait-il accéder à des données auxquelles l’employé n’a pas accès ? Fera-t-il une action supplémentaire en cas de délai d’attente de l’API ? Qui s’occupe de vérifier les erreurs lorsqu’un changement s’avère incorrect ?

Ces questions influencent la manière dont un fournisseur de développement d’agents doit être évalué. La bonne question n’est pas de savoir quelle entreprise propose la démonstration la plus fluide, mais plutôt quelle équipe comprend parfaitement tous les aspects qui la entourent. Les fournisseurs les plus solides proposent moins de démonstrations impressionnantes mais posent de meilleures questions concernant les flux de travail, les permissions, les intégrations, les pannes et les responsabilités.

Qu’est-ce qui a changé d’ici 2026

Récemment, les démos portaient sur la planification d’une tâche, l’utilisation d’un outil ou la poursuite d’une longue conversation. Ces compétences restent importantes, mais elles ne distinguent plus les équipes sérieuses des simples exécutants. Les acheteurs s’attendent désormais à ce que les agents puissent travailler avec des CRM, des systèmes de stockage de documents, des bases de données, des outils de gestion de tickets, des applications internes et des chaînes d’approbation.

C’est un problème plus difficile. L’agent doit comprendre la tâche, obtenir les informations nécessaires, choisir l’outil approprié, respecter les permissions, tenir un registre de ses actions et savoir quand s’arrêter. Les fournisseurs plus solides parlent moins d’intelligence autonome et davantage des conditions opérationnelles, et ils posent des questions telles que :

• Qui déclenche le flux de travail ?
• Quels systèmes sont impliqués ?
• Qu’est-ce que l’agent peut modifier ?
• Où un employé doit-il approuver quelque chose ?
• Comment récupérer une tâche qui a échoué ?

Qui possède l’agent après son lancement ?

Ces questions sont moins passionnantes qu’une démonstration en direct, mais elles sont bien plus proches du travail qui détermine si un agent survivra en production.

Commencer par le flux de travail

Les meilleurs prestataires partent du travail à effectuer et non du modèle. Demander un agent de vente est trop vague pour en partir, tandis qu’un flux spécifique est facile à comprendre : examiner une nouvelle opportunité, rechercher le compte, rédiger un suivi, demander l’approbation, mettre à jour le CRM. Il comporte un déclencheur, des étapes ordonnées et un résultat visible par tous.

Avant le début du développement, l’équipe doit avoir défini ce qui suit.

• Le déclencheur qui lance le flux de travail.
• Les informations nécessaires au flux de travail.
• Les systèmes auxquels il est connecté.
• Les points où des décisions sont prises.
• Les actions autorisées.
• Les approbations requises.
• Les conditions qui constituent un échec.
• Les critères de réussite.

Cette étape indique également s’un agent est vraiment nécessaire. Certaines tâches conviennent mieux à une automatisation fixe, tandis que d’autres nécessitent une recherche suivie d’une vérification par un humain. Un fournisseur qui recommande l’option la plus simple lorsque le comportement d’un agent flexible ne rajoute que peu de valeur envoie ainsi un signal utile d’honnêteté.

Les intégrations comptent plus que la fenêtre de chat

Les démonstrations privilégient l’interface utilisateur car elle est facile à présenter, mais c’est au niveau de la couche d’intégration que se trouve l’effort réel. Un agent peut lire un dossier client, récupérer une police d’assurance, mettre à jour un ticket, vérifier les stocks, compiler un rapport ou envoyer un message approuvé, et chaque étape dépend du bon fonctionnement d’un système métier conforme aux attentes.

Les systèmes réels ne sont pas coopératifs. Les identifiants expirent, les API ralentissent, les enregistrements disparaissent, deux applications peuvent retourner des données différentes, et une demande peut aboutir sans que la confirmation n’atteigne jamais l’agent. Les fournisseurs plus solides prévoient ces problèmes avant le lancement et couvrent :

• l’authentification et le stockage des identifiants,
• les vérifications de permissions,
• les délais de timeout des demandes,
• les tentatives de réessai sécurisées,
• la prévention des actions dupliquées,
• l’achèvement partiel d’une tâche,
• l’enregistrement des activités,
• la récupération manuelle.

Une conversation bien organisée ne peut pas compenser une intégration peu fiable. Une fois qu’un agent commence à modifier des enregistrements ou à déclencher des actions, la qualité de ces connexions fait partie intégrante du produit.

Les permissions montrent comment le risque est géré

Les permissions constituent l’un des principaux facteurs de distinction entre les équipes axées sur les prototypes et celles axées sur la production. Un prototype fonctionne souvent sous un compte de développeur doté d’accès étendus. Cela accélère la création de la première version, mais soulève une question cruciale : quels sont les droits dont l’agent doit disposer ?

Un agent de support peut avoir besoin de consulter une commande et de rédiger une réponse. Il n’a probablement pas besoin de tous les documents financiers, ni de la capacité d’effectuer un remboursement important. Un fournisseur compétent doit définir :

• qui peut activer l’agent,
• quelles informations il peut récupérer,
• quels outils il peut utiliser,
• quels documents il peut modifier,
• quelles actions nécessitent une approbation,
• quelles conditions doivent interrompre le flux de travail.

Ces limites font partie intégrante du processus opérationnel. Un document de politique stocké ailleurs ne pourra pas empêcher un agent d’effectuer une action pour laquelle il est techniquement autorisé.

Connaissances fiables

De nombreux agents commerciaux s’appuient sur des documents internes tels que des manuels, des contrats, des tickets antérieurs, des procédures, des politiques et des dossiers clients. Cependant, le fait d’utiliser ces documents ne garantit pas que les réponses soient fiables. Il reste à déterminer qui est responsable de ces documents, leur actualité et les règles en cas de conflit : quelle version d’un document compte, qui en assure la mise à jour, et que fait l’agent lorsque deux sources sont contradictoires.

La capacité à récupérer des informations dans une grande collection interne permet à un agent de consulter des passages pertinents avant de répondre ou de choisir sa prochaine action. La qualité reste cependant un enjeu, car une réponse assurée et bien rédigée peut encore être basée sur le mauvais document. Les personnes chargées de la vérification bénéficient également en pouvant voir ce que l’agent a lu : lorsque celui-ci propose quelque chose d’important, la personne qui le vérifie doit pouvoir examiner le matériel sur lequel se base cette proposition.

Plusieurs agents ne sont pas toujours mieux

Les systèmes multi-agents semblent impressionnants, mais sont souvent inutiles. Un seul agent suffit lorsque le flux de travail utilise un petit nombre d’outils et suit une séquence gérable. Ajouter plus d’agents entraîne des communications supplémentaires, des états plus complexes et un risque accru d’erreurs.

Plusieurs agents sont pertinents lorsque les tâches ont vraiment des rôles distincts, par exemple :

• un agent collecte les informations,
• un autre vérifie les exigences des politiques,
• un troisième prépare l’action proposée,
• une personne approuve l’étape finale.

La question importante n’est pas de savoir si un fournisseur peut créer un système multi-agents, mais plutôt si cette structure supplémentaire améliore le résultat. Un prestataire fiable peut expliquer pourquoi chaque agent existe, ce qu’il reçoit, comment le travail est transmis entre les agents et ce qui se passe en cas de désaccord.

Gestion des pannes

Les démos suivent un parcours sans problème, tandis que la production le fait rarement ; par conséquent, un fournisseur doit être capable de gérer des entrées complexes. Un plan de test utile expose l’agent à des situations délicates et vérifie les résultats :

• une demande manquant de détails,
• une recherche qui ne renvoie rien,
• des politiques qui se contredisent,
• une application intermédiaire devenue silencieuse,
• un utilisateur demandant quelque chose d’interdit,
• une appel à outil destiné au mauvais destinataire,
• une soumission dupliquée d’une même demande,
• une tâche qui ne peut pas s’achever en toute sécurité.

Il ne s’agit pas de résoudre chaque cas. Souvent, le comportement correct consiste à s’arrêter, poser une question pour clarifier, réessayer un nombre limité de fois ou transférer le cas à une personne. La fiabilité inclut la capacité à reconnaître quand continuer serait une erreur.

Le déploiement, c’est plus que de l’hébergement

L’hébergement constitue la partie la plus mineure d’une plateforme de déploiement. Une fois que les employés commencent à utiliser un agent, les opérateurs doivent surveiller son comportement et expliquer les échecs. Cela nécessite des journaux des appels effectués par l’outil, du matériel récupéré, des étapes du flux de travail, des résultats des approbations, des erreurs, des tentatives de réessai, de la latence, des coûts et des transferts d’informations aux personnes concernées.

En l’absence de tels traces, une équipe ne voit que le résultat final est incorrect et ne peut déterminer si le modèle, les données, le connecteur ou les instructions en sont responsables. La gestion des versions et le retrait des modifications permettent de résoudre ce problème. Les modèles, les prompts, les sources de données et les règles métier évoluent constamment, il doit donc être possible de savoir quelle configuration a produit un résultat donné et de revenir à une configuration fiable après une mise à jour défectueuse.

Revue humaine adaptée à la gravité de la situation

Exiger l’approbation pour chaque action d’un agent a peu de valeur et peut transformer un système utile en une version plus lente du processus ancien. Éliminer complètement l’examen par un humain crée le problème inverse. La solution raisonnable consiste à placer l’approbation là où les conséquences sont importantes. Un agent peut classer une demande, organiser des informations ou rédiger un brouillon par lui-même, tandis qu’un paiement, une modification de contrat, une restriction de compte ou un message ayant une portée juridique envoyé en dehors de l’entreprise peut encore nécessiter un employé autorisé.

Les personnes chargées de l’examen ont également besoin de contexte. Un bouton « Approuver » n’a guère de sens si la personne ne peut pas voir les informations sources, l’action proposée, le dossier concerné et la raison pour laquelle l’affaire lui est parvenue. Pour les workflows sensibles, les pratiques de gouvernance doivent relier les permissions, les approbations, le suivi, la responsabilité et la gestion des incidents aux opérations quotidiennes.

Responsabilité après le lancement

Une autre différence apparaît lorsque l’on aborde le déploiement. Certains fournisseurs considèrent que le lancement marque la fin du processus, tandis que les équipes plus solides discutent des semaines et des mois qui suivent. L’environnement de l’agent continue de changer : les manuels sont révisés, les API sont remplacées, le personnel trouve des moyens non planifiés d’utiliser le flux de travail, et de nouveaux types de demandes apparaissent que l’ensemble de tests initial n’avait jamais couverts.

Plusieurs tâches nécessitent un responsable : surveiller les performances, examiner les tâches échouées, mettre à jour les connaissances pertinentes, valider les modifications du flux de travail, suivre les dépenses, répondre aux incidents et décider du moment de désactiver l’agent. Un fournisseur peut continuer à offrir un soutien technique, mais une personne désignée au sein de l’entreprise doit assumer la responsabilité. Sinon, de petits défauts s’accumulent jusqu’à ce que le personnel cesse de faire confiance au système.

Questions à se poser avant de choisir

La qualité de la présentation doit passer après les réponses à quelques questions ciblées.

• Comment le fournisseur compte-il cartographier le flux de travail existant, et pourquoi a-t-il besoin d’un intermédiaire ?
• Quels systèmes seront impactés, et comment les permissions des utilisateurs y seront-elles transmises ?
• Qu’est-ce qui empêche une même action d’être exécutée deux fois, et que se passe-t-il en cas de panne d’outil ?
• Où un humain doit-il approuver les actions ?
• Comment la base de connaissances reste-t-elle à jour ?
• Comment la performance en temps réel est-elle mesurée, et qui gère le support une fois le système en fonctionnement ?
• Est-il possible de tracer et d’annuler n’importe quel changement ?

Un bon fournisseur répond en langage simple et relie chaque choix technique au flux de travail proposé.

Le point essentiel

Les bonnes équipes ne cherchent pas à donner l’illusion d’une indépendance totale. Elles mettent en place un système capable d’accomplir des tâches utiles dans des limites définies, ce qui nécessite un flux de travail clair, des intégrations fiables, un accès contrôlé, des connaissances fiables, des tests de défaillance réalistes, une révision humaine, un suivi ainsi qu’une responsabilité après le lancement. Une démonstration impressionnante est un bon moyen de lancer une discussion, mais elle constitue une base insuffisante pour une décision finale.