Dans nos sociétés, le besoin de références communes à visée opérationnelle se perd dans la nuit des temps. Dès l’Antiquité, les calendriers, nécessaires à l’organisation efficace des échanges et à toute forme de planification, apparurent et se perfectionnèrent, sans toutefois se coordonner. Dans la métrologie antérieure à la Révolution française, « les unités [étaient] incohérentes, leurs mesures diverses et les procédés de mesure incertains : ni caractère national, ni doctrine d’ensemble » (Ouvrir dans un nouvel ongletLacombe, 1979). En 1789, on dénombrait en France presque autant d’unités de mesure que de lieux et de corps de métiers. À Paris, merciers, drapiers et marchands de toile avaient chacun leur aune, par exemple. Muid, minot ou boisseau pouvaient représenter des mesures très diverses selon les situations. Elles pouvaient être liées à la matière : setiers de sel, mires d’huile, corbes de foin, mines de grains, penses de fromage, etc. Si les paysans, commerçant localement, s’en accommodaient peu ou prou, certains négociants n’y trouvaient pas leur compte. Passer à une métrologie universelle pour la longueur, le temps, la masse, n’allait pas de soi, loin de là. On n’imagine pas aujourd’hui l’extraordinaire épopée que fut la création du système métrique (Ouvrir dans un nouvel ongletDébarbat et Quinn, 2019), ni le rôle décisif qu’eurent les circonstances politiques favorables des débuts pour lancer le processus.

Dans tous les domaines d’activité, on s’est ainsi attelé à construire des cadres de référence communs, partagés, reconnus, publiés : des référentiels. Ce ne fut pas sans douleur, sans conflits de pouvoir (Alder, 2005). À l’ère de l’informatisation et dans un monde de plus en plus complexe, les référentiels n’ont cessé de se développer, incluant de nouvelles dimensions applicatives, techniques, systémiques, sans que ne soit démentie la difficulté que représente leur construction et leur mise en œuvre.

Au sein des systèmes d’information, on peut distinguer plusieurs types de référentiels, mais deux en particulier méritent d’être isolés. En premier lieu, les nomenclatures (Ouvrir dans un nouvel ongletGuibert, Laganier et Volle, 1971), ou classifications, répondent à un besoin permanent de catégoriser (Bowker et Star, 2000) : nomenclature de professions (Amossé, 2020), nomenclature d’infractions (Camus, 2022), classification internationale des maladies (CIM), etc. Mais il existe un second type de référentiel particulièrement crucial, d’apparence simple en première approche : les répertoires, répondant à un besoin de clarté sur une « population » de référence. Mais en quoi consistent-ils ? Selon quels principes, avec quels outils, méthodes, contraintes la tenue d’un répertoire s’organise-t-elle ? Répondre à ces questions et donner ses lettres de noblesse à une brique majeure et pourtant mal connue de l’univers des données est l’objet de cet article.

Commençons par une définition générale, abstraite : un répertoire, c’est une liste d’instances d’une même entité. Par exemple, pour une entreprise, la liste de ses fournisseurs, celle de ses clients, la liste de ses produits, etc. Les « instances » ne sont pas des concepts, des catégories qu’on invente mais des objets précis, qui naissent et qui peuvent disparaître.

Répertorier, c’est en quelque sorte inventorier, cataloguer, et le répertoire résulte de cette opération. Il se caractérise donc essentiellement par sa structure : c’est une liste « à plat », une liste d’objets avec une certaine pérennité, une certaine épaisseur temporelle (répertoire de véhicules, mais pas répertoire d’accidents, par exemple). La structure de répertoire n’implique pas systématiquement la dimension référentielle : un répertoire d’amis sur un smartphone, ou bien le répertoire d’une cantatrice (liste d’œuvres) n’ont pas nécessairement vocation à servir de référence.

Car « référentiel » signifie « qui a trait à la référence ». Le terme existe depuis longtemps dans de nombreux domaines comme la physique (référentiel galiléen), la linguistique, la psychologie ou l’éducation (Ouvrir dans un nouvel ongletCros et Raisky, 2010). Dans un système d’information, un référentiel est une source d’information reconnue, contenant des données « maître » (master data), et dans laquelle on peut puiser. Les répertoires sont une de ces sources. Dans ce qui suit, les répertoires désigneront implicitement des répertoires avec un statut référentiel (on utilisera indifféremment l’un ou l’autre terme). On peut citer par exemple des répertoires d’individus, d’étudiants, de professionnels de santé, d’électeurs (Demotes- Mainard, 2019), d’entreprises (Bernard, 1995), de véhicules routiers, d’établissements d’enseignement, etc.

