Démo créée par programmation avec l’IA en 2026 : comment éviter les données personnelles réelles lors des tests de courriel ?

Le référentiel OWASP des risques liés aux applications fondées sur les grands modèles de langage présente dix catégories de risques, dont la divulgation d’informations sensibles (document OWASP sur les risques des applications LLM). Pour votre démo créée avec l’IA, la règle est simple : n’utilisez ni adresse de personne réelle, ni véritable code de vérification, ni profil personnel. Préférez des données synthétiques clairement identifiées, un circuit de réception isolé et des journaux réduits au nécessaire. Avant toute présentation publique, vérifiez manuellement que le code n’enverra pas de courriel à un utilisateur réel.

Cette démarche s’adresse à vous si vous développez seul une démo avec des fonctions d’inscription, de vérification ou de notification.
Elle est aussi utile si vous participez à une petite équipe non spécialisée ou si vous assurez la recette QA d’un environnement de démonstration.

Dernière mise à jour : 20 octobre 2026. Vérification documentaire : ressources OWASP citées ci-dessous et rapport Sonar sur l’état du code et les développeurs en 2026. Les recommandations qui suivent sont des pratiques de prudence, pas une certification de conformité : les obligations et les durées de conservation dépendent de votre organisation, de votre région et de votre activité.

Avant de créer les données, séparez les environnements et les flux

Une démo peut sembler indépendante alors qu’elle réutilise des éléments de votre application réelle : une base copiée pour gagner du temps, des identifiants de production conservés dans un fichier de configuration ou un service de messagerie configuré par défaut. Le code généré peut fonctionner sans que ces connexions soient appropriées. Il vous revient de repérer les flux réellement actifs.

Consignez, pour chaque environnement, les éléments suivants :

• La source des données : base de test vierge, jeu de données synthétiques ou copie de données existantes. Une copie de production reste une copie de données potentiellement personnelles, même si l’interface de la démo ne montre qu’une partie des champs.
• La configuration d’envoi : hôte de messagerie, identité de l’expéditeur, destinataires possibles et paramètres d’environnement. Vérifiez les valeurs effectivement chargées au lancement, pas uniquement celles inscrites dans un fichier exemple.
• Les destinations des messages : boîte de réception de test, mécanisme de capture interne ou service de transfert. Vérifiez également les liens de validation et de réinitialisation : leur domaine doit correspondre à l’environnement de test.
• Les traces et outils de suivi : journaux applicatifs, rapports d’erreur et espaces de partage utilisés par l’équipe. Une adresse retirée de l’écran peut encore apparaître dans une trace ou une capture.

Votre règle d’équipe doit exclure les adresses personnelles des utilisateurs, celles des collègues et leurs véritables codes de vérification des exemples de démonstration. Précisez aussi qu’aucun jeu de données de test ne doit être synchronisé vers la production. Ce choix réduit l’exposition inutile, mais ne suffit pas à établir à lui seul que votre dispositif respecte toutes les obligations applicables.

Pour évaluer votre configuration sans tableau, attribuez à chaque point un état maîtrisé, à vérifier ou bloquant. Une source de données inconnue, des identifiants de production ou un destinataire non contrôlé sont bloquants ; ne présentez pas la démo tant que vous ne les avez pas corrigés. Cette notation est un outil de triage interne, pas une mesure officielle du niveau de sécurité.

À la préparation, remplacez les personnes par des données synthétiques

Un nom inventé ne rend pas automatiquement un dossier anonyme. Un mélange d’informations rares ou réutilisées peut permettre de reconnaître une personne, et une adresse personnelle saisie dans un exemple reste une donnée réelle même si le reste du profil est fictif. La protection des données personnelles dans les jeux de test commence donc par le choix des champs, mais ne s’arrête pas à la création de fausses identités.

Pour un scénario de démo, utilisez des noms et des contenus inventés, sans reprendre ceux d’un client, d’un collègue ou d’une capture issue d’un compte réel. Pour le champ d’adresse, choisissez une adresse de test dont vous maîtrisez le circuit de réception, plutôt qu’une boîte personnelle saisie « juste pour essayer ». Gardez des valeurs reconnaissables comme fictives pour les noms de compte, les coordonnées et le contenu du message.

