SaaS pret pour les agents : structurer votre produit pour les agents IA

Pendant dix ans, la question pour un produit SaaS etait de savoir si une personne pouvait l'utiliser. Les ecrans, l'integration, les etats vides, tout etait regle pour un humain capable de lire une etiquette, de deduire un flux de travail et de se remettre d'un moment confus en cliquant un peu partout jusqu'a ce que les choses prennent sens. Un agent IA ne fait rien de tout cela. Il ne peut pas deduire votre flux de travail d'une mise en page astucieuse, il ne peut pas se remettre d'un enregistrement ambigu en le scrutant, et il ne peut pas dire lequel de deux boutons d'apparence semblable est le bouton sur. Il travaille a partir de la structure sous votre produit : la forme de vos donnees, la stabilite de vos identifiants, la clarte de vos actions et les limites de ce qu'il a le droit de faire. Etre pret pour les agents n'est pas une fonctionnalite que l'on rajoute. C'est une propriete de la maniere dont votre produit est construit sous les ecrans.

Ceci est un guide independant pour rendre un produit SaaS pret pour les agents, ecrit du cote de l'equipe qui construit et exploite le produit. L'ecosysteme des agents est jeune et les standards sont encore en train de se stabiliser, alors considerez les specificites ici comme la forme du travail plutot que comme une liste figee ; la ou un standard est pertinent, comme le Model Context Protocol, les details actuels se trouvent dans la specification du Model Context Protocol. Ce qui ne change pas, c'est ce dont les agents ont besoin pour bien fonctionner : des donnees propres qu'ils peuvent interpreter, des identifiants stables auxquels se raccrocher, des actions concues comme des taches discretes plutot que comme des flux d'interface, des permissions qui tiennent quel que soit l'appelant, et une surface deliberee, souvent un serveur MCP, qui expose la bonne tranche de tout cela. C'est ce que couvre ce guide.

Il complete notre explication de ce qu'est le MCP, notre guide sur le MCP pour le SaaS et notre article sur la conception des definitions d'outils MCP, puisque les outils que vous exposez ne valent que ce que vaut la structure du produit derriere eux.

L'essentiel en 60 secondes

• Les agents lisent la structure, pas les ecrans. Tout ce qu'un agent fait bien depend des donnees, des identifiants et des actions sous votre interface, pas de l'interface elle-meme.
• Des donnees propres sont la fondation. Un agent ne peut pas desambiguiser un enregistrement qu'un humain resoudrait d'un coup d'oeil, donc des donnees coherentes et bien formees sont ce qui lui permet d'agir correctement.
• Des identifiants stables sont non negociables. Un agent garde un identifiant a travers les etapes, donc un identifiant qui change ou est reutilise casse le travail en plusieurs etapes pour lequel les agents existent.
• Concevez les actions comme des taches, pas comme des flux d'interface. Une action propre fait une chose avec des entrees et des sorties claires. Un assistant reparti sur cinq ecrans n'est pas quelque chose qu'un agent peut piloter.
• Les permissions doivent tenir quel que soit l'appelant. Un agent agit pour le compte d'un utilisateur, donc son acces doit etre delimite aux permissions de cet utilisateur, applique cote serveur, a chaque fois.
• Exposez une surface deliberee. Un serveur MCP, ou une API propre derriere lui, est la maniere de donner aux agents la bonne tranche de votre produit a dessein, plutot que de les laisser extraire l'interface.
• Commencez par la lecture, meritez l'ecriture. Lire des donnees est a faible risque et a forte valeur ; ecrire change le monde, alors verrouillez les ecritures derriere des permissions et des approbations avant de les ouvrir.

Pourquoi etre pret pour les agents est une propriete du produit, pas un connecteur

Il est tentant de penser le support des agents comme quelque chose que l'on ajoute en peripherie : construire un serveur MCP, exposer quelques outils, c'est fait. Mais un connecteur ne peut exposer que ce que le produit en dessous prend reellement en charge. Si vos donnees sont incoherentes, les outils construits dessus seront peu fiables, aussi proprement soient-ils definis. Si vos identifiants sont instables, un agent qui en garde un a travers une tache en plusieurs etapes echouera d'une maniere que le connecteur ne peut pas reparer. Si votre seul chemin "creer une commande" est un assistant a cinq ecrans dont la logique est repartie dans le front-end, il n'y a pas d'action propre qu'un outil puisse appeler. Le connecteur est le dernier kilometre. La preparation est dans le produit.

