Minimisation des données : méthode et grille RGPD

Un formulaire peut sembler sobre et alimenter malgré tout des exports trop complets, des journaux indiscrets ou des copies de test inutiles. La minimisation consiste à ajuster les données et leur utilisation à chaque objectif réel, pendant toute la vie du traitement.

Ce qu’impose la minimisation

L’Art. 5(1)(c) du RGPD exige des données adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités. L’Art. 25(2) applique cette exigence par défaut à la quantité collectée, à l’étendue du traitement, à la conservation et à l’accessibilité. Sources : Art. 5(1)(c) et Art. 25(2).

L’examen dépend donc du service et de la fonction de chaque information. Demander une adresse postale pour une livraison peut être nécessaire ; la demander pour envoyer uniquement une réponse électronique exige une autre justification. Une facture ou une obligation sectorielle peut, dans une situation donnée, créer un besoin distinct.

Commencez par le principe de finalité : on ne peut pas juger la nécessité d’un champ sans savoir quelle opération il permet d’accomplir. Une donnée simplement disponible ou intéressante ne suffit pas à justifier sa collecte.

Obligatoire ou facultatif : deux contrôles différents

Un champ obligatoire doit être justifié au regard de ce qui est demandé à la personne. Le rendre facultatif ne régularise pas une collecte sans finalité légitime, sans base légale ou excessive. Inversement, toute donnée facultative n’est pas interdite : un numéro fourni pour un rappel effectivement demandé peut répondre à une finalité précise, même si le service principal fonctionne par courriel.

La CNIL recommande d’examiner la pertinence des données, de distinguer les champs obligatoires et facultatifs et d’encadrer les commentaires libres. Le contrôle doit donc porter sur le formulaire, mais également sur ce que les équipes écrivent dans les zones non structurées.

Cas pratique : organiser une intervention à domicile

Exemple hypothétique. Une PME d’entretien de chauffage reçoit les demandes de rendez-vous sur son site. Son formulaire historique demande un nom, une adresse, une date de naissance, la profession, un courriel, un téléphone, une description libre et une photographie. Le logiciel reporte ensuite tous ces champs sur la fiche du technicien et dans l’export comptable.

La finalité examinée est précise : qualifier la demande et organiser l’intervention demandée par le client. La dirigeante et la responsable du planning reprennent chaque donnée avec le technicien et la comptable. Elles ne cherchent pas à remplir le fichier le plus complet possible ; elles déterminent ce qui manque réellement à chacun pour effectuer son travail.

La grille renseignée avant modification

Cette grille est une décision propre à ce service, pas une liste universelle de champs autorisés. Une autre activité peut avoir un besoin justifié de connaître un âge ou une profession. Elle doit expliquer ce besoin et choisir le niveau de précision adéquat. Ici, aucune fonction du rendez-vous ne justifie ces deux informations.

La zone libre devient une description technique accompagnée d’une consigne courte : « Indiquez le modèle et le problème observé ; ne joignez pas de pièce d’identité ni d’information privée sans rapport avec l’appareil. » L’entreprise conserve cette zone parce qu’une liste de pannes prédéfinies ne couvre pas tous les cas. Elle donne au planning une consigne de tri pour les informations excessives reçues malgré l’avertissement.

La photographie ne devient pas obligatoire par commodité du technicien : la saisie de la référence constitue une solution moins intrusive pour les clients qui la connaissent. Le personnel ne demande pas une nouvelle photographie de la pièce entière lorsque l’étiquette suffit. Le choix des données, leur précision et leur mode de collecte se décident ensemble.

Appliquer la décision au logiciel et aux équipes

La dirigeante valide le périmètre ; le prestataire informatique modifie les formulaires, le stockage et les exports selon ses instructions. La responsable du planning vérifie ensuite le parcours avec des demandes fictives. Elle contrôle le résultat reçu par le planning, la fiche du technicien, la confirmation envoyée au client et le fichier transmis à la comptabilité.

Le code d’entrée ne figure plus sur la facture ni dans le tableau général des interventions. Il reste accessible au planning chargé du rendez-vous et au technicien affecté lorsque cette information est nécessaire. Si le client annule, le besoin d’accès disparaît : l’équipe retire le code du dossier opérationnel. Elle conserve seulement les éléments encore justifiés par la gestion de l’annulation.

La preuve de cette mise en œuvre comprend la grille approuvée, les consignes, la liste des écrans et sorties vérifiés et les résultats observés. Elle ne contient pas de vrais codes d’entrée pour démontrer que le champ existe. Un exemple fictif suffit à documenter le fonctionnement prévu.

