Memoire Online - Intégration et Généricité: Modèle ADROIT

Ce tableau montre que pratiquement tous les ERP libres ont été développé avec des langages libres tels que python, XML, java/J2EE et Php. Ils sont implémentés sur des serveurs d'applications libres tels que Zope, Tomcat, Jboss, Apache et utilisent des bases de données libres comme ZODB, Mysql, Postgresql.

Parmi les ERP étudiés ici, il n y a que Compière qui utilise Oracle comme serveur

d'application et comme SGBD. Ce cas a été critiqué parce que Oracle est propriétaire et donc si on utilisait Compière, on était obligé de acquérir Oracle. Cette situation est maintenant gérée avec l'utilisation de Jboss et de Postgresql.

Compiere s'adresse davantage aux secteurs financiers et de la distribution (un module orienté manufacturing devrait cependant voir le jour).

ERP5 s'adresse par contre davantage à l'industrie manufacturière, avec une réelle capacité à gérer des nomenclatures complexes de produits.

Tiny ERP s'adresse aux salles de vente tandis qu'Ofbiz s'adresse au secteur du commerce avec son orientation e-Commerce.

Pour ce qui est des fonctionnalités, on voit que chaque ERP a une spécialité avant de s'étendre dans les autres secteurs de l'entreprise.

ERP			ERP5		OFBIZ		TINYERP		COMPIERE	ADROIT
Principale fonctionnalité			Production		Commerce éléctronique		Salle de ventes		Financiers et Distribution	Financiers et Dossiers
Editeur	ERP/PGI	Langage		Exemple Serveur d'applications		Exemple BDD utilisée		Fonctionalités
Nexedi/ Coramy	ERP5	Python		Zope		ZODB ( Zope Object Database)		Gestion production, Gestion financière, CRM, Chaîne logistique, E-business, Groupeware
Nereide	Ofbiz	XML		J2EE(Tomcat)		MySql		Gestion clients, Gestion fournisseurs Gestion employés, Gestion des articles, Gestion des stocks, Gestion des commandes Gestion de projet, E-commerce
Audaxis	Compiere	Java/J2EE		Jboss, Oracle etc...		Oracle/PostgreSql MySql		Gestion des ventes, Gestion des catalogues, des tarifs, Suivi des commandes, Gestion des achats, des stocks, Gestion de la logistique Gestion de la comptabilité, des finances
Tiny	TinyErp	Python		Jboss		Postgresql		CRM, Gestion Stocks, Gestion de la comptabilité Gestion de projet, Gestion des ventes, des achats. Gestion de la production, Gestion Ressources humaines, Marketing

	ERP5	COMPIERE	OFBIZ	TINYERP	ADROIT
Couverture fonctionnelle	X	X	X	X	X
Base de données unique	X	X	X	X	X
Adaptation et paramétrage	X	X	X	X	X
Architecture informatique ouverte	X	X	X	X	X
Présence d'outils d'aide à la décision	X	X	X	X

MQ Series Integrator (Middleware asynchrone en mode message) : transforme, augmente, applique les règles de " message based data". Il transfert et distribue les données entre les différents systèmes.

C'est un outil qui permet l'intégration de nouvelles applications aux applications déjà existantes et cela même avec du contenu dynamique. Il permet de visualiser les flux des applications grâce au développement d'un environnement graphique.

E-biz Integrator : transforme automatiquement les bases de données dans n'importe quel format requis par le système informatique de l'entreprise. La technologie utilisée par e-biz Integrator assure le transfert des données critiques même si les programmes, réseaux ou SI sont en panne. E biz integrator permet l'intégration de n'importe quel environnement informatique quelque soit le matériel, l'OS, les logiciels, les bases de données et les protocoles de communications, utilisés.

Agha G.A. [I.37] définit ScalAgent comme un exemple de réalisation d'un Middleware qui fournit un modèle de programmation de composants applicatifs adapté à la communication asynchrone et inspiré du modèle d'acteurs.

Dans l'article « Configuration de Middleware dirigé par les applications - INRIA» Vivien Quema et Luc Bellissard [I.38] montrent que chaque composant applicatif de ScalAgent est créé et s'exécute au sein d'un représentant local du Middleware appelé serveur de composants. Celui-ci assure la création des composants, leur exécution et leurs communications. Il héberge une fabrique de composants et un bus local qui est composé de deux composants principaux. Chaque composant Middleware responsable d'une propriété non fonctionnelle possède un ensemble d'attributs qui lui permettent de fournir cette propriété.

L'environnement Calife permet la création de deux types d'automates [I.39]. Les automates simples, représentables sous la forme d'un graphe ; les automates composés par produit synchronisé d'automates. Par la suite, le terme automate désignera un automate simple et le terme block désignera un produit synchronisé d'automates (simples ou eux-mêmes crées par produit synchronisé). Le terme composant désignera indifféremment un block ou un automate simple.

L'entrepôt de données , baptisé Gedaw (Gene Expression DAta Warehouse), [I.40] intègre à ce jour les données expérimentales du groupe fer de l'Unité 522 (par l'intermédiaire de la création d'une base de données relationnelle Transcriptome) et intégrera à terme des données expérimentales d'autres équipes, des données pertinentes provenant de grandes banques publiques. Une fois intégrées, ces données vont être analysées à l'aide de requêtes et d'outils dédiés, développés localement et/ou importés des sites Web.

Dans les travaux sur « La modélisation d'un entrepôt de données dédié à l'analyse du transcriptome hépatique », Guérin, Moussani et autres [I.41] ont montré que le GEDAW (Gene Expression Data Warehouse) est un entrepôt de données orienté objet qui permet l'intégration de ces données et d'autre part fournit des outils pour leur analyse, afin de mettre en évidence des corrélations entre gènes étudiés.

