GOVERNANCE.md

Gouvernance — Picarones

Politique de gouvernance institutionnelle. Contexte historique : docs/archive/2026-audits/remediation-plan.md.

Ce document explicite comment Picarones est maintenu et fait évoluer : qui décide, à quelle cadence, avec quels engagements de service. Il complète :

• CONTRIBUTING.md — comment contribuer techniquement (branches, tests, style) ;
• CODE_OF_CONDUCT.md — comportement attendu dans les espaces du projet ;
• SECURITY.md — signalement de vulnérabilités ;
• .github/CODEOWNERS — qui est reviewer par défaut sur quel chemin.

Rôles

BDFL / Maintainer principal

À ce stade du projet (mai 2026, 5000+ tests, 1.x), Picarones est maintenu en BDFL par @maribakulj. Toute décision finale sur les contrats d'API publique, les choix éditoriaux (palette, règle de neutralité du moteur narratif, conventions de normalisation) et les releases lui incombe.

Reviewers

Tout collaborateur qui a contribué au moins 3 PR mergées en 6 mois peut être ajouté à .github/CODEOWNERS comme reviewer sur les paths qu'il connaît bien. La promotion est sur invitation par le BDFL après accord du contributeur.

Domain experts

Pour les sujets qui exigent une expertise non-tech :

• Paléographie / archivistique : cas d'études, prompts médiévaux, glossaire historique, profils de normalisation diplomatique.
• Accessibilité : déclarations RGAA, audits manuels NVDA/VoiceOver, retours WCAG.
• Linguistique computationnelle : métriques NER, taxonomies d'erreurs, recherchabilité fuzzy.

Ces personnes sont nommées dans CODEOWNERS sur les chemins qui les concernent et leur revue est systématique — pas pour bloquer le merge mais pour garantir la qualité éditoriale.

Évolution vers un comité de pilotage

Si Picarones atteint > 5 mainteneurs actifs ou > 5 institutions adoptantes documentées, la gouvernance bascule en comité de pilotage (steering committee) avec un vote à la majorité simple sur :

• ajout/retrait d'un mainteneur ;
• ruptures d'API publique (breaking changes au-delà d'un tag majeur) ;
• changement de licence ;
• évolution majeure de la philosophie éditoriale (neutralité du rapport, ouverture aux modules contribués externes).

Cette évolution sera entérinée par une PR sur ce fichier signée par tous les mainteneurs actifs.

Cadence de release

Type	Cadence cible	Déclencheur
Patch (1.2.x)	À la demande	Bug fix, correctif sécurité, doc
Mineure (1.x.0)	Mensuelle	Sortie d'au moins un sprint d'audit ou d'un nouveau feature group
Majeure (x.0.0)	Trimestrielle	Breaking changes API publique cumulés
Hotfix sécurité	< 72 h	CVE critique, problème de confidentialité

La cadence est un objectif, pas un engagement contractuel. Une release mineure peut être reportée si le travail planifié n'est pas prêt — la stabilité prime sur le calendrier.

Procédure release détaillée : docs/operations/release-process.md.

SLO de réponse

Type d'événement	SLO en jours ouvrés
Triage initial d'une issue	5
Réponse à une PR (1ère revue)	7
Triage initial d'une faille de sécurité (cf. SECURITY.md)	2
Correctif d'une faille HIGH/CRITICAL	5
Release patch après correctif sécurité	3

Ces SLO sont best-effort : Picarones est maintenu sur du temps disponible, sans garantie commerciale. Pour des SLO contractualisés, contractualiser un support institutionnel via une convention de prestation (cf. modalités à définir au cas par cas).

Politique de breaking changes

L'API publique de Picarones est définie par docs/reference/api-stable.md. Elle inclut :

• les symboles ré-exportés depuis picarones/__init__.py ;
• les commandes CLI picarones X documentées dans le README ;
• les endpoints HTTP listés dans le README ;
• la structure du JSON de résultats (BenchmarkResult.as_dict()).

