Journal 'Règle'. Organiser son traitement. Sans se désorganiser.

Sommaire

• 1. "Pourquoi diable vas-tu nous parler de hype… ?"
• 2. "En gros tu nous présentes un POC ? Pour quel principal usage ?"
• 3. "Et globalement ça fonctionne comment ?"
• 4. Fantastique. Pour essayer on fait comment ? Où puis-je l'utiliser ?
• 5. "C'est sérieux ça, comme projet ?"

Bonjour à tous,

D'abord une intro, un peu longue, mais pour mieux cibler après le sujet de ce journal.

1. "Pourquoi diable vas-tu nous parler de hype… ?"

Il n'est pas toujours évident de représenter un traitement "métier" (un besoin) dans un processus informatique. Loin de là : la forte accélération de la numérisation de nos sociétés ces dernières années n'empêche pas les mêmes questions de se poser, encore et encore, tant pour la petite que la grande organisation ; personnelle ou collective. Au premier chef d'avoir des outils adaptés à chaque situation, à chaque personne ou besoin.

Face à cela, quelques réponses : résumons-les en quelques grandes lignes (les puristes me pardonneront les raccourcis).

Si le "low/no-code" semble progresser depuis quelques années, au moins dans les esprits, il a pourtant toujours fait partie intégrante de l'informatique. Certainement pas sous sa forme moderne, portée par l'évolution des IHM, des pratiques, etc. Sa forme première a été de faire une abstraction même de la partie matérielle : le langage de programmation, compilé ou non, est en soi une forme déjà ramassée, conceptuelle et moins "libre" que vous ne pourriez le faire en jouant directement avec les broches de votre processeur. Il y a eu très tôt cette perspective d'en faire davantage avec un même matériel - tout en écrivant moins et en se concentrant sur l'algo.

De langages dits généralistes, la suite a été une forme de langage dite "spécialisée" que sont les DSL - Domain Specific programming Language. Le SQL en est un exemple régulier et on peut débattre à l'infini sur ce que comporte la spécialisation en avantages (ou inconviennents) comparatifs. En résumé, là encore, le DSL "ramasse" (on réduit) sur l'ensemble des possibles précédents, à certains aspects ou opérations informatiques ou algorithmiques - en abandonnant ou en rendant difficile les autres.

Le low-code dans l'approche, est de rendre au plus près d'un utilisateur d'informatique lambda qui n'a (1) pas l'envie et/ou (2) pas la connaissance, le monde de la programmation - sans en avoir la lourdeur. On permet avec un peu de code - souvent dans un langage limité ou un superset d'un langage générique - d'avoir la volonté écrite la plus efficente pour l'exécution d'une tâche - avec une interface la plus conviliale. Le no-code est alors le paroxysme où on se sert bêtement de connecteur ou d'équivalent de portes logiques complexes, pour lier des actions entre elles, au travers de seuls IHM et des boîtes noires.

J'ai déjà placé deux buzz-words, préparez-vous au troisième : l'intelligence artificielle. Ce grand (gros) mot a dans sa première lecture et origine des systèmes experts qui loin d'être dépassés. Ils restent très intéressants sur certains sujets où soit la ressource est limitée ; soit on doit travailler avec un système complément auditable (notamment pour des aspects de conformité).

L'intelligence artificielle dans cette vision, se réduit ou se limite à la capacité à prendre des décisions (moins qu'à repérer des chatons sur une image en apprenant à le distinguer ; vous pouvez me jeter des pavés numériques dans les commentaires, rassurez-vous). Cela porte un nom aux ramifications nombreuses : un système expert. Il est le regroupement à la fois de la connaissance et de la logique - donc de l'expertise humaine - sous une forme qui permet de lui soumettre des situations à résoudre (principe du "chaînage avant") ou de retrouver d'un état final, la situation initiale pour y arriver (principe du "chaînage arrière"). Ainsi que d'autres variantes.

Les systèmes experts complets, généralistes, sont excessivement complexes à mettre en œuvre et à maintenir. Comme tout projet informatique, il faut une ontologie, des spécifications formelles claires, une multitude de profils différents qui ne peuvent pas être que des dév' - fussent-ils excellents. Ces systèmes ont des composants bien délimités pour porter les usages : le moteur d'inférence, la base de faits, etc. ; mais ils regroupent aussi des métiers qu'il faut décomposer, recomposer, traduire dans un DSL.

Il existe une version limitée de tels systèmes et dans une manière que vous trouverez dans des services comme IFTTT par exemple (vous le sentez le lien avec le low/no-code ?). Il s'agit d'un moteur de règles : "prendre" la décision, suivant l'équivalent d'un arbre à résoudre (avec de la logique floue ou une logique booléenne), suivi d'une conséquence (positive : "alors" ; ou négative : "sinon").

