L’interopérabilité des systèmes d’information

Je me trouvais voici quelques mois dans le bureau d’un directeur général dont l’entreprise s’associe à divers partenaires pour élaborer ses produits. J’ai prononcé le mot « interopérabilité ».

« Ah non, s’écria ce DG. L’interopérabilité, c’est beaucoup trop compliqué. »

Surpris, j’ai sursauté et, manquant à tous mes devoirs de consultant, me suis exclamé « mais alors votre système d’information est foutu ! ». La réunion s’est terminée vite et plutôt froidement.

Je vais dire ici ce que j’aurais dû expliquer calmement à ce DG.

*     *

Un partenariat associe deux entités différentes (entreprises ou directions d’une entreprise) dans l’élaboration d’un produit, c’est-à-dire dans l’enchaînement des tâches qui concourent à sa production.

L’entreprise qui organise une production doit définir les tâches élémentaires, la façon dont elles se succèdent, les données et les documents qui permettront de les exécuter. On appelle cela « modéliser un processus ». Ce n’est pas facile mais l’état de l’art des systèmes d’information fournit des règles, méthodes et instruments informatiques dont l’utilisation habile est efficace.

Quand le flux du processus traverse la frontière entre deux entités qui collaborent à son exécution, on dit que le processus est « transverse » : c’est alors que se pose le problème de l’interopérabilité.

*     *

Chacune de ces entités a en effet son langage, ses concepts, sa façon de voir le monde, de nommer les êtres qui le peuplent, de définir ses priorités, bref ses habitudes et sa culture.

Il en résulte que l’une nommera « chien » ce que l’autre nomme « chat » : je connais ainsi une entreprise où chaque usine a construit à sa façon le catalogue des outils, produits et pièces détachées, de sorte qu’il faudrait un dictionnaire pour traduire un vocabulaire dans l’autre. Lors des réunions beaucoup de temps est consacré, parfois en vain, à lever des malentendus et corriger des contresens.

Chaque entité a par ailleurs sa façon de découper le monde en « régions », la clientèle en « segments », les produits et salariés en « catégories », le temps en « périodes » et souvent ces classifications ne s’emboîtent pas exactement. C’est évidemment le cas si l’une raisonne en « mois » et l’autre en « semaines », il peut arriver que la liste des pays qui composent le marché nommé « Asie » ne soit pas la même de part et d’autre, etc.

Chaque entité identifie aussi à sa façon les êtres dont le système d’information contient l’image : un étudiant est ainsi identifié de façon différente par chacune des universités, écoles et bibliothèques qu’il fréquente. Les identifiants sont d'ailleurs souvent défectueux : ceux qui contiennent des attributs (département de résidence, qualification, etc.) sont modifiés quand un attribut change, certaines entreprises identifient non le client mais un service (RIB) ou un équipement (numéro de téléphone), sur l’Internet l’adresse de votre ordinateur portable change quand vous vous déplacez, etc.

Ajoutons que tout cela est évolutif : des classifications changent selon les priorités de la gestion et du marketing, de nouveaux produits sont introduits, de nouvelles qualifications, etc.

Il semble donc bien que mon DG ait eu raison : faire interopérer des systèmes d’information, « c’est beaucoup trop compliqué ».

Eh bien non, il a tort car on peut savoir s’y prendre et cela vaut la peine.

*     *

Les choses se simplifient en effet si l’on considère que les deux entités partagent un processus et non la totalité de leurs opérations. Il s’agit donc de faire en sorte que les données et documents qui accompagnent le flux du processus puissent traverser sans dommage la frontière entre les deux entités. L’attention doit se focaliser sur ces données-là, ces documents-là, et non sur l’ensemble des données et documents que comportent les deux systèmes d’information. Le problème reste certes difficile mais au moins il est délimité : il s’agit de placer sur le flux du processus, à l’endroit où il traverse la frontière, une interface qui réalisera les traductions nécessaires.

Si l’une des entités par exemple a coutume de travailler sur des « objets » (au sens de la programmation « orientée objet ») tandis que l’autre travaille sur des données, il faudra que l’interface sache d’un côté extraire les données que contient un objet, de l’autre reconstruire un objet autour des données.

La traduction ne pourra être qu’approximative quand deux classifications ne s’emboîtent pas. Si cette approximation est jugé intolérable, il faudra que l’un des partenaires accepte de faire un codage plus précis.

*     *

Il faut une collaboration des partenaires pour identifier les données et documents qui doivent traverser l’interface, programmer des traductions automatiques, organiser l’exécution « à la main » des codages supplémentaires, etc. Ce travail est une étape de l’« ingénierie d’affaires » qui définit les relations entre les partenaires, leurs devoirs réciproques, le partage des dépenses et recettes.

Si ce travail n’est pas réalisé le partenariat sera boiteux car le processus sera défectueux. Des dossiers mal identifiés seront perdus, des erreurs dans l’interprétation des données provoqueront des décisions malencontreuses, les délais seront allongés, etc.

La « complication » que l’on aura évitée en ne se souciant pas de l’interopérabilité des systèmes d’information se paiera au centuple par une autre « complication », celle d’un processus dont le désordre contraint les agents à faire et refaire le travail « à la main » devant des clients exaspérés par leurs erreurs et leur lenteur.

La réaction de mon DG n’est qu’une manifestation de l’ignorance si répandue envers les systèmes d’information. Il croit que pour mettre en place un partenariat il suffit de passer un contrat alors qu’il faut aussi un travail technique, comme toujours lorsqu’on organise un processus, et plus encore ici puisque le partenariat met en communication des mondes logiques et sémantiques différents.