La donnée synthétique sert à réduire l’exposition d’informations réelles ; elle ne constitue pas, à elle seule, une garantie juridique ou technique. Si votre jeu de données est produit à partir d’enregistrements réels, demandez-vous si des détails peuvent encore être rattachés à une personne et qui peut accéder au résultat. Le guide du NIST sur la confidentialité différentielle traite d’une approche formelle de la confidentialité statistique : produire des données synthétiques ne revient pas automatiquement à appliquer cette approche ni à prouver l’absence de risque de réidentification.

Appliquez le même principe aux matériaux qui alimentent votre outil de programmation. Ne collez pas de courriel réel dans une consigne, un dépôt de code, un ticket partagé ou une image de démonstration. Même si l’outil produit ensuite un résultat convaincant, le texte initial a déjà été transmis à un autre contexte de traitement. L’OWASP classe la divulgation d’informations sensibles parmi les risques des applications utilisant des modèles de langage ; utilisez cette référence comme motif pour examiner vos flux, et non comme preuve que toute utilisation d’un assistant expose nécessairement vos données.

Une démo générée avec l’IA peut-elle être testée avec de vraies adresses ?

Évitez cette pratique pour les scénarios ordinaires. Elle peut envoyer des messages non sollicités, laisser des informations dans des journaux ou mélanger les données de test avec une boîte de réception professionnelle. Pour tester l’expérience d’un destinataire réel, définissez un compte de test contrôlé et un environnement autorisé ; ne choisissez pas l’adresse d’un client ou d’un collègue par commodité.

Voici une règle de décision utilisable avant chaque essai :

• Si l’adresse appartient à une personne réelle ou si vous n’avez pas son accord explicite, remplacez-la par une adresse synthétique et contrôlée.
• Si vous devez observer la réception effective du message, utilisez une boîte réservée aux tests ou un circuit de réception isolé, avec un accès limité à l’équipe concernée.
• Si le test concerne un compte sensible ou un parcours de récupération important, ne le faites pas sur une identité réelle dans la démo ; créez un environnement de test approuvé et des données dédiées.
• Si vous ne pouvez pas déterminer qui recevra le message, bloquez l’envoi avant l’exécution et corrigez la configuration.

L’usage d’une adresse jetable peut être adapté à une inscription temporaire ou à la réception d’un code pour tester votre propre produit. Il ne remplace pas un compte de test documenté lorsque vous devez suivre un échange, recevoir des réponses ou reproduire un parcours dans la durée. Pour choisir une méthode sans mêler ces cas, consultez le guide d’utilisation des adresses de test.

Au premier lancement, contrôlez le contenu et la destination du courriel

Avant de lancer l’inscription, le rappel de mot de passe ou une notification, vérifiez les valeurs qui déterminent le trajet du message. Dans la configuration, contrôlez au minimum l’hôte d’envoi, l’identité de l’expéditeur, le destinataire et le domaine des liens inclus dans le corps. Ces paramètres sont des points de contrôle concrets : un expéditeur de test ne suffit pas si le destinataire reste celui d’un client réel.

Examinez aussi le contenu généré par l’application. Un gabarit peut intégrer une valeur issue de la base, un nom de compte ou un lien de réinitialisation qui contient un jeton. Lancez des essais avec des données fictives et observez le message reçu dans le circuit de test. Vérifiez que le code de validation, le lien de récupération et les données affichées se rapportent bien à l’environnement de démo, pas à un profil de production.

Testez les chemins de réussite, d’échec et de nouvelle tentative. Un envoi qui échoue peut laisser un message dans une file d’attente, puis partir plus tard lorsque la configuration change. Une relance peut aussi générer plusieurs messages ou réutiliser un lien qui n’aurait pas dû être partagé. Confirmez donc ce que fait l’application lorsque l’adresse est invalide, que l’envoi est refusé ou que l’utilisateur demande une nouvelle validation. N’effectuez ces essais que sur votre propre produit et avec des destinataires de test autorisés.

Vous pouvez suivre cette séquence opérationnelle :

