Mode sandbox pour démos : semer un tenant et bloquer les e-mails réels

Qu'est-ce qui peut mal tourner quand vous faites une démo sur un système en production

Une démo en direct donne l'impression d'être fluide parce que tout est déjà configuré. C'est aussi l'endroit où un petit clic peut devenir une action réelle : vrais e-mails, prélèvements réels et modifications de données effectives.

La surprise la plus fréquente concerne les messages. Un utilisateur de démo met à jour un profil, invite un coéquipier ou déclenche une réinitialisation de mot de passe et votre appli envoie joyeusement un e-mail vers une vraie adresse. Si votre compte de démo utilise les paramètres de production, même un « test » peut avertir de vrais clients, spammer une liste ou divulguer des informations privées dans un modèle.

Les paiements peuvent être pire. Il suffit d'un seul flux de paiement connecté à un processeur en direct, d'une carte enregistrée, ou d'une étape de « vérification à 1 $ » pour prélever de l'argent par erreur. Parfois, cela n'arrive même pas pendant l'appel : un utilisateur clique sur « passer à la version payante », votre job de facturation s'exécute plus tard, et un compte est facturé quand vous avez déjà oublié la démo.

« Utilisez simplement le staging » ne résout pas toujours le problème. Le staging partage souvent des intégrations tierces (e-mails, SMS, webhooks) et est fréquemment moins verrouillé. Ou votre démo a besoin de données et de performance proches de la production, si bien que des équipes finissent par démo en production.

Un bac à sable de démo sûr doit protéger quatre choses :

• Les personnes (pas d'e-mails, de SMS ou d'invitations accidentels)
• L'argent (pas de prélèvements réels, remboursements, factures ou paiements)
• Les données (pas d'accès aux enregistrements clients, et pas d'actions de démo qui modifient de vrais comptes)
• La réputation (pas de notifications surprises aux partenaires via webhooks ou intégrations)

Imaginez un fondateur présentant à un investisseur. Il tape une vraie adresse e-mail lors de l'inscription, clique sur « inviter un coéquipier » et votre appli envoie une invitation à une personne au hasard. Puis il clique sur « passer à la version payante » et le système crée un abonnement réel. C'est le genre d'histoire de démo qu'il suffit de vivre une fois.

Ce que signifie réellement le « mode sandbox » en termes simples

Un mode sandbox pour les démos est une promesse que vous vous faites à vous-même et à votre audience : le produit doit sembler réel, mais ne doit pas pouvoir provoquer d'impact réel dans le monde.

Cette promesse diffère d'un environnement de staging. Le staging est généralement une copie séparée de votre appli où les ingénieurs testent les changements. Il peut toujours envoyer des e-mails si quelqu'un le mal configure, et contient souvent des données mixtes et incomplètes. Le mode sandbox est un comportement que votre appli impose, même si l'UI ressemble à la production.

C'est aussi différent d'un simple « compte test ». Un compte test n'est qu'un autre enregistrement utilisateur. Si votre appli est reliée à de vrais e-mails, paiements et intégrations, ce compte peut toujours déclencher des effets secondaires.

Les effets secondaires sont tout ce que votre démo peut faire accidentellement en dehors de votre appli. Les suspects habituels sont les messages sortants (e-mail/SMS), les paiements, les webhooks et intégrations (mises à jour CRM, notifications Slack, automatisations), et les écritures de données qui créent de vrais objets (clients, commandes, tickets de support).

Un bon sandbox garde l'expérience réaliste en simulant les résultats. L'utilisateur clique sur « Inviter un coéquipier », il voit « Invitation envoyée », le journal d'activité se met à jour, mais aucun e-mail ne quitte votre système. L'utilisateur clique sur « Passer à la version payante », il voit un écran de reçu crédible et un badge « Plan : Pro », mais rien n'est prélevé.

Décidez quoi simuler, bloquer ou autoriser en démo

