permettent de rendre les règles candidates compréhensibles au niveau lexical (normalisation lexicale), autonomes (normalisation contextuelle), syntaxiquement simplifiées et élémentaires (normalisation syntaxique), sémantiquement cohérentes (normalisation sémantique). Analyser le travail étape par étape permet une plus grande systématisation, un meilleur contrôle de la complétude du travail, et réduit l’expertise logique impliquée dans cette première phase. Il est difficile d’imposer un ordre dans l’application des opérations mais il est souvent recommandé dans les travaux sur la simplification textuelle de simplifier les mots avant de simplifier la phrase en entier.
Actuellement, l’expert est en mesure d’effectuer ces opérations à la main. Ces normalisations peuvent s’opérer spontanément et sans distinguer de types de normalisation, c’est souvent ainsi que les experts travaillent, en ajustant la forme finale par essais et erreurs. Mais notre objectif est, pour des documents complexes, de proposer à l’expert une assistance . Un système interactif lui propose sur chaque type de normalisation, une détection ou une transformation automatique qu’il pourra ensuite accepter, modifier si nécessaire et valider, ou alors refuser.
V.4 Maintenance des règles
V.4.1 Recours aux textes
Nous savons que d’une part, la méthode d’acquisition (présentée dansV.3) de règles à partir des textes réglementaires présente les règles sur plusieurs niveaux. Autrement dit, chaque règle est soumise à plusieurs révisions à travers le processus de reformulation, de sa version initiale dans les textes à sa version complètement normalisée. C’est cette dernière version qui est prise en compte dans la phase de formalisation. Ce processus peut être à l’origine de plusieurs erreurs qui renvoient à un besoin de maintenance des règles. Il s’agit d’erreurs qui apparaissent dans les textes ou dans le passage du langage naturel au langage contrôlé à travers les opérations de normalisation.
Et d’autre part, un schéma de maintenance (voir IV.1.3) consiste en général à maintenir des règles déjà mises en œuvre, c’est-à-dire des règles formalisées et automatisées. Le processus de maintenance quant à lui consiste en trois phases, une phase de détection des problèmes présents dans la base de règles formelles, une phase de diagnostic de ces problèmes et une phase de mise à jour des règles.
Ainsi, nous nous intéressons particulièrement ici à la prise en charge des problèmes liés aux erreurs produites dans notre processus d’acquisition. Notre travail ne porte ni sur la
détec-Chapitre V. Méthodologies d’acquisition et de maintenance des règles métier
tion des problèmes ni sur leur correction mais nous proposons une méthode de diagnostic des problèmes au regard des textes d’origine et de l’ensemble des reformulations que subissent les règles candidates initiales.
Cette méthode repose sur la traçabilité que nous utilisons pour diagnostiquer les problèmes d’incohérences dans la base de règles. Elle consiste à recourir aux traces d’une règle candidate donnée en revenant sur l’ensemble de ses versions de normalisation antérieures jusqu’à sa version initiale dans les textes. Cela permet de remonter chacun des problèmes afin de comprendre son origine et de pouvoir le justifier. Les problèmes d’incohérences sont dues à des erreurs commises à certaines étapes du processus d’acquisition. Une partie de ces erreurs correspond à des incorrections dans les textes d’origine, et l’autre partie apparaît quant à elle dans les étapes de normalisation lorsque des problèmes d’interprétation et d’explicitation conduisent à une non conformité entre les textes et les règles dans leur version transformée. Si ces erreurs persistent jusqu’à la fin du processus, elles se traduisent pendant l’utilisation du SGRM par des problèmes de maintenance.
La traçabilité peut aussi être utilisée lorsque des règles deviennent obsolètes et ne servent plus à rien avec le temps. Ces règles posent alors problèmes et il nécessaire de les mettre à jour en faisant recours aux textes pour analyser s’il faut les modifier ou les supprimer de la base de règles. Cela est du au fait que les textes changent régulièrement et donc toutes les règles dérivées des fragments ayant subi des modifications devront alors être mises à jour.
V.4.2 Diagnostic des problèmes
Nous prenons en compte uniquement les problèmes susceptibles d’apparaître dans la base de règle et dont le diagnostic peut être effectué en recourant aux textes d’origine. Nous avons ainsi sélectionné les types de problèmes où la traçabilité peut aider à comprendre s’ils proviennent des textes ou du processus de reformulation. Ces problèmes sont bien connus dans la littérature et nous pouvons les classer en trois catégories :
– les problèmes d’incompréhension et d’incomplétude qui caractérisent des règles qui quand elles sont appliquées par exemple dans un SGRM aboutissent à des décisions difficilement compréhensibles ou incomplètes ;
– les problèmes d’incohérences qui traduisent des contradictions entre des couples de règles de la base, qui lors qu’ils sont appliqués produisent des décisions incorrectes ou alors les règles d’un couple ne peuvent s’appliquer en même temps ;
– les problèmes d’évolution qui conduisent à des règles obsolètes qui nécessitent une mise à jour et qui sont caractérisés par évolution du fonctionnement de l’entreprise.
V.4 Maintenance des règles
Nous analysons ici plusieurs exemples de problèmes et pour chacun d’eux nous tenterons de voir comment le diagnostic peut se faire en utilisant la traçabilité. Ces exemples sont tirés pour la plupart des corpus AAdvantage et Audi, les autres sont tirés d’autres textes réglementaires qui ne sont pas décrits dans ce rapport.
V.4.2.1 Incohérence
Les règles incohérentes sont des règles dont l’application est soit impossible, soit incertaine, soit sans effet. Il y a nécessairement à l’origine de ce fait une mauvaise rédaction. Au premier rang des incohérences, on trouve les contradictions qui, permettant de déduire une chose et son contraire, vident le système logique de tout résultat. Décider si un ensemble de règles contient des règles contradictoires ne peut se faire que par des méthodes de déduction automatique au niveau des règles formalisées. Typiquement dans le SGRM, la contradiction est détectée à ce niveau et ensuite tracée. Les autres incohérences ont été répertoriées par les praticiens de l’écriture des règles en fonction de leur expérience. Elles ont des formes syntaxiques qui permettent de les reconnaître plus tôt, et c’est pour cela que nous nous sommes intéressés à leur reconnaissance avant même que la formalisation soit achevée.
Nous n’avions pas assez d’incohérences dans nos cas d’usage pour avoir une idée de comment elles se produisent. Nous supposons que là aussi le retour aux textes permet aux experts de cor-riger les erreurs. Détecter certaines incohérences au point de départ du processus d’acquisition est un gain : la détection n’est pas complète mais elle a lieu avant la formalisation. Lorsque les problèmes sont identifiés dans la base de règles, leur coût de réparation est, de l’avis des experts, beaucoup plus important.
Nous décrivons ci-dessous quelques problèmes d’incohérence classiques :
Les règles indécidables décrivent des règles dont la traduction en une procédure de décision est ambiguë. L’exemple suivant pose une difficulté au moment de la décision. Dans la règle (1), l’obtention du statut de résident est obtenu à la suite d’un certain délai (”12 months”) de résidence en territoire norvégien. Cette condition est distincte de celle de la règle (2) qui confère le statut à partir du moment où l’immigré s’installe en Norvège, à un moment où on ne sait pas si les conditions d’obtention sont remplies.
(1) Norwegian resident is defined as one who is staying in Norway, when the stay is intended to last or has surpassed 12 months.
(2)A person who moves to Norway is considered a resident from the date of arrival.
Chapitre V. Méthodologies d’acquisition et de maintenance des règles métier
Les redondances décrivent des relations d’inclusion entre deux règles c’est-à-dire lorsque dans un couple de règles, le domaine d’application de l’une est couvert par celui de l’autre. En général, il s’agit de couples où une règle est une spécification ou vice versa une générali-sation de l’autre. Dans l’exemple suivant la règle (2) est une spécification de la première (1) car les ”Emerald customers” sont aussi des ”Loyalty customers”. Comme on le voit dans cet exemple, ces inclusions sont dues aux relations de subsomption entre les termes métier de domaine.
(1)Loyalty customers can use the frequent customers boarding queue.
(2)Emerald customers can use the frequent customers boarding queue.
Les incompatibilités décrivent des règles dont chacune isolément serait sans problème, mais telles que, prises ensemble, l’une au moins devient inapplicable. Il est inutile de les laisser subsister simultanément dans la base de règles, et il y a vraisemblablement une erreur dans l’interprétation du texte. Le couple de règles suivant le montre très bien.
(1) A man is not a woman.
(2)If a human being is a man and a woman, he is an hermaphrodite.
V.4.2.2 Obsolescence
Dans la durée, les besoins du système d’information changent régulièrement, certaines règles métier deviennent obsolètes et nécessitent d’être modifiées. Soit que le texte soit modifié par les responsables, soit que les conditions d’application de la règle ne soit plus réunies et qu’elle devienne sans objet. Dans le texte réglementant les bonus d’une compagnie aérienne, on trouve :
If your account has no qualifying activity in any 18-month period, all miles in the account will expire except for those miles earned prior to July 1, 1989 in accounts established prior to January 1, 1989 whose mileage credit will not expire.
Ce texte s’analyse en deux règles, applicables aux bonus obtenus avant et après le 1er juillet 1989. 23 ans après cette date, il est vraisemblable que la première sera bientôt obsolète et qu’il va devenir inutile de mentionner l’exception. Pour maintenir la cohérence, il est nécessaire de vérifier l’existence de règles textuelles qui mentionnent l’expiration des bonus dans leur conclusion (ce qui pourrait rendre la modification totalement ou partiellement sans effet) ou leur prémisse (si l’obsolescence est confirmée, cette règle sera elle aussi obsolète).
Quand le texte est modifié, il s’agit de répercuter à moindre coût ce changement sur les éventuelles règles qui en sont dérivées. Le texte sur les ceintures de sécurité a été modifié à 13