Connecter un outil à l’IA : quel travail lui confier ?

Connecter un agenda permet à un traitement d’accéder à certaines opérations. Cela ne décide pas quelle salle choisir, qui peut réserver ni comment résoudre deux demandes concurrentes. Une intégration utile doit décrire le travail à accomplir avec cet accès.

Je propose de distinguer trois éléments : les capacités techniques exposées, la procédure qui les utilise et les personnes responsables des décisions.

Une réservation comme exemple

Exemple fictif. Un agent reçoit une demande de réunion pour six personnes mardi après-midi. Il peut consulter des calendriers et proposer la création d’un événement. La durée et le besoin de visioconférence restent inconnus.

La connexion fonctionne, mais ces informations peuvent empêcher de choisir correctement. Une salle libre peut être trop petite. Un créneau disponible peut se terminer avant la fin prévue de la réunion. Le modèle ne doit pas transformer ces inconnues en choix implicites.

La procédure doit préciser les renseignements nécessaires, les critères de sélection et la façon de demander une décision.

Écrire les trois responsabilités

Une opération exposée n’est pas nécessairement autorisée pour toutes les demandes. Les droits du compte et les contrôles de l’application doivent limiter les actions au périmètre convenu.

Un protocole d’accès commun peut faciliter l’utilisation de plusieurs outils ; le Model Context Protocol, par exemple, décrit comment un agent découvre et appelle les fonctions qu’un outil expose. Il ne fournit pas automatiquement les règles métier de votre organisation. La conception doit les rendre explicites, quel que soit le mécanisme technique retenu.

Prévoir le temps entre proposition et action

Un créneau peut être libre lorsque l’agent le consulte et occupé au moment de confirmer. La procédure doit vérifier l’état utile au moment de l’action et expliquer ce qui arrive si la proposition n’est plus réalisable.

Il faut aussi définir la relance. Si la création réussit mais que la réponse se perd, rejouer aveuglément la demande peut créer un second événement. Le traitement doit pouvoir retrouver le résultat de l’opération précédente ou signaler l’incertitude avant de recommencer.

Pour expliciter ces embranchements, un organigramme Mermaid peut représenter le parcours : demande complète, disponibilité vérifiée, confirmation obtenue, puis réservation. Chaque refus devient une branche à tester. Le schéma décrit la procédure souhaitée ; il ne prouve pas que le connecteur la respecte.

Tester l’intégration par ses effets

Préparez des scénarios fictifs : réservation ordinaire, durée absente, salle devenue indisponible et demande répétée. Vérifiez l’événement réellement créé, ses participants et le nombre de réservations, en plus du message affiché.

Ajoutez un accès révoqué. Le résultat doit montrer que l’outil n’a pas pu être consulté, sans présenter une ancienne disponibilité comme une vérification récente.

Cadrer la demande avant le choix du connecteur

Une fiche de besoin peut préciser la tâche, les utilisateurs, les données nécessaires et les effets autorisés. Elle permet ensuite d’examiner si les accès disponibles suffisent ou si une adaptation est nécessaire.

Pour une intégration avec TARS, cette vérification se fait sur votre outillage et votre processus. La présence d’un connecteur ne permet pas, à elle seule, de promettre une réservation complète ni son fonctionnement dans toutes les situations.