Un agent IA peut aujourd’hui rechercher un fournisseur, comparer des offres, remplir un formulaire de commande et arriver jusqu’à la page de paiement. Il ne lui manque souvent qu’une chose pour terminer la tâche : un moyen de payer. Lui confier la carte de l’entreprise serait imprudent. Lui refuser tout paiement oblige un humain à reprendre la main à chaque achat, ce qui annule une bonne partie de l’intérêt de l’automatisation.

Les cartes virtuelles dédiées aux agents offrent une voie médiane : l’agent paie seul, mais dans un cadre que vous fixez à l’avance. Ce guide explique comment construire ce cadre.

Les risques propres aux agents

Un agent n’est ni un salarié ni un simple script. Il prend des décisions à partir d’instructions et de ce qu’il lit en ligne, ce qui crée des risques particuliers :

• La boucle. Un agent qui croit avoir échoué peut répéter la même action, et donc le même achat.
• La manipulation. Une page web peut contenir des instructions cachées destinées à détourner l’agent, par exemple pour le pousser à acheter autre chose ou plus cher.
• L’erreur d’interprétation. Une consigne ambiguë peut mener à un montant ou à un commerçant inattendu.
• L’exposition. Si les données d’une carte fuient, tout ce qui est accessible avec cette carte est exposé.

Aucune consigne écrite dans le prompt ne protège complètement contre ces risques. La protection doit venir de la carte elle-même : ce qu’elle peut dépenser, combien de fois, et combien de temps elle existe.

Le principe : la carte est la limite

La règle la plus sûre tient en une phrase : une carte d’agent ne contient jamais plus que ce que vous acceptez de perdre. Quoi que l’on dise à l’agent, il ne peut pas dépenser au-delà du solde de sa carte ni au-delà du plafond que vous avez fixé. Le pire scénario est donc connu à l’avance, et il est petit.

Chez Monerails, les cartes d’agent sont des cartes virtuelles Visa ou Mastercard en dollars, alimentées depuis un solde cartes distinct de vos encaissements. Une dépense par carte ne touche jamais l’argent que vous recevez de vos clients.

Choisir le bon type de carte

La carte à usage unique est le choix par défaut pour un agent qui achète : elle ne peut être débitée qu’une fois, ne peut être ni rechargée ni vidée, et se ferme automatiquement 30 jours après son émission si vous ne l’avez pas résiliée avant. Son reste revient alors sur votre solde cartes.

Émettre une carte d’agent par API

Une carte d’agent n’a pas de titulaire humain : elle porte le nom de l’agent. Voici la création d’une carte avec un plafond journalier de 50 $ et une recharge initiale de 60 $ (les montants sont en cents).

curl https://api.monerails.com/v1/cards \
  -H "Authorization: Bearer $MONERAIL_KEY" \
  -H "Idempotency-Key: card-agent-recherche-1" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "agent",
    "agent_name": "recherche",
    "label": "Crédits d’API",
    "amount": 6000,
    "spending_limit": { "amount": 5000, "interval": "daily" }
  }'

Pour un achat ponctuel, remplacez le plafond par "single_use": true et chargez la carte du montant exact. Les deux ne se combinent pas : sur une carte à usage unique, c’est le montant chargé qui fait office de plafond. La toute première carte d’agent de votre entreprise est émise par un membre Propriétaire depuis le tableau de bord ; les suivantes peuvent l’être par API.

Garder la main en temps réel

Donner une carte ne veut pas dire perdre de vue ce qu’elle fait. Quatre mécanismes vous gardent informé et vous permettent d’agir :

1. Les webhooks. Chaque paiement déclenche card.transaction, chaque refus card.authorization_declined. Branchez-les sur une alerte : un refus répété est souvent le premier signe d’un agent qui tourne en boucle.
2. Le gel instantané. POST /v1/cards/{id}/freeze bloque tout paiement en un appel ; unfreeze le rétablit.
3. La résiliation. POST /v1/cards/{id}/terminate ferme la carte définitivement et renvoie son solde sur votre solde cartes.
4. L’idempotence. Chaque création de carte ou recharge porte une Idempotency-Key : si l’agent ou votre orchestrateur relance la même demande, elle n’est exécutée qu’une fois.

Une architecture simple et sûre

Pour la plupart des équipes, le schéma suivant suffit :

1. L’agent formule une demande : montant, commerçant, motif.
2. Votre service applique vos règles : montant maximal par tâche, liste de commerçants autorisés, validation humaine au-delà d’un seuil.
3. Si la demande passe, votre service émet une carte à usage unique du montant validé et la met à la disposition de l’agent pour cette tâche.
4. L’agent paie. Le webhook card.transaction confirme la dépense, que vous rattachez à la tâche.
5. Votre service résilie la carte, ou la laisse se fermer d’elle-même.

La clé d’API de ce service ne doit avoir que les droits nécessaires, et rester hors de portée de l’agent : l’agent ne parle jamais directement à l’API de paiement.

Garder une trace de chaque décision

Quand un humain dépense, on peut lui demander pourquoi. Avec un agent, il faut l’avoir prévu. Pour chaque carte émise, conservez dans votre service : la tâche concernée, la demande de l’agent (montant, commerçant, motif), la règle qui l’a acceptée et, le cas échéant, la personne qui l’a validée. Rattachez ensuite le webhook card.transaction à cette entrée grâce à l’identifiant de la carte.

Ce journal sert trois fois : pour comprendre un incident, pour ajuster vos règles (un plafond trop bas qui bloque des tâches légitimes, un commerçant à ajouter à la liste), et pour la comptabilité, qui retrouve chaque dépense avec sa justification.

Questions fréquentes

Un agent peut-il dépasser son plafond ?

Non. Au-delà du plafond ou du solde de la carte, le paiement est refusé et vous recevez card.authorization_declined.

Que se passe-t-il si l’agent est manipulé ?

Il peut tenter un achat non souhaité, mais il reste borné par sa carte. C’est pour cela que la limite doit être sur la carte, et non dans les instructions de l’agent.

Faut-il une carte par agent ou par tâche ?

Par tâche pour les achats ponctuels, par agent pour les dépenses récurrentes et budgétées. Beaucoup d’équipes combinent les deux.

Combien cela coûte

Une carte virtuelle Monerails coûte 1 $ à l’émission, sans abonnement mensuel au compte. Alimenter une carte depuis le solde cartes est gratuit ; récupérer le solde d’une carte vers le solde cartes coûte 1,5 %. Pour un agent qui fait des achats ponctuels, les cartes à usage unique chargées au montant exact évitent ces retraits. Le détail est sur la page Tarifs.

Tester avant de faire confiance

En mode test, les cartes sont émises dans un environnement de test et les paiements de commerçants se simulent par API, acceptés ou refusés. Profitez-en pour vérifier les situations difficiles avant la production : un agent qui relance la même demande, un montant au-delà du plafond, un gel en plein milieu d’une tâche. Si votre système se comporte bien dans ces cas, il se comportera bien en production.

Pour l’intégration, la documentation des cartes et le fichier llms.txt sont conçus pour être lus aussi bien par vos développeurs que par vos agents. Pour les usages humains des mêmes cartes, voyez notre article sur la carte virtuelle USD pour entreprise, et pour l’offre complète, la page Cartes.