Sécurité des biens dans une entreprise de grande ... · Sécurité des biens dans une entreprise de grande distribution : ... Cadre de travail Dans le chapitre concernant la définition

UNIVERSITE DE LAUSANNE

ECOLE DES HAUTES ETUDES COMMERCIALES

Sécurité des biens dans une entreprise de grande distribution :

Méthodologie et conception d’un système à base de

connaissances pour la formation et la gestion

Mémoire présenté par Paoly Philippe

en vue de l’obtention du

Diplôme postgrade en informatique et organisation

Année académique 1999-2000

devant le jury composé de :

Professeur A.R. Probst, directeur du mémoire

Marcel Giller, chef sécurité auprès de COOP Vaud Chablais valaisan

CONFIDENTIEL

Paoly Philippe Diplôme postgrade en informatique et organisation Page 2/80


Table des matières

Partie I – Introduction

1 - Définition du sujet………………………………………………………………. Page 4

2 - L’entreprise……………………………………………………………………… Page 6

3 - Confidentialité, contraintes et cadre de travail…………………………………. Page 8

4 – Contexte………………………………………………………………………… Page 10

5 - Hypothèses et postulats…………………………………………………………. Page 12

6 - Politique de l’entreprise………………………………………………………… Page 13

Partie II – Méthodologie

7 - Importance d’une méthodologie……………………………………………..….. Page 14

8 - Définition d’une méthodologie…………………………………………………. Page 14

Partie III – Méta connaissances

9 - Besoins de connaissances………………………………………………………. Page 16

10 - Acquisition de connaissances…………………………………………………. Page 23

11 - Choix d’une stratégie de gestion des connaissances………………………….. Page 25

12 - Expression des connaissances………………………………………………… Page 27

Partie IV – Conception et modélisation du business

13 - Outil de modélisation………………………………………………………….. Page 37

14 - Diagramme de classe………………………………………………………….. Page 39

15 - Use case……………………………………………………………………….. Page 40

16 – Séquences…………………………………………………………………….. Page 42

17 - Diagramme de composant……………………………………………………. Page 43

18 - Diagramme de déploiement………………………………………………….. Page 44



Partie V – Moteur d’inférence

19 - Définition des besoins d’inférence……………………………………………. Page 45

20 - Choix des moteurs d’inférence……………………………………………….. Page 47

21 - Modélisation des moteurs d’inférence………………………………………... Page 48

Partie VI – Le prototype

22 - Choix des outils de développement…………………………………………... Page 56

23 - Limites du développement…………………………………………………… Page 56

24 - Fonctionnalités de l’application……………………………………………… Page 57

25 – Modélisation Entité-Association et relationnelle……………………………. Page 58

26 - Implémentation des moteurs d’inférences……………………………………. Page 61

27 - Définition de l’interface………………………………………………………. Page 62

Partie VII – Conclusion

28 - Critiques et difficultés………………………………………………………… Page 72

29 - Proposition d’améliorations……...…………………………………………… Page 73

30 - Conclusion générale………………………………………………………….. Page 76

31 – Remerciements………………………………………………………………. Page 76

32 - Bibliographie et références…………………………………………………… Page 77

Partie VIII – Annexes …………………………………………………………… Page 78



Partie I – Introduction

1. Définition du sujet

La gestion des connaissances est un problème important permettant la capitalisation et la valorisation de

connaissances et de compétences [Dieng 00]. De plus, apprendre c’est trouver une réponse à une

question préalablement posée, mais aussi mettre en pratique le savoir acquis [HBR 00]. Ceci étant dit,

intéressons-nous au sujet même du présent mémoire.

« Sécurité des biens dans une entreprise de distribution : méthodologie et conception d’un

système à base de connaissances1 pour la formation et la gestion ». Ce titre recouvre divers

éléments qui se doivent d’être précisés. La sécurité des biens recouvre l’ensemble des atteintes à la

propriété. Nous verrons dans les chapitres qui suivent que cette notion sera limitée d’une part

géographiquement, d’autre part fonctionnellement.

Par méthodologie, nous entendons la définition d’une méthode de travail, méthode qui se veut

généraliste, en ce sens qu’elle doit être capable de devenir un pattern2 et donc être appliquée à d’autres

cas de modélisation d’un système à base de connaissances notamment dans un rôle « d’aide mémoire »,

et s’appliquer de manière inchangée à la conceptualisation de systèmes équivalents à celui qui est

justement le sujet du présent travail.

La conception sous-entend la création d’un modèle théorique mais également la concrétisation de ce

modèle au travers d’un prototype d’application. La réalisation d’un prototype signifie donc qu’il s’agit

de l’implémentation des diverses fonctionnalités définies. L’application ainsi réalisée n’a pas l’ambition

de la perfection, mais se veut être une illustration du domaine du possible et montrer, sous les

contraintes imposées naturellement comme le temps par exemple, les difficultés qui peuvent se présenter

lors d’un travail équivalent.

Concernant la gestion et la formation, ces termes ont une portée interne à l’entreprise. Le chapitre

concernant les hypothèses et postulats définit les objectifs principaux et permettra d’éclaircir ces deux

concepts. En terme de gestion, nous verrons qu’il s’agit moins d’une gestion opérationnelle et précise

1 Par connaissances, nous entendons le savoir et l’expérience 2 Modèle générique réutilisable lors de travaux équivalents



qu’une gestion d’indices offrant des « directions » ou des suggestions. Sur le plan de la formation, celle-

ci s’adresse aux divers intervenants faisant partie du personnel de l’entreprise. A ce propos précisons

encore que le présent mémoire est réalisé en collaboration avec COOP Vaud-Chablais valaisan.

En résumé, l’objectif est de concevoir un système de gestion des connaissances, de présenter une

méthodologie et de la suivre dans notre développement, puis pour terminer, de réaliser le prototype

d’une application informatique reflétant le système conçu.

Afin d’aider le lecteur à suivre de manière optimale les pages qui suivent, je crois nécessaire de

présenter dès le départ, de manière succincte, l’approche utilisée.

L’idée de base est de créer un Case-Based Reasoning3 (CBR). Ceci suppose trois éléments :

• Trouver les données essentielles d’un cas

• Trouver comment exprimer ces données

• Trouver comment exploiter ces données

La partie III tente de définir les données nécessaires et comment les exprimer. La partie V tente de

montrer comment exploiter ces données.

La partie IV est importante. Elle permet deux choses essentielles :

• D’une part de se faire une idée du business, du « travail » de la sécurité et d’en avoir une bonne

compréhension

• D’autre part de situer notre système dans ce cadre d’activité.

Ces deux éléments permettent non seulement de voir plus facilement les besoins d’informations (et donc

influe sur la partie V), mais également de cerner les objectifs et contraintes de notre prototype (et donc

influe sur la partie VI).

3 Raisonnement à partir d’une base de cas



2. L’entreprise

COOP Vaud Chablais valaisan est une des coopératives du groupe COOP4. Chaque coopérative est

une unité indépendante et la coordination de toutes les coopératives est assurée par COOP Suisse. En

août 1999, l’ensemble des coopératives a décidé de fusionner en une seule unité : COOPForte, fusion

qui deviendra opérationnelle en 2001. Le présent travail prend donc place dans un environnement en

mutation, sans pour autant remettre en cause la problématique générale. Cependant, il est important de

préciser que les chiffres qui suivent ainsi que les organigrammes ont une réalité qui est sur le point de

disparaître, d’être modifiée ou de perdre en représentativité, puisqu’ils se basent sur l’entreprise COOP

Vaud Chablais valaisan, entreprise en train de disparaître en tant qu’unité indépendante.

Fondée en 1895, COOP Vaud Chablais valaisan est une société coopérative dont le nombre de

sociétaires s’élevait, en fin 1999, à 121'428. Elle possédait en fin de cette période 58 magasins, 4

Brico-Bâti-Loisirs, 13 restaurants (ou assimilés) pour une surface de vente totale de près de 61'000 m2.

Toujours fin 1999, l’entreprise employait 2'058 personnes et réalisait un chiffre d’affaires net de près de

562 millions de francs, et ce pour un résultat d’exercice de 2,2 millions.

Le graphique suivant permet de se faire une idée sur l’évolution du chiffre d’affaires depuis 1996 :

4 Site web : http://www.coop.ch

510520530540550560570

CA net en millions

1996 1997 1998 1999

Années

Evolution du chiffre d'affaires



Figure 1 : CA de COOP Vaud Chablais valaisan

Les organigrammes suivants illustrent l’organisation de l’entreprise, d’une part d’un point de vue

directionnel, d’autre part l’organisation plus spécifique du service de sécurité, lui-même dépendant du

département du personnel.

Figure 2 : Organigramme de COOP Vaud Chablais valaisan

Figure 3 : Organigramme du service de sécurité de COOP Vaud Chablais valaisan

Notons que le groupe spécial est un groupe de surveillance affecté à un secteur géographique précis,

contrairement au groupe de surveillance qui, lui, est géographiquement polyvalent.

Organigramme directionnel

Ventes Achats & Logistique

Sécurité

Personnel et Formation Finances & Informatique

Techniques

Conseil d'administration

Organigramme Service sécurité

Secrétariat

Chef de service adjoint

Groupe spécial Contrôle-Statisitique Groupe surveillance

Chef de service



3. Confidentialité, contraintes et cadre de travail

3.1. Confidentialité

Diverses clauses de confidentialité ont été imposées, soit pour des raisons légales soit pour des raisons

propres à la sécurité de l’entreprise. Parmi ces clauses, nous pouvons notamment relever :

• Les données nominatives existantes des délits, dans le cadre de la loi fédérale sur la protection

des données. Ces données seront donc anonymes.

• L’inventaire physique des moyens de surveillance.

• Les noms des surveillants et autres intervenants.

• Le détail des procédures internes de traitement et de décision.

• Les plans et stratégies de surveillance.

• L’inventaire physique des moyens de protection.

• Toutes données stratégiques, par exemples le nom des possesseurs de clé d’accès aux magasins

ou l’organisation des transferts de fonds.

Les données confidentielles existent dans les annexes, mais également dans le texte au travers de chiffres

ou d’indications diverses. En conséquence, l’ensemble du mémoire est touché par la clause de

confidentialité.

3.2. Contraintes

Diverses contraintes ont été imposées par l’entreprise alors que d’autres relèvent du cadre même du

mémoire. On peut citer notamment :

• La non-utilisation du matériel de l’entreprise.

• Le contrôle des interviews du personnel de l’entreprise par le responsable de la sécurité.

• Le contrôle des sorties de documents de l’entreprise par le responsable de la sécurité.

• Les contraintes de responsabilité (civile) lors d’observations sur le terrain.

• Les contraintes d’échéance et les obligations académiques.



Ces contraintes peuvent avoir un impact sur l’orientation du travail et sur son organisation.

3.3. Cadre de travail

Dans le chapitre concernant la définition du sujet, il est précisé que l’objet du travail regroupe

l’ensemble des atteintes à la propriété, mais que cette notion est limitée géographiquement et

fonctionnellement. De plus, l’orientation de la gestion et de la formation est résolument interne à

l’entreprise. Le cadre de travail se limite donc à l’interne de l’entreprise, en intégrant les contraintes

légales auxquelles l’entreprise doit faire face.

La limite géographique comprend l’ensemble des magasins COOP sous l’autorité de COOP Vaud-

Chablais valaisan, sans tenir compte d’éventuelles sociétés détenues en participations.

De plus, la limite fonctionnelle définit la frontière entre les atteintes à la propriété dont nous tiendrons

compte et celles ignorées. Cette limite comprend deux axes :

• La surface de vente à l’intérieur du magasin et tout ce qu’elle contient, y compris les caisses et

les entrepôts.

• Le type de délit : l’appropriation illégale d’un bien ou d’argent liquide, qu’il s’agisse de vol à

l’étalage, de fausse monnaie ou d’arnaque.

Ces limites excluent donc les délits de type vandalisme, espionnage ou sabotage. Précisons en outre

qu’elles sont posées de manière arbitraire, pour les besoins du mémoire.



4. Contexte

4.1. En général

Observons en premier lieu les chiffres suivants, qui indiquent les cas de vols5 années après années :

Figure 4 : Evolution du nombre des cas de vol chez COOP Vaud Chablais valaisan

Nous constatons en premier lieu une évolution fluctuante des cas de vols. On pourrait croire à première

vue à l’existence d’une tendance (à la baisse), cependant non seulement une régression linéaire donne un

coefficient de corrélation de 0.6, ce qui n’est pas très bon, mais de plus le maître mot du responsable de

la sécurité, fruit de plusieurs années d’expérience, est « aléatoire ». Dès l’instant où l’on admet cet

adjectif se pose le problème de la prévision, ce qui est susceptible de pénaliser la précision des travaux

de prévention.

Toujours avec comme source l’expérience, le service de sécurité estime à 50% des cas le nombre de

5 Vols à l’étalage. Les cas d’escroquerie, arnaques aux caisses, fausses monnaies

0

200

400

600

800

1000

Nbre de cas

1991 1993 1995 1997 1999

Années

Evolution des cas de vols



vols commis par des récidivistes. En résumé, un voleur sur deux est connu de l’entreprise comme tel. Il

n’est malheureusement pas possible d’estimer actuellement le nombre de récidives moyen (récidive ou

multi-récidive). De plus, 20% environ des vols sont commis par le personnel de l’entreprise.

Relevons également l’incertitude concernant le montant moyen d’un vol, outre le nombre de ces vols. A

titre d’exemple, les 700 cas de 1999 ont représenté un montant de 38'450.-, soit un montant moyen de

55.- environ, alors que les 956 cas de 1991 représentaient près de 100'000.- , soit environ 105.-. On

constate donc des variations d’au moins du simple au double.

Un élément à noter également est le nombre d’escroqueries et d’arnaques aux caisses. Ces cas ne sont

pas compris dans le graphique représenté à la figure 4. En l’absence de statistiques, ils sont estimés à une

cinquantaine de cas annuellement.

4.2. La formation

Un élément important est l’aspect de la formation. Lorsqu’un nouveau surveillant arrive dans le service

de sécurité, ce dernier est envoyé sur le terrain accompagné par des collaborateurs d’expérience. Le

savoir se transmet donc de manière orale en fonction des cas rencontrés. Une autre méthode de

formation est l’organisation de cours de formation, soit par des personnes internes, soit externes, sur des

