31 mars 2022 Hors série Outils

Découvrir ODASE, partie II : intégrer les ontologies dans le SI

ODASE est un logiciel permettant de formaliser la réalité du métier, de façon à constituer un référentiel exploitable par une multitude d’applicatifs.

La semaine dernière, nous accueillions Rémi Le Brouster pour nous parler de cette solution, de ses objectifs et du changement de paradigme que cela entraîne pour la définition des règles métier.

Nous nous retrouvons cette semaine pour échanger sur l’intégration de cette solution dans le quotidien des acteurs techniques.

H : Comment les équipes techniques utilisent la représentation du métier définie par ODASE ?

RLB : Avec l’équipe informatique côté client, on définit en parallèle comment ils souhaitent interroger l’outil. On peut par exemple déterminer un ensemble de services pour interroger ODASE, auquel cas on établit alors un contrat d’API. Nous nous occupons alors de réaliser la partie technique qui va proposer les services, transmettre les informations à l’outil, demander le résultat, et le retourner. Ainsi, ni le client, ni le serveur n’ont à connaître le fonctionnement métier.

Afin de décorréler encore plus le technique du métier, et exploiter encore plus l’explicabilité fournie par l’outil ODASE, l’API n’a pas nécessairement besoin de se baser sur la modélisation métier. Nous réalisons alors une ontologie d’intégration, qui fait la conversion entre les concepts métiers et les concepts techniques. Cette correspondance est donc parfaitement compréhensible et documentée, et il n’y a donc pas besoin d’aller investiguer du code pour comprendre le mapping. La passerelle entre le métier et le technique est donc une simple affaire de traduction, très localisée et lisible, et cette indépendance entre le métier et le technique permet de pouvoir avancer sur les deux aspects de façon indépendante.

H : Comment les développeurs accueillent la solution ODASE ? Le fait qu’il y ait besoin de s’interfacer avec un outil tiers complique-t-il leur travail ?

RLB : Les développeurs n’étant pas une entité unique, je suppose que leur accueil de la solution doit varier. Par exemple, je sais qu’en tant que développeur, j’adore me creuser la tête sur des problématiques métiers, définir le périmètre précis et les cas limites, et trouver des algorithmes efficaces, ce que rend obsolète ODASE sur la partie métier, le périmètre et les cas limites étant modélisés en amont, et les résultats étant calculés par l’outil.

A ma connaissance, la plupart des développeurs préfèrent s’occuper de la partie technique, ce qu’ils ont encore plus le loisir de faire grâce à notre outil. Cela leur évite également les frustrations de devoir gérer des spécifications métiers qui ne sont pas toujours limpides, ou de se rendre compte trop tard de la divergence entre la réalité métier et ce qu’ils en avaient compris, ce qui invalide parfois toute leur implémentation.

Concernant le fait de s’interfacer avec ODASE, c’est aussi simple que de s’interfacer avec n’importe quelle autre API ou JAR (selon le choix technique qui a été fait), ce à quoi les développeurs sont généralement habitués. ODASE a donc plus tendance à leur simplifier le travail et à leur éviter des frustrations que l’inverse.

H : Certains développeurs aiment particulièrement apprendre des choses sur le métier, pour comprendre pourquoi ils font ce qu’ils font et donner du sens à leurs efforts. En séparant les règles métier de l’implémentation technique, y a-t-il un risque de frustrer les développeurs qui ont ce type d’appétence ?

RLB : Bien que cela soit possible, s’ils aiment autant s’occuper de problématiques métiers que moi, je pense qu’il reste important pour les développeurs de se familiariser avec le métier, même dans une approche ODASE, ne serait-ce que pour comprendre comment seront utilisées leurs applications. Ainsi, même si on les libère d’une partie de la gestion de ce métier, on ne saurait que trop les encourager à s’y intéresser tout de même (et encourager leurs employeurs à leur y octroyer du temps !). Idéalement, ils pourront alors s’appuyer sur la modélisation ontologique pour approfondir leurs connaissances métiers, afin de proposer et délivrer des applications et fonctionnalités plus pertinentes.

