Le domaine de la protection sociale se caractérise par des systèmes d’information complexes nécessitant de fréquents échanges d’information. Dès février 2016, les nombreux échanges de données volumineuses entre les régimes et organismes de la protection sociale étaient cités dans le rapport IGAS-IGF (Gratieux et Le Gall, 2016). Par exemple, en 2015, la Caisse nationale d’assurance vieillesse (Cnav) a comptabilisé, sur les 11 premiers mois, 1881 échanges avec 381 partenaires, correspondant à un total de 1,152 million de fichiers reçus ou émis. Assurer la qualité de ces échanges et la cohérence des informations devenait alors nécessaire pour alimenter correctement les référentiels.

Pour la branche retraite, plus de 20 millions d’actifs et 15 millions de retraités sont gérés, avec des flux de 50 millions d’éléments de carrière en provenance des entreprises, 30 millions en provenance de Pôle emploi, 10 millions en provenance de la branche maladie mais aussi plusieurs dizaines de millions en provenance ou à destination des autres organismes de retraite.

Toutes ces informations sont utilisées pour calculer les droits et servir aux assurés des prestations exactes. Pour cela, des informations complètes et de qualité sont essentielles afin de disposer d’éléments certains pour exécuter des calculs corrects. Pour stocker et centraliser les données et en garantir la qualité, la création de référentiels s’est imposée.

Compte tenu du nombre d’organismes, du nombre d’échanges et du volume de données, définir les principes de normalisation des échanges et les appliquer est essentiel pour garantir la qualité d’alimentation des référentiels, en extraire toute la plus-value et offrir des services à valeur ajoutée à toute la sphère sociale.

Les aspects juridiques, d’infrastructure, la notion de norme d’échanges et ses principes sont présentés. Les différents composants de la structure en blocs de la norme sont décrits ainsi que les dimensions fonctionnelles et techniques de ces blocs et des données qui les composent (les « rubriques »). On explicite ensuite les différents types de contrôles automatiques sur les flux. Un ensemble d’outils, nommé Saturne, a été développé par la Cnav pour générer automatiquement ces contrôles et d’autres livrables. On explique cet outillage et son rôle majeur pour reproduire la démarche et disposer de la réactivité dans la prise en compte des évolutions. Pour conclure, les apports après 12 ans d’expérience sont détaillés ainsi que les perspectives.

Les échanges se présentent sous différentes dimensions. Pour identifier les acteurs et le niveau de service lié à l’échange (fréquence, volume, délai de traitement...), ils sont encadrés par une convention juridique qui précise l’infrastructure technique permettant de garantir la robustesse et la traçabilité et définit les éléments fonctionnels liés à la structure des données et à la qualité attendue.

Les données doivent être accessibles, échangées uniquement entre acteurs autorisés et seulement sur le périmètre correspondant à leur besoin d’utilisation. Les échanges sont encadrés par une convention de service fixant les objectifs et modalités (fondements juridiques, nature, modalités de transmission et de conservation des données, sécurité et traçabilité des échanges, échéances à respecter, règles de protection des données, conditions financières et modalités de suivi de la convention).

Par exemple, les données des déclarations employeurs issues de la déclaration sociale nominative (DSN) (Humbert-Bottin E., 2018) et les autres ressources (exemple : retraite) sont transmises et partagées mensuellement pour le prélèvement à la source ou encore pour les prestations sociales quand elles sont soumises à conditions de ressources (allocation logement, pension de réversion...). Pour ces échanges, une convention régit les rapports entre le promoteur du service, le Groupement d’Intérêt Public de Modernisation des Déclarations Sociales (Gip-MDS), et les maîtrises d’œuvre qui y contribuent :

Historiquement, les régimes et organismes de la sphère sociale ont instauré des liens informatiques spécifiques pour chaque échange. Les difficultés sont d’en assurer la robustesse, la sécurité et la traçabilité.

Des infrastructures ont été mises en place pour véhiculer, piloter et superviser chaque grand projet d’échange. Pour mettre fin à cette prolifération opportuniste, l’article R. 114-31 du code de la sécurité sociale crée le DGE devenu un vecteur incontournable de communication et d’échange de données au sein de la sphère sociale.

