vendredi 25 septembre 2026

À propos

Contact

IA & MCP

Journaliser les décisions d’un agent IA connecté à WordPress pour les auditer

Recette pour enregistrer systématiquement le prompt, la réponse et l'action réalisée par un agent, afin de reconstituer une décision contestée plus tard.

Par Clément Hadrot • 31 décembre 2025 • 4 min de lecture • Aucun commentaire
Journaliser les décisions d'un agent IA connecté à WordPress pour les auditer

Trois mois après la mise en production d’un agent capable de reclasser automatiquement des fiches produit dans les bonnes catégories, un client nous a contactés avec une question difficile : « pourquoi cette fiche a-t-elle été déplacée le 14 novembre ? ». Le journal technique existant indiquait bien qu’un appel d’outil avait eu lieu, mais aucune trace du raisonnement qui l’avait déclenché. Impossible de répondre autrement que « l’agent a dû juger que c’était pertinent ».

Cette recette ne traite pas la journalisation de sécurité générale (tentatives d’intrusion, erreurs serveur), déjà couverte ailleurs : elle porte spécifiquement sur la traçabilité des décisions d’un agent, pour pouvoir reconstituer, des mois plus tard, pourquoi une action précise a eu lieu.

Ce qu’un journal technique classique ne capture pas

Un journal d’appels d’API standard enregistre en général l’horodatage, le nom de l’outil appelé et ses paramètres. C’est utile pour du débogage technique, mais insuffisant pour répondre à une question d’audit : cela ne dit rien du contexte de la conversation qui a mené à cet appel précis, ni de la justification donnée par l’agent avant d’agir.

L'essentiel à retenir : On journalise le prompt, pas seulement l'appel d'outil ; Chaque entrée relie décision, action et résultat ; Le journal doit rester consultable des mois plus tard

La structure d’entrée retenue

Chaque décision d’agent ayant entraîné une action réelle sur le site génère une entrée de journal avec quatre champs obligatoires, stockés dans une table dédiée plutôt que dans les journaux serveur génériques :

CREATE TABLE wp_agent_audit_log (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    horodatage DATETIME NOT NULL,
    prompt_contexte TEXT NOT NULL,
    outil_appele VARCHAR(100) NOT NULL,
    parametres_json TEXT NOT NULL,
    resultat_json TEXT NOT NULL,
    utilisateur_source VARCHAR(100) NOT NULL
);

Le champ prompt_contexte est le plus important des quatre : il contient l’instruction ou la conversation ayant conduit à cette action précise, pas seulement l’appel technique qui en a résulté.

Où insérer la journalisation

Plutôt que de journaliser dans chaque fonction métier séparément, au risque d’en oublier une, nous journalisons à un point d’entrée unique : la couche qui reçoit les appels d’outils du serveur MCP, avant qu’ils ne soient distribués vers la fonction PHP correspondante.

function agence_journaliser_avant_execution( $nom_outil, $parametres, $contexte_prompt, $callback ) {
    $resultat = call_user_func( $callback, $parametres );

    global $wpdb;
    $wpdb->insert( 'wp_agent_audit_log', array(
        'horodatage'         => current_time( 'mysql' ),
        'prompt_contexte'    => $contexte_prompt,
        'outil_appele'       => $nom_outil,
        'parametres_json'    => wp_json_encode( $parametres ),
        'resultat_json'      => wp_json_encode( $resultat ),
        'utilisateur_source' => 'agent_reclassement_v2',
    ) );

    return $resultat;
}

Cette centralisation garantit qu’aucun nouvel outil ajouté par la suite n’échappe à la journalisation par simple oubli d’un développeur pressé.

Rendre le journal réellement consultable

Un journal stocké mais jamais consulté ne sert à rien lors d’un incident. Une page d’administration dédiée permet de filtrer par date, par outil, ou par identifiant de contenu affecté, avec un export possible en CSV pour une analyse plus poussée.

  • Recherche par identifiant de contenu affecté (l’article ou la fiche produit concernée).
  • Filtre par plage de dates, utile pour répondre à une question portant sur une période précise.
  • Affichage lisible du prompt d’origine, pas seulement du JSON brut des paramètres techniques.

Durée de conservation et RGPD

Le prompt journalisé peut contenir des informations liées à un utilisateur (par exemple, une conversation de support ayant déclenché une action). La durée de conservation du journal a donc été fixée à douze mois, avec purge automatique au-delà, en cohérence avec la politique de conservation des données déjà en place chez le client pour ses autres journaux applicatifs.

Un journal conservé indéfiniment n’est plus un outil d’audit, c’est un passif de conformité qui s’accumule sans qu’on s’en rende compte.

En résumé

Répondre à la question « pourquoi cette action a-t-elle eu lieu » demande de journaliser bien plus que l’appel technique : il faut conserver le contexte qui a motivé la décision de l’agent, à un point d’entrée unique du système pour ne rien oublier, et avec une durée de conservation cohérente avec vos obligations réglementaires plutôt qu’une accumulation sans limite.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi