Checklist de base légale du traitement pour fondateurs et responsables conformité

Les décisions sur la base légale paraissent simples jusqu'au moment où l'équipe produit veut livrer vite, où un client demande des explications ou où un audit veut comprendre pourquoi un usage précis des données était autorisé. À ce moment-là, une simple étiquette juridique ne suffit plus. Il faut une méthode répétable pour montrer la finalité, la nécessité, les owners et les preuves.

Cette checklist répond à ce besoin. Le RGPD exige une base légale pour traiter des données personnelles, et les orientations officielles du CEPD comme de l'ICO rappellent qu'il faut choisir cette base avant le traitement, l'aligner sur la finalité réelle et pouvoir la justifier ensuite. Pour une équipe SaaS, l'objectif est très concret: décider tôt, documenter clairement et éviter les reconstructions de dernière minute.

Ce que cette checklist permet d'éviter

Les difficultés viennent rarement d'un rejet de la privacy. Elles viennent plutôt de quatre lacunes:

• une finalité trop vague;
• une base unique étendue à des activités différentes;
• un workflow qui change sans revalidation;
• une équipe qui connaît le libellé mais pas le raisonnement.

On retrouve ensuite ces faiblesses dans les revues clients, le procurement, l'onboarding fournisseurs, les lancements produit et les audits internes.

La checklist

Utilisez-la pour toute activité importante: nouvelle fonctionnalité, analytics, marketing, intégration fournisseur, changement de conservation ou nouveau partage de données.

1. Décrire le traitement de façon précise

Évitez les formules vagues comme "nous traitons les données clients pour faire tourner la plateforme". Décrivez plutôt le workflow réel:

• créer et authentifier des comptes;
• envoyer des factures et relances;
• gérer les tickets support;
• mesurer l'usage produit;
• détecter des connexions suspectes;
• envoyer des campagnes promotionnelles.

2. Écrire la finalité spécifique

La base légale doit correspondre à la finalité. Demandez-vous:

• quel résultat le traitement doit soutenir;
• si cette finalité est commerciale, opérationnelle, juridique, sécurité ou produit;
• si les mêmes données servent un second usage qui mérite une analyse distincte.

3. Tester la nécessité avant de choisir la base

Pour le contrat, vérifiez si le service peut réellement être fourni sans les données en question. Pour l'obligation légale, identifiez le texte qui impose le traitement. Pour l'intérêt légitime, clarifiez l'intérêt poursuivi, la nécessité du traitement et ce qu'une personne concernée peut raisonnablement attendre. Pour le consentement, assurez-vous qu'il y a un vrai choix et un retrait simple.

4. Vérifier si des données sensibles modifient l'analyse

Une base de l'article 6 ne suffit pas si le workflow inclut des données de santé, des données biométriques d'identification, des opinions politiques, des convictions religieuses ou d'autres catégories particulières. Il faut alors aussi vérifier les conditions additionnelles de l'article 9.

5. Consigner le raisonnement dans une courte fiche de décision

Pas besoin d'un mémo long. Une fiche courte suffit si elle contient:

• l'activité de traitement;
• la finalité;
• la base légale retenue;
• la raison pour laquelle elle convient;
• les systèmes ou vendors concernés;
• l'owner de décision;
• les limites et garde-fous;
• les triggers de re-review.

6. Vérifier que le workflow réel correspond à la décision

Un bon enregistrement sert peu si l'opérationnel fonctionne autrement.

Vérifiez notamment:

• si le consentement peut être refusé et retiré facilement;
• si, en base contrat, seules les données nécessaires sont collectées;
• si les obligations légales sont bien reliées aux règles de conservation ou disclosure;
• si les hypothèses sur l'intérêt légitime et les safeguards restent vraies.

7. Aligner notices, formulaires et messages externes

La décision interne et l'explication externe ne devraient pas diverger. Privacy notice, formulaires, écrans produit et discours commercial doivent raconter la même chose.

8. Nommer un owner de maintenance, pas seulement d'approbation

Chaque décision importante devrait avoir:

• un owner pour la logique de décision;
• un owner pour s'assurer que le workflow continue de respecter cette logique.

9. Définir des déclencheurs de nouvelle revue

Revenez sur la décision quand:

• la finalité change;
• un nouveau vendor ou sous-traitant arrive;
• le périmètre des données augmente;
• un nouveau marché ou segment change les attentes;
• des données sensibles apparaissent;
• les règles de conservation ou de partage évoluent nettement.

10. Conserver des preuves légères et retrouvables

Les preuves utiles ressemblent souvent à:

• un registre des traitements avec une finalité et une base significatives;
• de courtes traces de décision pour les cas plus risqués;
• des formulaires ou tickets qui posent les bonnes questions;
• des captures ou logs sur le consentement, le disclosure, la conservation ou les contrôles.

Un déploiement simple en 30 jours

Semaine 1: choisir les workflows prioritaires

Commencez par cinq à dix traitements qui créent déjà de la pression: comptes, billing, support, analytics, sécurité ou marketing.

Semaine 2: documenter finalité et base

Créez une petite fiche de décision par workflow.

Semaine 3: comparer documentation et réalité

Vérifiez si les formulaires, notices, comportements produit, vendors et règles de conservation correspondent à la décision documentée.

Semaine 4: fixer owners et triggers

Attribuez les responsabilités, choisissez l'emplacement de la fiche et définissez les triggers de re-review.

Erreurs fréquentes

Utiliser le contrat comme réponse générale

Le contrat peut couvrir la fourniture du service, pas tous les usages voisins.

Considérer le consentement comme l'option la plus sûre

Il ne l'est pas si la personne n'a pas de vrai choix.

Cacher plusieurs finalités dans une seule réponse

Une nouvelle finalité nécessite souvent une nouvelle analyse.

Documenter l'étiquette mais pas la limite

L'équipe doit savoir dans quelles conditions la base reste défendable.

Laisser la décision dans un document que personne n'utilise

Si produit, procurement ou sécurité ne peuvent pas s'en servir au quotidien, la checklist n'est pas encore opérationnelle.