Préparer une intégration IA qui se vérifie facilement.

Décrire l’intégration du point de vue de son utilisateur

Une intégration fiable exige de décrire fidèlement les outils exposés à un assistant. MCP est un protocole d’échange entre une application IA et des serveurs qui proposent notamment des outils et du contexte. La disponibilité d’une connexion ne suffit cependant pas à définir un bon parcours métier.

Prenons le cas fictif d’un distributeur qui souhaite consulter ses commandes depuis un assistant. La demande initiale est simple : « Où en est la commande du client ? » Pour y répondre correctement, l’intégration doit distinguer recherche du dossier, lecture du statut et éventuelle intervention.

Identifier le bon dossier avant de répondre

La question « Où en est la commande de Martin ? » semble naturelle, mais elle peut désigner plusieurs clients ou plusieurs commandes. L’intégration doit fournir les informations nécessaires pour résoudre cette ambiguïté : référence, date, établissement concerné et éventuellement montant ou résumé des articles. Le choix doit rester compréhensible pour la personne qui pose la question.

Dans notre exemple, le distributeur pourrait présenter deux commandes : une livraison de pièces à Lyon et un équipement destiné au site de Grenoble. L’assistant demande laquelle consulter. Il ne sélectionne pas automatiquement la commande la plus récente si aucun élément de la demande ne justifie ce choix. Une réponse exacte sur le mauvais dossier reste une réponse inutilisable.

La recherche doit aussi respecter le périmètre de l’utilisateur. Un responsable d’agence peut être autorisé à consulter certains établissements seulement. Ce contrôle doit intervenir avant que les informations soient transmises à l’assistant. La fiche d’opération peut alors distinguer un dossier introuvable dans le périmètre autorisé d’une recherche trop imprécise. L’utilisateur obtient une prochaine étape utile, sans que la connexion serve à révéler l’existence de dossiers auxquels il n’a pas accès.

Écrire une fiche pour chaque opération

Une fiche utile indique la question à laquelle l’opération répond, les données nécessaires et le résultat attendu. Pour « consulter une commande », elle peut demander une référence exacte et retourner le statut, la date de mise à jour et les lignes concernées. Si plusieurs commandes correspondent, elle doit permettre de les distinguer.

Ajoutez un exemple de résultat complet et un exemple de résultat partiel. Une expédition peut concerner seulement deux lignes sur trois. Présenter le dossier comme entièrement expédié parce qu’un colis possède un numéro de suivi serait une erreur de conception du résultat.

Prévoir un résultat que plusieurs outils comprennent

Un résultat d’intégration doit pouvoir servir à l’assistant, mais aussi à l’interface et aux contrôles automatiques. Définissez donc les informations qui restent stables : identifiant de la commande, statut, date de mise à jour et état de chaque ligne. Le texte présenté à l’utilisateur peut varier, tandis que ces données conservent une signification précise.

Le statut « en préparation » doit notamment avoir un sens partagé. Signifie-t-il que toutes les lignes sont disponibles, que certaines sont emballées ou simplement que la commande a été reçue ? Si le système métier distingue ces situations, l’intégration doit permettre de les restituer. Elle ne doit pas les ramener à une formule rassurante qui efface les différences utiles.

Décrivez également ce que signifie une valeur absente. Une date de livraison inconnue ne doit pas apparaître comme une date dépassée ou comme la date du jour. Une quantité égale à zéro doit rester différente d’une quantité non renseignée. Ces détails se vérifient facilement sur des exemples préparés à l’avance. Ils évitent qu’un autre outil interprète ensuite une absence d’information comme un fait confirmé et déclenche une action sur cette base.

Distinguer consultation et engagement

Dans cet exemple, lire le statut, préparer une demande de changement d’adresse et appliquer ce changement correspondent à trois capacités différentes. Les séparer permet d’attribuer des droits adaptés et de rendre la conséquence de chaque action visible à l’utilisateur.

Avant une modification, l’écran peut présenter la commande concernée, l’ancienne valeur, la nouvelle valeur et l’effet attendu. Le serveur doit contrôler les droits et les conditions métier au moment de l’exécution. Une commande déjà confiée au transporteur peut nécessiter une autre procédure.