Ce dispositif de gestion des échanges est un outil permettant les échanges entre Organismes de protection sociale (OPS), d’informations relatives aux assurés/bénéficiaires tout en garantissant la robustesse, la sécurité et la traçabilité. Il permet le routage de données concernant un unique assuré ou des millions d’assurés en flux de masse de la part d’un ou plusieurs émetteurs vers un ou plusieurs destinataires.

Il répond ainsi à des besoins d’échanges journaliers entre organismes. De plus, il expose un catalogue d’échanges très utile dans une démarche « Dites-le nous une fois ».

L’étape suivante consiste à définir la structure des données et les dispositifs de partage de la connaissance et à garantir la qualité et la cohérence des données des différents flux.

Pour y répondre, le principe de norme d’échange pour caractériser toutes les dimensions des flux de données est formalisé comme suit :

Au-delà de la définition théorique, une norme se matérialise par des livrables :

Le besoin n’est pas récent. Différentes normes ont déjà été appliquées dans la sphère sociale :

En dehors de la sphère sociale, d’autres normes d’échange de données existent. Par exemple, l’arrêté du 19 octobre 2018 approuvant le schéma national des données sur l’eau, les milieux aquatiques et les services publics d’eau et d’assainissement et l’article R. 131-34 du Code de l’environnement, ont mis en place le Sandre (Service National d’Administration des Données et Référentiels sur l’Eau).

La logique de structuration des données est le premier élément à prendre en compte dans la norme pour clarifier la présentation et formaliser la signification des objets utilisés et des liens entre eux. Elle s’appuie sur un format standard pour les données élémentaires.

Pour décrire ces notions, deux exemples :

La description fonctionnelle est structurée avec des rubriques élémentaires (nom d’une personne, etc.) regroupées en blocs de données cohérents portant sur les mêmes concepts fonctionnels (bloc identité dans le cas présent avec le nom, le prénom, le numéro d’identification, etc.) et les liens entre les différents blocs (un « bloc » individu possède plusieurs « blocs » adresse par exemple). La représentation est cohérente avec le modèle conceptuel de l’ensemble des objets et de leurs relations, préalablement défini.

Cette structure est présentée sous la forme d’un arbre pour présenter les blocs et leurs rubriques ainsi que les dépendances entre les blocs. Les normes R, NEODeS ou NEORAu ont donc une structure hiérarchique.

Cette structuration est ensuite déclinée en modèles de message reprenant tout ou une partie des objets précédents pour répondre aux différents besoins d’échanges spécifiques (alimentations ou restitutions par exemple). Dans chaque modèle de message, un bloc se caractérise par une cardinalité : présence une fois et une seule, 1 à n fois, 0 à n fois (figure 1).

Figure 1 - Structure de la norme

La norme comprend un en-tête avec les informations concernant l’émetteur et la nature et plusieurs messages contenant les données fonctionnelles.

Par exemple, pour la DSN, quelques blocs et les rubriques identifiantes dans chacun d’eux :

La structure technique des normes d’échange évolue dans le temps ; les plus anciennes étaient généralement des lignes à champ de longueur fixe ou du texte avec séparateur :

Une démarche identique à la précédente est ensuite appliquée pour les rubriques. On descend d’un cran en passant de la formalisation du message à celle des rubriques qui la composent, tout d’abord dans une démarche fonctionnelle qui décrit précisément chaque rubrique, puis dans une approche plus « technique » avec la liste des caractères autorisés. Une définition précise de chacune est fournie ainsi que son format et la plage de valeurs qu’elle peut prendre. Le format précise la typologie du champ (numérique, chaîne de caractères) et sa longueur.

Outre le format, la liste des valeurs que peut prendre la rubrique est précisée. Selon la nature de celle-ci, la typologie des valeurs est expliquée :

De cette façon, dans la norme, est associé à chaque rubrique ce que l’on appelle un « type » ou « datatype », caractérisé de façon précise par la nature de la rubrique (numérique, alphanumérique...), la liste de valeurs possibles (s’il y a lieu), l’expression régulière associée (s’il y a lieu), et les longueurs minimum et maximum (figure 2).

