Le WordPress d'aujourd'hui, décodé pour les développeurs

IA & MCP

Stocker le prompt système d’un assistant IA en option plutôt qu’en code

Rendre un prompt système ajustable depuis l'administration WordPress, sans nécessiter de redéploiement du plugin à chaque changement de ton.

Par WordPress Développement • 5 janvier 2024 • 4 min de lecture • Aucun commentaire
Stocker le prompt système d'un assistant IA en option plutôt qu'en code

Changer trois mots dans un prompt système ne devrait pas nécessiter une mise à jour de version, un déploiement, puis une vérification en production. C’est pourtant ce que provoque un prompt codé en dur directement dans le fichier PHP d’un plugin, dès qu’un rédacteur en chef souhaite ajuster le ton d’un assistant sans passer par le développeur à chaque fois.

Stocker ce prompt dans une option WordPress, modifiable depuis un écran de réglages classique, élimine cette dépendance sans complexité technique particulière.

Le prompt codé en dur, un frein à l’ajustement

Un prompt directement écrit dans le code ressemble souvent à ceci, mêlé à la logique d’appel de l’API :

function appeler_assistant( string $question ): ?string {
    $prompt_systeme = 'Tu es un assistant qui répond de façon concise et professionnelle.';
    // ... appel à l'API avec ce prompt fixe
}

Modifier ce texte impose de rouvrir le code source, de le tester, puis de déployer une nouvelle version du plugin. Pour un ajustement de ton, une reformulation d’une consigne ou l’ajout d’une contrainte métier, ce cycle complet est disproportionné par rapport à l’ampleur du changement.

Déplacer le prompt vers une option

L'essentiel à retenir : Un prompt codé en dur impose un redéploiement pour chaque ajustement ; Une option WordPress rend le prompt modifiable depuis l'administration ; Une valeur par défaut évite un prompt vide en cas d'oubli

Une option enregistrée via l’API de réglages de WordPress rend ce texte modifiable sans toucher au code, tout en conservant une valeur par défaut cohérente en cas d’absence de configuration :

add_action( 'admin_init', function () {
    register_setting( 'mon_plugin_reglages', 'mon_plugin_prompt_systeme', array(
        'type'              => 'string',
        'sanitize_callback' => 'sanitize_textarea_field',
        'default'           => 'Tu es un assistant qui répond de façon concise et professionnelle.',
    ) );
} );

function obtenir_prompt_systeme(): string {
    return get_option(
        'mon_plugin_prompt_systeme',
        'Tu es un assistant qui répond de façon concise et professionnelle.'
    );
}

Ajouter un champ dans l’écran de réglages

add_settings_field(
    'mon_plugin_prompt_systeme',
    'Prompt système de l\'assistant',
    function () {
        $valeur = obtenir_prompt_systeme();
        printf(
            '<textarea name="mon_plugin_prompt_systeme" rows="4" cols="60">%s</textarea>',
            esc_textarea( $valeur )
        );
    },
    'mon-plugin-reglages',
    'mon_plugin_section_ia'
);

Prévoir une valeur de secours robuste

Le second argument de get_option() fournit une valeur de secours si l’option n’existe pas encore, par exemple juste après l’installation du plugin avant tout enregistrement de réglage. Un prompt vide envoyé à l’API produirait des réponses imprévisibles, sans consigne pour cadrer le comportement du modèle : cette valeur de secours n’est donc pas un simple détail de confort, elle évite un comportement dégradé silencieux.

Historiser les changements de prompt

Une option modifiable depuis l’administration présente un risque nouveau : un changement effectué sans trace, difficile à relier à une dégradation constatée ensuite dans les réponses de l’assistant. Un enregistrement simple de l’historique, à chaque modification, facilite le diagnostic :

add_action( 'update_option_mon_plugin_prompt_systeme', function ( $ancienne, $nouvelle ) {
    $historique = get_option( 'mon_plugin_historique_prompts', array() );
    $historique[] = array(
        'date'     => current_time( 'mysql' ),
        'ancienne' => $ancienne,
        'nouvelle' => $nouvelle,
    );
    update_option( 'mon_plugin_historique_prompts', array_slice( $historique, -20 ) );
}, 10, 2 );
  • Conserver les vingt dernières versions suffit largement pour un usage éditorial courant
  • Afficher cet historique dans l’écran de réglages aide à revenir à une version antérieure en cas de dérive
  • Ne jamais supprimer l’ancienne valeur sans trace, même en cas d’erreur de saisie manifeste

Un prompt système modifiable sans historique associé transforme un gain de souplesse en risque de régression difficile à diagnostiquer : les deux doivent toujours aller de pair.

Ce qu’il faut retenir

Déplacer un prompt système du code vers une option WordPress redonne aux équipes éditoriales une autonomie qu’un cycle de déploiement classique ne permet pas. Cette souplesse mérite d’être accompagnée d’une valeur de secours fiable et d’un historique des changements, pour ne pas transformer un gain de réactivité en source d’instabilité.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

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

Voir tous ses articles

Dans la même veine

À lire aussi