sujets généraux ou plus précis. De plus, il existe des procédures écrites permettant une acquisition du

savoir par la lecture.

Concernant le personnel en magasin, la formation concerne principalement les gérants qui d’une part

possèdent le manuel du gérant, recueil de procédures, et d’autre part suivent divers cours de formation.

En outre, chaque gérant passe au moment de sa nomination une journée sur le terrain avec une équipe

du service de sécurité. Concernant la formation du reste du personnel de magasin, il faut constater

qu’elle est inexistante vu l’absence de programme de cours ciblé. En effet, ces collaborateurs ne sont

pas censés intervenir dans un cas de vol, bien que leur intervention soit constatée sur le terrain.

En bref, on peut retenir 4 éléments principaux :

• L’imprévisibilité des cas de vol (quantité et montants).

• Le nombre important de récidives.

• L’importance des vols de la part du personnel.

• La formation sur deux axes principaux : manuels et tutorat.

ne sont pas compris dans les chiffres.



5. Hypothèses et postulats

Vu ce qui a été dit précédemment, notre système devrait remplacer ou appuyer la formation, offrir des

réponses efficaces à diverses questions, proposer des fonctionnalités de traitement statistique ou

d’exploration, de la simple régression aux méthodes plus évoluées telles que l’analyse factorielle ou

discriminante.

En bref, les fonctionnalités de base devraient être :

• Interpréter une requête en langage structuré : comprendre et traiter une question.

• Proposer une réponse pertinente : analyser les données existantes et générer une réponse.

• Apprendre et évoluer : assimilation des nouvelles données dans les traitements.

• Générer des scénarii : proposer des cas.

• Décrire diverses situations : mettre en évidence les caractéristiques de la situation, selon des

critères définis ou non.

• Illustrer une problématique : donner des exemples selon une problématique donnée.

• Tester divers comportements/réactions : tester la pertinence d’une action et générer la réaction

probable.

• Générer des profils.

• Déceler des problèmes sous-jacents : attirer l’attention sur des éléments probables.

• Traiter des indices : générer des probabilités suivant divers éléments.

• Traiter des données : divers types de traitements statistiques.

• Offrir une bibliothèque de cas : permettre la gestion des documents papiers.

• Gérer les procédures : indiquer les règles d’action existantes, proposer des règles d’action.

Ces fonctionnalités paraissent à priori essentielles dans les réponses aux besoins de l’entreprise. Elles

permettent d’offrir un soutien autant dans la formation que dans la gestion.



6. Politique de l’entreprise

La politique de COOP Vaud Chablais valaisan en matière de vol est la suivante :

« S’assurer que la marchandise soit payée. A priori le client est honnête. C’est donc la marchandise qui

est surveillée, non le client lui-même, ou le personnel le cas échéant ».

Cette politique influe sur les investissements en moyen de surveillance et sur les méthodes de

surveillance. Par exemple, la surveillance des WC par caméra est exclue, puisque cela supposerait une

surveillance des individus et non plus des produits. De plus, la surveillance s’exerce selon deux moyens

principaux : la surveillance par caméra (surveillance de produits ou de rayonnages) et la surveillance

directe par des professionnels, également sur des secteurs de vente ou des rayonnages. Rappelons en

outre qu’une personne peut remplir ses poches de marchandises. Sa seule obligation est de payer ces

marchandises à la caisse.

Une surveillance de personnes peut cependant exister. Par exemple si l’on constate des erreurs de

caisse trop fréquentes et que les soupçons portent sur une caissière en particulier, une surveillance sera

mise en place spécifiquement sur ce poste de travail au moment où cette caissière sera en activité. Mais

même dans ce cas, on relève que la surveillance initiale concernait l’argent, ou du moins son mouvement,

et que c’est uniquement lorsqu’un problème est décelé à une étape quelconque qu’une surveillance de

personne est éventuellement mise en place.

Cette politique de l’entreprise devra rester à l’esprit tout au long de la réflexion qui va suivre.



Partie II – Méthodologie

7. Importance d’une méthodologie

La méthodologie est un élément essentiel, sinon l’élément essentiel des méta-connaissances6. En effet, la

méthodologie fait totalement partie de la création d’un pattern réutilisable tel quel ou sous réserve

d’adaptations. Elle offre non seulement un cadre de réflexion mais également une méthode de travail et

de développement. La question « Comment faire ? » est importante car sa réponse conditionne

l’ensemble des travaux et l’ensemble des réflexions. La méthodologie développée ici concerne aussi

bien la réflexion intellectuelle que la modélisation du business ou la conception du prototype, mais

l’accent principal est mis sur les deux premiers éléments, dans un souci de respect du cadre

académique.

8. Définition d’une méthodologie

La méthodologie utilisée est axée sur trois piliers fondamentaux :

• Les méta-connaissances: il s’agit ici des connaissances sur les connaissances, principalement la

définition des besoins, des méthodes d’acquisition ou des sources, les stratégies de gestion et

l’expression des connaissances.

• La conception et la modélisation du business : il s’agit ici de représenter les processus et les

méthodes de fonctionnement dans le cadre de notre problématique. Nous cherchons à obtenir

une représentation fidèle de la réalité, de ce qui se passe concrètement dans le quotidien.

• La conception du moteur d’inférence 7: il s’agit de définir les besoins d’inférence, le choix d’un

modèle d’inférence et de modéliser le moteur d’inférence choisit. L’opération logique de

déduction ou d’induction peut prendre diverses formes et cette opération est essentielle dans la

modélisation du prototype.

6 Connaissances sur les connaissances 7 Moteur permettant d’automatiser une opération logique permettant d’admettre une proposition en vertu de sa liaison avec d’autres propositions tenues pour vraies



Ces trois piliers permettrons la conception et la réalisation du prototype : il s’agit ici de modéliser et de

créer un prototype d’application informatique permettant d’offrir les fonctionnalités, ou du moins les plus

importantes puisqu’il ne s’agit que d’un prototype, définies dans les opérations précédentes.

La définition de la méthodologie peut être schématisée de la manière suivante :

Figure 4 : Les 3 piliers de la méthodologie

Insistons sur l’objectif de cette méthodologie qui reste la réalisation d’un prototype d’application.

METHODOLOGIE

Mét

a-co

nnai

ssan

ces

Mét

a-co

nnai

ssan

ces

Con

cept

ion

bus

ines

sC

once

ptio

n b

usin

ess

Mot

eur

d’in

fére

nce

Mot

eur

d’in

fére

nce



Partie III – Méta connaissances

9. Besoins de connaissances

Nous pouvons reprendre certains éléments décrit dans le chapitre « Hypothèses et postulats » comme

base de travail et définir pour chacun d’eux un type de raisonnement ou d’approche de manière à cerner

plus précisément les besoins en connaissances. Le tableau suivant donne l’association entre chaque

objectif du système et un type de raisonnement :

Objectifs du système Types de raisonnement

Interpréter une requête Codage

Proposer une réponse Méthode de sélection

Apprendre et évoluer Méthode d’assimilation

Générer des scénarii Méthode de sélection

Décrire diverses situations Méthode d’agrégation

Déceler des problèmes sous-jacents Méthode de sélection

Traiter des indices Méthode de sélection

Traiter des données Méthode d’agrégation

Illustrer une problématique Méthode d’agrégation

Générer des profils Méthode d’agrégation

Offrir une bibliothèque de cas Méthode de sélection

Gérer les procédures Méthode de sélection

Tester divers comportements/réactions Méthode de sélection

Figure 5 : Objectifs et types de raisonnement

A partir de ce tableau, il est possible de travailler sur deux bases :

• Les données elles-mêmes (et les objets auxquels elles se rattachent)



• Les types de raisonnement

9.1. Les types de données et les objets

9.1.1. Les données

Par rapport à un cas précis, il est possible de définir trois types de données :

• Les données d’identification : par exemple un numéro identifiant une personne.

• Les données descriptives : par exemple le nom, l’adresse, etc. pour une personne.

• Les données de liaison : par exemple le vol lie une personne et un bien.

Les besoins en données sont définis par des objets, objets qui doivent être également définis.

9.1.2. Les objets

La définition des objets nous oblige à réfléchir sur la définition même d’un cas de vol dans le cadre de

tout ce qui à été dit précédemment . A partir de la définition du Petit Robert, qui nous dit : « Vol : action

qui consiste à soustraire frauduleusement le bien d’autrui », nous pouvons constater que nous avons

d’ores et déjà deux objets principaux :

• Un objet « Personne ».

• Un objet « Bien ».

Cependant, pour nous, cette définition n’est pas suffisante. Nous ne nous intéressons pas seulement au

vol, mais au « cas » de vol, ce qui englobe tout ce qui tourne autour du vol à proprement parler, qu’il

s’agisse de l’interpellation, de la surveillance, etc…

« Un cas de vol est un vol ainsi que toutes les interactions ou actions en rapport avec ce vol ».

En bref, nous pouvons ici définir un nouvel objet :

• Un objet « Action »

Toutefois, notre liste n’est pas encore complète. En effet une des tâches de notre système est la gestion

des procédures. Nous pouvons définir une procédure comme une règle obligatoire, c’est à dire une suite

ou un enchaînement d’actions obligatoires. L’objet « Action » défini ci-dessus n’est pas suffisant,

puisque ce qui nous intéresse ici n’est pas une action en particulier, mais l’enchaînement en tant que tel.

Nous définissons donc un objet supplémentaire :



• Un objet « Procédure »

En résumé, nous avons ici quatre objets fondamentaux, complété de l’objet principal de l’étude qu’est

le cas en lui-même, enchaînement ou ensemble d’objets :

• Personne

• Bien

• Action

• Procédure

• Cas

Les besoins en connaissances concernent donc ces cinq objets, qu’il s’agira d’identifier, de décrire (et

de qualifier en répondant éventuellement aux questions où, comment, pourquoi, quand, etc..) et de lier le

cas échéant. Naturellement, en fonction des besoins, ces objets peuvent être déclinés en « sous-

objets ».

9.2. Les types de raisonnement

Les types de raisonnement listés dans la figure 5 sont les suivants :

• Sélection

• Assimilation

• Agrégation8

La méthode de codage n’est pas essentielle ici, puisqu’elle dépend des outils utilisés, non du système

lui-même (en terme de conception).

A ce niveau il est nécessaire de répondre à deux questions, soit :

• Quoi : que faut-il sélectionner, agréger ou assimiler ?

• Comment : comment sélectionner, agréger ou assimiler ?

Il est possible d’apporter un premier élément de réponse à l’aide du tableau suivant :

8 Ou toute fonction de regroupement



Quoi ? Comment ?

Sélectionner Tout Définition de critères

Agréger Tout Définition de fonction

Assimiler Tout Stocker

Figure 6: Quoi et comment agréger, sélectionner et assimiler?

Le tableau ci-dessus montre que toutes les données doivent pouvoir être :

• Sélectionnées : en fonction de critères que l’utilisateur devra choisir parmi les diverses

occurrences possibles associées et éventuellement un opérateur de comparaison.

• Agrégées : à l’aide de fonctions pré-définies ou selon une formule insérée par l’utilisateur. Il est

nécessaire ici de faire la distinction entre les données qualitatives et les données quantitatives. En

effet, pour les données qualitatives, seule une fonction de définition de fréquence est possible,

même si d’autres fonctions de calcul sont possibles dans un deuxième temps sur les fréquences

elles-même.

• Assimilées : à l’aide d’une fonctionnalité de stockage, chaque donnée doit pouvoir être

enregistrée. En fonction du moteur d’inférence choisi, il sera possible dans un deuxième temps

d’automatiser certaines fonctions d’agrégation qui pourraient être vues comme une assimilation.

Mais ces fonctions sont effectuées dans un deuxième temps.

En résumé, nous pouvons aborder la perspective des objectifs du système décrit dans le chapitre

« Hypothèses et postulats » selon trois axes qui sont :

• Le type de données

• Le type de raisonnement

• Les objets

selon le schéma suivant :

Objets

Typ

es d

e do

nnée

s



Figure 7 : Perspectives d’approche des objectifs

A l’aide de cette approche, nous pouvons définir assez précisément les besoins en connaissances.

9.3. Les besoins en connaissances

Nous pouvons donc définir à l’aide d’un tableau les besoins précis de connaissances. Dans le tableau

qui suit, non exhaustif, nous pouvons suivre la figure 7 en gardant à l’esprit les objectifs du système

décris dans le chapitre « Hypothèses et postulats ».

Identification Qualification Liaison

Sélectio

n

Agrégatio

n

Assimi-

lation

Sélection Agrégation Assimi-

lation

Sélection Agrégatio

n

Assimi-

lation

Cas Numéro Fréquence Stockage Date

Lieu

Erreur

Fin

Causes

Calcul

Fréquence

Fréquence

Calcul

Fréquence

Stockage Personne

Bien

Procédure

Action

Fréquence

Tri

Stockag

e

Personne Numéro Fréquence Stockage Nom

Date naiss.

Sexe

Adresse

Téléphone

Type

Fréquence

Calcul

Fréquence

Fréquence

Fréquence

Fréquence

Stockage Cas Tri Stockag

e

Bien Numéro Fréquence

Stockage Nom

Type

Prix

Fréquence

Calcul

Calcul

Stockage Cas Tri Stockag

e



Procédure Numéro Fréquence

Stockage Objet 1

Donnée 1

Valeur 1

Objet 2

Donnée 2

Valeur 2

Fréquence

Fréquence

Calcul

Fréquence

Fréquence

Calcul

Stockage Action

Cas

Stockag

e

Action Numéro Fréquence

Stockage Nom

Circonstanc

es

Lieu

Fréquence

Fréquence

Stockage Cas

Procédure

Stockag

e

Figure 8 : Application de la figure 7

9.3.1. Remarques

Relevons que trois méthodes d’agrégation sont possibles :

• Le tri

• Le calcul de fréquences

• Le calcul

Ces méthodes sont liées par une hiérarchie ou une inclusion. En effet, nous avons :

Tri ⊂ Calcul de fréquence ⊂ Calcul .

En effet, partout où les fonctions de calcul sont possibles, nous pouvons calculer une fréquence,

et partout où le calcul d’une fréquence est possible nous pouvons effectuer un tri. L’inverse

n’est pas vrai. Pour simplifier la lecture, seule est indiquée la fonction la plus large.

Concernant les types de données, chaque objet est identifié par un numéro qui a une fonction