Vérifier qu’une action peut être reprise sans doublon

Supposons qu’un utilisateur confirme une demande de changement d’adresse. Le système enregistre la demande, puis la connexion se coupe avant que l’assistant reçoive la réponse. L’utilisateur réessaie. Si chaque tentative crée un nouveau dossier, le service logistique reçoit deux demandes pour une seule intention. La gestion des reprises doit donc faire partie du contrat de l’opération.

L’équipe technique peut rattacher l’action à une référence unique, puis retrouver le résultat de cette action lors d’un nouvel essai. Le choix précis dépend du système connecté. Ce qui compte pour la recette est observable : après une interruption simulée et une relance, on retrouve une seule demande, avec un statut clair. La validation doit examiner les données enregistrées, pas uniquement le message de confirmation.

Une nouvelle intention doit toutefois rester possible. Si le client corrige une seconde fois son adresse, il s’agit d’un changement distinct, qui doit être traité selon les règles métier. Distinguez donc « réessayer la même action » de « demander une autre modification ». Cette distinction aide les développeurs à définir le mécanisme de reprise et les utilisateurs à comprendre ce qu’ils peuvent relancer sans créer de confusion.

Concevoir les réponses d’échec

Une référence inconnue, un accès refusé et une indisponibilité temporaire appellent des suites différentes. Le premier cas demande une vérification de la référence. Le deuxième relève des autorisations. Le troisième peut permettre un nouvel essai. Un message unique « une erreur est survenue » laisse l’équipe sans direction.

Prévoyez aussi le cas où le changement a été enregistré mais où la réponse n’est pas parvenue à l’assistant. Avant de relancer l’action, le système doit pouvoir retrouver son résultat. Cette situation mérite un exemple dans la recette fonctionnelle.

Préparer une recette qui couvre les situations gênantes

La recette doit inclure des demandes qui ne peuvent pas aboutir telles quelles. Essayez une référence inexistante, un dossier appartenant à un autre périmètre, un champ obligatoire absent et une modification devenue impossible après expédition. Pour chaque situation, définissez le résultat attendu et la prochaine action proposée à l’utilisateur. Vous vérifiez ainsi la qualité du service rendu lorsque tout ne se déroule pas comme prévu.

Ajoutez des demandes formulées différemment. « Change le lieu de livraison » et « Le colis doit aller à notre autre agence » peuvent exprimer le même besoin, mais la seconde formulation laisse une information manquante. L’assistant doit pouvoir demander l’adresse exacte. Un parcours utile accepte les formulations ordinaires tout en conservant des exigences précises pour l’action finale.

Consignez les résultats dans une grille simple : demande, dossier utilisé, opération effectuée, effet constaté et message affiché. La personne qui valide le projet peut suivre chaque cas de bout en bout. Lorsque l’intégration évolue, cette grille fournit aussi un ensemble de situations à rejouer. Une nouvelle capacité ne doit pas modifier silencieusement le comportement d’une opération déjà utilisée par l’équipe.

Faire essayer le parcours à une autre personne

Préparez un espace de démonstration avec quelques commandes fictives : une commande normale, une expédition partielle, une annulation et une référence introuvable. Donnez à un collègue des demandes exprimées comme celles d’un utilisateur. Observez s’il comprend les réponses sans connaître l’architecture.

La recette peut ensuite confronter chaque résultat à la source de référence. La commande affichée est-elle la bonne ? La date correspond-elle à la dernière mise à jour ? L’utilisateur comprend-il si une modification a réellement été appliquée ? Ces questions rendent la validation concrète.

Préparer une livraison vérifiable

Rassemblez les opérations disponibles, les droits nécessaires, les exemples de recette et le contact chargé des incidents. Si l’intégration doit être publiée dans un catalogue tiers, vérifiez séparément ses exigences officielles au moment de la soumission. Le guide métier et les règles du catalogue répondent à deux besoins complémentaires : un usage compréhensible et une publication acceptée.