Commerce Agentique : Comment laisser les agents IA acheter en toute securite

Pourquoi c'est important maintenant

Les agents IA deviennent bons en conversation, en recommandation et en recherche. L'etape suivante est evidente : leur permettre de completer des transactions. Un agent capable de verifier la disponibilite, comparer les options et reserver des billets est plus utile qu'un agent qui te donne les options et te laisse cliquer dans un formulaire de paiement.

Mais au moment ou un agent peut depenser de l'argent, tout change. Un agent de support client qui reserve le mauvais spectacle. Un agent de voyage qui reserve 50 places au lieu de 5. Un assistant shopping qui passe une commande pour un produit que le fournisseur ne propose plus. Ce ne sont pas des scenarios hypothetiques. Ce sont les resultats previsibles quand on connecte un LLM a une API de checkout sans gouvernance.

On a construit un protocole pour ca. On l'appelle l'Agentic Checkout Protocol (ACP). Il gouverne la facon dont les agents IA initient, valident et completent des transactions commerciales au sein d'une plateforme multi-tenant. Cet article explique l'architecture depuis la base.

Pour le contexte sur notre approche des systemes IA agentiques et de l'architecture multi-agent, ces guides couvrent les patterns plus larges. Cet article se concentre specifiquement sur le probleme des transactions commerciales.

Le probleme fondamental

Les flux de checkout traditionnels supposent qu'un humain prend la decision. Le backend du marchand appelle l'API de checkout avec une cle API, la commande est validee, le paiement est capture. L'humain est responsable.

Avec le commerce agentique, l'appelant est un agent IA. L'agent opere dans un fil de conversation, a acces a des outils et peut agir de maniere autonome. Ca introduit des risques que le checkout traditionnel ne gere pas :

La solution n'est pas "ne pas laisser les agents acheter." La solution est un protocole qui gouverne chaque etape.

Le protocole Agentic Checkout

L'ACP compose cinq systemes en un framework de confiance unique :

┌─────────────────────────────────────────────────────────┐
│                   FLUX ACP                               │
│                                                          │
│  Utilisateur : "Reserve Le Roi Lion pour 2 adultes      │
│                  samedi"                                 │
│                         │                                │
│                         ▼                                │
│  ┌─────────────────────────────────┐                    │
│  │  1. COUCHE OUTILS MCP           │                    │
│  │  L'agent appelle               │                    │
│  │  createCheckout() via Model    │                    │
│  │  Context Protocol              │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  2. MOTEUR DE POLITIQUES        │                    │
│  │  Verifier : cet agent a-t-il   │                    │
│  │  le droit de reserver chez ce  │                    │
│  │  fournisseur ? La valeur est-  │                    │
│  │  elle dans les limites ?       │                    │
│  │  Resultat : AUTORISER ou       │                    │
│  │  REFUSER                       │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│          AUTORISER         REFUSER ──▶ Erreur a l'agent │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  3. PORTE D'APPROBATION HITL   │                    │
│  │  Si valeur commande > seuil :  │                    │
│  │  Suspendre le workflow,        │                    │
│  │  notifier les ops              │                    │
│  │  Attendre l'approbation        │                    │
│  │  humaine                       │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│              APPROUVE                                    │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  4. EXECUTION FOURNISSEUR       │                    │
│  │  Reserver l'inventaire         │                    │
│  │  Confirmer la reservation via  │                    │
│  │  le fournisseur                │                    │
│  │  Generer un recu HMAC          │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  5. JOURNAL D'AUDIT             │                    │
│  │  Ecrire un enregistrement      │                    │
│  │  immuable                      │                    │
│  │  actor_type: "agent"           │                    │
│  │  thread_id, tenant_id, receipt │                    │
│  └─────────────────────────────────┘                    │
│                                                          │
└─────────────────────────────────────────────────────────┘

Chaque composant a de la valeur en soi. Ensemble, ils forment un framework de gouvernance complet pour le commerce initie par l'IA.

Composant 1 : Couche outils MCP

L'agent n'appelle pas les APIs directement. Il utilise des outils MCP (Model Context Protocol) enregistres dans le framework agent. Chaque outil est un point d'entree controle avec validation des entrees, application des politiques et journalisation d'audit.