C'est pourquoi il vaut la peine de traiter l'aptitude aux agents comme une propriete structurelle plutot que comme une demande de fonctionnalite. Les memes qualites qui rendent un produit pret pour les agents, donnees propres, identifiants stables, actions discretes et permissions appliquees, sont des qualites qui le rendent plus facile a maintenir, plus facile a integrer de maniere classique, et plus facile a raisonner. Le travail que vous faites pour rendre un agent fiable profite en general aussi a vos utilisateurs humains et a vos propres ingenieurs, car il s'agit surtout de rendre la structure du produit honnete et explicite plutot qu'implicite dans l'interface.

Le changement en cours est reel. A mesure que les agents passent de la reponse aux questions a l'action dans de vrais systemes, les produits agreables a piloter via un agent seront ceux dont la structure etait deja propre. L'introduction au Model Context Protocol presente le protocole comme une maniere standard de connecter les modeles aux outils et aux donnees dont ils ont besoin, et la valeur de cette connexion est bornee par la qualite de la structure des outils et des donnees de votre cote. Reussir la structure est la partie que vous seul pouvez faire.

Etape 1 : des donnees propres que les agents peuvent interpreter

Un agent agit sur vos donnees, donc la qualite de vos donnees fixe le plafond de la qualite avec laquelle l'agent peut agir. Un humain qui regarde deux fiches client nommees "Acme" et "Acme Inc." deduit qu'il s'agit probablement de la meme entreprise et passe a autre chose. Un agent ne peut pas faire ce saut en toute securite ; soit il les traite comme deux clients et fait la mauvaise chose, soit il demande a l'utilisateur et casse le flux. Des donnees propres et coherentes sont ce qui permet a un agent d'interpreter un enregistrement correctement sans deviner, et deviner est exactement ce que vous ne voulez pas qu'un agent fasse pour le compte de vos clients.

A quoi ressemblent des donnees propres et adaptees aux agents en pratique :

• Des formes coherentes. Les enregistrements d'un meme type ont les memes champs renseignes de la meme maniere, pour qu'un agent ayant appris a lire un client puisse les lire tous. Des enregistrements clairsemes et incoherents forcent l'agent a traiter chaque cas a part.
• Des noms et des valeurs de champ porteurs de sens. Un champ appele status avec des valeurs comme active et cancelled est lisible ; un champ appele flag3 avec des valeurs 0 et 2 ne l'est pas. L'agent raisonne sur ce que disent les champs.
• Des doublons resolus. Les enregistrements en double ou quasi en double sont la ou les agents font le plus souvent la mauvaise chose. Plus vos enregistrements sont propres, moins l'agent a a desambiguiser.
• Des relations explicites. Si une commande appartient a un client, le lien doit etre explicite et suivable, pour qu'un agent puisse passer de l'un a l'autre sans inferer la connexion.
• Des vides honnetes. Une valeur manquante doit se lire comme manquante, pas comme une chaine de remplacement ou une valeur par defaut perimee que l'agent prendra au pied de la lettre.

Vous n'avez pas a nettoyer chaque enregistrement avant d'exposer quoi que ce soit ; c'est un projet sans fin. Mais les donnees derriere les actions que vous exposez aux agents doivent etre propres, car ce sont les donnees sur lesquelles un agent agira. Commencez par la tranche que vous ouvrez, rendez-la coherente, et laissez le reste suivre. Le principe est simple : un agent n'est aussi fiable que les donnees qu'il lit, donc les donnees qu'il lit doivent etre fiables.

Etape 2 : des identifiants stables auxquels un agent peut se raccrocher