Mais quelles sont les caractéristiques permettant d’affirmer qu’un répertoire possède un tel statut ? Pour cela, (Bizingre et alii, 2013) distinguent cinq propriétés fondamentales : centralité, qualité, stabilité, unité de sens et interopérabilité (figure 1).

Figure 1 - Cinq propriétés d’un répertoire avec statut de référentiel

La centralité d’un répertoire signifie qu’il est « la référence » pour un ensemble d’acteurs, qui le reconnaissent en tant que tel, lui conférant ainsi sa légitimité. Ce serait en quelque sorte, et toutes proportions gardées, l’équivalent de l’universalité pour le système métrique. Cette légitimation implique un certain degré d’officialisation, qui se matérialise souvent par un arsenal juridique : par exemple, l’arrêté du 13 novembre 2013 relatif à la mise en place d’un répertoire national des établissements sanitaires donne un statut officiel à Finess, en décrivant notamment ses finalités, son contenu et le service qui le gère.

Dans certains cas, cette forte légitimité donne un poids important au répertoire, allant parfois jusqu’à le rendre opposable pour des actes administratifs. Cette position centrale est facilitée par la neutralité de l’organisme en charge de sa gestion. Mais cette centralité ne s’exprime pas dans l’absolu, pour tous usages : elle s’inscrit dans le cadre des finalités attribuées au répertoire, des enjeux auxquels il est censé répondre. Il existe ainsi des répertoires dont la finalité est essentiellement statistique : ainsi, pour le répertoire statistique des véhicules routiers (RSVERO), la finalité principale est « la production de statistiques, d’études ou de rapports d’évaluation des dispositifs de politiques publiques ». Pour d’autres, les finalités, parfois nombreuses, sont administratives : ainsi, l’une des finalités de Finess est d’être l’autorité de référence pour les établissements qui demandent des accès numériques aux différents systèmes de santé.

Faire jouer au répertoire un rôle central requiert d’associer de nombreux acteurs à travers des instances de gouvernance : les organismes concernés (producteurs ou utilisateurs) s’expriment avec chacun leurs propres enjeux, qui ne sont pas toujours cohérents avec ceux du répertoire. Des arbitrages sont donc indispensables.

Enfin, l’encadrement juridique ou conventionnel imposé à un répertoire peut s’accompagner de contraintes, comme l’obligation d’alimenter le répertoire... qui offrent en contrepartie des garanties de qualité, fort utiles. Réciproquement, le fait que les données soient reconnues comme fiables lui confère une plus grande légitimité, facilitant sa position de pivot : en effet, décréter qu’un répertoire est central, sans se préoccuper de la réalité de son contenu est insuffisant ; il faut qu’il soit de qualité acceptable... Comment appréhender cette qualité ?

La qualité des données revêt en pratique des aspects divers (Di Ruocco, Scheiwiler et Sotnykova, 2012) : pertinence, exactitude, complétude, consistance, accessibilité, etc. Vis-à-vis de cette grille d’analyse générale, le cas d’un répertoire présente des spécificités. Ainsi, de par sa position de référence ultime, il est par construction plus difficile d’analyser sa qualité en le comparant avec d’autres sources de données... car un référentiel, c’est justement ce à quoi les autres sources se comparent (Bizingre et alii, 2013). Il soulève ainsi des difficultés particulières pour élaborer des indicateurs (Rivière, 2005), par exemple pour mesurer le taux de « faux actifs ».

En dehors des délicates questions d’exactitude, on peut insister sur :

Les deux propriétés suivantes, stabilité et unité de sens, renvoient à la sémantique des données.

La stabilité est une propriété très particulière d’un répertoire (Régnier-Pécastaing, Gabassi et Finet, 2008), qui le distingue fondamentalement d’autres bases de données et en particulier des bases de gestion. Il doit en effet contenir des données structurantes, qui ne changent pas en permanence. À cette aune, l’adresse du siège d’une entreprise est une information de référence, mais pas le montant de ses investissements. Pour chaque entité d’un répertoire, le principe doit être que les données changent peu dans le temps.

