Platform governance
Les règles de gouvernance bornent ce qu’une extension peut lire, produire, modifier ou divulguer. Elles sont indépendantes du statut commercial du partenaire et restent applicables à chaque exécution.
Pourquoi la gouvernance est contractuelle
Une extension agit au croisement de plusieurs systèmes qui peuvent être chacun source de vérité pour une partie du métier. Sans règles explicites, une synchronisation ou un webhook pourrait transformer une observation externe en mutation arbitraire de la plateforme.
Ormuz traite donc l’autorité, l’accès, la protection des données et le risque comme des dimensions de contrat, pas comme des conventions de bonne conduite implicites.
Quatre plans distincts
| Plan | Question | Exemple |
|---|---|---|
| Autorité métier | Qui a le droit d’établir ce fait ou cette transition ? | Un PSP établit un mouvement de paiement externe ; Ormuz ne le fabrique pas. |
| Accès plateforme | Cette exécution a-t-elle le droit de lire ou écrire l’objet concerné ? | Un node qui recherche lui-même une exposition de crédit doit déclarer un accès en lecture. |
| Protection des données | Comment la valeur doit-elle être classifiée, persistée et révélée ? | Un bearer token est secret et ne doit pas apparaître dans l’audit générique. |
| Risque d’exécution | Quel est le niveau maximal de conséquence d’un Tool ? | Un email envoy é à l’extérieur reste high même si son contenu est banal. |
Ces plans se combinent sans se remplacer. Une donnée peut être très confidentielle mais provenir d’un Tool low ; une mutation peut être high tout en portant uniquement des données normal.
Principes par défaut
- Pas d’accès générique : une extension reçoit uniquement les objets et capacités nécessaires à son contexte.
- Pas d’autorité par réputation : certification ou partenariat ne donnent aucun pouvoir métier implicite.
- Fail closed : une autorité ou une classification ambiguë ne doit pas être assouplie automatiquement.
- Consentement visible : lorsqu’un processus fournit explicitement un objet complet à un node, ce binding matérialise le consentement fonctionnel à cet input.
- Accès opaque déclaré : une lecture ou écriture active non visible dans les bindings exige une permission explicite.
- Provenance durable : origine, identité externe et mappings servent à reconstruire d’où vient une information sans créer un second système d’autorité.