La norme BODS (Beneficial Ownership Data Standard)

Ce qu’est la norme BODS

Les logiciels de registre passent ; les données de propriété qu’ils détiennent doivent leur survivre. Le Beneficial Ownership Data Standard (BODS) — le standard de données sur les bénéficiaires effectifs — est un standard ouvert qui encadre la collecte, le partage et l’usage de données de qualité sur les bénéficiaires effectifs. Pour quiconque évalue un logiciel de registre des bénéficiaires effectifs — un registre public, un ministère, un partenaire au développement —, la norme BODS est le point fixe de l’évaluation : si un système sait exporter fidèlement son registre vers la norme, les données ont une vie indépendante du logiciel qui les a produites.

La norme est développée et maintenue par Open Ownership, organisation à but non lucratif dédiée à la transparence des bénéficiaires effectifs, en collaboration avec Open Data Services. Sa version documentée actuelle est la 0.4, et son schéma est défini en JSON Schema 2020-12. Ce dernier détail compte plus qu’il n’y paraît : le schéma étant publié et vérifiable par machine, la conformité d’un fichier de données à BODS n’est ni une affaire d’opinion ni un argument commercial — le fichier valide contre le schéma, ou il ne valide pas.

Il faut être précis sur ce que BODS n’est pas. Ce n’est pas une loi : le cadre juridique décide qui doit déclarer, ce qui doit être vérifié et ce qui peut être publié. Ce n’est pas un logiciel : aucun produit n’embarque la norme d’office. C’est une langue commune pour les résultats — une manière de consigner qui possède et contrôle les entités juridiques, telle que l’enregistrement puisse être lu, vérifié, combiné et questionné bien au-delà du registre qui l’a produit.

Un modèle fondé sur des énoncés

Un jeu de données BODS se compose d’énoncés, et le choix de conception qui donne au modèle son caractère est celui-ci : les énoncés sont des affirmations, non des faits. Chaque énoncé représente, selon la norme, une affirmation faite par une source à un moment donné, et porte sa source, sa date et son contexte. Quand la réalité change — un actionnaire cède ses parts, un trustee est remplacé —, le registre ne retouche pas l’ancien énoncé : il en publie un nouveau, portant le même identifiant stable d’enregistrement, qui amende ou confirme ce qui avait été affirmé. Le résultat, selon les termes de la norme, est un journal en écriture seule ; l’histoire de ce qui a été affirmé, par qui et quand, reste lisible en entier.

La propriété et le contrôle sont portés par les énoncés de relation sous forme d’intérêts typés. La norme reconnaît qu’un intérêt peut tenir à la propriété juridique, au contrôle de l’entité ou à l’usage de ses actifs, et sa liste de codes des types d’intérêts en nomme les formes : participation au capital, droits de vote, nomination du conseil, droits accordés par contrat, dirigeant principal, montages de prête-noms, entre autres. Les relations peuvent être directes ou passer indirectement par des entités intermédiaires — là précisément où la dissimulation aime se loger, et la raison pour laquelle un enregistrement structuré et typé vaut mieux qu’un champ libre.

Les énoncés eux-mêmes sont de trois natures, décrits dans les concepts clés de la norme :

Pourquoi un standard ouvert compte pour un registre

Le premier argument est la portabilité. Un registre est la mémoire d’une institution publique sur qui possède et contrôle en dernier ressort les entités juridiques de son territoire (le glossaire fixe le vocabulaire), et cette mémoire ne doit pas être l’otage d’une décision d’achat. Des données détenues dans le seul schéma privé d’un fournisseur sont, en pratique, les données du fournisseur : en partir revient à rétro-concevoir son propre registre. Des données exportées vers BODS peuvent être portées vers un système successeur — ou simplement conservées, lisibles, en prévision du jour où le logiciel changera.

Le deuxième argument est l’analyse. Des énoncés normalisés se laissent lire par des outils que l’exploitant du registre n’a jamais construits : comparaison entre juridictions, analyse de réseaux, criblage par les autorités de la commande publique et les institutions financières, journalisme d’investigation. Chaque énoncé portant sa source et sa date, l’analyste peut peser la preuve au lieu d’accepter des totaux. Rien de cet outillage n’a besoin d’être commandé par le registre : un standard ouvert laisse l’écosystème faire le travail.

Le troisième argument est le contrôle — du logiciel lui-même. Quand le format d’export est ouvert et le schéma vérifiable par machine, l’exploitant d’un registre peut tester la promesse centrale d’un fournisseur au lieu de la croire. C’est l’inversion la plus saine qui soit dans la technologie publique : c’est la norme, non l’argumentaire commercial, qui définit ce que « fonctionner » veut dire.

