5-3.3 Aperçu du système M-Lex

M-Lex est décrit avec plus de détails dans notre monographie Schneider (90). La structure générale de M-Lex reflète la structure de la loi: L'article 2 reflète la logique générale sous le titre §"Régime de l'autorisation": "L'acquisition d'immeubles par des personnes à l'étranger est subordonnée à une autorisation de l'autorité cantonale compétente". L'Art.3-1 complète: "l'autorisation n'est accordée que pour les motifs prévus dans la présente loi". On retrouve dans la figure 5-11 les contextes principaux de M-Lex: "acquisition", "personne" et "motif", sur lesquels est fondée la décision: non-assujettissement et assujettissement accouplé à une autorisation ou à un refus.

Un ancien débat en informatique concerne les noms qu'il faut donner à des symboles dans un programme informatique. On peut se poser la même question au sujet des noms des règles et des paramètres. Lors de la création de M-Lex, nous nous sommes fondés sur les considérations suivantes:

un symbole doit avoir un sens direct, il doit afficher clairement sa fonction.
les noms de règles doivent être clairement distincts des noms de paramètres (pour augmenter la lisibilité des "traces").
les noms devraient donner une indication du contexte auquel ils appartiennent.
ils ne devraient pas être trop longs, car il faut les taper et il faut éviter que les "traces" soient trop grandes.

En adaptant ces contraintes[72], nous avions adopté les conventions suivantes:

les noms de règles commencent par "$" et les noms de paramètres par "*".
la lettre suivante indique le contexte, par exemple $-t-.... et *-t.... appartiennent au contexte "top".
les règles qui évaluent un même paramètre devraient avoir un nom similaire, et inclure le nom du paramètre et de la valeur en question. Par exemple, la règle "$t-aut-reg-yes" décide si le paramètre "*t-aut-reg" est "yes".

Voici un long extrait du système M-Lex qui montre la "hiérarchie au sommet" du système. Les lignes précédées par ";" sont des commentaires:

Les paramètres principaux guidant la décision:

;;; The top-parameter represents the four possible solutions of a case:
;;; authorization, refusal, non-subjection, non-solution
(defparm *t-conc single (aut refus notsub imposs) top)

;;; The authorization regime: subjection or not
(defparm *t-aut-reg yesno (yes no) top inferred)

;;; The acquisition: took place or not
(defparm *t-ac yesno (yes no) top inferred)

;;; The person is foreign, or not, or something special
(defparm *t-for-per single (yes no special) top inferred)

;;; the authorization grounds do exist or not
(defparm *t-aut-mot yesno (yes no) top inferred)

Les règles guidant la décision:

;;; The dummy rule to start the back-chaining
;;; In order to start-up the system we tell him to find a value for
;;; the top parameter *t-conc, i.e. we simply trigger a premisse.

(setq goal-rule
 (defrule $goal-rule
	 (known *t-conc nil)))

;; First we decide whether somebody is subject to the authorization
;; system. If so, we check whether he will receive an
;; authorization.

(defrule $t-decision-yes
 ;; the person is submitted to the authorization regime
 (defis *t-aut-reg yes)
 ;; and he gets an authorization
 (defis *t-aut-mot yes)
 ==>
 (advice-to |The acquisition will be authorized| 1.0)
 (*t-conc aut 1.0)
)

;; Same logic as before, but we check for refusal.
;; We will use eventually the conclusions triggered by $t-decision-yes.

(defrule $t-decision-no
 ;; the person is submitted to the authorization regime
 (defis *t-aut-reg yes)
 ;; and doesn't get an authorization
 (notsame *t-aut-mot yes)
 ==>
 (advice-to |The acquisition will be refused| 1.0)
 (*t-conc refus 1.0)
)

;; Checks whether a person is submitted to the regime of authorization
;; cf. art 2 LFAIE
;; If the person did an acquisition (according to Art.4 and Art.7 LAIE),
;; it is checked whether if is "foreign".

(defrule $t-aut-reg-yes
 ;; the person acquired real estate
 (defis *t-ac yes)
 ;; and it is foreign
 (defis *t-for-per yes)
 ==>
 (*t-aut-reg yes 1.0)
 (advice-to |The acquisition is subject to an authorization| 1.0)
)

;; If the person didn't acquire some real-estate,
;; we can immedialy make the general conclusion of
;; non-subjection.

(defrule $t-aut-reg-no1
 ;; the persone did not acquire a real estate
 (notsame *t-ac yes)
 ==>
 (*t-aut-reg yes -1.0)
 (advice-to |The acquisition is not subject to an authorization| 1.0)
 (*t-conc notsub 1.0)
)

(defrule $t-aut-reg-no2
 ;; the person acquired some real estate
 (defis *t-ac yes)
 ;; his status is known
 (known *t-for-per) ; simplify ?
 ;; but it is not foreign (or under foreign control)
 (notsame *t-for-per yes)
 ==>
 (*t-aut-reg yes -1.0)
 (advice-to |The acquisition is not subject to an authorization| 1.0)
 (*t-conc notsub 1.0)
)

;;; The next two rules are pessimistic about reality and our capacity

(defrule $t-no-conc1
 ;; It cannot be determined whether an acquisition was subject to an auth.
 (notknown *t-aut-reg)
 ==>
 (*t-conc imposs 1.0)
 (advice-to |No conclusion could be reached about the authorization regime | 1.0)
)

(defrule $t-no-conc2
 ;; A person is submitted to the authorization regime
 (defis *t-aut-reg yes)
 ;; ... but no motive can be found
 (notknown *t-aut-mot)
 ==>
 (*t-conc imposs 1.0)
 (advice-to |No conclusion could be reached, No authorization-motive| 1.0)
)

On peut représenter ces paramètres et ces règles dans un arbre graphique de décision qui met en valeur la complexité relative que possède déjà ce petit bout de M-Lex. Grâce aux extraits du système et à l'arbre dans la Figure 5-12: "Diagramme de la structure "top" de M-Lex" [p. 204], on peut voir comment fonctionne un système expert. Son exécution est étroitement liée à l'état de sa base de données. Le système démarre en tentant de déterminer la valeur du paramètre *t-conc, pour cela, il commence par exécuter la première règle dans la liste, soit "$t-decision-yes". Il tente de trouver d'abord une valeur pour le paramètre *t-aut-reg, à savoir s'il y a assujettissement au régime de l'autorisation. S'il trouve une valeur, le prochain paramètre ("*t-aut-mot*") est tracé. Si ces deux valeurs ne sont pas "yes" avec un CF de 1, le système essayera d'autres règles comme "$t-decision-no". Dans ce cas, il ne faut pas retracer les paramètres de cette règle car cela a déjà été fait. Le cheminement vers la décision se constitue donc d'une façon assez dynamique en fonction des besoins et des points connus.

[72] Ces trois dernières contraintes ne sont plus aussi importantes dans le contexte des interfaces graphiques qui permettent de gérer plus facilement l'information. Toutefois, étant donné qu'un système expert représente pour nous un modèle scientifique, nous pensons qu'il est important de tenir compte des contraintes d'une "version papier" du modèle.