Figure 2 - Exemple de rubrique (type de la prime) dans le cahier des charges de la norme NEODeS

Compte-tenu de la diversité des types de caractère, de la quantité et du volume des flux, il convient d’être très rigoureux sur la structure technique de chaque rubrique, jusqu’au format des caractères. La gamme des caractères autorisés est aussi normalisée. À savoir : on autorise de 0 à 9, de a à z (majuscule et minuscule) ainsi que quelques caractères spéciaux comme & ‘ ( ) ... et on interdit les caractères spéciaux comme ! # $ % < > ... (figure 3).

Figure 3 - Table des caractères autorisés ou non pour une rubrique

La description de la structure du message et des rubriques conduit mécaniquement à une série de contrôles à effectuer. Ils consistent à vérifier que le message respecte le « modèle de message » : par exemple, les blocs de données apparaissent dans l’ordre prévu, avec la bonne cardinalité (nombre minimum et maximum), les rubriques au sein de chaque bloc s’enchaînent dans le bon ordre, elles respectent le « type » prévu (par exemple, l’appartenance à une liste de valeurs prédéterminée ou la conformité à une expression régulière). Ainsi, on récupère les données attendues « dans les bonnes cases ».

Les contrôles fondés sur la structure sont appelés contrôles syntaxiques, puisqu’ils s’appuient sur la description d’une syntaxe, à la fois pour le message et pour chaque rubrique prise isolément.

Cependant, les contrôles syntaxiques ne suffisent pas. Il faut assurer la cohérence interne du message. Ainsi, il existe au sein de chaque norme d’autres contrôles, qui matérialisent ce besoin de cohérence entre rubriques au sein d’un même message.

Il s’agit souvent de contrôles conditionnant la présence / absence d’une rubrique à la présence / absence d’une autre. Par exemple, dans le bloc Établissement de la DSN, il existe un contrôle exprimé en français : « Si le code postal est présent alors le code pays et le code de distribution à l’étranger sont absents et réciproquement. ». Ou, dans le cas de la norme R : « Si un élément de carrière est de type « Période assimilée maladie », on ne va pas trouver de revenu pour le régime général. ».

Certains contrôles inter-rubriques sont de simples inégalités : « La date de fin prévisionnelle de contrat doit être supérieure ou égale à la date de début du contrat. »

Il existe aussi des contrôles plus complexes sur le plan logique. Par exemple :

« Pour une déclaration donnée, le numéro de contrat doit être unique pour un établissement et un individu ».

Ces contrôles inter-rubriques, appelés contrôles sémantiques, sont écrits en langage naturel, afin qu’ils soient lisibles, et dans le même temps ils sont décrits en langage mathématique. Chaque contrôle sémantique est ainsi exprimé sous forme de formule logique, respectant une grammaire formelle prédéfinie.

La principale différence entre les contrôles syntaxiques et sémantiques (encadré) est la suivante : les seconds sont explicites (on écrit la règle de contrôle inter-rubriques), alors que les premiers sont implicites (on décrit le type de la rubrique, ou la structure du message, et implicitement on dit que ce type ou cette structure doivent être respectés).

Quelques chiffres : en 2022, la Déclaration Sociale Nominative (DSN, norme NEODeS) comporte 7 modèles de messages, 61 blocs, 599 rubriques, 284 types. La norme R en 2023 comporte 26 modèles de messages, 163 blocs, 1174 rubriques, 282 types, 1163 contrôles sémantiques.

L’ensemble de ces règles de contrôle, syntaxiques et sémantiques, caractérise la norme d’échange. Chaque règle décrit « ce qui est interdit ». Il faut souligner que ces contrôles sont intrinsèques au message : Il s’agit de vérifier si dans le message, la structure d’ensemble est correcte et si les données sont bien celles attendues (le bon type, le bon ordre...) et sont conformes à des règles de cohérence.

