Publié le 28 septembre 2026 à 11:00 · Publication originale
Il possède l'identité nécessaire pour appeler l'API financière.
Mais identité et autorisation sont deux problèmes différents.
L'entreprise peut accepter les remboursements jusqu'à 5.000 euros, exiger une validation humaine au-delà, interdire certains comptes et appliquer une règle différente lorsqu'une anomalie de fraude existe.
Ces décisions pourraient être dispersées dans le code de plusieurs applications.
Une autre architecture les extrait.
Open Policy Agent, ou OPA, est un moteur open source capable de recevoir des données sur une situation puis d'évaluer une politique pour produire une décision.
L'application reste chargée d'appliquer cette décision.
Cette séparation crée deux composants distincts: le point de décision de politique et le point d'application.
Le premier détermine ce qui est autorisé. Le second bloque ou exécute l'action.
OPA peut être placé à proximité des applications afin d'éviter qu'une décision d'autorisation dépende systématiquement d'un service central distant.
Les politiques et les données nécessaires à leur évaluation peuvent être distribuées sous forme de "bundles". Une nouvelle règle peut ainsi être propagée sans redéployer chaque application qui l'utilise.
Ces bundles peuvent être signés cryptographiquement. Une instance OPA configurée pour vérifier leur signature refuse d'activer un bundle dont l'authenticité n'est pas validée.
La gouvernance acquiert alors des propriétés habituellement associées au logiciel: version, distribution, test, signature et déploiement.
Un autre mécanisme devient possible.
OPA peut produire un identifiant unique pour chaque décision et enregistrer la version du bundle utilisée, l'entrée reçue et le résultat retourné.
Après un incident, l'entreprise peut donc rechercher davantage que "qui avait accès?".
Elle peut retrouver quelle version de quelle politique a autorisé une action précise.
ULTRA®
Un journal de décisions peut lui-même devenir une fuite de données.
Pour expliquer pourquoi une opération a été autorisée, OPA peut enregistrer l'entrée utilisée par la politique. Cette entrée peut contenir identité, ressource, attributs métier ou autres informations sensibles.
OPA permet donc d'effacer ou masquer certains champs avant l'expédition des journaux.
Mais une difficulté plus profonde apparaît dans un système distribué.
Deux instances peuvent momentanément exécuter deux révisions différentes d'une politique pendant sa propagation.
La décision possède alors une dimension temporelle: "autorisé" ne suffit plus. Il faut savoir selon quelle révision.
Conseil: conserver ensemble décision_id, trace_id et révision du bundle. OPA sait relier ses décisions aux traces OpenTelemetry.
Une politique sans provenance permet de connaître la règle actuelle.
Elle ne permet pas nécessairement de reconstruire la règle réellement appliquée au moment de l'incident.