« Stable » ne signifie pas que les données sont « immuables » : par exemple, une facture est une information figée, dont le contenu ne changera plus, mais qui n’a rien à voir avec les référentiels.

Il est difficile de fonder la notion de stabilité sur la fréquence de mise à jour, trop dépendante de phénomènes métier et difficilement accessible. Plus simplement, la stabilité des données d’un répertoire peut être caractérisée par le fait que leurs évolutions doivent être indépendantes des processus métier qui les utilisent. Par exemple, dans un référentiel d’hôpitaux, le nombre de lits pourrait avoir une dimension référentielle, alors que le nombre de lits occupés, lié aux processus métier (accueil et départ des patients) et qui peut changer tous les jours, n’est en rien de nature référentielle.

La conception d’un répertoire suppose donc de porter une grande attention au choix des variables et de veiller à se limiter à celles qui sont essentielles, structurantes, stables et caractérisant l’objet : ainsi, lorsqu’une entreprise gère un répertoire de clients, on y trouvera par exemple des données de contact (numéro de téléphone, adresse mail), le canal de contact préférentiel (téléphone, courriel, site web, courrier, etc.), voire le type d’achat, mais certainement pas les achats eux-mêmes.

Avec la notion d’unité de sens, on souligne que le répertoire doit posséder une certaine homogénéité sémantique : on ne peut donc pas y mettre n’importe quoi pour céder aux demandes. L’idée est d’éviter que le répertoire devienne un fourre-tout dans lequel on ajoute des informations sous prétexte qu’elles sont utiles à certains utilisateurs. Cela vaut d’abord pour les entités : les responsables Sirene ont ainsi été sollicités pour immatriculer des éoliennes, ou des ruches par exemple... ce qui n’a rien à voir avec la notion d’entreprise ou d’établissement. De telles demandes se comprennent : les utilisateurs du répertoire peuvent voir ce dernier comme un outil utile pour faciliter leur travail, sans se préoccuper du « bien commun », perçu comme théorique. La gouvernance d’un répertoire donne donc naturellement lieu à des tensions entre besoins des utilisateurs et nécessité de cohérence au niveau global.

L’unité de sens s’applique également aux données : dans un répertoire d’électeurs (Demotes-Mainard, 2019), on va se limiter aux variables utiles pour le rôle d’électeur (commune de rattachement, bureau de vote), et ne pas ajouter des données sans rapport avec ce rôle (par exemple, nombre d’enfants). Plus généralement, un répertoire doit contenir « relativement peu » de variables en principe, car il est coûteux d’en assurer la qualité, et en particulier la fraîcheur ou encore la minimisation des données à caractère personnel, au titre du Règlement général sur la protection des données.

Cette dernière propriété aborde un aspect plus technique, qui n’est pas spécifique aux référentiels : le service rendu aux utilisateurs par le « système » répertoire, ainsi que son insertion technique dans l’ensemble du système d’information. En effet, si le répertoire possède toutes les propriétés évoquées précédemment, mais qu’il n’est pas pratique à utiliser et à intégrer, il perd tout son intérêt.

L’interopérabilité revient à considérer le référentiel non pas en termes de contenu, mais de services offerts, au sens informatique du terme (Régnier-Pécastaing, Gabassi et Finet, 2008), et d’interconnexion efficace avec les systèmes d’information qui l’environnent, partageant avec ceux-ci un même langage, en quelque sorte. Dire qu’il est interopérable, c’est dire qu’il est ouvert et accessible (par exemple via des API ou Application Programming Interface).

On distingue traditionnellement interopérabilité technique (exigences de performance, de disponibilité, de sécurité, d’utilisation de standards techniques, etc.), interopérabilité syntaxique (format utilisé, par exemple XML, JSON), et interopérabilité sémantique (identifiants, concepts, nomenclatures, etc.).

Les répertoires se caractérisent souvent par un grand nombre d’utilisateurs, sans pouvoir connaître et encore moins maîtriser leurs usages ; d’où ce fort besoin qu’ils soient interopérables. À titre d’exemple, la présence d’identifiants reconnus (NIR, numéro Siren, etc.) est un facteur d’interopérabilité, car elle permet de faire le lien avec d’autres processus (par exemple l’utilisation du numéro Siren dans la déclaration sociale nominative ou DSN).

