Introduction à la notion d’intégration du système d’information

Le système d’information des entreprises devient de plus en plus complexe au regard des nombreuses activités à couvrir et de la prépondérance de l’informatique pour assurer ces missions. Cela se traduit par un nombre croissant d’applications à gérer (progiciels, outils transverses, référentiels « techniques ») et un risque important de verticalisation si la question de l’intégration de ces différentes briques n’est pas traitée. La verticalisation signifie que les applications co-existent sans lien entre celles-ci et donc n’échangent ni données ni documents.

Les risques de la verticalisation

Quelles sont les risques de la verticalisation du système d’information ? Nous pouvons notamment citer :

• Des tâches à faible valeur ajoutée pour l’utilisateur comme la re-saisie ou la nécessité de faire des imports/exports pour faire le lien entre les logiciels,
• Une difficulté à maintenir un ensemble cohérent,
• La difficulté à mettre en œuvre une approche « qualité » de la donnée,
• La difficulté à obtenir une standardisation de l’activité ou de la tâche dans le cas d’une approche par processus.

Logiques d’intégration

Deux logiques s’affrontent sur ces questions d’intégration :

• Opter pour une logique à court-terme afin de répondre rapidement aux besoins énoncés par les directions métiers. Cela se traduit par exemple par le déploiement rapide d’un progiciel ou d’un outil qui n’est pas forcément intégré avec le reste du système d’information,
• Opter pour une logique à long-terme qui vise à réfléchir sur comment intégrer ces applications entre elles et mettre en place une approche urbanisée.

Un système d’information est dit « urbanisé » lorsque la problématique d’intégration et de cohérence d’ensemble au niveau fonctionnel a été traitée. Cela permet d’apporter de l’agilité au système d’information et de répondre presque « sur-mesure » aux besoins exprimés au sein de l’entreprise.

Comment intégrer les applications ?

Plusieurs leviers existent pour intégrer les différentes applications :

• L’acquisition et le déploiement d’un connecteur existant proposé par l’éditeur ou l’intégrateur. Ces connecteurs concernent les applications les plus fréquemment rencontrés sur le marché,
• Le développement spécifique d’un connecteur s’il n’existe pas nativement ou si celui-ci ne répond pas aux besoins,
• La mise en œuvre d’un bus applicatif suivant une logique ESB (Enterprise Service Bus). Il s’agit d’un modèle technique visant à interconnecter les différentes applications entre elles via l’utilisation d’un bus applicatif (canal permettant de faire transiter voire modifier les données entre les différentes applications). Ce type de projet fait appel à des compétences spécifiques (Exemples : l’analyste en charge du référentiel des processus et l’urbaniste en charge du déploiement technique de ce référentiel).

La logique d’intégration ESB est directement en lien avec l’architecture SOA (Architecture orientée services) et repose, sur la notion de « services » et « opérations ». Le langage BPMN est notamment utilisé pour formaliser de façon non équivoque le processus à implémenter. La définition de ces processus repose sur la rédaction de spécifications fonctionnelles et techniques des services et opérations à déployer. Ces spécifications mettent notamment en exergue les entrées et sorties attendues (données, format, évènements déclencheurs …), les cas d’usage à traiter, la gestion des erreurs ainsi que les outils sollicités durant l’appel du service.

Exemples de bus applicatifs open-source :

• Petals ESB,
• Talend Open-studio ESB,
• Fuse ESB.