Avant de construire quoi que ce soit, inventairez chaque effet « monde réel » que votre appli peut déclencher. Un bon mode sandbox porte moins sur de jolies données factices que sur le fait que rien ne s'échappe de votre tenant de démo.

Commencez par tout ce qui peut causer des dégâts ou de la confusion : e-mails, SMS, paiements, webhooks, téléchargements de fichiers et analytics. N'oubliez pas les risques plus discrets comme les réinitialisations de mot de passe, les liens d'invitation, les exports et les jobs en arrière-plan.

Ensuite, décidez ce qui doit être bloqué, ce qui peut être autorisé, et ce qui doit être simulé pour paraître réel pour l'utilisateur. Une règle simple : les lectures sont généralement sûres ; les envois, prélèvements et notifications doivent être bloqués ou simulés.

Une répartition pratique pour la plupart des produits ressemble à ceci :

• Autoriser : recherche, filtrage, tableaux de bord, consultation de rapports, modification des champs de profil
• Simuler : « envoyer une invitation », « e-mail de reçu », « mise à niveau de plan », « notifier l'équipe » (afficher une UI de succès et enregistrer l'événement)
• Bloquer : débit d'une carte, envoi d'e-mails/SMS réels, appel aux webhooks clients, export de données réelles
• Verrouiller : actions destructrices comme suppression, mises à jour en masse, ou changements d'admin (exiger une étape de confirmation)

Ensuite, définissez ce que le tenant de démo peut voir et modifier. L'objectif est un terrain de jeu sûr, pas un compte admin pouvant accéder à des paramètres de type production. Par exemple, vous pouvez autoriser la création de projets et de tâches, mais interdire la modification des détails de facturation, des clés API ou des paramètres d'authentification.

Écrivez les règles en un seul endroit afin que l'équipe reste alignée. Gardez-le court et concret :

• Ce que le tenant de démo est autorisé à faire
• Ce qui est toujours bloqué (sans exception)
• Ce qui est simulé et comment cela apparaît à l'utilisateur
• Où l'activité de démo est journalisée pour le dépannage
• Qui peut activer ou désactiver le mode démo

Exemple : pendant un appel commercial, quelqu'un peut s'inscrire, créer un espace de travail, inviter un coéquipier (simulé) et cliquer sur « Passer à la version payante » pour voir les fonctionnalités (simulées), mais l'appli n'envoie jamais d'e-mail ni n'essaie d'effectuer un prélèvement réel.

Étape par étape : semer un tenant de démo que vous pouvez réinitialiser

Commencez par créer un tenant dédié uniquement aux démos. Donnez-lui un nom sans ambiguïté (par exemple « DEMO - ACME ») et stockez un drapeau clair dans la base de données (par exemple is_demo_tenant = true). Ce drapeau devient votre filet de sécurité pour les règles ultérieures comme le blocage des e-mails et des paiements.

Ensuite, semez des données réalistes pour que le produit ait l'air vivant. Visez le « juste assez » : quelques utilisateurs d'exemple, un ou deux projets, et un petit ensemble d'éléments montrant les workflows principaux. Utilisez des noms et statuts crédibles, mais n'utilisez jamais de vraies données clients.

Gardez le script de seed petit et reproductible. Si vous ne pouvez pas le relancer en toute sécurité, ce n'est pas encore un vrai script de seed. Préférez des IDs déterministes ou un « namespace de démo » cohérent afin que les réinitialisations n'entraînent pas de doublons.

Un pattern de réinitialisation qui marche pour la plupart des applis :

• Supprimer toutes les données du tenant de démo (ou restaurer depuis un snapshot propre)
• Re-créer le tenant de démo avec le drapeau de démo
• Insérer des utilisateurs d'exemple et des rôles (admin, membre, lecteur)
• Insérer quelques enregistrements réalistes (projets, messages, factures)
• Vérifier que les écrans clés se chargent sans corrections manuelles

Rendez la réinitialisation facile. Un bouton de réinitialisation en un clic pour usage interne est idéal, et une réinitialisation programmée chaque nuit est un bon filet. Enfin, ajoutez un indicateur visible « Mode démo » dans l'UI (barre supérieure, en-tête ou bannière) pour que personne n'oublie où il se trouve.

