Les règles comme données

COADF P-8, tel que publié : les règles auxquelles une décision est mesurée sont des données, le moteur qui les évalue ne change pas quand une règle change, et un enregistrement de décision est lié à la version du jeu de règles qui l'a produit, ce qui prolonge la trace de P-4 jusqu'à la provenance des règles. COADF nomme lui-même l'état de la technique : des jeux de règles rechargeables, avec des enregistrements de décision liés à leur version, existent déjà, et Open Policy Agent en est l'exemple évident.

COADF ne publie pas une partie de P-8, et le dit sur sa page des principes. Rien sur cette page ne décrit cette partie. Les exemples utilisent un sujet volontairement générique : les fonctionnalités qu'un environnement de déploiement peut activer.

Les règles changent plus souvent que le code, et pour d'autres raisons : les orientations d'un régulateur, un contrat, un nouveau marché. Quand une règle vit dans le code, chaque changement est une livraison, plusieurs services s'éloignent les uns des autres, et personne ne peut dire quelle version d'une règle a produit une décision prise au trimestre dernier.

Le dernier problème est le plus coûteux. Une décision qu'on ne peut pas reconstruire ne peut pas être expliquée, et une décision qu'on ne peut pas expliquer ne peut pas être défendue.

La forme est petite : l'application pose sa question à travers une interface qui lui appartient, l'interface consulte un matériau de politique versionné, et la décision qui revient porte la révision de ce matériau.

• Une interface de politique qui appartient à l'application. L'application pose une question dans ses propres termes, et le moteur se trouve derrière un adaptateur.
• Un matériau de politique versionné. Les règles et leurs données sont des artefacts avec un identifiant par révision, déployés indépendamment de l'application.
• La révision sur chaque décision. L'enregistrement de décision porte la réponse, la révision, et assez de l'entrée pour la rejouer.
• Les anciennes révisions restent récupérables. Rejouer demande le matériau tel qu'il était, pas tel qu'il est.
• Une évaluation reproductible. Une politique qui va chercher des données ou lit l'horloge pendant qu'elle évalue ne peut pas être rejouée à partir de sa seule entrée et de sa seule révision. Il faut transmettre ces faits comme entrée, et les consigner.
• Le moteur versionné lui aussi. Une mise à jour du moteur peut changer le sens : OPA 1.0 a rendu obligatoires les mots-clés if et contains, par exemple. Consigner la version du moteur partout où le rejeu compte.
• Une défaillance maîtrisée. Une révision inconnue, une révision manquante, une réponse mal formée ou un moteur injoignable produit une issue que le responsable de la règle a choisie à l'avance, jamais une valeur par défaut non consignée. Il n'existe pas de bonne réponse universelle : refuser l'action est juste pour une règle d'accès à une fonctionnalité comme celle de l'exemple du profil Python ; pour une autre décision, son responsable définit ce que signifie une défaillance, et consigne ce choix.

Options technologiques

• Open Policy Agent. Un moteur de politiques généraliste qui découple les décisions de politique de leur application, avec des politiques écrites en Rego. Un bundle peut porter un manifeste avec une révision, et les journaux de décisions d'OPA consignent la révision du bundle utilisée pour chaque décision. Son API REST renvoie un decision_id quand la journalisation des décisions est activée.
• Des tables de règles qui appartiennent à l'application. Des lignes avec une révision et une période d'effet, évaluées par un code qui ne change pas quand les lignes changent.
• Des tables de décision et DMN, là où les responsables des règles sont des analystes plutôt que des développeurs.
• D'autres langages et moteurs de politiques. OPA est ici un exemple. COADF ne l'exige pas.

• Des règles dans le code, avec la révision du build consignée sur chaque décision. Praticable pour un petit système. Chaque changement de règle est alors une livraison, et le moteur change chaque fois qu'une règle change, ce que P-8 exclut.
• Des services de feature flags. Proches des politiques, et souvent sans provenance des décisions : la configuration de flags qui a répondu à une requête donnée n'est souvent pas consignée.
• Un service de décision détenu par une autre équipe, consommé via la même interface, avec la révision dans sa réponse.

• Le pattern donne la provenance, pas la justesse. Une règle fausse bien versionnée reste fausse.
• Il ne couvre pas les parties de P-8 que COADF ne publie pas, ni la façon dont une décision de politique rencontre un autre contrôle.
• Open Policy Agent est un moteur d'exemple. Rien ici n'en fait une exigence.