Introduction

Difficile aujourd'hui d'imaginer une entreprise sans système d'information (SI). Données de gestion, comptables, clientes, produits, stocks, c'est même bien souvent plusieurs SI qui sont amenés à discuter entre eux.

Or, ces différents SI, bien que traitant de concepts communs, les représentent de manières très différentes. Cette problématique est exacerbée quand différentes entreprises ont besoin de communiquer entre elles à propos de mêmes objets, disons des billets de train.

Vous et moi avons une vague idée de ce qu'est un billet de train.

Un billet est lié à un trajet, comportant une gare de départ et une gare d'arrivée (voire plusieurs trajets successifs s'il y a des correspondances…).

C'est aussi une date de validité, des plages horaires de validité, voire même en cas de réservation, un train unique, avec son numéro, ses horaires (prévus ;-) ), peut-être un numéro de place, peut-être non.

Le billet est également attaché à une personne unique, à un abonnement, à une catégorie de personne (réductions).

Sans parler de tout ce qui gravite autour (facturation, conditions d'échange, etc.)

Donc, si jamais une agence de voyage tente de discuter avec plusieurs compagnies ferroviaires (vendeuses de billets) de pays différents, chacune utilisant une représentation adaptée à son contexte, on se doute que les SI vont avoir du mal à discuter entre eux.

On comprend aussi que ces différents acteurs parlent bien de choses similaires. Comment un modèle suffisamment générique pourrait-il alors permettre de leur faciliter les échanges ? Comment s'assurer que ce modèle soit construit avec le métier et compréhensible et validable par celui-ci ? C'est notamment en cela que consiste le cœur de métier d'Anabasis : concevoir et faire évoluer des modèles de représentation de la connaissance permettant l'interconnexion de SI ainsi qu'un traitement complexe et sémantique de la donnée. Voici les grandes lignes de cette démarche.

Lien avec les métiers

Le cas des billets de train effleuré plus haut semble connu de tout le monde, il n'en est pas de même pour des problématiques ultra spécifiques concernant un processus de fabrication avec ses machines complexes et ses multiples paramètres.

En règle générale, la connaissance du métier est détenue… par le métier, avec son vocabulaire, ses pratiques, sa logique, ses réglementations, ses contraintes et ses éventuelles interactions avec d'autres services ou métiers dont il dépend ou qu'il influence.

L'expertise métier, que ce soit des techniciens, des ingénieurs, ou des gestionnaires, est présente sous de multiples formes: dans de la documentation technique, fragmentée dans la mémoire de plusieurs experts, voire dans une sombre macro au fin fond d'un tableur rédigée par un ancien collaborateur et qui ne fonctionnera bientôt plus avec la nouvelle version de la suite bureautique.

Cette expertise se perd, si l'entreprise ne déploie pas de moyens colossaux, à l'échelle de sa complexité, pour la transmettre. Plus personne ne sait utiliser la macro du tableur. La connaissance, souvent empiriquement acquise, souvent implicite, se perd au lieu de se perfectionner.

Différents projets nécessitent le recueil de cette connaissance. Par exemple, la création d'un nouveau logiciel métier permettant d'automatiser ou de formaliser des processus passe par la consultation des experts. Cependant, les développeurs du logiciel ne sont pas les experts métiers. Afin de réduire les mauvaises surprises en fin de projet, les cycles courts sont mis en avant, notamment par les méthodes Agiles. Un défaut de ces méthodes est qu'elles nécessitent beaucoup de temps de la part des experts, car spécifier le fonctionnement d'un logiciel ne fait en général pas partie des compétences de ces derniers.

La modélisation de la connaissance métier permet de discuter avec les experts dans un langage avec lequel ils sont familiers, et ainsi de communiquer plus efficacement. Il suffit ainsi aux experts de valider ou amender les spécifications fonctionnelles. La formalisation de celles-ci n'est plus de leur ressort, elle est réalisée par les ingénieur·e·s de la connaissance.

Ingénierie de la connaissance

La formalisation du besoin métier par les ingénieur·e·s de la connaissance passe tout d'abord par une modélisation statique de l'univers métier. Cette modélisation, pourtant de haut-niveau et donc compréhensible par tout à chacun, a le grand avantage de pouvoir être directement exploitable informatiquement.

La modélisation repose ainsi sur un schéma global de l'univers métier : les éléments clés manipulés par les experts sont appelés des concepts, détaillés par des propriétés. Ces concepts sont reliés entre eux par des relations. Par exemple, le concept billet de train pourrait être relié à un concept compagnie de train par une relation est-émis-par. Ce schéma est exprimé grâce à un langage structuré de représentation de connaissances respectant les standards du web sémantique, dans notre cas OWL (https://en.wikipedia.org/wiki/Web\_Ontology\_Language).

La modélisation peut être poussée un cran plus loin et devenir dynamique grâce à l'écriture de règles logiques qui manipulent les éléments de l'univers métier modélisé, de la forme :

Si tel concept possède telle propriété ou relation alors nous pouvons en déduire telle nouvelle relation ou propriété.

Si le train du billet part après 22h et arrive le lendemain, alors c'est un train de nuit.

Si le tarif du billet n'est pas lié à un abonnement, alors un échange la veille du départ coûte 50 €.

Nous avons d'ailleurs développé notre propre langage à Anabasis, Kalamar, nous permettant à la fois de déclarer les concepts et les règles.

L'exécution de ces règles est rendue possible par l'instanciation des concepts et relations avec des données issues du métier et un moteur de raisonnement qui permet de résoudre toutes les "contraintes" spécifiée par ces règles. Les règles permettent ainsi de construire de nouvelles informations et ainsi d'enrichir la base de connaissances. Celle-ci est ainsi constituée de l'instanciation de la modélisation et l'ajout de toutes les déductions obtenues par l'exécution des règles. On peut finalement interroger directement cette base par l'intermédiaire d'un langage de requêtes, ou encore construire une interface graphique qui permet d'afficher des résultats choisis aux utilisateurs.

Le point essentiel est de faire en sorte que les informations calculées et restituées soient pertinentes au sens où elles adressent correctement et totalement les interrogations issues des besoins des experts métiers.

Pour cela, le travail du recueil des attentes est crucial, qu'il s'agisse de celles des experts ou des besoins du client, car précisons-le, les experts et les clients peuvent ne pas être les mêmes personnes, ne portant pas toujours la même vision sur la problématique à traiter. Le besoin client doit ainsi être saisi dans son environnement métier, dans son ensemble, à l'aide de documentations et d'experts.

Ce travail s'opère dans un contexte où il existe une fracture entre le monde des équipes IT, notamment extérieures, et le monde des équipes métier et client. Il n'existe pas de façon usuelle de lier ces deux équipes, et le décalage entre les attentes de l'une et la réalisation de l'autre est aujourd'hui l'un des problèmes majeurs du service informatique.

La volonté de l'ingénierie de la connaissance porte ainsi sur l'importance de formaliser correctement le besoin métier pour pallier à cette fracture. Il s'agit d'une tâche délicate, les experts eux-mêmes ne sachant pas toujours comment exprimer leurs attentes. Il est bien entendu difficile de traiter informatiquement et correctement quelque chose de mal exprimé, et très facile de traiter informatiquement quelque chose de formalisé... mais comment garantir que la formalisation proposée soit correcte ?

La démarche de l'ingénierie de la connaissance permet cela en plusieurs points.

Tout d'abord, l'interrogation continue des métiers dans leur propre vocabulaire permet de recueillir régulièrement des éléments, ensuite analysés et triés, qui s'affinent dans le temps. Pour cela, les questions posées doivent provoquer des réactions chez les experts afin de les pousser à s'exprimer sur des points a priori non évidents, dans un souci de détection d'éléments informels. Poser la question naïve dans l'objectif d'obtenir des « mais non, c'est ça qu'il faut faire à la place voyons » est un bon moyen de parvenir à ses fins ;)

Mais afin de pouvoir poser des questions pertinentes et qui visent juste, de brosser un tableau global du contexte métier et de ne pas abuser du temps des experts, un travail d'appropriation de la documentation technique ou légale du métier est nécessaire. La compréhension du besoin métier et des premières bases du contexte passe cependant par un temps incompressible d'étude du domaine, et avouons-le, de premières ébauches fort approximatives et foisonnantes de la modélisation. Une lecture approfondie de l'œuvre de Marie Kondō est alors fortement recommandée.

Ces deux aspects permettent au final de mettre en place une présentation continue de la modélisation (concepts et règles exécutées), et d'instaurer une boucle vertueuse restitution/interrogation/appropriation/construction.

Ce processus permet la création continue d'une modélisation dynamique, dite ontologique, qui grandit et se modifie petit à petit tout au long du projet jusqu'à se stabiliser à la fin. Bien entendu, un travail d'IHM de rendu de cette ontologie doit accompagner la démarche de l'ingénierie de la connaissance pour que le client puisse visualiser les résultats et, à terme, utiliser un produit qui lui corresponde.

Ces processus peuvent sembler lourds, mais ils ne devraient pas l'être. L'ingénieur·e de la connaissance opère avec discrétion, loin des ateliers classiques de recueil usuellement utilisés par d'autres métiers. La démarche vise à être non intrusive et optimiser le temps consacré par les clients et experts. Toute interaction a un objectif précis, de recueil ou de validation par des résultats concrets, obtenus par exécution de la modélisation, en temps très limité. C'est l'agilité, poussée à l'extrême, qui prime encore une fois.

Conclusion

En somme, l'ingénierie de la connaissance est un tout continu d'outils et de méthodes, exécuté en relation constante avec le client et ses experts métier, dans le respect des besoins, des contraintes et du temps limité des interlocuteurs, à visée de restitution et de traitement corrects des besoins du client.

Pour aller plus loin :

• OWL un langage pour décrire des ontologies.
• Protégé un éditeur OWL graphique permettant de concevoir des ontologies.
• SWRL un langage permettant d'écrire des règles travaillant sur une ontologie.

Sabrina et Fabien,

Ingénieurs de la connaissance