À ce stade, on n’a fait que décrire des règles. Il faut maintenant les mettre en œuvre, et donc vérifier le message dans toutes ses composantes. C’est nécessaire sur le plan métier car cela permet à toutes les parties prenantes, utilisatrices du message, d’être assurées de la qualité du message, et en corollaire de la qualité d’alimentation des référentiels. Cette vérification est implémentée dans des interfaces applicatives (API) qui exécutent des contrôles automatiques pour accepter ou rejeter les éléments contenus dans le flux.

Ces contrôles sont des contrôles bloquants. Le flux, dans le cas d’un traitement unitaire, fait l’objet d’un retour KO (le traitement s’arrête) et dans le cas d’un traitement de masse, il fait l’objet en retour d’un fichier de rejet (le traitement continue quant à lui pour les autres données du flux). Ces contrôles peuvent être complétés par des contrôles non bloquants qui permettent de continuer le traitement mais positionnent une alerte à l’utilisateur.

La succession des étapes, entre émetteur et récepteur du message, lorsque le message passe les contrôles, ou lorsqu’il ne les passe pas, est décrit avec précision dans la documentation de la norme.

La norme représente le format d’échanges pour l’envoi et la réception de flux entre les différents acteurs et en assurer la standardisation et la qualité. Les normes d’échange concernent de nombreux acteurs et sont susceptibles d’évoluer fréquemment (changements réglementaires, nouvelles demandes...). Un ensemble de livrables cohérents entre eux et systématiquement associés à un numéro de version doit être impérativement transmis à tous les acteurs.

Ces livrables sont les suivants :

Le premier livrable, documentaire, est le cahier technique de la norme. Il contient les objectifs, le périmètre, la description de la structure, ainsi que la définition de chaque bloc, chaque rubrique avec son format (datatype) et la gamme de valeurs associée. Le cahier technique est proposé au format pdf et au format html pour faciliter la mise à disposition ainsi que la recherche d’information à partir du poste de travail.

Ce document est riche et très détaillé : dans sa version 2022, le cahier technique de la norme NEODeS fait 354 pages. Il commence par une centaine de pages d’explications générales sur la DSN, ses usages, et sur toutes les notions liées à une norme d’échange. Le document décrit ensuite les différents modèles de message, en l’occurrence les modèles de déclaration (DSN mensuelle, DSN signalement fin de contrat, DSN signalement arrêt de travail), et pour chaque modèle, l’arborescence de blocs correspondante. Il explicite ensuite tous les blocs, toutes les rubriques dans les blocs avec pour chaque rubrique son type et les contrôles associés (figure 4).

Figure 4 - Extrait du cahier technique de la norme Neodes pour la rubrique « Nature juridique de l’employeur »

La documentation produite, au-delà du besoin de standardisation, comprend l’ensemble des informations et leur précision associée (blocs, rubriques, types de données, gammes de valeurs, contrôles appliqués...), tout en étant accessible grâce à une composition, un choix de maquette, des polices et des graphiques qui en facilitent la lecture.

La norme fait l’objet d’un affichage précis des versions successives ainsi que de la traçabilité des évolutions d’une version à l’autre, et elle est « à jour » et en cohérence avec les autres livrables techniques.

D’une version à l’autre, la liste de toutes les évolutions apportées est tracée dans un document spécifique livré avec chaque nouvelle version de norme.

Le cahier technique est complété par les fichiers techniques de description du flux (format xsd) exposant la norme sous forme de schémas XML utilisables par les équipes de développement pour en dériver des objets.

L’API ou brique de contrôle est utilisée par les applications qui garantissent la qualité du flux (et, dans le cas de la norme R, la bonne alimentation du référentiel de carrières). Cette API ou brique de contrôle applique l’ensemble des vérifications et contrôles de la norme pour autoriser ou rejeter les enregistrements en fonction du résultat du contrôle. Il existe une API ou une brique par norme.

L’API ou brique de contrôle traite deux types de flux, les flux unitaires et les flux de masse (figure 5).

Figure 5 - La brique de contrôle

Dans le cadre d’une saisie par un technicien sur une application ou par un assuré sur le web (cas du flux unitaire), si un seul contrôle s’avère négatif, le flux est rejeté : dans le cas du référentiel de carrières, cela implique que le flux n’est pas intégré dans le référentiel.

