Un agent qui reclasse automatiquement des demandes de contact entrantes prend, chaque jour, des dizaines de petites décisions : quelle catégorie attribuer, quelle priorité, quel service notifier. Consulter le fichier debug.log pour comprendre pourquoi une demande précise a été classée d’une certaine façon un mardi soir devient vite impraticable, noyé parmi d’autres messages sans structure commune.
Une table dédiée, pensée dès le départ pour l’analyse plutôt que pour le simple diagnostic technique, change radicalement la facilité avec laquelle une décision peut être retrouvée et comprise plus tard.
Ce qu’un fichier de log ne permet pas de faire
Un appel à error_log() écrit une ligne de texte dans un fichier, sans structure interrogeable. Retrouver toutes les décisions prises pour une catégorie donnée, ou compter combien de demandes ont été classées avec un faible niveau de confiance sur une semaine, suppose alors d’analyser ce fichier texte avec des outils externes, une opération lourde pour un besoin qui devrait rester simple.
Concevoir une table de décisions
function creer_table_decisions_agent() {
global $wpdb;
$table = $wpdb->prefix . 'decisions_agent_contact';
$charset = $wpdb->get_charset_collate();
$sql = "CREATE TABLE $table (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
demande_id BIGINT UNSIGNED NOT NULL,
categorie_choisie VARCHAR(50) NOT NULL,
niveau_confiance DECIMAL(3,2) NOT NULL,
justification TEXT NOT NULL,
date_decision DATETIME NOT NULL
) $charset;";
require_once ABSPATH . 'wp-admin/includes/upgrade.php';
dbDelta( $sql );
}
Enregistrer la justification, pas seulement le résultat
Le champ le plus utile de cette table n’est pas categorie_choisie, mais justification : une phrase brève, générée par le modèle lui-même, expliquant pourquoi cette catégorie a été retenue plutôt qu’une autre. C’est ce champ qui permet, plus tard, de comprendre un classement surprenant sans avoir à rejouer la demande d’origine.
function enregistrer_decision( int $demande_id, array $resultat ): void {
global $wpdb;
$wpdb->insert( $wpdb->prefix . 'decisions_agent_contact', array(
'demande_id' => $demande_id,
'categorie_choisie' => $resultat['categorie'],
'niveau_confiance' => $resultat['confiance'],
'justification' => $resultat['justification'],
'date_decision' => current_time( 'mysql' ),
) );
}
Demander explicitement une justification au modèle
Cette exigence de justification doit figurer dans la consigne envoyée au modèle, sous forme de sortie structurée, plutôt qu’espérer l’obtenir spontanément d’un texte libre difficile à parser ensuite de façon fiable.
Consigne : « Réponds uniquement au format JSON suivant :
{"categorie": "...", "confiance": 0.0, "justification": "une phrase courte"} »
Exploiter la table pour repérer les cas fragiles
Une fois la table alimentée sur plusieurs semaines, une requête simple isole les décisions les plus incertaines, celles qui méritent une vérification humaine en priorité :
SELECT * FROM wp_decisions_agent_contact
WHERE niveau_confiance < 0.6
ORDER BY date_decision DESC
LIMIT 20;
- Repérer les catégories les plus souvent associées à une confiance faible
- Identifier une dérive progressive dans le temps, si le niveau de confiance moyen baisse d’un mois sur l’autre
- Servir de base à une revue humaine périodique, plutôt qu’à une vérification systématique de chaque décision
Une décision d’agent sans justification enregistrée reste une boîte noire : la traçabilité d’un agent ne se limite pas à son résultat, elle inclut le raisonnement qui y conduit.
Ce qu’il faut retenir
Une table dédiée, structurée autour de la décision elle-même plutôt que du seul événement technique, rend possible une analyse a posteriori qu’un fichier de journalisation classique ne permet pas. Le champ de justification, souvent négligé, constitue l’élément le plus précieux de cette structure pour comprendre les choix faits par l’agent au fil du temps.