Les apports d'une intégration des données sont une garantie de la cohérence des données dans les deux systèmes, l'évitement des redondances inutiles et la possibilité de manipuler les données de manière transparente à partir des différents systèmes.

La base de données unique d'un ERP permet les avantages immédiats suivants :

L'un des plus gros avantages des web services est qu'ils reposent sur des protocoles standardisés. Cela permet que cette technologie soit exploitable par de nombreux langages.

En effet, les web services se reposent sur les protocoles tels que XML et disposent en effet de fonctions pour lire un fichier XML ( Parseur XML). Donc un web service développé sous une plate forme .NET peut être utilisé via le langage Perl, PHP, Python, Delphi, Cobol .

Les web services sont la base de l'EAI. [I.42] contrairement à ce qu'on peut voir aujourd'hui, ils ne se limitent pas à la création de petits composants à destination du Web. C'est un véritable système de communication qui peut être utilisé pour l'intégration des applications.

Le principe fondamental de fonctionnement des web services [I.43] est de morceler les applications et les processus d'affaires en morceaux réutilisables appelés « Service » de sorte que chacun de ces segments effectue une tâche distincte. Ces services peuvent alors servir à l'intérieur et à l'extérieur de l'entreprise, facilitant l'interopérabilité entre tous ces services.

D'après Pierre Yves Fourmond [I.34] , les Middleware Orientés Message, outre les services d'acheminement (envoi, réception), de stockage, et de recherche des messages etc ..., offrent des services plus évolués tels que :

Un autre avantage des MOM est qu'ils sont insensibles (au moins temporairement) à l'indisponibilité des applications, en ce sens que dès qu'un message est envoyé au MOM ou reçu par l'applicatif, cet applicatif peut s'arrêter, puisque la connexion entre l'application et le MOM n'est requise que pendant l'échange du message.

L'EII présente pour principal avantage de simplifier le travail de développement et de maintenance des applicatifs nécessitant l'intervention de bases de données hétérogènes. Il facilite le déploiement d'applications nécessitant l'accès à diverses bases de données, notamment en rendant plus simple le travail d'élaboration et de maintenance des requêtes.

Dans les travaux sur la classification des documents XML, Mounir Fegas [I.21] donne quelques apports de XML qui sont : la possibilité de structurer des documents quelque soit leur complexité - l'extensibilité, en définissant toutes les balises dont on a besoin - la validation, permettant de vérifier la conformité de la syntaxe d'un document par rapport à la grammaire générale du langage XML.

Dans son article « La connectivité des logiciels doit s'appuyer sur des standard afin d'assurer l'interopérabilité des systèmes, Olivier Grenet [I.14] explique que XML présente certains avantages. Il est auto-descriptif car les balises décrivent la structure et le type des noms des données ; il est portable puisque codé en Unicode, et il peut décrire les données sous la forme d'un arbre ou d'un graphe.

La conception d'un datawarehouse débouche naturellement vers une approche multidimensionnelle, donc sur la mise en place de cube qui va plus loin, encore, dans l'analyse des données. Cela permet que les données restituées soient : normalisées, de meilleure qualité, homogènes.

C'est des systèmes très lourds, lents et coûteux à la mise en oeuvre. Il y a aussi une sensation de perte d'autonomie et de pouvoir due au partage des informations, au décloisonnement des fonctions de l'entreprise et aux réorganisations.

Dans le livre « Making ERP a success, communications of the ACM - vol. 43» Scheer August-Wilhelm et Habermann F. [I.44] disent que les ERP requièrent beaucoup de ressources notamment en espace mémoire, les besoins de réseautique, et en coûts de formation.

Pour la plupart, les outils de EAI ne possèdent pas de fonctionnalités de workflow qui permettent de prendre en compte les interactions avec les utilisateurs.

Un inconvénient majeur des web services aujourd'hui est l'absence de vraie sécurité dans les normes officielles.

Dans son article, Pierre-Yves Fourmond [I.34] explique que l'inconvénient que l'on peut trouver aux MOM est précisément de devoir installer et configurer un composant logiciel supplémentaire pour faire communiquer plusieurs applications. On critique ensuite les MOM pour leur manque de standards. Cette critique n'est pas recevable dans la mesure où la plupart des MOM actuels implémentent tous l'interface JMS, qui est le standard pour la communication en mode message en Java.

. Dans le cas de l'EII, les requêtes multi-sources consomment beaucoup de ressources et les temps de réponse s'en ressentent. En outre, l'EIIl ne dispose pas de fonctions pour transformer les données, il n'y a pas de fonctions de transformation et il y a peu de performances sur les requêtes complexes.

Malgré le fait que la solution EDI Edifact permette de structurer les segments et les messages qui couvrent les besoins des entreprises dans leur échanges, il n'est que peu utilisé cela principalement pour les raisons suivantes :

Dans l'article de Steven Song et Bellant [I.45], on peut voir la mise en évidence de l'une des faiblesses contre laquelle le langage XML ne fait rien au vocabulaire.

Olivier Grenet [I.14] cite Ronald Bourret qui énumère les faiblesses de XML: un stockage inefficace, les index, la sécurité, les transactions et l'intégrité des données, l'accès multi-utilisateur, les déclencheurs (triggers), les requêtes sur plusieurs documents, etc.

Les changements technologiques incluent le déploiement de tous les modules d'un ERP, et l'intégration de l'ERP avec les applications de l'entreprise. Cette approche pose des inconvénients : si les changements technologiques sont réalisés en même temps, il devient difficile de déterminer l'origine d'une panne technique qui entraîne des interruptions du travail des employés, enquêtes du coté des administrateurs système.

L'EAI permettra à terme de créer des liens de plus en plus étroits entre les différents partenaires. Pour bientôt les applications EAI permettront la connexion avec des terminaux mobiles tels que les téléphones portables WAP, les assistants personnels, les ordinateurs portables et autres applications Peer to Peer et Wireless.