Dans le cadre d’échange en masse entre systèmes d’information, les enregistrements contrôlés « incorrects » sont rejetés. Les enregistrements qui satisfont les contrôles constituent un flux valide à intégrer. Un bilan de traitement du flux est envoyé à l’émetteur pour information et redressement des enregistrements incorrects.

L’outil d’autocontrôle (ou application d’autocontrôle) est destiné aux émetteurs de données afin qu’ils vérifient la validité de leur flux avant de le transmettre à la plateforme de collecte, pendant les phases de test principalement.

Il s’agit d’une application qui comporte une interface graphique pour présenter le message à valider. Il génère le même bilan de traitement que la brique de contrôle implantée sur le serveur de collecte en production.

L’outil d’autocontrôle décrit la norme et identifie, dans le flux, toutes les données en anomalie. Il comporte aussi une aide en ligne et un mécanisme qui appelle le site de référence. En comparant sa version de la norme avec celle de référence, il propose sa mise à jour le cas échéant sans avoir à télécharger un nouvel outil complet.

Dans le cadre de la DSN, cet outil est très utile pour les entreprises, qui peuvent tester les déclarations sociales « chez elles » avant l’envoi dans les référentiels de la sphère sociale.

Les structures d’échanges peuvent comporter un grand nombre de blocs, de rubriques et de contrôles (pour la norme Neodes ou la norme R, plusieurs centaines de contrôles) et avec des évolutions fréquentes. Le risque d’incohérence entre les livrables est important et peut devenir très coûteux pour les opérations de vérification voire de remise en cohérence de la norme et des développements qui l’utilisent.

Il y a une dizaine d’années, à la Cnav (par exemple sur la N4DS et la DSN), le principe était d’écrire le cahier technique et de le faire évoluer régulièrement en fonction des nouveautés réglementaires ou des nouvelles demandes, puis de développer les contrôles automatiques et l’outil d’autocontrôle. Cela générait un coût élevé et le risque d’incohérence était permanent entre les différents livrables.

Pour gagner en efficacité et cohérence, il fallait disposer d’une description formelle en un seul endroit pour y décliner tous les livrables... sans besoin de développer les contrôles ou réécrire la documentation à chaque fois. C’était un gage de réactivité et de cohérence compte-tenu du nombre d’évolutions à gérer :

Le principe appliqué est celui de la séparation des aspects métier et technique en construisant les outils les plus génériques possibles applicables à une norme d’échange. Le code relatif aux données et le code relatif aux traitements doivent être séparés (figure 6).

Figure 6 - La chaîne des livrables

L’outil doit être basé sur la description d’un modèle et la déclinaison des livrables à partir de celui-ci.

La déclinaison automatique d’un modèle unique permet de maintenir tout au long des années un modèle intègre, valide et tracé. Toute opération sur le modèle est attachée à une série de spécifications s’inscrivant dans un cycle de publication versionné. À son tour, le pilotage projet reprend ce versionnage pour construire les plans de déploiement.

Cet automatisme permet d’associer une équipe « maîtrise d’ouvrage » qui spécifie la norme et une équipe « maîtrise d’œuvre » qui réalise la chaîne de validation des flux. Ainsi, cette équipe mixte avec ces compétences couvre la modélisation de la norme et la génération de la base de connaissance associée qui sera lue par un moteur de validation unique.

Cet outil Saturne pour « Suite Applicative pour des Traitements Unifiés et Rationalisés fondés sur une Norme d’Échange » (Ouvrir dans un nouvel ongletRivière P. et Rosec O., 2013), possède une interface, l’Outil de gestion de la norme (OGN), pour décrire la norme. Il constitue alors un « référentiel de norme » fondé sur la modélisation. Cet outil permet de générer automatiquement la documentation, les formats XML et les outils de contrôle automatique ou d’autocontrôle.

Techniquement, l’implémentation fondée sur un modèle a été réalisée avec un Domain Specific Language (DSL). Il s’agit d’un langage concis et adapté à un domaine métier (Spinellis D., 2001 ; Fowler M., 2010). La mise en œuvre de ces principes a permis de faciliter l’implémentation, la généricité et la réactivité.