Garanties :

• À l'intérieur d'un tag majeur (1.x), aucun de ces contrats ne change de manière incompatible.
• Une dépréciation est annoncée au moins 2 versions mineures avant suppression, avec DeprecationWarning à l'appel et entrée dans le CHANGELOG.md en section Deprecated.
• Un breaking change exige un bump majeur (1.x → 2.0) et une section BREAKING CHANGES dans la release notes.

Hors API publique (modules internes, helpers privés _*) : aucune garantie de stabilité — utiliser à vos risques.

Procédure de transfert de mainteneur

Si le BDFL doit transférer la maintenance (départ, indisponibilité prolongée, conflit d'intérêt apparu) :

1. Annonce : issue publique sur le repo + entrée CHANGELOG.
2. Période de transition (≥ 3 mois) : nouveau mainteneur en shadow review, le BDFL valide.
3. Bascule : transfert des droits GitHub (admin), update de CODEOWNERS, update du CITATION.cff (auteurs).
4. Communication : annonce à la communauté HuggingFace Space, PyPI, et institutions adoptantes connues.

Si aucun successeur n'est trouvé en 6 mois, le projet entre en mode archive : tag archived: 2026-XX, dernière release de sécurité, README enrichi d'un encart « projet en cherche d'un nouveau mainteneur — fork bienvenu ».

Conflicts of interest

Picarones benchmarke des fournisseurs cloud commerciaux (OpenAI, Anthropic, Mistral, Google, Microsoft Azure). Pour qu'un papier ou une étude qui s'appuie sur ses analyses Pareto coût soit citable sans suspicion, nous déclarons :

Affiliations des mainteneurs

Les mainteneurs déclarent leurs affiliations académiques et industrielles dans la liste suivante (mise à jour à chaque ajout de mainteneur dans CODEOWNERS) :

• @maribakulj : aucune affiliation salariée chez un fournisseur OCR/LLM/cloud benchmarké par Picarones. Aucune participation capitalistique dans une entreprise concurrente ou cliente d'un des fournisseurs.

Indépendance des données de pricing

Les valeurs dans picarones/data/pricing.yaml :

• proviennent exclusivement des tarifs publics affichés sur les sites des fournisseurs (sans NDA, sans accord commercial) ;
• sont datées explicitement (meta.last_updated, meta.valid_until) ;
• peuvent être surchargées par l'utilisateur via ReportGenerator(..., pricing=...) pour refléter ses propres tarifs négociés.

Aucun fournisseur ne finance, sponsorise ou influence le contenu de cette table. Si un fournisseur souhaite corriger une valeur, il doit ouvrir une PR publique avec source vérifiable.

Indépendance éditoriale du moteur narratif

Le moteur narratif émet des Fact traçables au JSON d'entrée. Aucune logique privilégie un fournisseur sur un autre :

• les seuils des détecteurs sont éditoriaux (publics dans core/facts.py) et symétriques entre moteurs ;
• la philosophie « Picarones mesure et classe — il ne tranche pas » garantit l'absence de recommandation prescriptive.

Toute évolution de cette politique exige un PR signé par la totalité des mainteneurs actifs.

Sponsoring et financement

Si Picarones reçoit un jour un financement institutionnel ou commercial (subvention, prestation, sponsorship), le donateur sera listé en pied du README.md avec mention explicite « Picarones n'est pas obligé envers ses sponsors et conserve son indépendance éditoriale ». Toute restriction d'usage demandée par un sponsor sera publiquement refusée et déclenchera l'annulation du sponsoring.

Ressources

• CONTRIBUTING.md — guide technique pour PR
• CODE_OF_CONDUCT.md — Contributor Covenant 2.1
• SECURITY.md — signalement de vulnérabilités
• docs/operations/accessibility.md — engagement WCAG 2.1 AA
• docs/operations/release-process.md — cycle de release

---

Dernière mise à jour : 2 mai 2026.