Gouvernance : ce que nous mettons dans la fondation, et quand

Un socle que la BITD (base industrielle et technologique de défense) instancie et fédère ne peut pas rester indéfiniment la propriété de son éditeur. La question de la gouvernance se poserait tôt ou tard ; ce texte la traite tôt. Il décrit l’état à la publication, les critères qui déclencheront le transfert vers une structure neutre, ce qui sera transféré et ce qui ne le sera jamais, les modèles de fondation étudiés, et le processus de décision qui s’applique dès maintenant.

L’état à la publication

Le projet est porté par Cercle Digital, qui édite le socle sous licence Apache-2.0 et opère le dépôt public.

Les contributions externes sont acceptées sous DCO (Developer Certificate of Origin) : chaque commit porte l’attestation de son auteur qu’il a le droit de soumettre ce code sous la licence du projet [1]. Le DCO est un engagement individuel et traçable ; il n’exige aucune cession de droits à Cercle Digital, à la différence d’un contrat de cession de type CLA.

La revue de sécurité est obligatoire sur le cœur : aucun changement du socle (boot, chaîne de signature, isolation, maillage) n’entre sans relecture par les mainteneurs du domaine, en plus des 9 chaînes CI et des ~930 tests automatisés qui gardent le dépôt. Le dépôt publie une politique de signalement des vulnérabilités : un canal dédié, un engagement de réponse et une divulgation coordonnée avec les instances connues avant publication du correctif.

Le bilan des contributions à ce stade est qualitatif : les contributions reçues portent surtout sur les modules, les connecteurs et la documentation ; les contributions au cœur restent le fait des mainteneurs. Les décomptes précis (contributeurs actifs, organisations distinctes, contributions fusionnées par domaine) sont un point ouvert : le tableau de bord public qui les établira fait partie des travaux de gouvernance, et nous publierons ces chiffres quand ils seront mesurés, pas avant.

Les critères de déclenchement

Le transfert vers une structure neutre n’est pas daté ; il est conditionné. Deux critères le déclenchent, cumulativement :

1. des contributeurs industriels réguliers : plusieurs organisations distinctes, sans lien capitalistique avec Cercle Digital, contribuant au cœur de façon soutenue sur plusieurs cycles de publication ;
2. des premières instances en production : au moins une instance opérée par un tiers en conditions réelles, au sens du guide d’instance.

La logique de ces critères : une fondation sans contributeurs multiples est une coquille qui ajoute du coût sans ajouter de neutralité ; une fondation sans instance en production arbitre des questions théoriques. Quand les deux critères sont atteints, le processus de transfert s’ouvre publiquement, avec un calendrier publié.

Deux éléments ne sont volontairement pas des critères. Un seuil de notoriété n’en est pas un : le nombre d’étoiles d’un dépôt ne mesure ni la contribution ni l’usage. Une échéance calendaire n’en est pas un non plus : annoncer une date de fondation avant d’avoir des co-décideurs reviendrait à créer la coquille décrite ci-dessus, avec un conseil qui resterait de fait celui de l’éditeur.

Ce qui part, ce qui reste

Le périmètre du transfert est défini dès maintenant, pour que personne ne découvre les termes au moment de la négociation.

Sera transféré à la structure neutre :

1. la marque OC2-Edge, pour que le nom du socle n’appartienne à aucun fournisseur ;
2. le processus de certification, c’est-à-dire les règles par lesquelles une implémentation ou un module se déclare conforme ;
3. le dépôt de conformité, qui héberge les suites de tests et les résultats opposables de certification.

Restera chez les instances, sans exception : leurs clés, leurs builds, leurs preuves. La souveraineté d’instance n’est pas un actif transférable ; c’est une propriété d’architecture. Une fondation qui détiendrait les clés des instances reproduirait la dépendance que le projet existe pour supprimer. Cercle Digital, après transfert, devient un contributeur et un opérateur d’instance parmi d’autres.

Les modèles étudiés

Trois familles de structures sont à l’étude. La comparaison ci-dessous est courte et se veut loyale ; aucun choix n’est arrêté, c’est un point ouvert.