Gilbert B.F. et Cirano M.L. [I.43] comparent les web services aux Middlewares en expliquant que fonctionnellement, les web services n'apportent rien de neuf par rapport aux Middlewares, conçus pour appeler des services distants, ou par rapport à l'EDI, qui décrit comment échanger des documents d'affaires. Cependant, la façon avec laquelle les web services réalisent ces fonctions est entièrement novatrice, découplant le service lui-même de son implantation.

En bref, la mise en place d'une solution EDI implique un haut niveau de technicité et exige une préparation soigneuse ; elle représente un certain investissement, et induit ensuite des coûts de fonctionnement qui, tout en étant très compétitifs par rapport aux transmissions par courrier, téléphone, télex ou fax, ne sont tout de même pas nuls.

L'utilisation des composants XML, document XML et feuilles de style XSL est relativement facile grâce à des éditeurs XML. Toutefois, l'utilisation unique de ces composants limite l'application du langage à la création de pages HTML statiques. Pour avoir une solution dynamique, il faut employer un langage de programmation.

Mohand-Saîd Hacid et Chantal Reynaud [I.46] dans leurs travaux sur « l'intégration de sources de données » expliquent qu'un datawarehouse répond aux problèmes de données surabondantes et localisées sur de multiples systèmes hétérogènes.

La bonne définition d'un modèle de données générique a été capitale pour ADROIT.

En effet, si une information de l'entreprise ne peut être gérée par le système, son efficacité est remise en question.

Il s'agit alors d'imaginer tous les cas de figure qui risquent de se présenter d'un domaine à un autre pour déterminer le niveau de généricité à mettre en place. C'est ainsi qu'une fois qu'il ait atteint un certain niveau de généralisation, la base de données résultante du modèle, sera utilisée pour l'intégration de ADROIT dans d'autres systèmes.

Le modèle de données de ADROIT est défini sur six (6) principales classes pour gérer toutes les informations de l'entreprise. Elles sont : Acte, Document, Rubrique, Objet, Informations, Tiers

Pour gérer les informations concernant le paramétrage et la gestion des accès du système on a définit trois autres classes, qui sont : Reference, Paramètre, User

Cette classe est l'une des plus importantes de notre modèle. Elle regroupe les informations concernant un acte du système ; c'est-à-dire une FACTURE, un AVOIR, une CONSULTATION ou une HOSPITALISATION. Elle est identifiée par le « NumeroActe » qui est unique et surtout caractérisée par le « Type » de l'Acte. Il y a donc certains attributs qui sont spécifiques à certaines instances d'acte, ce qui prouve la prise en compte de tous les cas de figure.

Cette classe renseigne sur les informations des Tiers concernés par un Acte. Elle est identifiée par le « NumeroTiers » et le « NumeroActe » auquel le Tiers se réfère et caractérisée par le « Type » du Tiers. Le Tiers peut être de type CLIENT, PATIENT, MEDECIN, etc.

Dans cette classe, on définit les produits ou services gérés par l'entreprise. Elle est liée à la classe Acte et sert en même temps pour la gestion de stock. Les instances de cette classe sont surtout caractérisées par leur attribut « Type » qui peut être soit PRODUIT ou SERVICE.

Cette classe fait plutôt référence au détail d'une instance Acte de Actes de nature FINANCE. Elle est aussi liée à la classe Objet.

Dans cette classe on regroupe toutes les autres informations concernant l'Acte ou le Tiers. Elle est identifiée par le « NumeroInfos » et le « NumeroActe » et caractérisée par le « Type » d'Information.

Cette classe contient les informations concernant les utilisateurs du système. Elle est utilisée principalement pour la gestion des utilisateurs.

Dans cette classe on stock les informations concernant les documents joints à une instance Acte de la classe Actes. Elle est identifiée par le « NumeroDoc » et le « NumeroActe ».

Cette classe regroupe les informations de base du progiciel. Elle est indispensable pour le paramétrage et le bon fonctionnement du progiciel.

La classe Reference, regroupe toutes les informations concernant les Type d'Acte, Tiers, Infos, Document et les autres paramètres permettant de faciliter la saisie et les traitements des informations du système.

Ce diagramme représente les six (6) principales classes et les relations existant entre elles.

ADROIT est un logiciel créé par la société InformatiS. Auparavant conçu pour être un ERP, les concepteurs ont pensé le doter d'un système intégrateur pour en faire un système intégré.

Actuellement, [I .78] le modèle ADROIT est basé sur une approche d'intégration centrée sur les modèles. Cette approche a l'avantage de gérer l'interdépendance des plateformes, de permettre un accès temps réel et une interaction bidirectionnelle entre systèmes.

Par contre l'intégration centrée sur les modèles a des inconvénients comme la nécessité de modéliser tous les aspects (sources de données, utilisation des données, agrégation et insertion des données, le problème de maintenance), la problématique des cas où plusieurs structures doivent partager les modèles.

Etant un outil de gestion intégrée du système d'informations de l'entreprise, ADROIT vise des objectifs fonctionnels pouvant améliorer ces performances.

Pour modéliser les processus de traitement et de gestion des informations de processus, les événements, les relations de causalité et les informations elles-mêmes (entités, relations, états, etc...), on peut envisager les approches suivantes [I .78] :

Cette approche permet l'accès aux informations détenues par les sous-systèmes au niveau des postes de travail. L'utilisateur réalise lui même son intégration.

L'intégration poste à poste peut se faire aussi en dotant les différents sous-systèmes de serveurs Web et permettre une consultation facile des informations à partir d'un navigateur. Dans ce cas, l'utilisateur décide de se connecter au serveur Web.

Les systèmes orientés datawarehouse tels que EII, les ERP non modélisé, les EDI et les systèmes de réplication permettent de faire une intégration centrée sur les données.