Derrière cette notion, c’est aussi tout le sujet de l’accostage du référentiel aux systèmes d’information qui est en jeu : qui doit s’accoster, comment... Cela comporte une dimension technique (par exemple une API à utiliser), mais aussi des règles de fonctionnement auxquelles on s’astreint : obligation pour telle application de s’accoster à tel référentiel, obligation de ne s’alimenter qu’à tel répertoire, etc. Last but not least, il ne faut pas oublier le sujet de la cohérence des répertoires entre eux, de leurs interactions, et les enjeux associés (par exemple, les liens entre Finess et Sirene, ou bien la mise en cohérence mutuelle SNGI – RNIPP), qui relèvent clairement de l’interopérabilité.

Un répertoire est un ensemble d’entités de même type, et pour chacune d’elles, on trouve toujours peu ou prou le même type de données, liées au statut référentiel.

En premier lieu, l’identifiant  : par exemple, le numéro Siret pour un établissement, le numéro RPPS pour un professionnel de santé, le numéro INE pour un élève, étudiant ou apprenti. Il doit être présent pour tout répertoire, puisque c’est ce qui désigne l’objet et l’officialise. Attribuer un identifiant à un objet se nomme immatriculation et revient à créer l’objet dans le répertoire. Le processus d’immatriculation est une opération majeure qui demande la plus grande rigueur ; en effet, ce processus ouvre accès à des services, ce qui poserait problème au cas où l’immatriculation est faite avec une fausse identité. L’identifiant est ainsi la clé d’accès à l’entité, clé qui permet aussi de faciliter les appariements entre fichiers portant sur le même objet. Une bonne pratique consiste à faire en sorte que cet identifiant soit non signifiant, c’est-à-dire qu’il ne contienne aucune information porteuse de sens ; cette pratique n’est d’ailleurs pas toujours respectée (voir le NIR).

Mais l’identifiant ne peut être créé à partir de rien ; il faut savoir « de qui on parle ». Ainsi, on doit disposer de traits d’identité, grâce auxquels on peut repérer sans ambiguïté l’objet : par exemple, nom‑prénom‑date de naissance pour un individu, raison sociale-adresse pour un établissement. Les traits d’identité sont distincts de l’identifiant et ne le contiennent pas.

Une précision importante : les traits d’identité ne doivent être présents (avec statut référentiel) que pour certains types de répertoires, dits répertoires‑socles : ce sont eux qui formalisent le lien entre identifiant et traits d’identité. Les autres répertoires sont dits répertoires adossés. Par exemple, le REU, répertoire d’électeurs, est adossé au RNIPP, répertoire-socle d’individus ; autre cas, le RGCU, répertoire de carrières, est adossé au SNGI. Ainsi, dans un répertoire adossé, les traits d’identité, s’ils sont présents, ne constituent pas une référence : le lien entre traits et identifiant dépend complètement du répertoire-socle auquel il est adossé.

Au-delà de ce noyau dur, un répertoire contient systématiquement des données de catégorisation, car les entités qui le composent ne sont pas toutes équivalentes. Par exemple, pour des établissements d’enseignement, on utilise un découpage du type : établissements du premier degré, du second degré, de l’enseignement supérieur ou de formation continue, etc. Un répertoire d’entreprises comme Sirene s’appuie quant à lui sur des nomenclatures officielles, ayant une existence et une gestion en dehors du répertoire : ainsi, pour caractériser l’activité principale, on se fonde sur la nomenclature d’activités française (NAF).

On trouve également, mais de façon moins systématique, des données pour positionner l’objet dans l’espace : adresse, géolocalisation, code lié à un zonage. Il faut également le situer dans le temps, à l’aide de dates-clés : dates d’ouverture, ou de création, et réciproquement de fermeture, ou de cessation. Plus généralement, la connaissance de l’historique des objets (étapes de création, cessation-fermeture, mais aussi fusions ou scissions, dans le cas des entreprises par exemple) peut se révéler indispensable.

Il est souvent nécessaire de compter parmi les données les identifiants d’autres objets liés, ou des références à des conventions.