// Definition de l'outil MCP pour creer un checkout
const createCheckoutTool = createTool({
    id: 'createCheckout',
    description: 'Create a checkout for a product booking',
    inputSchema: z.object({
        productId: z.string(),
        date: z.string().datetime(),
        persons: z.array(z.object({
            type: z.enum(['adult', 'child', 'senior']),
            count: z.number().int().positive(),
        })),
    }),
    execute: async ({ productId, date, persons }, ctx) => {
        // 1. Valider que le produit existe dans l'index de recherche
        const product = await searchApi.getProduct(ctx.tenantId, productId);
        if (!product) throw new ToolError('Product not found');

        // 2. Verifier la politique
        const policy = await policyEngine.evaluate(
            ctx.tenantId, ctx.channelId, 'create_order',
            { productId, supplierId: product.supplierId, estimatedValue: product.price }
        );
        if (!policy.allowed) throw new ToolError(`Policy denied: ${policy.reason}`);

        // 3. Demarrer le workflow de checkout
        return checkoutWorkflow.start({ productId, date, persons, ctx });
    },
});

L'outil valide que le produit existe reellement (previent les reservations hallucinees), verifie la politique avant toute action financiere et redirige vers un workflow gouverne. L'agent n'a jamais d'acces direct a l'API du fournisseur.

Ce pattern vient de la facon dont on concoit les systemes de workflow IA. L'outil est la frontiere de confiance. Tout ce qui est a l'interieur de l'outil est gouverne. Tout ce qui est a l'exterieur n'est que de la conversation.

Composant 2 : Moteur de politiques

Avant toute action financiere, le moteur de politiques evalue des regles specifiques au tenant. Les regles sont stockees par tenant et mises en cache avec un TTL de 5 minutes.

interface PolicyRule {
    action: string;                    // "create_order", "cancel_order", "search"
    effect: "allow" | "deny";
    conditions: {
        max_order_value?: number;          // Plafond strict, rejeter au-dessus
        allowed_suppliers?: string[];      // Restreindre les fournisseurs
        require_human_approval_above?: number;  // Seuil HITL
        max_items_per_order?: number;      // Prevenir la fraude en masse
    };
}

Regles d'evaluation

1. Les regles de refus ont la priorite. Si une regle de refus correspond, l'action est rejetee immediatement.
2. Les regles d'autorisation avec conditions. Si une regle d'autorisation correspond, ses conditions sont evaluees par rapport a la requete.
3. Pas de regle correspondante = refuse. Default-deny. Un agent ne peut rien faire qui ne soit pas explicitement autorise.

Exemple de politique

{
    "tenant_id": "tenant_acme",
    "rules": [
        {
            "action": "create_order",
            "effect": "allow",
            "conditions": {
                "max_order_value": 5000,
                "allowed_suppliers": ["supplier_alpha", "supplier_beta"],
                "require_human_approval_above": 500,
                "max_items_per_order": 10
            }
        },
        {
            "action": "cancel_order",
            "effect": "allow",
            "conditions": {}
        },
        {
            "action": "search",
            "effect": "allow",
            "conditions": {}
        }
    ]
}

Les agents de ce tenant peuvent chercher librement, creer des commandes jusqu'a 5 000 EUR (mais les commandes au-dessus de 500 EUR necessitent une approbation humaine), reserver uniquement chez deux fournisseurs approuves et creer des commandes avec au maximum 10 articles. Ils peuvent annuler des commandes sans restriction. Tout le reste est refuse.

Le moteur de politiques est scope au tenant. Differents marchands ont differentes regles. Une grande entreprise pourrait fixer le seuil HITL a 2 000 EUR. Un petit operateur pourrait exiger une approbation pour tout ce qui depasse 100 EUR. L'operateur de la plateforme definit les politiques par defaut, et les tenants peuvent personnaliser dans la plage autorisee.

Composant 3 : Portes d'approbation HITL

Quand une commande depasse le seuil require_human_approval_above, le workflow de checkout se suspend et attend l'approbation humaine.