Cette approche offre aux utilisateurs un entrepôt de données virtuel sans déplacement de données capables de fonctionner en mode événementiel

Cette approche pourra être mise en oeuvre à travers les EAI, les Middleware applicatifs, par workflow ou par BPM (Business Process Management - gestion des processus métiers).

Cette intégration permet de réduire la redondance, améliore la cohérence des informations entre les différents systèmes. Elle est extensible et grâce au workflow et au BPM, on peut respecter l'architecture et les développements déjà réalisés.

Son coût s'avère élevé (modification des sous systèmes existants, développement d'adaptateurs pour les applications à intégrer. Sa véritable traduction syntaxique et sémantique des informations entre les dialectes locaux et le langage commun le rend complexe.

Les web services permettent à un système d'offrir à d'autres systèmes d'intégrer ses informations à leur processus. Ils s'appuient sur un langage ouvert (XML et dérivés) et fonctionnent avec les EAI qui en sont un élément de base.

L'analyse de certains outils d'intégration nous a permis de choisir ETL et EAI en tenant compte des avantages et des inconvénients de chacun.

L'utilisation de ces deux outils nous permettra de répondre immédiatement aux demandes des clients.

L'EAI a des mécanismes d'acheminement des données en temps réel mais ne sait pas transformer les données.

L'ETL est une technologie capable apporter de la cohérence aux données, de transformer et de les consolider dans un datawarehouse.

En générale, l'intégration des systèmes d'informations pose un problème de choix technique vue la limite des techniques à répondre à toutes les questions du décideur

Depuis leur détermination à vouloir mettre en place un système capable de subvenir aux besoins de l'entreprise industrielle, les concepteurs de ERP5 ont introduit les notions de transformation et de variantage dans leur système. Cette initiative a beaucoup joué dans l'espérance de performance souhaitée de ERP5.

Selon Eric Darras, ERP5 est plutôt un progiciel sectoriel qu'un PGI générique en considérant qu'un ERP est sectoriel lorsqu'il est dédié à un secteur spécifique

Les inconvénients de OfBiz résident sur sa lenteur, sa consommation mémoire astronomique (à cause de sa programmation en java/J2EE), et au nombre de tables. Le modèle Entité-Relation de Ofbiz a l'inconvénient de s'attacher plus aux données qu'à la dynamique du système.

