# Une file d’audit dédiée aux appels effectués par un agent IA via les Abilities API

> Le journal d'activité natif de WordPress n'est pas conçu pour tracer des milliers d'appels d'agent par jour. Une file dédiée, asynchrone, tient mieux la charge.

- Auteur : Clément Hadrot
- Publié le : 2025-12-22
- Mis à jour le : 2025-12-22
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/file-audit-appels-agent-ia-abilities-api/

## L’essentiel

- Le journal d'activité natif sature vite sous le volume d'appels générés par un agent
- Une file d'écriture asynchrone évite de ralentir chaque appel d'ability
- La rétention et la purge doivent être décidées dès la conception, pas après coup

Plusieurs centaines d'appels d'ability par jour, générés par un agent IA qui interroge et modifie régulièrement un site WordPress : c'est un ordre de grandeur banal dès qu'un agent est intégré à un flux de travail réel plutôt qu'à un usage ponctuel. À ce volume, consigner chaque appel dans le journal d'activité natif de WordPress, pensé pour des événements humains occasionnels, pose vite un problème de volumétrie et de lisibilité.

Une architecture d'audit dédiée, séparée du journal d'activité classique, répond mieux à ce cas d'usage : elle isole les événements liés aux agents, supporte un volume plus élevé, et permet une politique de rétention distincte adaptée à ce contexte spécifique.

## Pourquoi séparer ce flux du journal d'activité natif

Le journal d'activité WordPress, qu'il repose sur une extension tierce ou sur les tables natives, reste conçu autour d'un modèle d'événements relativement rares : une connexion, une publication d'article, une modification de réglage. Un agent IA qui exécute des dizaines d'appels d'ability par minute, dans une session de travail intensive, produit un volume d'un ordre de grandeur différent. Mélanger ces deux flux rend le journal d'activité illisible pour un humain qui cherche à comprendre ce qui s'est passé sur le site, en plus de ralentir les requêtes d'affichage de ce journal.

## Le principe de la file asynchrone

Chaque appel d'ability déclenche l'écriture d'un enregistrement dans une file de traitement plutôt qu'une insertion directe et synchrone en base de données. La table dédiée est alimentée par un traitement en arrière-plan, ce qui évite d'ajouter de la latence perceptible à chaque appel d'agent tout en garantissant que l'écriture finit par se produire.

> L'essentiel à retenir : Le journal d'activité natif sature vite sous le volume d'appels générés par un agent ; Une file d'écriture asynchrone évite de ralentir chaque appel d'ability ; La rétention et la purge doivent être décidées dès la conception, pas après coup

```
function enregistrer_appel_ability(string $nom_ability, int $utilisateur_id, array $contexte): void
{
    $evenement = [
        'ability'      => $nom_ability,
        'utilisateur'  => $utilisateur_id,
        'contexte'     => wp_json_encode($contexte),
        'horodatage'   => time(),
    ];

    // Écriture rapide dans une file, traitement différé vers la table d'audit
    wp_schedule_single_event(time(), 'audit_agent_ia_traiter_evenement', [$evenement]);
}

add_action('audit_agent_ia_traiter_evenement', function (array $evenement): void {
    global $wpdb;
    $wpdb->insert($wpdb->prefix . 'audit_agent_ia', $evenement);
});
```

Cette structure découple l'exécution de l'ability de l'écriture du journal : un ralentissement ponctuel de la base de données n'empêche jamais l'ability elle-même de répondre à temps à l'agent.

## Structurer la table d'audit

Une table dédiée, distincte des tables natives de WordPress, permet d'indexer les colonnes réellement utiles à l'analyse : nom de l'ability, identifiant utilisateur associé au jeton, horodatage, et un contexte structuré (au format JSON) qui capture les paramètres de l'appel sans exposer de données sensibles en clair.

| Colonne | Rôle |
| --- | --- |
| ability | Nom de l'ability appelée, indexé pour les requêtes de filtrage |
| utilisateur_id | Identifiant du compte associé au jeton de l'agent |
| contexte | Paramètres de l'appel sérialisés, sans données de paiement ni mot de passe |
| horodatage | Date et heure précises, en UTC pour éviter les ambiguïtés de fuseau |
| resultat | Succès, refus ou erreur, avec un code court |

## Décider la rétention avant de la subir

Sans politique de purge définie dès la conception, cette table grossit indéfiniment jusqu'à devenir elle-même un problème de performance. Une tâche planifiée hebdomadaire, appuyée sur `wp_scheduled_delete` côté conception ou une tâche personnalisée équivalente, purge les enregistrements plus anciens qu'une durée fixée par avance (trente ou quatre-vingt-dix jours selon les obligations de conservation applicables au projet).

- Définir la durée de rétention avant la mise en production, jamais après avoir constaté la taille de la table
- Archiver plutôt que supprimer si une obligation légale impose une conservation plus longue
- Vérifier que la purge ne s'exécute jamais pendant une période de forte activité de l'agent

## Exposer une vue de consultation, pas la table brute

Un écran d'administration dédié, qui interroge la table d'audit avec des filtres simples (par ability, par utilisateur, par plage de dates), rend ce dispositif réellement exploitable au quotidien. Sans cette interface, la table existe mais reste invisible pour l'équipe qui devrait pourtant la consulter régulièrement.

> Une file d'audit que personne ne consulte n'apporte aucune sécurité supplémentaire : elle ne devient utile que le jour où elle est interrogée, idéalement avant l'incident plutôt qu'après.

## En résumé

Le journal d'activité natif de WordPress n'a pas été conçu pour absorber le volume et la fréquence des appels générés par un agent IA connecté en continu. Une file d'audit dédiée, alimentée de façon asynchrone dans une table structurée avec une politique de rétention explicite, offre une base bien plus solide pour comprendre, après coup, ce qu'un agent a réellement fait sur le site.