L’outil Saturne s’appuie sur un framework de modélisation des normes. En première approche, la personne qui crée la norme n’a pas besoin de faire de développement. Elle modélise son projet par la saisie de la structure de la norme, des paramètres de contrôles dans Saturne, qui génère l’ensemble des livrables indiqués précédemment.

La richesse et la complexité d’une norme nécessitent une approche industrielle pour la développer et pour en garantir la reproductibilité. Un processus et un outillage sont créés en ce sens et intégrés à une chaîne continue comprenant la validation de son niveau de qualité.

Le modèle d’une norme comporte des milliers de propriétés. La qualification de la norme passe par la rédaction d’un cahier de tests très complet et la réalisation de milliers de tests. La charge de réalisation d’une norme dense peut être de l’ordre d’une quinzaine de jours mais la couverture de test peut, elle, prendre 2 à 4 fois plus de temps.

L’approche industrielle de Saturne est fondée sur une démarche et un outillage d’intégration continue, complétés, compte-tenu du nombre de cas de tests liés au nombre de blocs et rubriques de la norme, par un outillage spécifique pour tester la norme avec un outil de qualification de norme (OQN). Il permet de dupliquer à partir de stéréotypes d’instances de norme valides les jeux de tests pour gagner en délai et en qualité de ceux‑ci. Deux modèles auxiliaires représentent d’une part les jeux de tests et d’autre part le bilan d’une campagne de test.

Compte tenu des caractéristiques génériques de Saturne basées sur des modèles, un nouveau type d’outil a été créé : la transformation d’un flux de données d’une norme à une autre. La grammaire utilisée pour représenter les règles de contrôle dans la norme (encadré) est utilisée pour définir les règles de transformation d’une norme à une autre.

Selon le même principe, des programmes sont générés automatiquement à partir de la description mathématique des règles de transformation : c’est l’outil de transformation de norme (OTN).

Les OTNs, par l’utilisation de Saturne, bénéficient donc des mêmes avantages que la norme pour la cohérence des livrables, la standardisation de la documentation, la reproductibilité et la réactivité pour des demandes d’évolutions.

L’outil de transformation de norme (OTN) peut être conservé alors que le nouveau référentiel est généralisé, si des applications métier conservent les interfaces de l’ancien référentiel (figure 7).

Figure 7 - Les outils de transformation de norme

La difficulté principale est de réunir les partenaires pour normaliser la transformation, écrire les règles de passage d’une norme à une autre, mettre en place la couverture de tests et le processus de qualification qui étend au processus de transformation la garantie de qualité que l’on veut faire peser sur le flux d’alimentation nativement à la norme d’entrée (Ouvrir dans un nouvel ongletMiotto E., 2011).

Dans le cadre du remplacement du SNGC (Système National de Gestion des Carrières) par le RGCU, les OTNs sont des éléments déterminants. En effet le SNGC était alimenté par de nombreux organismes de la sphère sociale (Cnam, Pôle emploi, etc.) utilisant pour la plupart leur propre norme d’échange pour l’alimentation et la restitution des éléments de carrière. La bascule vers le RGCU de ces flux d’alimentation et de restitution a nécessité de les adapter à la norme R. Depuis, une vingtaine de normes ont été ainsi transformées vers la norme R.

De plus, dans le cas de l’alimentation du RGCU par la DSN, sachant que les deux normes sont partenariales, il faut écrire une spécification inter-régimes qui s’étend au fur et à mesure que ceux-ci basculent dans le RGCU. La spécification est publiée et éventuellement amendée au regard des remarques des représentants des régimes avant de devenir opposable pour la modélisation et le développement.

À l’origine, la suite Saturne devait supporter la N4DS (Norme pour la dématérialisation des déclarations de données sociales) qui, en 2012, remplaçait la norme DADS-U. Mais à la suite d’un prototype et à la relance du projet DSN (déclaration sociale nominative, norme NEODeS), fin 2011, un rapport Igas – IGF a posé comme prérequis la conception d’un format d’échange plus simple et concis que la N4DS.

