Votre agent vocal appelle un client pour un impayé. Il propose un règlement immédiat. Le client dit oui. Aujourd'hui, cet accord oral déclenche au mieux l'envoi d'un lien de paiement par SMS. Demain, avec AP2, il pourra devenir un ordre de paiement signé, vérifiable et exécuté sans rupture de canal. C'est ce que le protocole AP2 (Agent Payments Protocol) de Google rend possible.

Annoncé par Google Cloud en septembre 2025 avec plus de soixante partenaires de lancement - dont Mastercard, PayPal, American Express, Coinbase et Salesforce - AP2 répond à un problème précis : comment un agent IA peut-il dépenser ou encaisser de l'argent au nom d'un humain, sans que cette délégation devienne un vecteur de fraude ou un vide juridique ?

Pour les éditeurs et intégrateurs d'agents vocaux téléphoniques, AP2 complète les protocoles d'interopérabilité déjà en place. Le Model Context Protocol (MCP) connecte un agent à des outils et des données. Le protocole A2A connecte un agent à d'autres agents. AP2 connecte un agent à l'argent - avec une preuve cryptographique du consentement à chaque étape.

Ce guide explique le fonctionnement d'AP2, ce qu'il change concrètement pour un callbot de recouvrement, de commande ou de renouvellement d'abonnement, et les précautions de sécurité et de conformité à respecter avant de l'adopter en production téléphonique.

Qu'est-ce que le protocole AP2 ?

AP2 (Agent Payments Protocol) : protocole ouvert créé par Google, qui donne à un agent IA une autorisation cryptographiquement signée par un humain avant qu'il ne puisse dépenser ou encaisser de l'argent en son nom. Cette autorisation prend la forme de « mandats » - des contrats numériques vérifiables qui prouvent l'intention et le consentement de l'utilisateur.

Le problème qu'AP2 résout est celui de la confiance dans le commerce agentique : à mesure que des agents IA négocient, comparent des prix, remplissent des paniers et concluent des transactions pour le compte d'un utilisateur, les émetteurs de cartes, les banques et les commerçants ont besoin d'une preuve fiable que la transaction a bien été autorisée par l'humain - et non générée par une hallucination du modèle ou une action malveillante.

AP2 répond à cette exigence par une chaîne de mandats signés numériquement, indépendante du rail de paiement utilisé : carte bancaire, virement en temps réel ou stablecoin. Il s'intègre nativement avec l'écosystème A2A et MCP de Google, mais reste un protocole ouvert utilisable par n'importe quel fournisseur.

Comment fonctionnent les mandats Intent, Cart et Payment

Le cœur technique d'AP2 repose sur trois types de mandats, chacun signé par un identifiant vérifiable et horodaté :

  • Intent Mandate - décrit ce que l'utilisateur autorise l'agent à faire, en amont de toute transaction précise. Exemple : « je t'autorise à régler mes factures en retard jusqu'à 200 € sans repasser par moi ».
  • Cart Mandate - une fois que l'agent a préparé une transaction concrète (montant exact, bénéficiaire, motif), ce mandat fige les termes précis et doit être confirmé, explicitement ou selon les règles de l'Intent Mandate.
  • Payment Mandate - l'ordre final transmis au prestataire de paiement (banque, réseau de carte, portefeuille), accompagné de la preuve cryptographique que les deux mandats précédents ont bien été respectés.

Cette chaîne de trois mandats crée un audit trail complet : à tout moment, il est possible de reconstituer ce que l'utilisateur a autorisé, ce que l'agent a proposé, et ce qui a été effectivement débité. C'est cette traçabilité qui permet aux émetteurs de cartes et aux régulateurs d'accepter qu'un agent IA agisse comme initiateur de paiement.

Mandat Rôle Moment dans l'appel
Intent Mandate Cadre général d'autorisation (plafond, périmètre) Souscrit en amont ou en tout début d'appel
Cart Mandate Détail exact de la transaction proposée Après confirmation orale du montant par l'appelant
Payment Mandate Ordre d'exécution transmis au prestataire de paiement Juste avant la fin de l'appel ou en tâche de fond

Cas d'usage pour un agent vocal IA téléphonique

Plusieurs scénarios de centre de contact et de recouvrement bénéficient directement d'un flux de paiement AP2 :

  • Recouvrement avec règlement immédiat - l'agent vocal détecte un impayé, négocie un montant ou un échéancier, et déclenche le paiement sans transfert vers un conseiller humain ni rupture de canal.
  • Renouvellement d'abonnement - un agent sortant appelle avant l'échéance d'un contrat, confirme les nouvelles conditions tarifaires, et exécute le renouvellement si l'appelant l'autorise.
  • Commande vocale avec encaissement - dans la restauration ou le retail, un agent vocal prend une commande, calcule le total et encaisse directement, sans renvoyer l'appelant vers un terminal ou un lien web.
  • Régularisation de solde - un agent d'assurance ou de mutuelle propose de régulariser une cotisation en retard pendant l'appel de gestion d'un sinistre.