Le modèle de données de ADROIT comparé à ERP5 gère la transformation (un produit peut être transformé ou être obtenu à partir de la transformation de plusieurs autres produits) et le variantage (un produit peut avoir plusieurs variantes, par exemple : chaussure taille 12, chaussure taille 20, chaussure taille 23) par le principe du clonage (faire une copie d'un objet et y apporter des modifications).

La classe Acte (contient les actes) peut représenter la classe Movement (définit les mouvements de ressources) dans ERP5. Dans la classe Acte, on retrouve un montant qui peut être un prix, une taxe, un montant d'une rubrique de salaire etc...Mais un problème se pose si un fournisseur (type de tiers) a un profil qui lui permet de vendre à un prix préférentiel ou un client qui doit acheter à un prix préférentiel.

La classe Tiers correspond à la classe correspond à la classe Node de ERP5. Les deux classes ont le même contenu à la différence que dans ERP5, le Stock est un type de Node.

La classe Rubrique correspond à la classe Resource de ERP5. L'ERP ADROIT intégre le prix du produit ou du service alors que dans ERP5, il est prévu la possibilité d'avoir plusieurs prix ou des variations pour une ressource. La classe Ressource du modèle ERP5 contient des objets Profile et Catégorie qui permettent de gérer les prix, les conditions d'achats et de ventes et le variantage. Un produit peut être transformé ou être obtenu à partir de la transformation de plusieurs autres produits donc il y a la notion de transformation qui n'est pas gérée dans l'ERP ADROIT.

L'historique est une fonctionnalité qui a des limites dans ADROIT car l'historique des prix des articles en stock n'est pas pris en compte (dés que le prix d'un article change, il est remplacé et n'est stocké nulle part).

Au niveau des classes, on voit que la classe Informations ne prend en compte que les informations de l'Acte et du Tiers alors que l'Objet peut avoir des informations.

Dans la classe Acte, on retrouve un montant qui peut être un prix, une taxe, un montant d'une rubrique de salaire etc...Mais un problème se pose si un fournisseur (type de tiers) a un profil qui lui permet de vendre à un prix préférentiel ou un client qui doit acheter à un prix préférentiel.

La classe Objet ne permet pas effectivement de prendre en charge les différents prix et les conditions de ventes ou d'achats qui peuvent lui être affectés suivant des profils Tiers bien définis.

L'objectif d'un logiciel, en général, est l'automatisation des tâches auparavant manuelles. Une application informatique est appelée à évoluer au rythme de la technologie et de l'importance des informations gérées.

Pour faire de ADROIT un système intégré capable de prendre en compte les autres logiciels ou de pouvoir intégrer d'autres systèmes, nous avons pensé à proposer trois approches intégratives.

Intégration au niveau des données : Les données sont transmises avec des transformations éventuelles.

Intégration au niveau application : Utilisation d'API métier (web services) pour transférer ou intégrer les flux de données).

Intégration au niveau processus : Orchestration d'un ensemble de tâches à effectuer par différentes applications

Pour atteindre cet objectif visant à assurer l'intégration des données, nous avons proposé les outils EAI et ETL ( Extract Transform, Load ).

L'EAI est un bus inter-applicatif qui fonctionne en mode synchrone et traite des charges importantes de données mais n'a pas de fonctions de transformations.

Extract

L'ETL extrait, transforme les données et les charge dans une nouvelle base de données. Une seule base de données est interrogée par l'outil de restitution. Il fonctionne en mode asynchrone et n'est pas flexible aux modifications. On peut considérer l'ETL qui permet d'alimenter un datawarehouse peut être considéré comme un sous ensemble d'EAI.

Le but de l'extracteur est de prélever le flux de données. L'extraction peut se faire de deux manières (totale ou incrémentielle).

La fonction de transformation permet de supprimer des données de mauvaises qualité (incomplètes, aberrants, doublons, obsolètes etc ...).

Une fois un ensemble homogène obtenu, le chargement (Load) consiste à injecter de manière correcte les données dans le datawarehouse et les rendre disponible.

Pour atteindre cet objectif visant à assurer l'intégration des données, nous avons proposé les outils EAI et ETL (Extract Transform, Load).

La transformation de l'information est assurée par les services de transformations. Avec ces deux outils, la sécurité et la fiabilité des informations et des échanges sont traitées. L'utilisation de XML et/ou des web services par l'intermédiaire de l'EAI permettra aux applications concernées par l'intégration de se connecter.

L'échange direct entre bases de données par l'intermédiaire de l'EAI court circuit la couche métier (les règles de gestion implémentées ne sont pas vérifiées). On pourra parer à ce

problème en dupliquant les règles de gestion dans l'outil EAI mais on aura un autre problème de maintenance dû à l'évolution du logiciel.

Pour faire une intégration efficace au niveau des données, il faut une connaissance parfaite et détaillée des schémas internes de bases de données mis en jeu.

Nous proposerons de faire un datawarehouse (entrepôt de données) pour permettre à l'ETL de charger les données extraites de diverses sources. L'utilisation de l'ETL est limitée par le fait qu'il ne donne pas la photographie en temps réel des données.

L'application ADROIT ne contenant pas d'API (points d'entrées d'intégration applicative), donc il faut faire d'abord une structuration. La modification de l'application ne doit pas nécessiter la modification de l'API métier. Le mode asynchrone court sera utiliser pour permettre à l'EAI d'appeler l'API en mode synchrone.

- Transport (transporter les infos ou les messages entre les applications connectées. Elle s'appuie sur la couche transport du modèle OSI.,

- Sécurité (règles les problèmes d'authentification, d'intégrité, de confidentialité)

Pour ADROIT, nous proposons l'architecture du système centralisé (Hub and Spoke). Aucun flux d'informations ou de données ne pourra se faire sans l'entremise du hub.

Cette intégration est fonctionnelle au niveau de l'application. Le BPI (Business Process Integration ou processus d'intégration d'affaires) se charge de gérer automatiquement le code nécessaire aux interactions entre les actions élémentaires et les instructions permettant au moteur d'exécuter les processus.

Pour permettre une bonne intégration, nous avons proposons ce modèle ci-dessus. Il diffère de l'ancien modèle par la liaison entre les classes Objets et Informations. Nous considérons qu'à l'instar des classes Actes et Tiers, la classe Objets peut avoir des informations.

Par exemple : Une CHAISE a plusieurs caractéristiques telles que la taille, la couleur, poids etc...

Le mot générique est à la mode, il sous entend réutilisation possible, simplicité d'utilisation et unification.

L'introduction de la notion de système générique a permis une adaptation des logiciels aux besoins de l'utilisateur.

Ø paramétrage sur les structures, méta modèles ( c'est à dire en dehors du modèle)

Les PGI sont caractérisés par la généricité des fonctionnalités qu'ils proposent et disposent. Ils utilisent une seule base de données pour l'ensemble des données relatives aux fonctions de l'entreprise

Plutôt que d'ignorer le contexte d'exécution ou de tenter de le masquer par des couches d'abstraction (intergiciel), nous pensons que les applications doivent avoir un caractère générique.

Du point de vue de la technologie, la généricité est une promesse d'économie de moyens, et de réutilisabilité.

Pour montrer l'impact du paramétrage dans la généricité, Pierre Crescenzo dit que [I.52] la généricité regroupe traditionnellement les problèmes de variabilité et ceux d'adaptation à un domaine ou un rôle spécifique. La spécification de modèles, notamment métiers, implique la prévision de différentes variantes d'une même entité pour définir des lignes de produits. En d'autres termes, certaines entités d'un modèle métier sont génériques et cette généricité doit permettre une variation aussi bien structurelle que comportementale des entités.

Selon Mathieu Lafourcade [I.1], la conception et la programmation orientée objet sont imposées comme des modèles de programmation générique mais on peut voir derrière ce terme de programmation générique l'utilisation des patrons de classes.

Les patrons de classes permettent d'atteindre des niveaux de paramétrage et de factorisation des modèles orientés et du code qui restent hors de portée des seuls concepts de l'objet.

L'utilisation des patrons de classes ne se limite pas à la réalisation de conteneurs génériques. La spécialisation est l'opération qui consiste à utiliser un patron en renseignant ses paramètres de généricité. Les classes ainsi construites peuvent être utilisées par du code exécutable.

L'avantage d'un logiciel générique réside dans la réduction des coûts et des risques par contre on trouve ses inconvénients dans la nécessité de réorganisation des processus métiers, la diminution de son avantage concurrentiel et la perte de contrôle total.

Philippe Dosch [I.47] écrit dans son document « Introduction à la conception objet et à C++ » que la généricité permet de définir des modules paramétrés par le type qu'ils manipulent. Un module générique n'est alors pas directement utilisable : c'est plutôt un patron de modèle qui sera « instancié » par les types paramètres qu'il accepte. Cette notion est très intéressante, car elle va permettre la définition de méthodes (façon de travailler) plus que de fonctions (plus formelles). Elle permet de définir des modules paramétrés par le type qu'ils manipulent.

Si la généricité est le moyen de réaliser l'interopérabilité de façon efficace et évite l'explosion combinatoire liée au support de multiples personnalités, la variabilité est définie comme la capacité d'un système à être changé, personnalisé et configuré en fonction d'un contexte spécifique [I.50]

La généricité n'existe pas dans le code compilée, au niveau de la JVM. Cela entraîne quelques restrictions dans son usage.

La généricité a pour seul effet de changer des types pour les variables et méthodes d'une classe. Ces types sont connus une fois la substitution des paramètres effectuée, c'est `a dire dans le code qui utilise la classe paramétrée.

Dans une démarche de conception d'un modèle générique, Michel Chokron, Mireille Des Rochers [I.15] dit que le concept de modèle générique est apparenté à celui d'architecture des systèmes d'information de l'entreprise ou de cadre («framework») de développement des systèmes. Une architecture des systèmes est le regroupement, à l'aide d'un critère donné, des entités et des activités en domaines et des liens entre ces derniers. En général, chaque domaine est sujet au développement d'un système d'information. Un modèle générique est une architecture des systèmes qui peut s'appliquer à un ensemble donné d'entreprises.

Au niveau des systèmes multi-agents, Maher EL'ARBI, Ahmed HADJ KACEM, Mohamed JMAIEL [I.64] montrent que la généricité des modèles et des outils doit donc s'imposer afin d'évoluer vers la réutilisation.

Selon Eric SARDET [I.56], l'approche orientée objets propose une solution pour permettre un accès à des propriétés à un niveau intermédiaire d'une hiérarchie de classes au moyen du mécanisme de factorisation/héritage. Cette approche consiste à redéfinir une propriété ne pouvant être factorisée au niveau d'une famille générique, car ne participant pas à la description de toutes les sous-classes de cette classe générique, dans toutes les classes où elle est effectivement utilisée.

Pour Philippe Dosch [I.47], le concept de généricité permet encore d'accroître cette

abstraction, en proposant des classes qui sont paramétrées par des types de données ;

- extensibilité : les classes sont définies en terme de services. Dès lors, un changement de représentation interne de données ou une modification de celles-ci n'altère pas la façon dont les autres classes les utilisent.

- lisibilité : l'interface (documentée) permet d'avoir un mode d'emploi clair et précis de l'utilisation d'une classe, qui est d'autant plus clair que l'implantation des classes est cachée.

La notion de généricité permet de paramétrer les fonctions et les classes par un type de données.

Pour Frédéric Gava [I.58], avec le polymorphisme objet, on pouvait notamment mettre dans un conteneur différents objets de type différents s'il avait un type père (commun). Mais il était difficile d'exprimer le fait que l'implantation du conteneur ne dépendait pas des objets contenus. Pour cela, il fallait passer soit par un »objet abstrait» (avec les méthodes qui sont utilisées) soit directement par le type Object. La généricité va remédier à ce défaut afin d'exprimer plus concisément ce genre de problèmes (on parle d'expressivité).

Pour Hyacinthe Choury [I.57] la généricité d'un service doit permettre sa réutilisation sans excès. L'approche orientée objets propose une solution pour permettre un accès à des propriétés à un niveau intermédiaire d'une hiérarchie de classes au moyen du mécanisme de factorisation / héritage. Cette approche consiste à redéfinir une propriété ne pouvant être factorisée au niveau d'une une famille générique, car ne participant pas à la description de toutes les sous-classes de cette classe générique, dans toutes les classes où elle est effectivement utilisée.

Selon Mathieu Lafourcade [I.1] dans sa thèse « Génie Logiciel pour le Génie Linguiciel », la généricité est obtenue d'une part au niveau du modèle en permettant l'ajout de nouveaux types et opérateurs. Cette généricité est obtenue d'autre part au niveau des représentations symboliques: elles ne sont pas fixées et il est donc possible d'en ajouter autant que nécessaire tant que les interfaces sont respectées.

Dans la thèse intitulée «Vers un environnement générique d'aide au développement d'applications interactives de simulations de métamorphoses », Fabrice DEPAULIS [I.59] dit qu'à partir d'une application générique, l'utilisateur peut construire de nouvelles fonctions en se basant sur celles existant et les inclure dans la présentation de sa nouvelle application ...Une classe générique est chargée de représenter le « support de programme ». Il s'agit d'identifier, dans la structure de données, le point de départ du parcours de la structure.

Mathieu Barcikowski [I.51] dit que l'un de nos objectifs d' une démarche générique pour l'adaptation des interfaces dans les applications Web est de fournir un système générique. Cette généricité commence par le langage de description des modèles qui permet de représenter selon un même formalisme le modèle usager, de groupe et de contexte. [...] Le modèle usager [...] qui permet de stocker, de modifier et de fournir des informations sur l'environnement dans lequel se déroulent les interactions, sont des services disjoints avec le service d'adaptation fourni par notre système.

Dans son mémoire de DEA intitulé «Une démarche générique pour l'adaptation des interfaces dans les applications Web», Mathieu Barcikowski explique que [I.51] le modèle de contexte est un modèle adaptatif. [...] Le langage de description de modèle est composé de quatre éléments, qui sont les modèles, les sections, les objets et les attributs. [...]

Les modèles permettent de séparer les informations selon l'utilisation auxquelles elles

sont destinées.[...] Les sections permettent d'organiser de manière arborescente les informations

contenues dans les modèles [...] Les objets représentent les différentes catégories d'informations qu'il est possible d'utiliser lors de l'adaptation. Les objets sont décrits par un ensemble d'attributs qui les qualifient. [...] Les attributs fournissent les valeurs qui seront demandées et utilisées lors du processus d'adaptation, et modifiées lors de l'interprétation des actions de l'utilisateur.

Une interface, quelle soit adaptée ou non, a pour but de présenter des informations à l'utilisateur.

Le problème de la représentation des données à afficher se pose alors. L'approche systèmes adaptatifs [...] permet surtout d'adapter la navigation et rend l'adaptation du contenu et de la présentation plutôt difficile à réaliser. [... ] Les systèmes plus récents utilisent une approche par fragments qui permet de bénéficier, en plus d'une adaptation de la navigation, d'une adaptation beaucoup plus fine qui peut porter à la fois sur le contenu et la présentation.

Georges-Louis Baron et Éric Bruillard [I.60] ont expliqué que la relation étroite entre connaissance et représentation soulève la question de la généricité des modèles que l'on peut construire. [...] du point de vue de la technologie, la généricité est une promesse d'économie de moyens, et de réutilisabilité. Le rapport entre spécificité et généricité des modèles est en fait une question fondamentale que nous devons aborder comme telle, c'est-à-dire avec méthode et en cherchant un encadrement théorique du débat qui permette de rendre plus objectif son issue.

Bertrand Marquet et Laurent Ballester [I.53] ont montré que l'approche générique mise en place consiste à appréhender de manière globale le domaine par un modèle générique s'appliquant à la fois sur les exigences du domaine et sur le système proprement dit. La méthode fait apparaître deux grandes étapes : La première consiste à décrire une solution générique sur la base des besoins des utilisateurs des systèmes , des technologies à supporter (bien que, en toute théorie, le modèle devrait être indépendant des technologies) et enfin des normes en vigueur ; la seconde étape consiste à appliquer cette solution générique d'une part à un cadre spécifique en considérant le domaine applicatif.

Pierre Crescenzo, Philippe Lahire, Emanuel Tundrea [I.52] parlent de la généricité paramétrée en expliquant que le concepteur d'un modèle métier doit tout d'abord identifier les différentes entités du domaine modélisé et établir le degré de généricité de chaque entité. Il commence par décrire les entités qui ne sont pas génériques.[...] Pour les entités génériques, le concepteur définit une métaclasse générique et y décrit des paramètres et des caractéristiques qui vont permettre de faire varier la structure et le comportement de ces entités. Ils sont respectivement définis comme des instances des classes .

Selon Mathieu Barcikowski [I.51], le processus d'adaptation [...] consiste à générer une description abstraite d'une interface au moyen d'un langage de description de l'interface. Cette génération s'effectue en fonction du modèle usager, de groupe et de contexte, des fragments et en fonction des templates, mais aussi consiste à traduire l'interface décrite de manière abstraite vers une description concrète utilisant le langage utilisé par le terminal de l'utilisateur. »

Pour avoir un haut degré de généricité, [I.54] les approches orientées modèles, telles que MDA (Model Driven Architecture), prônée par l'OMG , deviennent intéressantes. Ces approches de développement sont souvent appelées "prototypage par raffinements" (evolutionary prototyping) [I.12]. Le principe est de concevoir le système en utilisant un modèle exprimé dans un langage dédié au domaine d'application visé (ici, les systèmes répartis).

Un système générique est décrit par Chouki Tibermacine [I.48] comme un certain nombre de composants. Le mode de communication et de coordination entre ces composants est encapsulé par des connecteurs. La configuration du système est représentée par un assemblage de composants par le biais de connecteurs.

Pour mieux appréhender l'importance des composants dans la généricité, Tarak Chaari et Frédérique Laforest disent que [I.55] pour la généricité, un composant doit fournir des services utiles, conformes à l'usage courant de l'entité qu'il modélise ; l'adaptation d' un composant générique aux besoins spécifiques d' une application doit coûter moins cher que le développement d' un composant spécifique.

Cauvet C., SemmakF. [I.61] ont dit que le développement à base de composants repose sur deux mécanismes : la production de composants pour la réutilisation et la production de composants par réutilisation [[I.61], [I.62]].

La qualité principale attendue d'un composant est d'être réutilisable. Cette qualité est directement liée à sa généricité : la définition d'un composant doit être exempte de tout élément contextuel, lié à une utilisation particulière du composant, qui restreint sa capacité à être réutilisé pour d'autres utilisations. [...] La réutilisabilité d'un composant dépend de la généricité de son contexte de définition. Cette généricité dépend à son tour de la capacité du langage de modélisation à isoler la définition d'un composant de tout contexte d'utilisation.

Sylvain Vauttier, Christelle Urtado et Eric Mendizabal [I.63] ont montré que pour être utile au processus de réutilisation, le contexte de définition d'un composant doit comporter :

- les relations structurelles (relations de composition) qu'entretiennent les classes d'objets du composant entre-elles,

- les relations fonctionnelles (collaborations définies par des relations d'association) qu'entretiennent les classes d'objets du composant entre-elles.

Dans sa thèse,Thomas Quinot [I.49] montre comment le polymorphisme et l'héritage facilitent la réutilisation de composants, l'un en permettant la manipulation générique d'ensembles d'entités partageant un ensemble minimal de propriétés, l'autre en autorisant l'ajout de fonctionnalités à des objets existants, sans modification directe de ceux-ci.

Mamadou Niang , Mohamed Sidi Farssi, Sissoko Gregoire, A. Cissé et A.S.T. Sané [I.65] ont dit que le modèle ADROIT vise la mise en oeuvre des composants d'un SI grâce à une application générique paramétrable dotée d'outils décisionnels et de management de la connaissance.

ADROIT est développé pour répondre aux besoins des entreprises Sénégalaises en générale et surtout pour les centres médicaux dans le domaine de la Télé médecine, de l'Hôtelerie, de l'Enseignement et du Commerce en général. Il peut gérer toute l'activité d'un hôtel ou d'un centre médical.

ADROIT est développé en PHP. Le système est basé sur 6 principales fonctionnalités :

ADROIT permet de faire des saisies, des modifications, des suppressions, des consultations et des éditions.

L'ordonnancement des tâches suit le niveau d'informations de la base de données.

Par exemple: on ne peut pas faire une entrée en stock d'un nouveau article sans pour autant au préalable créer l'article.

Chacune de ses fonctionnalités est le résultat d'une instanciation d'un formulaire qui aura des caractéristiques liées au profil de l'utilisateur.

Par exemple : le secrétaire comptable pourra saisir dans des comptes mais ne pourra pas saisir les infos liées à la masse salariale.

La généricité de ADROIT est fonction de sa capacité de paramétrage. Par cette caractéristique, les modules de ADROIT peuvent être instanciés avec des méthodes, des fonctions et des propriétés spécifiques.

Exemple d'Acte Exemple de Tiers

Les éditions dans ADROIT sont paramétrées de la même manière qu'au niveau formulaire.

On tient compte des profils des utilisateurs; ceci permet d'instancier le module d'impression pour avoir un état ( une facture, un bulletin de salaire etc...).

L'accès au menu principal passe par un formulaire d'authentification lié à la table stockant les informations concernant les utilisateurs autorisés du système. Les règles de contrôle sont définies de sorte que, tout utilisateur du système dispose d'un profil permettant de déterminer quels sont les droits qui lui sont octroyés, et quelles sont les informations auxquelles il a accès. Ce qui fait que n'importe qui ne peut faire n'importe quoi sur le système. Aussi, pour éviter des attaques externes comme internes, la technologie de cryptage md5 a été utilisée pour la transmission des informations sensibles, telles que les mots de passe, sur le réseau.

Ainsi tout mot de passe fourni sur le réseau est crypté de façon irréversible de sorte que même si une personne mal intentionnée récupère l'information, elle ne puisse pas régénérer le mot de passe en clair.

Le paramétrage de ADROIT est relativement simple avec l'interface qu'il offre pour le faire.

L'accès au menu d'administration n'est permis qu'à l'administrateur ou l'intégrateur du site et pour le faire il faut s'identifier à l'accueil.

On accède à toutes les autres fonctionnalités de paramétrage et d'administration du progiciel.

Dans la gestion des Profils, on détermine le niveau d'accès à un domaine fonctionnel du système. Par exemple si on attribue « Publique » au domaine Stock, cela veut dire que Stock est accessible à tout le monde.

Dans la gestion des Outils, l'intégrateur peut stocker ses outils de travail ( outils de développement, de conception et d'intégration etc ...).

Dans la gestion des Domaines, on crée les domaines ou les fonctions d'une entreprise. Ceci permet de faire une gestion verticale d'une fonction d'entreprise. Par exemple : La comptabilité existe dans toutes les entreprises et par conséquent ce domaine pourra être utilisé par toute entité quelque soit son activité (médicale, commerciale, production etc...).

Pour chaque domaine, on peut lui attribuer des classes du modèle. Cette fonctionnalité est un des résultats de la généricité du modèle ADROIT.

Permet de choisir les actes qui peuvent être envoyés par SMS, par mail ou par serveur vocal. Dans ce cas chaque acte est associé à un ou plusieurs types de média. Par exemple : une facture peut être envoyée par SMS, par mail ou son montant communiqué par boîte vocal

Pour chaque Acte, on associe les champs qui sont concernés (les champs d'une facture ne seront pas les mêmes que ceux d'un acte médical). Il n'a que les champs choisis qui seront affichés au moment de l'instanciation de la classe. La généricité réside dans le degré de paramétrage qui permet l'association d'un acte à des champs sans limite aucune.

Les listes font parti d'une série de concepts qui ont donné à ADROIT sa généricité car il y a le principe de la réutilisation des classes telles que TIERS ou OBJETS ou PRODUITS dans toutes les fonctions d'une entreprise. Les listes sont des instances des classes qui participent aux éléments de bases d'une classe principale (Acte). Par exemple : Création de la liste des clients d'une entreprise commerciale ; pour facturer un client, il faut aller récupérer le client dans la liste des clients ou la créer dans la liste.

Dans la gestion des utilisateurs, on peut associer à chaque utilisateur les domaines et les menus où il a accès. Cette fonctionnalité permet de gérer la sécurité du système au niveau accès.

Dans la gestion des types d'Actes, on peut créer des types d'actes qui seront associés à des domaines, des classes (Tiers, Objets ou Produits, Infos ou Documents). Chaque zone contenant l'instance d'une classe peut être affichée ou non suivant la définition et la fonctionnalité du type d'acte considéré.

Ce paramétrage de la gestion des Actes donne un caractère générique au modèle ADROIT.

Dans la gestion des types de Tiers, on peut créer des créer des types de tiers ( par exemple : CLIENTS, FOURNISSEURS, EMPLOYES etc..). L'instanciation de la classe tiers associée au type de tiers permet de créer une liste ( par exemple : Clients : Mamour Ndiaye, Moustapha Diouf etc...)

Dans la gestion des objets, on crée les objets et les produits. Chaque objet ou produit est lié à un type d'Acte. Les produits représentent les articles commercialisables et les objets représentent les immobilisations. Ceci permet par exemple de gérer séparément la gestion des immobilisations à la gestion commerciale. Cette fonctionnalité est possible à cause la généricité du modèle qui à permis de prendre en compte les objets et les produits dans une même entité.

La gestion des informations permet de définir le paramétrage des éléments divers ne figurant pas dans les classes prédéfinies. Ces éléments divers peuvent être des listes qui pourront servir à alimenter le choix des rubriques informations. Par exemple : les pays de naissance ou les pays des adresses clients ou fournisseurs.

La gestion des documents prend en compte les types de documents tels que les documents scannés, les photos, les textes attachés etc. Chaque type de documents peut être lié à un domaine. Par exemple : Le type de document Photo peut être lié au domaine Ressources Humaines.

Intégration et Généricité: Modèle ADROIT

Comparaison des ERP

ERP

TINYERP

ERP5

Extract

Exemple d'Acte Exemple de Tiers