Trames et règles de fonctionnement intégrées au processus
Le livre de règles ne devrait pas être un oracle distant
Les règles métier sont généralement présentées comme quelque chose de simple. Un client est éligible ou ne l’est pas. Une transaction passe ou échoue. Un devis bénéficie d’une remise. Un utilisateur peut accéder à une ressource. Puis les règles s’étoffent, les exceptions arrivent, la conformité demande des preuves, et soudain le simple contrôle est devenu un service de politiques, un interpréteur, un cache, un travail de rapprochement et une réunion avec un fournisseur. Formidable. Nous avons réinventé un feu tricolore avec un abonnement.
Lattice part d’une idée moins théâtrale : le livre de règles devrait s’exécuter là où la décision est prise. La page actuelle de Lattice décrit un composant Rust sous licence Apache 2.0 qui compile les règles à l’avance en un artefact binaire mappable en mémoire. L’évaluation est une traversée d’arbre compacte dans le processus. L’artefact contient des sommes de contrôle. Les mêmes règles et les mêmes données sont décrites comme produisant la même réponse sur les cibles prises en charge. Aucun service supplémentaire ne doit se trouver sur le chemin d’une décision. C’est la forme utile.
Ce n’est pas une opposition à la gouvernance. C’est tout le contraire. La gouvernance s’affaiblit lorsque les règles vivent loin des systèmes qui les utilisent et que les explications doivent être reconstruites plus tard. Un livre de règles versionné, compilé, doté d’une somme de contrôle, chargé dans le processus et rejouable donne aux auditeurs quelque chose de plus concret que « nous avons demandé au service de politiques et il a dit non ». Cette phrase peut être vraie. Elle ne suffit pas.
Compiler une fois, cesser d’interpréter pour toujours
Le pipeline de la page est clair : rédiger, compiler, empaqueter, évaluer. Les règles et les contraintes vivent à côté du code source et de l’historique des versions. La compilation classe les contraintes et fixe le moteur de résolution. L’empaquetage produit un artefact binaire avec des sommes de contrôle XXH3-64 sur l’en-tête, le contenu et le fichier. Le chargement est un appel système, pas une analyse syntaxique. L’évaluation traverse l’arbre empaqueté dans le processus. Cette séquence compte parce qu’elle transforme le travail à l’exécution en travail à la compilation.
Les interpréteurs sont pratiques jusqu’à ce qu’ils se trouvent sur chaque requête. Un service de politiques distant est pratique jusqu’à ce que le saut réseau fasse partie du budget de latence et que le service devienne une chose de plus qui peut tomber en panne. Un JIT est pratique jusqu’à ce que différents hôtes, versions ou optimiseurs fassent partie de l’explication. Lattice est volontairement moins dramatique. Il dit que le livre de règles devrait devenir un fichier que l’application peut mapper et exécuter de manière déterministe. Le chemin de la requête ne devrait pas redécouvrir les règles à chaque fois.
La page rapporte des chiffres de référence pour le chemin d’artefact actuel, y compris un nombre d’évaluation à chaud, une recherche à froid après mmap et des chiffres de débit. Ces nombres appartiennent à la page et à son contexte de référence, pas à un mythe qui devrait être copié dans chaque future version. Le point d’ingénierie durable est la conception : un artefact empaqueté, une évaluation locale au cache, aucun analyseur syntaxique sur le chemin critique, aucun allocateur sur le chemin critique et aucun saut réseau par décision.
Une API de règles unique ne devrait pas masquer la réalité des solveurs
Les règles ne sont pas toutes identiques. Certaines sont de purs contrôles booléens. Certaines combinent logique et arithmétique. Certaines sont des programmes linéaires. Certaines nécessitent des décisions entières. Certaines sont des contraintes à domaine fini. Certaines sont des problèmes de chemin ou des contraintes souples. Un moteur de règles sérieux ne devrait pas forcer chaque cas à passer par un seul trou de serrure en forme de solveur. Il devrait classer la règle et l’acheminer vers le bon moteur.
La page Lattice regroupe SAT, SMT, LP, MIP, CP, A* et MaxSAT sous une seule API de règles. SAT couvre les règles booléennes pures et les indicateurs de fonctionnalités. SMT gère les théories mixtes comme la logique, l'arithmétique, les tableaux et les bitvectors. LP couvre l'optimisation continue. MIP ou ILP gère les décisions à variables entières. CP gère les domaines finis et les contraintes non linéaires. A* et MaxSAT couvrent les problèmes de chemins et de contraintes souples. La phrase produit importante est que l'appelant écrit des règles, pas des appels de solveur.
Cela compte pour la maintenabilité. Si chaque équipe produit écrit son propre code d'intégration spécifique au solveur, la couche de politique devient une collection d'astuces locales ingénieuses. Les astuces locales ingénieuses coûtent cher lors des audits, car personne ne se souvient laquelle était ingénieuse et laquelle n'était qu'un vendredi. Une surface de règles classifiée donne aux équipes un endroit unique pour inspecter la règle, sa classe de backend, l'artefact compilé et la réponse qu'elle a produite.
La latence est aussi une règle métier
Les systèmes de décision adorent prétendre que la latence est une considération technique secondaire. Ce n'est pas le cas. Si un contrôle de conformité s'exécute sur chaque transaction, la latence fait partie du produit. Si le contrôle d'accès se trouve à une passerelle, la latence fait partie de la sécurité. Si la tarification s'exécute au moment du devis, la latence fait partie du chiffre d'affaires. Si le filtrage de fraude s'exécute avant le règlement, la latence fait partie du risque. Une règle lente peut être correcte et néanmoins opérationnellement fausse.
C'est pourquoi l'évaluation en processus compte. La page Lattice actuelle oppose les contrôles interprétés ou distants à l'échelle de la milliseconde au chemin de l'artefact compacté, et elle souligne le coût des sauts réseau, des services sidecar et des lacunes d'audit. Le chiffre exact d'un benchmark importe moins que la forme du coût. Si une requête nécessite dix contrôles, l'ancien chemin peut survivre. Si une requête nécessite dix mille contrôles, l'ancien chemin commence à occuper une place dans le budget de la requête. À ce stade, le moteur de règles n'est plus un composant. C'est ce que les utilisateurs attendent.
Le bénéfice opérationnel n'est pas seulement la vitesse. C'est moins de pièces mobiles. Pas de service de politique supplémentaire. Pas de chemin réseau à maintenir en bonne santé. Pas de processus d'analyse séparé. Pas de cache séparé à expliquer. Le livre de règles se trouve avec l'application, à l'intérieur de la juridiction et de la frontière opérationnelle que vous contrôlez déjà. C'est moins glamour qu'un tableau de bord. C'est aussi moins susceptible de réveiller quelqu'un.
La réponse d'audit est la relecture
Lorsqu'un auditeur demande pourquoi une décision a été refusée, la pire réponse est un paragraphe reconstitué de mémoire. La deuxième pire réponse est une capture d'écran. La réponse utile est : cette version du livre de règles a été exécutée sur cette entrée et a produit cette sortie, voici la somme de contrôle de l'artefact, voici la règle, voici la relecture. Lattice est conçu pour rendre cette réponse possible.
La page associe Lattice aux décisions automatisées du RGPD, à la transparence exigée par l’AI Act européen, à la résilience opérationnelle de DORA et à l’assurance de la chaîne d’approvisionnement de NIS2. Ces étiquettes peuvent devenir de la poudre aux yeux si le système ne peut rien montrer de concret. Le concret, c’est l’artefact. Un recueil de règles compilé peut être nommé. Une somme de contrôle peut détecter toute altération. Les entrées journalisées peuvent rejouer la décision. Une sortie bit pour bit identique signifie qu’un basculement ne devrait pas modifier silencieusement une réponse. L’exécution en processus dans des systèmes contrôlés permet d’éviter le problème du service externe sur le chemin de décision.
Où l’intégrer en premier
Lattice est le plus pertinent aux points de décision qui surviennent souvent et qui nécessitent des preuves ultérieures. Les contrôles de conformité sur les transactions. La tarification et l’éligibilité au moment de la soumission d’un devis. Les décisions d’accès aux passerelles. Le filtrage de la fraude avant le règlement. Les contrôles d’éligibilité dans le secteur public. Les étapes de souscription en assurance. Les autorisations de flux de travail internes. Ce sont des cas où un simple oui ou non ne suffit pas. Le système doit savoir quelle version du oui ou du non a été appliquée.
Il convient également aux situations où la même décision doit rester identique d’un serveur à l’autre. Un basculement ne devrait pas modifier un résultat de conformité. Un déploiement régional ne devrait pas interpréter une règle différemment parce qu’une version de bibliothèque a dérivé. Une relecture d’audit ne devrait pas dépendre de l’existence du même service hébergé par un fournisseur. Le recueil de règles devrait être suffisamment portable pour être exécuté là où l’organisation en a le contrôle, et suffisamment explicite pour que les coûts de changement restent faibles.
C’est aussi pour cela que l’open source compte ici. Un moteur de règles qui participe à la conformité, à l’accès, à la tarification ou à la fraude n’est pas une dépendance décorative. Il fait partie du plan de contrôle. Si personne au sein de l’organisation ne peut l’inspecter, l’épingler, le tester et le conserver, alors le recueil de règles n’est pas vraiment le sien. C’est une autorité louée.
Ce qu’il faut examiner avant de l’adopter
D’abord, identifiez les points de décision. Ne commencez pas par une migration de plateforme. Commencez par un recueil de règles qui fait mal aujourd’hui. À quelle fréquence s’exécute-t-il ? Que protège-t-il ? Qui demande pourquoi ? Que se passe-t-il si le service est indisponible ? Quelles preuves sont disponibles six mois plus tard ?
Ensuite, examinez la forme des règles. Les contraintes sont-elles booléennes, arithmétiques, linéaires, entières, à domaine fini, de type chemin ou souples ? Quelle classe de moteur devrait les prendre en charge ? Si la règle ne peut pas expliquer pourquoi elle est orientée vers une famille de solveurs, l’abstraction est trop magique.
Troisièmement, examinez la discipline des artefacts. Où la règle source est-elle stockée ? Quelle compilation a produit l’artefact ? Quelle somme de contrôle a été chargée ? Quelle version d’application l’a utilisée ? Quelles entrées ont été journalisées ? Quel chemin de relecture prouve la réponse ? Si la réponse est répartie entre trois systèmes et une personne nommée Jan, le recueil de règles n’est pas encore un objet d’audit. C’est une tradition.
La leçon
Lattice est une histoire de moteur de règles, mais c’est surtout une histoire de contrôle. Compilez le recueil de règles avant la requête. Empaquetez-le dans un artefact que l’application peut mapper en mémoire. Vérifiez l’artefact avant de le charger. Acheminez les contraintes vers la bonne famille de solveurs. Évaluez en processus. Rejouez plus tard avec la même entrée et la même version du recueil de règles.
Ce n’est pas glamour. Tant mieux. Les règles métier ne devraient pas être glamour. Elles devraient être ennuyeuses, rapides, explicites et vérifiables. Les systèmes de décision importants d’une entreprise ne devraient pas dépendre d’oracles distants, de boucles d’analyse syntaxique et d’archéologie d’audit. Ils devraient porter leurs recueils de règles comme des infrastructures.
Le recueil de règles ne devrait pas être un oracle distant. Il devrait être quelque chose que le système peut exécuter, nommer et rejouer.