// A l'interieur du workflow de checkout
async function checkoutWorkflow(ctx, params) {
    // Etape 1 : Reserver l'inventaire
    const reservation = await supplierAdapter.reserveInventory(
        ctx.tenantId, params.productId, params.date, params.persons
    );

    // Etape 2 : Verifier si une approbation humaine est necessaire
    if (reservation.totalPrice > policy.require_human_approval_above) {
        // Suspendre le workflow, notifier le dashboard ops
        const approval = await workflow.suspend({
            reason: 'Order exceeds approval threshold',
            totalPrice: reservation.totalPrice,
            threshold: policy.require_human_approval_above,
            productName: reservation.productName,
            reservationExpiresAt: reservation.expiresAt,
        });

        if (!approval.approved) {
            await supplierAdapter.cancelReservation(reservation.id);
            return { status: 'REJECTED', reason: approval.rejectionReason };
        }
    }

    // Etape 3 : Confirmer la reservation
    const booking = await supplierAdapter.confirmBooking(reservation);

    // Etape 4 : Generer le recu
    const receipt = generateHmacReceipt(booking, ctx.tenantId);

    // Etape 5 : Journal d'audit
    await auditLog.write({
        action: 'order_completed',
        actor_type: 'agent',
        thread_id: ctx.threadId,
        tenant_id: ctx.tenantId,
        order_id: booking.orderId,
        receipt_hmac: receipt.hmac,
    });

    return { status: 'COMPLETED', orderId: booking.orderId, receiptHmac: receipt.hmac };
}

Le workflow utilise suspend() et resume() du framework agent. Quand il est suspendu, le dashboard ops affiche la commande en attente avec tous les details. Un operateur peut approuver ou rejeter avec un motif. Le workflow reprend automatiquement quand la decision est prise.

La reservation a un temps d'expiration. Si l'humain n'approuve pas avant l'expiration de la reservation, le systeme annule automatiquement la reservation et informe l'agent. L'agent peut alors dire a l'utilisateur que la fenetre de reservation est fermee.

Pour aller plus loin sur la supervision humaine dans les systemes IA, consulte notre guide sur l'IA human-in-the-loop.

Composant 4 : Recus HMAC

Chaque commande completee genere un recu infalsifiable en utilisant HMAC-SHA256. Ca fournit une preuve cryptographique de ce qui s'est passe.

Specification du recu

Payload du recu

interface ReceiptPayload {
    order_id: string;
    tenant_id: string;
    products: Array<{
        id: string;
        date: string;
        total_price: number;
    }>;
    total_price: number;
    currency: string;
    booker_email: string;
    created_at: string;  // ISO 8601
}

Signature

function generateHmacReceipt(order: Order, tenantId: string): Receipt {
    const payload: ReceiptPayload = {
        order_id: order.id,
        tenant_id: tenantId,
        products: order.items.map(item => ({
            id: item.productId,
            date: item.date,
            total_price: item.totalPrice,
        })),
        total_price: order.totalPrice,
        currency: order.currency,
        booker_email: order.bookerEmail,
        created_at: order.createdAt.toISOString(),
    };

    // JSON canonique : cles triees pour un resultat deterministe
    const canonical = JSON.stringify(payload, Object.keys(payload).sort());
    const secret = await secretsManager.getTenantSecret(tenantId);
    const hmac = crypto.createHmac('sha256', secret).update(canonical).digest('hex');

    return { payload, hmac, signedAt: new Date().toISOString() };
}

Verification

GET /v1/order/{orderId}/verify
Response: { valid: true, signed_at: "2026-06-15T14:30:00Z" }

L'endpoint de verification recalcule le HMAC a partir des donnees de commande stockees en utilisant le secret du tenant et le compare au recu stocke. Une divergence signifie que les donnees de commande ont ete modifiees apres la signature. Ca donne aux marchands, aux auditeurs et aux regulateurs une preuve verifiable qu'un agent specifique, agissant dans le scope d'un tenant specifique, a cree une commande specifique a un moment precis.

Composant 5 : Piste d'audit immuable

Chaque action ACP genere une entree d'audit. Le systeme d'audit utilise une architecture a deux niveaux :

Niveau 1 : Journal operationnel (base de donnees, requetable, retention 90 jours)