Le formulaire est corrigé, mais le journal reçoit tout

Dans le scénario, la responsable constate une anomalie : les champs de date de naissance et de profession ont disparu à l’écran, mais un ancien parcours les envoie encore au serveur. Le journal technique enregistre la demande complète. La modification visuelle n’a donc pas réalisé la minimisation décidée.

L’équipe bloque ce parcours ancien, corrige les données acceptées par l’application et filtre les informations inscrites dans le journal. Elle rejoue ensuite une demande depuis chaque point d’entrée connu, y compris le lien conservé dans un ancien courriel. La reprise est autorisée lorsque les champs supprimés ne sont plus collectés par ces parcours et que les sorties utiles restent fonctionnelles.

Les copies antérieures sont traitées séparément. Le responsable identifie les formulaires enregistrés, exports et journaux concernés, puis supprime ce qui ne répond plus à un besoin licite. Si une conservation distincte est justifiée, elle est limitée à son périmètre et à ses accès. Modifier l’écran aujourd’hui ne permet pas de déclarer que toutes les données historiques ont disparu.

Si le prestataire ne peut pas corriger rapidement le flux, l’entreprise maintient le parcours défectueux fermé et prend les rendez-vous par un canal évalué, avec les seuls renseignements nécessaires. Elle évite de recréer en urgence un tableur contenant les mêmes champs excessifs. Le responsable suit l’écart jusqu’à sa correction et conserve le résultat du nouveau contrôle.

Réduire les données dans les usages secondaires

Les règles ne s’arrêtent pas à l’écran de collecte. Une application peut limiter l’accès courant, puis donner à tous les utilisateurs un bouton d’export intégral. Contrôlez les colonnes exportées, les destinataires et le devenir des copies. Le guide des exports Excel contenant des données personnelles détaille ce point.

Pour la maintenance, choisissez un jeu adapté au problème plutôt que de recopier systématiquement toute la production. La méthode sur les données de production en environnement de test examine les jeux fictifs, la réduction du périmètre et les conditions d’un recours exceptionnel aux données réelles.

Un outil d’extraction documentaire peut également traiter plus d’informations que celles dont le métier a besoin. Comparez le document source, les champs extraits et les copies produites avec la fiche sur la minimisation des données issues d’un OCR.

Conservation, sécurité et anonymisation restent distinctes

La minimisation aide à réduire les données exposées, mais ne remplace pas la sécurité. Un petit fichier peut contenir des informations très sensibles. Une restriction d’accès ne rend pas nécessaire une donnée qui ne l’était pas.

La durée relève aussi de l’Art. 5(1)(e) : supprimez ou anonymisez réellement les informations qui ne doivent plus être conservées, sous réserve d’une obligation ou d’un autre besoin licite justifié. Une pseudonymisation conserve un risque d’attribution et ne doit pas être présentée comme une disparition automatique des données personnelles. Les accès, la durée et le risque de réidentification doivent rester examinés.

Pour un projet d’IA, justifier le périmètre

Le principe ne fixe pas un nombre maximal universel de lignes d’entraînement. La CNIL explique son application à la conception des systèmes d’IA en tenant compte notamment de la pertinence des données et des connaissances disponibles. Documentez les catégories retenues, l’utilité attendue et les solutions moins intrusives effectivement étudiées.

Une AIPD est obligatoire si le traitement est susceptible d’engendrer un risque élevé, notamment selon l’Art. 35(1), et dans les cas qui la rendent obligatoire. Le seul mot « IA » ne remplace pas cette qualification. La minimisation doit être examinée même lorsque l’AIPD n’est pas obligatoire.

Ce qu’il faut retenir

• Justifiez chaque catégorie de données par une finalité déterminée.
• Distinguez nécessité de la collecte et caractère obligatoire d’un champ.
• Contrôlez aussi les accès, exports, journaux et environnements de test.
• Conservez le raisonnement et vérifiez que les réglages réels lui correspondent.

FAQ

Le consentement autorise-t-il une collecte excessive ?

Non. Une base légale valable ne dispense pas du respect des principes de l’Art. 5(1), dont la minimisation.

Faut-il toujours collecter moins de données ?

Il faut collecter et traiter ce qui est nécessaire à la finalité. Une donnée insuffisante ou imprécise peut également empêcher un traitement adéquat ; l’objectif est un périmètre justifié, pas une quantité minimale abstraite.

Comment démontrer la démarche ?

Reliez les catégories de données à leurs usages, conservez les arbitrages et contrôlez les paramètres en production. L’Art. 5(2) impose de pouvoir démontrer le respect des principes ; une grille remplie sans application ne suffit pas.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.