• Inspectez les variables de configuration réellement chargées par l’application.
• Remplacez les adresses et les profils par des valeurs synthétiques.
• Vérifiez le domaine de l’expéditeur et des liens présents dans le message.
• Déclenchez chaque parcours prévu, y compris l’échec et la relance.
• Confirmez où le message arrive, puis vérifiez ce qui est conservé dans les journaux.
• Arrêtez le test si un destinataire réel, une donnée de production ou un jeton inattendu apparaît.

Pour une recette plus structurée, utilisez une méthode de test qui suit les inscriptions, les codes et les réinitialisations comme des cas distincts. Si vous automatisez l’interface, séparez l’assertion « un message a été produit » de l’assertion « le bon destinataire l’a reçu ». Ce sont deux résultats distincts, et le premier ne prouve pas le second.

Comment traiter les codes et les données personnelles dans les courriels de test ?

Considérez un code de vérification ou un lien de réinitialisation comme un secret temporaire, pas comme un exemple inoffensif. Ne le copiez pas dans une documentation accessible largement, une capture destinée à une présentation ou un rapport d’erreur partagé sans contrôle. Dans le scénario de test, utilisez des comptes fictifs et évitez de conserver le code au-delà de ce qui est nécessaire pour diagnostiquer le parcours.

Le contenu d’un courriel de test doit aussi être relu comme le serait un écran de l’application : nom affiché, adresse du destinataire, objet, texte, lien et données insérées. Une capture d’écran peut révéler davantage que le corps du message, par exemple une notification de bureau ou le nom d’un compte ouvert dans un autre onglet. Avant de partager une image, masquez les informations qui ne sont pas nécessaires à la compréhension du défaut.

L’objectif est de tester la fonction sans faire circuler de données personnelles authentiques. Si le besoin métier impose l’emploi de données réelles, suspendez l’approche improvisée et faites valider le jeu de données, les accès, le canal de transmission et les règles de conservation par les personnes responsables dans votre organisation.

Pendant le débogage, limitez les traces et les captures

Les journaux sont utiles lorsqu’ils permettent de retrouver une erreur précise. Ils deviennent un risque supplémentaire lorsqu’ils stockent les courriels complets, les codes, les jetons ou des informations de compte sans nécessité. La recommandation de l’OWASP est de maîtriser les informations consignées et de ne pas journaliser des données sensibles telles que des secrets d’authentification ou des données personnelles sensibles (guide OWASP sur la journalisation).

Pour diagnostiquer un envoi, conservez les éléments qui expliquent le résultat : type d’événement, statut, environnement et identifiant technique de corrélation si votre application en utilise un. Évitez d’enregistrer le jeton complet, le corps intégral du message ou une adresse personnelle lorsque ces éléments ne sont pas indispensables. Si un défaut ne peut être reproduit sans consulter une donnée sensible, définissez qui peut y accéder et comment le résultat sera retiré après la résolution.

L’OWASP propose également des recommandations sur la validation et la vérification des adresses électroniques, utiles pour concevoir des parcours qui vérifient une adresse sans en faire un contenu de journal inutile (guide OWASP sur la validation et la vérification des courriels). Ne confondez pas validation de format, preuve de contrôle de la boîte et autorisation d’envoyer un message : ces contrôles répondent à des questions différentes.

Sur un espace partagé, appliquez les mêmes précautions aux outils de suivi d’erreurs, aux conversations d’équipe et aux enregistrements d’écran. Une capture faite pendant un test audio ou vidéo peut montrer une boîte de réception, une notification ou un onglet avec une adresse. Pour une présentation de design ou une vidéo produit, préparez une session dédiée avec des données fictives, fermez les fenêtres personnelles et vérifiez l’image finale avant diffusion.

Avant la présentation publique, faites relire le comportement généré

Le code qui s’exécute n’est pas automatiquement sûr pour les données. Une instruction de génération peut avoir produit un destinataire par défaut, laissé un paramètre de production dans une configuration ou traité un échec d’envoi de façon inattendue. Lisez le code et comparez-le à la configuration réelle ; ne vous contentez pas du commentaire explicatif fourni par l’assistant.

Vérifiez en particulier :

