# Gouvernance — Picarones > Sprint A10 du plan de remédiation institutionnelle > ([`docs/audits/remediation-plan-2026-05.md`](docs/audits/remediation-plan-2026-05.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`](CONTRIBUTING.md) — comment contribuer > techniquement (branches, tests, style) ; > - [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) — comportement attendu > dans les espaces du projet ; > - [`SECURITY.md`](SECURITY.md) — signalement de vulnérabilités ; > - [`.github/CODEOWNERS`](.github/CODEOWNERS) — qui est reviewer par > défaut sur quel chemin. ## Rôles ### BDFL / Maintainer principal À ce stade du projet (mai 2026, ~3 600 tests, 1.x), **Picarones est maintenu en BDFL** par [@maribakulj](https://github.com/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`](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`](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 (Sprint A10, M-10) 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` depuis Sprint A8) ; - 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 (Sprint 19+) é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`](CONTRIBUTING.md) — guide technique pour PR - [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) — Contributor Covenant 2.1 - [`SECURITY.md`](SECURITY.md) — signalement de vulnérabilités - [`ACCESSIBILITY.md`](ACCESSIBILITY.md) — engagement WCAG 2.1 AA - [`docs/operations/release-process.md`](docs/operations/release-process.md) — cycle de release --- *Dernière mise à jour : 2 mai 2026 (Sprint A10).*