Projet urgent : organiser la revue RGPD avant lancement

Le lancement est annoncé pour la semaine suivante et le DPO découvre le projet. Il faut rapidement établir ce qui sera réellement fait avec les données, puis décider quelles opérations peuvent commencer. L’urgence commerciale permet de concentrer la revue ; elle ne dispense pas de remplir les conditions applicables avant le traitement.

Le résultat attendu est une décision exploitable : périmètre examiné, conditions à satisfaire, preuves attendues et personnes chargées de les produire. Une liste de réserves sans responsable ne protège ni les personnes concernées ni l’équipe qui doit mettre le service en fonctionnement.

Réunir les faits utiles à la décision

Commencez par une démonstration du parcours, depuis l’arrivée d’une donnée jusqu’à son effacement ou son archivage. Un document commercial peut décrire une option désactivée, tandis qu’un connecteur oublié exporte déjà les données. La revue doit porter sur le fonctionnement prévu et sa configuration.

Demandez les finalités, catégories de personnes, champs collectés, destinataires, habilitations, prestataires, lieux de traitement, durées et modalités d’exercice des droits. Pour chaque réponse, distinguez le fait établi, l’engagement contractuel, le réglage annoncé et l’inconnue. Le mot « sécurisé » ne répond pas à la question de savoir qui peut télécharger le fichier.

L’Art. 25(1) impose des mesures appropriées dès la détermination des moyens et pendant le traitement. L’Art. 38(1) exige une association appropriée et en temps utile du DPO. Une revue tardive doit aussi déboucher sur une correction de l’organisation des projets suivants. Source : RGPD, Art. 25(1) et Art. 38(1).

La protection des données dès la conception et par défaut reste le cadre de travail. Dans l’urgence, elle conduit notamment à vérifier les fonctions actives par défaut, les données obligatoires et les accès créés automatiquement.

Distinguer urgence de planning et nécessité juridique

La date promise à un client ou le coût d’un report ne constitue pas une base légale. L’Art. 6(1) énumère les conditions de licéité ; la nécessité contractuelle de l’Art. 6(1)(b) ne se déduit pas du seul intérêt commercial à lancer rapidement. Il faut rattacher chaque opération à son fondement propre. Source : RGPD, Art. 6(1).

Cette distinction évite les arbitrages trompeurs. Une donnée facultative dans le logiciel peut être inutile à votre finalité. Une clause générique signée avec le fournisseur peut omettre le traitement réellement confié. Un risque déclaré « accepté par la direction » ne rend pas licite une opération sans fondement.

À l’inverse, toute amélioration souhaitable ne bloque pas nécessairement un service déjà conforme dans son périmètre. Le travail consiste à expliquer la condition applicable, le fait observé et la conséquence opérationnelle. Évitez une note globale de conformité dont personne ne sait déduire les actions nécessaires.

Classer les points selon leur effet sur le lancement

La grille suivante est une méthode proposée, sans remplacer l’analyse du projet. Elle distingue les conditions d’une opération et les améliorations qui peuvent réellement attendre.

Pour une collecte directe, l’Art. 13(1) et 13(2) situe l’information au moment où les données sont obtenues, sous les conditions du texte. Pour la sous-traitance, l’Art. 28(3) exige un contrat ou autre acte juridique encadrant le traitement. Une promesse de compléter ces documents après le lancement ne remplace pas leur effet utile. Sources : RGPD, Art. 13 et Art. 28(3).

Une inconnue majeure n’est pas une simple absence de pièce. Si les lieux et destinataires d’un flux restent indéterminés, l’équipe peut être incapable d’apprécier les garanties applicables. La procédure relative aux preuves fournisseur manquantes permet de formuler une demande ciblée et une échéance de réponse.

Réduire le périmètre sans déplacer le problème

Une réduction utile change les opérations. Elle peut retirer un champ inutile, fermer un import, supprimer un connecteur ou limiter les personnes habilitées. Elle doit être vérifiée sur les chemins réellement utilisables, y compris les interfaces techniques et les anciennes configurations.

Masquer un bouton ne prouve pas que l’opération correspondante est impossible. Si l’import reste disponible par une autre interface ou une tâche planifiée, la réduction annoncée ne décrit pas le périmètre réel. Demandez au responsable technique comment le résultat sera démontré.

Limiter le nombre d’utilisateurs ne suffit pas non plus à régler une absence de base légale ou une collecte excessive. Le pilote SaaS contenant des données personnelles demeure un traitement soumis aux règles applicables. Une démonstration avec des données réellement fictives peut, en revanche, permettre de travailler sur l’outil pendant que les conditions d’un usage réel sont établies.

Vérifiez également ce que le changement laisse derrière lui : fichiers déjà importés, copies de travail, invitations et droits d’accès. Une fonction désactivée aujourd’hui ne supprime pas automatiquement les données collectées hier. Le traitement de ces éléments doit figurer dans la décision.

Une décision renseignée pour un projet fictif

La société fictive Rive prépare un portail de prise de rendez-vous. La première version prévoit nom, coordonnées, créneau et dépôt facultatif d’une pièce libre. Le chef de projet annonce une ouverture le 8 octobre 2026. La revue du 5 octobre constate que l’utilité des pièces libres n’est pas établie et que leur accès n’a pas été correctement défini.