d’identification. Pour les données de type descriptif, quelques précisions s’imposent, à l’aide du

tableau de définition (figure 9).

Pour les données de liaison, le tableau (figure 8) indique seulement les objets directement liés. Il

est évident que des liaisons indirectes sont possibles. De plus, le lien entre deux objets entraîne

obligatoirement un lien entre les données relatives à ces objets.

Concernant les procédures, les données qualificatives reprennent une structure « si…alors… ».

En effet, l’idée est de formaliser une procédure comme suit : si la donnée 1 appartenant à l’objet



1 prend la valeur 1, alors la donnée 2 appartenant à l’objet 2 prend la valeur 2.

Objets Données Définitions

Date Date du cas

Lieu Lieu de déroulement du cas

Erreur Y-a-t-il eu vol ou s’agit-il d’une erreur ?

Fin Indice de terminaison (violence, collaboration, etc..).

Cas

Cause Causes, circonstances ou contexte du cas

Nom Nom et prénom

Date de naissance Date de naissance et âge (par calcul)

Sexe Sexe de la personne

Adresse Rue, numéro postal, ville et pays

Téléphone Le numéro de téléphone de la personne

Personne

Type Client, service de sécurité, personnel

Nom Désignation du bien

Prix Prix ou valeur du bien Bien

Type Type de bien (appartenance à un rayon)



Objet 1 Objet imposant la procédure

Donnée 1 Donnée imposant la procédure

Valeur 1 Valeur imposant la procédure (ou critère)

Objet 2 Objet sur lequel porte la procédure

Donnée 2 Donnée sur laquelle porte la procédure

Procédure

Valeur 2 Valeur résultant de la procédure

Nom Désignation de l’action

Circonstances Circonstances, causes de l’action Action

Lieu Lieu de déroulement de l’action

Figure 9 : Précisions et définitions des données

10. Acquisition de connaissances

L’acquisition des connaissances pose le problème des sources de connaissances. Ces sources peuvent

être internes à l’entreprise ou externes. Pour schématiser les sources de connaissances, nous pouvons

utiliser en partie la figure 9 pour créer un tableau des sources (figure 10).

Ce tableau nous donne les sources de connaissances concernant les données. Nous pouvons lister ces

sources, en ajoutant l’expertise externe :

• La police : donne des indices, des avertissements (risque de vol) ou des règles à suivre.

• Le manuel du gérant : ensemble de procédures à l’attention des gérants de magasin.

• Règlements internes : ensemble de règles et de procédures définies par l’entreprise.

• La presse (et médias) : donne des éléments d’information (manifestations, évènements, etc.).

• Autres entreprises : donnent des informations sur des risques particuliers (fausses monnaies,

etc.).

• La loi : référence aux règles légales impératives (obligations et interdictions).

• Le contrôle des habitants : toutes les informations de base concernant les individus.

• Les fiches techniques : toutes les informations relatives aux biens.

• L’expérience : toute l’information provenant des gérants, des surveillants ou du personnel sur



une base intuitive.

• L’observation : l’observation directe d’un élément et sa constatation.

• Expertise externe

Ces onze sources de connaissances vont nous permettre de cerner les connaissances et de définir une

stratégie de gestion des connaissances, dans le but d’en obtenir une utilisation optimale.

Objets Données Sources

Date Observation

Lieu Observation

Erreur Observation

Fin Observation

Cas

Cause Observation, police, expérience, autres entreprises

Nom Papier d’identité, contrôle des habitants

Date de naissance Papier d’identité, contrôle des habitants

Sexe Observation, papier d’identité, contrôle des habitants

Adresse Papier d’identité, contrôle des habitants

Téléphone Annuaire

Personne

Type Observation, fichier du personnel

Bien Nom Fiche technique



Prix Fiche technique

Type Fiche technique

Objet 1 Police, loi, manuel du gérant, règlements internes

Donnée 1 Police, loi, manuel du gérant, règlements internes

Valeur 1 Police, loi, manuel du gérant, règlements internes

Objet 2 Police, loi, manuel du gérant, règlements internes

Donnée 2 Police, loi, manuel du gérant, règlements internes

Procédure

Valeur 2 Police, loi, manuel du gérant, règlements internes

Nom Observation

Circonstances Observation, presse, police, autres entreprises Action

Lieu Observation

Figure 10 : Tableau des sources de connaissances

11. Choix d’une stratégie de gestion des connaissances

Le choix d’une stratégie de gestion des connaissances va dépendre des sources de connaissances. La

question à se poser est « Comment utiliser cette source de connaissances ? ». Pour définir ces

stratégies, nous pouvons créer un tableau indiquant, pour chaque source, une utilisation possible. De

plus, nous pouvons également indiquer pour chaque source par quel moyen elle intégrera notre système.

Le tableau suivant donne ces indications :

Sources Utilisation Intégration

Police Collaboration et contacts fréquents Procédures et données

Manuel du gérant Révision et distribution Procédures

Règlements internes Révision et distribution Procédures

Presse et média Revue de presse, suivi Données

Autres entreprises Collaboration et contacts fréquents Données

Loi Mise à jour des compétences Procédures



Contrôle des habitants Par téléphone si besoin -

Fiches techniques Révision et distribution Données

Expérience Intégration et analyse, cours et séminaires Données

Observation Intégration et analyse Données

Expertise externe Cours et séminaires -

Figure 11 : Utilisation et intégration des sources de connaissances

Précisons encore que par « intégration et analyse », il est entendu une intégration, au travers de la saisie des données et de la conception même du système des éléments d’expérience et d’observation. L’aspect de la conception sera abordé plus loin.

11.1. Précisions

La figure 11 indique comment gérer les sources de connaissances. Cependant elle offre également une

information quant à la gestion des connaissances elles-mêmes. En effet, nous constatons qu’excepté

l’expertise externe et les fichiers du contrôle des habitants, toutes les connaissances peuvent être

intégrées dans le système, soit au travers des procédures, soit au travers des données. Nous constatons

cependant que toutes les sources de connaissances offrent comme information soit un fait constaté, soit

une règle à suivre. Deux exceptions à cette constatation : l’expertise externe et l’expérience.

L’expérience n’est rien d’autre qu’une expertise interne. Cette expertise, qu’elle soit externe ou interne,

transmet donc un savoir théorique et une expérience de terrain. Si le savoir théorique peut être transmis

par des cours ou des séminaires, l’expérience est plus intuitive. Comment transmettre une manière de

faire non formelle, intuitive et qui concerne une problématique où les rapports humains et la subjectivité

jouent un rôle important, puisqu’il s’agit de cerner un ensemble d’interactions humaines ? C’est le

chapitre suivant, concernant l’expression des connaissances qui nous offre la réponse. Cependant, nous

pouvons d’ores et déjà signaler que nous aurons une stratégie de gestion des connaissances basée une

caractéristique des connaissances, caractéristique qui peut prendre deux valeurs :

• Objective (ou qui peut être raisonnée)

• Subjective (ou instinctive)

Par une connaissance objective, il est entendu une connaissance qui découle d’une règle ou d’un fait qui

peut être défini par réflexion. A titre d’exemple, une règle de procédure, une observation ou un texte de

loi sont des données objectives. Par donnée subjective, il est entendu une connaissance intuitive. A titre

d’exemple, la réaction face à un voleur agressif est un comportement intuitif ou instinctif qui ne peut, la



plupart du temps, être cerné qu’au moment où il se produit. Si nous demandons à quelqu’un ce qu’il

ferait dans ce cas, nous aurons certainement une réponse intéressante, mais biaisée par divers éléments

extérieurs et surtout une part de réflexion. Mais pour connaître véritablement ce que cette personne

ferait, seule l’observation donne une réponse sans appel car elle permet le constat pur et simple. Or

l’expérience est de ce type. L’expérience relève du réflexe plus que de la réflexion. Le Petit Robert

donne comme synonymes de l’expérience, entre autres, « routine » et « habitude », deux termes qui

généralement excluent la réflexion. Agir par habitude, c’est agir machinalement.

Nous pouvons donc définir une stratégie de gestion des connaissances basée sur trois piliers, dont le

principal est certainement le premier :

• Saisie et traitement par le système

• La gestion de documents

• La transmission orale (cours, etc)

Dès maintenant, ce qui va nous intéresser est la saisie et le traitement par le système. La transmission

orale (cours, tutorat, etc) ainsi que la gestion de documents ne seront plus abordés excepté, pour ce

dernier point, l’accès automatique éventuel aux procès verbaux.

12. Expression des connaissances

L’expression des connaissances concerne ici les moyens et méthodes pour formaliser et coder les

connaissances dans notre système. La figure 11 nous a donné les sources de connaissances, comment

en tirer l’information (la connaissance brute) et comment intégrer cette information dans notre système.

Notons que pour l’observation et l’expérience, l’utilisation de la source de connaissances suppose une

intégration et une analyse au travers de notre système, alors que les autres sources peuvent être gérées

indépendamment de celui-ci. Dans tous les cas (excepté l’expertise externe et le contrôle des habitants),

toutes les informations peuvent être saisies sous forme de données, y compris l’expérience et

l’observation. La particularité de ces deux sources de connaissances est que l’expression de la

connaissance ne se contente pas d’une simple saisie de données, mais est totale à condition de mettre en

place une structure de données. Nous avons donc deux outils d’expression des connaissances :

• Les données en tant que tel

• La structure des données

La structure est un élément essentiel de cette expression, comme la syntaxe peut être essentielle à la



langue. Dans une langue, nous avons en effet des listes de mots, mais c’est la syntaxe qui est l’élément

essentiel du sens, au-delà de la sémantique. En effet, chaque mot à un sens intrinsèque, mais c’est

l’enchaînement lui-même qui donne un sens global à une proposition.

Or si nous reprenons la définition d’un cas de vol donnée précédemment :

« Un cas de vol est un vol ainsi que toutes les interactions ou action en rapport avec ce vol »

Nous constatons que nous avons bien affaire à un enchaînement d’actions ou d’interactions, et que si

l’action est importante intrinsèquement, l’enchaînement et l’ordre d’enchaînement sont les éléments

porteurs et générateurs de connaissances nouvelles, et que l’expérience dans la manière de traiter un cas

sera exprimée principalement par l’enchaînement plutôt que par une liste d’actions.

En conséquence, nous allons tenter de définir un nouveau langage avec comme base de référence la

langue française, mais en créant une nouvelle grammaire nous permettant de répondre à notre

problématique. L’avantage de cette approche est que la nouvelle grammaire définie peut être

rapprochée de toutes les langues de base latine ou germanique (pour le moins).

12.1. Création du langage

Pour la création de notre langage, nous allons, tout en gardant le vocabulaire de la langue française, nous

intéresser à la morphologie9 et à la syntaxe10 de ce langage.

En terme de syntaxe, il est nécessaire de garder à l’esprit l’objectif cherché : enregistrer l’expérience (en

plus des données brutes). Nous avons précisé plus haut que c’est l’enchaînement d’actions ou

d’interactions qui était important. En conséquence, il est nécessaire de définir une structure unitaire la

plus simple possible, de manière à obtenir une précision optimale au niveau de l’ensemble. Nous

pouvons définir d’ores et déjà l’action comme un élément de cette structure unitaire. Cependant, l’action

ne suffit pas. L’intérêt porte également sur la source de l’action, et sur l’objet de l’action. La structure

unitaire est donc la suivante :

Source + Action + Objet

Cependant, cette structure de base n’est pas tout à fait suffisante. Dire « le surveillant attrape le voleur »

est intéressant, mais l’information permettant de répondre aux questions « Où ? », « Avec quoi ? »,

9 La morphologie englobe les catégories de mots, la déclinaison et la conjugaison



« Pourquoi ? », etc. (et parfois « Combien ? ») est également intéressante. Il est donc nécessaire

d’intégrer la notion de « circonstance » dans notre structure unitaire, ainsi qu’une qualification numérique

de l’objet de l’action.

Nous avons donc en final la structure suivante :

Source + Action + Qualification numérique + Objet + circonstances

En linguistique, notre structure correspond à :

Sujet + Prédicat11 + numéral + COD12 + Compléments circonstanciels

Notons que pour respecter la structure unitaire, non seulement le numéral ne peut concerner que des

objets inanimés mais qu’il est impératif d’empêcher l’utilisation de groupe verbal, de groupe nominal,

etc. En conséquence, notre structure se limite à l’échelle de la proposition13, rendant impossible la

phrase. De plus, par souci de simplification, seule une action directe est admise (« le voleur est interpellé

par un surveillant » est interdit. Seul est autorisé « le surveillant interpelle le voleur »). Pour simplifier la

formule, nous imposons que le sujet est obligatoirement une personne.

Cependant, s’arrêter à l’aspect syntaxique n’est pas suffisant pour préserver l’aspect unitaire de cette

structure. Il nous faut se pencher sur l’aspect morphologique pour donner des règles d’expression qui

garantissent cette nécessité.

En conséquence, le langage créé ne comporte que trois catégories morphologiques :

• Les substantifs.

• Les verbes.

• Les numéros.

Ceci nous permet principalement de supprimer :

• Les adverbes et les adjectifs qui risquent d’amener une subjectivité supplémentaire (en effet, la

valeur de « rapidement » ou « rapide » est relative).

• Les pronoms qui peuvent être remplacés par des substantifs.

• Les conjonctions, rendues inutiles par l’imposition d’une structure limitée à la proposition.

• Les prépositions puisque qu’elles sont remplacées par une qualification des compléments

10 La syntaxe défini les règles d’enchaînement des mots ou des propositions 11 Le prédicat est une catégorie syntaxique : qui concerne le sujet 12 Complément d’objet direct



circonstanciels au sein même de notre système.

• Les articles : l’information quant au genre, au cas et au nombre n’est pas utile dans notre

problématique. De plus, seul le singulier caractérise nos substantifs, puisque chaque substantif

est nominalisé.

Notre langage ne comporte ni conjugaison, ni déclinaison. En effet, l’absence de conjugaison est rendue

possible par l’imposition de l’infinitif pour tous les verbes14 exprimant le prédicat de notre structure.

L’absence de déclinaison est possible en imposant les règles suivantes :

• Impossibilité d’avoir un COI15 dans notre structure, ce qui élimine le datif (dû à l’imposition de

l’action directe).

• Impossibilité d’avoir un attribut du sujet, ce qui élimine le génitif (dû à notre structure unitaire).

