PublicSchema

Pourquoi un vocabulaire partagé est essentiel

Un gouvernement souhaite savoir si l'enfant qui s'inscrit à l'école est bien le même que celui enregistré à la naissance et le même que celui suivi dans le calendrier vaccinal. Le registre d'état civil détient le document officiel. L'hôpital a enregistré l'accouchement. L'école admet un enfant dont l'âge est estimé, faute d'acte présenté. Les trois enregistrements décrivent la même personne, mais leurs champs et leurs valeurs ne s'alignent pas, si bien que la réconciliation exige un travail manuel qui prend des semaines et génère des erreurs.

Il en va de même au-delà des personnes. Une parcelle apparaît dans le cadastre, dans le registre des exploitations agricoles et dans la liste des usagers de l'eau d'un périmètre d'irrigation, chacun avec son propre identifiant et sa propre idée de la superficie de la parcelle. Une entreprise est un enregistrement au registre du commerce, un autre à l'administration fiscale, et un troisième dans le dossier de permis environnemental.

C'est le coût de la coordination : à chaque fois que deux systèmes doivent partager des données, quelqu'un passe des semaines à établir des correspondances entre champs et à traduire des codes. C'est coûteux, fragile, et tout recommence à zéro à chaque mise à niveau d'un système.

Ce ne sont pas des problèmes qu'une simple table de correspondance peut résoudre. On ne peut pas reconstruire une date de naissance exacte à partir d'un âge estimé, et les identifiants utilisés par chaque système ne pointent vers rien que les autres puissent vérifier. Par ailleurs, un système décrit la famille par l'admission hospitalière, un autre par le lien parental dans un registre, et un troisième pas du tout. Les concepts eux-mêmes ne s'alignent pas. Les définitions partagées ne font pas qu'économiser du temps ; elles rendent tout simplement possible un échange précis.

PublicSchema ne prescrit pas quelle représentation est la bonne. Il vous offre un point de référence commun pour voir les différences, choisir ce qui correspond à votre contexte, et l'étendre là où votre contexte en a besoin. Adoptez ce qui fonctionne ; laissez le reste.

Sa relation avec les autres normes

PublicSchema s'articule avec les normes que vous utilisez déjà. Il ne les remplace pas ; il leur donne un point de référence sémantique commun.

Les normes d'échange telles que la Digital Convergence Initiative (DCI) et GovStack définissent comment les données circulent entre les systèmes : contrats d'API, protocoles de transport, blocs de construction. PublicSchema définit ce que ces données signifient : ce qui constitue une inscription, un enregistrement ou une exploitation agricole, et quelles valeurs sont valides pour un statut ou un type de tenure. DCI peut transporter le dossier ; PublicSchema dit ce que signifient ses champs.

Les normes sectorielles telles que HL7 FHIR pour la santé, l'ISO 19152 (LADM) pour l'administration foncière, et le World Programme for the Census of Agriculture de la FAO creusent un domaine en profondeur. PublicSchema les réutilise là où elles couvrent le terrain et les relie par un socle commun, de sorte qu'un établissement de santé, une école et une parcelle utilisent les mêmes briques de base pour la localisation, les identifiants et l'enregistrement.

Les vocabulaires sémantiques comme les Vocabulaires de base SEMIC de l'UE (Core Person, Core Business, Core Location) poursuivent le même objectif. PublicSchema s'y aligne et étend cette approche aux registres sectoriels et à la prestation de services, qu'ils ne couvrent pas. En savoir plus sur les normes connexes.

Par où commencer