## Le contrôle budgétaire est intégré au modèle Donneriez-vous votre carte de crédit à une IA ? Je l'ai fait, pour cet épisode. Le plus intéressant n'est pas que cela ait fonctionné. C'est le protocole, et la couche de gouvernance, qui l'ont empêchée de dépenser trop. Voici le problème tel que je le rencontre constamment. La plupart des approches de paiement agentiques intègrent le contrôle budgétaire directement dans le LLM : une invite système qui dit "ne dépense pas plus de X $". C'est structurellement la même chose que de demander à quelqu'un de faire respecter sa propre limite de dépenses. Le modèle qui décide d'acheter est le modèle qui vérifie s'il doit le faire. Lorsque ce sont les mêmes composants, vous n'avez pas de contrôle. Vous avez une suggestion. Il existe désormais un protocole ouvert visant précisément ce problème : **AP2, l'Agent Payments Protocol v0.2**, construit par l'équipe A2A de Google et donné à la FIDO Alliance. L'idée centrale est simple : le mandat réside en dehors de l'agent. Il est externe, signé cryptographiquement, et l'agent ne peut pas le outrepasser. L'agent opère à l'intérieur d'une limite qu'il n'a pas tracée et ne peut pas retracer. AP2 définit une chaîne de mandats, et cette chaîne est tout l'intérêt : Agent d'achat, Mandat de paiement, Agent marchand, Mandat de paiement, Fournisseur de justificatifs, Processeur de paiement. Chaque étape est vérifiable. Aucune étape ne peut être omise. Un paiement n'a lieu que lorsque toute la chaîne est validée. ## Le scénario : des billets pour les quarts de finale de la FIFA 2026 Les protocoles abstraits nécessitent un achat concret, donc la démo est un concierge d'achat consommateur avec un cahier des charges impitoyable. L'utilisateur signe un mandat : 2 billets de catégorie 3 pour un quart de finale de la FIFA 2026, à moins de 1 500 $ chacun, avec un plafond strict de 3 200 $ au total. L'agent surveille TicketVault, une place de marché de billets fictive, pendant la nuit. Aucun humain n'est présent. Lorsqu'un prix baisse, une politique de dépenses DMN évalue le panier dans une tâche de règle métier Camunda. Cette évaluation se produit en dehors du modèle, nativement dans Camunda, et son résultat détermine tout ce qui suit. J'ai construit trois chemins à travers la même couche de gouvernance : | Chemin | Déclencheur | Résultat DMN | Résultat | |---|---|---|---| | Doré | Le prix baisse à 1 350 $, panier 2 700 $ | APPROUVER | Reçu de 2 700 $, entièrement autonome | | HITL | Le prix baisse à 1 560 $, panier 3 120 $ (97,5 % du plafond) | HITL_REQUIRED | Approbation du service de paiement avant le paiement | | Violation du mandat | Achat permanent de 3 500 $ dépasse le plafond de 3 200 $ | REFUSER | Refus automatique avant même d'atteindre le processeur | Le chemin doré est la démo que tout le monde veut voir : le prix baisse à 3 heures du matin, l'agent achète, un reçu attend le matin. Les deux autres chemins sont le produit. Un panier à 97,5 % du plafond ne passe pas grâce à une technicalité ; il réveille un humain au service de paiement. Et un achat dépassant le plafond n'est pas négocié par une invite astucieuse ; il est refusé par une table de règles avant même que le processeur de paiement n'en entende parler. ## La couche de gouvernance La politique de dépenses DMN est composée de cinq règles, et j'aime qu'elle soit ennuyeuse : une vérification de plafond, un déclencheur de quasi-plafond qui achemine tout ce qui dépasse 95 % du mandat vers une révision humaine, une liste blanche d'instruments de paiement, une limite de vélocité et une approbation fourre-tout. Elle s'exécute dans Camunda en tant que tâche de règle métier, et non à l'intérieur du LLM. L'agent ne voit jamais la politique comme un texte qu'il pourrait rationaliser. Il voit un résultat de décision. La troisième couche est la piste d'audit, et elle est gratuite avec l'architecture. Chaque étape d'autorisation est enregistrée dans Camunda Operate : mandat émis, prix capturé, DMN évalué, justificatifs émis, reçu stocké. Chaque décision, de manière permanente, en tant qu'instance de processus que vous pouvez ouvrir et rejouer. Personne n'a écrit de code de journalisation pour obtenir cela. > Le LLM propose. Le DMN dispose. Si votre politique de dépenses peut être modifiée par un paragraphe bien formulé, ce n'est pas une politique de dépenses. ## Des mandats, pas de la confiance AP2 v0.2 définit deux types de mandats, et chacun a une étape ouverte et une étape fermée. Ouvert signifie que l'utilisateur pré-signe les contraintes. Fermé signifie que l'agent signe la transaction spécifique qui s'est produite dans ces contraintes. **Le Mandat de paiement.** L'utilisateur pré-signe la portée de l'article, le prix plafond, un TTL et une liste blanche de marchands. Au moment de l'achat, l'agent le clôture avec le panier spécifique : SKU, prix, hachage de paiement. Le marchand vérifie le mandat clôturé avant de livrer quoi que ce soit. **Le Mandat de paiement.** L'utilisateur pré-autorise l'instrument de financement : la source, le montant maximum, les restrictions de catégorie. L'agent le clôture avec le montant exact et le hachage de paiement. Le Fournisseur de justificatifs vérifie les deux mandats avant d'émettre le jeton de paiement. L'étape de clôture est celle où la cryptographie prend tout son sens. Chaque mandat est lié à une transaction spécifique via une signature ECDSA P-256. Aucun mandat ne peut être réutilisé. Aucun ne peut être falsifié. Et toute partie de la chaîne peut vérifier indépendamment, sans autorité centrale requise. Cette dernière propriété est ce qui fait de la chaîne un protocole plutôt qu'une plateforme. Cet épisode a un article complémentaire qui approfondit les mécanismes du protocole, le modèle de menace et les modes de défaillance : le [Guide de terrain AP2](/fr/guides/ap2-field-guide/). Si cet article est l'épisode, le guide de terrain est le manuel. ## Ce qui n'a pas été inclus dans le post LinkedIn Cet épisode est encore en cours de construction, donc les notes honnêtes sont plus importantes que d'habitude. La démo simule plusieurs composants AP2. Le Fournisseur de justificatifs et le transport A2A complet sont simulés à des fins de démonstration ; TicketVault est une place de marché factice. Ce qui est fidèle à AP2 v0.2, c'est la partie qui compte pour évaluer le protocole : la structure du mandat, la logique de signature (véritable SD-JWT via jose, véritables signatures ECDSA P-256) et les interactions entre les parties. Et la couche de gouvernance n'est pas du tout simulée : le BPMN, la politique de dépenses DMN et le service de paiement HITL sont de véritables Camunda 8 fonctionnant sur un cluster SaaS en direct. Les modèles de mandat sont également délibérément agnostiques à la pile technologique. Camunda est mon moteur, mais le même flux de mandat "ouvrir-puis-fermer" fonctionne sur Temporal, LangGraph, n8n ou du simple Node.js. Le dépôt inclut un document MAKE_IT_REAL avec un chemin de mise à niveau en 5 étapes de cette démo vers la production AP2, couvrant exactement quels composants simulés vous remplacez et dans quel ordre. Une autre note honnête : le dépôt est privé jusqu'à la sortie de l'épisode. Il sera rendu public avec l'épisode, ainsi que la vidéo de démonstration. Le guide de terrain est déjà en ligne, car l'analyse du protocole n'a pas besoin d'attendre mon calendrier de production. ## Journal de bord - **Protocole :** AP2 v0.2 (Agent Payments Protocol, équipe Google A2A, donné à la FIDO Alliance) - **Moteur :** Camunda 8 (cluster SaaS en direct) : orchestration BPMN, politique de dépenses DMN, service de paiement HITL - **Modèle :** Claude Sonnet comme agent d'achat - **Cryptographie :** SD-JWT via jose, signatures de mandat ECDSA P-256 - **Politique :** Table de décision DMN à 5 règles (plafond, HITL à 95 % près du plafond, liste blanche d'instruments, vélocité, fourre-tout) - **Frontend :** React avec AG-UI sur SSE, repris de l'EP 02 - **Backend :** Node.js - **Complément :** [Guide de terrain AP2](/fr/guides/ap2-field-guide/) - **Dépôt :** public lors de la sortie de l'épisode