Étape par étape : ajouter un interrupteur de mode démo visible

Une démo sûre commence par un interrupteur clair qui change le comportement de toute l'appli. Choisissez un seul endroit pour le contrôler (une variable d'environnement, un paramètre tenant, ou un feature flag), et faites en sorte que tout le reste le lise.

1) Choisir un seul interrupteur et rendre le mode « sûr » par défaut

Pour beaucoup d'équipes, une variable d'environnement est la solution la plus simple : DEMO_MODE=true. Si vous avez besoin de tenants réels et de démo dans le même environnement, utilisez un paramètre au niveau du tenant comme tenant.is_demo.

Rendez le comportement par défaut sûr. Les accidents arrivent quand quelqu'un oublie de positionner une variable.

2) Centraliser les vérifications (éviter les if dispersés)

Créez un seul module « demo guard » que votre appli appelle avant toute action risquée. Le garde décide : autoriser, bloquer, ou remplacer par une réponse factice. Chaque envoi d'e-mail, appel de paiement, webhook et export doit passer par ce module.

Routez ceci via le garde :

• Messages sortants (e-mail, SMS, push)
• Paiements et remboursements
• Webhooks et appels API tiers
• Exports de fichiers (CSV, factures, rapports)
• Actions d'administration (suppression, invitation, changements de rôles)

3) Journalisez tout ce que vous bloquez (pour pouvoir le prouver)

Lorsque le garde bloque une action, écrivez un événement log clair indiquant ce qui a été tenté, quel tenant/utilisateur l'a fait, et pourquoi cela a été bloqué. Exemple : pendant une démo, quelqu'un clique sur « Inviter un coéquipier », vous retournez « Invitation mise en file (démo) » tout en loguant blocked_email_send. Si une partie prenante demande « Quelque chose est-il sorti ? », vous aurez une réponse.

4) Rendre le contournement difficile

Ajoutez une bannière visible « DEMO MODE » et mentionnez-la dans les logs serveur au démarrage. Ajoutez aussi un test qui échoue si le mode démo est désactivé dans un environnement de démo.

Étape par étape : empêcher les e-mails, SMS et webhooks réels

La façon la plus rapide de foirer une démo est que votre appli parle à de vraies personnes ou systèmes. En mode sandbox, traitez chaque message sortant comme dangereux par défaut, puis autorisez seulement ce que vous pouvez contrôler totalement.

1) Empêcher les e-mails sortants de quitter votre système

Commencez par l'e-mail car il est souvent relié à l'inscription, aux invitations, aux réinitialisations et aux reçus.

• Redirigez tous les e-mails sortants vers une boîte de réception de capture, ou désactivez l'envoi complètement en démo
• Remplacez chaque adresse destinataire par une adresse de test sûre (même si l'utilisateur a saisi la sienne)
• Ajoutez une bannière in-app comme « E-mail supprimé en mode démo » pour éviter la confusion
• Journalisez le contenu de l'e-mail dans l'UI (objet et aperçu) pour que la démo paraisse réelle
• Empêchez les retries en arrière-plan afin qu'un e-mail supprimé ne reste pas en file d'attente indéfiniment

Exemple : pendant une démo, quelqu'un invite [email protected]. Votre appli devrait la remplacer par une adresse sûre (comme [email protected]), puis afficher un toast : « E-mail d'invitation supprimé en démo. Voir le message. » Cela maintient le fil narratif sans contacter un vrai client.

2) Bloquer SMS, push, webhooks et jobs en arrière-plan de la même manière

Appliquez la même règle pour les SMS et notifications push : ne jamais envoyer vers un appareil réel en démo. Pour les webhooks, mettez la livraison en pause ou simulez-la et affichez ce qui aurait été envoyé.