Les agents ont de la valeur parce qu'ils font du travail en plusieurs etapes : trouver la commande, verifier son statut, la mettre a jour, prevenir le client. Chaque etape apres la premiere depend du fait de garder un identifiant d'une etape precedente, ce qui signifie que vos identifiants doivent etre stables. Un identifiant qui change, qui est reutilise, ou qui n'est pas reellement unique casse la chaine en plein milieu, et l'agent finit par agir sur le mauvais enregistrement ou sur aucun. Des identifiants stables ne sont pas un confort pour le travail des agents. Ils sont ce qui rend possibles les taches en plusieurs etapes tout court.

Quelques proprietes rendent un identifiant fiable :

Le dernier point est facile a manquer. Si votre action "creer" ne renvoie qu'un message de succes, l'agent n'a aucune prise pour l'etape suivante ; il doit aller chercher la chose qu'il vient de creer, ce qui est lent et source d'erreurs. Une action de creation devrait renvoyer l'identifiant de ce qu'elle a cree, pour que l'agent puisse passer cet identifiant directement dans l'appel suivant. Cela rejoint directement la conception d'outils, que nous traitons dans concevoir des definitions d'outils MCP : un outil qui renvoie un identifiant utilisable est un outil qu'un agent peut chainer, et le chainage est la ou les agents gagnent leur vie. Traitez vos identifiants comme un contrat public des l'instant ou un agent peut les voir, car un agent les gardera a travers les etapes et a travers les sessions.

Etape 3 : des actions concues comme des taches, pas comme des flux d'interface

Une grande partie de la logique d'un produit SaaS typique vit dans le front-end, repartie sur les ecrans d'un assistant : une validation ici, une valeur derivee la, une etape de confirmation qui positionne discretement un indicateur. C'est tres bien pour un humain qui clique, et inutile pour un agent, qui n'a aucun ecran a cliquer. Pour qu'un agent prenne une action, cette action doit exister comme une tache discrete et appelable, avec ses entrees et ses effets au meme endroit, pas eparpilles dans un flux. Rendre vos actions pretes pour les agents implique souvent d'extraire la logique de l'interface pour la mettre dans une action propre que le produit peut realiser en un seul appel.

A quoi ressemble une action adaptee aux outils :

• Une tache, des entrees claires. L'action fait une seule chose reconnaissable, comme creer une facture, et prend les entrees dont cette tache a besoin, pas un ensemble partiel que l'interface completerait depuis un etat cache.
• La validation dans l'action, pas dans le formulaire. Si une regle compte, l'action l'applique, pour qu'un agent appelant directement ne puisse pas contourner un controle qui ne vivait que dans le front-end.
• Un retour porteur de sens. L'action renvoie le resultat et un identifiant, pour que l'agent sache qu'elle a fonctionne et puisse utiliser ce qu'il a cree, plutot qu'un succes nu sur lequel l'agent ne peut rien construire.
• Pas d'etat cache en plusieurs etapes. Une action qui depend secretement d'un ecran precedent ayant ete execute est une action qu'un agent ne peut pas realiser. La tache doit etre autonome ou ses prerequis doivent etre explicites.
• De l'idempotence la ou cela compte. Pour les actions qu'un agent pourrait reessayer, prendre en charge une nouvelle tentative sure, pour qu'un appel repete ne cree pas de doublon, protege contre la maniere dont les agents se remettent des erreurs.

C'est la meme separation qui rend une API testable et un produit maintenable : la logique metier appartient a la couche d'action, pas a la couche de presentation. Un agent rend simplement visible le cout de melanger les deux, car il ne peut atteindre que la couche d'action. Si la seule maniere de creer une commande passe par l'interface, la correction honnete est de construire une vraie action "creer une commande" et de faire en sorte que l'interface l'appelle aussi, ce qui vous laisse un produit plus propre et pret pour les agents en meme temps.

Etape 4 : des permissions qui tiennent quel que soit l'appelant

Un agent agit pour le compte de quelqu'un, et la propriete de securite la plus importante d'un produit pret pour les agents est que l'agent obtienne exactement l'acces qu'a cette personne, pas plus. Un agent qui appelle votre produit n'est pas un service interne de confiance ; c'est un appelant qui agit pour un utilisateur precis, et votre modele de permissions doit le delimiter aux droits de cet utilisateur et appliquer ce perimetre sur le serveur, a chaque appel, quoi que demande l'agent. Le mode de defaillance ici est le pire : un agent qui, par une requete confuse ou une instruction malveillante, atteint des donnees ou des actions auxquelles l'utilisateur derriere lui n'avait jamais droit.