La déclaration sociale nominative (DSN, norme NEODeS) a été déployée par phases portant des scénarios métier de plus en plus ambitieux. En phase 1, elle transmettait mensuellement à un bloc applicatif de stockage les données qui servaient à générer à la place de l’employeur les attestations maladie ou chômage dont a besoin le salarié. En phase 2, elle collectait les cotisations précomptées par les employeurs et l’instrument de leur paiement. En phase 3, elle collecte les données carrière qui serviront à calculer les retraites des salariés.

Fin 2016, le prototype de la norme NEORAu a été utilisé par les employeurs hors DSN (les fonctions publiques jusqu’en 2022) puis par tous les collecteurs d’impôt sur le revenu dans le cadre du prélèvement à la source entré en production en 2019.

En septembre 2014, la conception de la norme R (comme retraite) a porté toutes les interactions entre le répertoire de gestion des carrières unique (RGCU) et les systèmes d’information (SI) métier des plus de trente régimes de retraite français qui peu à peu vont y basculer. L’ancien système national de gestion des carrières (SNGC) était alimenté par une multitude de flux hétérogènes. Dans le cas du RGCU toutes les interactions avec le répertoire sont unifiées dans la même norme, la norme R.

Pour l’ensemble des projets pour laquelle la norme a été implémentée, le gain est indéniable. La compréhension et le partage des concepts liés à la qualité de la documentation sont facilités et la cohérence des livrables est toujours présente. La réactivité grâce au nommage des versions est vérifiée et est indispensable pendant la montée en charge des projets où le nombre d’évolutions reste très important. La mise en œuvre des contrôles automatiques permet d’assurer la qualité d’alimentation du référentiel dans le cadre d’arrivée régulière de nouveaux fournisseurs de flux. La mise à disposition d’outils d’autocontrôle autorise les émetteurs de flux à tester par anticipation l’adéquation de ceux-ci avec la structure de la norme et ainsi faciliter leur intégration lors des phases de tests, limitant ainsi les coûts et les délais.

D’un Proof of Concept en 2012, Saturne est devenu un outil irremplaçable au service de deux programmes nationaux majeurs, la DSN et le RGCU.

La mise en œuvre de grands référentiels avec l’accroissement du volume, de la variété des données et des échanges associés génère un besoin de gouvernance de la donnée. La qualité des données est une condition indispensable à l‘adoption de ces référentiels. La gouvernance de la donnée s’inscrit dans la stratégie data destinée à fournir des services à valeur ajoutée.

Cette stratégie est aujourd’hui portée par une direction dédiée à la Cnav, la direction de la gestion de la donnée (DGD), chargée de délivrer des services liés à la donnée grâce à une plateforme technologique, et en amont d’une démarche de mise en qualité de la donnée indispensable à la fourniture de services à haute valeur ajoutée.

Cette mise en qualité est une orientation forte de la stratégie data, que ce soit pour les SI internes de la Cnav ou pour les référentiels majeurs utilisés par toute la sphère sociale.

Les processus et les outils mis en œuvre autour de Saturne s’inscrivent pleinement dans cette orientation. Ils constituent aujourd’hui une suite industrielle qui tire parti des leviers de productivité offerts en matière de production logicielle par la génération de code par les modèles, la réutilisation de composants et la notion de ligne de produits.

C’est un gage de qualité pour l’intégration des flux dans les référentiels mais aussi un moyen de partage et de compréhension des données avec les différents partenaires. C’est aussi un gage de réactivité pour la prise en compte de modifications dans les phases de spécifications ou dans les phases de tests.

La documentation détaillée des données et l’apport de qualité sur les référentiels facilitent le travail de l’ensemble des acteurs utilisant les données, en particulier, les statisticiens pour qui la phase de prise de connaissance des données et de préparation est une composante lourde de leur processus.

La démarche aujourd’hui est de constituer une offre autour des principes de la norme et de la suite Saturne pour l’étendre à d’autres référentiels et bénéficier de ses atouts.

À la suite de ce retour d’expérience et dans le cadre de la démarche sur la stratégie data, la Cnav s’interroge pour étendre cette offre au-delà, à travers un cadre de mise en qualité général des données, dans un contexte d’échanges de plus en plus massifs entre les organismes.