À toutes ces données de fond, il faut ajouter des données dites de gestion ; ces données ne sont pas de nature référentielle, mais facilitent la gestion courante du répertoire. Par exemple, les données de contact telles que l’adresse mail, l’adresse physique ou le numéro de téléphone associées à l’entité sont importantes lorsqu’il faut justement la contacter, pour effectuer des vérifications notamment.

Enfin, il est fort utile de disposer, pour certaines données, des métadonnées : provenance de la donnée, ou date de mise à jour, par exemple. Les conventions peuvent aussi se présenter comme des métadonnées.

Ainsi, construire une base contenant toutes les données nécessaires est une chose. Faire en sorte que cet ensemble de données soit de nature référentielle, et donc respecter les cinq propriétés citées précédemment, en est une autre. Toute une organisation doit être mise en place pour obtenir un tel résultat. Comment fait-on, concrètement ?

L’image courante, lorsqu’on évoque une information de référence, consiste à dire qu’elle est « gravée dans le marbre ». Mais cette image est tout à fait inadaptée dans le cas d’un répertoire. En effet, ce dernier ne peut pas être figé, car le monde réel qu’il est censé décrire ne l’est pas : de nouvelles instances apparaissent (naissances, créations, ouvertures), d’autres disparaissent (cessations, fermetures, décès), et les données descriptives peuvent évoluer (par exemple la capacité d’accueil d’un établissement de santé). Ainsi, les grands répertoires sont affectés quotidiennement par de nombreux événements de mise à jour.

Un répertoire se caractérise également par les forts liens qu’il entretient avec de nombreux systèmes d’information : en amont pour le nourrir, en aval pour les services rendus aux utilisateurs. Ainsi, une image plus appropriée d’un répertoire serait celle d’une pompe aspirante refoulante d ’ informations, d ’ un cœur battant, régulièrement alimenté par des événements de mise à jour, et irriguant en permanence d’autres systèmes (figure 2). Car il n’a pas d’intérêt pris isolément, et ne prend sa signification que vis-à- vis de ses utilisateurs (fournisseurs ou consommateurs), variés et nombreux.

Figure 2 - Le répertoire, au centre d’un échange de flux

Plus qu’une simple base de données, un répertoire est un véritable système dont les données de référence constituent le centre. À ce titre, on peut le caractériser selon plusieurs dimensions (entrée, sortie, contenu, boucle de rétroaction) :

Le système vivant ainsi décrit doit être alimenté régulièrement, avec des informations fraîches (autant que possible), à travers des « événements » qui requièrent une mise à jour : création, fermeture, changement d’adresse ou d’activité, toute forme de changement de statut, etc.

Ces modifications ne relèvent pas d’une mise à jour classique dans une base de données : le statut référentiel du répertoire entraîne des exigences particulières de maîtrise de la qualité, de traçabilité des modifications. Il faut donc en particulier mettre en place des contrôles automatisés permettant de filtrer les entrées dans le répertoire.

Plus précisément, on vérifie que le flux d’entrée transmis, le « message », est conforme à un standard : on peut imager cela en disant qu’on « branche » le flux de données sur le répertoire et on vérifie que la prise est bien conforme. Dans notre cas, le standard se présente sous la forme de règles à respecter pour toutes les données transmises, que l’on appelle norme d’échange.

Quelles sont ces règles ? Tout d’abord, l’ordre dans lequel se présentent les données du message : par exemple nom, prénoms, date de naissance, département, commune de naissance. Plus généralement, on vérifie que la structure du message est conforme à une structure attendue. On effectue également des contrôles de type (numérique, alphanumérique, date, chaîne de caractères) et de domaine d’appartenance. Par exemple, une date doit respecter un certain format (comme JJMMAAAA), et des règles spécifiques (mois ≤ 12, jour ≤ 31, etc.). Un code de département, ou un code d’activité doivent appartenir à une liste précise et prédéfinie.

En amont, la normalisation est également sémantique : il faut avoir défini le sens de chaque donnée, de chaque valeur dans une liste d’items ou une nomenclature, pour maîtriser l’information transmise. Enfin, standardiser les échanges, c’est formaliser la cinématique des flux, un processus complet dans lequel sont décrites les modalités d’envoi entre émetteur et récepteur ou les notifications transmises, et ce selon le type d’événement.

