Démo commerciale : construire un environnement fictif

Une démonstration de logiciel doit montrer un scénario utile sans ouvrir des dossiers réels ni déclencher d’actions vers des clients. Préparez un jeu fictif, des comptes dédiés et des connexions maîtrisées. Remplacer les noms d’une copie de production ou afficher un bandeau « démo » ne suffit pas.

Le point de contrôle décisif est concret : que peut voir, saisir, télécharger et déclencher le présentateur ou le participant ? Cette méthode permet au responsable produit et au référent RGPD de préparer une démonstration reproductible, avec une décision claire si un contrôle échoue.

Choisir les données selon ce que vous voulez montrer

Commencez par le parcours : créer une demande, ajouter une pièce, faire valider, corriger une erreur, envoyer un rappel. Pour chaque étape, décrivez les champs nécessaires et le résultat attendu. Vous pourrez ensuite fabriquer les dossiers correspondants, au lieu de chercher dans la production un client qui « ferait un bon exemple ».

Trois situations demandent des décisions différentes :

Le guide des données de test développe cette distinction. Une donnée dite synthétique n’est pas rendue anonyme par son seul nom : si votre jeu provient d’une base réelle, examinez les risques de réidentification des données synthétiques.

Le cadre RGPD ne disparaît pas derrière le mode « démo »

Utiliser un dossier client pour convaincre un prospect constitue une utilisation à analyser, pas une conséquence automatiquement permise par la collecte initiale. Les Art. 5(1)(b) et (c) encadrent finalités et minimisation ; une base légale reste nécessaire lorsque des données personnelles sont traitées. RGPD, Art. 5 et 6.

Les Art. 25(1) et (2) imposent une protection intégrée à la conception et aux paramètres par défaut. L’Art. 32(1) impose une sécurité appropriée au risque. Le choix d’un environnement et de connexions adaptés doit donc précéder la première présentation. RGPD, Art. 25 et 32.

La CNIL recommande des environnements de développement et de test distincts de la production, avec des données fictives ou anonymisées. Cette recommandation fournit un appui technique utile ; elle ne constitue pas un régime juridique spécifique aux démonstrations commerciales. CNIL, encadrer les développements informatiques.

Même si les dossiers présentés sont fictifs, les comptes des salariés, les inscriptions des participants et les journaux de connexion peuvent contenir des données personnelles. Il faut les gérer avec leurs propres finalités, accès, informations et durées. « Notre démo est fictive » ne décrit que le jeu de dossiers.

Cas complet : présenter un outil de suivi d’interventions

Scénario hypothétique. Une PME éditrice d’un logiciel veut montrer à une entreprise de maintenance comment traiter une demande, programmer une intervention et produire un compte rendu. La présentation dure une vingtaine de minutes. Aucun dossier d’un client existant n’est nécessaire.

La responsable produit prépare trois situations : une demande complète, une demande avec une pièce manquante et une intervention terminée. Elle crée les références DEMO-101 à DEMO-103, des sites explicitement fictifs et deux documents fabriqués pour l’exemple. Les dates sont cohérentes avec l’ordre des opérations. Les pièces portent la mention « document de démonstration ».

L’objectif n’est pas de générer des centaines de faux dossiers. Trois cas suffisent ici pour montrer un parcours normal, une difficulté et sa résolution. Le jeu peut contenir des montants ou délais réalistes, sans les emprunter à un contrat client.

Le présentateur utilise un compte limité aux fonctions montrées. Une seconde personne peut jouer le valideur avec un autre compte dédié. Les identités réelles du personnel n’apparaissent pas dans les fiches fictives ; les comptes techniques restent attribués et maîtrisés en interne.

La fiche d’environnement remplie

Cette fiche est une proposition pour le scénario, à adapter à l’architecture réelle. Elle sert de référence au responsable produit et à l’informatique.

Une adresse électronique choisie au hasard peut appartenir à quelqu’un. Le contrôle doit empêcher la remise d’un message réel, pas seulement espérer que l’adresse est inutilisée. Si l’environnement permet des envois, leurs destinations doivent être effectivement maîtrisées.

Le bouton « envoyer » peut être montré sans utiliser l’infrastructure de messagerie de production. En revanche, le commercial doit expliquer honnêtement ce qui est simulé : une démo ne doit pas faire passer un résultat préparé pour une intégration réellement configurée chez le prospect.

Isoler les connexions, pas seulement l’interface

Un espace séparé peut rester relié au stockage réel, au moteur de recherche global ou à une automatisation de production. Le même problème existe lorsqu’un import de configuration conserve des clés d’accès ou une adresse de notification oubliée.

L’informatique dresse donc les sorties possibles : messagerie, stockage, agenda, facturation, notifications, outils de support et services appelés automatiquement. Pour chaque connexion, elle choisit une simulation, un service de test adapté ou une désactivation. Elle vérifie aussi les tâches différées : un rappel programmé pendant la présentation peut partir après sa fin.

Dans le cas fictif, le premier essai du rappel révèle une connexion de messagerie encore active. L’équipe bloque la présentation de cette fonction, retire cette connexion puis confirme que le message suivant arrive uniquement dans la capture prévue. La fiche conserve le défaut constaté et le contrôle ayant permis sa clôture.

Une restriction seulement visuelle ne protège pas nécessairement la donnée sous-jacente. Vérifiez le compte réellement utilisé et ses accès, notamment dans la recherche interne et ses habilitations. Le fait que le présentateur connaisse le bon parcours ne doit pas être la seule protection contre un clic ailleurs.