H : La solution ODASE, quand elle est mise en place, semble devenir le point névralgique d’un système d’information… Le SI devient-il « captif » de cette solution ? Les équipes de vos clients deviennent-elles autonomes, ou bien faut-il faire appel aux ontologues d’ODASE pour chaque ajout de règle métier ?

RLB : Dans une approche idéale où le client embrasse intégralement l’approche ODASE, notre solution devient en effet le point névralgique du système d’information, et je pense qu’il est essentiel de comprendre pourquoi, afin de saisir aussi en quoi cela peut aussi être émancipateur, notamment si le client veut changer totalement d’approche plus tard, et refondre son système d’information tout en revenant à une approche classique.

Tout d’abord, je tiens à rappeler que le système d’information ne se limite pas simplement à de l’applicatif, mais inclut aussi l’ensemble des échanges entre les acteurs et leur accès aux informations et documentations.

Dans une approche classique, la définition du métier est morcelée. Elle se trouve dans les connaissances et souvenirs des différents acteurs, dans des brouillons papiers, dans des mails, dans des outils de ticketing, dans des documents à destination du métier, des développeurs, du support ou des utilisateurs, dans le code aussi bien en langage informatique qu’en commentaires, etc. Il devient alors difficile d’interroger ces connaissances, et de savoir quelle source est fiable pour quel aspect. Car une spécification peut être obsolète ou décrire un changement qui n’a pas encore été implémenté, et même un expert avec une excellente connaissance métier peut se tromper, surtout face à des spécifications changeantes; l’interprétation du code par un humain peut passer à côté de certains cas particuliers, et le code lui-même est rarement une source unique, avec de multiples applications intégrant différentes règles, et comme nous venons de le voir, ces règles varient selon la source qui a été choisie en amont.

Dans l’approche ODASE, l’essentiel de notre travail est d’agréger toutes les connaissances de l’ensemble du domaine à modéliser, et de clarifier ce qu’est la vérité métier. A partir de là, nous construisons l’ontologie métier qui servira de référence. L’entreprise obtient ainsi un point unique qui définit toutes les règles de façon parfaitement indépendantes, et qui est interrogeable directement, que ce soit pour valider cette définition métier (plus besoin de tester extensivement le métier dans chaque application, et de devoir comparer les résultats !) ou pour vérifier ce qu’on obtient, d’un point de vue métier, dans telle ou telle situation. Cela signifie aussi que quelqu’un ayant une question métier peut la confronter à une source fiable. Cette source est réellement un point unique en ce que l’ensemble des applications peuvent se baser dessus, car elle ne décrit pas des règles métiers pour une application ou un ensemble d’applications, mais bien les règles métiers de l’ensemble du domaine. Ainsi, même pour une nouvelle application ayant besoin de nouveaux services afin d’interroger certains éléments intermédiaires, il suffit de rajouter techniquement de nouveaux services dans l’interface programmatique d’ODASE, autrement dit de nouveaux points d’entrée ou de nouvelles façons de l’interroger, mais sans toucher aucunement à la partie métier. De même, si c’est la partie métier qui change, sans que cela n’impacte les éléments nécessaires et donc la partie technique, il suffit de modifier les règles métiers, puis de déployer la nouvelle version sur les différentes plateformes intégrant ODASE.

Cette solution a donc ceci d’émancipateur que :

  • si le client veut remplacer une application faite il y a 15 ans en développant une version plus au goût du jour, il n’a pas besoin de recoder la partie métier, ni de développer de nouveaux algorithmes car le métier est approché d’une nouvelle façon (par exemple, avec l’ordre des questions qui change) ; il peut se concentrer purement sur la partie technique
  • si le client veut refondre totalement son système d’information et se séparer d’ODASE, pour déléguer l’ensemble de sa gestion à un gros ERP par exemple, le fait d’avoir défini clairement le métier en un point unique et fiable fera que son travail sera grandement facilité, et qu’il y gagnera en coûts, en qualité et en délais.

