Chapitre 16.1 — Checklists
⏱️ TL;DR — Cinq listes à cocher prêtes à l’emploi pour les décisions RGPD les plus fréquentes : lancer un nouveau traitement, répondre à une demande de droit, notifier une violation en 72 h, choisir une base légale, et intégrer un nouveau sous-traitant SaaS. Copie celle qu’il te faut dans ton ticket, ta fiche de registre ou ton canal d’incident. Aucune n’est exhaustive — elles attrapent l’essentiel et te disent vers quelle partie aller pour le détail.
Ce que tu trouveras ici
Des checklists actionnables, pas des rappels de cours. Chaque item est une question ou une action binaire (fait = OK). Quand un point mérite une explication, on renvoie vers la partie qui l’approfondit. La règle d’or : une checklist ne remplace pas le raisonnement ni la documentation — elle t’évite d’oublier l’évident et de découvrir le trou après coup.
1. Lancer un nouveau traitement
Avant d’écrire la première ligne d’une fonctionnalité qui manipule des données personnelles. C’est la checklist privacy by design (art. 25). Détail : Partie 1 (principes) et Partie 11 (documentation).
- Finalité — je peux écrire en une phrase claire pourquoi je collecte ces données (ex. « gérer les inscriptions »), et elle est déterminée, explicite et légitime. Voir Partie 1.
- Base légale — j’ai choisi une base par finalité (art. 6) avant de coder, et je peux la justifier. Voir Partie 4.
- Données sensibles / mineurs — je vérifie si le traitement touche à l’art. 9 (santé, biométrie…), à l’art. 10, ou à des moins de 15 ans (consentement parental en France). Voir Partie 5.
- Minimisation — chaque champ collecté se justifie par la finalité ; je retire tout ce qui est « au cas où ».
- Information — les mentions (art. 13) sont prêtes : qui, quoi, pourquoi, base légale, durée, droits, destinataires. Voir Partie 8.
- Durée de conservation — une durée justifiée par finalité, avec un mécanisme de purge (tâche planifiée), pas juste une intention.
- Sécurité — mesures techniques et organisationnelles adaptées au risque : chiffrement, contrôle d’accès, journaux (art. 32). Voir Partie 9.
- Sous-traitants — si un prestataire est impliqué, un DPA est prévu et la localisation des données est connue. Voir Partie 12.
- AIPD — je vérifie si une analyse d’impact (art. 35) est requise (risque élevé, données sensibles à grande échelle, suivi systématique…). Voir Partie 11.
- Registre — je crée la fiche de registre (art. 30) du traitement. Modèle en 16.2.
2. Répondre à une demande de droit
Un mail « je veux accéder à mes données / les supprimer / m’opposer » arrive. Le compteur tourne. Détail : Partie 6.
- Identifier le droit exercé — accès (art. 15), rectification (16), effacement (17), limitation (18), portabilité (20), opposition (21), ou décision automatisée (22).
- Vérifier l’identité du demandeur — sans en demander trop (pas de sur-collecte pour « prouver » l’identité) ; le doute raisonnable seul justifie une pièce.
- Lancer le délai d’un mois — la réponse est due sous 1 mois, prolongeable de 2 mois si la demande est complexe (avec information dans le premier mois).
- Délimiter le périmètre — quelles données, dans quels systèmes, y compris chez les sous-traitants ; est-on responsable ou sous-traitant de ce traitement ? (dans le second cas, on transmet au responsable).
- Cas particuliers — pour un effacement, vérifier s’il existe une obligation légale de conservation qui s’y oppose ; pour un mineur, gérer le titulaire de l’autorité parentale.
- Répondre — de façon claire, gratuitement par principe, en fournissant les données ou en motivant un refus ; tracer la demande et la réponse (accountability).
- Journaliser — la demande, sa date, la réponse et sa date sont consignées (preuve du respect du délai).
3. Notifier une violation en 72 h
Une fuite, un accès non autorisé, une perte de données est détectée. Détail : Partie 10.
- Qualifier — est-ce bien une violation (atteinte à la confidentialité, l’intégrité ou la disponibilité de données personnelles) ? Quelles données, combien de personnes, quelles conséquences possibles ?
- Évaluer le risque pour les personnes — faible, ou élevé ? C’est ce niveau qui déclenche les obligations.
- Notifier la CNIL sous 72 h — dès qu’il y a un risque pour les personnes, la notification part dans les 72 heures après la prise de connaissance (art. 33). Notification par étapes possible si tout n’est pas encore connu.
- Informer les personnes concernées — si le risque est élevé (art. 34), les prévenir dans les meilleurs délais, en langage clair, avec les mesures et les recommandations.
- Contenir & corriger — mesures immédiates (couper l’accès, réinitialiser, patcher) et actions pour limiter l’impact.
- Consigner au registre des violations — toutes les violations, y compris celles non notifiées, sont inscrites au registre interne (obligatoire même quand on ne notifie pas).
- Sous-traitant impliqué ? — s’il s’agit d’un sous-traitant, il doit alerter le responsable sans délai ; c’est le responsable qui notifie la CNIL.
4. Choisir une base légale
Une base par finalité (art. 6), choisie avant le traitement et non interchangeable après coup. Détail : Partie 4.
- Une obligation légale m’impose-t-elle ce traitement ? → base obligation légale.
- Est-il nécessaire à un contrat avec la personne (ou à des mesures précontractuelles) ? → base contrat.
- Protège-t-il un intérêt vital (vie ou intégrité d’une personne) ? → base sauvegarde des intérêts vitaux.
- Relève-t-il d’une mission d’intérêt public dont je suis investi ? → base mission d’intérêt public.
- Ai-je un intérêt légitime qui ne porte pas atteinte aux droits de la personne (test de mise en balance documenté) ? → base intérêt légitime.
- Sinon, il reste le consentement — libre, spécifique, éclairé, univoque, aussi facile à retirer qu’à donner. Voir Partie 7.
- Données sensibles (art. 9) ? — il faut en plus une exception de l’art. 9 (souvent le consentement explicite). Voir Partie 5.
- Je documente le choix (et le test d’intérêt légitime le cas échéant) dans la fiche de registre.
⚠️ Piège — Mettre « consentement » partout par réflexe. Le consentement est souvent la base la moins pratique (retirable à tout moment, à retracer). Pour la gestion d’un compte ou l’exécution d’un service, c’est le contrat ; pour la sécurité ou la mesure d’audience, souvent l’intérêt légitime. Voir Partie 4.
5. Intégrer un nouveau sous-traitant SaaS
Avant de brancher un nouvel outil (e-mailing, visio, hébergeur, analytics, modèle d’IA…) qui verra passer des données personnelles. Détail : Partie 12 et Partie 13.
- DPA signé — un contrat de sous-traitance écrit (art. 28) encadre le prestataire ; il n’agit que sur instruction documentée. Clauses en 16.2.
- Finalité & instructions — je sais exactement ce que le prestataire fait des données, et rien de plus (pas de réutilisation pour son compte, ex. entraîner un modèle).
- Localisation des données — où sont hébergées et traitées les données ? Support, sauvegardes et sous-traitants ultérieurs compris.
- Transfert hors UE ? — si oui, une garantie appropriée s’applique : adéquation (art. 45), CCT (art. 46), ou DPF pour un prestataire US certifié — et une analyse d’impact du transfert (TIA) au cas par cas. Voir Partie 13.
- Sous-traitance ultérieure — le prestataire liste ses propres sous-traitants et s’engage à m’informer de tout changement.
- Sécurité & réversibilité — mesures de sécurité vérifiées (art. 32), et sort des données prévu en fin de contrat (restitution puis suppression).
- Registre & mentions à jour — le nouveau destinataire apparaît dans la fiche de registre et, s’il y a lieu, dans les mentions d’information.
🧭 Sur FormaCampus — Ces cinq checklists sont vécues chaque trimestre : lancer la fonctionnalité « aide IA » (checklist 1 + AIPD), traiter la demande d’accès d’un parent (checklist 2), notifier une fuite de logs (checklist 3), choisir l’intérêt légitime pour la mesure d’audience (checklist 4), brancher un nouvel outil d’e-mailing hébergé aux États-Unis (checklist 5 + TIA). Elles ne remplacent pas le DPO — elles font gagner du temps avant de le solliciter.
Chapitre suivant : Modèles (registre, DPA, mentions) — les squelettes à adapter à tes vrais traitements.