Exactitude des données RGPD : corriger à la source
Données inexactes, historique, rectification et limitation : une procédure pour corriger les erreurs et éviter leur retour dans vos logiciels.
Une adresse corrigée dans le CRM peut rester fausse dans le logiciel de facturation. Une fusion de fiches peut attribuer la dette d’un client à un autre. Le principe d’exactitude impose de traiter ces erreurs à l’échelle du circuit de données, en tenant compte de leur utilisation réelle.
Ce qu’il faut retenir
L’Art. 5(1)(d) exige des données exactes et, si nécessaire, à jour. Les mesures raisonnables de correction ou d’effacement s’apprécient au regard de la finalité. Une ancienne adresse peut rester exacte dans un historique daté ; elle ne doit pas continuer à servir d’adresse actuelle. La rectification doit se propager aux usages concernés et, selon l’Art. 19, aux destinataires.
Distinguer donnée actuelle, fait passé et appréciation
Le principe d’exactitude du RGPD ne commande pas de remplacer tous les faits anciens par la situation présente. Il impose d’éviter qu’une donnée erronée serve à un traitement pour lequel cette erreur importe.
| Donnée | Question utile | Action possible |
|---|---|---|
| Adresse de livraison | Est-ce l’adresse de cette commande ? | Faire confirmer avant expédition |
| Ancienne adresse sur une facture | Décrit-elle correctement le document historique ? | Préserver l’archive et distinguer l’adresse courante |
| Montant contesté | Le calcul et le rattachement au dossier sont-ils exacts ? | Vérifier les pièces et marquer la contestation |
| Score de risque | Les entrées, la date et la nature du score sont-elles identifiables ? | Corriger les entrées et réexaminer les conséquences |
| Commentaire libre | S’agit-il d’un fait vérifiable ou d’une appréciation attribuée ? | Corriger l’erreur factuelle, contextualiser et limiter le contenu |
Une prédiction n’est pas une certitude. Présenter un score comme un fait acquis peut induire l’utilisateur du dossier en erreur. Inversement, le désaccord avec une appréciation ne conduit pas automatiquement à la remplacer par celle demandée. Il faut examiner sa nature, ses données d’appui et la finalité du dossier.
Organiser la correction en six étapes
1. Identifier le champ et sa source. Relevez le système dans lequel l’information a été saisie, son auteur ou son origine, sa date et les logiciels qui la recopient. Le registre des traitements aide à repérer les usages, mais ne remplace pas la cartographie des synchronisations.
2. Évaluer les conséquences immédiates. Une erreur susceptible d’envoyer un document confidentiel à un tiers appelle une action rapide. Évitez d’attendre la fin d’une campagne mensuelle de nettoyage pour corriger une donnée déjà reconnue fausse.
3. Vérifier avec des éléments proportionnés. Un justificatif pertinent peut être nécessaire pour une donnée déterminante. Une pièce d’identité complète n’est pas le contrôle par défaut de chaque correction. La vérification ne doit pas devenir une nouvelle collecte excessive.
4. Corriger le système de référence. Inscrire la bonne valeur dans une copie locale ne suffit pas si une synchronisation nocturne remet l’erreur. Définissez quel outil fait autorité pour chaque donnée.
5. Traiter les copies et destinataires. Corrigez les systèmes concernés, transmettez les instructions utiles aux sous-traitants et appliquez l’Art. 19 aux destinataires. L’exception d’impossibilité ou d’efforts disproportionnés doit être appréciée et documentée, pas invoquée par défaut.
6. Vérifier le résultat. Contrôlez après la synchronisation suivante que l’erreur n’est pas revenue. Conservez une trace limitée : objet de la demande, vérification, décision, date et systèmes traités. Ne créez pas un historique détaillé sans durée de conservation.
Répondre à une demande de rectification
L’Art. 16 permet d’obtenir la correction de données inexactes et, selon la finalité, de compléter des données incomplètes. L’Art. 12(3) impose une réponse sans retard excessif et au plus tard sous un mois ; une prolongation de deux mois est possible si elle est nécessaire au regard de la complexité et du nombre de demandes. Elle doit être motivée et annoncée dans le premier mois. Ces règles figurent dans le chapitre III du RGPD.
Une demande telle que « mon numéro de compte est faux » doit être instruite même si elle ne cite pas le RGPD. La procédure du droit de rectification doit pouvoir être déclenchée par le support, la comptabilité ou une agence.
Lorsque l’exactitude est contestée, la personne dispose du droit d’obtenir une limitation pendant les vérifications, selon l’Art. 18(1)(a). Cela ne signifie pas qu’une contestation annule automatiquement une dette ou suspend toute activité de l’entreprise. Il faut identifier le traitement limité et appliquer ses règles d’utilisation. Notre guide sur la limitation du traitement détaille cette distinction.
Prévenir le retour des erreurs
Attribuez un responsable métier aux champs qui ont des conséquences fortes : adresse d’envoi, identité, coordonnées bancaires, droits à une prestation. Ajoutez un contrôle avant les opérations difficiles à réparer, par exemple une transmission à un tiers ou une décision défavorable.
La fusion de doublons mérite une vérification humaine lorsque l’identité est incertaine. Deux personnes peuvent partager un nom, une adresse ou un téléphone. Un indicateur de rapprochement ne suffit pas à établir qu’il s’agit de la même personne.
L’autocorrection par l’utilisateur est utile, mais elle ne résout pas tout. Certains champs sont verrouillés pour préserver une pièce justificative ; d’autres sont alimentés par un partenaire. Prévoyez alors un canal de demande et un responsable capable d’intervenir à la source.
Enfin, ne conservez pas une base inutile dans l’espoir de la remettre à jour un jour. L’exactitude se combine avec la limitation de la conservation, sans transformer toute donnée ancienne en donnée fausse.
Cas pratique : deux clientes fusionnées par erreur
Le scénario suivant est fictif. Atelier Location loue du matériel de bricolage à des particuliers. Lors d’un contrôle des réservations, une salariée repère deux dossiers au nom de Camille Durand. Un import a fusionné les fiches sur le seul rapprochement du nom et du code postal. Le système présente désormais une cliente comme débitrice de 240 euros ; une autre salariée s’appuie sur cette indication pour lui refuser une nouvelle réservation.
La responsable, Anaïs, ne se contente pas d’effacer l’alerte visible. Elle examine les références des contrats et les coordonnées déjà disponibles. Les dossiers correspondent à deux personnes différentes : le contrat R-214 appartient à la cliente du compte C-18 ; le contrat R-397 concerne celle du compte C-73. Dans l’hypothèse, le montant encore dû concerne seulement R-397. Ces vérifications suffisent à séparer les dossiers, sans demander à chacune une copie intégrale de sa pièce d’identité.
Définir ce qui doit faire référence
L’équipe retrouve trois systèmes : l’outil de réservation, le suivi comptable et un export quotidien destiné au service clients. L’import fautif avait transféré le montant de R-397 dans la fiche C-18. La comptabilité, elle, avait conservé les deux contrats séparés. L’erreur porte donc sur l’association entre une personne et une information ; elle ne démontre pas que le montant du contrat R-397 est lui-même faux.
Anaïs fixe la règle : l’identité du client est rattachée à l’identifiant de son compte ; le solde provient du contrat qui lui est effectivement attribué. Le nom et le code postal restent des indices de recherche, sans servir seuls à fusionner des identités. La règle est documentée pour que le prochain import ne reproduise pas le rapprochement.
| Élément | Constat dans le scénario | Correction et contrôle |
|---|---|---|
| Compte C-18 | Contrat R-214 sans dette, mais alerte de 240 euros importée | Retirer le rattachement à R-397 ; vérifier l’absence d’alerte erronée |
| Compte C-73 | Véritable titulaire du contrat R-397 | Maintenir le suivi justifié de ce contrat, sans modifier son solde pour corriger l’autre fiche |
| Réservation refusée | Refus fondé sur le mauvais rattachement | Réexaminer la demande de C-18 avec les données corrigées |
| Fichier quotidien | Contient encore la ligne fusionnée | Remplacer la version utilisée par le support et neutraliser l’ancienne |
| Règle d’import | Fusion par nom et code postal | Retirer ce rapprochement automatique et contrôler les identifiants de contrat |
| Preuve de correction | Valeur centrale corrigée avant la prochaine synchronisation | Attendre le contrôle du cycle suivant pour clore techniquement |
Cette fiche conserve les références nécessaires au suivi. Elle n’implique pas de déposer les contrats complets dans un dossier partagé avec toute l’entreprise. Anaïs limite l’accès à l’équipe chargée de la correction et définit le sort de la trace de travail après résolution.
Le défaut revient au premier cycle
La première correction retire le mauvais solde de C-18. La salariée peut de nouveau préparer sa réservation. Pourtant, le lendemain, l’alerte réapparaît : la tâche quotidienne a relu un fichier intermédiaire créé avant la correction. Le rapprochement automatique a été supprimé du nouvel import, mais ce fichier ancien reste une source prioritaire pour le logiciel de réservation.
Anaïs refuse de clore l’incident de qualité. Elle fait suspendre cette alimentation, retire la version périmée du circuit actif et demande la reconstruction du fichier depuis les contrats correctement associés. La nouvelle version comporte deux lignes distinctes. L’équipe rejoue ensuite un cycle complet dans le scénario : C-18 reste sans dette et C-73 conserve uniquement le montant qui lui correspond. Elle vérifie un troisième dossier témoin pour s’assurer que la correction n’a pas supprimé toutes les alertes de solde.
La réservation de C-18 est réexaminée et le refus erroné est retiré. Cela ne garantit pas la disponibilité du matériel demandé : le service clients doit encore appliquer les conditions normales de la réservation. La correction d’une donnée ne doit pas devenir une promesse commerciale que l’organisme n’a pas vérifiée.
Traiter les conséquences, puis les autres dossiers exposés
Anaïs informe la cliente de l’erreur qui concernait son compte et de sa correction, sans lui révéler les coordonnées ni le détail du dossier de l’autre Camille. Dès la découverte, l’agence examine aussi si la fusion a provoqué une altération accidentelle résultant d’une violation de sécurité au sens de l’Art. 4(12). Une violation peut toucher l’intégrité des données sans aucune divulgation. Si cette qualification est retenue, l’agence documente l’événement et évalue les risques ainsi que les obligations de notification et d’information prévues aux Art. 33(1), Art. 33(5) et Art. 34(1). Elle recherche également d’éventuelles communications au mauvais destinataire. Toute erreur n’impose donc pas une notification automatique ; sa correction ne dispense pas d’analyser l’incident.
Enfin, elle recense les autres fusions réalisées par la même règle. Elle ne les annule pas toutes sans examen : certaines concernent réellement des doublons d’un même client. Elle priorise celles qui ont modifié une identité, un montant ou une décision de réservation. Le contrôle se termine par un relevé des dossiers examinés, des corrections et des incertitudes restantes, pas par la seule fermeture du premier signalement.
FAQ
Faut-il vérifier chaque déclaration avec une pièce officielle ?
Non. Le niveau de vérification doit être proportionné à la finalité et aux risques. Les données déclaratives ne dispensent toutefois pas d’agir lorsqu’une erreur devient manifeste.
Une ancienne information doit-elle être effacée ?
Pas nécessairement. Un historique justifié peut conserver un fait passé clairement daté. Il faut empêcher son utilisation comme information actuelle et respecter sa durée de conservation.
Faut-il prévenir tous les destinataires ?
L’Art. 19 impose de notifier la rectification à chaque destinataire concerné, sauf impossibilité ou efforts disproportionnés. Si la personne le demande, elle doit être informée de ces destinataires.
Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.
Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.