Comment organiser les données d’un projet numérique commun à plusieurs services ?

Définir les finalités avant le dossier partagé

Une finalité décrit l’usage poursuivi avec les données : instruire une demande, organiser un rendez-vous ou suivre une prestation. La formule améliorer le service est trop générale pour justifier toutes les opérations imaginables. L’équipe identifie pour chaque fonction les données nécessaires, leur provenance et les personnes qui en ont besoin. Elle distingue les informations utiles au contact des pièces nécessaires à l’examen d’un droit.

Les principes de l’article 5 du RGPD imposent notamment limitation des finalités, minimisation, exactitude et limitation de conservation. L’article 6 exige une base juridique appropriée. La réunion de services sur une même plateforme ne permet pas de remplacer cette analyse par un consentement global demandé à tous les usagers. Dans un service public, la base doit correspondre à la mission et aux opérations réellement poursuivies.^[1]

Les catégories particulières de l’article 9 nécessitent une attention propre. Un dossier peut contenir une information de santé alors qu’une fonction de rendez-vous n’en a pas besoin. La présence de la pièce dans le système ne justifie pas son accès par tous les modules. Le flux peut transmettre les seules données nécessaires ou séparer la pièce sensible, avec l’examen de sa condition de traitement lorsque son utilisation est requise.^[1]

Les données de pilotage constituent également une finalité à décrire. Mesurer le délai d’une démarche peut nécessiter des dates et catégories, sans conserver le contenu complet des justificatifs dans un outil statistique parallèle. L’équipe détermine le niveau utile d’agrégation et les accès. Le besoin d’améliorer l’organisation ne doit pas devenir une justification permanente de duplication des dossiers individuels.

Attribuer les responsabilités réelles

L’article 24 du RGPD rattache au responsable du traitement la mise en œuvre de mesures appropriées et la capacité de démontrer la conformité. Il faut donc identifier qui détermine les finalités et les moyens essentiels, en examinant les décisions réelles. Le porteur du marché informatique n’est pas nécessairement, pour cette seule raison, l’unique responsable de toutes les activités des partenaires.^[3]

Lorsque plusieurs acteurs déterminent conjointement les finalités et moyens, l’article 26 appelle une organisation transparente de leurs responsabilités. Une convention doit refléter cette réalité et préciser notamment le traitement des droits. Le fait que chaque service conserve son logo ne prouve pas l’indépendance des traitements ; inversement, l’usage d’un logiciel commun ne prouve pas à lui seul une responsabilité conjointe. La qualification repose sur les choix et relations effectifs.^[3]

Si un fournisseur traite les données pour le compte du responsable, l’article 28 impose un cadre adapté. Le contrat décrit l’objet, la durée, la nature, les finalités, les catégories de données et les obligations pertinentes. Une clause générale de confidentialité ne couvre pas toutes ces exigences. Les instructions, les sous-traitants ultérieurs, l’assistance et les conditions de fin de prestation doivent être suffisamment déterminés.^[3]

La réutilisation pour améliorer un produit doit être examinée séparément. Un fournisseur qui poursuit une finalité propre ne devient pas automatiquement sous-traitant pour cette opération parce qu’il l’est pour l’hébergement. L’équipe identifie ce qui est autorisé, ce qui est exclu et la manière de vérifier les réglages. La qualification juridique et la configuration du service doivent raconter la même chose.

Organiser les flux, les accès et les durées

La cartographie des flux suit la collecte, le transfert, l’accès, l’export, la sauvegarde et la suppression. Elle inclut les accès de support et les sous-traitants, pas seulement l’interface des agents. Un écran réservé aux personnels ne prouve pas que le fournisseur ne peut jamais consulter le contenu. Le dossier technique et le contrat permettent d’examiner les opérations effectivement possibles.

L’article 32 demande des mesures de sécurité appropriées au risque. L’équipe examine notamment les habilitations, la disponibilité et les moyens de restauration. La sécurité ne se réduit pas à la robustesse d’un mot de passe : une erreur d’accès entre services peut divulguer un dossier sans intrusion extérieure. Les droits sont construits par fonction et vérifiés sur des cas représentatifs, puis revus lorsque l’organisation évolue.^[3]

Les durées doivent correspondre aux besoins et obligations applicables. Le dossier distingue les pièces d’instruction, les données de contact, les journaux et les sauvegardes. Une durée unique peut conserver trop longtemps certains éléments et supprimer trop tôt d’autres preuves nécessaires. Les modalités de suppression doivent être décrites avec les limites des sauvegardes, sans promettre un effacement instantané que l’architecture ne permet pas.