• L’imposition de l’infinitif exclu le mode16 impératif, ce qui élimine le vocatif.

• Le nominatif est inutile puisque déduit de notre structure même. En effet, le sujet appelle le

nominatif et le sujet précède obligatoirement le prédicat.

• L’accusatif est inutile puisque définit par déduction dans notre structure. Par défaut, tout ce qui

suit le prédicat est accusatif.

De plus, tous les compléments sont également des substantifs.

Ajoutons que certains compléments circonstanciels sont abandonnés, notamment les compléments :

• De but (ex : afin de…) : la notion du futur n’est pas essentielle.

• De condition (ex : en cas de…) : inutiles puisqu’une action est un constat (s’est produite).

• De concession (ex : malgré…) : apportent une nuance non essentielle.

• D’association (ex : avec…): ne respectent pas la structure unitaire.

• Cumulatifs (ex : ensemble) : ne respectent pas la structure unitaire.

• De mode (ex : rapide) : impliquent une subjectivité dans l’interprétation ou apporte une nuance

non essentielle.

• Consécutifs ( ex : jolie à croquer) : ne respectent pas la structure unitaire.

13 En grammaire, unité syntaxique élémentaire de la phrase, généralement construite autour d’un verbe 14 Un verbe est une catégorie morphologique : mot exprimant une action ou un ensemble d’action 15 Complément d’objet indirect 16 Le mode est la forme verbale qui exprime la manière dont l’action est présentée (infinitif, impératif, conditionnel, etc.)



• Fréquentatifs (ex : toujours) : ne respectent pas la structure unitaire.

• D’agent : (ex : il est arrêté par …) : supposent une action passive.

• Comparatifs (ex : plus petit que …) : ne respectent pas la structure unitaire.

• D’exclusion (ex : sans moi) : ne respectent pas la structure unitaire.

• D’opposition : ne concernent que les phrases.

• Restriction : ne concerne que les phrases.

Restent les compléments de :

• De temps : qui permettent de répondre à la question « quand » se déroule l’action.

• De lieu : qui permettent de répondre à la question « où » se déroule l’action

• De cause : qui permettent de répondre à la question de « l’origine » de l’action

• Instrumentaux : qui permettent de répondre à la question « à l’aide de quels moyens » se déroule

l’action

En résumé, les connaissances sont exprimées selon un langage suivant les règles suivantes :

• Unité d’une proposition.

• Le sujet est une personne.

• Que des substantifs et des verbes.

• Un seul mode : l’infinitif.

• Une structure imposée : sujet + prédicat + numéral + COD + compléments circonstanciels.

• Pas de conjugaison.

• Pas de déclinaison.

• Numéral uniquement pour les substantifs inanimés.

• Compléments circonstanciels limités aux compléments :

o De lieu.

o De temps.

o De cause.



o Instrumentaux.

12.2. Remarques

Quelques remarques s’imposent sur notre langage. Notre structure est ici une structure logique

linguistique. Il est évident que le système informatique derrière cette structure sera adapté pour une

optimisation de traitement. La vue présentée ici en terme d’expression des connaissances s’adresse

donc principalement à l’utilisateur. Le problème du codage en arrière plan n’est pas abordé dans ce

chapitre.

De plus, en ce qui concerne les personnes, voir les objets, il est important de relativiser le terme

« substantif ». Le COD, le sujet et les compléments circonstanciels sont obligatoirement des substantifs

dans notre langage. Là aussi se cache une abstraction. En effet, pour exprimer le fait que M. Dupond

vole trois pains, une structure comme suit :

Dupond / voler / 3 / pain

Il est évident qu’en arrière plan, Dupond sera qualifié par un prénom, une adresse, etc. De même, pain

sera qualifié par un type, un prix, etc.

En bref, notre langage donne une manière formelle d’exprimer les connaissances sur papier (rappelons

que la connaissance que nous cherchons à exprimer par ce langage est une connaissance

d’enchaînement des actions, une structure). Ce sera à notre système, dans un deuxième temps,

d’identifier « Dupond » et « pain ». La qualification de ces deux substantifs ne fait plus partie du

problème structurel du langage, mais de l’identification des besoins de connaissances et de leur

expression sous forme de données brutes.

12.3. Enchaînements et combinaison du langage

Nous avons défini un langage permettant de formaliser le problème de structure. Ce langage nous

permet d’exprimer une action élémentaire dans une structure unitaire.

Cependant l’expérience et l’observation découlent comme dit précédemment d’un enchaînement

d’actions ou d’interactions. Reste donc la question de l’expression de cet enchaînement. Cette

expression peut être réalisée par défaut en utilisant le complément circonstanciel de temps. Non

seulement ce complément nous offre une information sur les circonstances de l’action, mais, de plus, il

nous offre une information sur l’ordre chronologique du déroulement de l’ensemble des actions.

Or la chronologie peut être vue de deux manières différentes. Soit deux actions A et B ayant lieu dans



cet ordre. Nous pouvons dire soit « A précède B » soit « B suit A ».

Les deux approches sont équivalentes. Un choix arbitraire est fait pour privilégier la première. Ceci

signifie que nous posons comme ordre de lien un ordre « Amont-Aval » et non l’inverse.

Cependant le lien chronologique n’est pas suffisant. En effet, si l’on se réfère à la définition du cas de vol

donnée précédemment, soit « un cas de vol est un vol ainsi que toutes les interactions ou actions en

rapport avec ce vol », on constate que l’ordre chronologique ne donne pas nécessairement le lien

d’interaction.

Mais il est possible de combiner les deux aspects, ordre chronologique et lien d’interaction, dans une

approche « stimulus-réponse ». L’idée est que puisque nous avons des actions unitaires ou

élémentaires, il est possible de faire l’hypothèse que pour chaque intervenant dans un cas de vol, une

action entraîne obligatoirement une réaction d’un autre intervenant, et qu’une action est elle-même une

réaction. En effet, même l’absence de réaction est une réaction en soi. Ceci connaît pourtant une

exception : « l’initialisation ». En effet, il est évident qu’il doit exister au moins une première action,

comme il existe nécessairement une dernière action. Puisque le lien d’interaction se fait dans le sens

« Amont-Aval », il existe une première valeur nulle pour l’aval, soit le début de l’enchaînement. Ceci

peut être résolu par l’existence d’un complément de cause. Nous pouvons donc poser une règle

supplémentaire :

• Un ensemble d’interactions est un enchaînement d’actions où chacune d’elle est une réaction à

la précédente, excepté pour la première action qui est dépendante d’une cause extérieure à cet

enchaînement.

Cette règle, basée sur le principe stimulus-réponse, peut être représentée de la manière suivante :

Figure 12 : Schéma de Stimulus-Réponse

Action RéactionCause



12.4. Langage complet

L’expression des connaissances définie ici prend comme assise les sources de connaissances existantes.

Outre l’expertise externe, le contrôle des habitants et une partie de l’expertise interne, toutes les

connaissances utiles s’appuient donc sur trois piliers principaux :

• Des données

• Une structure

• Une règle d’enchaînement

Ceci permet de définir un principe général d’expression des connaissances. L’implantation de ce

principe pourra bien sûr être adapté, puisque se posera la question de savoir où commence

l’enchaînement.

Nous avons donc le système général suivant :

Figure 13 : Schéma du langage

Relevons que les données relatives au cas (ainsi que les procédures - voir ci-dessous) ne sont pas

intégrées dans notre structure. En effet une telle intégration n’est pas nécessaire ni utile, puisque ces

données ne sont que des descriptions générales du cas. Ces données ne sont donc pas concernées par

les règles de grammaire décrites précédemment.

12.5. Les procédures

On constate dans la figure précédente que les données relatives aux procédures sont à part. En effet,

une procédure (en tant que donnée) n’est pas soumise aux règles de structure ou d’enchaînement. En

effet, si l’on s’intéresse à la structure de la procédure telle qu’elle est définie dans le chapitre

Cas

Sujet + Prédicat + numéral + COD + Compléments circonstanciels

Cause Action RéactionCause Action Réaction

PersonneActionBien ProcédureDonnées:

Structure:

Enchaînement:



« Acquisition des connaissances », soit :

Objet 1 + Donnée 1 + Valeur 1 + Objet 2 + Donnée 2 + Valeur 2

où la valeur peut également être un critère, le principe est que si la valeur 1 associée à la donnée 1

relative à l’objet 1 est vraie, alors la valeur 2 doit être associée à la donnée 2 relative à l’objet 2. Il s’agit

ici du principe des règles de procédures selon le concept :

Si Condition Vrai, alors Résultat

La condition est l’ensemble Objet 1 + Donnée 1 + Valeur 1 et le résultat par l’ensemble Objet 2 +

Donnée 2 + Valeur 2.

La procédure n’entre pas dans le cadre de la structure ou de l’enchaînement définis à la figure 13, mais

influe sur l’enchaînement en imposant des actions ou des valeurs aux différents éléments de la structure

syntaxique.

Toutes les procédures devront donc être exprimées sur ce principe. L’intégration des procédures dans

le schéma général présenté à la figure 13 se fait selon le schéma de la figure 14.

L’expression des connaissances, utilise donc, en plus des données, structures et des règles

d’enchaînement des règles de définition de valeur.

12.6. Les procédures obligatoires et non obligatoires

Il est une distinction importante à faire au sein même des procédures. Cette distinction est la notion

d’obligation. En effet, certaines procédures sont impératives, pour des causes légales ou internes à

l’entreprise, alors que d’autres offrent la possibilité aux intervenants de s’adapter aux conséquences, le

plus souvent lorsque des procédures sont contradictoires ou susceptibles de l’être. A titre d’exemple,

les règlements internes donnent comme règle un appel aux forces de l’ordre lorsqu’un cas de récidive se

présente. Cependant, une autre règle conseillant une grande diplomatie envers les personnes âgées, les

femmes enceintes, etc.. laisse aux intervenants une marge de manœuvre. D’autre part, en pratique,

l’appel aux forces de l’ordre se fait principalement en cas de multi-récidive.

Nous avons ici un exemple concret d’une procédure qui en fait n’est qu’une recommandation.

L’intégration des procédures dans le schéma général, comme décrit dans la figure 14 doit être

relativisée. Ce schéma s’impose en effet uniquement pour les procédures obligatoires.

Les procédures assimilées à des recommandations sont intégrées avec une modification importante :

suite à la phase de test, la procédure ne définit pas une donnée de notre structure, mais une donnée d’un



autre objet nommé « indication » (cf. le prototype) qui définira simplement le contenu de boîtes de

dialogue.

En résumé, quel que soit le type de procédure, la structure est identique à celle décrite plus haut, mais

l’objet touché n’est plus un élément du langage.

Figure 14 : Langage et procédures


PersonneActionBien

Objet 2 + Données 2 + valeur 2

Objet 1 + Données 1 + valeur 1


PersonneActionBien

TestTest

DéfinitDéfinit



Partie IV – Conception et modélisation du business

13. Outil de modélisation

Maintenant que nous avons défini la méthodologie, les besoins de connaissances, la stratégie de gestion

des connaissances, l’acquisition et l’expression des connaissances, il nous faut comprendre et modéliser

le business, autrement dit la problématique générale de la sécurité dans l’entreprise COOP Vaud

Chablais valaisan dans le cadre que nous avons défini. Pour ce faire, nous allons utiliser le langage de

modélisation UML17 dans une approche orientée objet.

UML se base sur quatre vues, selon le schéma suivant développé par [Muller 97] :

Figure 15 : approche 4+1 vues

Outre ces 4+1 vues, UML propose de manière transversale un total de neuf diagrammes, soit :

• Diagramme des cas d’utilisation (use-case)

• Diagramme d’objet

• Diagramme de collaboration

17 Unified Modeling Language

VueLogique

Vue desprocessus

Vue dedéploiement

Vue descomposants

Vues des cas d’utilisation



• Diagramme de séquence

• Diagramme de classe

• Diagramme d’état transition

• Diagramme d’activité

• Diagramme de composants

• Diagramme de déploiement

Cependant, N.Kettani [Kettani 98] explique l’importance de la dimension métier d’un système

d’information. Il définit la modélisation du métier comme l’ensemble des étapes suivantes :

• L’étude du périmètre des intervenants extérieurs à l’entreprise

• L’étude des processus de l’entreprise

• L’étude des travailleurs et des entités de l’entreprise

• L’étude des workflows des processus

• L’étude des structures organisationnelles

Le tout suppose d’intégrer les processus de développement du système informatique dans le processus

d’ingénierie de métier, de construire le système informatique dont le métier a besoin (et non l’inverse) et

d’utiliser les mêmes concepts pour un métier et pour son système.

Dans le cadre du présent mémoire, l’objectif n’est pas la réalisation complète d’un système

d’information opérationnel, mais de définir une méthode de conception et de créer un prototype. Ajouté

à la contrainte temporelle, il est évident qu’il n’est pas possible de réaliser une modélisation complète

selon les deux composantes que sont les vues et les diagrammes.

De plus, nous ne cherchons pas à modéliser une entreprise mais une activité seulement de celle-ci,

modélisation dont la difficulté est due à l’existence d’un système compliqué mais non complexe (au sens

systémique). En conséquence, certains diagrammes ne sont pas essentiels. Dans notre cas, le diagramme

d’état transition n’apporte aucun élément utile, puisque les objets définis précédemment ne subissent

aucun changement d’état lors des processus. En outre, le diagramme d’objet n’est pas ici utile, puisque

le diagramme de classe apporte la même information (en plus détaillé). Ajoutons que le diagramme

d’activité n’apporte pas non plus d’information essentielle puisque que celle-ci peut se voir dans le

diagramme des cas d’utilisation et que le détail des activités est justement l’inconnu que nous cherchons

à saisir.



D’autre part, nous ne sommes pas dans un service ayant une activité industrielle. Les processus sont des

ensembles de relations humaines, ce qui entraîne logiquement une communion des concepts de

processus et de collaboration. Un diagramme de séquence englobe donc l’information contenue dans un

diagramme de collaboration ou d’activité.

Ceci étant dit, nous pouvons déduire que seuls cinq diagrammes sur neuf sont utiles pour nous. Ceux-ci

sont :

• Le diagramme de classe

• Le use case (diagramme des cas d’utilisation)

• Le diagramme de séquences

• Le diagramme de composant

• Le diagramme de déploiement

