Conformité RGPD technique : contrôles essentiels

La conformité RGPD technique se prouve dans les systèmes : accès, données, sauvegardes, sous-traitants et procédures de production documentées utiles.

Un formulaire de contact envoyé par e-mail, une base clients copiée dans un export CSV, un compte administrateur partagé entre prestataires : la conformité RGPD technique se joue rarement dans une grande décision d'architecture. Elle se perd plus souvent dans ces détails de production que personne ne possède vraiment.

Pour une TPE ou une PME, le sujet n'est pas de construire une forteresse théorique. Il faut savoir quelles données personnelles circulent, qui peut les voir, où elles restent, comment elles sont restaurées et ce qui se passe lorsqu'un client demande leur suppression. Le reste dépend de votre activité, de vos contrats et de votre niveau de risque.

La conformité RGPD technique n'est pas un document

Un registre de traitements, une politique de confidentialité et des contrats de sous-traitance sont nécessaires. Ils ne rendent pas un système conforme à eux seuls. Si votre application conserve des comptes supprimés dans une base secondaire, si les journaux exposent des adresses e-mail, ou si une sauvegarde est accessible avec le mot de passe d'un ancien salarié, la documentation ne corrige rien.

La partie technique du RGPD traduit des principes juridiques en contrôles opérationnels. Minimisation, confidentialité, intégrité, limitation de conservation et capacité à répondre aux droits des personnes doivent exister dans le code, l'infrastructure et les procédures d'exploitation.

Ce point compte particulièrement pour les entreprises qui ont fait évoluer leur produit par couches successives. Une boutique en ligne connectée à plusieurs outils marketing, un SaaS avec des intégrations tierces ou une application métier développée sur plusieurs années accumulent des flux de données difficiles à voir. Avant de modifier quoi que ce soit, il faut les cartographier.

Commencer par suivre les données, pas par acheter un outil

La première question utile est simple : quelles données personnelles entrent dans le système et pourquoi ? Nom, e-mail, téléphone, adresse IP, identifiant de compte, historique de commande, fichier envoyé par un utilisateur, enregistrement d'appel ou donnée RH n'ont pas tous le même niveau de sensibilité, mais ils doivent tous avoir une raison d'être.

Suivez ensuite leur parcours réel. Une donnée peut être saisie dans un formulaire, stockée dans une base applicative, répliquée vers un CRM, envoyée à une plateforme d'e-mailing, écrite dans des logs et incluse dans des sauvegardes. Le schéma utile n'est pas celui présenté lors de la conception. C'est celui que produit l'environnement en service.

Cette cartographie permet de prendre des décisions concrètes. Certaines données peuvent être supprimées. D'autres peuvent être pseudonymisées dans les environnements de test. Certaines intégrations doivent être reconfigurées, car elles reçoivent plus d'informations que nécessaire. Dans beaucoup de cas, réduire le volume collecté diminue aussi le coût de maintenance et le risque d'incident.

Les environnements de test sont souvent le vrai problème

Copier la base de production vers un serveur de recette est une habitude courante et dangereuse. Elle est parfois justifiée pour reproduire un bug complexe, mais elle ne doit pas devenir le mode normal de travail.

Préférez des jeux de données synthétiques ou anonymisés. Si une copie de production est indispensable, limitez son accès, chiffrez-la, fixez une date de suppression et documentez l'exception. Un serveur de test moins surveillé qu'une production ne doit pas devenir une seconde production pleine de données clients.

Contrôler les accès avant de parler chiffrement

Le chiffrement est utile, mais il ne compense pas une mauvaise gestion des identités. Un utilisateur qui possède des droits excessifs peut consulter ou exporter les données sans casser aucun chiffrement. Dans une petite structure, les privilèges s'accumulent vite : ancien prestataire, compte mutualisé, clé API intégrée dans un script, accès SSH conservé pour dépanner.

Chaque accès doit être attribuable à une personne ou à un service. Les comptes partagés sont à éliminer dès que possible. Les accès administrateur doivent être limités, protégés par une authentification forte et revus périodiquement. Lorsqu'un collaborateur ou un prestataire quitte le projet, la révocation fait partie de la sortie, pas d'une tâche à traiter plus tard.

Il faut aussi séparer les rôles. Une personne chargée du support n'a pas nécessairement besoin d'accéder à toute la base de données. Un développeur peut avoir besoin des logs d'une application sans détenir les clés de l'infrastructure. Ce découpage a un coût d'organisation. Il ralentit légèrement certaines interventions au début, mais évite que le dépannage quotidien repose sur des droits permanents et trop larges.

Sécuriser les flux et les secrets

