# Sécuriser les abilities d’un agent sur un front headless relié à Stripe

> Checklist de permissions pour un front découplé ouvrant des abilities WordPress 6.9 à un agent qui orchestre paiement Stripe et emailing transactionnel.

- Auteur : Clément Hadrot
- Publié le : 2026-06-05
- Mis à jour le : 2026-06-05
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/securiser-abilities-agent-front-headless-stripe/

## L’essentiel

- Chaque ability déclarée avec une portée d'action strictement définie
- Aucune ability de remboursement accessible sans confirmation humaine explicite
- Journalisation distincte des abilities financières par rapport aux abilities de contenu

Cinq abilities sur vingt-deux déclarées : c'est le périmètre exact accordé à un agent conversationnel chargé d'orchestrer les relances de panier abandonné et l'envoi d'emails de confirmation sur un site e-commerce headless, relié à Stripe pour l'encaissement. L'Abilities API, introduite avec WordPress 6.9 en décembre 2025, permet de déclarer précisément des capacités structurées qu'un agent peut découvrir et invoquer, ce qui change la façon d'aborder la sécurité par rapport à une simple attribution de rôle WordPress classique.

Cette checklist détaille comment restreindre ces abilities pour un agent qui touche, même indirectement, à un flux de paiement Stripe. Elle ne traite pas la configuration de Stripe ou du service d'emailing eux-mêmes, uniquement le périmètre d'action accordé à l'agent WordPress.

## 1. Séparer strictement les abilities de lecture et d'action

Sur les vingt-deux abilities déclarées dans le projet, la majorité concerne la lecture de données (état d'un panier, historique de commande, statut d'expédition). Seules cinq ont été jugées nécessaires à l'agent pour accomplir sa mission de relance et de confirmation, et aucune ne touche directement à l'encaissement ou au remboursement :

```
wp_register_ability( 'monsite/relancer-panier-abandonne', array(
    'label'               => __( 'Relancer un panier abandonné', 'monsite' ),
    'category'            => 'commerce',
    'input_schema'        => array( 'type' => 'object', 'properties' => array(
        'cart_id' => array( 'type' => 'integer' ),
    ) ),
    'permission_callback' => function () {
        return current_user_can( 'monsite_relancer_panier' );
    },
    'execute_callback'    => 'monsite_envoyer_relance_panier',
) );
```

## 2. Interdire formellement toute ability de remboursement automatisé

Aucune ability accordée à l'agent ne permet de déclencher un remboursement Stripe, même partiel. Cette limite n'est pas seulement une question de capacité WordPress : elle est renforcée côté Stripe lui-même, où la clé API utilisée par le serveur qui exécute les abilities de l'agent ne dispose que des droits de lecture sur les objets `PaymentIntent`, sans aucun droit d'écriture sur les remboursements.

> L'essentiel à retenir : Chaque ability déclarée avec une portée d'action strictement définie ; Aucune ability de remboursement accessible sans confirmation humaine explicite ; Journalisation distincte des abilities financières par rapport aux abilities de contenu

## 3. Exiger une confirmation humaine pour toute ability à impact financier

Même parmi les cinq abilities accordées, celle qui déclenche l'envoi d'un email de relance intégrant un lien de paiement direct impose une étape de confirmation humaine avant exécution effective, matérialisée par un statut intermédiaire `pending_review` que l'agent ne peut pas lever lui-même :

```
wp_register_ability( 'monsite/envoyer-lien-paiement-direct', array(
    'label'            => __( 'Envoyer un lien de paiement direct', 'monsite' ),
    'category'         => 'commerce',
    'execute_callback' => function ( $input ) {
        return array(
            'status'  => 'pending_review',
            'message' => 'En attente de validation par un opérateur humain.',
        );
    },
) );
```

## 4. Journaliser séparément les abilities financières

Les cinq abilities accordées à l'agent alimentent un journal d'audit distinct du journal général de l'application, avec une rétention plus longue et un accès restreint à l'équipe financière. Chaque invocation d'ability liée de près ou de loin à un flux de paiement génère une entrée horodatée, incluant l'identifiant de session de l'agent et le résultat exact renvoyé.

## 5. Retester le périmètre à chaque évolution du catalogue d'abilities

1. Lister l'intégralité des abilities déclarées sur le site avant chaque mise à jour majeure du projet.
2. Vérifier qu'aucune nouvelle ability à portée financière n'est accordée par défaut à l'agent existant.
3. Revalider explicitement, capability WordPress par capability WordPress, le périmètre accordé après toute montée de version du cœur ou d'une extension liée au paiement.
4. Documenter tout changement de périmètre dans le journal d'audit, avec la justification métier associée.

> Une capacité financière accordée par commodité aujourd'hui devient rarement une capacité retirée demain ; mieux vaut partir du périmètre le plus restreint possible et l'élargir explicitement, une ability à la fois, plutôt que l'inverse.

## En résumé

L'Abilities API rend la déclaration de capacités pour un agent bien plus lisible qu'un système de rôles WordPress classique, mais cette lisibilité ne dispense pas d'une discipline stricte : périmètre minimal, séparation claire entre lecture et action, confirmation humaine obligatoire sur tout ce qui touche au paiement, et journalisation dédiée. La configuration de Stripe et du service d'emailing eux-mêmes reste un chantier séparé, à traiter indépendamment de ce périmètre d'abilities WordPress.