Comme le souligne Robert Reix (2002), l’interopérabilité est la capacité de différents systèmes informatiques à coopérer pour la réalisation en commun de traitement. L’interopérabilité tra- duit, de façon concrète, un certain degré de compatibilité entre les applications. Rendre pos- sible l’assemblage de composants (sous-systèmes) de différentes sources (tout ou partie de modules de plusieurs fournisseurs d’ERP, par exemple) implique d’intégrer la notion d’inter- opérabilité comme une exigence dès les premières étapes de la conception des dits composants. L’interopérabilité doit permettre de rendre les Systèmes d’Information plus efficients (Michel Schneider, 2001).
Il y a encore peu de temps, la construction de ce type d’architecture logicielle était d’un coût très élevé, dû à la nécessité de développer des passerelles pour rendre effective la compatibilité entre les applications. De plus, la pérennité de ce genre de passerelles suite aux mises à jour des applications ne pouvait être garantie du simple fait de l’absence de protocoles standard de communication, réduisant l’intérêt de ce type de pratique.
Différentes approches architecturales tendent à réduire cette lacune, en imposant ces nouveaux standards de communication. Nous pouvons citer le principe de l’urbanisation des systèmes (Gérard Jean, 2000), les concepts de l’EAI (Laurent Avignon et al., 2000) ou encore les services Web (Hubert Kadima, 2003).
La mise en œuvre de ces principes appelle des choix techniques dans le domaine de la commu- nication directe d’applications par les réseaux (middleware), en cela elles touchent les points de vue logique et physique. Mais quelle que soit la solution technique choisie, il est indispen- sable de disposer d’un modèle, cartographie des processus, décrivant les interactions entre les fonctions utilisées dans les différents modules déployés pour maîtriser l’architecture du sys- tème cible et synchroniser les échanges de différentes natures. Il faut donc insister sur le fait que ces modes basés sur une communication accrue entre des sous-systèmes distincts posent l’usage d’un modèle de représentation comme un prérequis à la conception, et pas comme un soutien éventuel.
68 CHAPITRE 5. ARCHITECTURE D’ERP
5.3.1 EAI
Le sigle EAI (Enterprise Application Integration) pourrait se traduire en français par Inté- gration des Applications d’Entreprise. Le but de l’EAI est d’instaurer une architecture basée sur des échanges entre des applications, principalement au sein d’une même entreprise. L’in- tégration d’application permet de faire dialoguer des systèmes, souvent hétérogènes, entre eux.
L’EAI doit remplir 4 fonctions :
1. interfacer : il doit être capable d’extraire et d’injecter des données dans une application. Il s’agit de la création, spécification et description de l’interface de l’application avec laquelle nous allons dialoguer ;
2. transformer : il doit être capable de convertir les données. Grâce à un moteur de trans- formation, il est possible de convertir des informations produites par une application en informations acceptées par une autre application. Cette fonction porte le nom de mapping en utilisant un format « pivot » ou « fédérateur » (XML) qui joue le rôle de traducteur ;
3. router : il doit être capable de transporter les données jusqu’au destinataire. Pour cela, on utilise (s’appuie sur) des protocoles du middleware (SOAP, CORBA, etc.) qui sont utilisés pour réaliser des communications synchrones ou asynchrones entre applications. 4. gérer : il doit pouvoir suivre l’état du processus. Lors de l’échange de données entre deux applications, un processus permet de valider les différentes étapes du transfert. C’est souvent un moteur de workflow qui assure cette fonction.
Les connecteurs de solution logicielle doivent permettre de réduire l’effort nécessaire d’intégra- tion de plusieurs solutions logicielles du Système d’Information. Les connecteurs fournissent deux types de services :
– la transformation des données aux formats manipulés par les solutions logicielles, – la relation aux interfaces spécifiques de type API (Application Program Interface) de la
solution logicielle.
Le contrôle des échanges utilise la notion de « trigger », c’est-à-dire la capacité de déclencher un programme sur l’apparition d’un événement interne particulier, sensibilisant un processus à un état donné.
5.3.2 Urbanisation des Systèmes d’Information
Le concept d’urbanisation d’un SI repose sur une volonté d’anticipation de l’évolution architec- turale : un découpage et des grands principes de construction qui permettront de faire évoluer le Système d’Information et l’informatique au même rythme que la stratégie et l’organisation de l’entreprise.
« Urbaniser son Système d’Information consiste à en dresser la cartographie de manière à le dessiner en termes de blocs fonctionnels et de flux - d’où le parallèle avec la ville, ses quartiers, ses artères, etc. But du jeu : rendre le Système d’In- formation assez flexible pour suivre les évolutions de la stratégie d’entreprise. » (Gérard Jean, 2000)
Les principaux concepts émanant de l’urbanisation du Système d’Information sont :
– de donner de la visibilité et de la souplesse à l’évolution du Système d’Information (principe de modularité),
– de mutualiser les grandes infrastructures (principe d’économie), – de garantir une cohérence d’ensemble (principe de cohérence),
– de répartir les responsabilités entre les différents niveaux d’acteurs de l’entreprise en favorisant la prise de décision au plus près du terrain (principe de subsidiarité).
Il s’agit principalement de fournir une nouvelle valeur au système. Il ne s’agit pas de refaire une implémentation, mais une extension du système existant. Il est souhaitable de réutiliser l’existant (le passé) s’il répond aux besoins des utilisateurs, les applications seront reliées par une plate-forme d’échange, idéalement l’EAI. L’évolution du système en alignement straté- gique avec l’organisation future amène son lot de réformes et impacte l’architecture. Pour ces évolutions, il est souhaitable d’utiliser une approche par composants. Et pour répondre aux exigences d’intégration, ces composants seront connectés à la plate-forme et devront dialoguer avec les anciennes applications (XML se taille la part du lion pour la structuration des mes- sages échangés). Il y a un souci de ne pas rompre avec le passé par des fractures technologiques portant sur la totalité du système, mais de rentrer dans une démarche d’amélioration continue en introduisant progressivement les nouvelles technologies.
5.3.3 Services WEB
Les services Web sont des composants logiciels encapsulant des fonctionnalités métiers de l’entreprise et distribués, c’est-à-dire accessibles via des protocoles standard du Web. Le service est donc mis à disposition sur un site pour utilisation depuis n’importe quelle plate-forme de développement.
D’un point de vue technologique, il s’agit d’offrir la possibilité d’interconnecter des applications via le Web. Ce sont des standards (XML, SOAP, WSDL, UDDI) qui permettent de décrire les interfaces de communication en essayant de masquer la complexité des technologies middleware (Corba, DCOM, Java/RMI).
Ce type de solutions se développe dans le cadre des applications pour les affaires du grand public (tourisme, transport, ...), il y a peu de développement orienté vers le monde de la gestion des entreprises pour l’instant.