Une répétition qui couvre aussi les erreurs

La répétition doit explorer les chemins qu’un prospect curieux pourrait demander. Pour notre démonstration, le responsable produit suit ce déroulé :

1. Ouvrir DEMO-101 depuis la liste, puis effectuer une recherche et consulter les éléments récents.
2. Ajouter la pièce fictive manquante à DEMO-102 ; refuser ensuite la validation pour montrer la correction.
3. Déclencher le rappel et vérifier sa destination dans la capture interne.
4. Télécharger le compte rendu de DEMO-103 et inspecter le fichier obtenu.
5. Revenir au jeu initial et vérifier qu’aucune saisie de la répétition ne reste exposée.

Contrôlez aussi les suggestions de saisie, notifications, menus de documents récents et fenêtres de sélection de fichiers. Un dossier principal entièrement fictif n’empêche pas un nom réel de surgir dans une suggestion ou dans le répertoire de téléchargement du poste partagé à l’écran.

La validation peut rester courte : version du jeu, compte utilisé, actions contrôlées, résultat et personne ayant vérifié. Elle ne doit pas annoncer « environnement sûr » sans préciser ce qui a réellement été examiné.

Décider avant la session : poursuivre, limiter ou reporter

Trois résultats conduisent à trois décisions :

• Parcours vérifié et environnement connu : la présentation peut utiliser les fonctions validées.
• Fonction isolée non vérifiée : retirez-la du parcours et empêchez son déclenchement ; utilisez une illustration fictive préparée si elle répond au besoin.
• Donnée réelle ou accès de production découvert : suspendez l’usage de l’environnement concerné jusqu’à correction et nouveau contrôle.

Le report d’une fonction est une décision de préparation, pas une sanction pour l’équipe commerciale. Il vaut mieux annoncer qu’une intégration sera montrée lors d’une session préparée que l’improviser avec un compte client.

Si une donnée réelle a déjà été exposée à des personnes non autorisées, conservez les faits utiles et déclenchez la qualification de l’incident. Les Art. 33 et 34 déterminent les obligations de notification et d’information selon leurs conditions ; une présentation interrompue ne suffit pas à conclure que tout risque a disparu. Source : RGPD, Art. 33 et 34.

Encadrer les saisies des participants

Une présentation conduite par un salarié et un essai libre par le prospect ne présentent pas les mêmes possibilités d’apport. Si le participant peut importer un fichier, il peut transformer l’espace fictif en traitement de ses propres données.

Annoncez dès l’entrée d’utiliser les dossiers et documents fournis. Proposez un choix de pièces fictives au lieu d’un import libre lorsque cela suffit au parcours. Une consigne seule reste fragile : limitez effectivement les fonctionnalités qui ne sont pas nécessaires.

Dans notre cas, le prospect souhaite essayer son propre fichier d’interventions. Le présentateur refuse l’import dans la démonstration partagée et propose d’examiner un essai encadré séparément. Avant cet essai, les parties devront définir le périmètre, les rôles, le contrat applicable, les accès, les flux et le sort des données. La présence d’un bouton d’import ne règle aucune de ces questions.

Si un fichier réel est néanmoins ajouté, interrompez son affichage, identifiez où il a été enregistré ou copié et traitez son retrait. Vérifiez les téléchargements et notifications éventuels ; supprimer seulement la fiche visible peut laisser des copies ailleurs.

Remettre l’environnement en état et préserver le jeu de référence

Après la session, le propriétaire de l’environnement retire les apports inutiles, révoque les accès temporaires et rétablit le jeu prévu. Dans le scénario, cette opération intervient après chaque session interactive pour éviter qu’un ajout soit montré au prospect suivant. C’est un choix de fonctionnement, pas une fréquence réglementaire universelle.

Vérifiez le résultat : trois dossiers de référence, deux documents attendus, aucune tâche d’envoi en attente et aucun compte invité encore actif. Les journaux nécessaires sont gérés séparément ; la remise à zéro ne justifie ni leur conservation illimitée ni leur suppression aveugle en présence d’un incident.

Refaites les contrôles pertinents après une évolution : nouveau connecteur, nouvelle recherche, fonction d’IA, possibilité d’export ou changement des droits. Une validation ancienne ne couvre pas automatiquement le fonctionnement ajouté.

Ce qu’il faut retenir

• Fabriquez les données à partir du scénario à montrer.
• Vérifiez fichiers, comptes, recherche et sorties vers les services externes.
• Prévoyez la décision à prendre si un contrôle échoue.
• Un essai avec les données du prospect exige son propre cadre.

FAQ

Peut-on utiliser une capture d’écran d’un vrai dossier ?

Une capture peut encore révéler des noms, situations ou références. Préférez une capture du jeu fictif ; si vous utilisez une image issue du réel, son contenu et sa diffusion doivent être analysés et maîtrisés.

Un accord de confidentialité du prospect suffit-il ?

Il peut encadrer ses engagements, mais ne rend pas nécessaire ni automatiquement licite la communication des données d’autres personnes. Il ne remplace pas la minimisation et la préparation de l’environnement.

Faut-il recréer tout le jeu après chaque mise à jour ?

Pas nécessairement. Reprenez les éléments affectés et les parcours susceptibles de révéler de nouveaux accès ou flux. Conservez une version de référence cohérente et la trace des contrôles effectués.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.