Le RGPD entre en application le 25 mai dans l’Union européenne. Au Québec, on pourrait facilement se dire que c’est un règlement européen et passer au prochain sprint.

Sauf que la question derrière le règlement est très concrète pour une équipe TI : est-ce qu’on sait vraiment où circulent les renseignements personnels, et peut-on appliquer une décision à toutes leurs copies?

Les organisations visées doivent expliquer pourquoi elles recueillent une donnée, comment elle est utilisée et combien de temps elle est gardée. Une entreprise québécoise n’est pas automatiquement concernée dans tous les scénarios. Mais le réflexe de tout conserver au cas où devient quand même beaucoup plus difficile à justifier.

Suivre la donnée comme un flux

Une adresse peut entrer par un formulaire Web, être validée par une API, puis être écrite dans la base du CRM. Un traitement de nuit la copie ensuite vers l’entrepôt de données. Un employé l’exporte dans Excel et envoie le fichier par courriel. La sauvegarde prend une nouvelle copie de la base. Le trajet ressemble davantage à ceci qu’à une seule case dans un registre :

formulaire → API → CRM → export nocturne → entrepôt BI
                       ↘ fichier Excel → courriel
                       ↘ sauvegarde → copie hors site

Chaque flèche doit avoir un but, un responsable, une règle d’accès et une durée. L’inventaire technique a donc besoin de plus que le nom du système :

Élément	Exemple de question
identifiant	quelle clé permet de retrouver la même personne ici?
catégorie	adresse, paiement, comportement ou donnée sensible?
finalité	quelle opération justifie cette copie?
transfert	quel service reçoit ensuite la donnée?
accès	quel groupe peut la lire ou l’exporter?
rétention	quel événement démarre le délai de suppression?
preuve	quel journal montre la lecture, la correction ou l’effacement?

Le choix de l’identifiant est déjà un problème d’architecture. Le CRM connaît client_id=1842, le site utilise une adresse courriel et le système comptable garde un numéro de compte. Une demande au nom de Simon Tétreault ne peut pas devenir trois recherches manuelles imprécises. Il faut une correspondance maîtrisée entre les identités, sans créer pour autant une énorme table accessible à tout le monde.

Exécuter une demande sans effacer la mauvaise personne

Une demande d’accès, de correction ou d’effacement devrait suivre une séquence qu’on peut tester :

1. recevoir la demande dans un canal contrôlé et lui donner un identifiant de suivi;
2. confirmer l’identité avec une preuve proportionnée au risque, sans recueillir plus d’information que nécessaire;
3. résoudre les identifiants utilisés par les systèmes concernés;
4. demander à chaque système d’extraire, corriger ou marquer les données visées;
5. traiter séparément les éléments qu’une obligation impose de conserver;
6. vérifier les résultats, consigner qui a fait quoi et répondre par un canal sûr.

Je séparerais la décision de l’exécution. Une personne autorisée confirme la portée de la demande; des connecteurs appliquent ensuite des actions précises. Une commande générique du genre DELETE FROM Clients WHERE email = ... peut enlever le mauvais dossier, briser des relations comptables ou laisser toutes les copies secondaires intactes.

La suppression physique n’est d’ailleurs pas toujours la première opération. Un système transactionnel peut devoir anonymiser certaines colonnes, bloquer l’usage marketing et conserver une facture pour une durée légale. La règle doit être exprimée par catégorie de donnée et par finalité, pas avec un seul bouton « oublier » branché partout.

Les exports et les sauvegardes compliquent la reprise

Un export Excel contourne facilement les permissions fines de l’application. Une fois le fichier sur un poste, l’accès dépend du disque, du partage réseau et du courriel. Je veux donc limiter qui peut exporter, marquer le fichier, chiffrer son transfert, lui donner une date d’expiration et journaliser sa création. Si tout dépend de la mémoire de la personne, le cycle de vie n’est pas contrôlé.

Les sauvegardes posent un autre problème. Modifier chaque bande ou image historique peut rendre la restauration inutilisable. Une approche réaliste garde la sauvegarde protégée et hors des usages courants, laisse sa rétention expirer, puis réapplique les demandes d’effacement si une ancienne copie doit être restaurée. Ça exige un registre séparé et un test de reprise; sinon, une restauration peut ressusciter des données déjà retirées des systèmes actifs.

Les pannes à prévoir ne sont pas juste techniques. Un connecteur peut répondre en erreur, un système peut être hors ligne, deux personnes peuvent partager une adresse courriel ou une demande frauduleuse peut viser le dossier de quelqu’un d’autre. Le workflow doit pouvoir s’arrêter, reprendre sans doubler les actions et montrer quels systèmes restent à traiter.

La conformité ne peut donc pas rester un document juridique. Pour un vrai projet, je prendrais une personne fictive, suivrais son identifiant dans chaque copie, exécuterais une correction complète et testerais ensuite une restauration de sauvegarde. Si on ne peut pas expliquer le résultat sans une longue chaîne de courriels, le flux de données n’est pas encore sous contrôle.