Modèle	Traits principaux	Points d’attention pour OC2-Edge
Fondation type Apache	Gouvernance par des individus élus au mérite, comités de projet, longue pratique de l’incubation [2]	Structure de droit américain ; la gouvernance par individus s’accorde mal avec des engagements d’organisations industrielles de défense
Eclipse Foundation	Association de droit belge, groupes de travail industriels, processus de spécification et de certification éprouvés [3]	Ancrage juridique européen ; le modèle par groupes de travail correspond au besoin ; coût d’adhésion à budgéter
Linux Foundation Europe	Entité européenne d’une fondation établie, hébergement de projets avec membres organisationnels, services mutualisés [4]	Ancrage européen ; mutualisation forte ; poids relatif des grands membres à examiner

Les critères d’arbitrage sont publics : ancrage juridique européen, place donnée aux organisations sans exclure les contributeurs individuels, existence d’un processus de certification, coût de structure supportable par un écosystème naissant. L’évaluation se fera avec les membres fondateurs, pas avant eux : le choix de la structure engage ceux qui y siégeront, et une décision prise par l’éditeur seul contredirait l’objet même du transfert.

Quel que soit le modèle retenu, deux invariants s’imposent : la licence reste Apache-2.0, conforme à la définition de l’open source [5], et le projet vise les bonnes pratiques vérifiables de l’OpenSSF, dont le badge des meilleures pratiques [6]. Un troisième invariant découle de l’architecture : aucune structure, quelle qu’elle soit, ne reçoit d’autorité technique sur les flottes. La fondation certifie la conformité au socle ; elle ne signe rien pour personne.

Le processus de décision, dès maintenant

La gouvernance ne commence pas au transfert ; elle se pratique dans le dépôt dès aujourd’hui.

La feuille de route est ouverte : les orientations du socle sont publiées dans le dépôt et discutées publiquement avant engagement.

Les décisions structurantes passent par RFC (Request for Comments) : un document versionné dans le dépôt, une période de commentaires publique, une décision motivée par les mainteneurs. Les RFC refusées restent archivées avec leurs motifs, au même titre que les RFC acceptées : l’historique des décisions est un livrable du projet, opposable et citable. Un contributeur qui rejoint le projet dans trois ans doit pouvoir lire pourquoi chaque choix structurant a été fait, et par qui.

Ce présent article vaut engagement public : les critères de déclenchement et le périmètre de transfert décrits ci-dessus ne seront modifiés que par RFC, avec trace. Un changement silencieux de ces termes serait détectable par l’historique du dépôt, et c’est exactement le rôle qu’un projet ouvert doit donner à son historique.

Appel aux membres fondateurs

L’écosystème a besoin de membres fondateurs avant d’avoir besoin d’une fondation : industriels qui instancient, services étatiques qui évaluent, éditeurs qui publient des modules, fabricants qui livrent des Provider Packs. Ce sont ces acteurs qui rempliront les critères de déclenchement et qui siégeront dans la structure neutre le moment venu.

Ce que gagne un membre fondateur se décrit sans promesse : une voix dans les RFC dès aujourd’hui, la co-définition du processus de certification avant qu’il ne soit figé, et l’antériorité d’une instance opérée quand les critères de transfert seront examinés. Ce que le projet y gagne est symétrique : des co-décideurs réels au lieu d’une neutralité déclarée. Une gouvernance ne se décrète pas neutre ; elle le devient quand plusieurs acteurs, aux intérêts distincts, peuvent chacun bloquer une dérive. Les organisations qui veulent participer aux travaux de gouvernance (RFC, certification, tableau de bord des contributions) peuvent se signaler dès maintenant via le contact du site. Les termes sont sur la table ; ils sont faits pour être discutés publiquement.

Sources

1. Linux Foundation, « Developer Certificate of Origin, version 1.1 », 2004, https://developercertificate.org/
2. Apache Software Foundation, « Corporate Governance Overview », 2024, https://www.apache.org/foundation/governance/
3. Eclipse Foundation, « About the Eclipse Foundation », 2024, https://www.eclipse.org/org/
4. Linux Foundation Europe, « About Linux Foundation Europe », 2024, https://linuxfoundation.eu/
5. Open Source Initiative, « The Open Source Definition », 2007, https://opensource.org/osd
6. OpenSSF, « Best Practices Badge Program », 2024, https://www.bestpractices.dev/