Normer les échanges est indispensable dans le cas de grands répertoires largement utilisés : norme EDI-CFE pour Sirene, norme A pour le SNGI, norme R pour le RGCU, ce qui donne lieu à de vastes documentations techniques.

Au-delà des référentiels, la standardisation des flux de données est une pratique essentielle dans les systèmes d’information alimentés de façon industrielle : par exemple, la norme GTFS (General Transit Feed Specification) est un format standardisé pour communiquer, entre autres, des horaires de transports en commun et les informations géographiques associées ; la norme Odette fait référence dans l’automobile ; le monde de la protection sociale fait l’objet d’une forte rationalisation des échanges (Ouvrir dans un nouvel ongletGratieux et Le Gall, 2016), et utilise en particulier la norme NEODeS pour la déclaration sociale nominative (Humbert-Bottin, 2018).

Le répertoire, ainsi nourri et même rassasié de flux d’information réguliers et standardisés, ne demande désormais qu’à être utilisé. Point d’articulation entre systèmes d’information, il se comporte comme un fournisseur de services envers des utilisateurs variés. Dans le cas du référentiel de métrologie (seconde, kilogramme, mètre), des « services » avaient en quelque sorte été développés en dehors du référentiel : respectivement, le chronomètre, la balance, le mètre ruban. C’est très différent pour un répertoire, évoluant dans un système d’ information  : les services lui sont intégrés, en sont une composante à part entière.

Quels sont ces services ? Il faut isoler en premier lieu les services spécifiques d’un répertoire-socle : l’immatriculation et l’identification. Immatriculer un objet, cela consiste à le créer dans le répertoire, à lui donner naissance dans le système d’information. Pour cela, à partir des traits d’identité de l’objet (nom-prénoms-date et lieu de naissance pour un individu, raison sociale – adresse pour un établissement), on vérifie automatiquement qu’il n’existe pas déjà, puis on lui attribue un identifiant (NIR, numéro Siret, etc.).

La fonction d’identification est tout à fait différente, car elle ne crée aucun objet. À partir de traits d’identité connus (par exemple, « Leyla Garcia, née le 2 novembre 1999 à Lille »), on cherche s’il existe une personne ayant des caractéristiques identiques ou proches (par exemple « Leila » et non « Leyla »), pour obtenir son identifiant (ici le NIR). Lorsque l’information est imparfaite, incomplète (par exemple en absence de l’année de naissance) ou qu’il reste des ambiguïtés, l’algorithme d’identification doit proposer plusieurs possibilités, plusieurs échos, et les classer par pertinence.

D’autres fonctions viennent naturellement à l’esprit : consulter les données d’une entité (par exemple, toute l’information disponible dans Finess sur tel établissement de santé), ou bien effectuer une sélection (par exemple, la liste, au 31/12/2021, des établissements de santé de l’Oise, créés après 2010). Le fait de pouvoir sélectionner tout ou partie des objets du répertoire à un instant t, de « prendre une photographie », sont des services particulièrement précieux pour les statisticiens, car cela permet de constituer une base de sondage, et plus généralement d’avoir une population de référence pour toute statistique.

Des services peuvent aussi être déclenchés par un mécanisme d’abonnement : par exemple, une caisse de retraite demande à être informée automatiquement de mises à jour concernant les personnes affiliées à son régime.

Les répertoires ont aussi vocation à être utilisés au sein de processus automatisés, sans intervention humaine, en proposant des API intégrables à des processus de production (par exemple, le RGCU fait appel au moteur d’identification de Sirene, pour déterminer les établissements dans lesquels une personne a travaillé pendant sa carrière).

Au total, un répertoire doit proposer une palette de services standard, et différentes modalités d’appel de ces services. Attention cependant, un répertoire n’est certainement pas là pour offrir des services « sur mesure » à chaque utilisateur : par exemple, fournir toutes les « photographies » possibles (contenu, fréquence, filtre, etc.). Ce n’est pas son rôle. La gestion courante en pâtirait, paralysée par la multiplicité des demandes, avec le risque de perdre de vue l’objectif principal, la vocation de référentiel.

Pour finir, soulignons qu’il ne faut pas aborder la notion de service en se limitant aux seuls services numériques  : dans les répertoires importants, des équipes de gestionnaires assurent en général un travail de réponse aux sollicitations (téléphone, courriel). Cette activité est essentielle pour la qualité du répertoire, et elle fait bien sûr, partie intégrante du service rendu aux utilisateurs.

