Conception et construction de fédérations de progiciels

L’informatique au sein des organisations durant ces dernières années a été marquée par l’apparition de technologies nouvelles alors que s’exprimaient des besoins de plus en plus importants des utilisateurs.

L’arrivée de grands progiciels de gestion intégrée, dotés de nombreuses fonctionnalités qui supportent les besoins des utilisateurs et la diversité des fonctions des entreprises, constituent le cœur des systèmes d’information. Parallèlement, les applications logicielles peuvent désormais communiquer, coopérer, grâce à l’émergence de nouvelles technologies permettant par la même occasion de franchir les portes et les frontières des organisations.

Enfin, l’attrait pour Internet, passant du statut de simple média au rang de support « universel », et qui permet d’intégrer et d’offrir des services aux utilisateurs, d’avoir un rôle d’intégrateur d’applications…

La refonte des systèmes d’information des entreprises s’inscrit dans ce contexte, au milieu des paradoxes, des antagonismes, voire, des leurres technologiques. Deux tendances se dessinent cependant et s’affrontent [ICSSEA 2001]. La première est de choisir un éditeur et de s’y tenir. Un éditeur important, dont le comportement parfois hégémonique et duquel dépendent les clients peut parfois conduire à l’impasse ou à des situations de blocage. La seconde est de diversifier ses choix. Cette dernière s’accompagne généralement de contraintes techniques fortes. Mis dans le contexte des applications d’entreprises (notamment les Progiciels de Gestion Intégré – PGI), un éditeur unique semble avoir beaucoup de mal à couvrir l’ensemble des fonctions métiers des entreprises et propose des applications souvent moins bonnes que les éditeurs, spécialistes métiers, et que les applications développées en interne. D’autre part, sachant que certains spécialistes de la relation client ou de la chaîne logistique ont des solutions adaptées aux besoins, les utilisateurs poussent les éditeurs de PGI à s’ouvrir. C’est dans ce contexte, et dans le cadre des relations intra ou/et inter entreprises que se situe notre problématique. Disposant d’outils divers, les groupements d’entités (entreprises réseaux, entreprises virtuelles, etc. [Favrel 1998, AMA 1991, Sandoval 1995]) tentent de mettre en place des systèmes d’information transversaux à la fois entre les services et entre les entreprises ; le but étant de pouvoir interconnecter un ensemble d’applications, un ensemble de services afin de répondre aux attentes des utilisateurs et aux nouveaux modes d’organisation [Reix 1986, Morton 1991, Reix 1995, Morton 1995] tout en gardant une certaine flexibilité. En effet, ces inévitables rapprochements, partages, communications, ne doivent pas se faire au détriment de l’autonomie de chaque unités, de chaque utilisateur, de  chaque outil mis dans un certain contexte. Forts de ces constatations, plusieurs groupes de travail se sont constitués ayant pour objectif de proposer des spécifications, des standards, des normes que ce soient sur les échanges informatisés, les technologies pour le Web et les bus logiciels. Pourtant, si certaines de ces propositions semblent s’imposer (XML par exemple), d’autres rentrent en concurrence et tendent à se complexifier (CORBA et Java/RMI, EJB, CCM, .NET, etc.). De nombreux travaux se sont focalisés sur cette problématique : l’intégration d’outils. Cela part de la programmation classique où un programme est « découpé » en opérations, à la programmation orientée objet où on parle de classes, de paquetages à la prise en compte d’applications réparties. Différentes technologies ont été proposées pour mettre en synergie les applications et les utilisateurs [Fuggetta 1993, Totland et Conradi 1995] :
· les collecticiels,
· les outils de workflow,
· le génie logiciel,
· l’ingénierie des systèmes d’information,
· la modélisation d’entreprise,
· la conception des organisations,
· l’ingénierie concurrente,
· les Environnements de Génie Logiciel Centrés Processus.