Ce que je présente dans cet article est l'esprit de cette introduction :
- un outil qui se veut proche dans l'esprit low-code, donc qu'une personne avec peu de compétences informatiques, puissent aborder sans (trop) partir en courant ;
- un outil qui se base sur un DSL générique (au sens où le domaine n'est pas défini, mais que toutes les opérations de programmation ne sont pas possibles) ;
- un outil qui "prend" des décisions d'actions en calculant des états pour l'application (ou non) de règles.

J'y ai rajouté quelques aspects pour rendre la chose intéressante à l'usage :
- être le plus (ré)utilisable possible, sous la forme d'une quasi-commande Bash ;
- agir seulement sur le STDIN/STDOUT pour communiquer avec son processus parent ;
- être optimisée pour éviter de redémander un état, si la règle précédente n'est pas déclenchée ;
- être réutilisable (un environnement chargée, peut jouer un contexte de règles en se revenant à son état d'origine) ;
- permettre des embranchements (l'équivalent de JUMP).

Ne vous attendez pas à une merveille, je ne suis pas révolutionnaire : je n'en ai ni les moyens, ni la prétention. Je ne suis qu'un passionné de ces sujets qui essaient "des trucs". Un passionné : le terme n'est ici pas gavauldé (votre clémence me sied !).

Voici le résultat.

2. "En gros tu nous présentes un POC ? Pour quel principal usage ?"

Oui.

Un POC en Rust que j'espère de relativement de bonne qualité et qui fait déjà un cappucino léger (le café ne va pas tarder). Blague à part : je n'ai pas la prétention de ré-inventer quoique ce soit et ce que je publie là, issu de quelques dizaines d'heures ces derniers mois, est une version utilisable certes, dont je ne néglige pas les limites.

Pour autant j'estime avoir un PMV - produit minimum viable pour les intimes - qui prend un fichier texte en entrée, parsé, dont on créée tous les objets de manière plutôt efficace en mémoire ; puis qui communique avec son superviseur (qui exécute les "ordres" du moteur de règles) et s'assure une stabilité. Bref il fait le travail.

Quant à l'usage… calculs de prix ou de valeurs ; envoi d'information ; suivi d'événement via le superviseur ; attribution de droits ou de profils pour des comptes ; création d'items ou d'objets à travers des API… je vous laisse l'entière responsabilité de votre imagination. Une idée pour ceux qui en manquent : étendre un outil existant, au travers du sous-processus que représente le programme 'Regle' (son petit nom), pour avoir un format d'entrée supplémentaire.

3. "Et globalement ça fonctionne comment ?"

Le dépôt contient un exemple que j'ai travaillé pour être parlant :

Variable message_bonjour: 
  "bonjour" 

Variable taux_max: 
  25 

Condition "est membre": 
  client.est_membre( 50, "jours" ) 

Condition "offre spéciale": 
  ?"est membre"
  et 
  client.total_historique( ceci_est_une_variable_locale_a_l_executeur, ">", 1000 ) 

Condition "date offre spéciale": 
  date.aujourdhui( "<", "2022-02-16" ) 

Condition "réduction maximale atteinte": 
  panier.total_reduction_verifier( ">", taux_max, "%" ) 

Règle "réduction applicable" (0): 
  Si 
    ?"réduction maximale atteinte" 
  Alors 
    !"" 

Règle "réduction" (10): 
  Si 
    ?"offre spéciale" et ?"date offre spéciale" 
  Alors 
    panier.reduction( 10.5, "%" ), 
    panier.notification( message_bonjour, "bravo, vous êtes un client fidèle" ) 
  Sinon 
    panier.reduction( -5, "%" ) 
  Finalement 
    panier.mettre_a_jour() 

Même sans lire le peu de doc du projet, je pense que vous avez déjà une bonne vision de ce que ça fait et comment. Si vous jouez avec le programme en direct, le dialogue ressemblera à ça :

julien@julien-Vostro-7580:~/Developpement/Regle$ RESOLUTION_TYPE=asservi REGLES_SOURCE=./regles.txt cargo run 
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/Regle`
initier
o
definir "taux_max" 25
o
definir "message_bonjour" "bonjour"
o
executer panier.total_reduction_verifier ">" $taux_max "%"
f
executer client.est_membre 50 "jours"
v
executer client.total_historique $ceci_est_une_variable_locale_a_l_executeur ">" 1000
v
executer date.aujourdhui "<" "2022-02-16"
f
executer panier.reduction -5 "%"
v
executer panier.mettre_a_jour
v
initier
a

En somme, le moteur de règle demande l'exécution de commandes Bash à son superviseur (coucou shlex pour Python), et à partir des règles qui lui sont données, va toutes les parcourir ou en partie, s'il y a des embranchements. L'un est particulier : !"" est par exemple l'appel à une règle qui permet de terminer la résolution (une sorte 'dexit donc).

4. Fantastique. Pour essayer on fait comment ? Où puis-je l'utiliser ?

Pour tester, deux pré-réquis :
- l'interpréteur Python (dans sa version au moins 3.7 - cf. asyncio),
- la dernière version de Rust à date (aucune dépendance à des crates extérieures).

Vous avez ensuite trois possibles :
- avoir la documentation projet : cargo doc --open ;
- lancer "en direct" le projet : RESOLUTION_TYPE=asservi REGLES_SOURCE=./regles.txt cargo run (pour la version debug et --release sinon) ;
- lancer via un superviseur Python : cargo build --release && RESOLUTION_TYPE=asservi REGLES_SOURCE=./regles.txt ./superviseur.py.

Je n'ai pas terminé - loin de là - toute la documentation, mais vous avez un README.md pour patienter.

Enfin vous pouvez utiliser tout ou en partie du code comme bon vous semble, dans le cadre de la licence MIT… c'est peu restrictif… !

5. "C'est sérieux ça, comme projet ?"

Bof, c'est d'abord un entraînement me concernant, et pour les archéologues de Git, vous verrez que j'étais parti sur tout à fait autre chose au départ (plutôt l'inférence via un graphe ; avec un passage par Julia).

Et puis cela ne peut pas être un projet sérieux, car il est totalement francophone… Damned ! Heureusement que je suis sur linuxfr.org !

---

Le dépôt GitHub est ici : JGarderon/Regle.

Bon code.

PS : je l'ai déjà dit que votre clémence me sied… ?