Des API prêtes pour les agents d'IA : ce dont votre système a besoin pour qu'un agent l'utilise sous contrôle

Un client demande à l'assistant d'IA de sa banque de payer sa facture d'électricité depuis son compte. L'assistant —un agent : un programme qui, face à une instruction, décide lui-même quels systèmes appeler et dans quel ordre— appelle l'API de paiement. La réponse tarde, la connexion se coupe. L'agent ne sait pas si le paiement est parti, alors il fait ce que ferait n'importe quel programme : il réessaie. Si l'API n'a aucun moyen de reconnaître qu'il s'agit du même paiement, le client se retrouve avec un double débit, une réclamation ouverte et une mauvaise opinion de sa banque.

Ce scénario n'exige ni agent malveillant ni mauvais modèle. Il suffit d'une API pensée, comme presque toutes, pour un développeur qui lit la documentation, connaît le métier et sait quoi faire quand quelque chose échoue. Un agent peut ne pas avoir ce contexte, et chaque ambiguïté du contrat se transforme alors en une action erronée.

Remplacez le paiement par l'émission d'une police, une commande qui décrémente un stock, un virement vers un portefeuille numérique ou une facture qui se timbre auprès du SAT (l'administration fiscale mexicaine), et le problème est de la même famille. Cet article s'adresse à celles et ceux qui répondent de ces systèmes dans une banque, une fintech, une compagnie d'assurance, une enseigne de commerce ou toute entreprise réglementée.

De plus en plus d'API vont avoir ce nouveau consommateur. Dans l'enquête Postman de 2025 —un éditeur d'outils d'API, avec plus de 5 700 participants—, 24 % des développeurs ont déclaré concevoir leurs API en pensant aux agents ; 60 % les conçoivent principalement pour des humains [1]. Cet article explique ce qui manque à une API pour qu'un agent l'utilise sous contrôle, lesquelles de ces briques sont déjà des standards et lesquelles ne le sont pas, et comment y arriver sans réécrire vos systèmes.

La connecter n'est pas la préparer

Aujourd'hui, « connecter » une API à un agent est facile. Le protocole MCP, que nous avons déjà expliqué dans ce blog, et les passerelles de plusieurs fournisseurs —Microsoft, AWS, Google, Kong et Cloudflare, entre autres— peuvent convertir un contrat OpenAPI en outils qu'un agent appelle [2]. Un contrat, dans ce contexte, est la description formelle, lisible par une machine, de ce que fait chaque opération d'une API et de ce qu'elle accepte.

Convertir le contrat règle la connexion, pas le contrôle. Une prépublication académique a examiné 116 serveurs MCP officiels et 80 contrats OpenAPI. Dans cet échantillon, 92 % des serveurs se contentaient d'encapsuler l'API telle quelle, et exposaient une médiane de 19 % de ses opérations. Le plus intéressant est venu ensuite : lorsque les auteurs ont corrigé automatiquement les contrats —descriptions, paramètres, regroupement—, la proportion d'outils qui fonctionnaient bien est passée de 76 % à 94,2 % [3].

La leçon : le premier goulot d'étranglement n'est pas le connecteur, c'est la qualité du contrat. Convertir 200 opérations en 200 outils ne donne pas 200 capacités à un agent ; cela lui donne 200 occasions de se tromper.

Les sept propriétés d'une API qu'un agent peut utiliser

1. Elle s'explique d'elle-même

Un développeur peut demander ce que signifie le paramètre type. Un agent, au mieux, le déduit ; au pire, il devine. C'est pourquoi chaque opération doit dire ce qu'elle fait pour le métier, et pas seulement quels types de données elle reçoit : « Annule le paiement programmé s'il n'est pas encore exécuté ; les paiements déjà exécutés sont contrepassés par une autre opération ». OpenAPI 3.2, la spécification en vigueur pour décrire les API, fournit les emplacements pour l'écrire : un identifiant stable par opération, des descriptions, des exemples et la manière de déclarer les notifications que l'API envoie à la fin d'un processus long [4]. La prépublication citée plus haut est précisément une preuve que réparer ces descriptions améliore les performances de l'agent [3].

Une nuance que presque personne ne mentionne : la spécification de MCP elle-même avertit que les descriptions et les annotations d'un outil ne sont pas fiables, sauf si elles proviennent d'un serveur de confiance [6]. Un outil qui dit de lui-même « je suis en lecture seule » ne devient pas sûr pour autant. La sécurité se met dans l'API, pas dans la description.

2. Elle est cohérente

Si une opération renvoie les dates dans un format et une autre dans un autre, l'agent doit apprendre chaque exception. Et la différence entre « je ne sais pas qui vous êtes » et « je sais qui vous êtes, mais vous n'avez pas la permission » compte plus qu'il n'y paraît : face à la première, l'agent tente de renouveler son jeton d'accès ; face à la seconde, il devrait s'arrêter ou demander une autorisation. Une API qui confond les deux envoie l'agent renouveler ses jetons en boucle, en consommant des quotas et en remplissant les journaux. Cette différence est définie dans le standard HTTP (les codes 401 et 403, dans la RFC 9110) [7], et le guide de l'IETF pour construire sur HTTP demande de ne pas réinventer ces significations [8].

3. Ses erreurs indiquent comment corriger

Lorsqu'un appel échoue, le message d'erreur est le guide le plus direct dont dispose l'agent. « Entrée invalide » l'envoie essayer au hasard ; « le montant doit être supérieur à zéro et inférieur à la limite quotidienne du compte » lui permet de se corriger en une tentative.

Cela a déjà un standard : la RFC 9457 (2023) définit un format d'erreur qu'une machine peut lire —type de problème, titre, statut et détail, plus les champs dont chaque API a besoin— et a remplacé la RFC 7807 [9]. Il n'est pas nécessaire d'inventer un schéma propre ; il faut utiliser celui qui existe, dans toutes les opérations, et indiquer dans chaque erreur s'il convient de réessayer. Avec mesure : l'erreur doit être précise sans exposer l'intérieur du système.

4. Réessayer ne duplique pas

Les agents réessaient ; cela fait partie de leur fonctionnement. Si un appel est coupé, ils ne savent pas si l'opération a été appliquée. Pour une consultation, ce n'est pas grave. Pour un paiement, une police ou un mouvement de stock, une nouvelle tentative peut exécuter l'opération deux fois.

La solution connue est la clé d'idempotence : le client envoie un identifiant unique avec chaque opération, et s'il la renvoie avec la même clé, l'API retourne le résultat d'origine au lieu de l'exécuter à nouveau. Avant de la mettre en œuvre, il faut savoir deux choses :

• Ce n'est pas un standard. Le brouillon de l'IETF pour l'en-tête Idempotency-Key a atteint sa version 07 en octobre 2025 et figure aujourd'hui comme expiré et archivé, sans être devenu une RFC [10]. C'est pourquoi chaque API doit publier ses propres règles : combien de temps elle conserve la clé, comment elle compare la requête répétée et ce qu'elle répond si la même clé arrive avec un autre contenu ou pendant que la première est encore en cours de traitement. Le brouillon distinguait ces cas par des réponses différentes [10].
• L'essentiel est ce qui se passe quand quelque chose échoue. Stripe, la référence en la matière, conserve le résultat de la première exécution même s'il s'agissait d'une erreur du serveur [11]. En termes simples : si la première tentative est restée dans le doute, la nouvelle tentative ne débite pas à nouveau ; elle répond au client « cela en est resté là, vérifiez avant d'essayer autre chose ».

Et tout ne doit pas être réessayé. Google, dans son guide de conception d'API, réessaie automatiquement les erreurs transitoires —indisponibilité, délais dépassés— et considère le quota épuisé comme ne justifiant généralement pas de nouvelle tentative, sauf cas documentés [12]. Si votre API ne dit pas ce qui justifie une nouvelle tentative, l'agent va le deviner.

5. Elle répond sous une forme constante

Un agent lit sans problème un texte libre ; ce qui lui coûte, c'est une structure qui change : un champ tantôt texte, tantôt objet, tantôt absent. Une liste vide doit être une liste vide, pas l'absence de la liste. Les opérations longues ont besoin de leur propre schéma : répondre immédiatement que la demande a été acceptée, avec un endroit où consulter son état, plutôt que de laisser l'agent attendre.

Et pour une entreprise réglementée, l'état d'une opération devrait distinguer au moins cinq issues : rejetée, non démarrée, en cours, terminée et résultat inconnu. Cette dernière est la plus oubliée et celle qui cause le plus de problèmes, car c'est précisément elle qui provoque la nouvelle tentative de l'exemple initial.

Lorsqu'une démarche touche plusieurs opérations —une création de client qui passe par trois systèmes, par exemple—, la spécification Arazzo permet de décrire le flux complet, étape par étape, pour que l'agent n'ait pas à déduire l'ordre [18].

6. Elle indique ce qu'il lui reste

Un agent dont la logique comporte une erreur peut faire des milliers d'appels en une nuit, et chacun consomme de la capacité de l'API et, souvent, aussi des tokens du modèle qui la paie. Si l'API lui indique dans chaque réponse ce qu'il lui reste de son quota et quand il se renouvelle, l'agent peut freiner avant de heurter la limite. Lorsqu'il la heurte, l'API peut répondre par le code 429 (« trop de requêtes », RFC 6585) et inclure l'en-tête Retry-After pour indiquer quand revenir [5][7]. GitHub, par exemple, demande d'attendre ce délai et, s'il n'est pas fourni, d'allonger progressivement l'attente ; insister peut bloquer l'intégration [14].

Le standard d'en-têtes pour communiquer le quota reste à l'état de brouillon à l'IETF, dans sa version 11 de mai 2026, et sa forme a changé d'une version à l'autre [15]. Le plus sensé est de choisir une convention, de la documenter et de l'appliquer de la même façon dans toutes les opérations.

7. Elle prévient avant de se retirer

Les API changent. Un développeur lit le courriel qui annonce le retrait d'une version ; un agent, non. Aujourd'hui, cela a déjà un standard : l'en-tête Deprecation a été publié comme RFC 9745 en 2025, et l'en-tête Sunset, qui indique quand l'API cessera de répondre, comme RFC 8594 [16][17]. Grâce à eux, un agent peut détecter à temps qu'il doit passer à la nouvelle version.

Ce qui est déjà un standard et ce qui ne l'est pas

Ce tableau est ce qu'il vaut le mieux avoir sous la main avant de concevoir. Confondre un brouillon avec un standard est le moyen le plus rapide de construire quelque chose qu'il faudra changer.

Standard : RFC publiée par l'IETF sur sa voie de standardisation. Brouillon : travail en cours qui peut changer ou être abandonné. RFC informative : guide non contraignant. Aucun n'est, à lui seul, une obligation légale.

Les lignes marquées comme standard ne prêtent guère à débat : ce sont la référence à suivre. Les lignes en brouillon sont des décisions de conception que chaque entreprise doit prendre et documenter, et ce sont celles qui varient le plus d'une organisation à l'autre.

À quoi cela ressemble dans votre secteur

Les sept propriétés sont les mêmes partout ; ce qui change, c'est ce qui casse quand elles manquent. Cinq scénarios, un par secteur, illustratifs et sans client :

Dans tous les cas, le même schéma se répète : une API aux états explicites réduit le risque qu'une nouvelle tentative fasse des dégâts, et agit de concert avec les contrôles d'identité, d'autorisation et de rapprochement que nous verrons ensuite.

La sécurité ne peut pas être confiée au modèle

Voici le point qui pèse le plus pour une banque, une fintech, une compagnie d'assurance, une enseigne de commerce détenant les données de millions de clients ou toute entreprise réglementée : un agent peut être trompé par les données qu'il lit. Un courriel, un document ou la réponse d'un autre outil peuvent contenir des instructions cachées, et l'agent peut les suivre. Cela s'appelle l'injection indirecte d'instructions, et l'OWASP la place en tête des risques des applications reposant sur des modèles de langage [22].

Le plus gênant est qu'il n'existe pas de détecteur infaillible, et l'OWASP le reconnaît lui-même [22]. Un groupe de chercheurs a attaqué douze défenses publiées, plusieurs avec un taux de réussite rapporté proche de zéro, et a dépassé 90 % de réussite contre la plupart d'entre elles en adaptant ses attaques [23]. L'institut de sécurité de l'IA du NIST a constaté quelque chose de semblable dans un environnement de bureau simulé : face au même modèle, la meilleure attaque connue a réussi dans 11 % des cas et une attaque nouvelle, dans 81 % [24]. La leçon n'est pas un taux général de vulnérabilité : c'est qu'une défense testée contre des attaques connues n'est pas une défense prouvée. Et le cas EchoLeak, dans un assistant d'entreprise à grande diffusion, a montré qu'un seul courriel, sans que personne ne clique, pouvait extraire des données internes [25][34].

La conclusion pratique n'est pas « n'utilisez pas d'agents ». C'est contenir les dégâts dans l'API, que vous contrôlez, au lieu de promettre que le modèle ne se trompera pas. Cela commence par séparer ce qu'un agent peut faire en trois niveaux :

Et sur cette séparation, quatre contrôles qui vivent dans l'API, pas dans le modèle :

• Une identité propre pour chaque agent. Un identifiant de machine, pas celui d'une personne. Lorsque l'agent agit au nom d'un client ou d'un employé, l'échange de jetons permet de représenter qui a délégué à qui [21] ; conserver cette trace est une décision de configuration et de journalisation qu'il faut exiger. Et les jetons peuvent être liés à celui qui les utilise, pour qu'un jeton volé ne serve pas à un autre [19][20]. L'incident de l'intégration Salesloft Drift, en 2025, était exactement cela : des identifiants d'une intégration volés et utilisés avec des requêtes qui semblaient valides [26]. C'est la même discipline d'accès qu'il convient d'appliquer aux personnes, et nous l'expliquons dans Maîtriser les accès.
• Des permissions minimales par opération. Un agent qui consulte le stock n'a pas besoin de pouvoir supprimer des clients.
• Des montants, des limites et des règles d'autorisation dans l'API, en dehors du modèle.
• Un journal de chaque action : quel agent, au nom de qui, avec quelle permission, ce qu'il a demandé, qui a approuvé et ce qui s'est passé.

La spécification de MCP va dans la même direction : lorsque son autorisation est utilisée, elle exige de valider que le jeton a été émis pour ce serveur et interdit de retransmettre le jeton de l'utilisateur à d'autres services [6].

Au Mexique, il y a en plus la loi

Deux textes changent la conversation. Le premier s'applique à tous les secteurs ; le second, au secteur financier. Ils ne remplacent pas l'examen de votre service juridique, mais il convient de les avoir à l'esprit dès la conception :

• Pour la banque et la fintech, la Ley Fintech (Ley para Regular las Instituciones de Tecnología Financiera, la loi mexicaine qui encadre les entités de technologie financière) impose, à son article 76, de partager les données au moyen d'API standardisées, en trois couches : données ouvertes, agrégées et transactionnelles. Le développement réglementaire n'est pas uniforme : il dépend du type d'entité, de la donnée et de l'autorité. La Banque du Mexique (Banxico), par exemple, a émis en 2020 des dispositions qui prévoient les trois couches pour les sociétés d'information de crédit et les chambres de compensation [13]. Et le texte de la loi comporte déjà un contrôle qui est exactement ce qu'exige un agent : l'accès d'un tiers est interrompu dès que le client retire son consentement, que des vulnérabilités sont détectées ou que le tiers manque à ses obligations, et l'interruption est notifiée à l'autorité en deux heures au plus [27]. Pour les interfaces soumises à cet article, pouvoir révoquer un accès sans manœuvres manuelles compliquées n'est pas un luxe ; pour les autres, c'est un contrôle qui vaut la peine d'être mis en place.
• Pour tous les secteurs —assurance et commerce compris—, la nouvelle Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, la loi fédérale mexicaine sur la protection des données personnelles détenues par des personnes privées), publiée en mars 2025, donne à la personne concernée le droit de s'opposer à un traitement automatisé qui, sans intervention humaine, évalue des aspects tels que sa situation économique ou son comportement et lui cause des effets juridiques non souhaités [28]. Si un flux avec des agents réalise ce type d'évaluation, il faut le vérifier au regard de cette règle. Et dans tous les cas, la loi demande des mesures de sécurité proportionnées au risque : l'usage des données par un agent fait partie du traitement, et entre dans la même analyse de risques et de contrôles [28].