L’évaluation du risque porte sur les personnes : divulgation, erreur de rapprochement, perte d’une demande ou utilisation hors contexte. L’article 35 prévoit une analyse d’impact lorsqu’un traitement est susceptible d’engendrer un risque élevé, selon sa nature, sa portée, son contexte et ses finalités. Le nom pilote ne dispense pas de cet examen. Une analyse existante peut être utile, mais elle doit correspondre au nouveau flux et à ses effets.^[3]

Construire le partage sur un guichet fictif

Dans un exemple fictif, une intercommunalité propose un guichet commun de prise de rendez-vous, d’accompagnement administratif et de dépôt de demandes d’aide auprès de plusieurs autorités. Le projet initial prévoit un dossier unique contenant toutes les pièces. L’analyse commence par distinguer les fonctions et les autorités destinataires. La simplification recherchée ne démontre pas que chaque intervenant peut accéder à l’ensemble du dossier.

Le module de rendez-vous utilise le contact et la catégorie générale de demande. Le service d’instruction reçoit les pièces nécessaires à la demande qui le concerne. L’accompagnateur peut aider à leur dépôt selon un circuit défini, sans disposer d’un droit permanent d’accès à toutes les décisions ultérieures. Cette séparation permet de conserver un parcours commun tout en réduisant la diffusion d’informations qui ne sont pas utiles à chaque fonction.

Une pièce relative à la santé est nécessaire à une demande particulière. Elle n’est pas transmise au module de rédaction d’un message de rendez-vous ni à l’outil de statistique de fréquentation. La minimisation agit donc sur le flux, avant que la donnée ne soit traitée. Demander au modèle de l’ignorer après réception ne supprimerait pas les questions de licéité, de sécurité et de conservation liées à sa transmission.^[1]

Le fournisseur propose de conserver les conversations afin d’améliorer son assistance. Le responsable distingue ce besoin commercial de la finalité d’accompagnement. Le contrat et les paramètres excluent la réutilisation retenue comme incompatible avec le projet, puis une vérification confirme le fonctionnement. L’équipe ne se contente pas d’une consigne aux agents si les flux techniques transmettent encore les contenus dans des conditions différentes.

Le dispositif prépare enfin une demande d’accès d’un usager. Le guichet doit savoir quelles données il détient, quelle autorité traite quelle demande et comment orienter ou coordonner la réponse. Les articles 12 à 15 du RGPD organisent notamment une information compréhensible et les droits d’accès. Une architecture répartie entre partenaires ne doit pas rendre ces droits impraticables en renvoyant indéfiniment l’usager d’un acteur à l’autre.^[2]

Vérifier le dispositif avant de l’élargir

Les tests doivent porter sur les règles d’accès et les conséquences d’erreur. Un agent d’un service tente de consulter un dossier relevant d’un autre ; un compte est retiré ; une pièce est remplacée ; un usager demande une correction. Ces tests ne constituent pas une preuve générale de conformité, mais ils vérifient des garanties concrètes. Les cas et résultats sont documentés pour que les corrections puissent être suivies.

L’objection selon laquelle la séparation des données annulerait la simplification mérite un examen de parcours. Certains échanges peuvent être justifiés et éviter une nouvelle demande de pièce. Il faut alors établir leur objet et leurs conditions, plutôt que renoncer à toute circulation ou autoriser toutes les circulations. La proportionnalité consiste à partager ce qui permet la fonction, avec les accès et durées correspondants.

Une autre difficulté concerne la connaissance des agents. Les règles ne peuvent rester dans la seule convention entre responsables. Les personnels doivent comprendre les données qu’ils peuvent utiliser, les canaux autorisés et les situations à transférer. La formation part des tâches réelles et des erreurs possibles. Un schéma juridique exact peut rester inefficace si l’interface encourage un export général dont le service n’a pas prévu les conséquences.

Le changement de fonction doit enfin déclencher une révision. Ajouter un module de tri ou ouvrir l’accès à un partenaire modifie le traitement. La décision examine les bases, les informations aux personnes et les mesures de sécurité avant activation. La facilité technique d’ajouter un compte ne doit pas tenir lieu de décision sur la nouvelle circulation. Le responsable conserve une version datée de la cartographie et des habilitations.

Un partage utile est donc celui dont les finalités et responsabilités restent identifiables. Dans le guichet fictif, le parcours commun peut être maintenu sans ouvrir toutes les pièces à tous les acteurs. Les règles deviennent concrètes par des flux limités, des accès testés et un circuit de droits praticable. La mutualisation améliore alors le service parce qu’elle organise l’information nécessaire au lieu d’accumuler des données disponibles sans usage déterminé.