• les destinataires par défaut, les copies et les listes de diffusion ;
• les identifiants, les variables d’environnement et les paramètres de production ;
• l’activation de l’envoi dans l’environnement utilisé pour la présentation ;
• le domaine des liens de validation et de récupération ;
• les branches d’erreur, les tentatives répétées et les tâches mises en attente ;
• les journaux, rapports d’erreur et captures qui pourraient conserver une adresse ou un jeton.

Comment vérifier avant une présentation que les messages ne partiront pas vers de vrais utilisateurs ?

Partez de la configuration active, puis suivez le message jusqu’à sa destination. Confirmez le destinataire final, pas seulement l’adresse visible dans le formulaire. Contrôlez les copies, les destinataires ajoutés par le serveur, les files d’attente et les tâches de relance. Enfin, faites un essai avec une adresse de test que vous maîtrisez et examinez les traces produites. Si vous ne pouvez pas confirmer le trajet complet, ne présentez pas la fonction d’envoi comme vérifiée.

Avant de poursuivre, utilisez cette liste de décision. Cochez chaque point après l’avoir contrôlé dans l’environnement réellement lancé :

• [ ] Les données du scénario sont synthétiques et ne proviennent pas d’un compte réel.
• [ ] Les variables actives ne contiennent pas d’identifiants ni de destinataires de production.
• [ ] Le destinataire final, les copies et les files d’attente sont connus et réservés aux tests.
• [ ] Les liens du message utilisent le domaine de l’environnement de démo.
• [ ] Les essais de réussite, d’échec et de nouvelle tentative n’envoient rien à un utilisateur réel.
• [ ] Les journaux et les captures ne conservent pas de codes ou de jetons inutiles.
• [ ] Une personne responsable a vérifié le parcours et consigné le résultat.

Décision : si toutes les cases sont confirmées, vous pouvez poursuivre la recette dans le périmètre prévu. Si une case reste vide ou incertaine, désactivez l’envoi externe, corrigez le point concerné et recommencez le contrôle. Cette liste ne remplace pas la revue de sécurité ou les règles internes de votre organisation ; elle évite de présenter comme validé un trajet de courriel que personne n’a réellement vérifié.

Un outil d’IA peut aider à repérer des valeurs suspectes dans le code, mais sa réponse ne valide ni vos secrets ni les paramètres injectés au lancement. Les recommandations OWASP sur les risques liés aux applications LLM justifient une revue des données et des sorties ; la décision de diffuser la démo doit s’appuyer sur vos propres vérifications de configuration et de comportement.

Après la démonstration, nettoyez et consignez la vérification

La fin d’une présentation n’efface pas automatiquement les comptes, les messages capturés et les traces de débogage. Désignez un responsable du nettoyage avant la démo, puis définissez le déclencheur qui lance cette tâche : fin de présentation, fermeture de l’environnement ou retrait d’un jeu de test partagé. Choisissez les durées de conservation selon les règles de votre organisation ; n’appliquez pas un délai improvisé comme s’il s’agissait d’une obligation générale.

Le nettoyage doit couvrir les comptes de démonstration, les boîtes de réception utilisées pour les essais, les codes ou liens conservés, les journaux temporaires, les captures et les copies de données de test. Vérifiez également les espaces collaboratifs où un extrait de message aurait pu être repris. Si un élément doit être gardé pour expliquer un défaut, conservez uniquement ce qui est nécessaire, avec un accès approprié et une raison documentée.

Après suppression, consignez le résultat : responsable, environnement concerné, catégories de données examinées et éléments restant à traiter. Cette trace permet à l’équipe de repérer un nettoyage incomplet et de répéter la vérification lors d’une prochaine présentation. Elle ne remplace pas une politique interne de conservation, mais rend l’action vérifiable.

Pour intégrer cette démarche à votre recette, ajoutez un contrôle de diagnostic des problèmes de réception. Distinguer une erreur de livraison d’un problème de destinataire évite de résoudre un défaut technique en réutilisant une boîte personnelle. Si votre scénario consiste seulement à créer un compte de test, essayer une inscription ou recevoir un code pour votre propre produit, une boîte temporaire peut éviter d’exposer votre adresse principale et d’y accumuler des courriels de démonstration. TmpWay peut servir d’option pour cet usage ponctuel ; gardez une adresse durable pour les comptes importants, les services qui exigent une récupération à long terme ou les échanges nécessitant une réponse.