Il en va d’un répertoire comme de tout processus d’approvisionnement : il est toujours plus pratique et plus efficace de contrôler la marchandise à son arrivée, immédiatement. Ainsi, avant l’entrée dans le répertoire, on vérifie la provenance et la conformité à des standards, et cela se fait automatiquement (contrôle d’habilitation, application de la norme d’échange). Ces contrôles sont bloquants : si le moindre d’entre eux n’est pas respecté, il y a rejet. Des contrôles non-bloquants peuvent compléter le dispositif : contrôle de cohérence entre données du flux, ou bien comparaison entre la donnée du flux et celle présente dans le référentiel, pour déterminer si l’évolution est plausible. L’élaboration de ces contrôles non-bloquants et leur mise en œuvre sont un sujet en soi non détaillé ici.

On ne peut se limiter à vérifier le flux d’entrée : il faut aussi analyser le répertoire dans son ensemble, de façon macroscopique. Par exemple, repérer des doublons, pour éviter le phénomène de sur-couverture du répertoire, ou bien repérer des données manquantes, ou plus généralement vérifier que les données du référentiel, « en stock », respectent la structure attendue (en termes de typage et de domaine d’appartenance notamment). C’est ce que proposent les systèmes avancés de contrôle, généralement réunis sous le vocable de data quality tools (Boydens, Hamiti et Van Eeckhout, 2021), avec des techniques dites de profiling (Olson, 2003).

