La démo est convaincante. Votre agent pourra-t-il utiliser le logiciel ?
Matías Bonvin· Mis à jour le
Imaginez que vous achetiez un logiciel de gestion des commandes. Le commercial retrouve un client, modifie son adresse de livraison et envoie une confirmation avant que vous ayez terminé votre café.
L'équipe opérations apprécie. Quelqu'un demande alors si un assistant IA pourrait préparer cette même modification à partir d'un email client.
« Oui, nous avons une API. »
Gardez la démonstration ouverte. Il reste à voir ce que cette réponse permet réellement de faire.
Une API permet à deux logiciels de communiquer. Son existence ne précise ni les actions disponibles, ni les personnes autorisées à les approuver, ni ce qui arrive lorsqu'une requête échoue en cours de route. Ces détails détermineront les possibilités d'intégration de votre équipe.
Demandez une opération ordinaire
Choisissez une tâche que vos équipes réalisent déjà. Pour le logiciel de commandes, prenez un changement d'adresse sur une commande non expédiée. Travaillez dans un environnement de test avec des données fictives.
Demandez au fournisseur de montrer le parcours complet. L'assistant consulte la commande, vérifie qu'elle reste modifiable et prépare la nouvelle adresse. Une personne valide. Le logiciel enregistre la modification, puis l'assistant vérifie que l'adresse a bien été sauvegardée.
La démonstration n'exige pas un agent autonome. Un technicien peut appeler directement l'interface prévue. Vous testez les capacités de l'application avant de décider quelle marge de jugement confier à un agent.
Notez les endroits où le fournisseur quitte une fonction officiellement prise en charge pour utiliser un contournement. Si modifier l'adresse impose à un robot de navigateur de retrouver un bouton, la solution peut rester utilisable. Elle demande un entretien différent, notamment lorsque l'interface change. Intégrez ce travail à la décision d'achat.
Rendez les permissions visibles
Demandez un compte réservé à ce processus, avec les accès nécessaires et sans les droits étrangers à la tâche.
Dans cet exemple, l'assistant pourrait consulter une commande et proposer un changement d'adresse. Il ne devrait pas recevoir le droit d'émettre des remboursements parce qu'un compte administrateur partagé facilite la démonstration.
Testez cette limite. Tentez une action que le compte ne doit pas pouvoir exécuter, puis examinez le refus. Regardez ensuite le journal d'activité : permet-il d'identifier le compte, la modification exacte et son heure ? Si une validation humaine est nécessaire, peut-on la relier à la version réellement exécutée ?
Ce dernier point compte lorsque le dossier évolue pendant l'attente. Le client peut encore changer d'adresse. Une validation de la première adresse ne doit pas autoriser implicitement la seconde.
Interrompez la démonstration
Demandez au fournisseur de répéter une requête après une interruption simulée. Le logiciel reconnaît-il l'opération initiale ou en crée-t-il une nouvelle ?
Répéter un changement d'adresse peut être sans conséquence. Répéter une expédition, un débit ou une notification l'est beaucoup moins. Le fournisseur doit expliquer comment vérifier un résultat incertain avant de recommencer.
Testez aussi un accès expiré et une commande devenue non modifiable. Un échec utile donne à l'intégration assez d'informations pour s'arrêter ou transmettre le dossier à une personne. Un message générique suivi de tentatives à l'aveugle deviendra le problème de votre équipe.
Examinez enfin la reprise. Certaines modifications peuvent être annulées. D'autres exigent une action compensatrice, comme l'annulation d'une demande encore non traitée. Restaurer un champ en base ne rappelle pas un message déjà envoyé. Notez le cas qui s'applique.
Consignez les capacités disponibles aujourd'hui
Dans le dossier d'achat, distinguez ce qui a été démontré, ce qui est documenté mais non testé, ce qui est promis pour plus tard et ce qui est indisponible.
Pour chaque action indispensable, relevez l'abonnement nécessaire, les limites d'utilisation et les éventuels frais supplémentaires. Vérifiez comment le fournisseur annonce les changements d'interface et combien de temps il maintient la version précédente. Demandez si votre équipe peut exporter les traces nécessaires pour enquêter sur une opération échouée.
Cela ne justifie pas d'écarter un bon logiciel parce qu'il lui manque une fonction « agent » à la mode. Une interface stable, prise en charge et dotée des bonnes permissions peut suffire. Si l'achat se justifie déjà pour vos équipes, une étape manuelle peut être acceptable au départ. Chiffrez simplement ce travail.
Chez Solve IT, nous examinons le processus et connectons les systèmes capables de le soutenir. Avant l'achat d'une application, cela consiste à identifier les opérations nécessaires à l'assistant et à tester les points incertains dans un périmètre convenu.
Apportez la commande à modifier et la réponse du fournisseur au sujet de son API.