Ce que BODS exige d’un logiciel de registre

La conformité à BODS 0.4 a un plancher précis : la section conformité de la norme impose qu’une implémentation sérialisant en JSON valide contre le schéma JSON de la norme, emploie les termes du schéma conformément à leurs définitions, et n’en sorte que là où ils sont insuffisants. Mais la validité de schéma est la partie facile. Bien exporter est une propriété du système de registre tout entier, et cela demande quatre disciplines :

• Des identifiants stables. Chaque entité, personne et relation a besoin d’un identifiant d’enregistrement qui survive aux mises à jour, aux corrections et aux migrations. Sans identifiants stables, les nouveaux énoncés ne peuvent ni amender ni confirmer les précédents, et l’histoire du registre se défait en instantanés sans lien.
• La complétude. Les intérêts typés n’ont de sens que si le registre saisit les intérêts dans leur variété — pourcentages détenus, droits de vote, contrôle par contrat, prête-noms — au lieu de les aplatir dans un champ libre qu’aucun outil ne peut interroger.
• La discipline de mise à jour. BODS modélise le changement par de nouveaux énoncés, jamais par des retouches silencieuses. Un système de registre doit traiter ses propres enregistrements de la même façon : ajouter des événements, préserver l’histoire, et laisser l’export refléter ce qui a été affirmé à chaque moment.
• L’export machine comme fonction de premier rang. Un export assemblé de temps à autre, à la main, sort de conformité à la première évolution du modèle de données. L’export doit être une sortie maintenue et testée du système, produite de la même manière à chaque fois.

L’alignement de RÉCOR

Une conséquence du schéma ouvert mérite d’être soulignée : la vérification n’exige pas la confiance. Le Data Review Tool d’Open Ownership valide la conformité d’un fichier au schéma JSON et à des exigences supplémentaires contrôlables par programme. Chacun — exploitant, auditeur, journaliste — peut y soumettre l’export d’un registre. La prétention d’un fournisseur à exporter vers BODS est donc une prétention que le fournisseur n’arbitre pas lui-même.

RÉCOR est un registre souverain des bénéficiaires effectifs conçu pour le Cameroun, bâti pour exporter vers BODS v0.4. L’alignement est structurel, non cosmétique. Les enregistrements de RÉCOR sont conçus pour se projeter sur les trois natures d’énoncés de la norme — personnes, entités et relations de propriété ou de contrôle, avec des intérêts typés tels que la participation au capital et les droits de vote. Son journal de déclarations est en ajout seul par conception, ce qui répond au journal en écriture seule des énoncés ; ses enregistrements portent des identifiants stables, ce qui permet à un énoncé exporté d’amender ou de confirmer un énoncé antérieur ; et la vérification précède la publication, de sorte que ce qui est exporté est ce qui a résisté à l’examen.

Le détail machine de cette correspondance est publié sous la forme d’un profil d’export BODS v0.4 auto-déclaré — l’énoncé canonique de la manière dont les enregistrements de RÉCOR se projettent sur la norme. Il existe pour que la phrase « exporte vers BODS » puisse être examinée champ par champ plutôt que crue sur parole. Le profil est déclaré par SIGIL ; il n’est certifié par aucun tiers.

RÉCOR a fait l’objet d’une démonstration complète auprès d’Open Ownership le 1 juillet 2026, et Open Ownership en a pris acte. Il s’agit d’une démonstration technique, non d’un soutien institutionnel. Nous la consignons parce qu’elle est le genre d’affirmation que cette page défend : précise, datée, bornée — la démonstration d’un export qui fonctionne, non un label.

Ce que nous ne prétendons pas

Les limites de cette page sont aussi délibérées que ses affirmations. Il n’existe pas de programme de certification de la conformité à BODS — aucun organisme ne délivre de label « certifié BODS » —, si bien que l’alignement de RÉCOR est auto-déclaré, comme doit honnêtement l’être celui de tout fournisseur. Ce qui peut être offert à la place est examinable : un profil d’export publié, un schéma ouvert contre lequel valider, une démonstration datée. RÉCOR est en pré-déploiement ; il n’a ni clients, ni déploiements, ni pilotes à rapporter, et cette page n’en rapporte aucun.

Cette retenue n’est pas de la modestie ; c’est une méthode. Une entreprise qui propose d’opérer la mémoire d’une institution doit être lisible de la même manière qu’elle demande à la propriété de l’être. La façon dont SIGIL formule et borne ses affirmations est exposée dans la méthode, et le contexte plus large de ce travail se trouve dans notre pratique d’infrastructure de gouvernance.

Questions fréquentes

Demander une présentation →

À lire ensuite