Quelques principes pour garder l'acces des agents sur :

• Appliquez les permissions cote serveur, toujours. Ne comptez jamais sur l'agent, ni sur la definition d'outil, pour respecter une limite. Le serveur verifie les droits de l'appelant a chaque action, car l'agent n'est pas un garant de confiance.
• Delimitez a l'utilisateur agissant. L'agent herite des permissions de l'utilisateur pour le compte duquel il agit. Si cet utilisateur ne peut pas voir les donnees d'une autre equipe dans l'interface, l'agent ne doit pas non plus les voir via un outil.
• Moindre privilege par defaut. Exposez l'acces le plus etroit qui fait le travail. Un agent qui n'a besoin que de lire des commandes ne devrait pas detenir des identifiants pouvant les supprimer.
• Separez la lecture de l'ecriture. La lecture est a faible risque ; l'ecriture change le monde. Verrouillez plus etroitement les actions d'ecriture, et envisagez une etape d'approbation humaine pour les plus consequentes.
• Journalisez ce que l'agent a fait. Une piste d'audit indiquant quel agent a pris quelle action pour le compte de qui est ce qui permet d'enqueter, de rassurer les clients et de detecter les abus.

La perspective de securite ici n'est pas optionnelle, car un agent elargit les manieres dont votre produit peut etre pilote, et certaines de ces manieres sont adverses. L'injection d'instructions, ou des instructions cachees dans les donnees cherchent a faire agir un agent contre l'interet de l'utilisateur, est une preoccupation reelle, et la defense est en partie un modele de permissions qui ne laisse pas l'agent depasser l'utilisateur quoi qu'on lui dise. Le projet OWASP API Security est une solide reference independante pour les risques sous-jacents de l'exposition d'actions, et nous couvrons les controles specifiques aux agents, perimetres, approbations et garde-fous, dans securiser un serveur MCP. Les permissions sont la ou l'aptitude aux agents et la confiance se rejoignent, et bien les reussir est ce qui vous permet de dire oui aux agents sans dire oui au risque.

Etape 5 : exposer une surface MCP deliberee

Avec des donnees propres, des identifiants stables, des actions adaptees aux outils et des permissions appliquees en place, la derniere etape est de les exposer a dessein, a travers une surface concue pour les agents plutot que laissee a leur extraction. Pour beaucoup de produits, cette surface est un serveur Model Context Protocol : un ensemble defini d'outils, chacun correspondant a l'une de vos actions propres, avec des entrees types et des descriptions honnetes, situe derriere votre modele de permissions. L'interet d'une surface deliberee est que vous decidez de ce que les agents peuvent faire, plutot que de decouvrir apres coup ce qu'ils ont reussi a faire a votre interface.

Une surface deliberee a quelques caracteristiques :

• Un ensemble d'outils delimite. Exposez les taches qui comptent, pas un miroir mecanique de chaque endpoint. Une surface petite et nette est plus utilisable et plus facile a securiser qu'une surface exhaustive.
• Des outils qui correspondent a des actions propres. Chaque outil appelle l'une des actions discretes de l'etape trois, pour que la surface soit fiable parce que les actions en dessous le sont.
• Des definitions honnetes et types. Des noms, des descriptions et des schemas ecrits pour qu'un agent choisisse le bon outil et l'appelle correctement, ce que nous detaillons dans concevoir des definitions d'outils MCP.
• Des permissions appliquees derriere elle. La surface est une porte d'entree, pas un contournement. Chaque outil passe par les memes controles cote serveur que le reste de votre produit.
• La lecture d'abord, l'ecriture a dessein. Ouvrez les outils de lecture qui apportent de la valeur a faible risque, et ajoutez des outils d'ecriture a mesure que vous gagnez en confiance et que les garde-fous suivent.

