Comment donner à un auditeur externe la possibilité de vérifier le comportement exact d’une extension, sans lui ouvrir un accès à la production ni lui livrer une copie de la base de données contenant des informations de santé ? C’est la question posée par un client du secteur médical avant un audit de conformité portant spécifiquement sur une extension de prise de rendez-vous en ligne.
La réponse habituelle — cloner l’environnement de staging et créer un compte temporaire pour l’auditeur — pose deux problèmes dans ce contexte : le staging contient généralement une copie anonymisée mais imparfaite des données réelles, et sa durée de vie dépasse largement le temps de l’audit, ce qui prolonge inutilement la surface d’exposition. WordPress Playground, l’environnement WordPress qui tourne entièrement dans le navigateur via WebAssembly, permet de générer un site jetable en quelques secondes, sans jamais toucher à une base de données réelle.
Construire le scénario d’audit avec un blueprint
Playground s’appuie sur des fichiers de blueprint au format JSON qui décrivent l’état initial du site à générer : version de WordPress, extensions installées et activées, contenu de démonstration créé au démarrage. Pour cet audit, le blueprint installait uniquement l’extension de prise de rendez-vous concernée et un jeu de données factices générées à la volée, sans aucun lien avec un patient réel.
{
"landingPage": "/wp-admin/admin.php?page=rdv-parametres",
"preferredVersions": {
"wp": "6.2",
"php": "8.1"
},
"steps": [
{
"step": "installPlugin",
"pluginZipFile": {
"resource": "url",
"url": "https://exemple-agence.fr/dist/rdv-extension-audit.zip"
}
},
{
"step": "runPHP",
"code": "<?php require '/wordpress/wp-load.php'; for ($i = 0; $i < 5; $i++) { wp_insert_post(['post_type' => 'rdv_demo', 'post_title' => 'Rendez-vous fictif ' . $i]); }"
}
]
}
Partager un lien plutôt qu’un accès
Une fois le blueprint validé, Playground génère une URL qui recrée l’environnement complet à chaque ouverture, dans le navigateur de l’auditeur, sans installation ni compte à créer. L’auditeur reçoit un simple lien, l’ouvre, manipule l’extension de prise de rendez-vous exactement comme un utilisateur le ferait, puis referme l’onglet : rien ne persiste au-delà de la session, aucune donnée n’a transité par un serveur intermédiaire.
Ce que Playground ne peut pas simuler
Cette approche a une limite claire qu’il faut annoncer à l’auditeur avant l’audit : Playground fonctionne sans base de données MySQL réelle (il utilise SQLite en interne) et sans connexion réseau sortante persistante vers des services tiers comme une API de calendrier externe ou un service d’envoi de SMS de confirmation. Pour l’audit du comportement de saisie, de validation des créneaux et d’affichage des consentements RGPD, cette limite n’était pas bloquante. Pour vérifier l’intégration complète avec le service de rappel SMS, un second environnement de staging classique restait nécessaire.
- Playground convient parfaitement à l’audit d’interface, de logique métier interne et de comportement de formulaire.
- Il ne convient pas pour auditer une intégration réseau avec un service tiers réel.
- Sa durée de vie limitée à la session du navigateur est un avantage de sécurité, pas une contrainte à contourner.
Vérifier que rien ne fuit malgré tout
Avant d’envoyer le lien, nous avons vérifié le blueprint avec un œil attentif à deux points : aucune URL de production n’était codée en dur dans le jeu de données de démonstration, et aucun identifiant de connexion réel n’apparaissait dans les commentaires du code de l’extension packagée pour l’audit. Ce contrôle manuel reste indispensable ; l’outil ne protège pas automatiquement contre une fuite involontaire glissée dans le contenu de démonstration.
Résultat de l’audit
L’auditeur a pu dérouler l’ensemble de son scénario de vérification — affichage du consentement, validation des champs obligatoires, comportement en cas de créneau déjà réservé — en moins d’une heure, sans qu’aucune donnée de santé réelle n’ait été manipulée à un seul moment du processus. Le rapport d’audit a explicitement mentionné cette méthode comme une bonne pratique de limitation de l’exposition des données.
Le meilleur moyen de protéger une donnée sensible pendant un audit reste de ne jamais la rendre accessible à l’auditeur, plutôt que de compter sur sa discrétion.
Pour aller plus loin
Cette méthode se généralise facilement à d’autres contextes d’audit externe : vérification d’accessibilité, revue de sécurité d’une extension tierce, démonstration commerciale sans exposer de données client. Le coût de mise en place d’un blueprint reste faible une fois le premier écrit, et il devient réutilisable pour chaque nouvel audit portant sur la même extension.
