Quelles fonctions ouvrir aux agents IA ?

Rendez une fonction de votre entreprise accessible aux assistants IA lorsqu’elle répond à un besoin précis et que vos systèmes peuvent en faire respecter les limites. Partez de la tâche, des données nécessaires et de la personne responsable du résultat. Une FAQ publique peut simplement avoir besoin d’une page plus claire. Le statut privé d’une commande exige un accès contrôlé. Une réservation exige un processus d’approbation et de confirmation défini.

Une fonction « appelable par un agent » est une fonction que vous exposez pour qu’un assistant l’utilise, par exemple vérifier une disponibilité. Cela ne suppose pas de lui donner un accès général à vos systèmes.

Choisir une première tâche et ses limites

Prenons une entreprise de services fictive dont les clients demandent souvent si leur travail est terminé. Un premier outil utile pourrait indiquer le statut d’un seul dossier. Ses règles devraient préciser ceci :

• L’appelant doit avoir le droit de consulter ce dossier. Connaître son numéro ne suffit pas.
• La réponse contient le statut destiné au client, la date de sa dernière mise à jour et un moyen de joindre le soutien. Elle exclut les notes internes et les dossiers des autres clients.
• L’outil ne peut ni modifier le dossier, ni rembourser, ni promettre une date d’achèvement absente du système source.
• Si la source est indisponible ou si l’accès échoue, il le signale sans inventer de statut.

Comparez cette fonction au portail client existant avant de créer une autre interface. Si le portail répond déjà au besoin, précisez pourquoi les clients auraient besoin d’un accès par assistant et comment vous l’entretiendrez.

Pour une première version, gardez les paiements, remboursements, modifications destructrices et exportations massives de données personnelles hors du périmètre accessible. Toute extension proposée doit faire l’objet de sa propre approbation et de ses propres tests. Une consigne demandant au modèle de bien se comporter n’est pas un contrôle d’accès.

La lecture seule doit aussi être protégée

Une lecture peut divulguer un document privé, révéler la commande d’un autre client ou présenter un ancien prix comme actuel. Ces résultats peuvent nuire aux clients sans modifier la base de données.

Déterminez les droits à partir d’une identité vérifiée et des permissions côté serveur. Un account_id fourni par l’assistant ne prouve pas que le compte lui appartient. Même au sein d’une organisation, un employé n’a pas forcément accès à tous les documents.

Ce que fournit MCP et ce qu’il faut mettre en œuvre

Le Model Context Protocol (MCP) est un moyen de rendre des outils accessibles aux assistants. Les références ci-dessous concernent sa révision du 28 juillet 2026, vérifiée le 9 octobre 2026. Confirmez les versions que votre client et votre serveur prennent réellement en charge.

La spécification d’autorisation couvre l’autorisation HTTP, notamment la validation des jetons et les portées d’accès. Elle fait plus que transmettre une connexion. Votre implémentation doit toutefois relier les permissions accordées aux opérations et aux dossiers autorisés. Un jeton valide destiné à un autre service doit être refusé.

La spécification des outils exige validation des entrées, contrôles d’accès, limites de débit et assainissement des sorties côté serveur. Elle recommande une supervision humaine et des demandes de confirmation, sans imposer un seul modèle d’interaction. Connecter un client MCP ne prouve pas que ces contrôles fonctionnent dans votre application.

Les recommandations de sécurité précisent aussi que détenir un identifiant d’état ne constitue pas une authentification. Une référence de processus ou de panier identifie un élément à vérifier; elle ne détermine pas qui peut l’utiliser.

Rendre l’approbation précise et vérifiable

Pour une réservation proposée, montrez au client le service, le fuseau horaire, la date, le prix et les conditions d’annulation avant confirmation. Conservez ce qui a été approuvé. Si un élément important change, obtenez une nouvelle approbation. Un indicateur « approuvé » généré par le modèle ne prouve pas l’accord du client.

Séparez la préparation de la proposition de sa confirmation. Si enregistrer un brouillon crée un dossier ou envoie une notification, c’est déjà une écriture à intégrer aux permissions. Le serveur doit refuser l’engagement sans l’approbation requise pour ces conditions précises.

Notre offre de systèmes accessibles aux agents commence par la lecture et ajoute les actions créant des obligations en dernier, avec confirmation du client pour toute action irréversible. Notre projet pilote possède ses propres exigences d’approbation humaine pour les écritures, messages aux clients et mouvements d’argent. Un exemple général d’architecture n’élargit pas le périmètre contractuel.

Tester les refus et la reprise avant le lancement

Utilisez des comptes et dossiers de test. Conservez le résultat attendu à côté du résultat observé pour que le prochain développeur puisse reproduire le test.

Utilisez des permissions restreintes, des accès avec expiration et une révocation testée. Séparez les identifiants de connexion lorsque les limites de sécurité l’exigent; un compte distinct pour chaque outil n’est pas une règle universelle. Fixez des délais d’attente, des limites de reprise et des quotas par appelant. Pour les écritures, utilisez un identifiant stable d’opération et une gestion des doublons côté serveur, plutôt que la mémoire du modèle.

Journalisez l’appelant, l’opération, la décision d’accès, la référence d’approbation pertinente et le résultat. Masquez les secrets et les données personnelles inutiles; définissez qui peut lire les journaux et leur durée de conservation. Désignez un responsable capable de retirer un outil et de clarifier un résultat incertain. Le guide du pilote pour l’approvisionnement explique comment documenter ces responsabilités.

Ce que démontre notre exemple public

Le 9 octobre 2026, nous avons examiné tools/list sur mcp.strataigize.com, ses métadonnées publiques d’autorisation et auth.md. La liste annonçait sept outils de lecture publics et un outil authentifié request_growth_audit pour demander une consultation croissance gratuite. Malgré son ancien nom, il s’agit d’une consultation, pas de l’AI Opportunity Audit payant.

Cette demande est une écriture. La documentation exige la demande d’une personne précise et indique qu’une personne examine les soumissions; aucun rendez-vous n’est réservé automatiquement. Elle distingue explicitement l’inscription ouverte d’un client logiciel de la vérification de l’identité d’une personne.

Cet examen confirme l’interface et les règles publiées. Nous n’avons soumis aucune demande ni testé sa sécurité dans ce cadre. La liste des outils ne démontre ni usage externe ni ventes.

Avant de commander une interface, consignez la première tâche client, les données permises, les actions interdites, le moment de l’approbation, les tests d’échec, le responsable et la procédure de retrait. Mesurez les tâches correctement achevées, ainsi que les refus, les exceptions et le temps de révision. Les appels bruts incluent reprises et échecs; ils ne donnent pas le nombre de tâches réussies. Le conseil en IA peut aider à définir ce périmètre avant de commander l’intégration.