PublicSchema
Lorsque des programmes servent les mêmes personnes, leurs systèmes ont besoin d'un langage commun. PublicSchema le fournit : des définitions partagées pour les concepts, les champs et les codes de valeur. Prenez-les comme point de départ, puis adaptez-les au contexte de votre pays.
Contenu du schéma
PublicSchema n'est ni une norme d'API, ni un produit logiciel, ni un cadre de conformité. Il fournit des définitions partagées où chaque concept porte un poids sémantique, pas seulement une structure. Une Personne n'est pas un simple ensemble de champs. Chaque définition reçoit un URI stable, utilisable directement dans des attestations vérifiables (Verifiable Credentials). Tout est optionnel. Adoptez ce qui s'applique au contexte de votre pays ; étendez le reste dans votre propre espace de définition.
Concepts et propriétés
Les entités comme Personne, Inscription et Paiement reçoivent des définitions claires
rédigées pour les gestionnaires de programmes. Chaque concept porte des
propriétés nommées et typées (given_name, date_of_birth,
enrollment_status) définies une fois et réutilisées d'un concept à
l'autre.
Vocabulaires
Ensembles de valeurs contrôlées pour des champs tels que le genre, le pays, la modalité de prestation et le statut d'inscription. Lorsque des normes internationales existent (ISO, FHIR), nous nous y référons. Lorsqu'elles n'existent pas, nous définissons un ensemble commun fondé sur la convergence observée entre les systèmes.
Pourquoi un vocabulaire partagé est essentiel
Une mère inscrite à un programme de transfert monétaire devrait automatiquement être éligible à une prestation de santé maternelle. Mais les deux systèmes définissent le « genre » différemment, le « ménage » différemment, et le « statut d'inscription » différemment. Le renvoi vers la prestation de santé nécessite alors un exercice de mise en correspondance manuelle, qui prend des semaines et génère des erreurs.
| Système | Nom du champ | Valeurs |
|---|---|---|
| Système A | gender | 1, 2, 3 |
| Système B | sex | M, F, O |
| Système C | gender_identity | male, female, non-binary, prefer_not_to_say |
Le même concept. Trois systèmes. Trois représentations incompatibles.
C'est le coût de la coordination : à chaque fois que deux programmes 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.
Pire encore, certaines correspondances ne sont pas seulement lentes mais entraînent des pertes d'information. Le système C distingue
non-binary et prefer_not_to_say ; le système A possède
trois codes numériques. Aucune correspondance ne peut préserver cette distinction. L'information
est perdue, et les décisions en aval sont prises sur des données déformées. Les définitions partagées
ne font pas qu'économiser du temps ; elles rendent tout simplement possible un échange précis.
Sa place dans le paysage des normes
Des normes comme DCI et GovStack définissent comment les données circulent entre les systèmes : contrats d'API, protocoles de transport, blocs de construction. Elles incluent des modèles de données, mais ces modèles servent la couche de transport. PublicSchema part de l'autre direction : que signifie « inscription » ? Quelles propriétés décrivent un paiement ? Quelles valeurs sont valides pour la modalité de prestation ? Le modèle sémantique est l'artefact principal.
Les deux approches sont complémentaires. DCI spécifie comment transférer des dossiers d'inscription entre systèmes ; PublicSchema spécifie ce que signifient « inscription », « actif » et « benefit_modality » dans ces dossiers. EU Core Person Vocabulary couvre les attributs d'identité ; PublicSchema va plus loin, en intégrant le cycle de vie complet de la prestation, au-delà du nom et de la date de naissance.
Ancré dans des données probantes
PublicSchema est fondé sur une analyse comparative de six systèmes de protection sociale. Lorsque des normes internationales existent (ISO pour le genre, les pays, les devises ; FHIR pour la santé), nous nous y référons. Lorsqu'elles n'existent pas, nous définissons un ensemble commun fondé sur le fonctionnement réel de ces systèmes.
Choisissez votre point d'entrée
Par où commencer
“Je coordonne des programmes qui servent des publics cibles communs”
Vous avez besoin de chiffres consolidés, de listes de bénéficiaires dédupliquées, ou de parcours d'orientation entre services. PublicSchema vous fournit des définitions partagées pour que les données de différents programmes puissent être comparées et liées.
“Je développe ou maintiens des intégrations entre systèmes”
Vous avez besoin de noms de champs et de codes de valeur partagés pour que les systèmes échangent des données sans couches de traduction sur mesure. Établissez la correspondance de votre système avec PublicSchema une fois ; tout autre système déjà mappé devient automatiquement interopérable.
“Je rédige des exigences pour un nouveau système”
Vous avez besoin de spécifications d'interopérabilité concrètes pour votre appel d'offres, pas simplement « le système doit être interopérable ». Citez les propriétés et codes de valeur de PublicSchema pour que les prestataires disposent d'une cible vérifiable.
“J’analyse des programmes entre pays ou secteurs”
Vous avez besoin d'un cadre structuré pour que les divergences deviennent visibles et identifiables. L'inventaire des concepts et propriétés de PublicSchema vous offre une grille commune de référence.
“J’adapte un standard au contexte de mon pays”
Les concepts universels comme Personne et Ménage s'appliquent tels quels. Là où les programmes de votre pays ont besoin de plus (catégories de prestations spécifiques, scores de ciblage indirect, identifiants existants), étendez PublicSchema dans votre propre espace de définition. L'interopérabilité est préservée ; la spécificité locale n'est pas perdue.
Explorer le schéma
Concepts fondamentaux
19Protection sociale
9Vocabulaires
51PublicSchema est maintenu comme un projet ouvert. Source sur GitHub À propos du projet