Définir où vos données peuvent aller

Distinguer deux flux de données

Le vibe coding est utile pour explorer un processus avec des données fictives. Le risque change dès que de vraies informations de l’entreprise entrent dans l’outil. Cela peut se produire avant même que l’application ait des utilisateurs.

Deux flux doivent être examinés. Le flux de développement comprend les prompts, le contexte du dépôt, les pièces jointes, les résultats des outils et les journaux de diagnostic. Le flux de l’application comprend les requêtes des utilisateurs, les bases de données, les intégrations, la télémétrie et les sauvegardes. Chaque flux peut avoir des destinataires et des contrôles différents.

Prenons une application fictive de notes de frais. Sa base de données fonctionne dans un compte cloud approuvé. Pour corriger un parseur, un développeur colle une demande réelle dans un assistant. Elle contient le nom d’un salarié, un reçu et des coordonnées bancaires. L’emplacement approuvé de la base ne donne pas l’autorisation de divulguer ces informations séparément.

Examiner le parcours complet

Dessinez le parcours avant d’ajouter des données confidentielles. À chaque étape, indiquez le service et le compte réellement utilisés. Une étiquette commerciale comme « enterprise » ne remplace pas un schéma des flux de données.

Consignez le contrat et la configuration applicables. Vérifiez les sous-traitants ultérieurs, le comportement de suppression, les conditions d’entraînement et, le cas échéant, les transferts internationaux. Demandez aux responsables de la protection des données et de la sécurité de lever les incertitudes.

Les exigences du RGPD dépendent du contexte du traitement. Les dispositions pertinentes portent notamment sur la minimisation des données, les relations avec les sous-traitants, la sécurité et l’analyse d’impact. La confidentialité de l’entreprise couvre aussi des informations qui ne sont pas des données personnelles, comme le code source ou les projets commerciaux. Lire le règlement.

Commencer avec un jeu de test fictif utile

Un exemple sûr doit conserver une structure réaliste. Remplacez les noms, les identifiants et les numéros de compte. Conservez les conditions à l’origine du défaut : un champ manquant, une date inhabituelle ou une description longue.

Ne qualifiez pas de « synthétique » une copie de données de production après avoir changé un seul nom. Les autres champs peuvent identifier une personne ou divulguer une transaction. Construisez un nouvel enregistrement à partir du schéma et de la condition qui provoque l’échec.

Gardez les identifiants secrets hors des prompts et des jeux de test. Si la tâche nécessite un secret, utilisez le mécanisme approuvé avec un accès limité. L’instruction « gardez ceci privé » n’impose pas de limite technique.

Vérifier avant d’élargir l’usage

Rédigez une courte décision sur les usages autorisés : catégories de données, configuration du service approuvée, actions permises et responsable. Prévoyez une expiration ou un événement déclencheur de réexamen. Un nouveau connecteur, un autre chemin vers le modèle ou une nouvelle configuration des journaux peut modifier cette décision.

Si des informations parviennent à un destinataire non approuvé, arrêtez toute nouvelle divulgation et suivez la procédure de gestion des incidents. Consignez ce qui a été partagé et où. Évitez de recopier les informations sensibles dans d’autres tickets ou conversations.

L’objectif concret est un usage maîtrisé. Les données fictives permettent une exploration rapide. Des périmètres de traitement vérifiés permettent de passer aux processus de l’entreprise. Ni une démonstration soignée ni une région cloud ne répondent à toutes les questions nécessaires.