Pourtant, peu de travaux ont mis l’accent sur l’assemblage d’applications hétérogènes et existantes, si ce n’est, ces dernières années, les approches dans le domaine de l’EAI (Enterprise Application Integration). Malgré tout et comme nous le verrons dans les chapitres suivants, ces technologies n’ont pas permis de couvrir l’étendue des besoins, pas plus qu’elles ne permettent de s’adapter aux changements.

L’idée de départ est de considérer que les applications logicielles de demain seront davantage des assemblages de composants logiciels déjà existants (prêts à l’emploi) aux seins des entreprises plutôt que de nouveaux produits issus de longs processus de développement. Nous partons du principe que la plupart des fonctionnalités requises existent déjà sous forme d’outils logiciels qu’il faut pouvoir intégrer.

Nous nous intéressons aux systèmes qui sont construits à partir de composants existants. Ces composants sont majoritairement de deux types :
· les composants disponibles sur le marché (appelés « COTS »),
· les composants disponibles et développés au sein des organisations (appelés
composants, applications ou systèmes « patrimoines »). Dans le premier cas, les composants sont autonomes puisqu’ils peuvent s’exécuter en dehors du contexte du système qu’ils intègrent. Ils disposent, pour la plupart, de ressources locales, d’un modèle de fonctionnement interne (décrit par le code du composant). Dans les deux cas, il est souvent intéressant d’adopter une approche de type « boîte noire » dans la mesure où :
· le code est indisponible pour les composants de type COTS ;
· le code est souvent difficile à maintenir, à faire évoluer pour les composants patrimoines. Ainsi, nous partons du principe selon lequel nous ne pouvons pas, en règle générale, modifier le comportement intrinsèque du composant. Ces composants sont donc :
· autonomes,
· hétérogènes,
· distribués sur un réseau et potentiellement sur plusieurs sites géographiquement éloignés.

L’objectif est de mettre ensemble des composants, des outils logiciels, pour permettre d’unifier les possibilités et les fonctionnalités des outils, et proposer un « tout » cohérent, aussi complet que possible au sein d’un système qui va permettre d’automatiser certaines tâches. La raison de la construction d’un tel système est de proposer aux utilisateurs une application (qui, par définition, propose un certain nombre de services), composée d’outils hétérogènes, dont le fonctionnement soit comparable (en termes de services rendus aux utilisateurs) à une application logicielle classique. Sachant que les outils logiciels doivent ensemble satisfaire les objectifs de l’application, ils forment ce que nous appelons une organisation (une communauté d’intérêts). Cette organisation sera régie par un mode (ou politique, ou stratégie…) de fonctionnement qui déterminera son comportement au cours du temps et donc, le comportement de chaque outil à l’intérieur de l’organisation. Ainsi, les organisations de composants qui nous intéressent ont deux caractéristiques importantes qu’il faudra étudier :
1. les artefacts partagés (tout ou partie) de l’application ;
2. le fonctionnement commun du système.

Les travaux de cette thèse ont eu lieu dans le cadre du projet ESPRIT IV LTR PIE (Process Instance Evolution). Les partenaires de ce projet sont l’Université Joseph Fourier (Adèle/LSR-IMAG), l’Université de Savoie (LLP/CESALP), le Centre de Recherche Européenne de Xerox, Dassault Système (France), The Victoria University of Manchester, Teamware Group Ltd (Royaume Uni), Universitaet Dortmund (Allemagne) et Politecnico di Milano (Italie). Le projet aborde le problème de l’évolution en-ligne des processus logiciels. L’évolution du processus est faite à travers un système de rétroaction, contenant des supports pour le monitoring, la prise de décision, le changement ainsi qu’un support pour la stratégie d’évolution [Cunin 2000, Alloui et al. 2000, Greenwood et al. 2000, Cîmpan 2000]. L’ensemble de ces outils, de ces systèmes forme ce que nous avons qualifié de fédérations d’outils dont le but (l’application) est l’évolution du processus sujet. Les travaux de cette thèse se placent dans la définition, la construction et la mise en oeuvre de la fédération d’outils [Estublier et Verjus 1999, Cugola et al. 2000b, Estublier et al. 2001a, Estublier et al. 2001b, Estublier et al. 2001c].