Dans la plupart des cas, vos systèmes ne sont pas réécrits : ils reçoivent une façade

Aucune banque ne va réécrire son système central, aucune compagnie d'assurance son système de polices et aucune enseigne son ERP ou son point de vente pour qu'un modèle de langage les utilise, et dans la plupart des cas ce n'est pas nécessaire. La voie que recommande la littérature sur la modernisation —et celle que suivent les éditeurs eux-mêmes— est une façade : une couche qui expose à l'agent des opérations métier claires —consulter un solde, coter une police, enregistrer un retour, initier un paiement, consulter l'état d'une facture— et qui, à l'intérieur, traduit vers le langage du système existant [29].

Trois décisions déterminent si cette façade aide ou gêne :

• Ce qui est exposé. Des opérations métier étroites, pas des tables ni des transactions internes génériques. Un agent qui a accès à « exécuter n'importe quelle transaction » n'est pas un agent doté de capacités : c'est un risque.
• Quelles responsabilités restent dans la façade et lesquelles dans le système d'origine. Le guide de Microsoft sur ce modèle prévient que la couche de traduction ajoute de la latence et un service de plus à exploiter, et recommande de ne pas en faire le lieu des règles métier [29] ; si elle finit par décider ce que décidait auparavant le système central, elle devient un autre système hérité.
• Avec quelle preuve. Chaque opération exposée doit pouvoir démontrer ce que promet son contrat : qu'elle ne duplique pas, qu'elle peut être révoquée, qu'elle laisse une trace.