Naturellement, même dans le cadre restrictif de ces cinq diagrammes, toutes les situations ne peuvent

être abordées, faute de temps. Nous allons donc présenter ces cinq diagrammes dans une forme non

exhaustive et à titre principal d’illustration.

14. Diagramme de classe

Concernant le diagramme de classe, nous pouvons ici nous baser sur les objets, du moins dans un

premier temps, définis dans le chapitre « besoin de connaissances ».

Ces objets sont :

• Les cas : l’objet cas est un objet englobant données et enchaînement

• Les personnes : l’objet personne peut se décliner en divers types selon les besoins

• Les biens : l’objet bien peut se décliner en divers types selon les besoins

• Les procédures : l’objet procédure peut se décliner en procédure obligatoire et non obligatoire

• Les actions : l’action de base, unitaire

Il est possible de rajouter certains objets, de manière à simplifier l’approche et la compréhension du

business. Ceci peut bien sûr apporter quelques modifications à la liste du chapitre « Besoin de



connaissances », liste rappelons-le qui n’est pas exhaustive d’une part, et qui prend place dans une

réflexion plus large que la modélisation d’autre part. Notamment, nous pouvons définir 5 classes

d’objets supplémentaires :

• Le lieu : le lieu où se déroule un cas ou une action

• Les moyens : les moyens d’action mis en œuvre

• Les processus : le processus sous-jacent à l’action

• Les causes : la cause d’une action

• Le contexte : le contexte général du cas

A l’aide de ces classes, nous pouvons construire le diagramme de classe :

Figure 16 : Diagramme de classe

Ce diagramme nous montre les diverses classes d’objets et leurs relations entre elles.

15. Use case

Le use case possède ici un rôle important, puisqu’il pose le problème de l’utilisation de notre système.

Nous commençons en premier lieu à définir les acteurs du métier, qui sont ici :

• Le client

• Le surveillant

Cas

Personnes

Biens

Procédures

Actions

Lieu

Cause

Moyens

Processus

Contexte

Prédicat

englobe 1..*

produit 1..*

sélectionne 1..*

définit 1..* est 1-1

Prend place dans 1-1

utilise 1..*

appartient à 1-1

utilise 1..*

implique 1..*définit 1..*

utilise 1-1

Cas

Personnes

Biens

Procédures

Actions

Lieu

Cause

Moyens

Processus

Contexte

Prédicat

englobe 1..*

produit 1..*

sélectionne 1..*

définit 1..* est 1-1

Prend place dans 1-1

utilise 1..*

appartient à 1-1

utilise 1..*

implique 1..*définit 1..*

utilise 1-1



• L’interpellant

• Le personnel du magasin

• Le chef de la sécurité

• Les tiers

Une fois ceci fait, il est important de définir les acteurs de notre système, qui sont les mêmes personnes,

mais dans une approche de fonction. Ici, le même acteur du métier peut endosser plusieurs vestes

différentes comme acteur du système.

Ceux-ci sont, en rappelant que notre objectif principal, dans l’utilisation de notre système, est la gestion

et la formation :

• Le gestionnaire : le gestionnaire du système

• L’élève : en formation

• Le formateur : celui qui a la charge de la formation

• Le surveillant : celui qui effectue la surveillance

• L’interpellant : celui qui interpelle l’auteur du délit

• L’administrateur : s’occupe des problèmes administratifs (saisies, etc…)

Nous pouvons dès lors construire un use case. Ici nous en présentons un, où le gestionnaire du système

n’apparaît pas, dans le but d’en faciliter la compréhension, de même que l’administrateur. Le rôle du

gestionnaire se définit comme un rôle de modérateur, de contrôle des entrées dans le système, de

maintien de la cohérence et un rôle général de supervision. Le rôle de l’administrateur est une notion de

fonction, rôle remplit ici par tous les intervenants excepté l’élève.



Figure 17 : Use case

La liste des tâches effectuées par le système n’est bien sûr pas complète, mais donne ici une idée des

possibilités offertes.

16. Séquences

Surveillant

Calcule des risques

Gestion d'indices

Génère des profils

Interpellant

Traite les requêtes

Elève

Indique des procédures

Indique les cas délicats

Formateur

Surveillant

Calcule des risques

Gestion d'indices

Génère des profils

Interpellant

Traite les requêtes

Elève

Indique des procédures

Indique les cas délicats

Formateur



Le diagramme de séquences montre les interactions, entre les objets, arrangées en séquences dans le

temps. En particulier, il montre les objets participant dans l’interaction par leur « ligne de vie » et les

messages qu’ils échangent ordonnancés dans le temps. Il ne montre pas les associations entre objets

[Kettani 98]. Cette définition est illustrée ici par un diagramme présentant le déroulement d’un cas de

vol.

Figure 18 : Diagramme de séquence

Bien évidemment, le diagramme ci-dessus n’est qu’une illustration permettant de voir, de manière

simplifiée, le déroulement d’un cas de vol. Il est important de préciser encore que les objets présentés

sont des personnes, définies par leurs fonctions. L’interpellant et le surveillant, par exemple, sont le plus

souvent une seule et même personne.

17. Diagramme de composants

Surveillant Personnesoupçonée

Interpellant Administrateur Gestionnaire

Remarquer

Hesiter

Rechercher

Avertitr et Informer

Arreter

Reagir ou collaborer

Appeler

Verifier BD

Assister

Poser des questions

Repondre

Demander informationssuplem.

Fournir justification

Decider

Expliquer la décision

Payer, restituer ou Réfuser

Remplir les formulaires

Transmettre les informations

Modifier BD

Donner des instructions

Surveillant Personnesoupçonée

Interpellant Administrateur Gestionnaire

Remarquer

Hesiter

Rechercher

Avertitr et Informer

Arreter

Reagir ou collaborer

Appeler

Verifier BD

Assister

Poser des questions

Repondre

Demander informationssuplem.

Fournir justification

Decider

Expliquer la décision

Payer, restituer ou Réfuser

Remplir les formulaires

Transmettre les informations

Modifier BD

Donner des instructions



Le diagramme de composants donne l’interaction entre différents modules logiciels. Ici est présenté un

modèle illustratif permettant de se faire une idée des différents modules que l’on pourrait éventuellement

trouver.

Figure 19 : Diagramme de composants

Les différents modules sont dérivés des objets et des classes définies précédemment. Un schéma

complet nécessiterai plusieurs schémas permettant de définir l’ensemble du système. Cependant, bien

qu’incomplet, ce diagramme donne une vue grossière de ce qui serait souhaitable dans une modélisation

complète.

Clients Produits Employes

Base de données

ClientsAvertis

ClientsInrerpellés

ClientsProuvé

En cas de Preuve

Eduquer Surveiller

ProcessusInformel

Pas d'enregistrement

DB Clients Interpellés



18. Diagramme de déploiement

Le dernier diagramme présenté est le diagramme de déploiement. Il donne une idée de l’architecture

générale que devrait avoir l’implémentation du système. Là aussi, il ne s’agit qu’une représentation

illustrative, donnant une idée d’une implantation possible.

Figure 20 : Diagramme de déploiement

On constate que la proposition est ici de lier entre elles les différentes coopératives régionales. Au sein

de chaque coopérative régionale, il existe des relations informatiques avec les magasins et les centres de

formation. Le tout étant relié à un serveur central, permettant une agrégation des données au niveau

national.

Naturellement, à chaque niveau, il est possible d’intégrer des périphériques, comme un serveur

d’impression par exemple. De plus, l’utilisation d’Internet permet des liens avec divers serveurs, internes

ou externes à l’entreprise. Non seulement il est facile d’imaginer des liens avec d’autres services de

l’entreprise, comme les achats par exemple (dans le but d’une modification directe de certaines

données), mais aussi avec d’autres partenaires ou entreprises, parfois concurrentes mais partenaires

dans le domaine de la sécurité.

ServeurGeneve

Serveur central

Serveurweb

Poste acheteur

Serveurd'impres

SGBD

Internet

Consulter marché

ServeurVaud

Serveur magasin

Serveur C.format

SGBD régional

SGBD local

SGBD local

SGBD local

Consulter historique

Serveurmagasin

Serveurmagasin

ServeurC.format

Serveurmagasin

SGBD local

SGBD local

SGBD local SGBD régional

Consulter historiqueConsulter historique



Partie V – Moteur d’inférence

19. Définition des besoins d’inférence

Il est important dans cette définition de garder à l’esprit les objectifs du système et principalement de se

souvenir des fonctionnalités de base définies dans le chapitre « Hypothèses et postulats ». Ces

fonctionnalités étaient (et restent) celles-ci :

• Interpréter une requête en langage structuré

• Proposer une réponse pertinente

• Apprendre et évoluer

• Générer des scénarii

• Décrire diverses situations

• Illustrer une problématique

• Tester divers comportements/réactions

• Générer des profils

• Déceler des problèmes sous-jacents : attirer l’attention sur des éléments probables

• Traiter des indices : générer des probabilités suivant divers éléments

• Traiter des données : divers types de traitements statistiques

• Offrir une bibliothèque de cas : permettre la gestion des documents papiers

• Gérer les procédures : indiquer les règles d’action existantes, proposer des règles d’action

Ces fonctionnalités paraissent à priori essentielles dans les réponses aux besoins de l’entreprise. Elles

permettent d’offrir un soutien autant dans la formation que dans la gestion.

Nous pouvons définir trois groupes de fonctions à partir de ces hypothèses :

• Fonctions d’extraction suite à une question : ces fonctions permettent non seulement de

répondre à une question, mais également d’illustrer une certaine problématique

• Fonctions d’extraction en vue d’un traitement statistique : ces fonctions doivent préparer les

données extraites en vue d’un traitement quelconque.

• Fonctions de génération de scénarii (ou de test) : doivent permettre de générer des scénarii dans



le but de simuler des jeux de rôle, en cohérence avec la réalité.

La bonne marche de ces groupes de fonctions dépend naturellement des types de raisonnement définis

dans le chapitre « besoin de connaissances ». Ces types étaient :

• Sélection

• Assimilation

• Agrégation

La réflexion concernant la modélisation du moteur d’inférence doit donc s’appuyer sur une matrice à

deux dimensions qui permet de définir la méthode qui nous permettra de répondre aux deux objectifs.

Le chapitre « modélisation des moteurs d’inférence » détaillera cette matrice qui est la suivante :

Extraction :question Extraction : statistique Extraction :scénarii Sélection Critères Critères Probabilité Assimilation - - Probabilité Agrégation Probabilité et proximité Calcul ou néant Probabilité

Figure 21 : Matrice de réflexion du moteur d’inférence On distingue à partir de cette matrice quatre type de méthodes :

• L’utilisation de critères de recherche

• L’utilisation des probabilités

• L’utilisation de la notion de proximité

• L’utilisation de fonctions de calculs

Ces types de méthodes vont définir les choix des moteurs d’inférence. Mais le choix des moteurs d’inférence

influence également l’utilisation des ces types de méthodes. Il y a ici un raisonnement itératif.

En outre, les fonctions de calculs ne sont pas vraiment un élément d’inférence, de même que l’utilisation de

critères. Ces deux derniers éléments ne correspondent pas ici à la définition d’un moteur d’inférence (permettant

d’automatiser une opération logique permettant d’admettre une proposition en vertu de sa liaison avec d’autres

propositions tenues pour vraies). Reste donc deux méthodes utiles pour les moteurs d’inférence, l’utilisation de la

proximité et des probabilités. L’utilisation de critères et les fonctions de calcul n’ont pas d’utilité ici, dans la

conception du moteur d’inférence, mais en auront naturellement dans la conception du prototype, puisque

qu’elles correspondent à des fonctionnalités prévues pour l’utilisateur.



20. Choix des moteurs d’inférence

Quels moteurs d’inférence allons choisir, ou plutôt quels types de moteur d’inférence. La principale

question est de choisir entre deux types principaux :

• Moteur basé sur des règles de procédures

• Moteur basé sur des stéréotypes

Puisque nous avons des procédures, aurons-nous naturellement un moteur d’inférence basé sur les

règles de procédures ?

Il est essentiel de se souvenir que dans notre système, les procédures sont là pour guider l’enchaînement

d’actions, non pour générer une opération logique de lien. De plus, il ne faut pas perdre de vue que

l’élément essentiel à intégrer dans notre système est l’expérience. Il s’agit d’un enchaînement variable

d’actions unitaires variables. L’utilisation de règles de procédure est ici irréaliste. En effet, il est

impossible de définir une règle de procédure liant l’action d’un individu (par exemple l’interpellation) et

la réaction d’un autre individu (par exemple la collaboration). En cas d’interpellation, les possibilités de

réaction sont à priori aussi nombreuses qu’il y a d’individu sur la planète.

Par contre, la notion de stéréotype est ici pertinente. Il possible de dire, s’il s’agit de ce qui est observé

le plus souvent dans la réalité, que s’il y a interpellation, il y a généralement une réaction de

collaboration.

En bref, compte tenu de certains éléments connus à l’origine, il est possible, par analogie, de définir un

cas probable qui, pour notre problématique, devient un stéréotype associé à une probabilité.

Nous aurons donc un moteur d’inférence basé sur la notion de stéréotype. De plus, les stéréotypes

seront basés sur l’utilisation des probabilités d’apparition.



21. Modélisation des moteurs d’inférence

La modélisation des moteurs d’inférence n’est pas présentée de manière complète. Elle illustre

l’utilisation de la notion de distance et des probabilités. Comme illustration, nous allons aborder trois

fonctionnalités que doit remplir notre moteur, soit :

• La sélection d’un stéréotype

• La génération de scénarii

• Interpréter une requête en langage structuré

Mais il est important de commencer par le commencement, soit par la méthode d’assimilation, puisque

sans une assimilation correcte, une sélection et une agrégation seraient impossibles.

Notons également que la modélisation est également limitée, toujours dans un but illustratif, à

l’enchaînement d’actions uniquement définies par le prédicat. Le principe d’utilisation des probabilités et

de distances reste identique pour les autres éléments de notre langage.

21.1. L’assimilation

21.1.1. Rappels sur les probabilités

Précédemment nous avons défini l’assimilation comme le résultat de l’utilisation des probabilités. En

faisant appel aux principes de base de l’utilisation des probabilités, principalement à la notion de « OU »

et à la notion de « ET » et à leurs significations dans la théorie des ensembles (intersection et union),