Les données personnelles en transit doivent utiliser des connexions chiffrées correctement configurées. Cela concerne le site public, les API, les accès d'administration, les échanges entre services et les outils internes. Un certificat valide ne suffit pas si une API accepte encore des protocoles obsolètes ou si des données sont envoyées dans une URL, puis conservées par des proxys et des outils d'analyse.

Les secrets méritent un contrôle distinct : mots de passe de base de données, tokens API, clés de chiffrement, identifiants SMTP et certificats. Ils ne doivent pas vivre dans le dépôt Git, dans un ticket de support ou dans un fichier de configuration partagé sans protection. Une solution de gestion des secrets adaptée à votre taille est préférable à un fichier texte baptisé \production-final-v2.txt\.

La rotation des secrets est souvent négligée parce qu'elle peut provoquer une interruption. C'est précisément pourquoi elle doit être préparée, testée et documentée. Une clé qui ne peut pas être remplacée sans stress est une dette opérationnelle.

Conservation, suppression et sauvegardes : le test de réalité

La suppression est le point où les déclarations générales rencontrent le système réel. Supprimer un compte dans l'interface ne signifie pas forcément effacer les données associées dans les tables de paiement, les exports, les index de recherche, les outils tiers ou les sauvegardes.

Il faut définir des règles de conservation par catégorie de données, en cohérence avec vos obligations métier et comptables. Ensuite, il faut les implémenter : tâches planifiées, archivage contrôlé, suppression automatisée, purges de journaux et procédures pour les demandes exceptionnelles. Une règle qui dépend d'un rappel manuel n'est pas une règle fiable.

Les sauvegardes demandent une nuance. Vous n'allez pas réécrire toutes les archives à chaque demande de suppression. En pratique, il faut protéger les sauvegardes, limiter leur durée de rétention et s'assurer que les données effacées ne réapparaissent pas lors d'une restauration. Une restauration doit être suivie d'un mécanisme de remise en conformité, ou la sauvegarde doit expirer selon un cycle connu.

Surtout, testez la restauration. Une sauvegarde non restaurée est une hypothèse, pas une protection. Ce test vérifie à la fois la disponibilité du système, la qualité des procédures et l'exposition des données pendant l'opération.

Journaux, supervision et gestion des incidents

Les logs sont essentiels pour exploiter un système, diagnostiquer une erreur ou enquêter sur un incident. Ils deviennent un problème lorsqu'ils enregistrent des mots de passe, des tokens, des pièces jointes, le contenu complet de requêtes ou des données clients sans nécessité.

Définissez ce qui peut être journalisé, masquez les champs sensibles et fixez une durée de conservation. Les droits d'accès aux outils de supervision comptent autant que ceux de l'application elle-même. Un tableau de bord d'erreurs peut contenir des adresses e-mail, des identifiants et des traces métier très détaillées.

En cas de violation de données, les premières heures sont désordonnées. Préparez donc le minimum : qui isole le système, qui conserve les preuves, qui contacte les prestataires, qui qualifie les données concernées et qui décide de l'escalade. Le RGPD impose parfois des délais courts de notification. Vous ne pouvez pas reconstituer votre architecture au milieu d'un incident.

Évaluer les sous-traitants dans le flux réel

Un fournisseur de cloud, un outil de support, un service d'analytics, une plateforme d'IA ou un prestataire de paiement peuvent traiter des données pour votre compte. Le contrat compte, mais il faut également vérifier la configuration : régions d'hébergement, durée de conservation, comptes ayant accès aux consoles, exportations activées et données envoyées par les intégrations.

Les composants d'IA méritent une vigilance spécifique. Envoyer des tickets clients ou des documents internes à un modèle externe peut être pertinent, mais seulement si la finalité, les données transmises, les réglages de conservation et les engagements du fournisseur ont été examinés. Un prototype réalisé en urgence ne doit pas devenir un traitement permanent par oubli.

Faire de la conformité un travail d'exploitation

La bonne cadence n'est pas un chantier annuel spectaculaire. C'est une discipline d'exploitation : revue des accès, contrôle des nouveaux flux, vérification des sauvegardes, mise à jour des dépendances critiques et traitement des vulnérabilités selon leur exposition réelle.

Un audit technique sérieux commence par lire le code, les configurations de déploiement et les comptes d'infrastructure. Il produit ensuite une liste priorisée : ce qui expose immédiatement les données, ce qui doit être corrigé à court terme, puis ce qui relève d'une amélioration structurante. Rocket Services intervient dans cette logique, avec des recommandations écrites et applicables sur l'environnement existant.

Ne cherchez pas une conformité parfaite sur un diagramme. Cherchez un système dont les données sont connues, dont les accès sont maîtrisés et dont les incidents peuvent être traités sans improvisation. C'est moins spectaculaire qu'un grand programme de transformation, et beaucoup plus utile le jour où un client, un partenaire ou un problème de production vous demande des preuves.