Il serait illusoire de penser que la démarche qualité d’un répertoire se résume à une approche purement mécaniste et algorithmique, en grande partie automatisée. Qui dit répertoire dit équipe de gestionnaires, chargés de vérifications plus complètes et plus fines qui échappent à la machine, et aussi d’échanges directs avec les entités concernées (téléphone, courriel), avec le terrain en quelque sorte, pour une meilleure compréhension en remontant à la source (Ouvrir dans un nouvel ongletDenis, 2018. L’organisation de ce travail, souvent intitulée « administrationderéférentiel », prévaut dans tous les grands répertoires administratifs.

Entre autres exemples :

Administrer le répertoire, choisir ses cibles d’intervention, requiert une vision d’ensemble, quantifiée, sous forme de tableaux de bord, notamment pour fixer des priorités et ainsi orienter le travail des gestionnaires de répertoire. Cela comporte des tâches récurrentes (comme le suivi du traitement des rejets) et des tâches projet (par exemple un projet d’amélioration de la qualité du stock). Cette administration inclut également, de façon plus macroscopique, un suivi de production, qui peut utilement mettre en évidence des anomalies : par exemple, lors d’un suivi mensuel du nombre de mises à jour du répertoire, une chute brutale un mois donné alerte sur un possible dysfonctionnement dans les flux d’entrée.

Pour qu’un système aussi complexe qu’un répertoire fonctionne, il faut le piloter, et en particulier prendre des décisions concernant ses évolutions, dans le respect permanent de ses finalités. Pour cela, si les tableaux de bord sont très utiles, il faut également que des instances de décision soient mises en place, à savoir une véritable gouvernance du référentiel, associant les différentes parties prenantes.

Celle-ci est en fait de deux natures  : la gouvernance structurelle (sa définition) et la gouvernance « instancielle » du répertoire (son contenu, son peuplement). Dans la première, on trouve par exemple le modèle de données (même si les modalités de validation sont difficiles), la norme d’échange, le suivi des réglementations concernées, et dans la seconde, la qualité des données et les conséquences concrètes de la non-qualité (retours d’usage), ou bien l’accostage du répertoire sur les systèmes d’information métier.

Dans ces instances, il faut parvenir à un consensus sur les évolutions de contenu : nouveaux types d’objets à incorporer (« intègre-t-on les associations dans le répertoire d’établissements ? »), nouvelles données, nouvelles nomenclatures, etc., en gardant en tête l’unité de sens, pour éviter d’ajouter des objets ou des variables non pertinents.

Les sujets à aborder portent aussi sur les services offerts par le répertoire : extension de la palette de services et du niveau de service (ergonomie, temps de réponse, etc.).

En pratique, « gouverner un répertoire » revient souvent à «  rester raisonnable dans ses ambitions ». Ajouter ne fût-ce qu’une seule variable dans un répertoire représente un coût : introduire une nouvelle variable requiert en effet d’organiser les flux d’alimentation associés, donc de trouver les fournisseurs, de s’assurer de la fraîcheur des informations fournies, de développer les contrôles correspondants, de faire évoluer les services, etc. Cela ne se limite donc pas à une simple modification de schéma de base de données.

Un répertoire joue un rôle pivot : c’est un objet-frontière, qui « articule des perspectives d’acteurs appartenant à des mondes sociaux hétérogènes » (Ouvrir dans un nouvel ongletTrompette et Vinck, 2009. À ce titre, il est naturellement confronté à de multiples acteurs ayant leurs propres intérêts, leurs propres besoins, qui vont aller à l’encontre de la stabilité et de l’unité de sens. Les instances décisionnelles sont ainsi, naturellement, un lieu de rapport de forces entre d’une part des utilisateurs qui en souhaitent toujours plus, d’autre part les responsables du répertoire cherchant à garantir sa généralité, sa cohérence et sa solidité pour des usages futurs.

Comme on l’a souligné en introduction, l’entité « répertoire » présente tous les attributs de la simplicité : on imagine une liste d’objets, une liste de courses à faire, etc. et on n’y associe pas a priori une quelconque complexité. Dès lors, le fait d’assurer la gestion d’un tel objet peut donner l’illusion de l’évidence. Cet a priori est source d’erreur et conduit parfois à de grandes difficultés, voire des échecs : (Bizingre et alii, 2013) consacrent ainsi un chapitre au cas du référentiel d’une organisation, décrivant « simplement » la liste de ses unités, et montre pour quelles raisons de tels référentiels sont très difficiles à élaborer. Il apparaît, en particulier, que les unités organisationnelles ne sont pas les mêmes selon les usages, et qu’il s’avère impossible pour un référentiel de satisfaire une trop grande variété de besoins, exprimés ou implicites.

Car dans un monde où la donnée ne cesse de prendre de l’importance, les répertoires s’inscrivent dans des systèmes référentiels plus larges, véritables infrastructures de connaissances (Borgman, 2015), incluant des nomenclatures ou d’autres répertoires, une standardisation des échanges, un système documentaire, une comitologie (groupe de travail, comité décisionnel), un sous-bassement juridique, le tout étant associé à une « culture référentielle » de l’organisation dont il ne faut pas sous- estimer l’importance. Pourquoi tout cela ?

Ce que l’on stocke, échange et met à disposition, ce ne sont pas des choses inertes, mais de véritables concentrés de sens, mouvants, diversement interprétables selon les acteurs et ayant des impacts colossaux sur des processus métiers.

C’est une matière soumise à une double dynamique :

Dès lors, rien de plus normal que des réunions techniques ou décisionnelles parfois interminables, avec des consensus difficiles à trouver. Que les projets de répertoire soient longs et coûteux ne doit pas non plus surprendre au vu des sujets à traiter : structuration de la base de données, tour d’horizon des sources d’alimentation, reprise des données passées, transition et bascule vers le nouveau système, élaboration et maintenance de la norme d’échanges, transformation des anciens flux d’entrée, poste de travail du gestionnaire, gamme de services à mettre en œuvre, optimisation du fonctionnement en production... sont le lot commun de ces projets ((Alviset, 2020) et (Demotes-Mainard, 2019)).

Plus généralement, et même si la dimension informatique y joue un rôle majeur en raison du haut degré d’interopérabilité généralement attendu, un projet de réalisation de répertoire ne doit pas être vu en premier lieu comme une opération technique. Car le résultat est avant toute chose un système hautement sensible caractérisé par des finalités générales certes partagées, mais qui se heurtent dans l’opérationnel à des enjeux individuels qui eux ne le sont pas. C’est donc une exigence permanente de compromis entre les acteurs du répertoire, avec la flexibilité suffisante pour satisfaire des utilisateurs, tout en ne baissant jamais la garde sur la rigueur de conception, les finalités transverses. C’est aussi naturellement un reflet d’enjeux de pouvoir, un « lieu » de confrontation d’intérêts divergents... comme ce fut le cas durant la passionnante aventure qui a conduit à élaborer le système métrique.