{
    action: 'order_completed',
    actor_type: 'agent',           // "agent" | "human" | "system"
    thread_id: 'thread_abc123',    // quelle conversation
    tenant_id: 'tenant_acme',
    channel_id: 'ch_web_en',
    order_id: 'ord_xyz789',
    total_price: 450,
    currency: 'EUR',
    supplier_id: 'supplier_alpha',
    receipt_hmac: 'a1b2c3...',
    policy_evaluated: true,
    hitl_required: false,
    created_at: '2026-06-15T14:30:00Z',
}

Niveau 2 : Archive immuable (stockage objet avec ecriture unique/lecture multiple, retention 7 ans)

Le journal operationnel streame vers le stockage objet avec des verrous d'objet (mode compliance). Une fois ecrites, les entrees ne peuvent pas etre modifiees ou supprimees pendant la periode de retention. Ca satisfait les exigences reglementaires pour les enregistrements de transactions financieres.

Chaque entree d'audit inclut actor_type et thread_id. Ca permet de tracer exactement quel agent IA, dans quelle conversation, a initie quelle action financiere. Combine avec le recu HMAC, la piste d'audit fournit une preuve de bout en bout de la chaine de decision.

Pour voir comment on construit les systemes d'audit et d'observabilite plus largement, consulte nos guides sur la gouvernance IA et l'observabilite IA.

ACP vs checkout traditionnel

Idempotence

Les transactions initiees par un agent necessitent l'idempotence au niveau du protocole. Les retries reseau, les re-tentatives de l'agent et les replays de workflow ne doivent pas creer de commandes en double.

// Cle d'idempotence pour les checkouts inities par un agent
const idempotencyKey = `${tenantId}:${threadId}:${productId}:${date}`;

// Verifier avant de traiter
const existing = await idempotencyStore.get(idempotencyKey);
if (existing) {
    return existing.result;  // Retourner le resultat en cache
}

// Traiter et stocker
await idempotencyStore.acquire(idempotencyKey);
const result = await processCheckout(params);
await idempotencyStore.complete(idempotencyKey, result);
return result;

La cle d'idempotence combine le tenant, le fil de conversation, le produit et la date. Le meme agent dans la meme conversation qui reserve le meme produit a la meme date obtient toujours le meme resultat. Un fil de conversation different obtient une cle neuve.

Le store utilise des ecritures conditionnelles pour prevenir les conditions de concurrence. Si deux workers essaient d'acquerir la meme cle simultanement, un seul reussit.

Isolation multi-tenant

Chaque operation ACP est scopee a un tenant et un canal. La hierarchie d'identite assure l'isolation des donnees a chaque couche :

Tenant (organisation marchand)
  └── Canal (vitrine ou canal de vente)
       └── Client (utilisateur final)
            └── Session (session navigateur/appareil)
                 └── Thread agent (conversation unique)

Le thread agent herite de son contexte tenant et canal a partir de la session authentifiee. Chaque appel d'outil, chaque evaluation de politique, chaque entree d'audit porte ces identifiants. L'acces aux donnees inter-tenant est architecturalement impossible parce que chaque requete inclut le scope tenant comme filtre obligatoire.

C'est le meme pattern d'isolation multi-tenant qu'on decrit dans notre guide d'architecture systeme. La difference avec l'ACP est que l'agent ajoute un niveau de scoping supplementaire : le thread. La memoire et le contexte d'un agent sont scopes a tenant_id + session_id + thread_id. L'agent A d'un tenant ne peut pas voir la conversation de l'agent B d'un autre tenant.

Ce qui peut mal tourner

Meme avec l'ACP, il y a des modes de defaillance a gerer :

Considerations d'implementation

Quand introduire l'ACP

Chaque integration de commerce IA n'a pas besoin du protocole complet. Considere le niveau d'autonomie :

Commence par la recherche seule. Ajoute la construction de panier quand la confiance est etablie. Passe au checkout assiste avec HITL sur chaque commande. Evolue vers le checkout autonome avec des seuils HITL bases sur les politiques uniquement apres avoir des donnees sur la precision de l'agent et un taux d'erreur acceptable.

Choix technologiques

L'ACP est au niveau du protocole, pas specifique a une implementation. Les composants peuvent etre construits avec differentes technologies :

