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

Posté par  . Licence CC By‑SA.
Étiquettes :
24
12
mar.
2022

Sommaire

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… ?

  • # rule-based … assert

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

  • # Low code ?

    Posté par  . Évalué à 3.

    J'ai pas vraiment l'impression que ça soit ça, le low code/no code.

    De ce qu'il me semble, c'est que derrière ce terme, on englobe les outils qui visent à s'abstraire :
    - la programmation sous forme textuelle (donc ça inclut le code, mais aussi le pseudo-code comme tu l'utilises)
    - la gestion de l'outillage attenant (pas de chaîne ou de commandes de compilation, pas de dépôt, pas besoin de lire une documentation pour se lancer, pas de configuration à gérer : un login sur un site web ou un téléchargement d'appli et ça s'utilise)

    Pour moi tu n'as pas fait du low/no-code, mais un PoC de métalangage (?).

    Ma remarque est sans jugement sur le bien-fondé de la démarche, il va de soit.

    • [^] # Re: Low code ?

      Posté par  . Évalué à 2. Dernière modification le 14/03/22 à 22:02.

      "Ma remarque est sans jugement sur le bien-fondé de la démarche, il va de soit."

      Aucun problème, je suis ouvert à l'échange.

      "J'ai pas vraiment l'impression que ça soit ça, le low code/no code.
      De ce qu'il me semble, c'est que derrière ce terme, on englobe les outils qui visent à s'abstraire :
      - la programmation sous forme textuelle (donc ça inclut le code, mais aussi le pseudo-code comme tu l'utilises)
      - la gestion de l'outillage attenant (pas de chaîne ou de commandes de compilation, pas de dépôt, pas besoin de lire une documentation pour se lancer, pas de configuration à gérer : un login sur un site web ou un téléchargement d'appli et ça s'utilise)"

      Je te rejoins, ce n'est certainement pas du "no-code". Pour le "low-code" - en traduction littérale : "peu codée" -, par contre, la frontière me semble moins claire. Si je reprends la présentation Wikipedia : "A common benefit is that a wider range of people can contribute to the application's development—not only those with coding skills but require a good governance to be able adhere to common rules and regulations."

      L'intention de permettre à une personne "métier" d'utiliser de manière simple des fonctions applicatives possiblement très complexes, compte autant à mes yeux que la seule méthode d'accès / d'édition (par une interface Web par exemple). D'ailleurs le défi de premier de ces outils est de garantir la conformité entre la volonté / ce qui est marqué, et l'application / la résolution effective.

      Pour arriver à un outil purement "low code" et complet, il faudrait développer tout l'attirail autour. A mon sens, j'ai créé une brique qui s'intègre dans une logique low-code et pas n'importe quelle brique, car elle porte ce qui fait le lien le plus direct entre le métier et l'applicatif.

      "Pour moi tu n'as pas fait du low/no-code, mais un PoC de métalangage (?)."

      Métalangage je ne sais pas, c'est un DSL tout ce qu'il y a classique (si on considère qu'un DSL est un type de ML, alors oui).

      J'espère avoir pu répondre à ta remarque.

      • [^] # Re: Low code ?

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Un DSL est soit un langage trop spécialisé et très limité car ne sortant pas de son domaine, contrairement aux autres langages de programmation ; soit un métalangage (méta au sens de surcouche simplificatrice à un autre langage plus standard/générique.) Ce dernier cas est souvent le cas de syntaxes déclaratives qui vont être transpilées derrière.

        Pour moi, les trucs low-code (en tout cas ceux que j'ai rencontré) correspondent à ce-qu'on appelait des macros…

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Low code ?

          Posté par  . Évalué à 1.

          Ton argument fait mouche !

          Bien que je ne sois pas sûr que ça soit transposable directement à ce cas (peut-on résumer le programme 'Règle' à une grosse macro ? j'ai un sérieux doute : il gère des états et agit en conséquence).

          Une vraie question : de ton point de vue, comment catégorises-tu Prolog, où il est aussi question de description de règles logiques et là aussi, sans être transpilé vers autre chose (à ma connaissance du moins) ?

          Pour moi c'est typiquement un DSL :
          - tu as une notion de programmation, avec ce que ça concerne de relative souplesse algo ;
          - tu le restreints à un "domaine spécifique" (la programmation logique, très loin de l'éventail de toute la programmation possible).

          Qu'en penses-tu ?

          • [^] # Re: Low code ?

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Pour moi, Prolog est un langage à part (mais je suis biaisé car ayant fait mumuse avec quand j'étais gamin) et révolutionnaire (parce-que déclaratif et non impératif, je pense avant SQL mais en tout cas je les ai connu dans cet ordre) qui s'apparente à un solveur (terme qu'on rencontre plutôt dans les logiciels mathématiques de calculs sur des polynômes et matrices ou du calcul symbolique) …donc probablement un DSL (spécialisé ici en déduction logique car c'est créé dans le contexte de l'IA) mais pas dans la catégorie plus courante des trucs transpilés (en écrivant mon commentaire, je pensais en tant qu'admin sys au gestionnaires de confs —Chief/Puppet— et de déploiement —Ansible— mais quid des machines d'états ? Je ne sais pas trop exactement…)
            Ceci dit, la programmation logique est une forme/approche comme la programmation événementielle ou la programmation fonctionnelle ou autres. Prolog n'est pas enfermé dans un seul truc (comme on le serait dans un tableur…) et on peut l'utiliser pour résoudre divers autres problèmes tout comme les autres.

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Low code ?

            Posté par  . Évalué à 1. Dernière modification le 15/03/22 à 09:11.

            • tu le restreints à un "domaine spécifique" (la programmation logique, très loin de l'éventail de toute la programmation possible).

            Je ne comprend pas bien cette phrases.

            Je questionne pour comprendre :

            La programmation logique est très loin de l'éventail de toute les programmation possible.

            tu parles du paradigme du langage?

            ou autre chose?

            moins sérieusement :
            pour sourire, imaginez une programmation sentimentale :)

            • [^] # Re: Low code ?

              Posté par  . Évalué à 2.

              "tu parles du paradigme du langage?"

              Oui en quelque sorte, mais pour moi c'est encore un aspect un peu différent. Le paradigme concourt à produire un développement bien au-delà des aspects algorithmiques, en définissant aussi une logique de développement / d'organisation, des types, etc.

              En soi même SQL qui est l'exemple DSL type de nos échanges, permet en soi d'être "Turing-complete" et donc revêt un caractère universel (l'exemple est donné de la récursivité des requêtes SQL à partir de la norme SQL:1999, lui conférant la possibilité des embranchements, des boucles, etc.).

              Je distingue donc la "possibilité" expressive de la "volonté" expressive. Et j'espère ne pas dire là un contre-sens ou une contre-vérité…

              nb : 'Règle' gère les boucles, les embranchements, les états combinés (les clauses et les conditionnels des règles) peuvent permettre des comparaisons. Sa liaison pour effectuer des calculs jusqu'à sur des bits via le superviseur, rend donc l'ensemble Turing-Complete. Mais la volonté et l'usage premier est bien de représenter une logique métier.

              "pour sourire, imaginez une programmation sentimentale :)"

              Ah ça se tente… !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.