nous nous souvenons que le « OU » entraîne l’addition des probabilités associées et le « ET » entraîne

la multiplication des probabilités.

A titre d’exemple, si dans un sac se trouvent dix boules de couleurs différentes, trois rouges, trois

bleues, deux blanches et deux noires, et que nous pratiquons un tirage avec remise, la probabilité de

tirer une boule blanche est, à chaque tirage, de 1/5, alors que la probabilité de tirer une boule rouge est

de 3/10.

La probabilité, avec un tirage, de tirer une boule blanche OU une rouge est de 1/2. Nous constatons

que ce chiffre peut être obtenu en additionnant 1/5 et 3/10.

La probabilité, avec deux tirages, de tirer une boule blanche ET une rouge est de 3/50. Nous constatons

que ce chiffre peut être obtenu en multipliant 1/5 et 3/10.

La probabilité, avec deux tirages, de tirer deux boules blanches est de 1/25. Nous constatons que ce



chiffre peut être obtenu en multipliant 1/5 et 1/5.

21.1.2. L’assimilation et probabilités

L’élément essentiel est l’élément unitaire. Notre moteur d’inférence doit donc assimiler les actions en

passant par les probabilités associées à chacune d’elles. A partir de là, il sera possible de calculer la

probabilité d’un enchaînement. A titre d’exemple, voici un tableau de trois actions avec leurs fréquences

d’apparitions et leurs probabilités associées :

Actions Fréquences d’apparition Probabilités

Surveiller 4 2/5

Voler 4 2/5

Interpeller 2 1/5

Figure 22 : Tableau de probabilité no 1

L’insertion de deux enchaînements supplémentaires, comprenant les trois actions (surveiller, voler et

interpeller), va entraîner une modification des fréquences d’apparition, donc des probabilités :

Actions Fréquences d’apparition Probabilités

Surveiller 6 3/8

Voler 6 3/8

Interpeller 4 2/8


On peut voir dans le tableau suivant l’impact de cette assimilation en observant la modification de la

probabilité totale d’un enchaînement passé « Surveiller, Voler, Interpeller » :

Actions Probabilités Probabilités

Situation initiale Situation finale

Surveiller 2/5 3/8

Voler 2/5 3/8

Interpeller 1/5 2/8

Total 0.032 0.035


L’assimilation signifie donc l’insertion d’un nouveau cas, puis une mise à jour des probabilités associées à



chaque action puis enfin une mise à jour des probabilités de chaque cas déjà inséré.

21.2. La sélection d’un stéréotype

La sélection d’un stéréotype se base également sur les probabilités, mais en intégrant une notion

supplémentaire, celle de distance. En se référant à l’assimilation, le travail repose sur l’analyse des

enchaînements.

L’idée est qu’en proposant un enchaînement d’actions, le moteur d’inférence recherche le cas le plus

probable comportant cet enchaînement. Deux cas de figure peuvent apparaître : soit l’enchaînement

existe dans la base de données, soit l’enchaînement n’existe pas. Parallèlement à cela, deux options sont

possibles : soit l’ordre d’apparition des actions dans l’enchaînement compte, soit il ne compte pas.

Nous n’illustrerons ici que l’option où l’ordre compte, cette option étant la plus complète et surtout la

plus logique dans notre problématique.

21.2.1. Si l’enchaînement existe

Lorsque l’enchaînement existe dans la base de données, l’idée est de trouver le cas le plus probable

comprenant cet enchaînement. Prenons par exemple une base de données comportant six cas différents,

combinant dix actions différentes (voir la figure 25) :

• Enchaînement no 1 : actions 1, 2, 4 et 7






Imaginons que nous recherchons l’enchaînement comprenant les actions no 1, 2 et 4, ce qui correspond

aux cas no 1 et 2 (les enchaînements dans lesquels se retrouvent les actions).

Hors, grâce à l’assimilation, nous avons pu définir une probabilité pour chaque action (voir la figure 26),

ce qui nous permet d’associer une probabilité à chaque cas (voir la figure 27). Cette association nous

permet de donner un rang à chaque cas. Ici notre problématique est la recherche d’un cas existant, les

cas no 1 et 2. La figure 27 permet de choisir entre les deux, soit ici celui qui à la probabilité (ou le rang)

la plus élevée, soit le cas no 1. Lorsque nous avons une recherche donnant comme résultat deux cas

ayant la même probabilité, soit le moteur travaille sur la proximité à partir des cas sélectionnés, dans



l’idée de ne proposer qu’un seul résultat, soit le moteur présente tous les résultats possibles.

Figure 25 : Six combinaisons de dix actions

Figure 26 : Calcul des probabilités

Action no 1

Action no 3Action no 2

Action no 6Action no 4 Action no 5Action no 5

Action no 9Action no 8Action no 5Action no 7 Action no 10

No d'action Fréquence Probabilité1 6 0.260869572 2 0.086956523 2 0.086956524 3 0.130434785 5 0.21739136 1 0.043478267 1 0.043478268 1 0.043478269 1 0.0434782610 1 0.04347826

Total 23 1



Figure 27 : choix des cas

L’intégration de la notion d’ordre est ici très simple à effectuer. En effet il suffit d’associer à chaque

action de l’enchaînement recherché un numéro d’ordre, et de ne sélectionner que les cas où

l’enchaînement correspond à ces numéros d’ordre, en travaillant sur la notion de plus grand ou plus

petit. Ceci est d’autant plus facile qu’au moment de la saisie des informations, l’ordre d’enchaînement

des actions est intégré dans la structure et devient donc disponible.

A titre d’exemple, en recherchant par exemple l’enchaînement des actions no 2 et 1, dans l’ordre, nous

n’avons aucun résultat disponible.

21.2.2. Si l’enchaînement n’existe pas

Lorsque l’enchaînement n’existe pas dans la base de données, l’idée de base est de trouver le cas dont

la probabilité est la plus élevée et dont la proximité avec l’enchaînement donné est la plus haute. La

méthode est décomposée en trois étapes :

• Recherche des cas comportant le maximum des actions de l’enchaînement recherché

• Recherche du cas le plus probable

• Recherche du cas dont la proximité avec l’enchaînement recherché est la plus élevée

A titre d’exemple (en continuant à nous baser sur l’exemple précédent), si nous recherchons

l’enchaînement comportant les actions no 1, 8, 9 et 10, nous nous rendons compte, en nous basant sur

la figure 25, que cet enchaînement n’existe pas. Par contre, une première recherche permet de

sélectionner les cas no 3, 4 et 5, selon la figure suivante :

No d'action/cas 1 2 3 4 5 61 0.26086957 0.26086957 0.26086957 0.26086957 0.26086957 0.2608695652 0.08695652 0.08695652 0.08695652 0.08695652 1 13 1 1 1 1 0.08695652 0.0869565224 0.13043478 0.13043478 1 1 1 15 1 0.2173913 0.2173913 0.2173913 0.2173913 16 1 1 1 1 1 0.0434782617 0.04347826 1 1 1 1 18 1 1 0.04347826 1 1 19 1 1 1 0.04347826 1 1

10 1 1 1 1 0.04347826 0.043478261Total 0.00012864 0.00064322 0.00021441 0.00021441 0.00021441 4.28815E-05Rang 4 3 2 2 2 1



Figure 28 : Concordance

Cette figure nous permet de voir la concordance entre l’enchaînement recherché et les cas de la base.

Lorsqu’une action existe dans un cas, 1 point est accordé. La concordance est la somme des points.

La concordance la plus élevée est 2 et correspond aux cas no 3, 4, et 5. Cependant, les trois cas ayant

la même probabilité, il est possible d’affiner notre recherche, en travaillant sur la notion de proximité.

Cette notion se rapproche de celle de la moyenne. Etant donné un ensemble d’éléments, quel est celui

qui est le plus proche de la masse formée par cet ensemble. Pour ce faire, nous comparons un cas

donné avec tous les autres cas successivement. Lorsqu’une action se trouve dans les deux cas, un point

est accordé. Par exemple, si le cas donné est le cas no 3, nous constatons qu’il possède deux actions en

commun avec le cas no 1 et trois actions en commun avec le cas no 2. La somme des points donne la

proximité. La figure suivante donne la proximité des trois cas retenus avec tous les autres :

Figure 29 : Proximité

On constate qu’il est possible d’éliminer le cas no 5 et de ne retenir que les cas no 3 et 4. Ici le moteur

choisira entre les deux cas restant selon un critère arbitraire, par exemple le plus récent. Ici aussi,

l’intégration de la notion d’ordre est simple à effectuer. Il suffit, dans l’attribution des points de

concordance, de n’accorder un point que si l’action analyser vient bien après la précédente, selon

l’ordre donné par l’enchaînement cherché.

21.3. La génération de scénarii

La génération de scénarii repose sur une hypothèse qui est la suivante :

No d'action/cas 1 2 3 4 5 61 1 1 1 1 1 12 0 0 0 0 0 03 0 0 0 0 0 04 0 0 0 0 0 05 0 0 0 0 0 06 0 0 0 0 0 07 0 0 0 0 0 08 0 0 1 0 0 09 0 0 0 1 0 0

10 0 0 0 0 1 0Concordance 1 1 2 2 2 1Probabilité 0.00012864 0.00064322 0.00021441 0.00021441 0.00021441 4.28815E-05

No cas 1 2 3 4 5 6 Proximité3 2 3 4 3 2 1 154 2 3 3 4 2 1 155 1 2 2 2 4 3 14



Les probabilités associées aux cas suivent une distribution normale.

Ceci permet donc d’utiliser les probabilités associées et la loi normale pour générer un scénario. Le

principe est le suivant, décomposé en trois étapes :

• Génération par le moteur d’un nombre aléatoire suivant une distribution normale.

• Multiplication de ce nombre par la probabilité maximum associée à un cas.

• Choix du cas ayant la probabilité la plus proche du produit précédent.

A titre d’exemple, en prenant comme référence les chiffres de la figure 28, voyons ce qui se passerait en

générant un nombre aléatoire égal à 0.56.

En multipliant ce nombre par la probabilité maximum associée à un cas, soit 0.00012864, nous obtenons

0.000072016. La probabilité associée la plus proche est alors de 0.0000428815, soit le cas no 6.

Puisqu’un nombre aléatoire est toujours compris entre 1 et 0, nous avons, en multipliant ce nombre à la

probabilité maximum associée à un cas, une borne supérieure (le cas ayant la plus forte probabilité) et

une borne inférieure (le zéro). Tous les cas sont donc couverts.

Cette approche permet de travailler sur des cas en copiant leur fréquence d’apparition dans la réalité.

Mais elle peut-être étendue dans une vue action-réaction, reproduisant la structure de notre langage. En

effet, il est possible d’attribuer un rôle à une personne en formation, par exemple le rôle de l’interpellant,

et d’attribuer un rôle différent au moteur. Lorsque la personne choisit une action, le moteur choisit une

réaction de manière aléatoire, selon le même principe. A cette réaction, la personne choisit une action en

réponse. Le moteur peut analyser alors, selon les méthodes décrites dans le chapitre concernant le test

de comportement, quelles sont les implications de cet enchaînement.

21.4. Interpréter une requête en langage structuré

L’interprétation d’une requête en langage structuré repose sur le langage développé dans ce travail.

Nous avons développé un langage avec sa propre morphologie et grammaire. Ce sont ces règles qui

représentent la structure de la requête.

Le but de la requête est ici la recherche précise d’un cas.

La requête s’appuiera donc sur la figure 13, où l’utilisateur définira une donnée associée à un élément de

structure. L’ordre d’enchaînement des propositions sera défini par l’ordre de saisie.

Outre cette recherche basée sur le langage défini précédemment, la recherche peut naturellement porter

sur l’ensemble des objets et attributs définis dans les chapitres précédents. A chaque attribut, l’utilisateur



pourra définir une valeur de référence, éventuellement un ordre de grandeur (plus grand et plus petit),

valeur sur laquelle portera la recherche.

Naturellement, la transcription entre les valeurs de recherche définies par l’utilisateur et le langage SQL

devra être automatique et non visible.

Outre la définition de valeur, l’utilisateur devra pouvoir donner des indications de sélection, notamment

deux fonctions primordiales, le OU et le ET.

En résumé, l’utilisateur doit pouvoir faire une recherche répondant à trois questions :

• Quoi ? (Quel objet ou quelle valeur)

• Comment ? (Et/Ou)

• Quand ? (Sous quelles conditions )

La structure du langage est reprise de la figure 13 dans le but de conjuguer saisie et recherche et permet

d’introduire un élément supplémentaire dans la recherche : la notion d’ordre.

Naturellement, deux approches sont possibles dès l’instant où les paramètres de recherche sont définis :

• La sélection d’un cas précis, en indiquant l’absence de cas si les paramètres ne sont pas

absolument respectés

• La sélection d’un cas précis, puis la sélection du cas le plus probable en cas d’inexistence, ce

qui revient à générer un stéréotype.

L’utilisateur doit donc avoir le choix entre les deux options.



Partie VI – Le prototype

22. Choix des outils de développement

Le choix des outils de développement du prototype repose sur deux piliers principaux :

• L’aspect pratique et la disponibilité de l’outil

• Le souci de l’utilisateur, soit l’emploi d’un outil qu’il connaît

Dans notre cas, cinq outils principaux sont utilisés, d’une part en termes de modélisation du prototype,

d’autre part en termes d’implémentation du modèle. Ces outils sont les suivants :

• Le modèle Entité-Association : permet une première modélisation de la base de données

• Le modèle relationnel : permet une modélisation de l’implantation de la base de données

• DB-main : outil logiciel permettant les deux modélisations précédentes

• MS-Access : outil logiciel permettant l’implantation des modèles précédents

• VBA : langage de programmation associé à MS-Access [Callahan 00]

L’utilisation de DB-main s’explique par sa disponibilité, sa gratuité et son efficacité. L’utilisation de MS-

Access s’explique par le fait que l’entreprise utilise déjà ce logiciel, notamment au service de sécurité.

MS-Access utilise VBA comme langage de programmation, ce qui explique ce choix du langage, qui est

d’ailleurs plus une contrainte qu’un choix.



23. Limites du développement

Comme pour de nombreux éléments de ce travail, le temps est une contrainte essentielle. Il est

impossible de développer notre prototype avec autant d’ouverture qu’il faudrait. L’objectif est ici de

montrer un potentiel, de montrer une petite partie de ce qu’il est possible de faire. Un autre objectif est