Les éditeurs vont dans cette direction : SAP propose sa couche de gestion d'API pour ajouter authentification, quotas et supervision aux services existants [30], et IBM expose des systèmes mainframe sous forme d'API décrites avec OpenAPI [31]. La technologie de la façade existe ; le plus difficile —et ce sur quoi les erreurs sont les plus fréquentes— est de décider ce qui est exposé, avec quelles règles et avec quelle preuve.

Que se passe-t-il si rien n'est fait

Les directions métier n'attendront pas. Si l'API n'est pas prête, quelqu'un va connecter un agent quand même : avec un identifiant personnel, sans journal et avec plus de permissions qu'il n'en faut. Le résultat typique n'est pas une attaque sophistiquée ; c'est un double débit qui finit en réclamation, un quota épuisé en pleine nuit ou un identifiant d'intégration qui fuit, comme dans les incidents cités plus haut. La préparer avant coûte généralement moins cher que d'avoir à expliquer l'incident après coup.

Comment savoir si cela fonctionne

Une réussite isolée ne dit rien ; ce qui mesure la confiance, c'est la régularité des résultats. Le benchmark τ-bench, de 2024, a proposé de mesurer combien de fois un agent résout la même tâche si on la lui répète. Dans ses tests, un modèle de pointe de l'époque résolvait moins de la moitié des tâches, et dans le domaine du commerce, moins d'un quart lorsqu'on lui demandait de réussir huit fois de suite [32]. Les chiffres de cette année-là ont déjà changé ; la méthode reste la bonne : mesurer des tâches complètes, plusieurs fois, avec leur état final, et mesurer à part les tentatives d'attaque [33].

