Registre de groupe : séparer les responsabilités

Un groupe peut centraliser son registre dans un même outil, à condition de restituer les activités et les responsabilités de chaque entité. Un modèle commun évite les recopies ; les variantes montrent les différences de destinataires, d’accès, de données ou de conservation. La centralisation documentaire ne transfère pas automatiquement la responsabilité au siège.

Ce que chaque entité doit pouvoir expliquer

L’Art. 30(1) du RGPD prévoit un registre des activités effectuées sous la responsabilité de chaque responsable. L’Art. 30(3) accepte la forme électronique et l’Art. 30(4) prévoit sa mise à disposition de l’autorité sur demande. Le texte n’impose pas un fichier informatique séparé par société. Source : RGPD, chapitre IV.

En revanche, la centralisation ne doit pas empêcher d’identifier les activités d’une entité et leurs caractéristiques. Avant de fusionner les fichiers, vérifiez les rôles : responsable autonome, responsable conjoint ou sous-traitant. Un registre des traitements décrit des responsabilités, pas seulement une liste de logiciels.

Une architecture à trois niveaux

La structure suivante est une recommandation de gestion documentaire, pas une présentation réglementaire obligatoire.

Les fiches ne doivent hériter que des informations réellement communes. Un champ obligatoire vide ne devient pas conforme parce qu’une autre filiale a renseigné le sien.

Définir les données qui peuvent diverger

Pour chaque activité commune, demandez aux filiales de confirmer les catégories de personnes et de données, les destinataires, les transferts éventuels, les durées prévues et les mesures applicables. Les finalités figurent expressément à l’Art. 30(1)(b). La base légale n’est pas une rubrique littéralement énumérée par cet article, mais sa justification doit être documentée et peut utilement compléter le registre.

Une politique de conservation groupe ne suffit pas si certains pays ou activités imposent des obligations différentes. La variante doit citer l’écart et sa justification, sans transformer une préférence locale en obligation juridique.

Exemple rempli : deux filiales et une société de services

Exemple entièrement hypothétique. Le groupe Nacre comprend Nacre Services SAS, qui répare des appareils au domicile des particuliers, Nacre Atelier SARL, qui reçoit les appareils dans ses locaux, et Nacre Coordination SAS, qui assure l’administration technique du logiciel commun.

Chaque filiale conclut ses propres contrats, décide des informations nécessaires à ses prestations et des personnes qui peuvent les utiliser. Pour l’administration décrite ici, Nacre Coordination exécute leurs instructions documentées, sans réutiliser les dossiers clients pour ses propres objectifs. Elle est donc sous-traitante de ces opérations dans ce scénario. Elle reste responsable de ses propres traitements de personnel et de facturation.

Le registre central n’affiche pas « groupe Nacre » comme unique responsable. Son répertoire des entités distingue E-01, Nacre Services, E-02, Nacre Atelier, et E-03, Nacre Coordination, avec leurs coordonnées et celles du DPO commun désigné. Les adresses de contact illustratives sont droits@services-nacre.example, droits@atelier-nacre.example et dpo@groupe-nacre.example. Le DPO commun est joignable depuis les trois sociétés.

Un socle réellement commun, deux vues différentes

La fiche type REP-01 décrit la gestion des demandes et des contrats de réparation. Elle est reliée aux notices, aux règles de conservation et aux documents contractuels de chaque entité. Le tableau suivant présente un extrait comparé des variantes, pas un registre complet prêt à couvrir toute l’activité du groupe.

La suppression des consignes à la fin de l’intervention est un choix de fonctionnement de cet exemple, pas une durée générale imposée à tous les réparateurs. Les pièces contractuelles suivent leur propre analyse et ne sont pas supprimées avec la consigne. La distinction entre les deux catégories doit exister dans les paramètres, pas seulement dans le document.

L’outil commun n’exige pas de rendre tous les champs accessibles partout. Les salariés d’Atelier ne voient pas les codes d’entrée des clients de Services. Les administrateurs de Coordination disposent seulement des accès nécessaires à leur mission, encadrés et contrôlés. Mutualiser la licence ne justifie aucun accès automatique entre filiales : la limitation de l’accessibilité relève notamment de l’Art. 25(2).

Ce qui apparaît dans le registre de Coordination

Coordination décrit séparément ses catégories d’activités de sous-traitance pour E-01 et E-02 au titre de l’Art. 30(2) : administration du logiciel, gestion technique des habilitations et assistance sur instruction dans le périmètre convenu. Les noms des deux responsables et les variantes pertinentes restent retrouvables. Les activités propres de Coordination relèvent de son registre de responsable.

Ce classement repose sur les faits retenus. Si Coordination décidait de croiser les historiques des deux filiales pour ses propres objectifs commerciaux, cette opération devrait recevoir sa propre qualification. La fiche « administration technique » ne pourrait pas la couvrir par simple ajout d’une ligne. De même, une activité dont plusieurs entités détermineraient ensemble les finalités et les moyens devrait être examinée sous l’Art. 26, avec l’accord correspondant. RGPD, Art. 26, 28 et 30.

Définir ce qui peut être partagé, hérité ou remplacé

Une information commune doit avoir un propriétaire et une version. Pour Nacre, l’annexe de sécurité SEC-04 décrit le périmètre commun effectivement déployé : comptes nominatifs, séparation des espaces, gestion des habilitations et contrôles. Chaque vue d’entité référence cette version ; les éventuelles différences locales sont visibles à côté.