de faire le lien entre tout ce qui a été dit précédemment et la réalisation d’une implantation concrète. En

effet, l’intérêt est pour nous de passer d’une problématique théorique, avec la création d’un langage

d’expression des connaissances, la définition de classes et d’objet, puis de passer à un modèle

relationnel et une application effective.

24. Fonctionnalités de l’application

Les fonctionnalités de notre prototype sont le résultat d’un choix arbitraire. Il serait bien sûr possible

d’effectuer autant de fonctionnalités qu’il existe de besoins. Nous en retenons deux :

• La saisie d’un cas • La recherche selon un langage structuré, avec la recherche d’un cas précis

Ces deux fonctionnalités sont naturellement complétées par les utilitaires du système, principalement :

• L’intégration des procédures • L’intégration du langage défini

De plus, la saisie d’un cas peut entraîner des fonctions de mise à jour de la base données. Deux fonctions de mise à jour sont réalisées à titre illustratif :

• L’insertion d’une nouvelle personne • L’insertion d’une description de personne, lorsque celle-ci est inconnue

Les fonctions de programmation en VBA ne sont pas ici détaillées ni définies, l’objectif n’étant pas pour nous de

présenter ou de concevoir une structure d’application informatique. Cependant, il est évident que le prototype

nécessite un travail de programmation, autant au niveau de la gestion de l’interface qu’au niveau du

fonctionnement du système. D’ailleurs, ajoutons à ce propos que la gestion de l’interface repose implicitement sur

certaines procédures. Par exemple, lorsqu’une personne commet un délit et que sa fuite empêche une

identification, il est nécessaire d’en faire une description. La gestion de l’interface prend en compte cette règle.

Les règles de procédure définies précédemment restent valables, mais l’interface devient elle-même un objet.



25. Modélisation Entité-Association et relationnelle

La réalisation du prototype passe par la modélisation en schéma E-A de la problématique générale

décrite dans les pages précédentes puis dans la transformation de ce schéma en un schéma relationnel.

Pour ce faire nous allons naturellement nous baser sur toutes les réflexions précédentes.

25.1. Le schéma Entité-Association

Nous pouvons définir douze entités différentes :

• Le cas : le cas de vol

• La proposition : la proposition unitaire de notre langage

• Le processus : les principales étapes d’un cas de vol (surveillance, interpellation, vol et

traitement)

• La personne : tout individu intervenant dans un cas

• Les inanimés : tout substantif n’étant pas une personne

• Les types de complément : les types définis lors de l’élaboration de notre langage

• Les procédures : l’ensemble des procédures

• Les verbes : les verbes qui serviront de prédicat

• Les messages : indication lorsqu’une procédure n’est pas obligatoire

• Les terminaisons : définition de la fin d’un cas



• Magasin : magasin dans lequel se déroule le cas

• Place_Lieu : l’endroit du magasin où se déroule le cas

Nous constatons que pour des raisons pratiques, nous avons détaillé ce que nous appelions les

substantifs dans la définition de notre langage, notamment en faisant la distinction entre les substantifs

inanimés, les personnes et les lieux. D’autre part, les lieux ont été eux-même subdivisés en magasins et

place. Les substantifs inanimés comprennent donc aussi bien des mots comme « pain » que des états,

« pauvreté » par exemple.

En outre, toujours pour des raisons pratiques, certaines entités ont été crées pour offrir à un attribut une

valeur dont le choix est limité à une liste. Il en est ainsi pour les entités « terminaison », « Table » et

« Attributs ».

Ceci étant dit, le schéma E-A résultant est celui-ci :

Figure 30 : Schéma Entité-Association

Les entités présentées le sont avec des attributs dont la liste n’est pas exhaustive. Nous nous sommes

bornés à présenter pour chaque entité l’identifiant et un attribut.

Il en va de même pour le schéma relationnel qui en découle.

1-1

1-N

Termine

0-N

1-N

Regroupe

1-11-N Possède

1-1

0-N

Prendplace

1-1

0-1

Génère

0-N

0-N

Est sujet 1-1

0-N

Est predicat de

0-N

0-N

0-6

0-N

Est complement

1-10-NEnglobe

1-1

0-N

Défini

0-N

1-1

Connaît

VerbeNumVVerbeid: NumV

TypecomplémentsNumtypeTypeid: Numtype

TerminaisonNumTTerminaison

PropositionsNumpropNumeralid: Numprop

ProcessusNumprocessProcessusid: Numprocess

ProceduresNumProcObjet1id: NumProc

Place_LieuNumPlacePlaceid: NumPlace

PersonnesNumPNomid: NumP

MessagesNumMMessageid: NumM

MagasinNumMagMagasinid: NumMag

InanimésNuminaDesignationPrixid: Numina

AttributsNumAttNomAttid: NumAtt

TableNumtableNomTid: Numtable

CasnumCDateid: numC



25.2. Le schéma relationnel

Le schéma relationnel découlant du schéma E-A est le suivant :



Figure 31 : Schéma relationnel

Nous dénombrons quinze tables au complet pour faire fonctionner notre application. Outre les douze

tables découlant des entités définies, nous voyons l’apparition de trois tables supplémentaires, provenant

des associations définies précédemment, soit :

• Est complément : lie un objet inanimé, une personne, une proposition et un type de complément.

Cette association de quatre éléments nous donne un complément de notre langage. En effet, un

complément possède un certain type, concerne une proposition, et peut être soit un objet

inanimé soit une personne.

• Regroupe : lie un cas et les propositions

• Est sujet : Lie une personne et une proposition. Cette association de deux éléments donne le

sujet de notre langage. En effet, un sujet est une personne et est lié à une proposition.

Reste maintenant à implémenter ces tables.

26. Implémentation des moteurs d’inférences

L’implémentation du moteur d’inférence passe par le calcul des probabilités associées à chaque action,

NVP =

VerbeNumVVerbeid: NumV

acc

TypecomplémentsNumtypeTypeid: Numtype

acc

TerminaisonnumCNumTTerminaisonid: numC

equ acc

RegroupenumCNumpropid: numC

Numpropacc

equ: Numpropacc

ref: numCacc

PropositionsNumpropNumeralNumPlaceNumVNumprocessNumProcid: Numprop

acc ref: NumPlace

acc ref: NumV

acc ref: Numprocess

acc ref: NumProc

acc

ProcessusNumprocessProcessusid: Numprocess

acc ProceduresNumProcObjet1id: NumProc

acc

Place_LieuNumPlacePlaceid: NumPlace

acc

PersonnesNumPNomid: NumP

acc

MessagesNumMNumProcMessageid: NumM

acc id': NumProc

ref acc

MagasinNumMagMagasinid: NumMag

acc

InanimésNuminaDesignationPrixid: Numina

acc

Est sujet NumPNumpropid: Numprop

NumPacc

ref: Numpropacc

ref: NumPacc

Est complement NuminaNumPNumpropNumtypeid: Numtype

NumPNumpropNuminaacc

ref: Numtypeacc

ref: Numpropacc

ref: NumPacc

ref: Numinaacc

AttributsNumAttNomAttNumtableid: NumAtt

acc equ: Numtable

acc

TableNumtableNomTid: Numtable

acc

CasnumCDateNumMagid: numC

acc ref: NumMag

acc



ici à chaque verbe. Pour cela, il suffit de compter le nombre de propositions, puisque dans chaque

proposition il y a un prédicat défini par un verbe. Puis ce nombre, nommé NTP, devient le dénominateur

d’une fraction dont le numérateur est le nombre d’apparitions totales de chaque verbe, nombre nommé

NV. En conséquence, cette probabilité est, pour chaque verbe, calculée de la manière suivante :

A partir de ce résultat, nous pouvons, pour chaque cas, remplacer chaque proposition par la probabilité

associée à son prédicat et faire le produit de ces probabilités. Ceci nous donne la probabilité associée à

chaque cas.

L’utilisation des requêtes dans MS-Access permet une implémentation simplifiée de cette règle, mais

l’utilisation d’un algorithme codé reste nécessaire. Concernant la notion de proximité, cette approche

n’est pas implémentée puisque qu’elle n’est pas nécessaire dans les fonctionnalités choisies pour le

prototype. Cependant, une recherche basée sur cette notion ne poserait pas de problème particulier.

Encore une fois, l’utilisation de requêtes successives dans MS-Access simplifie le problème, même si le

codage en SQL n’est pas très complexe. Le principe de base est d’accorder 1 point lorsqu’il y a

correspondance, aucun point dans le cas contraire. Il suffit alors de choisir le cas où le nombre de point

est le plus grand. La notion d’ordre est une simple condition supplémentaire pour accorder un point

dans la correspondance

Avec C un cas, PT un point, V la valeur d’un attribut d’un cas, Vr la valeur d’un attribut recherchée et i

un indice lié au cas, nous avons alors deux formules successives :

Naturellement, il est possible d’additionner divers attributs de recherche. Pour chaque attribut

recherché, il faudrait alors calculer PT et en faire la somme, ce qui nous donnerait un PTtotal. Ce dernier

remplacerai PT dans la deuxième formule.

27. Définition de l’interface

0Pelse1PthenVrVifPT ====

( )∑= iPTMAXChoix



L’interface est naturellement un élément essentiel. Dans notre cas, l’aspect, le design, la présentation ne

sont cependant pas abordés et ne correspondent pas à un besoin important dans la création du

prototype. Cependant, une des règles appliquées est de faire correspondre l’interface, lorsque ceci est

nécessaire, aux formulaires utilisés dans l’entreprise. Nous allons donc nous intéresser uniquement à

l’organisation de l’interface, basée sur l’utilisation des formulaires de MS-Access. Le schéma suivant

donne la structure de l’interface :

Figure 32 : Structure de l’interface

Le rôle de chaque interface est le suivant :

Saisiecas

Type deRech.

Détail

Proposi-tions

PersonneDescrip-tions

Recherchecas

Recherchesur action

Resultatsur cas

Cas probable

Entrée

Adminis-trateur

Interface

Saisiecas

Type deRech.

Détail

Proposi-tions

PersonneDescrip-tions

Recherchecas

Recherchesur action

Resultatsur cas

Cas probable

Entrée

Adminis-trateur

Interface



• Entrée : interface de départ permettant un choix d’activité • Saisie cas : interface de saisie d’un cas • Administrateur : interface administrateur avec accès codé • Propositions : interface de saisie des enchaînements • Description : interface de saisie lorsqu’un voleur a pris la fuite • Personne : interface de saisie d’une nouvelle personne • Type de recherche : interface de choix d’une recherche sur cas ou sur action • Recherche cas : interface de saisie des paramètres de recherche du cas • Recherche sur action : interface de saisie des paramètres de recherche sur une action • Résultat sur cas : interface de présentation des résultats de recherche sur cas • Cas probable : interface de présentation du cas le plus probable, selon l’action prédéfinie • Détail : détail des enchaînements lié au cas le plus probable, suite à la recherche sur action

27.1. Entrée Cette interface est la suivante :

Figure 33 : Interface d’entrée L’utilisateur peut choisir entre les fonctions réservées à l’administrateur, quitter l’application ou saisir un nouveau cas.



27.2. Administrateur L’interface « Administrateur » est la suivante :

Figure 34 : Interface Administrateur

Cette interface permet un accès direct à la base de données (structure, code, etc.) et d’effectuer une recherche. La fonctionnalité de recherche est mise dans cette interface uniquement pour illustrer la possibilité de coder l’accès à certaines fonctions, donc de les réserver à des types d’utilisateurs prédéfinis.

27.3. Saisie cas L’interface de saisie des cas est la suivante :

Figure 35 : Interface de saisie des cas

Cette interface permet de saisir les données relatives au cas qui se présente. Le bouton « Valider » lance la procédure de saisie des propositions.



27.4. Propositions L’interface permettant la saisie des propositions, donc des enchaînements d’actions, est la suivante :

Figure 36 : Interface propositions Cette interface varie également en fonction des actes de l’utilisateur. Elle permet de saisir une proposition en respectant la structure du langage définit dans le paragraphe correspondant. La validation entraîne en arrière plan, à l’aide du code VBA, une mise à jour complète des tables.



27.5. Description L’interface permettant de décrire une personne inconnue est la suivante :

Figure 37 : interface description Cette interface reprend exactement le formulaire utilisé dans l’entreprise. Elle permet, lorsqu’une personne prend la fuite par exemple, d’en donner une description la plus détaillée possible, en offrant à la personne saisissant les données un aide mémoire visuel. De plus, elle suit également, implicitement, une procédure qui est de donner une description lorsqu’une personne ne peut pas être identifiée.



27.6. Personne L’interface permettant la saisie de nouvelles personnes est la suivante :

Figure 38 : interface personne

Cette interface reprend exactement le formulaire utilisé dans l’entreprise. Elle est utilisée lorsque l’interface proposition est ouverte. En effet, au moment de saisir le sujet par exemple, il est possible que la personne en question ne soit pas dans la base de données. Il est possible alors de saisir une nouvelle personne. Une fois cette interface fermée, l’interface « proposition » est actualisée.

27.7. Type de recherche L’interface permettant le choix des types de recherches est le suivant :

Figure 39 : interface type de recherche

Le choix offre deux possibilités : la recherche d’un cas suivant des paramètres liés à ce cas et la recherche du cas le plus probable étant donnée une suite d’actions.



27.8. Recherche cas L’interface de recherche de cas est la suivante :

Figure 40 : interface recherche de cas

Nous constatons que cette interface est la copie conforme de l’interface « Saisie cas ». Cette équivalence permet de maintenir une cohérence indispensable dans le design des interfaces. Il est possible ici des saisir un ou plusieurs paramètres de recherche. Ajouter une ligne entraîne la fonction d’agrégation « OU ».

27.9. Recherche sur action L’interface de recherche sur action est le suivant :

Figure 41 : interface recherche sur action

L’interface est ici présentée avec toutes ces fonctionnalités. Celles-ci peuvent varier suivant les manipulations de l’utilisateur. Par exemple, lors de la première saisie, seul les boutons « valider » et « Quitter » sont visibles. Les



deux autres boutons nécessitent la saisie d’au moins un paramètre. Il va sans dire que la recherche sur un seul élément, l’action, est minimaliste. Cependant c’est une bonne illustration des développements possibles. Une telle approche peut en effet être utilisée pour toutes les données relatives aux enchaînements de propositions.