Dans chacun de ces scénarios, le gain n'est pas seulement la vitesse : c'est la suppression d'une rupture de parcours. Aujourd'hui, la majorité des callbots qui doivent encaisser renvoient l'appelant vers un SMS, un email ou un serveur DTMF séparé. AP2 vise à terme à supprimer cette bascule de canal, à condition que l'authentification du payeur reste solide.

AP2, A2A et MCP : trois protocoles complémentaires

AP2 ne remplace ni A2A ni MCP. Il s'ajoute à la pile de protocoles ouverts qui structurent un agent IA en production, chacun couvrant une couche distincte.

Critère MCP A2A AP2
Communication entre Agent et outils/données Agent et autres agents Agent et prestataires de paiement
Ce qui est standardisé Accès aux ressources et actions Délégation de tâches Autorisation et exécution d'un paiement
Mécanisme central Serveurs MCP, outils exposés Agent cards, tâches Mandats signés (Intent, Cart, Payment)
Initiateur Anthropic (open source) Google (open source) Google (open source)
Maturité en 2026 Production généralisée Adoption croissante Naissante, pilotes en cours

Dans une architecture de callbot avancée, les trois protocoles peuvent coexister sur un même appel : l'agent frontdesk utilise MCP pour lire la facture du client dans le CRM, A2A pour déléguer la négociation à un agent de recouvrement spécialisé, puis AP2 pour obtenir le consentement et exécuter le règlement.

Sécurité, DSP2/SCA et conformité RGPD

Un mandat AP2 ne dispense d'aucune obligation réglementaire européenne. En France et dans l'Union européenne, tout paiement reste soumis à la directive DSP2 et à l'authentification forte du client (SCA - Strong Customer Authentication). Un accord oral pendant un appel ne constitue pas, à lui seul, une preuve d'authentification suffisante pour signer un Payment Mandate.

Précautions indispensables pour un déploiement conforme :

  • Authentification forte du payeur - biométrie vocale déjà enrôlée, code à usage unique envoyé par SMS, ou application bancaire tierce, avant la signature du Cart ou du Payment Mandate.
  • Consentement explicite et horodaté - la confirmation orale de l'appelant est enregistrée et associée au mandat, mais ne remplace pas le facteur d'authentification technique exigé par la SCA.
  • Minimisation des données dans les mandats - seules les données strictement nécessaires à la transaction (montant, bénéficiaire, référence) transitent dans les mandats, conformément au principe de minimisation du RGPD.
  • Conservation et chiffrement - les mandats signés sont conservés chiffrés, avec une durée de conservation définie et documentée, au même titre que tout justificatif de transaction bancaire.
  • Conformité PCI-DSS - dès qu'un numéro de carte ou un jeton de paiement transite par l'agent vocal, les exigences de tokenisation et de segmentation réseau du PCI-DSS pour les agents vocaux s'appliquent intégralement, quelle que soit la couche protocolaire utilisée.

Architecture technique d'un flux de paiement AP2 pendant un appel

Flux type d'un appel de recouvrement avec règlement AP2 :

  1. L'appelant est identifié et le solde impayé est lu depuis le CRM via MCP.
  2. L'agent vocal négocie oralement un montant et une date de règlement.
  3. L'appelant confirme verbalement. L'agent déclenche une authentification forte (SMS OTP ou biométrie vocale déjà enrôlée).
  4. Une fois l'authentification validée, l'agent génère le Cart Mandate avec le montant exact confirmé.
  5. Le Payment Mandate est transmis au prestataire de paiement compatible AP2 (émetteur de carte, PSP, portefeuille).
  6. Le prestataire exécute la transaction et retourne un statut. L'agent vocal confirme oralement le paiement et envoie un reçu par SMS ou email.
  7. Le CRM est mis à jour automatiquement, et les trois mandats sont archivés pour l'audit.

Le point critique de latence se situe à l'étape d'authentification forte : elle introduit une rupture de rythme dans la conversation. Les intégrations les plus abouties masquent ce temps d'attente par une phrase de transition et une notification push sur l'application bancaire de l'appelant plutôt qu'un SMS, plus rapide à confirmer.

Limites d'AP2 et prudence recommandée en 2026

AP2 reste un protocole jeune. Plusieurs limites doivent être prises en compte avant un déploiement en production téléphonique en France :

  • Adoption bancaire limitée - peu d'émetteurs et de PSP français supportent nativement AP2 en 2026. Les déploiements publics documentés concernent surtout des intégrations PayPal et Mastercard aux États-Unis.
  • Absence de jurisprudence - la valeur juridique d'un mandat AP2 en cas de litige n'est pas encore stabilisée en droit français ou européen.
  • Risque de sur-délégation - un Intent Mandate mal calibré (plafond trop large, périmètre imprécis) peut exposer l'utilisateur à des transactions non désirées bien que techniquement autorisées.
  • Dépendance à l'authentification forte - sans un facteur d'authentification robuste, un Payment Mandate signé sur la seule base d'un accord vocal reste un vecteur de fraude potentiel (deepfake vocal, usurpation).