Dans cette hypothèse, l’équipe choisit de retirer entièrement cette fonction de la version initiale. Elle examine séparément la finalité, le fondement, l’information, le fournisseur, la sécurité, la conservation et les droits pour la prise de rendez-vous restante. Le retrait d’un champ ne vaut donc pas approbation automatique du reste.

La décision préparée peut prendre la forme suivante :

Cette fiche est un exemple de décision conditionnelle, pas une autorisation constatée. Si la vérification révèle que des fichiers restent acceptés, la condition n’est pas satisfaite. Si les autres opérations ne sont pas suffisamment établies, leur lancement reste également à revoir.

L’équipe ne doit pas transformer le 8 octobre en conclusion obligatoire. Elle peut maintenir une démonstration fictive, ouvrir un périmètre réellement conforme ou reporter les opérations concernées. La réponse dépend des faits et des preuves obtenues.

Ne pas reporter une AIPD requise

L’Art. 35(1) exige une analyse d’impact avant un traitement susceptible d’engendrer un risque élevé. La décision doit considérer la nature, la portée, le contexte et les finalités, ainsi que les cas et listes applicables. « Seulement dix utilisateurs » ou « uniquement pendant quinze jours » n’est pas une dispense universelle. Source : RGPD, Art. 35(1) à 35(5).

Les lignes directrices WP248 rev.01 expliquent que l’actualisation ultérieure de l’AIPD ne justifie pas de différer l’analyse initiale. Le document peut évoluer avec le projet ; les travaux nécessaires doivent néanmoins précéder le traitement concerné. Source : lignes directrices AIPD, section III.D.a, pages 16–17 du PDF.

Si l’analyse laisse apparaître un risque élevé résiduel dans les conditions de l’Art. 36(1), la consultation préalable de l’autorité doit être examinée et réalisée lorsqu’elle s’impose. Une signature interne ne remplace pas cette démarche. Le calendrier doit intégrer les contraintes qui en résultent. Source : RGPD, Art. 36.

Conservez le raisonnement ayant conduit à exiger ou non l’AIPD. Une case vide ou la seule mention « risque faible » ne permet pas de comprendre les données et opérations évaluées. Si le périmètre change, réexaminez cette conclusion.

Séparer l’avis du DPO et la décision de l’organisme

Le DPO informe, conseille et contrôle dans le cadre de l’Art. 39(1). Le responsable de traitement conserve les obligations de l’Art. 24(1). La fiche doit donc attribuer les actions à leurs responsables réels ; elle ne doit pas transférer toute responsabilité au DPO par la formule « bon pour lancement ». Source : RGPD, Art. 24 et 39.

En cas de désaccord, faites apparaître l’avis, les faits contestés, les décisions et leurs raisons. Notre guide sur l’arbitrage entre DPO et direction détaille cette traçabilité. L’indépendance du DPO impose aussi de ne pas lui dicter la conclusion attendue sous prétexte que la date est déjà annoncée.

Un point non résolu doit rester visible. Écrivez, par exemple, « accès du support fournisseur non établi, opération concernée non ouverte », plutôt que « fournisseur validé sous réserve ». La première formulation permet au chef de projet de savoir ce qui peut effectivement être activé.

Vérifier après ouverture et avant chaque extension

Après la mise en service, rapprochez les réglages utilisés de la version examinée. Contrôlez les accès, champs et fonctions autorisés, puis les procédures de conservation et de droits lorsqu’elles doivent s’exécuter. La fréquence dépend du contexte ; aucun délai fixe de revue ne convient à tous les projets.

Conservez une liste des déclencheurs : nouvelle catégorie de données, connecteur, prestataire, destinataire, fonction de profilage ou extension importante du public. Chaque changement doit être examiné avant les opérations concernées, selon ses conséquences. La version R-1 ne constitue pas une autorisation permanente pour toutes les versions suivantes.

Ce qu’il faut retenir

• Décidez sur le parcours et la configuration réels.
• Reliez chaque condition à une preuve et à un responsable.
• Réduisez effectivement le traitement lorsqu’un périmètre plus limité est possible.
• Réalisez l’AIPD et la consultation préalable lorsqu’elles sont requises.
• Conservez l’avis du DPO sans lui transférer la décision de l’organisme.

FAQ

Peut-on valider le lancement avec des réserves ?

Une décision peut distinguer des opérations prêtes et des fonctions différées. Mais une réserve ne permet pas de commencer une opération dont une condition juridique nécessaire reste insatisfaite.

Une démonstration interne permet-elle d’utiliser de vraies données ?

Son caractère interne ne dispense pas du RGPD. Vérifiez le fondement, le périmètre et les garanties ; préférez des données fictives lorsque l’objectif de démonstration le permet.

Faut-il refaire toute la revue à chaque correction ?

Rattachez la correction aux conclusions qu’elle affecte et vérifiez le résultat. Un changement de finalité ou de risques peut nécessiter une analyse plus large qu’un simple ajustement de présentation.

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.