Le design du protocole compte plus que les outils specifiques. Si tu implementes les cinq composants (gouvernance des outils, evaluation des politiques, portes d'approbation humaine, recus infalsifiables et audit immuable), le systeme est sur quelle que soit la technologie sous-jacente.

Pour notre perspective plus large sur l'architecture des systemes IA et comment on approche nos missions de consulting, ces pages donnent plus de contexte.

Pieges courants

1. Laisser les agents appeler les APIs fournisseurs directement. La couche outils MCP est la frontiere de confiance. Sans elle, tu n'as pas d'application des politiques, pas de piste d'audit et pas d'idempotence.

2. Politique default-allow. L'ACP utilise le default-deny. Si aucune regle d'autorisation explicite n'existe pour une action, elle est rejetee. Le default-allow avec des surcharges de refus est plus faible parce que tu dois anticiper chaque mauvaise action a l'avance.

3. Ne pas utiliser les recus HMAC. Sans recus infalsifiables, tu ne peux pas prouver a un marchand ou a un regulateur qu'une commande n'a pas ete modifiee apres coup.

4. Meme format de cle d'idempotence pour toutes les operations. La cle doit inclure le contexte (thread, produit, date). Une cle globale comme order:123 n'empeche pas un autre agent dans une autre conversation de reserver le meme produit.

5. Pas d'expiration de reservation. Si l'approbation HITL prend une eternite, la reservation bloque l'inventaire indefiniment. Definis toujours une expiration et gere le cas de timeout.

6. Faire confiance aux donnees produit fournies par l'agent. L'outil doit valider que le produit existe dans l'index de recherche. L'agent pourrait halluciner un ID produit, un prix ou une date de disponibilite.

7. Ne pas scoper la memoire de l'agent par tenant. Un agent servant le tenant A ne doit pas avoir acces a l'historique de conversation, au catalogue produit ou aux regles de politique du tenant B.

8. Traiter le checkout agentique comme une fonctionnalite, pas comme un protocole. L'ACP n'est pas une fonctionnalite qu'on greffe apres coup. C'est un framework de confiance qui doit etre concu dans le systeme des le depart.

Points cles a retenir

• Les agents ne peuvent pas "juste reserver des trucs." Chaque transaction financiere initiee par un agent necessite une evaluation de politique, une approbation humaine optionnelle, des recus infalsifiables et une piste d'audit immuable. Ce n'est pas optionnel pour le commerce en production.

• L'outil MCP est la frontiere de confiance. L'agent n'a jamais d'acces API direct. Chaque action passe par un outil gouverne qui valide, verifie la politique et enregistre.

• La politique default-deny est non-negociable. Si aucune regle d'autorisation explicite n'existe, l'action est rejetee. Les regles de refus priment toujours sur les regles d'autorisation.

• Les portes HITL sont configurables, pas binaires. Les petites commandes passent automatiquement. Les grosses attendent l'approbation humaine. Le seuil est par tenant, par action.

• Les recus HMAC prouvent ce qui s'est passe. Cles de signature par tenant, serialisation JSON canonique, HMAC-SHA256 encode en hexadecimal. Verifiable par toute partie ayant le secret.

• L'idempotence empeche les commandes en double. La cle doit inclure le contexte de conversation (thread ID), pas seulement les donnees de commande.

• Commence par la recherche, evolue vers le checkout. Ne donne pas aux agents le pouvoir d'achat autonome des le premier jour. Construis la confiance incrementalement avec des donnees sur la precision et les taux d'erreur.

Le commerce agentique est inevitable. La question est de savoir si tu construis la gouvernance d'abord ou si tu repares les degats apres. On a construit l'ACP parce qu'on en avait besoin pour une vraie plateforme de commerce multi-tenant avec plusieurs fournisseurs et des agents de reservation IA. Le protocole fonctionne. L'architecture est prouvee en production.

Si tu construis du commerce alimente par l'IA et que tu as besoin d'aide pour concevoir la couche de gouvernance, parle a notre equipe ou demande un devis. Tu peux aussi explorer nos services IA et notre pratique d'architecture e-commerce pour plus de contexte.