Si vous avez des jobs en arrière-plan (séquences d'accueil, retries de facturation, synchronisation CRM), empêchez-les de s'exécuter pour les tenants de démo ou forcez-les vers un chemin sûr no-op.

Étape par étape : faire paraître les paiements réels tout en restant sûr

Les paiements sont là où les démos deviennent risquées très vite. Un bon mode sandbox rend le checkout crédible, mais garantit qu'aucun argent réel ne bouge, même si quelqu'un clique sur tous les boutons.

1) Utilisez par défaut la configuration de test du fournisseur

Connectez votre appli à l'environnement de test de votre fournisseur de paiement avec des clés de test. Séparez ces clés de celles de production et chargez-les depuis des variables d'environnement pour éviter d'embarquer accidentellement des clés live dans un build de démo.

Si vous pouvez avoir des tenants réels et de démo dans le même environnement, un drapeau au niveau du tenant comme is_demo_tenant est plus fiable qu'un réglage global.

2) Bloquer formellement tout débit réel pour les tenants de démo

Même avec des clés de test, ajoutez un second filet : lorsque is_demo_tenant est vrai, n'appelez pas du tout la capture/débit. Retournez une réponse contrôlée côté backend.

Un flux simple ressemble à ceci :

• L'utilisateur clique sur « Payer » ou « Passer à la version payante »
• Le backend détecte le tenant de démo et saute l'appel au fournisseur
• Le backend enregistre un faux enregistrement de transaction (statut, montant, devise)
• L'UI reçoit un résultat réaliste « succès » et affiche un écran de reçu
• Les pages d'administration montrent de façon cohérente le même paiement factice

3) Garder abonnements, remboursements et factures cohérents

Les démos se délitent quand un écran dit « Abonné » mais la liste des factures est vide. Choisissez un ensemble d'états factices et réutilisez-les partout : date de début d'abonnement, prochaine date de facturation, IDs de factures et statut de remboursement.

Exemple : un utilisateur « passe » à Pro pendant la démo. Vous générez INV-DEMO-1042, marquez la facture comme payée et fixez un renouvellement dans 30 jours. S'il clique sur « Rembourser », basculez les mêmes enregistrements en remboursé et affichez une note de crédit correspondante.

4) Ignorer les webhooks de paiement en mode démo

Les webhooks peuvent écraser votre état factice. À la réception d'un webhook, vérifiez le tenant (ou les métadonnées) et ignorez-le s'il cible un tenant de démo. Journalisez-le pour prouver que le blocage a fonctionné.

Principes de sécurité et confidentialité pour les environnements de démo

Un environnement de démo doit être sûr même lorsque vous êtes fatigué, pressé ou que vous partagez l'accès avec quelqu'un de peu connu. L'objectif est simple : votre démo peut paraître réelle, mais ne peut pas toucher de vraies données clients ni déclencher des actions irréversibles.

Commencez par une séparation stricte. Les comptes de démo ne devraient pas pouvoir voir ou deviner de vrais IDs de tenants, de vrais utilisateurs ou de vrais fichiers. Gardez les données de démo dans une base/schéma et un bucket de stockage séparés, et bloquez par défaut les lectures inter-tenant. Si vous avez des vues « admin », assurez-vous que les admins de démo n'administrent que le tenant de démo.

Verrouillez les actions qui causent des dégâts

Même en démo, certains boutons sont trop dangereux. Supprimez-les, placez-les derrière une connexion interne séparée, ou transformez-les en no-op en mode démo. Priorisez les contrôles comme exports, suppressions, modifications de rôles/permissions et téléchargements en masse. Limitez les uploads (type et taille) et rejetez tout contenu exécutable.

Les limites de taux importent plus qu'on ne le croit. Les démos publiques sont testées en force. Mettez des caps stricts sur les tentatives de connexion, réinitialisations de mots de passe et tout endpoint pouvant créer des coûts (uploads, appels tiers, SMS).

Journaux d'audit : partez du principe que vous devrez rejouer ce qui s'est passé