La recommandation pour 2026 : traiter AP2 comme une brique d'avenir à préparer architecturalement (mandats, journalisation, intégration API), sans nécessairement l'activer en autorisation vocale de bout en bout tant que l'écosystème bancaire français n'est pas mature.

Quand adopter AP2 pour votre agent vocal IA ?

Critère Flux hybride (recommandé en 2026) Flux AP2 de bout en bout
Validation finale du paiement Lien sécurisé, SMS ou application Vocal, avec authentification forte intégrée
Maturité requise du prestataire de paiement Standard (PSP classique) Compatible AP2
Volume de transactions concerné Tous volumes Volumes pilotes, cas d'usage à faible risque
Niveau de risque acceptable Faible À évaluer au cas par cas

TALKR et le commerce agentique par téléphone

TALKR suit de près la maturation d'AP2 et des protocoles de paiement inter-agents. Nos équipes accompagnent les entreprises qui souhaitent préparer leurs agents vocaux à des scénarios de règlement, de recouvrement ou de commande avec encaissement, en respectant strictement les exigences DSP2, PCI-DSS et RGPD.

Si votre callbot doit à terme déclencher des paiements réels, nous pouvons concevoir dès aujourd'hui une architecture hybride évolutive, prête à intégrer AP2 quand l'écosystème bancaire français sera mature.

Parler à un expert TALKR

FAQ - AP2 et agents vocaux IA

Qu'est-ce que le protocole AP2 (Agent Payments Protocol) ?

AP2 est un protocole ouvert annoncé par Google en septembre 2025, qui définit comment un agent IA peut initier un paiement au nom d'un humain de façon vérifiable et auditable. Il repose sur des mandats cryptographiquement signés qui prouvent l'autorisation de l'utilisateur. AP2 a été lancé avec plus de 60 partenaires, dont Mastercard, PayPal, American Express, Coinbase et Salesforce.

Quelle différence entre AP2, A2A et MCP ?

MCP standardise la communication entre un agent et des outils ou données externes. A2A standardise la communication entre agents IA. AP2 standardise l'autorisation et l'exécution d'un paiement initié par un agent. Les trois protocoles sont complémentaires : un agent vocal peut utiliser MCP pour lire une facture, A2A pour déléguer la négociation, et AP2 pour exécuter le règlement.

Comment fonctionnent les mandats Intent, Cart et Payment dans AP2 ?

L'Intent Mandate décrit ce que l'utilisateur autorise l'agent à faire (par exemple, régler des factures jusqu'à un plafond donné). Le Cart Mandate fige les termes exacts d'une transaction précise. Le Payment Mandate est l'ordre final transmis au prestataire de paiement, avec preuve cryptographique du respect des mandats précédents. Cette chaîne crée un audit trail complet et vérifiable.

Un agent vocal IA peut-il faire payer un client par téléphone avec AP2 ?

Oui en théorie : l'agent négocie, obtient un consentement vocal, génère les mandats et transmet l'ordre de paiement. En pratique en 2026, cette chaîne nécessite une authentification forte du payeur (biométrie vocale enrôlée ou code SMS) avant la signature du mandat, car un accord oral seul n'est pas une preuve cryptographique suffisante.

AP2 est-il conforme au RGPD et à la DSP2/SCA en Europe ?

AP2 est un protocole technique, pas un cadre réglementaire. En Europe, tout paiement initié par un agent IA reste soumis à la DSP2 et à l'authentification forte du client (SCA) : le mandat documente et sécurise le consentement, il ne remplace pas cette obligation légale. Les mandats doivent être stockés avec minimisation des données et chiffrement, conformément au RGPD.

Quels sont les partenaires de lancement d'AP2 ?

AP2 a été annoncé par Google Cloud en septembre 2025 avec plus de 60 partenaires, parmi lesquels Mastercard, PayPal, American Express, Coinbase et Salesforce. En 2026, des pilotes publics existent autour de l'intégration PayPal avec l'agent de commerce conversationnel de Google Cloud et d'un programme Mastercard Agent Pay.

AP2 supporte-t-il les stablecoins et les cryptomonnaies ?

Oui. AP2 est agnostique au rail de paiement : cartes bancaires, virements en temps réel et stablecoins sont supportés, avec une extension A2A x402 dédiée aux paiements en cryptomonnaie entre agents. Pour un agent vocal grand public en France, le rail carte ou prélèvement reste le plus pertinent à court terme.

Quand adopter AP2 pour son agent vocal IA téléphonique ?

AP2 devient pertinent dès que votre agent vocal doit déclencher des paiements réels : recouvrement, renouvellement d'abonnement, commande avec encaissement. En 2026, l'adoption bancaire française étant naissante, il est recommandé de commencer par un flux hybride (mandats préparés par l'agent, validation finale sur un canal authentifié) avant de viser une autorisation vocale de bout en bout.

Pour aller plus loin