# Journaliser les accès à un catalogue B2B exposé par une ability à un agent IA

> Quand une ability WordPress donne accès à un catalogue sensible, la question n'est plus seulement qui a le droit d'y accéder, mais ce qu'un journal doit retenir de chaque consultation.

- Auteur : Clément Hadrot
- Publié le : 2026-04-10
- Mis à jour le : 2026-04-10
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/journaliser-acces-catalogue-b2b-ability-agent-ia/

## L’essentiel

- L'identité de l'agent et du compte de service doit apparaître sur chaque ligne
- Les paramètres de la requête méritent d'être conservés, pas seulement le résultat
- Une rétention limitée dans le temps évite d'accumuler des données inutiles

Que doit contenir une ligne de journal quand un agent IA consulte, via une ability, un catalogue de pièces destiné normalement à des visiteurs humains ? La question se pose concrètement depuis que l'Abilities API rend possible l'exposition contrôlée de fonctionnalités WordPress à des agents automatisés. Un journal insuffisant ne permet de reconstituer ni l'ampleur d'un incident, ni son origine ; un journal trop verbeux devient illisible et peut lui-même exposer des données sensibles. Ce billet ne traite pas de la conception des abilities elle-même, mais du contenu que leur journal d'activité doit conserver.

## Pourquoi le journal d'un agent diffère de celui d'un humain

Un visiteur humain formule ses requêtes à un rythme naturel, avec des variations dans son comportement de navigation. Un agent IA, lui, peut enchaîner des dizaines de requêtes en quelques secondes, reformuler une même question sous plusieurs angles, ou combiner plusieurs abilities dans une même session de raisonnement. Le journal doit donc permettre de distinguer un usage légitime intensif d'un comportement réellement anormal, ce qui suppose de conserver davantage de contexte qu'un simple journal d'accès web classique.

## Les cinq champs minimaux

> L'essentiel à retenir : L'identité de l'agent et du compte de service doit apparaître sur chaque ligne ; Les paramètres de la requête méritent d'être conservés, pas seulement le résultat ; Une rétention limitée dans le temps évite d'accumuler des données inutiles

1. **Identité du compte de service** qui a exécuté l'ability, jamais un identifiant générique partagé entre plusieurs intégrations.
2. **Nom de l'ability invoquée**, par exemple `domaine/consulter-piece`, pour distinguer les usages entre plusieurs abilities exposées côté catalogue.
3. **Paramètres reçus**, filtrés pour ne pas conserver de données personnelles superflues, mais suffisamment détaillés pour rejouer le scénario en cas d'enquête.
4. **Horodatage précis**, à la seconde près, pour reconstituer la chronologie d'une séquence de requêtes rapprochées.
5. **Résultat de l'appel** — succès, refus de capacité, erreur de validation — pour repérer les tentatives répétées d'accès refusé.

## Une implémentation concrète

```
add_action('wp_ability_before_execute', function ($nom_ability, $parametres) {
  if (strpos($nom_ability, 'domaine/') !== 0) {
    return;
  }
  $utilisateur = wp_get_current_user();
  domaine_journal_ability_inserer(array(
    'ability'    => $nom_ability,
    'compte'     => $utilisateur->user_login,
    'parametres' => wp_json_encode(domaine_filtrer_parametres_sensibles($parametres)),
    'horodatage' => current_time('mysql'),
  ));
}, 10, 2);
```

La fonction `domaine_filtrer_parametres_sensibles()` retire systématiquement les champs identifiés comme sensibles avant l'écriture en base, plutôt que de journaliser aveuglément l'intégralité des paramètres reçus.

## Ne pas confondre journal et boîte noire illisible

Un journal qui accumule des milliers d'entrées sans interface d'exploration ne sert à rien au moment où il faut réellement l'utiliser, souvent dans l'urgence d'un incident suspecté. Un tableau de synthèse quotidien, listant le volume de requêtes par compte de service et par ability, permet de repérer en un coup d'œil un écart significatif par rapport à l'usage habituel, sans avoir à parcourir manuellement chaque ligne brute.

## Fixer une durée de rétention raisonnable

Conserver indéfiniment ce journal pose une question de proportionnalité et de gestion des données personnelles qu'il pourrait malgré tout contenir indirectement, via les paramètres de recherche par exemple. Une durée de rétention de quatre-vingt-dix jours, avec purge automatisée via une tâche planifiée, offre un compromis raisonnable entre capacité d'investigation a posteriori et minimisation des données conservées.

```
if (!wp_next_scheduled('domaine_purger_journal_ability')) {
  wp_schedule_event(time(), 'daily', 'domaine_purger_journal_ability');
}
```

## En résumé

Un journal d'accès pensé pour un agent IA ne se contente pas de savoir « qui a fait quoi » : il doit permettre de reconstituer une séquence de raisonnement automatisé, souvent bien plus dense qu'un parcours humain. Cinq champs bien choisis, une synthèse quotidienne lisible et une purge planifiée forment un socle exploitable sans devenir un fardeau de conservation.