27.10. Résultat sur cas L’interface de résultat sur cas est le suivant :

Figure 42 : interface résultat sur cas

Nous retrouvons encore une fois la copie conforme de l’interface « Saisie cas ». Seule la source de données cachée derrière change.



27.11. Cas le plus probable L’interface du cas le plus probable est le suivant :

Cette interface donne le cas le plus probable répondant au(x) paramètre(s) d’action(s) donné(s). Ceci permet d’avoir une information préventive sur la base d’un enchaînement. En cliquant sur le bouton « Voir les propositions », nous arrivons à l’interface « Détail »



.

27.12. Détail L’interface Détail est la suivante :

Cette interface présente tous les enchaînements de propositions liés au cas. Dans la partie supérieure, nous retrouvons le processus auquel appartient la proposition et le lieu de déroulement, ainsi que les trois premiers éléments de notre langage. La partie inférieure (ici vide) présente la totalité des compléments, en donnant le substantif et le type de complément auquel il appartient.

27.13. Remarques Naturellement, l’interface devrait être davantage développée. Par exemple, la recherche d’action devrait englober l’action et également tous ses composants. De plus, la totalité des tables devraient pouvoir être mise à jour directement depuis une interface prévue à cet effet. En outre, la même interface peut prendre successivement des formes différentes. Par exemple, les éléments affichés sur l’interface de saisie peuvent varier au cours de la saisie. Ajoutons également l’utilisation des boites de messages au cours des étapes successives. Ces boites de messages ne sont pas indiquées ici car elles sont générées par du code. Précisons pour terminer que la figure 32 présente les formulaires MS-Access utilisés successivement, chacun d’eux étant en soi une interface pour un objectif donné et partie de l’ensemble que représente l’interface dans son sens général.



Partie VII – Conclusion

28. Critiques et difficultés

Les difficultés lors de la rédaction de ce mémoire furent nombreuses. Principalement le manque de

temps n’a pas permis une exploration totale de toutes les possibilités. Plus d’une fois, il fut nécessaire de

se limiter à des illustrations ou des présentations partielles. D’autre part, certaines contraintes matérielles

ont empêché l’utilisation d’outils peut-être plus polyvalents.

Le temps, outre sa responsabilité dans une exploration seulement partielle, a un impact également dans

la réalisation du prototype. Le choix de réaliser deux fonctionnalités seulement, la saisie et la recherche,

mais également une recherche limitée, est dû à cette contrainte. L’objectif est alors de favoriser l’élément

illustratif, au détriment de l’élément qualitatif d’un point de vue technique. La recherche d’un cas

correspondant exactement aux paramètres de recherche évite un travail de programmation, travail qui

peut être réalisé en manipulant les requêtes et en limitant la difficulté à l’intégration de formules

algébriques. La programmation est alors limitée à la gestion de l’interface, ce qui, bien sûr, peut être

réalisé dans un délai raisonnable. Notons toutefois que ce travail de programmation englobe également

un autre élément essentiel, la mise à jour. Si la mise à jour d’une table source est facilitée par l’utilisation

d’un formulaire, il en va autrement lorsqu’une table fait office de jointure. Dans ce cas, le code est

apparu comme un avantage. De plus, l’implémentation du moteur d’inférence ne peut que passer par

une utilisation intensive du code. Ceci explique que le moteur d’inférence implémenté dans le prototype

est resté très sommaire.

Une autre difficulté fut de trouver un moyen de modélisation de la problématique. L’idée de base étant

de modéliser la rencontre de deux ou plusieurs comportements, la première étape fut de penser à un

processus de stimulus-réponse, qui déboucha sur le principe action-réaction, reflétant le constat que

dans le traitement d’un cas de vol, chacun réagit en fonction de l’autre. D’où l’idée de l’enchaînement

d’actions. La deuxième étape, tout aussi problématique, était de trouver un moyen d’exprimer une

action, et de l’exprimer de la manière la plus complète possible. Or il existe un modèle connu de tous

pour exprimer une action, modèle parfaitement structuré depuis des siècles : la langue. D’où l’idée de



reproduire la structure de la langue (la réflexion s’est basée sur le latin, dont la structure est la plus

complète des langues occidentales). L’aide et les conseils d’un linguiste s’est alors révélé nécessaire. La

distinction entre la structure et la sémantique fut parfois problématique, mais la conclusion de la réflexion

est que l’interprétation sémantique est laissée à l’utilisateur.

29. Proposition d’améliorations

De nombreuses améliorations sont bien sûr possibles. Premièrement, en ce qui concerne l’expression

d’une action, nous avons supprimé par exemple les adverbes, les adjectifs, les compléments de mode,

etc.. avec comme justification une interprétation relative. En effet, comment interpréter des mots tel que

« rapidement », « violemment », voire des adjectifs comme « bleu », « grand » ou encore des

expressions comme « avec force » ? En effet, « rapidement » peut avoir un sens différent selon la

situation ou la personne qui l’utilise. « Grand » pose le même problème. Lorsqu’on mesure 165 cm, on

est grand pour celui qui mesure 130 cm, petit pour celui qui mesure 180 cm. La problématique est ici

l’interprétation des nuances, comme pour les couleurs. En prenant par exemple du bleu et en ajoutant

progressivement un pourcentage de jaune, nous allons finir par atteindre la couleur verte. Mais la

frontière entre les deux couleurs n’est pas clairement définie. Cependant il est possible de résoudre ce

problème à l’aide de la logique floue. La logique floue permet justement de résoudre ce genre de

problème, car elle permet d’appréhender l’imprécision et la subjectivité [Godjevac 99]. Je suis

persuadé (à priori) que l’intégration, au niveau du moteur d’inférence, d’un processus de fuzzification18

et d’un processus de defuzzification19, permettrait de modéliser la structure complète (ou d’une grande

partie) de la langue, peut-être avec quelques aménagements, notamment lorsque deux formes

permettent l’expression d’une seule et même chose (par exemple les pronoms peuvent être remplacés

par des substantifs ; une seule forme peut être alors imposée).

En élargissant la réflexion concernant les problèmes d’expression, nous nous rendons compte,

notamment vu les difficultés liées à la programmation, qu’une notion supplémentaire devrait être ajoutée à

notre langage : la notion de champ lexical20. Une liste de substantifs comme nous trouvons

principalement dans le prototype et également dans la structure du langage, en terme de concept et en

terme de source, est utilisable tel quel sans difficultés techniques, mais il semble évident que l’utilisation

de champs lexicaux permettrait une amélioration sensible d’une part de la compréhension générale du

système, d’autre part de l’efficacité du travail de programmation. En effet, l’utilisation de champs

18 Transformation des entrées précises en degrés d’appartenance 19 Transformation des résultats flous en sorties précises 20 Ensemble structuré d’unités lexicales. Par exemple, la couleur est un champ lexical regroupant bleu, vert, rouge, etc.



lexicaux offre un critère supplémentaire de tri, un ciblage plus précis des termes en fonction des besoins

de saisie ou de recherche et un travail qui peut être basé sur des ensembles et non plus des valeurs.

Une autre amélioration évidente est la séparation entre l’interface et la base de données. Une base de

données sur un serveur avec une application au niveau des postes clients permettrait une mise en

commun plus aisée et plus efficace du système complet. L’élaboration des requêtes et certaines

opérations de calcul serait alors à la charge du poste client, permettant ainsi le soulagement du serveur

central.

En liaison avec ceci, une autre amélioration possible serait d’utiliser une approche objet, autant pour la

création de la base de donnée que pour l’interface. L’utilisation de l’approche objet sur les deux

éléments permettrait la conjugaison de la base de donnée avec les fonctionnalités de programmation

d’un logiciel comme JAVA par exemple. Rappelons en outre que JAVA permet la création et la

gestion de base de données sous forme de matrice au format texte. Ce genre d’approche, avec l’idée

de séparer la base de données de l’interface permettrait d’utiliser Internet comme support réseau.

Une autre amélioration évidente est bien sûr l’interface. Rudimentaire ici dans la création du prototype,

l’interface devrait naturellement coller aux habitudes des utilisateurs et également simplifier le travail de

saisie et de recherche.

Ajoutons également une notion qui n’a pas été traitée, soit la notion d’oubli. En effet, il est essentiel de

reprendre la base de données régulièrement afin de l’épurer. Par exemple, nous pouvons nous

demander si des données vieilles de plusieurs années sont non seulement d’actualité, mais aussi

apportent une information ou une connaissance marginale suffisante. Si la réponse est non, il est

important de définir un âge limite des données et de procéder à leur élimination.

De plus, la gestion de la base nécessite un modérateur. En effet, le principe développé ici est que

l’intervenant effectue lui-même la saisie. Or la langue connaît des synonymes. Il serait donc souhaitable

d’avoir un modérateur qui contrôle régulièrement les éléments saisis, notamment en cas de mise à jour

(ajout de nouveaux verbes, etc), afin d’éviter d’avoir deux valeurs différentes pour une même

signification sémantique. La sémantique est un problème qui reste ici à la charge de l’utilisateur.

Pour terminer, notons qu’une formation préalable à l’utilisation du système ainsi que la mise en place

d’incitations semble essentielle. En effet, comprendre l’application et son maniement assure une

utilisation efficace. D’autre part, les incitations poussent l’utilisateur à faire preuve de rigueur et de

précision au moment de la saisie principalement. Notre système est basé sur une relation action-

réaction. Sa précision et son intérêt sont proportionnels au niveau de détail choisi pour décrire une



action. Il est important que celui qui effectue la saisie prenne le temps de chercher à chaque fois l’action

unitaire la plus petite possible. Or cette recherche peut prendre parfois du temps, temps que l’utilisateur

souhaite peut-être minimiser. Ajoutons également que certaines résistances peuvent apparaître, celui

possédant l’expérience ne souhaitant pas forcément la partager, cette expérience pouvant lui assurer une

sorte de « monopole » au sein de l’entreprise.

En bref, les principales améliorations (ou les principaux développements) envisageables sont :

• Utilisation de la logique floue

• Elargissement des catégories morphologiques

• Utilisation des champs lexicaux

• Séparation de l’interface et de la base de données

• Utiliser la programmation objet

• Créer la conjugaison entre l’interface et l’utilisateur

• Implémenter la notion d’oubli à l’aide de procédures d’épurement

• Intégrer un modérateur dans le fonctionnement général du système

• Intégrer un système d’incitations poussant l’utilisateur à un maximum de détail et de méticulosité

dans la saisie

Nous voyons que les améliorations sont nombreuses et touchent des domaines variés, autant en terme

d’outil, d’approche, d’interface ou de gestion.



30. Conclusion générale

Ce mémoire fut extrêmement intéressant et stimulant sur l’aspect de la réflexion. Les discussions avec le

responsable de la sécurité chez COOP Vaud Chablais valaisan, avec des intervenants et la visualisation

de cas réel de vol ont permis d’avoir une bonne vue d’ensemble des problèmes de vol en particulier, de

sécurité en général. L’approche linguistique à également permis de développer des connaissances dans

ce domaine et a montré les possibilités liant informatique et langage. Dans le même temps, le sentiment

d’une frustration est réel lorsqu’on compare le travail réalisé et le travail réalisable. En effet, le sujet

devient vite passionnant et la contrainte du temps, qui oblige à limiter non seulement l’exploration dans le

raisonnement mais également la mise en œuvre des fonctionnalités au niveau du prototype, devient vite

pesante.

Il serait intéressant de développer l’approche en intégrant la logique floue et en développant non

seulement l’approche linguistique, mais également en élargissant la problématique à l’ensemble des

problèmes de sécurité. De plus, il serait passionnant de développer la totalité des fonctionnalités utiles au

niveau du prototype, voire de réaliser une application opérationnelle. Ceci supposerait cependant le

cumul de diverses compétences, notamment en termes de linguistique, en termes de sécurité, en termes

de modélisation et bien sûr en termes de programmation.

Ceci dit, il semble évident que les possibilités offertes par les systèmes à base de connaissances, en tous

cas dans le domaine de la sécurité, voire dans la gestion des comportements (en effet, la modélisation

action-réaction pourrait s’appliquer à d’autres domaines, comme le déroulement d’une vente par

exemple) sont extrêmement larges.

Pour terminer sur une note personnelle, je dirais que ce travail m’a non seulement permis de

comprendre de manière plus approfondie les buts et le développement des systèmes à base de

connaissance, mais également éveillé un intérêt très vif pour la logique floue, élément qui n’a

malheureusement pas pu être intégré faute de temps.

31. Remerciements

Je remercie tout particulièrement le professeur A.R Probst, pour son soutien et son enthousiasme

communicatif. Je remercie également M. Giller, responsable de la sécurité chez COOP Vaud Chablais



valaisan pour sa disponibilité et les informations remises, ainsi que tous ses collaborateurs m’ayant

accordé du temps et ayant répondu à mes nombreuses questions. Je remercie également Mlle

Gradinaru, linguiste, pour ses conseils et son apport de compétences.

32. Bibliographie et références

[Kettani 98] Nasser Kettani, Dominique Mignet, Pascal Paré, Camille Rosenthal-Sabroux

« De Merise à UML », Eyrolles, 1998.

[Godjevac 99] Jelena Godjevac « Idées nettes sur la logique floue », Presses polytechniques et

universitaires romandes, 1999.

[Muller 97] P.A Muller « Modélisation objet avec UML », Eyrolles, 1997

[HBR 00] Harvard Business Revue « le Knowledge management », Editions d’Organisation,

2000.

[Dieng 00] Rose Dieng, Olivier Corby, Alain Giboin, Joanna Golebioska, Nada Matta,

Myriam Ribière, « Méthodes et outils pour la gestion des connaissances », Dunod,

2000.

[Callahan 99] Evan Callahan, « Microsoft Access2000, Visual Basic Edition Applications, étape

par étape », Microsoft Press.



Partie VIII – Annexes

• Exemples d’instructions et procédures :

o Vol à l’étalage de clients

o Agression, menace, chantage, attentat, enlèvement

• Formulaires internes :

o Déclaration de vol à l’étalage

o Fiche signalétique

• Graphiques et chiffres concernant le vol du personnel

o 1996-1997

o 1997-1998

o 1998-1999

Documents

Sécurité des biens dans une entreprise de grande ... · Sécurité des biens dans une entreprise de grande distribution : ... Cadre de travail Dans le chapitre concernant la définition