Enregistrez suffisamment de détails pour répondre à : qui a accédé à la démo, ce qu'il a essayé, et ce que le système a bloqué. Au minimum, logguez l'acteur (ID utilisateur), le tenant, l'IP et l'user agent, plus les événements clés comme connexion, tentatives d'invitation, tentatives d'export et changements de rôle. Rédigez les champs sensibles et stockez l'issue finale (autorisé/bloqué).

Si vous avez hérité d'un prototype généré par IA, vérifiez les fuites courantes comme secrets exposés, permissions admin trop larges ou contrôles de tenant manquants.

Erreurs fréquentes qui rendent une démo risquée

La plupart des désastres de démo arrivent parce que l'appli paraît sûre dans l'UI, mais le système continue de se comporter comme en production. Un bouton peut afficher « E-mail désactivé », et pourtant le backend envoie l'e-mail réel. Ou vous désactivez la page de checkout, mais le webhook de paiement déclenche quand quelqu'un réessaie un ancien lien.

Les erreurs qui coulent les démos sandbox encore et encore :

• Bloquer seulement le front-end alors que les endpoints backend envoient encore des e-mails, débitent des cartes ou appellent des APIs tierces
• Oublier les workers en arrière-plan, les jobs planifiés et les retries (ils s'exécutent souvent avec des credentials réels)
• Livrer un build de démo contenant encore des clés API réelles, des identifiants SMTP, ou des secrets de webhook de production
• Partager un seul compte de démo avec tout le monde, si bien que les réglages dérivent, les données se salissent et vous ne savez pas ce qui a changé
• Sauter un plan de réinitialisation, laissant le tenant de démo se remplir de données indésirables, d'états cassés et d'« abonnements fantômes »

Un exemple concret : vous montrez le flow d'« invitation d'équipe ». Le formulaire d'invitation est caché en mode démo, mais la route API est toujours active. Un curieux ouvre les devtools, frappe l'endpoint directement et votre worker envoie de vrais e-mails d'invitation à des adresses aléatoires. Maintenant vous avez un risque de confidentialité, de spam et une mauvaise image.

Deux habitudes préviennent la plupart de ces problèmes. D'abord, faites en sorte que le comportement sûr vive côté backend et pas seulement dans l'UI : bloquez formellement les fournisseurs sortants quand le mode démo est activé et logguez l'intention. Ensuite, traitez la réinitialisation comme une fonctionnalité : une action qui recrée le tenant de démo, resème les données connues et désactive les jobs longue durée pour ce tenant.

Checklist rapide avant de partager une démo

Une démo sûre ressemble à une appli ennuyeuse en coulisses. C'est une bonne chose. Avant de confier une démo à un prospect ou de monter sur un appel, faites une passe rapide qui prouve que votre démo ne peut pas envoyer de vrais messages, prélever de l'argent ou divulguer de vraies données.

Les 5 vérifications qui évitent la plupart des désastres

• Confirmez que vous êtes au bon endroit : le tenant de démo est clairement étiqueté et séparé de toute donnée client réelle
• Déclenchez les chemins bruyants : réinitialisation de mot de passe, invitation d'utilisateur, notifications. Vérifiez que les e-mails/SMS ne partent pas et que les webhooks sortants sont inactifs ou pointent vers une cible sûre
• Parcourez le chemin de l'argent : cliquez sur mise à niveau et tentez le checkout. Assurez-vous que c'est en mode test (clés de test) ou entièrement simulé et impossible à facturer
• Prouvez que vous pouvez nettoyer : lancez la réinitialisation, puis confirmez que le tenant revient à l'état de départ connu
• Cherchez les secrets accidentels : vérifiez la config d'environnement, les logs serveur et le code côté client pour des clés API réelles, tokens ou valeurs privées. Si un navigateur peut le voir, supposez que d'autres aussi

Script court pour le présentateur (quand des fonctionnalités sont désactivées)

Dites une phrase, puis passez à la démo :

• « C'est un bac à sable, donc les messages sont bloqués pour des raisons de sécurité. »
• « Les paiements sont simulés, mais les écrans correspondent au flux réel. »
• « Après l'appel, nous réinitialisons cette démo pour que tout le monde reparte à zéro. »

Exécutez cette checklist une fois par jour de démo. Cela prend quelques minutes et évite les surprises.

Exemple : une démo produit sûre de l'inscription à la « mise à niveau »

Un fondateur présente devant deux personnes : un investisseur et un client pilote. Le but est de montrer le parcours complet sans risquer d'e-mails réels, de prélèvements réels ou d'envois accidentels.

La démo commence avec un espace « Acme Demo » propre qui a été semé auparavant. Il contient déjà des projets réalistes, quelques tâches et des stats d'utilisation d'exemple pour que les écrans ne paraissent pas vides. Le fondateur s'inscrit avec une nouvelle adresse e-mail pour prouver que le onboarding fonctionne. En coulisses, le système route tout vers un tenant de démo dédié et marque la session en mode sandbox.

Ensuite, l'audience demande d'inviter un coéquipier. Le fondateur tape une adresse à l'air réelle, clique sur Inviter et l'UI affiche « Invitation envoyée ». En coulisses, l'e-mail est supprimé et stocké dans un journal d'audit avec une note comme « bloqué en mode démo ». Si le client pilote demande « Mon coéquipier l'a-t-il reçu ? », le fondateur répond honnêtement : « Non, les invitations sont simulées dans cet environnement pour ne contacter personne par erreur. »

Puis vient le moment de la mise à niveau. L'investisseur veut voir les prix et le paiement.

Ce que voit l'audience

Ils réalisent trois actions : inscription, invitation d'un coéquipier et mise à niveau d'un plan. Le flux de mise à niveau accepte un numéro de carte de test et affiche un écran de succès, puis le compte passe en « Pro » avec des limites supérieures.

Ce qui se passe en coulisses

Les paiements ne vont jamais chez un processeur live. L'appli crée un enregistrement de paiement dédié à la démo, retourne un statut « payé » et maintient cet état de façon cohérente pour les factures et les pages admin. Les webhooks sont ignorés pour le tenant de démo et tout e-mail de « reçu » est supprimé.

Après l'appel, l'équipe clique sur un bouton de réinitialisation (ou exécute un script) qui efface le tenant de démo et le resème dans l'état connu bon.

Prochaines étapes : livrer une démo qui ne vous surprendra pas

Commencez par choisir le bon lieu pour la démo. Le mode sandbox sert à la sécurité à l'intérieur de la même appli : vous gardez l'UI réelle, mais bloquez les effets secondaires (vrais e-mails, vrais prélèvements, vrais webhooks). Le staging est une copie séparée de la production : utile pour tester les releases, mais il peut encore envoyer de vrais e-mails si vous oubliez un réglage. Beaucoup d'équipes ont besoin des deux : staging pour tester les releases, et mode sandbox pour les démos client.

Si vous voulez la voie la plus rapide vers une démo plus sûre, déployez par petites étapes :

• Bloquez d'abord les e-mails/SMS réels (remplacez par un journal ou une vue d'inbox)
• Faites paraître les paiements réussis sans prélever les cartes
• Désactivez les webhooks sortants et les jobs en arrière-plan qui communiquent avec de vrais systèmes
• Ajoutez un bouton de réinitialisation pour le tenant de démo (ou une réinitialisation nocturne)
• Ensuite seulement, peaufinez les données semées et les parcours

Ajoutez des garde-fous qui échouent bruyamment. Si quelqu'un fait une démo sur le mauvais tenant, l'appli doit refuser les actions risquées.

Si vous avez hérité d'une base de code générée par IA (Lovable, Bolt, v0, Cursor, Replit), cela vaut la peine d'avoir un deuxième regard sur les branchements. FixMyMess (fixmymess.ai) se spécialise dans le diagnostic et la réparation de ce type d'effets secondaires — choses comme environnements mélangés, secrets exposés et intégrations pointant encore vers la production — afin que la démo reste sûre et reproductible.