C'est la meme approche par etapes que nous recommandons dans MCP pour le SaaS : commencer par une surface petite, utile et a faible risque, apprendre de la maniere dont les agents l'utilisent, et l'etendre a dessein. La surface est la ou tout le travail anterieur devient utilisable, mais elle ne vaut que ce que vaut ce travail. Un serveur MCP soigne au-dessus de donnees desordonnees et de permissions poreuses est une maniere rapide d'exposer des problemes aux agents a grande echelle. Un serveur modeste au-dessus d'une structure propre est quelque chose que les agents savent bien utiliser, ce qui est tout l'objectif d'etre pret pour les agents.

Erreurs frequentes, et comment les corriger

Traiter le support des agents comme un connecteur que l'on rajoute. La correction : traitez-le comme une propriete du produit. Un connecteur ne peut exposer que ce que le produit en dessous prend en charge, donc le travail de preparation est dans les donnees, les identifiants, les actions et les permissions, pas en peripherie.

Exposer aux agents des donnees incoherentes ou en double. La correction : nettoyez la tranche de donnees derriere les actions que vous exposez, avec des formes coherentes, des valeurs porteuses de sens et des doublons resolus. Un agent ne peut pas desambiguiser un enregistrement qu'un humain resoudrait d'un coup d'oeil.

Des identifiants instables ou non renvoyes. La correction : rendez les identifiants uniques, stables et jamais reutilises, et faites en sorte que chaque action de creation renvoie l'identifiant cree. Un agent garde les identifiants a travers les etapes, donc un identifiant qui bouge casse le travail en plusieurs etapes pour lequel les agents existent.

Enfermer les actions dans des flux d'interface. La correction : construisez des actions discretes et appelables avec leur validation et leurs effets au meme endroit, et faites en sorte que l'interface les appelle aussi. Un agent n'a aucun ecran a cliquer, donc une logique repartie sur un assistant est une logique qu'il ne peut pas atteindre.

Faire confiance a l'agent pour respecter les permissions. La correction : appliquez les permissions cote serveur a chaque appel, delimitees a l'utilisateur agissant, avec moindre privilege et une piste d'audit. L'agent est un appelant qui agit pour un utilisateur, pas un garant de confiance.

Ouvrir les actions d'ecriture avant d'etre pret. La correction : commencez par des outils de lecture qui apportent de la valeur a faible risque, et verrouillez les ecritures derriere des permissions plus etroites et, pour les plus consequentes, une etape d'approbation humaine. La lecture est sure ; l'ecriture change le monde.

FAQ

Que signifie reellement "pret pour les agents" pour un produit SaaS ? Cela signifie que la structure sous votre produit, ses donnees, ses identifiants, ses actions et ses permissions, est assez propre et explicite pour qu'un agent IA puisse la lire et agir dessus de maniere fiable, plutot que de dependre d'une interface reglee pour les humains qu'il ne peut pas utiliser. Un produit pret pour les agents expose des actions discretes avec des identifiants stables sur des donnees coherentes, applique les permissions cote serveur pour celui pour le compte de qui l'agent agit, et fait remonter la bonne tranche de tout cela a travers une interface deliberee comme un serveur MCP.

Ai-je besoin d'un serveur MCP pour etre pret pour les agents, ou une bonne API suffit-elle ? Une API propre et bien structuree represente l'essentiel du travail, car les donnees, les identifiants, les actions et les permissions y vivent, et un serveur MCP est une bonne maniere de presenter cela aux agents en particulier. Le protocole donne aux agents une maniere standard de decouvrir et d'appeler vos outils, ce qui reduit la friction par rapport au fait que chaque agent apprenne votre API sur mesure. Mais la preparation est dans la structure ; la surface MCP l'expose. Une API solide derriere un serveur MCP leger est une forme courante et raisonnable.

Pourquoi les identifiants stables sont-ils si importants pour les agents ? Parce que les agents font du travail en plusieurs etapes, et chaque etape apres la premiere depend du fait de garder un identifiant d'une etape precedente. Si un identifiant change entre les etapes, est reutilise pour un autre enregistrement, ou n'est pas reellement unique, l'agent agit sur la mauvaise chose ou perd le fil entierement. Des identifiants stables, uniques et jamais reutilises, renvoyes par les actions qui creent ou recuperent des enregistrements, sont ce qui rend possible une chaine d'etapes, ce qui est exactement la raison d'etre des agents.