Méfiez-vous des objectifs ronds qui circulent dans les supports d'éditeurs, comme « 85 % de réussite du premier coup » ou « moins de 1,5 nouvelle tentative ». Nous n'avons trouvé aucune source indépendante qui les étaye. Les objectifs se fixent avec vos propres données.

Par où commencer

1. Pour le diagnostic, priorisez par risque. Les opérations d'écriture —paiements, polices, commandes, stock, factures— sont celles qui peuvent le plus nuire si un agent les utilise mal ; c'est pourquoi elles sont examinées en premier.
2. Pour le premier cas d'usage, choisissez quelque chose de circonscrit. Une consultation, ou une opération réversible et soumise à approbation explicite. L'agent qui déplace de l'argent vient après, avec des preuves.
3. Corrigez sur place ce qui peut l'être. Ajouter des descriptions, des erreurs standard et des en-têtes de quota est généralement compatible avec les clients actuels, car la plupart ignorent les nouveaux champs ; malgré tout, cela se teste d'abord contre vos intégrations existantes. Si votre équipe programme en TypeScript, la leçon « Le serveur » de notre cours ouvert met justement cela en pratique : codes d'état et contrats qui n'exposent pas de données internes.
4. Placez une façade là où le système ne peut pas être modifié, avec des opérations métier étroites, de l'idempotence et un journal.
5. Testez avec de vrais agents et mesurez la régularité des résultats avant de leur ouvrir la porte de la production.

Savoir quel standard utiliser est la partie facile. Le difficile est de savoir lesquelles de vos opérations sont prêtes, lesquelles peuvent être corrigées sur place, lesquelles ont besoin d'une façade et quels contrôles ne peuvent pas être délégués à un agent. C'est ce que nous examinons dans un diagnostic : nous vous remettons la carte de vos opérations critiques, les risques de contrôle que nous avons trouvés et l'ordre dans lequel il convient de les traiter, pour que les équipes IT, sécurité, risques et métier décident avec la même information, en cherchant à ne pas réécrire vos systèmes.

Parlons de votre cas