Ce que c’est
Moteur de politiques généraliste, projet diplômé de la fondation cloud native, qui sépare la décision de l’application.
Ce qu’on y travaille dans le laboratoire
- ·Externaliser plafonds, vélocité et règles d’autorisation
- ·Écrire des politiques testables
- ·Éviter la dispersion des règles dans le code
Parcours de maîtrise
Huit niveaux, de la première règle au moteur de politiques d’une plateforme de paiement — cent règles et une trentaine de travaux pratiques au projet final.
Niveau 1 · 1 semaine · Livrable : premier laboratoire de politiques
Fondamentaux
Comprendre la séparation entre la décision et son application.
- Point de décision et point d’application : deux rôles distincts
- Politiques écrites séparément du code applicatif
- Premières règles et évaluation sur des données structurées
- Outils d’évaluation et bac à sable
Niveau 2 · 2 semaines · Livrable : bibliothèque de règles
Rego Developer
Maîtriser le langage de politiques.
- Syntaxe, règles, objets, tableaux, ensembles
- Fonctions et primitives du langage
- Tests automatisés des règles
- Politique d’autorisation de paiement rendant trois décisions : autoriser, refuser, examiner
Niveau 3 · 2 semaines · Livrable : bibliothèque de politiques de paiement
Payment Policy Engineering
Écrire les règles métier propres au paiement.
- Plafonds, canaux, marchands
- Pays et devises autorisés
- Profil client et seuils de risque
- Horaires d’exploitation et règles propres à un dispositif
Niveau 4 · 2 semaines · Livrable : laboratoire proxy et politiques
Autorisation d’interface
Appliquer la décision au niveau du proxy plutôt que dans chaque service.
- Autorisation externalisée auprès du proxy de service
- Contrôle d’accès contextuel : identité, rôle, institution, portée, canal
- Point d’accès, méthode, montant, devise, niveau de risque
- Protection des interfaces de la couche de services
Niveau 5 · 2 semaines · Livrable : laboratoire de politiques d’infrastructure
Politiques d’infrastructure
Étendre la logique aux plateformes qui hébergent les paiements.
- Politiques appliquées à l’admission des charges
- Contrôles en amont du déploiement
- Bonnes pratiques d’orchestration de conteneurs
- Intégration au flux de déploiement déclaratif
Niveau 6 · 2 semaines · Livrable : jeu de politiques de conformité
Conformité en code
Traduire les exigences réglementaires en règles exécutables.
- Exigences de l’industrie des cartes et normes de sécurité de l’information
- Contrôles techniques associés à chaque exigence
- Preuves produites automatiquement et reporting
- Fiche de contrôle : exigence, contrôle, source, entrée, décision attendue, preuve, responsable, version
Niveau 7 · 3 semaines · Livrable : laboratoire d’intégration
Intégration dans la chaîne de paiement
Décider en temps réel, au cœur de la chaîne.
- Construction du contexte de décision à partir d’une transaction réelle
- Politiques d’accès participant, de plafond, de routage, de devise
- Politiques de risque, géographique, temporelle
- Décision de bout en bout sur un message normalisé
Niveau 8 · 3 semaines · Projet final : moteur de politiques de paiement
Policy Platform Engineer
Faire du moteur de politiques une plateforme interne.
- Dépôt de politiques, tests automatisés, paquets versionnés
- Chaîne d’intégration continue et distribution des politiques
- Observabilité des décisions, performance et haute disponibilité
- Comportement en cas d’indisponibilité : ouvrir ou fermer, et gouvernance associée
Le parcours se valide sur preuve. Chaque niveau se franchit par une démonstration en conditions réelles devant un jury, avec un critère d’acceptation écrit à l’avance — la règle de la Méthode SAKITI appliquée au laboratoire.
Le principe fondateur
Tout le reste en découle : la décision quitte le code applicatif.
Trois décisions, pas deux
Un moteur de politiques de paiement ne répond pas par oui ou non. La troisième réponse est celle qui évite autant les fraudes que les refus abusifs.
| Décision | Ce qu’elle déclenche |
|---|---|
| Autoriser | La transaction poursuit son chemin |
| Refuser | La transaction est arrêtée, avec un motif restituable au client |
| Examiner | La transaction est suspendue et remise à un opérateur — c’est ici que s’articulent le moteur de politiques et l’orchestration durable |
Ce que le moteur reçoit pour décider
Le contexte de décision est construit en amont. Sa qualité fait celle de la politique.
- 01Identité, rôle, institution appelante, portée d’accès
- 02Canal, point d’accès, méthode
- 03Montant, devise, pays du débiteur et du créditeur
- 04Niveau de risque, dispositif de paiement, horodatage
La fiche de contrôle du niveau 6
Ce qui transforme une règle technique en preuve opposable à un auditeur. Onze champs, à documenter pour chaque politique.
- 01Identifiant de l’exigence et identifiant du contrôle
- 02Source réglementaire ou normative, description
- 03Données d’entrée, politique appliquée, décision attendue
- 04Preuve produite, responsable, version, date
La question qui décide de l’architecture
Elle se pose au niveau 8, et elle n’a pas de bonne réponse universelle.
Que se passe-t-il quand le moteur de politiques est indisponible ? Ouvrir — laisser passer les transactions sans contrôle — ou fermer — les bloquer toutes ? La réponse dépend du service, du montant et du risque, et elle doit être décidée, documentée et testée avant la panne, jamais pendant.
Les huit compétences cibles
Chaque niveau franchi correspond à un rôle.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | www.openpolicyagent.org |
| Dépôt public | github.com/open-policy-agent/opa |
À vérifier au moment de la qualification. Licence exacte, version courante, activité du projet, gestion des vulnérabilités et conditions de support évoluent. Le statut affiché sur ce radar ne vaut ni certification, ni aptitude au déploiement en production dans une infrastructure de paiement.
Les autres briques du domaine
OpenSanctions · Moov Watchman · Cedar · Drools · Apache Flink