Comment empecher un agent de faire quelque chose que l'utilisateur n'a pas le droit de faire ? Appliquez les permissions sur le serveur pour chaque action, delimitees a l'utilisateur pour le compte duquel l'agent agit, et ne comptez jamais sur l'agent ni sur la definition d'outil pour respecter une limite. L'agent herite des droits de l'utilisateur et de rien de plus, les actions d'ecriture sont verrouillees plus etroitement que les lectures, les actions consequentes peuvent exiger une approbation humaine, et tout est journalise. Le principe est que l'agent ne peut jamais depasser l'utilisateur, quoi qu'on lui demande de faire.

Devrais-je commencer par l'acces en lecture ou en ecriture ? La lecture d'abord. Lire des donnees est a faible risque et immediatement utile, permettant a un agent de repondre a des questions et de rassembler du contexte sans rien changer, c'est donc le bon endroit pour gagner en confiance et voir comment les agents utilisent votre surface. Les actions d'ecriture changent le monde et portent un vrai rayon d'impact, alors ouvrez-les a dessein, derriere des permissions etroites et, pour les plus consequentes, une etape d'approbation humaine. Meriter l'acces en ecriture par etapes est plus sur que de tout ouvrir d'un coup.

Le travail pour etre pret pour les agents aide-t-il autre chose que les agents ? Oui, et c'est en partie pourquoi il vaut la peine d'etre fait. Des donnees propres, des identifiants stables, des actions discretes dont la logique est sortie de l'interface, et des permissions appliquees cote serveur sont les memes qualites qui rendent un produit plus facile a integrer de maniere classique, plus facile a tester, et plus facile a raisonner pour vos propres ingenieurs. Les agents rendent simplement visible le cout d'une structure desordonnee, car ils ne peuvent pas la masquer avec une interface astucieuse comme un humain le peut.

Pour aller plus loin

• Introduction au Model Context Protocol pour la maniere dont le protocole connecte les modeles aux outils et aux donnees.
• Specification du Model Context Protocol pour les details de reference, a jour, du standard.
• Reference JSON Schema pour typer les entrees des actions que vous exposez aux agents.
• Projet OWASP API Security pour les risques de securite de l'exposition d'actions, qu'une surface d'agent amplifie.
• OWASP Top Ten pour le contexte plus large de securite applicative dans lequel s'inscrit tout produit destine aux agents.

En bref

L'aptitude aux agents est une propriete de la maniere dont votre produit est construit sous les ecrans, pas un connecteur que l'on ajoute en peripherie, car un connecteur ne peut exposer que ce que la structure en dessous prend en charge. Nettoyez les donnees derriere les actions que vous exposez, puisqu'un agent ne peut pas desambiguiser un enregistrement comme un humain le resout d'un coup d'oeil, et des donnees incoherentes ou en double sont la ou les agents font la mauvaise chose. Rendez les identifiants uniques, stables et jamais reutilises, et faites en sorte que les actions de creation les renvoient, car les agents gardent les identifiants a travers les taches en plusieurs etapes pour lesquelles ils ont de la valeur. Concevez les actions comme des taches discretes avec leur validation et leurs effets au meme endroit plutot qu'une logique repartie sur un flux d'interface qu'un agent ne peut pas cliquer. Appliquez les permissions cote serveur pour celui pour le compte de qui l'agent agit, avec moindre privilege et une piste d'audit, pour que l'agent ne puisse jamais depasser l'utilisateur quoi qu'on lui dise. Exposez ensuite une surface deliberee, souvent un serveur MCP, qui fait correspondre un ensemble delimite d'outils honnetes et types a ces actions propres, en commencant par la lecture et en meritant l'ecriture. Faites ce travail et un agent saura piloter votre produit aussi fiablement qu'un utilisateur attentif, ce qui est tout le sens d'etre pret pour les agents.

Si vous voulez de l'aide pour faire de votre produit quelque chose que les agents savent piloter en toute securite, un Partner Audit examine vos donnees, vos actions, vos permissions et votre surface destinee aux agents, puis vous remet un plan concret de ce qu'il faut nettoyer et de ce qu'il faut exposer.