# Donner à un agent IA un bac à sable qui ne touche jamais le site en ligne > Construire une copie jetable d'un site WordPress où un agent peut agir librement avant d'autoriser la même action en production, sans jamais partager la base réelle. - Auteur : WordPress Développement - Publié le : 2025-09-08 - Mis à jour le : 2025-09-08 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/bac-a-sable-agent-ia-jamais-site-production/ ## L’essentiel - Une copie jetable, recréée à chaque session, évite tout risque sur les données réelles - Le domaine et les identifiants doivent différer visiblement de la production - Un agent ne doit jamais recevoir les deux accès en même temps `wp db export` puis `wp db import` : ces deux commandes suffisent, à elles seules, à construire l'essentiel d'un bac à sable jetable pour un agent IA. Mais la commande n'est que la partie visible d'une démarche plus large, qui doit garantir qu'aucun appel de l'agent, même erroné, ne puisse jamais atteindre la base de données réelle du site. Voici la méthode suivie pour mettre en place un tel environnement, avant d'autoriser un agent à exécuter la moindre action d'écriture sur un site en production, et les points de vigilance qui rendent cette isolation réellement fiable plutôt que théorique. ## Pourquoi un environnement de test classique ne suffit pas Un environnement de recette habituel, pensé pour des développeurs humains, part souvent du principe qu'une personne prudente ne va pas accidentellement appeler une route de production depuis son poste local. Un agent n'a pas cette prudence par défaut : s'il reçoit à la fois l'URL et les identifiants de la copie de test et ceux du site réel dans le même contexte, rien ne garantit qu'il n'invoquera jamais le mauvais outil au mauvais endroit, en particulier si les deux environnements portent des noms proches. ## Recréer la copie plutôt que la réutiliser La copie de test n'est pas un environnement permanent qu'on synchronise de temps en temps : elle est recréée entièrement avant chaque session de travail confiée à l'agent, à partir d'un export récent de la production, purgé des données sensibles avant import. > L'essentiel à retenir : Une copie jetable, recréée à chaque session, évite tout risque sur les données réelles ; Le domaine et les identifiants doivent différer visiblement de la production ; Un agent ne doit jamais recevoir les deux accès en même temps ``` #!/usr/bin/env bash set -euo pipefail wp db export /tmp/export-prod.sql --path=/var/www/production wp db import /tmp/export-prod.sql --path=/var/www/bac-a-sable wp search-replace 'https://exemple-asso.fr' 'https://bac-a-sable.exemple-asso.fr' \ --path=/var/www/bac-a-sable --all-tables wp eval 'foreach ( get_users( array( "role" => "customer" ) ) as $u ) { wp_update_user( array( "ID" => $u->ID, "user_email" => "anon-" . $u->ID . "@bac-a-sable.test" ) ); }' --path=/var/www/bac-a-sable rm -f /tmp/export-prod.sql ``` ## Un domaine et des identifiants visiblement différents Le sous-domaine `bac-a-sable.exemple-asso.fr` n'a pas été choisi par hasard : il doit rester impossible de confondre, même en lisant vite, l'URL de test avec celle de production. Les identifiants d'application WordPress générés pour l'agent sur cette copie sont eux aussi distincts, avec un préfixe explicite dans leur nom, et une durée de validité limitée à la session de travail en cours. - Nom de domaine distinct, jamais un simple sous-dossier de l'URL réelle. - Base de données purgée des adresses e-mail et données de paiement réelles avant tout usage. - Jeton d'application propre à la copie, révoqué à la fin de chaque session. - Aucun accès simultané aux deux environnements dans le contexte transmis à l'agent. ## Ce qu'une copie jetable ne remplace pas Cette isolation protège contre les conséquences d'une action mal choisie par l'agent, elle ne garantit en rien que l'action testée se comportera à l'identique en production : des extensions tierces, des files d'attente ou des services externes connectés uniquement en production peuvent réagir différemment. La copie jetable est une étape de validation du comportement de l'agent, pas une garantie de résultat identique une fois l'autorisation donnée en production. > Une copie de test qui ressemble trop à la production finit toujours, un jour ou l'autre, par être confondue avec elle. Mieux vaut qu'elle soit visiblement différente que rassurante. ## Passer de la copie jetable à la production Une fois qu'une action a été validée plusieurs fois sur la copie jetable sans effet indésirable, l'autorisation en production se fait outil par outil, jamais en bloc : chaque nouvel outil accordé à l'agent repasse par au moins une session complète sur la copie jetable avant d'être activé ailleurs. Ce séquencement ralentit la mise en production de nouvelles capacités, mais il a évité, sur ce projet, qu'un outil mal testé n'agisse directement sur des données réelles dès sa première utilisation. ## En résumé Un bac à sable qui protège réellement la production repose sur trois piliers simples à énoncer mais faciles à négliger : une copie recréée à chaque session plutôt que réutilisée, un domaine et des identifiants qu'on ne peut pas confondre avec ceux de la production, et l'absence totale d'accès simultané aux deux environnements dans le contexte de l'agent. Aucun de ces trois points ne demande d'outil sophistiqué, seulement de la rigueur dans la mise en place.