En revanche, les destinataires locaux et les consignes d’accès ne sont pas des champs hérités automatiquement. Le registre distingue trois états : information commune confirmée, variante propre à une entité et information encore à vérifier. Un blanc ne signifie ni « aucun destinataire » ni « aucun transfert ».

Les champs relatifs aux transferts doivent tenir compte des opérations réelles : stockage, accès de support et prestations associées. Une localisation renseignée par Services ne constitue pas une preuve pour Atelier si les configurations ou fournisseurs diffèrent. Chaque entité doit pouvoir retrouver le périmètre examiné et les éléments qui soutiennent la conclusion.

Cette organisation limite deux erreurs fréquentes : cinq copies indépendantes qui divergent sans raison, et une modification centrale qui remplace une exception locale pourtant nécessaire. Elle peut être mise en œuvre dans un tableur ou un logiciel, à condition que les vues restent lisibles et maintenables.

Organiser les validations sans inventer un responsable global

Nommez un référent qui collecte les informations, un propriétaire métier qui confirme le fonctionnement et une personne habilitée à décider pour l’entité. Le DPO conseille et contrôle dans son rôle ; il ne devient pas le responsable de tous les traitements parce qu’il administre le registre.

Les qualifications reposent sur les décisions effectives, comme le rappelle la CNIL dans sa fiche sur les rôles. Le guide de la fonction du DPO aide à préserver cette distinction.

Préparez une vue exportable par entité. Elle doit permettre de lire une fiche complète sans devoir reconstituer manuellement une dizaine de renvois dont certains ont changé depuis sa validation.

L’Art. 37(2) permet de désigner un DPO unique pour un groupe si celui-ci est facilement joignable à partir de chaque lieu d’établissement. Cette possibilité ne dispense pas de définir son périmètre, ses moyens et les interlocuteurs locaux. Une adresse commune qui ne permet pas de savoir quelle société est concernée peut compliquer le traitement des demandes plutôt que le faciliter.

Traiter les changements communs et locaux

Un changement de fournisseur commun doit produire une revue des variantes concernées. À l’inverse, un nouvel accès local ne doit pas écraser la fiche de toutes les sociétés. Conservez l’auteur, la date, l’objet du changement et les entités auxquelles il s’applique.

Dans le scénario Nacre, Services remplace son prestataire de rendez-vous. Le référent ouvre la modification CH-07 pour E-01 uniquement : identité du nouveau prestataire, données transmises, contrat, accès et fin des anciennes transmissions. Atelier n’ajoute pas ce prestataire à sa fiche puisqu’elle ne lui communique aucune donnée dans l’activité étudiée. Coordination reçoit seulement les instructions techniques nécessaires au changement de Services.

Le compte rendu de clôture indique que le nouveau circuit a été décrit et vérifié, que les anciens accès identifiés ont été retirés et que le sort des données chez le prestataire sortant a été traité selon les instructions. Si sa confirmation manque, la sortie reste ouverte ; la validation de la nouvelle fiche ne prouve pas à elle seule l’exécution de l’ancienne prestation.

Un tableau de suivi simple peut contenir : activité, version commune, variante locale, dernier événement vérifié, écart ouvert et prochaine action. L’automatisation du registre peut faciliter ces rappels, mais les informations doivent être confirmées par les équipes qui réalisent le traitement.

Contrôler la cohérence avant de clôturer la migration

Prenez quelques activités et reconstituez leur vue par filiale. Vérifiez que les documents contractuels, les notices et les accès réels correspondent aux informations affichées. Recherchez les fiches orphelines, les entités disparues et les fournisseurs renommés sans mise à jour.

Dans l’exemple, la vue E-01 restitue le prestataire de rendez-vous et la consigne temporaire, la vue E-02 ne les attribue pas à Atelier et la vue E-03 distingue activités propres et assistance sous-traitée. Le référent contrôle ces trois résultats avant de déclarer la migration documentaire achevée. Il ne se contente pas de compter trois entités dans le menu.

Conservez les anciennes versions nécessaires pour comprendre l’évolution du programme, selon une durée justifiée. L’historique documentaire ne doit pas devenir un dépôt de dossiers personnels : le registre décrit les traitements, il ne contient pas leurs données opérationnelles.

Ce qu’il faut retenir

• Un outil commun est possible si les activités de chaque responsable restent identifiables.
• Les variantes locales doivent être explicites et validées.
• La coordination du registre ne transfère pas automatiquement les responsabilités au siège ou au DPO.

FAQ

Faut-il un fichier Excel par filiale ?

Le RGPD n’impose pas ce format. Un référentiel central peut convenir s’il restitue clairement le registre relevant de chaque responsable.

Que faire lorsqu’une filiale ne valide pas les informations ?

Conservez l’écart visible et attribuez une action à une personne habilitée. Ne transformez pas son silence en validation ; si l’incertitude affecte un traitement en cours, faites décider les mesures nécessaires sans attendre la clôture du registre.

Peut-on utiliser une fiche identique pour toutes les sociétés ?

Seulement lorsque les informations correspondent réellement à leurs traitements. Les différences de destinataires, durées ou transferts doivent apparaître.

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.