<aside> 🛡️

RiskOps est un plan de contrôle transverse, jamais le propriétaire opérationnel du projet. Un projet conserve ses objectifs, son budget, son backlog, ses responsables et son exécution ; RiskOps normalise les risques, contrôles, incidents, traitements, preuves et escalades qui doivent traverser les frontières.

</aside>

Contrat universel

1. L’objet propriétaire décrit son contexte : projet, pôle, entité, œuvre, système, événement ou capacité.
2. Trou Noir / Cadastre identifie l’objet et permet de ne pas créer une seconde identité pour le même projet ou système.
3. ARIANE transporte le lien et la provenance entre l’objet, son aspect RiskOps, la preuve, le contrôle et le système d’exécution.
4. RiskOps qualifie le risque : famille, gravité, vraisemblance si applicable, contrôles préventifs, traitement, preuve attendue, autorité d’escalade et conditions de fermeture.
5. Le propriétaire exécute les mesures dans son PMO ou son système métier. RiskOps ne devient pas un second backlog du projet.
6. Airtable RiskOps conserve le registre structuré des risques, incidents, traitements et preuves ; Notion conserve doctrine et fiches ; Monday RiskOps porte uniquement les actions RiskOps transverses ou d’escalade.
7. La BOÎTE NOIRE du projet consigne les gates structurants lorsqu’un risque bloque, modifie ou conditionne une décision.

Identité de liaison minimale

Chaque intégration doit pouvoir pointer vers :

• object_id ou code canonique de l’objet propriétaire ;
• type d’objet ;
• système/PMO propriétaire ;
• risk_id ou incident_id RiskOps ;
• provenance / preuve ;
• contrôle ou traitement applicable ;
• responsable d’exécution côté propriétaire ;
• autorité d’escalade ;
• statut de la liaison.