Pour ce qui est de la modification lorsque l’approche ODASE est en place, passer par nous est tout à fait possible et encouragé, notamment pour garantir la qualité de la représentation ontologique. Toutefois, il est également possible pour le client d’avoir son ou sa propre ontologue qui réaliserait tout ou partie des modifications (on pourrait par exemple former quelqu’un chez le client à cette fin).

Pour ce qui est des modifications classiques (par exemple les prix qui évoluent d’une année sur l’autre), on peut avoir ces éléments stockés dans des sources externes (fichiers Excel, base de données, autre), que le client pourra aisément mettre à jour, afin qu’il n’y ait qu’à relancer les instances du serveur ODASE pour que tout soit pris en compte (dans le cas d’une utilisation en mode serveur).

Enfin, nous sommes actuellement en train de développer un outil pour rendre les ontologies plus accessibles, aussi bien pour les visualiser que pour les modifier.

Il me semble que l’important, comme dans tout domaine, est de faire réaliser les modifications par des personnes dont l’expertise est adaptée à la complexité de la modification à apporter. Et nous visons à permettre que ces personnes puissent être côté client, afin justement d’offrir de l’autonomie et de la maîtrise, aussi bien en faisant progresser l’expertise côté client qu’en simplifiant la réalisation de modifications.

H : Est-il possible d’intégrer ODASE au sein d’un SI ayant une forte proportion de legacy, ou est-ce plutôt une solution à privilégier sur des SI naissants ou du moins récents ?

RLB : Il est évidemment toujours plus confortable de travailler sur des bases neuves ou saines, plutôt que de devoir investiguer l’ancien. Toutefois, ODASE a principalement été utilisé dans des contextes de refonte du legacy de grosses structures, pour lesquelles les approchent classiques avaient déjà échouées plusieurs fois. En effet, l’approche ontologique permet de s’abstraire au fur et à mesure de la nébuleuse qu’est souvent la structure legacy, tout en testant ensuite le fait d’obtenir les mêmes résultats. De plus, là où dans les approches classiques, un petit détail peut invalider toute la structure de l’implémentation, ou forcer des contournements qui s’accumulent rapidement et rendent l’ensemble instable ou non-maintenable, dans l’approche ontologique, il est juste question de rajouter un concept, quelques attributs ou modifier / créer quelques règles supplémentaires. Autrement dit, c’est aussi simple que de mettre à jour de la documentation métier, mais sans avoir à s’encombrer de formulations complexes ni de phrases à rallonge.

H : Quelle est la plus grande réussite d’ODASE à ce jour ?

RLB : ODASE est actuellement utilisé dans le milieu de l’assurance, ce qui est gage de la fiabilité de l’outil et de l’intérêt de l’approche. C’est une très belle référence pour nous, et notamment de notre capacité à modéliser avec précision des ensembles métiers particulièrement complexes. 

H : Comment ODASE vise à se développer dans les années à venir ?

RLB : Nous sommes en train de créer notre propre outil qui permettra de visualiser et d’éditer les ontologies. L’objectif est que l’ensemble devienne plus simple, intuitif, pratique et confortable d’utilisation. Les étapes clefs sont :

  • la visualisation de l’ontologie (concepts et règles), en permettant de construire et enregistrer des vues qui affichent seulement les concepts qui leurs sont pertinents,
  • l’édition simple d’attributs ou de règles, pour permettre au métier de gagner de l’autonomie sur ces aspects,
  • l’ajout de règles,
  • puis de rajouter progressivement différents outils qui sont pratiques ou nécessaires pour les ontologues.
Etat actuel de l’outil de visualisation des ontologies.
Tout cela se fera évidemment en prenant en compte les retours des utilisateurs et utilisatrices, et avec pour objectif d’avoir avant tout un outil simple pour le métier, et ensuite seulement un outil pratique pour les ontologues, ce qui passera vraisemblablement par le fait de conditionner l’affichage de certains éléments à des options.

Merci à Rémi Le Brouster pour cette présentation détaillée du fonctionnement d’ODASE !

Un avis ? Un commentaire ?

Cet espace est pour vous.

Votre adresse e-mail ne sera pas publiée.