Memoire Online - Refonte du système d'information de la snel par la mise en place d'un module ERP pour la gestion automatique de paiement des factures par voie bancaire grà¢ce à l'intergiciel ActiveMQ

« Toutes sont claires pour celui qui est intelligent, et droites pour ceux qui ont trouvé la science. »

Dédicace

A mon père Frederick-Flavien KABEYA et à ma mère Elisée FUNDU, en signe d'amour, de reconnaissance et de gratitude pour tous les soutiens et les sacrifices dont ils ont fait preuve à mon égard.

Ames très chères soeurs, aucun mot ne pourra décrire vos dévouements et vos sacrifices.

A tous les gens qui ont cru en moi et qui me donnent l'envie d'aller en avant, votre soutien et vos encouragements me donnent la force de continuer.

Nous vous dédions ce travail en vous souhaitant un avenir radieux et plein de bonnes promesses.

Remerciements

A Jéhovah de l'Ancien Testament qui est Jésus-Christ dans le nouveau testament, lui le Dieu Tout Puissant l'Auteur du souffle de ma vie ;

A mes très chers parents pour exprimer toute la reconnaissance, la fierté et le profond amour que je porte pour vous, pour les sacrifices que vous aviez consentis pour ma réussite.

Vous trouverez ici le témoignage de mon attachement, ma reconnaissance, ma gratitude et mon respect ;

A la direction générale de l'Institut Supérieur Pédagogie et Technique de Kinshasa (I.S.P.T-KIN), au corps professoral;

A la direction générale de la Société Nationale d'Electricité (SNEL), au IKS ;

AuProfesseur ANGOMA MONGA SINDANI Blaise, pour une excellente direction, son aide, son partage d'expériences, de connaissances et sa confiance;

A mon oncle Guylain LUKESU ainsi qu'à ma tante Léa KABEYA pour leurs soutiens tant moral que matériel ;

A tous les membres de la famille : Vence, Debbie, Divine, Olga KABEYA, Géraldine KUTIMA, Abraham MUKANZA, Hervé et Dina ZAYA pour leur soutien moral ;

A tous les amis : Joël MBUYI ; Emmanuel TOMBO ; Elie TSHIMANGA; Flavia NGAWANI ; Christ BEYEYE ; Marc BOWALA ; Amigo, Voldy TSOKI, Alliance MANZ, Glody KOBI et que sais-je encore, pour leur soutien moral ;

A tous ceux qui de près ou de loin nous ont soutenus d'une manière ou d'une autre, nous disons cordialement merci. Et que vous trouviez en ce mot l'expression de notre profonde reconnaissance.

FIGURES ET TABLEAUX

Figure I.1	: Système distribué
Figure I.2	: Réseau de communication (intergiciel)
Figure I.3	: Architecture pair à pair
Figure I.4	: Architecture middleware
Figure I.5	: Architecture middleware (ISO)
Figure I.6	: Architecture MOM à plusieurs Brokers
Figure I.7	: Architecture protocole et API
Figure I.8	: Architecture JORAM
Figure II.1	: ERP (modules principales)
Figure III.1	: Organigramme administratif SNEL
Figure III.2	: Organigramme distribution SNEL
Figure IV.1	: Architecture de conception ActiveMQ
Figure IV.2	: Architecture de conception ActiveMQ JMS
Figure IV.3	: Présentation d'un acteur humain
Figure IV.4	: Présentation d'un acteur système
Figure IV.5	: Présentation d'un cas d'utilisation
Figure IV.6	: Présentation d'une relation include
Figure IV.7	: Présentation d'une relation de généralisation
Tableau IV.1	: Identification des acteurs et cas d'utilisation
Figure IV.8	: Diagramme de cas d'utilisation
Tableau IV.2	: Description de cas d'utilisation s'authentifier
Tableau IV.3	: Description de cas d'utilisation visualiser DB
Tableau IV.4	: Description de cas d'utilisation gérer facture
Tableau IV.5	: Description de cas d'utilisation gérer client
Tableau IV.6	: Description de cas d'utilisation créer client
Tableau IV.7	: Description de cas d'utilisation mettre à jour client
Tableau IV.8	: Description de cas d'utilisation supprimer client
Tableau IV.9	: Description de cas d'utilisation gérer DB
Tableau IV.10	: Description de cas d'utilisation gérer tables
Tableau IV.11	: Description de cas d'utilisation se déconnecter
Figure IV.9	: Diagramme de cycle de développement en V
Figure IV.10	: Diagramme de séquence s'authentifier
Figure IV.11	: Diagramme d'activité s'authentifier
Figure IV.12	: Interface MyBANK non connecté
Figure IV.13	: Interface MyBANK connecté
Figure IV.14	: Interface MyBANK saisie et envoie message
Figure IV.15	: Interface SNEL non connecté
Figure IV.16	: Interface SNEL NOTIFY connecté
Figure IV.17	: Interface SNEL NOTIFY réception message
Figure IV.18	: Choix de la langue d'installation Odoo
Figure IV.19	: Démarrage d'installation Odoo
Figure IV.20	: Licence Odoo
Figure IV.21	: Type d'installation All On In
Figure IV.22	: Configuration connexion PostgreSQL
Figure IV.23	: Emplacement et espace requit dans le serveur
Figure IV.24	: Fin de la copie de fichiers système
Figure IV.25	: Fin d'installation Odoo
Figure IV.26	: Configuration Serveur SMTP
Figure IV.27	: Configuration Serveur POP
Figure IV.28	: Connexion sur la machine serveur (Host1)
Figure IV.29	: Connexion sur Host2
Figure IV.30	: Login
Figure IV.31	: Clients
Figure IV.32	: Création client
Figure IV.33	: Génération numéro facture
Figure IV.34	: Validité paiement
Figure IV.35	: PostgreSQL (DB Bank)
Figure IV.36	: DB Bank (table gestion)
Figure IV.37	: PostgreSQL (DB postgres)
Figure IV.38	: DB postgres (table gestion)
Figure IV.39	: PostgreSQL (DB SNEL)
Figure IV.40	: DB SNEL table pour des factures payées ou non
Figure IV.41	: DB SNEL table pour des factures payées ou non
Figure IV.42	: DB SNEL table pour des factures payées
Figure IV.43	: DB SNEL table pour des factures payées

SIGLES ET ABREVIATIONS

SNEL	: Société Nationale d'Electricité
ERP	: Entreprise Resource Planning
PGI	: Progiciel de Gestion Intégré
DB	: Database
SGBD	: Système de Gestion de Base de données
XML	: eXtensibleMarkupLanguage
RPC	: RemoteProcedure Call
GTK	: GimpToolKit
SMTP	: Simple Mail Transfer Protocol
POP	: Post Office Protocol
SSII	: Société de Service et d'Ingénierie Informatique
DSI	: Direction des Systèmes d'Information
PSA	: Professional Service Automatique
ESA	: Entreprise Service Automatique
MRP	: MaterialRequirement Planning
BSD	: Berkeley Software Distribution
MVC	: Modèle Vu Controleur
GRC	: Gestion de la Relation Client
HTML 5	: Hyper TextMarkupLanguage (version 5)
CSS 3	: Cascading Style Sheet (version 3)
TCP	: Transmission Control Protoco
IP	: Internet Protocol
AMQP	: Advanced Message Queuing Protocol
HTTP	: HyperText Transfer Protocol
SQL	: StructuredQueryLanguage
SVG	: ScalableVectorGraphic
GPL v3	: General Public License
GMAO	: Gestion de Maintenance Assisté par Ordinateur
CMS	: Composant Monté en Surface
RAD	: Rapid Application Developement
SMC	: Supply Chain Management
EDI	: Electronic Data Interchange
ETCS	: European Computer Trade Show
CRM	: Customer Relationship Management
GNU	: Cousin de l'Unix (Système d'exploitation et noyau, Unix)
POS	: Point Of Sale
IKS	: Informatique Kinshasa Sud
PME	: Petite et Moyenne Entreprise
PMI	: Petite et Moyenne Industrie
UML	: UnifiedModelingLanguage
ISO	: International Organization for Standardisation
P2P	: Peer to peer
API	: Application Programming Interface
JDBC	: Java Data Base connection
JMS	: Java Messaging System
MOT	: Middleware Orienté Transaction
MOO	: Middleware Orienté Objet
MOM	: Middleware Orienté Message

INTRODUCTION GÉNÉRALE

0.1 Aperçu sur le sujet

Actuellement, avec le développement de la technologie de l'information, les entreprises sont de plus en plus font face à une panoplie de logiciels pour la gestion de leurs processus au quotidien. Le traitement de l'information dans l'entreprise est en pleine mutation. Toutes les entreprises, aussi bien nationales et qu'internationales, les PME et les PMI, sont confrontées aux besoins changeant du marché tels que : acquisitions, fusions et solutions collaboratives.

Aujourd'hui, l'informatique a pénétré dans tous les domaines de la vie quotidienne, nous citons : domaine financier, économique, politique, industriel, etc. l'informatique apparait comme un mode d'organisation répondant le mieux aux besoins d'une société cherchant sa voie vers un type nouveau de croissance dans les différents domaines de la vie. Elle offre aux grandes entreprises de production, la possibilité de réaliser en temps record des calculs complexes requis dans les industries.

Mais elle intervient également dans le secteur de l'enseignement, les banques, les assurances ou encore les commerces, ainsi qu'à domicile. Grace à la conception et à la fabrication assistée par ordinateur, l'informatique est un outil important dans tous les métiers nécessitant une modélisation préalable.

Etant donnée la diversité de systèmes existants au sein d'une entreprise ainsi que de la nécessité de collaboration entre ces entreprises, l'utilisation des logiciels dits middleware `intergiciel' deviennent de plus en plus incontournables. La mise en oeuvre d'un intergiciel (middleware) facilite donc la communication entre des différents logiciels et présente de nombreux avantages tels que : cohérence et homogénéité des informations, intégrité et unicité des données de base, partage du même système d'information, solution multi référentiels et multi législations, gain de productivité....

Dans ce projet, nous envisageons grâce à un système informatique de haut niveau faire communiquer deux systèmes d'information hétérogènes d'un côté,les banques et d'un autre, La SNELen utilisant le middleware ActiveMQ. Nous allons mettre également en place au sein de la SNEL, un module de gestion des factures en utilisant l'ERP Odoo, que nous aurons à détailler tout long de ce rapport. Nous comptons dans le cadre de mémoire TFE de licence nous focaliser sur le processus denotification automatiquelors despaiements de facture par voie bancaire.

Ainsi, le travail réalisé a été divisé en quatre chapitres. Dans le premier chapitre, il sera question de donner les généralités sur les intergiciels. Dans le second chapitre, nous présentons un état de l'art sur les ERPs. Le troisième chapitre abordera de l'analyse et critique de l'existant. Et le dernier chapitre sera consacré àla conception et l'implémentation de notre projet.

C'est pourquoi notre sujet est intitulé « Refonte du système d'information de la SNEL par la mise en place d'un module ERP pour la gestion automatique de paiement des factures par voie bancaire grâce à l'intergicielActiveMQ»

Dans ce travail, notre préoccupation majeure est d'améliorer le système gestion de paiement de facture en automatisant le processus au travers d'une collaboration temps réel avec les banques. Celles-ci informent le Système d'Information de la SNEL via un intergiciel de messagerie afin de rendre le travail de la finance et du commercial de la SNEL plus optimal en quittant l'approche traditionnelle vers une nouvelle gestion numérique par l'automatisation des activités opérationnelles.

0.2 PROBLEMATIQUE

La problématique désigne l'ensemble de questions posées dans un domaine de la science, en vue d'une recherche des solutions.

Ce travail traite de l'informatisation de processus de notificationdes banques à la finance de la Société Nationale d'Electricité, afin d'optimiser la gestion de paiement et permettre à la société elle-même d'avoir les informations fiables sur la gestion des paiements de ses clients. Aussi cette solution permettra aux clients d'effectuer le paiement dans n'importe quelle banque collaborant avec la SNEL.

Et d'après les investigations que nous avons menées dans le cadre de notre travail, nous nous sommes rendu compte que la Société Nationale d'Electricité continue toujours à utiliser la gestion manuelle des toutes les opérations liées au paiement de facture. Par conséquent, ellea du mal à faire un bon suivi sur les différents paiements et avoir un état réel de la situation de ses finances à un instant donné.

Ø La manière dont la SNEL arrive à avoir les informations sur les paiements par voie bancaires des factures de ses clients est-elle efficace par rapport aux objectifs du service demandé ?

Ø Qu'est ce qui explique la lenteur et les pertes de données au sein de cet établissement ?

0.3 HYPOTHESE

Une hypothèse est une proposition relative à une explication admise provisoirement avant d'être confirmée ou infirmée.

Dans le cadre de notre travail, nous émettons les hypothèses que voici : Compte tenu des grandes préoccupations telles que révélées dans la problématique, nous envisageons l'amélioration du système de gestion existant par l'informatisation du processus de gestion de paiement de facture au travers d'une communication temps réel avec les différentes banques.Ceci permettra d'éradiquer les erreurs de traitement et la mauvaise conservation des données.

0.4 CHOIX ET INTERET DU SUJET

Ø La contrainte qu'ont les étudiants finalistes de différents cycles de l'enseignement supérieur et universitaire de réaliser un travail de qualité à la fin de leur formation;

Ø Les besoins réels des entreprises congolaises à intégrer dans leur système d'information un module la gestion automatisée de paiement de facture au travers de n'importe quelle banque ou service monétique.

Ø Faciliter les clients à payer leurs factures dans faire des longs trajets pour trouver une agence de paiement de ladite société.

L'intérêt du sujet que nous développons est de chercher les voies et moyens de mettre un système pour l'épanouissement du service de finance et commercial dans le souci d'améliorer ses conditions de travail avec l'aide des procédures informatiques.

0.5 BUT ET OBJECTIFS POURSUIVIS

Nous comptons dans les années avenir centraliser les données clients par la mise en place d'un système d'information temps réel pour le compte de la Société Nationale d'Electricité pour sa meilleure gestion de toutes ses fonctions. Nous comptons aussi proposer un intergiciel pouvant interagir plusieurs systèmes hétérogènes tant dans le monde de finance que dans la production industrielle.

0.6 METHODES ET TECHNIQUES UTILISEES

En vue de doter ce travail d'un caractère scientifique, il est important d'opter une méthode parmi tant d'autres. Elle s'entend comme un cheminement cohérent de la pensée humaine en vue de donner une solution définitive à un problème de fond.

Selon R.PINTO et M. GRAWITZ, la méthode est un ensemble d'opérations intellectuelles par lesquelles une discipline cherche à atteindre la vérité qu'elle poursuit, la démontre et la vérifie.

Ainsi pour l'élaboration de ce travail, nous optons pour la méthode suivante :

Ø Méthode structuro-fonctionnelle : qui nous permet d'analyser la structure concernée ainsi que son fonctionnement et elle nous a doté des techniques et méthodes à suivre pour la conception d'une application informatique.

Nous avons utilisé deux techniques pour élaborer ce travail de fin de cycle, à savoir : les techniques documentaires et d'interview.

Ø Technique documentaires : a été d'une grande utilité pour collecter les données à partir des différents documents mis à notre disposition ;

Ø Technique d'interview : grâce à cette technique, nous avons obtenu des informations par le jeu des questions et réponses auprès des interlocuteurs ;

0.7 DELIMITATION DU SUJET

La délimitation du sujet consiste à cadrer ou à circonscrire les contours et les sphères de la recherche.

A ce stade, nous ne pouvons pas embrasser tous les services de cet établissement. Ainsi, nous voulons circonscrire les champs de notre étude sur les échanges des données entreles banques et la snel ainsi que côté gestion facturationde la snelsans toucher les autres fonctions.

0.8 SUBDIVISION DU TRAVAIL

Hormis l'introduction générale et la conclusion générale, notre travail est subdivisé en quatre (4) chapitres, à savoir :

CHAPITRE I. GENERALITES SUR LES INTERGICIELS

I.1 INTRODUCTION

Ce chapitre définit, donne le rôle, et l'historique résumant les grandes étapes de l'évolution et présente toutes les fonctions de l'intergiciel, les besoins auxquels elles répondent, ainsi que le système distribué.Et les principales types et sortes, l'analyse simple d'intergiciel en générale et celui de MOMs en particulier et les problèmes que pose leur conception.

I.2 DEFINITIONS D'INTERGICIEL

L'intergiciel (ou middleware en anglais) désigne les logiciels servant d'intermédiaire entre d'autres logiciels. On utilise généralement du middleware comme intermédiaire de communication entre des applications complexes, distribuées sur un réseau informatique.

On appelle middleware, l'ensemble des couches réseaux et des services logiciels qui permettant le dialogue entre les différents composants d'une application repartie. Ce dialogue se base sur un protocole applicatif commun, définie par l'API de middleware.

I.3 ROLE D'UN INTERGICIEL

Un intergiciel se situe au-dessus du système d'exploitation (OS pour OperatingSystem) et en dessous des applications (c'est-à-dire des clients et/ou des services) de son hôte.

L'utilisation d'un intergiciel permet de développer des applications viala réutilisation/assemblage de services déployés au travers de différents objetscommunicants indépendamment de leur localisation, langage de programmation, système d'exploitation et matériel.

Un intergiciel fournit différentes fonctionnalités/facilités pour l'implémentation d'applications distribuées. Dans la littérature, les fonctionnalités offertes d'un intergiciel sont souvent présentées comme étant les services de l'intergiciel à ne pas confondre, dans notre contexte, avec les services de l'architecture des services de messagerie.

I.4HISTORIQUE

Le terme middleware semble être apparu vers 1990, mais des systèmes intergiciels existaient bien avant cette date. Des logiciels commerciaux de communication par messages étaient disponibles à la fin des années 1970.

La référence classique sur l'appel de procédure à distance est (Birrell and Nelson 1984), mais des constructions analogues, liées à des langages particuliers, existaient déjà auparavant (la notion d'appel de procédure à distance apparaît dans white 1976 et une première réalisation est proposée dansBrinch Hansen 1978.

Vers le milieu des années 1980, plusieurs projets développent des infrastructures intergicielles pour objets répartis, et élaborent les principaux concepts qui vont influencer les normes et les produits futurs. Les précurseurs sont Cronus (Schantz et al. 1986) et Eden (Almes et al. 1985), suivis par Amoeba (Mullender et al. 1990),ANSAware (ANSA),Arjuna (Parrington et al. 1995, Argus (Liskov 1988), Chorus/COOL (Lea et al. 1993),Clouds (Dasgupta et al. 1989,Comandos (Cahill et al. 1994,Emerald (Jul et al. 1988),(GothicBanatre and Banatre 1991), Guide (Balter et al. 1991), Network Objects (Birrell et al. 1995), SOS (Shapiro et al. 1989), et Spring (Mitchell et al. 1994).

L'Open Software Foundation (OSF), qui deviendra plus tard l'Open Group, est créée en 1988 dans le but d'unifier les diverses versions du système d'exploitation Unix. Cet objectif ne fut jamais atteint, mais l'OSF devait spécifier une plate-forme intergicielle, le DistributedComputingEnvironment (DCE) [Lendenman 1996], qui comportait notamment un service d'appel de procédure à distance, un système réparti de gestion de fichiers, un serveur de temps, et un service de sécurité.

L'Object Management Group (OMG) est créé en 1989 pour définir des normes pour l'intergiciel à objets répartis. Sa première proposition (1991) fut la spécification de CORBA 1.0 (la version courante, en 2005, est CORBA 3). Ses propositions ultérieures sont des normes pour la modélisation (UML, MOF) et les composants (CCM).

L'Object Database Management Group (ODMG) définit des normes pour les bases de données à objets, qui visent à unifier la programmation par objets et la gestion de données persistantes.

Le modèle de référence de l'Open DistributedProcessing (RM-ODP), a été conjointement défini par deux organismes de normalisation, l'ISO et l'ITU-T. Il propose un ensemble de concepts définissant un cadre générique pour le calcul réparti ouvert, plutôt que des normes spécifiques.

La définition du langage Java par Sun Microsystems en 1995 ouvre la voie à plusieurs intergiciels, dont Java Remote Method Invocation (RMI) [Wollrath et al. 1996] et les Enterprise JavaBeans (EJB) [Monson-Haefel 2002]. Ces systèmes, et d'autres, sont intégrés dans une plate-forme commune, J2EE.

Microsoft développe à la même époque le Distributed Component Object Model (DCOM) [Grimes 1997], un intergiciel définissant des objets répartis composables, dont une version améliorée est COM+ [Platt 1999]. Son offre courante est .NET, plate-forme intergicielle pour la construction d'applications réparties et de services pour le Web.

La première conférence scientifique entièrement consacrée à l'intergiciel a lieu en 1998. Parmi les thèmes actuels de la recherche sur l'intergiciel, on peut noter les techniques d'adaptation (réflexivité, aspects), l'administration et notamment les travaux sur les systèmes autonomes (pouvant réagir à des surcharges ou à des défaillances), et l'intergiciel pour appareils mobiles et environnements ubiquitaires.

I.5 SYSTEME DISTRIBUE

I.5.1 Définition

Un système distribué est un système disposant d'un ensemble d'entités communicantes, installées sur une architecture d'ordinateurs indépendants reliés par un réseau de communication, dans le but de résoudre en coopération une fonctionnalité applicative commune.

Autrement dit, un système distribué est défini comme étant un ensemble des ressources physiques et logiques géographiquement dispersées et reliées par un réseau de communication dans le but de réaliser une tâche commune. Cet ensemble donne aux utilisateurs une vue unique des données du point de vue logique.

Un système distribué est un ensemble d'entités autonomes de calcul (ordinateurs, processeurs, processus, processus léger etc.) interconnectées et qui peuvent communiquer.

I.5.2 Intérêt des systèmes distribués

Ø Partage des ressources (données, programme, services) qui permet un travail collaboratif ;

Ø Accès distant, c'est-à-dire qu'un même service peut être utilisé par plusieurs acteurs situés à des endroits différents ;

Ø Amélioration des performances : la mise en commun de plusieurs unités de calcul permet d'effectuer des calculs parallélisés en des temps plus courts ;

Ø Confidentialité : les données brutes ne sont pas disponibles partout au même moment, seules certaines vues sont exportées ;

Ø Maintien d'une vision unique de la base de données malgré la distribution ;

Ø Augmentation de la fiabilité grâce à la duplication de machines ou de données, ce qui induit à une réalisation des systèmes à haute disponibilité.

I.5.3 Quelques domaines d'application des systèmes distribués

Ø La gestion intégrée des informations d'une entreprise (guichet de banque, agence de voyage,..) ;

Ø Internet : l'internet, aujourd'hui, constitue un grand exemple d'un système distribué le plus large au monde contenant de nombreux sous-systèmes selon le protocole considéré. Exemple : Web (http), bittorrent (peer-to-peer).

Des nombreux utilisateurs partout dans le monde peuvent utiliser des services offerts par l'internet comme le WWW, le FTP (File Transfert Protocol) et tant d'autres applications. On remarque ici une collection de réseaux d'ordinateurs interconnectés.

Et les programmes s'y exécutant interagissent grâce aux échanges de messages en utilisant un moyen de communication ou un autre ;

Ø Le WWW représente un système distribué logique consistant en un nombre considérable de ressources (pages web, fichiers de données et services) référencées par des URL (Uniform Ressource Locator) ;

Ø Le contrôle et organisation d'activités en temps réel (télévision interactive).

I.5.4 Difficulté de mise en oeuvre

La mise en oeuvre des systèmes distribués engendre un certain nombre de difficultés dont voici quelques-unes :

I.5.4.1 Gestion de l'hétérogénéité et Cohérence des données

Lors de la mise en place d'un système distribué, il est nécessaire que l'ensemble des composants travaillent avec des données cohérentes. Cette cohérence des données est d'autant plus problématique lorsque l'on commence à redonder certains composants pour augmenter la capacité de traitement et/ou la disponibilité du système.

En effet, les données comme le cache applicatif, le contenu d'une base de données ou bien les variables de session des utilisateurs Web doivent être synchronisées entre les différentes instances d'un composant afin d'assurer une cohérence dans les traitements réalisés.

I.5.4.2 Gestion des composants

Un système distribué étant composé d'un ensemble de composants logiciels répartis sur plusieurs serveurs physiques. Il est nécessaire pour assurer la maintenance corrective et évolutive du système de dresser une cartographie complète de ce système.

I.5.4.3 Disponibilité et détection d'arrêts

Dans un système distribué, l'indisponibilité d'un seul composant du système (serveur, base de données, ...) peut rendre indisponible le système complet. On mesure alors la disponibilité de ce type de système à celle de son maillon le plus faible.

Pour couvrir ce risque, il est nécessaire de mettre en place en amont une architecture permettant d'assurer la disponibilité cible pour tous les composants. Une fois que cette architecture est en production, des opérateurs doivent à l'aide de logiciels s'assurer de la détection au plus tôt d'un

I.5.4.4Gestion de la séquentialité

La mise en place d'un cluster de type actif/actif provoque la création de deux points d'entrée au système. Dans le cas d'un système distribué d'échange de données par exemple, il est alors possible que deux modifications successives du même objet soient dirigées vers deux noeuds différents du cluster, ce qui dans l'absolu peut aboutir à une situation où le message le plus récent est diffusé en premier vers l'application destinataire.

Si aucune gestion de la séquentialité des messages n'est faite, le message le plus ancien viendra écraser dans les applications destinataires le message le plus récent.

I.5.5 Caractéristiques des systèmes distribués

La performance d'un système distribué se révèle dans ces caractéristiques. Ces caractéristiques ci-dessous devraient être prises en compte lors de la conception d'un système distribué.

I.5.5.1 Interopérabilité

Dans un système distribué, ilse pose un vrai problème de coopération entre différents composants du système. En effet, ce problème peut être vu au niveau de la couche matériel (différents réseaux physiques et plateforme matérielle), de la couche système d'exploitation (divers OS utilisés (UNIX, Windows, Mac OS, Solaris)), de la couche application (langages de programmation différents) et de la couche middleware (.NET pour Microsoft, Corba pour le Consortium OMG). On parle de l'hétérogénéité, un problème dans le partage des ressources dans un système distribué.

L'interopérabilité est une caractéristique importante qui désigne la capacité à rendre compatibles deux systèmes quelconques. A son tour, la compatibilité est la capacité qu'ont deux systèmes à communiquer sans ambiguïté.

En effet, l'interopérabilité vise à réduire le vrai problème de l'hétérogénéité en la masquant par l'utilisation d'un protocole unique de communication (exemple de TCP/IP pour l'Internet). Pour les échanges des messages, il faut utiliser des standards qui cachent les différences entre les différentes plateformes.

Actuellement, il existe deux approches principales de standardisation pour masquer l'hétérogénéité : les middlewares et les machines virtuelles.

Concrètement, un middleware est représenté par des processus et des ressources d'un ensemble d'ordinateurs, qui interagissent les uns avec les autres. Ies middlewares améliorent la communication en offrant des abstractions telles que :

Ø Le RMI (Remote Method Invocation) qui est la possibilité, pour un objet, d'invoquer la méthode d'un autre objet situé sur une plateforme distante ;

Ø La notification d'événement pour la propagation d'informations d'une plateforme vers une autre ou plusieurs autres plateformes ou composants d'une application distribuée ;

Les machines virtuelles permettent de supporter le code mobile désignant la possibilité de transfert de code d'une machine source à une machine de destination et son exécution sur cette machine.

Au cas des différentes plateformes, le code produit sur l'une ne peut fonctionner sur l'autre. Pour éviter ce problème, le code mobile est généré d'un langage source pour une machine virtuelle donnée (exemple de la JVM).

En effet, chaque plateforme doit disposer d'une couche logicielle qui implémente la machine virtuelle car cette dernière représente une généralisation des middlewares offrant les mêmes services.

I.5.5.2 Partage des ressources

Le partage des ressources est le facteur principal de motivation pour construire les systèmes répartis. Des ressources telles que des imprimantes, des dossiers, des pages Web ou des disques de base de données sont contrôlées par des serveurs du type approprié. Par exemple, les serveurs Web contrôlent des pages Web et d'autres ressources d'enchaînement. Des ressources sont consultées par des clients - par exemple, les clients du web des serveurs s'appellent généralement les browsers (navigateurs) ;

I.5.5.3 Ouverture

Cette caractéristique fait mention de l'extensibilité dans la mesure où des composants peuvent être ajoutés, remplacés ou supprimés dans un système distribué sans en affecter les autres. Et lorsque nous parlons des composants, nous voyons les matériels (les périphériques, mémoires, interfaces, etc. et les logiciels (protocoles, pilote, etc.). L'ouverture nécessite que les interfaces logicielles soient documentées et accessibles aux développeurs d'applications.

Il se pose un vrai problème avec l'ouverture au sens que les composants d'un système distribué sont hétérogènes. Alors, cette qualité d'ouverture est accordée aux systèmes supportant sans ambages :

Ø L'ajout de nouveaux services au niveau application, middleware et système d'exploitation ;

I.5.5.4 Expansible

Nous disons qu'un système distribué est expansible lorsque les modifications du système et des applications ne sont pas nécessaires quant à l'augmentation de la taille de ce système.

I.5.5.5 Performance

Dans ce cas, le système doit s'adapter à bien fonctionner même quand le nombre d'utilisateurs ou de ressources augmentent.

I.5.5.6 Transparence

La transparence cache aux utilisateurs l'architecture, la distribution des ressources, le fonctionnement de l'application ou du système distribué pour apparaître comme une application unique cohérente.

La norme ISO (1995) définit différents niveaux de transparences telle que la transparence d'accès, de localisation, de concurrence, de réplication, demobilité, de panne, de performance, d'échelle).

Ø Transparence d'accès :il s'agit d'utiliser les mêmes opérations pour l'accès aux ressources distantes que pour les celles locales ;

Ø Transparence à la localisation : l'accès aux ressources indépendamment de leur emplacement doit être inconnue à l'utilisateur ;

Ø Transparence à la concurrence : il s'agit de cacherà l'utilisateur l'exécution possible de plusieurs processus en parallèle avec l'utilisation desressources partagées en évitant des interférences ;

Ø Transparence à la réplication : la possibilité de dupliquer certains éléments/ressources (fichiers de base de données) pour augmenter la fiabilité etaméliorer les performances doit être cachée à l'utilisateur ;

Ø Transparence de mobilité : il s'agit de permettre la migration des ressources et des clients à l'intérieur d'un système sans influencer le déroulementdes applications ;

Ø Transparence de panne : il s'agit de permettre aux applications des utilisateurs d'achever leurs exécutions malgré les pannes qui peuvent affecter lescomposants d'un système (composants physiques ou logiques) ;

Ø Transparence à la modification de l'échelle : il s'agit de la possibilité d'une extension importante d'un système sans influence notable sur lesperformances des applications.

Ø Transparence à la reconfiguration: il s'agit de cacher à l'utilisateur la possibilité de reconfigurer le système pour en augmenter les performances enfonction de la charge ;

En effet, la transparence n'est pas toujours possible dans certains cas. Notons le cas de la duplication d'une imprimante des caractéristiques différentes pour besoin des performances dans le système. Cependant, l'utilisateur doit toutefois avoir la possibilité de spécifier concrètement sur quelle imprimante il souhaite imprimer ses documents.

I.5.5.7 Sécurité

Le problème de sécurité se pose dans tout système informatique. Dans un système distribué, les ressources doivent être protégées contre des utilisations abusives et malveillantes. En particulier, le problème de piratage des données sur le réseau de communication. En ces raisons, il est préférable d'utiliser des périphériques ou logiciels licenciés. Outre, les connexions doivent être sécurisées par authentification avec les éléments distants ainsi que les messages circulant sur ce réseau doivent être cryptés en vue d'éviter des conséquences graves.

Le concept de sécurité des systèmes d'information recouvre un ensemble de méthodes, techniques et outils chargés de protéger les ressources d'un système d'information afin d'assurer :

Ø la disponibilité des services : les services (ordinateurs, réseaux, périphériques, applications...) et les informations (données, fichiers...) doivent êtreaccessibles aux personnes autorisées quand elles en ont besoin ;

Ø la confidentialité des informations : les informations n'appartiennent pas à tout le monde ; seuls peuvent y accéder ceux qui en ont le droit ;

Ø l'intégrité des systèmes : les services et les informations (fichiers, messages...) ne peuvent être modifiés que par les personnes autorisées(administrateurs, propriétaires...).

I.5.5.8. Concurrence

Le problème de la concurrence permet l'accès simultané à des ressources par plusieurs processus. Ce problème se pose pour les systèmes distribués comme pour les systèmes centralisés.

En effet, il y a bien d'autres ressources dont l'accès simultané n'est pas possible. Dans ce cas, leur manipulation ne peut se faire que par un processus à la fois. Le cas des ressources physiques telles que l'imprimante mais aussi des ressources logiques telles que les fichiers, les tables des bases de données, etc.

Dans ce cas, les applications distribuées (reparties) actuelles autorisent l'exécution de plusieurs services en concurrence (cas de l'accès à une base de données). Chaque demande est prise en compte par un processussimple appelé thread ; et la gestion de la concurrence fait appel aux mécanismes de synchronisation classiques.

I.5.5.9. Tolérance aux pannes

Une panne peut être comprise comme une faille au sein du système pouvant conduire à des résultats erronés comme aussi engendrer l'arrêt de toute ou partie d'un système distribué.Les pannes peuvent résulter des différentes couches et se propager éventuellement aux autres.

Peut-être, c'est une raison matérielle ou logique liée à la conception des applications, des middlewares et des systèmes d'exploitation.

Ainsi, un système distribué doit être conçu pour masquer ce genre des pannes aux utilisateurs.

La panne de certains serveurs (ou leur réintégration dans le système après la réparation) ne doit pas perturber l'utilisation du système en terme de fonctionnalité.

I.5.5.10. Disponibilité

Dans un système distribué, l'indisponibilité d'un seul composant du système (serveur, base de données, ...) peut rendre indisponible le système complet alors qu'il doit rendre en permanence des services et d'une façon correcte. On mesure alors la disponibilité de ce type de système à celle de son maillon le plus faible.

Ø aux pannes empêchant le système ou à ses composants de fonctionner correctement ;

Ø aux attaques de sécurité pouvant causer, d'une façon ou d'une autre, des dysfonctionnements, les incohérences et pertes de données et même l'arrêt du système.

Ø mettre en place en amont une architecture permettant d'assurer la disponibilité cible pour tous les composants. Une fois que cette architecture est en production, des opérateurs doivent à l'aide de logiciels s'assurer de la détection au plus tôt d'une défaillance de l'un des composants de l'architecture.

Ø veiller à la réplication des données au sein de ce système (c'est la solution que nous avons choisi dans le cadre de notre travail).

I.5.6 Architecture distribuée

L'architecture d'un environnement informatique ou d'un réseau est dite distribuée lorsque toutes les ressources ne se trouvent pas au même endroit ou sur la même machine. Ce concept s'oppose à celui d'architecture centralisée dont une version est l'architecture client-serveur que nous allons aussi voir dans cette partie.

En effet, la programmation orientée objet a permis le développement des architectures distribuées en fournissant des bibliothèques de haut-niveau pour faire dialoguer des objets répartis sur des machines différentes entre eux. Les objets distribués sur le réseau communiquent par messages en s'appuyant sur l'une des technologies telles que CORBA, RMI, les services web XML, .Net Remoting, Windows Communication Foundatation, etc.

Les architectures distribuées reposent sur la possibilité d'utiliser des objets qui s'exécutent sur des machines réparties sur le réseau et communiquent par messages au travers du réseau.

I.5.6.1. Avantages des architectures distribuées

Ø Augmentation des ressources : la distribution des traitements sur les ordinateurs d'un réseau augmente les ressources disponibles;

Ø Répartition des données et des services : (cas de l'architecture 3-tiers à la base de la plupart des applications distribuées de commerce électronique permettant d'interroger et de mettre à jour des sources de données réparties) ;

I.5.6.2. Types d'architecture distribuée

I.5.6.2.1. Architecture client-serveur

Le client server est avant tout un mode de dialogue entre deux processus. Le premier appelé client, demande l'exécution de services au second appelé serveur. Le serveur accomplit les services et envoi en retour des réponses. En général, un serveur est capable de traiter les requêtes de plusieurs clients.

Un serveur permet donc de partager des ressources entre plusieurs clients qui s'adressent à lui par des requêtes envoyées sous forme de messages.

Par extension, le client désigne également l'ordinateur sur lequel est exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté lelogiciel serveur.

Le client serveur étant un mode de dialogue, il peut être utilisé pour réaliser de multiples fonctions.

Parlant de l'architecture client-serveur, nous distinguons trois types d'acteurs principaux:

Un client est un processus demandant l'exécution d'une opération à un autre processus (fournisseur des services) par l'envoi d'un message contenant le descriptif de l'opération à exécuter et attendant la réponse à cette opération par un message en retour.

· Client léger : est une application accessible via une interface web consultable à l'aide d'un navigateur web ;

· Client lourd : est une application cliente graphique exécuté sur le système d'exploitation de l'utilisateur possédant les capacités de traitementévoluées ;

· Client riche : est une combinaison du client léger et client lourd dans lequel l'interface graphique est décrite avec une grammaire basée sur lasyntaxe XML.

On appelle serveur un processus accomplissant une opération sur demande d'un client et lui transmettant le résultat. Il est la partie de l'application qui offre un service, il reste à l'écoute des requêtes du client et répond au service demandé par lui. En effet, un serveur est généralement capable de servir plusieurs clients simultanément.

Ø Il est à l'écoute, prêt à répondre aux requêtes envoyées par des clients ;

Nous distinguons plusieurs types de serveur en fonction des services rendus : Serveur d'application, serveur de base de données, serveur des fichiers, etc.

Comme nous l'avons dit ci-haut le middleware est l'ensemble des services logiciels qui assurent l'intermédiaire entre les applications et le transport de données dans le réseau afin de permettre les échanges des requêtes et des réponses entre client et serveur de manière transparente.

Le client serveur étant un mode de dialogue, il peut être utilisé pour réaliser de multiples fonctions. Il existe donc différents types de client-serveur qui ont été définis : le client serveur de présentation, le client serveur de données et le client serveur de procédures.

I.5.6.2.2. Architecture pair-à-pair (peer-to-peer ou P2P)

Le pair-à-pair est un modèle de réseau informatique proche du modèle client-serveur mais où chaque ordinateur connecté au réseau est susceptible de jouer tour à tour le rôle de client et celui de serveur.

P2P est une architecture pouvant être centralisée (les connexions passant par un serveur central intermédiaire) ou décentralisée (les connexions se faisant directement).

Le pair-à-pair peut servir au partage de fichiers en pair à pair, au calcul distribué ou à la communication entre noeuds ayant la même responsabilité dans le système.

La particularité des architectures pair-à-pair réside dans le fait que les données peuvent être transférées directement entre deux postes connectés auréseau, sans transiter par un serveur central.

Cela permet ainsi à chaque ordinateur d'être à la fois serveur de données et client des autres. On appelle souvent noeudles postes connectés par un protocole réseau pair-à-pair.

Outre, les systèmes de partage de fichiers pair-à-pair permettent de rendre les ressources d'autant disponibles qu'elles sont populaires, et donc répliquées sur un grand nombre de noeuds.

Cela permet alors de diminuer la charge (en nombre de requêtes) imposée aux noeuds partageant les fichiers dans le réseau.

C'est ce qu'on appelle le passage à l'échelle. Cette architecture permet donc de faciliter le partage des ressources. Elle rend aussi la censure ou les attaques légales ou pirates plus difficiles.

Ces atouts font des systèmes pair-à-pair des outils de choix pour décentraliser des services qui doivent assurer une haute disponibilité tout en permettant de faibles coûts d'entretien. Toutefois, ces systèmes sont plus complexes à concevoir que les systèmes client-serveur.

I.5.7Les perspectives des architectures distribuées

L'une des évolutions attendues dans les temps à venir est le remplacement des achats de logiciels informatiques par des locations de ces mêmes logiciels, pour le temps nécessaire à leur utilisation.

On peut imaginer, par exemple, qu'il sera possible, à partir d'un logiciel de traitement de texte, de faire appel à différents services de corrections orthographiques disponibles sur Internet, et dont on louera les services selon les besoins.

I.6CARACTERISTIQUES DES INTERGICIELS

I.6.1 Les middlewares synchrones

Un autre mécanisme courant est l'appel synchrone (c), dans lequel A (le client d'un service fourni par B) envoie un message de requêteB et attend une réponse (cette émission est bloquante). Ce patron est utilisé dans le RPC. Les interactions synchrone et asynchrone peuvent être combinées, par exemple dans diverses formes de < RPC asynchrone >.

Le but est de permettre au demandeur d'un service de continuer son exécution après l'envoi de sa requête. Le problème est alors pour le demandeur de récupérer les résultats, ce qui peut être fait de plusieurs manières. Par exemple, le fournisseur peut informer le demandeur, par un évènement asynchrone, que les résultats sont disponibles ; ou le demandeur peut appeler le fournisseur a un moment ultérieur pour voir l'état de l'exécution.

Comme son nom l'indique, une communication synchrone désigne une liaison doublée d'un processus visant à synchroniser deux systèmes en présence, leur base de données métier respective par exemple. A l'inverse, les flux asynchrones mettent en oeuvre des échanges qui ne dépendent pas de l'état des applications impliquées. Ils sont exécutés à intervalles variables selon les ressources disponibles, en utilisant des références temporelles différentes.

C'est comme les appels téléphoniques avec les opérateurs mobiles où l'appelé doit être joignable ou disponiblepour se communiquer sinon il n'y aura pas communication.

I.6.2 Les middlewares asynchrones

Comparable avec le cas des sms ou de chat avec les réseaux sociaux, même-si le récepteur n'est pas disponible cela n'empêche pas à l'émetteur d'envoyer son message car le message sera envoyé et restera dans la file d'attente jusqu'à ce que le récepteur soit joignable pour le recevoir

Une forme de communication plus élaborée est le passage asynchrone de messages persistants. Un message est un bloc d'information qui est transmis d'un émetteur à un récepteur. Cette émission est non bloquante (l'émetteur continu son travail).

L'attribut < persistant > signifie que le système de communication assure un rôle de tampon : si le récepteur attend le message, le système de communication le lui délivre ; sinon, le message reste disponible pour une lecture ultérieure.

Grâce à cette caractéristique, les dispositifs asynchrones ont tendance à mieux gérer les goulets d'étranglement qui peuvent intervenir lors d'un problème d'accessibilité de l'environnement serveur. Par nature, le couplage applicatif qu'ils mettent en oeuvre est en effet plus lâche que pour les fonctions synchrones.

Ce qui leur permet de pallier les difficultés de disponibilité momentanées de manière plus efficace.

I.7ARCHITECTURES DE MIDDLEWARE

I.8 TYPES DE MIDDLEWARE

I.8.1 Middleware orienté accès aux données

I.8.2 Middleware orienté transaction (Le MOT)

Il est à préciser que l'on appelle transaction ou unité de travail. C'est une suite d'action qui change l'état de manière contrôlé. Il n'y a pas de demi-mesure, soit le travail a été effectué soit non. Si pour une raison quelconque la transaction n'a pu se terminer, on replace le système dans son état de départ.

Une transaction a un début et une fin que l'on doit obligatoirement atteindre pour que les modifications soient validées. Une transaction possède 4 attributs principaux:

1. Atomicité: c'est une unité de travail indivisible. Soit toutes les opérations sont jouées, soit aucune ;

2. Cohérence: tout système qui subit une transaction passe d'un état cohérent à un nouvel état cohérent. Si ce nouvel état ne peut être atteint, le système retourne à son état initial (rollback) ;

3. Isolation: les transactions s'exécutent simultanément mais de façon isolée, sans interfaces entre elles ni connaissances des états intermédiaires ;

4. Durabilité: Suite à une transaction, ses effets sur les données sont persistants.

Un MOT est un environnement réparti qui prend en charge l'exécution d'une application et la vérification de son bon fonctionnement en intégrant des mécanismes transactionnels. En plus des aspects purement transactionnels, ils offrent un outil de gestion optimisé et partagé des ressources, un outil de communication et un outil d'administration et de supervision.

Les MOT permettent au programmeur de ne pas s'occuper des problèmes de simultanéités d'accès, de défaillance du système, de ruptures de connexions. Ils fournissent le moteur pour faire tourner les applications au-dessus des OS et du matériel. Ils assurent une cohérence transactionnelles et facilite le découpage des applications en services.

Il existe différents moniteurs transactionnels comme Tuxedo de BEA ou CIS d'IBM

· Transaction invalide, si au moins une des opérations n'a pas pu être achevée.

· Portabilité réduite (pas de standard pour la définition des services sur les serveurs de composants).

I.8.3 Middleware orienté objet (Le MOO)

Pour permettre à différentes applications de communiquer entre elles, il faut des règles et des formats communs d'appels de services pour permettre aux différents objets de communiquer entre eux car les composants peuvent être de natures différentes. Tout d'abord ils peuvent être sur des machines différentes ayant des OS différents. Ils peuvent aussi avoir été conçus dans des langages différents.

Il existe trois modèles de composants objets qui sont complémentaires et interopérable. Il s'agit du modèle CORBA, des composant Java EJB et enfin de DCOM de Microsoft.

Ø Gestion d'applications distribuées : Une fonction est sur une machine et collabore au sein de l'application avec une fonction sur une autre machine ;

Ø Points forts (Fiabilité ;Capacité d'intégrer les messages et les transactions)

I.8.4 Middleware orienté message (MOM)

I.8.4.1 Définition

Les middlewares orienté messages sont des outils permettant aux applications d'interagir en échangeant des messages de manières asynchrone et fiable.

On l'a vu, les MOMs sont des middlewares, des outils d'échange qui permettent à des applications de communiquer en échangeant des messages. Une application « A » doit adresser un message à une application « B », qui tourne (peut-être) sur un serveur différent.

I.8.4.2 Descriptions

L'application « A » confie son message au MOM, qui se charge de l'acheminer et de le remettre à l'application « B ».L'objet véhiculé par le MOM entre deux applications est appelé message.Mais rien n'est imposé quant à ce que représente ce message, sa taille, ou encore le format des données qu'il véhicule.

Pour l'essentiel, ces questions ne concernent que l'application « A » et l'application « B », qui doivent partager un certain nombre de conventions, afin de se comprendre.

Le MOM, quant à lui, ne s'intéresse donc pas au contenu du message, il ne fait que le transmettre, et il le remet au destinataire sans y avoir apporté de changement.

I.8.4.3 Différences

À la différence d'un MOM, un outil d'EAI (Enterprise Application Integration), est aussi en charge de réaliser transformations sur lesinformations portées par les messages, afin d'adapter les données del'émetteur aux formats gérés par le destinataire.

Un EAI englobe donc les fonctionnalités du MOM, et y ajoute des possibilités facilitant l'intégration des applications au niveau des données transférées.

Dans un MOM, comme on l'a vu, les applications doivent parler le même langage, tandis qu'un EAI au contraire prend en charge les traductionsentre représentations différentes.

L'ESB, Enterprise Service Bus, est un concept plus ambitieux encore, qui se présente comme le socle uniforme d'une architecture SOA globale. Là où l'EAI peut prendre en charge des transformations de formats permettant à une application A d'interopérer avec une application B.L'ESB généralise le concept, en posant pour principe qu'il suffit qu'uneapplication A soit interfacée à l'ESB pour qu'elle puisse interopérer par son intermédiaire avec toute autre application interfacée à l'ESB.

Et par ailleurs, la connexion à l'ESB n'est pas exclusivement à base de messages, elle doit supporter une grande diversité de modes d'échange et de protocoles.

Puisque nous évoquons quelques acronymes en vogue, il faut parler aussi du concept EDA, « Event-Driven Architecture », architecture pilotée par les événements, qui est à certains égards une alternative à l'approche SOA.

L'approche EDA part de l'idée que tout traitement est d'une certaine manière exécuté en réaction à un événement. Et bien sûr, tout traitement est par ailleurs générateur d'événements.

Ainsi, la vente d'un produit est un événement, qui induit un ensemble de traitements relatifs par exemple à la gestion des stocks, à la comptabilité, à la logistique, à la relation client, etc. Tout est événement, tout est réaction à des événements, et il en va de même pour nous-mêmes, êtres humains, qui agissent en réaction à un ensemble de stimuli externes.

Dans l'approche EDA, la réaction à un événement n'est pas un traitement synchrone. Elle peut avoir des exigences de rapidité, mais elle est par essence asynchrone. Alors que l'approche SOA, même si elle peut se décliner dans une logique asynchrone, est malgré tout par essence une approche synchrone. Et bien sûr, les MOMs sont le support naturel d'une approche EDA.

Un dernier acronyme à trois lettres pour la route: CEP, pour « Complex Event Processing », traitement d'événements complexes, consiste àidentifier, puis traiter, des événements complexes à partir d'unecombinaison d'événements simples. C'est donc un conceptcomplémentaire à l'approche EDA, partant du principe qu'il ne suffit pasde réagir à des événements individuels, il faut être en mesure d'identifierdes événements de plus haut niveau, comme résultante d'événementsélémentaires. Par exemple: un ordre de vente, plus un autre ordre devente, plus encore un ordre de vente... égal une crise financière,événement complexe, s'il en est.

I.8.4.4 Des échanges asynchrones

Les échanges de messages mis en oeuvre par les MOMs sont asynchrones. Cela signifie que les applications ne sont pas en attente d'une réponse à leur message. En fait, il est possible qu'un message de réponse soit attendu, mais dans ce cas il n'y a pas de délai garanti pour cette réponse, de sorte que l'application ne doit pas se bloquer en attente de la réponse, et encore moins faire attendre un utilisateur. Le caractère asynchrone ne dit rien quant au délai d'acheminement du message : il peut être très rapide, de quelques millisecondes à peine, mais il ne doit pas être considéré comme assuré.

I.8.4.5 Des échanges fiables

L'une des qualités attendues des MOMs est de garantir l'acheminement des messages quelles que soient les circonstances, les aléas, et en particulier y compris dans le cas où la connectivité réseau est interrompue, où le serveur distant est arrêté, ou bien où l'application destinatrice n'est pas en mesure de réceptionner les messages. Dans tous ces cas de figure, le MOM doit conserver les messages qui lui sont confiés jusqu'à ce qu'ils aient été remis, et même, jusqu'à ce qu'ils aient été correctement traités par l'application destinatrice.

Nous verrons que cette fiabilité de l'acheminement peut être rendue plus ou moins forte, selon les paramètres et la configuration du MOM.

Les échanges à base de MOM ne sont pas, par nature, en mode requête / réponse, comme peut l'être un échange HTTP par exemple. Il estpossible bien sûr que l'application destinatrice émette à son tour unmessage, que l'on peut considérer comme une réponse, mais il s'agitalors seulement d'une utilisation particulière du MOM.

I.8.4.6 Brokers

Les brokers sont des programmes gérant le flux de messages. En d'autres termes, un MOM est composé d'un ou de plusieurs brokers. Comme le montre la figure suivante, c'est avec les brokers que les applications clientes communiquent, au travers de l'API.

Un broker est un serveur au sens logiciel du terme, c'est-à-dire un processus qui est à l'écoute des requêtes qui peuvent lui être adressées par d'autres processus, les applications clientes.

Une plateforme MOM ou plateforme middleware est donc constitué d'un ensemble des brokers et des passerelles.

I.8.4.7 Protocoles et APIs

Lorsqu'une application échange avec un broker, par exemple pour lui remettre un message, et de même lorsqu'un broker échange avec un autre broker, ces échanges mettent en oeuvre un protocole réseau. Le protocole définit les commandes invoquées et leurs paramètres, ainsi que la représentation des données, entêtes et corps, constituant les messages.

Figure I.7 Architecture protocole et API

Ce protocole est généralement invisible pour les applications, qui ne voient que des appels de fonctions, des APIs. Et de même, pour ce qui est des échanges entre deux brokers d'un même MOM, le protocole peut être considéré comme une affaire privée, interne, relevant purement de l'implémentation du MOM. C'est pourquoi on s'intéresse généralement davantage à l'ouverture des MOMs en termes d'APIs qu'en termes de protocoles d'échange.

Ø Points forts (Tolérance de panne ; Idéal pour la communication de groupes) ;

Ø Points faibles (Le même message pourra être délivré plusieurs fois ; L'extensibilité et l'hétérogénéité sont limitées ; Ne supporte pas les propriétés des transactions (ACID)).

I.9 SORTES DE MIDDLEWARE

I.9.1 Les middlewares payants

1. DCOM

Microsoft DCOM est souvent appelé «COM on the wire». Il supporte les objets distants en exécutant un protocole appelé ORPC (Object RemoteProcedure Call).

Un client DCOM appelle les méthodes exposées d'un serveur DCOM en acquérant un pointeur sur l'une des interfaces de l'objet serveur. L'objet client commence ensuite à appeler les méthodes exposées de l'objet serveur via le pointeur d'interface acquis, comme si l'objet serveur résidait dans l'espace adresse du client.

Comme la spécification COM est au niveau binaire, les composants du serveur DCOM peuvent être écrits dans divers langages de programmation tels que C++, Java, Object Pascal (Delphi), Visual Basic et même COBOL. Tant qu'une plateforme prend en charge les services COM, DCOM peut être implémenté sur la plate-forme. Cependant, il n'est pratiquement pas disponible sauf les systèmes Windows.

2. RMI

Sun Java RMI est un ORB natif intégré en langage Java. Il prend en charge les invocations de méthodes sur des objets distants. Du point de vue de la programmation pratique, le développement d'applications distribuées en RMI est plus simple que le développement avec des sockets, car il n'est pas nécessaire de concevoir un protocole, qui est une tâche sujette aux erreurs.

Dans RMI, le développeur a l'illusion d'appeler une méthode locale à partir d'un fichier de classe local, alors que les arguments sont envoyés à la cible distante et interprétés, et les résultats sont renvoyés aux appelants.

3. EntireX

Un logiciel middleware pour grands systèmes, Unix et NT. Cette version permet désormais la communication entre des applications XML et non XML et également entre les applications Corba et non Corba. EntireX est compatible avec les plates-formes.

I.9.2 Les middlewares open sources

1. Java Open ReliableAsynchronous Messaging (ou JORAM)

Object Web est aussi connu pour son serveur d'application Java nommé Jonas auquel est d'ailleurs intégré JORAM. JORAM est sortie en 1999 et est distribué sous licence LGPL depuisMai 2000.

Figure I.8:Architecture JORAM

JORAM a une architecture interne élégante, basée sur le modèle d'agent.Un agent est un composant logiciel répondant à certains événements. Dans le cas de JORAM, les événements sont sous forme de messages.Les queues et les topics sont ainsi représentés par des agents.

Un utilisateur connecté à la plateforme est également représenté par un agent dit proxy. Cette approche offre une grande flexibilité, car elle permet la création et la suppression d'agents à la volée et sur n'importe quel broker. Un broker est donc uniquement un serveur d'agent (ouun container d'agent). À l'instar des EJB, ces agents ne peuvent pas encore être déplacés de broker en broker.

Le code source récupéré du SVN JORAM est assez bien documenté. Il est fait de « beans» séparés en Interfaces et Implémentations. Dansl'ensemble, le code respecte les bonnes pratiques de développement Java.

Ø C et C++ : À l'aide de JNI, permettant ainsi de simuler un environnement JMS.

Le protocole interne de JORAM est propriétaire, et n'est pas documenté. Nous estimons que c'est un handicap dans la mesure où cela tend à limiter le nombre d'environnements dans lesquels des APIs sont offertes, et à rendre plus difficiles les interconnexions. Joram le désigne simplement par « TCP », mais il est évident qu'il y a un protocole, non spécifié, au-dessus de TCP/IP.

JORAM met à disposition des passerelles permettant d'étendre le nombre de protocoles gérés tout en se basant sur le protocole dit

Ø Passerelle SOAP (grâce à un serveur d'application) : Permet la communication en SOAP avec le broker, donc en principe depuis des environnements autres que Java.

Ø Passerelle Mail : Cette passerelle permet d'envoyer et de recevoir des messages JMS en s'appuyant sur du SMTP (Protocole de mail). Pour cela JORAM utilise des queues et topics spécifiques. Cette passerelle est réalisée en Java.

Ø Passerelle FTP : JORAM réserve des queues spécifiques pour les canaux FTP. Cette passerelle fonctionne sur le même principe que la passerelle Mail. Elle est destinée à l'échange de messages volumineux. Cette passerelle est réalisée en Java.

Ø Gestion des messages JORAM prend en charge le JMS 1.1 et est compatible avec JMS 1.0.2b. JORAM a aussi implémenté une interface JMS 1.1 destinée, au Framework J2ME, la version de l'environnement Java destinée aux mobiles, téléphones et PDAs. JORAM peut donc être mis en oeuvre à partir de terminaux mobiles compatibles Java.

JORAM prend aussi en charge JCA 1.5, lui permettant de se connecter aux différents PGI du marché (Open ERP, ...) qui le gèrent.

JORAM supporte l'interface d'administration JMX. Il est intégrable et configurable en Java. Il supporte aussi le JAAS pourl'authentification et les habilitations.

La notion de hiérarchie des topics : Chaque topic peut être lié à un autre (et un seul) et recevoir tous ses messages. À son tour, le parent topic reçoit tous les messages de ces parents et les envoie à tous ses topics fils. Il n'est pas possible de faire de traitement avec JORAM.

La persistance peut être gérée sur le système de fichier, dans une base java embarquée (Derby, voir plus loin pour plus de détail), ou sur une base de données relationnelle externe via JDBC.

Derby est un système de gestion de base de données relationnelle embarquée. « Embarquée » veut simplement dire qu'il n'est pas nécessaire d'avoir un serveur de base de données, au sens d'un processus distinct.

La base de données est dans le même processus que l'application. Le support de stockage de la base Derby est le fichier. Derby est une méthode avancée de lecture et d'écriture sur des fichiers.Nous n'avons pas trouvé, dans les documentations fournies par JORAM, d'information sur les optimisations possibles de la gestion de la persistance.

Comme on l'a évoqué, JORAM est construit selon une architecture à base d'agents. Cette architecture est l'objet d'un livre blanc disponiblesur le site du produit.

Ø La disponibilité : pour rappel, la défaillance d'un serveur n'affecte que les clients JMS connectés à ce serveur. Les autres continuent à fonctionner en accédant à d'autres copies du domaine. La synchronisation des domaines se fait d'une manière transparente, selon un principe maître-esclave.

Ø Répartition de charge : les applications clientes sont réparties sur plusieurs serveurs de telle sorte que la charge engendrée par la gestion des domaines soit répartie entre les serveurs. Cette répartition peut soit être réalisée manuellement (configuration et utilisation du « Store and Forward »), soit être confiée à un load-balancer.

Des fichiers de configuration au format XML sont utilisés pour définir la configuration de sécurité. Il est possible également de personnaliser la gestion de la sécurité au travers JAAS.

JORAM met à disposition une interface graphique d'administration. Elle se base sur l'utilisation de JMX.

2. ActiveMQ

Sorti en 2004, ActiveMQ est le MOM open source de la fondation Apache. Il est distribué sous licence Apache 2.0.

Ø Apache Camel : Implémentation partielle des « Entreprise Integration Patterns », que nous avons évoqués plus haut.

Ø ESB : Active MQ est utilisé par plusieurs ESBs (Enterprise Service Bus) tels qu'Apache Service Mix et Mule.

Ø Serveur J2EE : Active MQ est intégré au serveur d'application Geronimo (certifié JEE5) comme fournisseur JMS par défaut.

Le code source récupéré du SVN, ne semble pas toujours être d'une qualité exemplaire. La mise en forme du code laisse à désirer et certaines parties ne respectent pas les bonnes pratiques de codage Java : peu d'interfaces, classes et méthodes trop longues, ... Mais la robustesse du produit est néanmoins réputée.

La diversité des langages et environnements supportés est particulièrement grande, et c'est un des grands atouts de Active MQ.

Comme on l'a évoqué, l'aptitude à faire échanger des applications hétérogènes fait partie des missions naturelles d'un middleware.

Ø C++ : grâce à CMS : C'est une bibliothèque C / C++ proposant des interfaces similaires à JMS ;

Ø Ajax, RESTful et SOAP : sous condition d'utilisation des passerelles proposées par Active MQ. (La passerelle est sous forme d'un servlet Java, fonctionnant sur Jetty, ou autre) ;

Ø .Net : grâce à NMS : C'est une bibliothèque .Net proposant des interfaces similaires à JMS ;

Ø Perl, PHP, Pike, Python, Ruby, grâce au protocole STOMP et aux librairies client correspondantes.

On voit que le choix du duo STOMP et OpenWire comme protocole de communication a ouvert la voie à l'implémentation d'APIs dans de nombreux environnements.

De plus, s'agissant de protocoles ouverts et bien spécifiés, il est possible de réaliser un client STOMP vers ActiveMQ depuis de nouveaux environnements s'il en manquait à la liste.

Ø AMQP : Ce protocole est pris en charge,e mais comme sa définition est volatile, Active MQ prend en charge uniquement les versions 0.8 / 0.9 ;

Ø JXTA : C'est un protocole permettant de créer des réseaux au-dessus des réseaux. JXTA (pour juxtapose), défini par une série de protocoles légers conçus pour gérer n'importe quelle application peer-to-peer. JXTA est compatible avec l'ensemble des plateformes informatiques. L'implémentation Java est basée sur du XML. Avec Active MQ, il agit en tant que connecteur ;

Ø XMPP : Le protocole de messagerie instantanée utilisé par Jabber. Ainsi, on peut se connecter au MOM grâce à un client de messagerie de type Jabber ;

Mis à part la gestion standard des messages imposée par la spécification JMS 1.1, Active MQ gère :

Ø Groupe de messages : Ceci est un concept intéressant dans la mesure où il assure que tous les messages d'un même groupe soient reçus par un consommateur déterminé. Les messages d'un groupe X seront consommés uniquement par le consommateur privilégié. Si celui-ci meurt, Active MQ choisit automatiquement un autre consommateur suivant la configuration.

Ø Notion de sélecteur de messages compatible avec XPATH (et SQL 92 issue de la spécification JMS).

Ø Cependant, il n'y a pas de notion de priorité des messages. Il est possible de la simuler en utilisant des groupes de messages ou bien des sélecteurs.

Ø Destination virtuelle : Il est possible de définir des topics et des queues redirigeant vers des composants du même domaine (topic vers topic et queue vers queue).

Ø « Total Ordering» : Active MQ a la possibilité d'assurer que l'ordre de réception des messages correspond bien à l'ordre d'envoi.

Le traitement des messages d'Active MQ est sans doute son plus célèbre atout, après celui de sa grande connectivité. À l'aide du projet Camel qui est intégré, il a la possibilité de traiter les messages selon les modèles d'intégration d'entreprises (EIP).

Citons un exemple faisant d'Active MQ un EAI à part entière. Les fonctionnalités de routage et de transformation représentent les caractéristiques principales des EAIs.

Bien qu'il n'existe pas de documentation sur la méthode de gestion des transactions en interne, ActiveMQ nous donne quelques pistes.

Par exemple, la journalisation du « Message Store » permet la reprise sur incident sans perte de données lors d'un « rollback» (retour arrière).

Attention, par défaut, le routage et la transformation des messages ne sont pas transactionnels. Une « Dead Message Queue » est présente.

Active MQ a introduit un mode de persistance appelé « Active MQ Message Store » qui joint un stockage de données sous forme de fichiers avec un système de journalisation et de mise en cache. Il affiche des performances supérieures au système de persistance sur fichier ou base de données seule. Il affiche aussi une meilleure fiabilité, car il a été bâti pour le transactionnel.

Regardons de plus près son fonctionnement.Lors de l'écriture d'une donnée, le message réside en cache (Mémoire volatile). On construit sa référence (identification) qui sera stockée dans le journal des références. Périodiquement, une copie du journal des références caché est réalisée sur le support persistant. Ceci représente le journal des références persistant. De plus, si la donnée n'a pas été consultée depuis longtemps (configurable), elle est déplacée vers média persistant (d'une façon transactionnelle) et ses références sont mises à jour (cache et persistant).

Lors d'une lecture, on accède soit directement à la donnée en cache, soit dans le média de stockage.Lors d'une transaction, Active MQ ne modifie que les références des messages.Active MQ recommande d'avoir un nombre de messages inférieur à 1 million par page de cache. Le nombre de page de cache n'est pas limité.

Active MQ fournit une passerelle JMS aisément configurable (DSL, Spring XML). L'authentification est aussi prise en compte par les fichiers de configuration. Ces fichiers de configuration peuvent être intégrés à ceux d'Active MQ.

L'authentification et la gestion des droits sont intégrées sous forme de plugins dans Active MQ. Les plugins proposés par défaut s'appuient sur JAAS ou sur des fichiers XML.L'interconnexion entre brokers peut aussi être sécurisée par mot de passe et / ou chiffrement (SSL). Il est possible d'encapsuler les connexions dans du SSL entre les clients et un broker pour sécuriser les échanges. Le SSL se comporte donc comme un connecteur à part entière.Il possible de lier la sécurité de la plateforme avec un serveur LDAP.

Active MQ fournit une interface de personnalisation via des «Interceptors». Il est un ainsi possible d'étendre les possibilités de Active MQ très facilement.

L'exemple le plus commun serait la gestion de l'authentification. Les «Interceptors» permettent de modifier certains comportements internes sans changer le coeur d'Active MQ et en compatibilité avec les versions futures.

Ø par des messages : cette fonctionnalité est aussi disponible à distance via le protocole XMPP (Voir le Glossaire).

Active MQ propose des « Advisory Message » (message d'information) qui permettent de connaître l'état du système. Voici des exemples de métriques :

Les « Advisory Messages » sont organisés en queues et topics protégés par mot de passe. On peut y accéder à partir d'un simple client Active MQ (JMS ou autre).

Active MQ implémente aussi des « Mirrored Queues » : les messages envoyés à une file d'attente seront, de manière transparente, envoyés sur un Topic. Même si cette fonctionnalité est à utiliser avec précaution, elle permet à un ou plusieurs clients de suivre l'état d'une file d'attente. C'est l'application du design «WireTap» (les écoutes téléphoniques pratiquées par les espions) d'EIP.

Cette interface est démarrée par défaut à l'aide de Jetty. Elle démarre par défaut à l'adresse suivante : HTTP://0.0.0.0:8161/admin

Active MQ peut être installé sur n'importe quelle plateforme supportant au minimum Java 5.

Ø Active MQ est configurable en utilisant des fichiers XML intégrables à Spring.

Ø Active MQ peut aussi être configuré et lancé à partir d'un autre programme (Java), c'est la notion de « Embedded Broker » : le broker n'est plus un processus indépendant auquel le programme s'adresse par le réseau, il tourne dans le même processus que le programme client.

Active MQ est livré avec un ensemble d'exemples codés en Java ou en Ruby. Tous les cas d'utilisation d'Active MQ ne sont pas couverts par la trentaine d'exemples fournis.

3. MOM Open Message Queue (OMQ)

OMQ est le Middleware Orienté Message de Sun. Il a été développé pour fonctionner conjointement avec GlassFish (Open ESB). Le principal contributeur est la communauté Sun / Java.

OMQ a été réalisé pour fonctionner avec GlassFish, le serveur d'application de Sun. Cependant, OMQ peut facilement fonctionner tout seul ou avec d'autres types de serveur d'application Java.OMQ est distribué sous deux licences : CDDL ou GPL v2.

Les sources, récupérables du site Internet de la solution sont mal organisées. D'une part, on constate la présence de binaires, de fichiers C et autres. De plus, il n'y a pas de système de compilation automatique du type MAVEN ou ANT.

· UMS comme Universal Messaging System : C'est un protocole de communication comparable à AMQP. Sun ne le met guère en avant, étant données ses limitations en termes fonctionnalités et de performance. UMS est basé sur du XML, ce qui alourdit un peu les échanges.

OMQ ne gère pas la priorité des messages ; OMQ gère la compression et la décompression des messages à la volée.Pour finir avec la gestion des messages, OMQ gère la validation des contenus XML : « XML Schema Validation ».

Ø Traitement des messages (Le traitement des messages n'est pas pris en compte par OMQ).

La gestion de transaction est offerte à la fois à partir du C et du Java. OMQ propose aussi des interfaces du type XA / JTA.

Il est possible de réaliser de la persistance sur le système de fichier. La persistance est aussi disponible dans des bases de données telles que : Oracle, MySQL, PostgresSQL, Java DB (Derby), toutes accédées via JDBC.

Sun ne fournit aucun bridge JMS ou autre. Il est ainsi à notre charge d'en créer ou d'en adapter un (open source) à nos besoins.

OMQ support SSL / TLS comme mode d'encryptions des messages. Celui-ci peut se placer aussi bien entres applications et brokers qu'inter-brokers.

Les applications clientes (consommatrices ou productrices) peuvent se connecter grâce à un couple (nom d'utilisateur, mot de passe). Les mots de passe sont encodés à l'aide de l'algorithme MD5.

OMQ gère les groupes d'utilisateurs. On peut personnaliser les accès aux éléments des brokers (queues, topics, administration, monitoring) par utilisateurs ou par groupes.

OMQ fournit aussi des outils d'administration en ligne de commande permettant, à l'aide de scripts (shell ou autres), d'automatiser certaines tâches. A titre d'exemple, « imqadmin » et « imqcmd » permettent de gérer un parc de brokers, de recharger une nouvelle configuration, ... Ces outils se montrent ainsi particulièrement utiles.

Un monitoring du middleware est possible par messages. Il suit les mêmes concepts que les « Advisory Messages » d'Active MQ. La plateforme OMQ implémente JMX.

OMQ est réalisé en Java. Voici la liste des systèmes d'exploitation dont Sun annonce le support :

Toujours selon Sun, OMQ peut aussi bien tourner sous une architecture Sparc que x86. Il requiert un minimum de 256 Mo de RAM, mais Sun recommande 2 Go de Ram pour de la HA ou pour de gros volumes de messages.

Lors du téléchargement du paquet du site de Sun, on remarque la présence d'un installateur graphique.

En ce qui concerne les exemples, ils sont au nombre de 41, illustrant : JMS, JMX, le monitoring, et SOAP. On constate aussi la présence d'une dizaine d'exemples montrant l'utilisation de l'API C. Les exemples se limitent à l'utilisation des services de messageries et de monitoring d'OMQ. Dommage qu'aucun exemple ne montre la mise en place d'une plateforme en cluster ou high-availability (haute disponibilité).

I.10 INTERGICIELS DANS L'ENVIRONNEMENT INDUSTRIEL

I.10.1 Industrie électronique

Un intergiciel pour étiquettes électroniques est un logiciel tiers destiné à simplifier l'accès et l'exploitation des informations stockées dans des étiquettes RFID issues de l'industrie électronique.

Les étiquettes électroniques sont le plus souvent utilisées pour des besoins de marquage et de traçabilité d'objets (suivi de palettes, de livres, de chaînes de montage de voitures, sous la forme d'étiquettes électroniques de gondole dans les grandes surfaces...) aussi bien que d'êtres vivants (élevage, suivi d'animaux sauvages, ou encore suivi de la chaine du froid). La conception et le développement de nouveaux logiciels pour ces applications et pour bien d'autres (monétique, authentification...) s'avèrent néanmoins souvent délicat.

L'intégration, au sein des systèmes d'information, des informations stockées dans la mémoire des étiquettes électroniques est entravé par des difficultés techniques liées à l'organisation de leurs collectes mais aussi de leur filtrage.

C'est à cette fin que sont conçus les intergiciels pour étiquettes électroniques. Ils ont pour ambitions de :

2. traiter les données issues des lecteurs (formatage, agrégation, filtrage) ;

4. Notifier les événements significatifs survenus dans l'infrastructure (apparition de nouvelles étiquettes, retraits de lecteurs...).

Une entreprise produit des biens dans une usine (U). Ces produits sont marqués d'une étiquette RFID et son acheminés chez un transporteur (T). Ce transporteur regroupe les produits par palette, et appose une étiquette électronique sur chaque palette. Enfin, ces produits sont livrés chez un distributeur (D) qui les stocke à l'arrière de la boutique. Chacun des intermédiaires U, T et D possède un système d'information qui lui est propre.

L'usine possède donc les informations sur les familles de produits, le transporteur les associations palettes/produits, et le distributeur l'association entre un identifiant et une famille de produit. Il peut ainsi faire l'inventaire de ses stocks quasi-instantanément. Il faut donc rendre communes et accessibles aux 3 entités les données locales de chacune afin de rendre efficace le système d'information.

Il existe aujourd'hui différents intergiciels assumant tout ou partie de ces fonctions, dont certains sont des logiciels libres.

WinRFID est un intergiciel développés en Microsoft .NET WinRFIDa cinq couches principales :

· Vient la couche informatique, qui traite les données produites par le réseau du lecteur ;

· Puis une couche constitue le cadre de XML pour la représentation de données et d'information ;

· Enfin la couche supérieure traite la présentation de données selon les conditions des utilisateurs ou des différentes applications d'entreprise ;

La couche matériel traite l'abstraction de trois éléments de l'infrastructure de RFID - lecteurs, étiquettes et interfaces d'entrée-sortie. L'abstraction rend très simple de dériver n'importe quel lecteur ou d'étiquette.

Le composant protocole permet d'envelopper la syntaxe de commande et la sémantique d'une série de protocoles édités tels qu'ISO 15693, ISO 14443, A/B d'ISO 18000-6, ICode, EPC classe 0 et EPC classe 1.

La couche présentation des données facilite la visualisation de données pour la prise de décision.

Le middleware RFID IBM Websphere est composé de trois éléments : l'infrastructure dispositif RFID Websphere (WRDI). Qui permet de déployer entre autres les contrôleurs, les lecteurs et les imprimantes RFID. Tous ces appareils étant pilotés par le WRDI. Le WRDI permet également de filtrer et agréger les données RFID en éliminant les doublons et en identifiant les événements RFID pour minimiser le trafic sur le réseau.

Le serveur RFID Premises WebSphere permet un déploiement de la RFID en entrepôt, dans des centres de distribution ou des ateliers. C'est une plate-forme applicative J2EE permettant d'intégrer les événements RFID provenant des différents capteurs mis en place dans l'entreprise dans les processus métier. le logiciel IBM WebSphere Business Integration ne fait pas à proprement partie du middleware mais peut-être considéré comme la partie émergée de l'iceberg puisqu'il permet l'intégration des processus RFID dans les applications métier de l'entreprise.

Le projet d'AspireRFID vise à développer et promouvoir un middleware open-source, léger, conforme aux standards, évolutif et intégré avec plusieurs outils pour faciliter le développement, le déploiement et la gestion des applications basées sur RFID et sur les capteurs. Il met en oeuvre plusieurs spécifications des consortiums comme EPC Global, NFC Forum, JCP et OSGiAlliance. AspireRFID, fournit aussi un ensemble d'outils permettant aux consultants RFID de déployer des solutions RFID sans avoir besoin de la programmation ennuyeuse à bas niveau. AspireRFID permet les spécifications des processus permis par RFID.

En conséquence, les outils produisent tous les objets RFID exigés pour déployer ces solutions sur l'AspireRfidmiddleware.

· D'une couche d'abstraction de matériel, dont le rôle est d'unifier la façon dont l'intergiciel ASPIRE agit avec les lecteurs RFID des différents fournisseurs qui supportent lesdifférents protocoles ;

· La couche "Reader Core Proxy" qui permet de transformer un lecteur non conforme à la norme EPC en un lecteur conforme ;

· Une couche "Serveur de Filtrage et de Collection" qui permet d'btenir uniquement les données utile à l'application.

Fosstrak est une plate-forme logicielle open-source RFID qui met en application les caractéristiques de réseau d'EPC. En outre, AspireRFID utilise Fosstrak. Fosstrak possède :

· un client autonome et WEB afin de pouvoir configurer les serveurs de filtrage.

· RFID Gateway possède une architecture modulaire pour une mise en oeuvre progressive, possédant une capacité d'extension. Il est basé sur une architecture JAVA et ainsi compatible avec tout environnement JAVA sous Windows / Unix ;

· RFID GateWay permet également une intégration rapide avec les applications d'entreprise

I.10.2 Industrie du jeu vidéo

La production d'un jeu vidéo comprend plusieurs étapes et nécessite un lourd travail de programmation à plusieurs niveaux. Plutôt que de concevoir leurs propres solutions logicielles, certains studios de développement peuvent recourir à des technologies logicielles qui leur permettent de diminuer leurs délais de production.

Cet ensemble de technologies comprend des engins (gameengines), des intergiciels, qui sont soit des solutions logicielles franchisées produites par des entreprises tierces et des outils logiciels spécifiques (Maya, 3D Max), soit des suites logiciels standardisées utilisées par les graphistes, les ingénieurs du son, etc.

Les intergiciels de jeux vidéo sont pour l'instant peu étudiés. Il nous apparaît alors d'autant plus intéressant de comprendre cette industrie de l'intergiciel et son rôle dans la filière de production d'un jeu vidéo.

Game middlewaresont des logiciels qui permettent d'automatiser des suites de tâches de programmation nécessaires à la production des jeux vidéo. Les intergiciels et les engins peuvent plus précisément viser la gestion de l'intelligence artificielle (la manière dont le jeu réagit aux actions du joueur), le graphisme, les processus de texturage, l'animation ou encore le design de personnages. Ils vont être destinés à certains types de jeux, chaque genre de jeux nécessitant des technologies logicielles ad hoc consacrées à en gérer les caractères particuliers.

Il existe des engins spécialisés dans les jeux d'aventure, dans les jeux de tir à la première personne (FPS) ou encore dans les jeux en ligne massivement multi-joueurs(MMO).

Ces engins sont conçus par les gros éditeurs ou par des sociétés spécialisées et sont repris et modifiés par des studios de développement de jeux (franchise) ou par des communautés de développeurs si le code de l'engin ou du middleware est ouvert.

Si tel est le cas, le code peut être modifié par des communautés de développeurs extérieurs à l'industrie. Ainsi, le jeu de tir à la première personne Half Life sorti à la fin des années 1990 comprenait un engin dont le code a été ouvert et retravaillé par une communauté de développeurs pour mener à la production d'un nouveau jeu de tir à la première personne, distribué en ligne et qui a remporté un large succès auprès de la communauté des joueurs.

Il existe même à l'intention de ces communautés des sites répertoriant des solutions intergicielles pour les développeurs. Il y a donc une circulation des outils logiciels entre les sociétés spécialisées dans la production d'intergiciels, les studios de développement de jeux vidéo et les communautés de développeurs qui retravaillent le code d'engins ou d'intergiciels existants pour y rajouter des fonctionnalités.

Les engins et les intergiciels peuvent renvoyer au même type de logiciel, lanuance étant que les outils logiciels conçus à l'externe sont considérés comme des intergiciels, tandis que les solutions logicielles conçues à l'interne et qui sont propres à une entreprise ou à un jeu sont des engins. Les engins peuvent donc par la suite devenir des intergiciels s'ils sont revendus à des sociétés tierces. La catégorisation dépend donc du contexte de circulation de la technologie logicielle, qui devient tour à tour engin ou intergiciel. Il existe aussi des solutions intermédiaires : un engin acquis en franchise auprès d'une société par un studio de développement peut faire l'objet d'une personnalisation aux fins d'un jeu spécialement conçu par le studio en question. Par exemple, la série du jeu d'aventure SplinterCellconçue par Ubisoft utilisait l'engin Unreal développé par une société extérieure pour produire un autre jeu. Le marché des intergiciels dépend de l'adoption par les studios de développement d'outils logiciels externes et de la moindre production d'engins en interne. Ces technologies intergicielles sont particulièrement importantes pour les développeurs indépendants qui n'auraient pas les capacités financières de concevoir leurs propres technologies.

Le développement de ces technologies logicielles est fortement corrélé au développement des canaux de diffusion des jeux vidéo, via Internet notamment (Bowen et Deuze, 2009), ce qui entraîne une nouvelle demande pour la production rapide de nouveaux jeux vidéo.

L'offre intergicielle tend de ce fait à s'élargir. Certains packages d'intergiciels (middleware system) proposent toutes les fonctions de base d'un type de jeu, déclinées sous la forme de composants séparés -- par exemple la plateforme d'optimisation 3D Umbra Occlusion Booster (Mäkinen, 2009). Les fonctionnalités des intergiciels et des engins sont fortement dépendantes de l'évolution des matériels informatiques. Selon OtsoMäkinen, le directeur de la technologie de la société Umbra Software, les processeurs Intel ont joué sur l'écart promotionnel de son logiciel un rôle crucial dans le développement de nouveaux algorithmes et de nouveaux modèles de programmation pour la nouvelle génération d'intergiciels.

I.11 AVANTAGES ET INCONVENIENTS DU MIDDLEWARE

I.11.1 Avantages

Middleware est considéré comme un logiciel de connectivité, car il fonctionne à rejoindre applications grâce à la communication des mécanismes. Dans sa fonction, le middleware est l'interface entre les applications logicielles assistée et plates-formes d'applications, la création d'évolutivité, de transparence et d'interopérabilité. Logiciel middleware aide à la connectivité de base de données en fournissant un accès aux interfaces API de base de données.

L'avantage d'utiliser le middleware est la connectivité de base de données standard et simplifiée, le logiciel fournit des logiciels simplifiés.

I.11.2 Inconvénients

Toutefois, les inconvénients de ce type de middleware, RPC en particulier, notamment la réplication, les problèmes d'équilibrage de charge, d'évolutivité limitée et le faible niveau de tolérance aux pannes. L'absence de soutien direct dans divers domaines, les développeurs doivent faire face à ces aspects, l'ajout d'un niveau élevé de complexité des systèmes.

L'inconvénient des systèmes asynchrones est la tête de réseau et lent serveur de traitement de message. Autres inconvénients comprennent des limitations sur les plates-formes de support de protocole doivent avoir prouvé moins populaire. Chacun des produits middleware est conçu avec des différences inhérentes, ce qui rend difficile de choisir le vendeur. Programmeur Access Limited est l'un des principaux inconvénients.

RPC a une capacité de plate-forme, qui toutefois, les inconvénients de ce type de middlewarecomprennent la réplication, des problèmes d'équilibrage de charge, évolutivité limitée et une faible tolérance aux pannes. L'absence de soutien direct dans divers domaines exige des développeurs pour répondre à ces questions, l'ajout d'un niveau élevé de complexité des systèmes.

I.12CONCLUSION

Dans ce chapitre, nous nous sommes focalisés sur les conceptsde base des systèmes distribués les intergiciels (MOMs) en particulier. Nous avons donné en détail les caractéristiques des systèmes distribués, leurs architectures ainsi que les domaines concrets de leur application.

Le choix d'un MOM ; le choix du bon système MOM représente un investissement important et le risque de se tromper peut avoir un impact non négligeable sur votre avenir. Certains critères de sélection peuvent être utilisés pour choisir la perle rare des systèmes.

CHAPITRE II. ETAT DE L'ART SUR LES ERPs

II.1 INTRODUCTION

Dans ce chapitre, nous allons présenter un état de l'art sur le progiciel de gestion intégré en générale(ERP).

II.2 PRESENTATION GENERALE DES ERP

ERP vient de l'anglais (Enterprise Resource Planning). Littéralement, ERP signifie donc : (Planification des ressources de l'entreprise). On utilise parfois dans le monde francophone la dénomination PGI : (Progiciel de gestion intégré). Quoiqu'il en soit, un ERP a pour principale définition (Outil informatisé de pilotage de l'entreprise).

A l'aide de ce système unifié, les utilisateurs de différents métiers travaillent dans un environnement applicatif identique qui repose sur une base de données unique. Ce modèle permet d'assurer l'intégrité des données, la non-redondance de l'information, ainsi que la réduction des temps de traitement.

Ø En cas d'impact d'un module, l'information est mise à jour en temps réel dans l'ensemble des autres modules associés ;

Ø C'est un système qui garantit la piste d'audit : il est facile de retrouver et d'analyser l'origine de chaque information ;

Ø Il peut couvrir l'ensemble du Système d'Information (SI) de l'entreprise (sauf si l'entreprise ne choisit dans un premier temps d'implémenter que certains modules de l'ERP) ;

Il garantit l'unicité des informations qu'il contient puisqu'il n'a qu'une seule base de données au sens logique.

L'origine des PGI se trouve dans les méthodes de planification des besoins en composants qui ont été développées dans le cadre d'un impératif d'intégration de plus en plus poussée des fonctions de gestion de l'entreprise.

Dans les années 1960, Joseph Orlicky étudie le programme de production de Toyota et conçoit le MaterialRequirements Planning (MRP). Puis Oliver Wight et George Plosslmettent au point le MRP into manufacturing resource planning (MRP2). D'où une évolution en trois phases:

· MRP0, en anglais MaterialRequirements Planning Zero (littéralement, « planification des besoins en matières 0 ») : méthode de calcul des besoins matière, mise au point en 1965 ;

· MRP1, en anglais MaterialRequirements Planning One : première application industrielle de la gestion intégrée des flux de production, mise au point en 1971 ;

· MRP2, enanglais Material Requirements Planning Two (litt. « planification des ressources pour la fabrication 2 ») : en plus du calcul des besoins nets en matières premières et composants, effectue une planification des lancements en tenant compte des capacités des ressources par période ; mise au point en 1979.

À partir de 1990 environ, la logique introduite par le MRP s'étend progressivement à l'ensemble des fonctions de l'entreprise, pour donner l'« ERP » (E comme entreprise). Cette transition est facilitée par :

Ø L'état des systèmes d'information dont « les applications de base sont installées dans différents départements (services clients, marketing, ventes, comptabilité, fournisseurs, production, distribution, personnel) et ne permettent pas aux utilisateurs de partager un langage commun. Si des interfaces entre ces différents domaines de l'entreprise ont été mises en place, elles sont rarement en temps réel et les exemples où la même donnée est saisie deux ou trois fois, voire plus, ne sont pas rares. (...) les coûts induits sont inestimables : perte de temps, manque d'efficacité, mauvaise visibilité, mauvais processus décisionnel, duplication d'effort, taux d'erreur élevé. (...) Dysfonctionnements qui se traduisent (...) par un mauvais service client et une perte de compétitivité de l'entreprise ».

Ø « Le développement de logiciel est un domaine (...) encore au stade artisanal où l'approche composant - autrement dit l'approche objet- n'en est encore qu'à ses débuts ». Le développement logiciel dépend fortement de la capacité individuelle du développeur et n'est pas conduit par la recherche systématique du réemploi de ce qui a bien fonctionné dans le passé. « Le composant logiciel (l'objet) n'occupe pas la place qui devrait être la sienne alors qu'une nouvelle industrie logicielle est en train d'émerger qui s'inspire des concepts des ateliers de production des industries manufacturières : recherche, engineering, nomenclature, montage, assemblage, version, pièces détachées, inventaire, réutilisabilité, contrôle qualité ».

Ø Les objets logiciels ne sont pas les seuls éléments à devoir faire l'objet d'une meilleure intégration. Les composants techniques issus de fournisseurs divers et indépendants ne facilitent pas l'intégration : systèmes d'exploitation, protocoles de communication, base de données, Interface Homme/machines, machine serveur et machines client, réseau local et étendu, composants bureautiques et multimédias, etc.

Ø Enfin, les profondes modifications nécessitées par le passage informatique à l'an 2000 ont fait que les progiciels de gestion intégrés ont été considérés comme une opportunité technique à saisir pour remplacer des systèmes informatiques vieillissants et difficilement convertibles pour des raisons d'obsolescence technique. L'expansion considérable de ces logiciels dans les années 1990 s'explique en grande partie par les améliorations techniques apportées dans la conception et la mise à jour des systèmes d'information, mais aussi par les opportunités conjointes de refonte des organisations ouvertes à cette occasion.

II.2.1 DESCRIPTION

Ø les outils de type PSA (Professional Service Automation) qui s'adressent à des activités de service qui nécessitent une organisation en mode projet : ils sont centrés sur le service des fonctionnalités de gestion de projet et éventuellement sur celles du GRC/CRM, ce qui ne couvre donc pas l'ensemble des fonctions de l'entreprise à la manière d'un PGI.

Ø les outils de type ESA (Enterprise Service Automation) plus conformes à la définition d'un PGI. Les solutions d'ESA sont en effet capables de servir les fonctions usuelles d'un outil de GRC/CRM, (comme la prise de commande ou l'élaboration d'une proposition commerciale) mais également la plupart des fonctions de gestion administrative d'une entreprise.

Le principe fondateur d'un PGI est de construire des applications informatiques :

Ø de manière modulaire et intégrée au niveau des traitements offerts (les différents modules qui le composent sont indépendants mais parfaitement compatibles entre eux) ;

Ø de manière rigoureuse et cohérente au niveau des données gérées (partage d'une base de données unique et commune).

II.2.2 EVALUATION DE L'EMPLOI D'ERP

Un projet PGI est un projet de transformation. Pour qu'un PGI soit un succès il faut une mobilisation complète de l'entreprise.

Ø La DG ou les directions métiers sont mobilisées dès la phase de choix d'un PGI avec l'élaboration d'un business case qui vise à partager largement dans l'entreprise, les raisons de la mise en place, le périmètre visé et les gains attendus ;

Ø Une phase de sélection permet à l'entreprise de trouver les partenaires qui vont l'accompagner, généralement un éditeur (du PGI), un intégrateur (ou SSII spécialisée) pour la mise en oeuvre et parfois un cabinet de conseil pour la refonte des processus et l'accompagnement des changements ;

Ø Les PGI sont mis en place dans les organisations en « mode projet ». La méthodologie utilisée s'appuie sur les démarches et outils de gestion de projets, de gestion des risques et surtout de conduite de changement nécessaire pour les projets de transformation et donc essentielle pour les projets PGI ;

Ø Intégration des processus de gestion, largement exploitée par les entreprises pour optimiser le suivi financier et le contrôle de gestion ;

Ø Cohérence et homogénéité des informations (un seul fichier articles, un seul fichier clients, etc.) ;

Ø Partage du même système d'information facilitant la communication interne et externe ;

Ø Fiabilité. Une entreprise optant pour un PGI bénéficie généralement d'un outil éprouvé par de nombreuses entreprises de son secteur d'activité et par conséquent en fiabilisation continue au titre de la maintenance éditeur ;

Ø Évolutivité, garantie par la cohérence du modèle de données qui constitue le socle de tous les processus / fonctionnalités SI couverts par le PGI. Le PGI permet une implémentation adaptée et progressive de ces processus / fonctionnalités ;

Ø Rationalisation de l'architecture applicative et technique : diminution du nombre d'outils et par conséquent des interfaces entre ces outils, potentielle diminution ou optimisation des machines et serveurs supportant le système d'information.

Ø Minimisation des coûts : pas d'interface entre les modules, synchronisation des traitements, maintenance corrective simplifiée car assurée directement par l'éditeur et non plus par le service informatique de l'entreprise (celui-ci garde néanmoins sous sa responsabilité la maintenance évolutive : amélioration des fonctionnalités, évolution des règles de gestion, etc.) ;

Ø Diminution du nombre de salariés ayant pour mission principale la saisie comptable (aide-comptable);

Ø Disponibilité et maturité (au niveau coûts, délais, qualité) des prestations de service dédiées au PGI.

Ø Favoriser l'intégration entre les départements, matérialiser la stratégie et les politiques de gestion de l'entreprise dans le système d'information ;

Ø Rapprochement des métiers et de la DSI, appropriation du système d'information par les métiers. Les PGI étant nativement calqués sur les processus métier et flexibles, ils favorisent l'émergence d'une population métier sensibilisée aux aspects techniques du PGI et d'une population DSI sensibilisée à ses aspects métier ;

Ø Étendre l'intégration du système d'information à la supplychain amont et aval (fournisseurs et clients) ;

Ø Standardiser les processus SI et déployer les standards sur l'ensemble des organisations de l'entreprise.

Ce dernier point est essentiel et la mise en oeuvre d'un PGI dans une entreprise est fréquemment associée à une révision en profondeur de l'organisation des tâches et à une optimisation et standardisation des processus, en s'appuyant sur le « cadre normatif » du PGI.

Ø La mise en oeuvre peut s'avérer complexe si le périmètre fonctionnel est mal déterminé ou trop mouvant ou le projet mal piloté ;

Ø coût élevé de 300 000 € minimum pour un progiciel fiable et de qualité, mais pouvant rapidement monter beaucoup plus haut, en fonction de l'industrie et de la complexité du projet. L'option fonctionnellement riche des solutions de logiciels libres si elle réduit les coûts de licence, ne supprime pas les coûts d'accompagnement et de formation. Le paramètre coût est également fonction de la lourdeur et de la rigidité de mise en oeuvre de l'outil qui peuvent être accrues par les difficultés de son appropriation par les utilisateurs ;

Ø périmètre fonctionnel non adapté au besoin réel de l'organisation : le progiciel peut être surdimensionné et donc sous-utilisé s'il est plus large que les besoins effectifs de l'organisation, ou au contraire être sous-dimensionné s'il n'est pas capable de couvrir l'ensemble des besoins avérés ;

Ø nécessité d'une bonne connaissance des processus de l'entreprise (par exemple, une petite commande et une grosse commande nécessitent deux processus différents : il est important de savoir pourquoi, de savoir décrire les différences entre ces deux processus de façon à bien les paramétrer et à adapter le fonctionnement standard du PGI aux besoins de l'entreprise) ;

Ø captivité vis-à-vis de l'éditeur : le progiciel choisi ne peut pas toujours s'adapter à l'organisation qui s'équipe. Le choix d'une solution devient fortement structurant pour l'entreprise, et, au-delà d'un simple paramétrage, ce sera à l'organisation de s'adapter au progiciel (et non l'inverse). Par ailleurs, l'outil PGI risque d'être extrêmement lourd et couteux à gérer notamment s'il nécessite une maintenance continuelle et s'il rend la moindre adaptation (voire son abandon pour un autre produit) très difficile.

L'émergence récente de plusieurs PGI libres permet de minimiser les inconvénients de coût (liés à l'acquisition des licences logicielles), de rigidité et surtout de captivité. L'utilisation de formats ouverts facilite également les échanges de données, en interne et vers l'extérieur.

Pour finir, la pérennité de l'éditeur est un élément majeur à vérifier avant de s'engager dans un projet PGI. Le vrai coût est celui du temps passé en interne, plus que celui de l'achat des licences. La validité du modèle économique du partenaire retenu, dans le temps, est un critère fondamental. Quel que soit le produit retenu, à méthode de travail égale et périmètre fonctionnel identique, les coûts ne sont pas forcément très éloignés d'une société à l'autre quand on compare les acteurs historiques qui durent dans cet environnement très concurrentiel.

II.3 ETUDES COMPARATIVES DES ERP

II.3.1 LES ERP PAYANTS (LICENCE PAYANTE)

Il permet de modéliser simplement le fonctionnement de votre entreprise d'industrie mécanique et il est adapté aux exigences des secteurs Aéronautique, Automobile, Biens d'Equipements, Armement et Ferroviaire. Hélios II, c'est une gestion orientée logistique client et une traçabilité complète : traitement automatique des contrats logistiques EDI, Plan de production, pilote d'atelier en temps réel, gestion de la matière (chutes, fibrage), bilans d'affaires, analyse financière, gestion de la qualité complète et intégrée, portail d'accès Internet clients. Dans la gestion de production classique, Helios ERP assure la maîtrise des coûts et des délais ainsi qu'une traçabilité complète des flux sur l'ensemble des processus de la "supplychain".

Ø L'édition Standard, plus particulièrement destinée aux petites structures (50 à 500 personnes), qui souhaitent une mise en place rapide et des moyens de mise en oeuvre réduits et maîtrisés ;

Ø L'édition Premium, destinée aux entreprises à partir de 500 salariés, organisées en multi-sociétés, multi-sites, souhaitant intégrer à leur système d'information les filiales étrangères, avec une forte personnalisation des processus métiers dans les secteurs négoce, services, industriels.

Sage ERP X3 est une progicielle multi-devise, multi-société, multi-dépôts et multi-sites.Par législation standard, c'est un progiciel entièrement préparé, intégrant un pré-paramétrage complet : états légaux, plan comptable de référence lorsqu'il existe, fichiers bancaires, règles de taxe (TVA exemple).

Sage ERP X3 intègre en standard différentes fonctions de gestion d'entreprise :

Ø gestion financière (Comptabilité générale, analytique, budgétaire et auxiliaire) ;

Est un éditeur de logiciel, qui propose aux entreprises un ERP, qui permet à celles-ci de relier entre eux l'ensemble des processus sous-jacents à toute entreprise (facturation, comptabilité, paie) et des processus qui lui sont spécifiques (logistique, relation client, suivi d'avancement...).

Construit sur la meilleure plateforme cloud du monde, avec un modèle de licence unique et centré sur le client, Acumatica offre une suite d'applications entièrement intégrées. C'est actuellement la seule solution sécurisée d'ERP Cloud, basée sur un navigateur facile à utiliser, personnalisé et équipé d'une flexibilité de déploiement et de paiement.

La solution d'ERP sur le cloud qu'Acumatica propose permet de profiter de l'évolutivité des applications et de coûts matériels réduits. En effet, les clients peuvent construire un cloud interne pour réduire les coûts de matériel tout en maintenant un contrôle accru sur l'intégration ou acquérir un ERP Cloud sans avoir à gérer le matériel, le logiciel et les mises à niveau grâce à la version en SaaS.

Expert reconnu des progiciels de gestion propose aux établissements d'enseignement supérieur et de formation continue des solutions qui allient performance et expertise métier. Paramétrable, la suite AURION s'adapte à votre configuration. Modulaire, l'ERP s'adapte à vos besoins fonctionnels : Inscriptions, suivi des cursus, notation, certification, crédits ECTS, diplômes, plannings, relations entreprises, facturation des frais de formation, gestion des concours, web, pilotage.

AURION permet une gestion complète de toutes les activités d'un établissement de formation, quelles que soient sa taille, sa spécialité, son organisation :

Ø gestion des ressources humaines et préparation de la paie des intervenants, enseignants,...

Ø planification et optimisation logistique des ressources : cours, matériels, salles,...

Ø suivi des relations avec les partenaires : stages, emplois, taxe d'apprentissage, évènements de promotion, prospection, fundraising,...

SAP (Systems, Applications and Products for data processing en anglais et Systeme, AnwendungenundProdukte in der Datenverarbeitung en allemand) est par abus de langage le nom utilisé pour désigner un progiciel de gestion intégré développé et commercialisé par l'éditeur de ce produit (SAP AG).

Le nom exact du progiciel a été plusieurs fois modifié au fur et à mesure de l'évolution des versions. En parallèle de l'évolution du produit, la société SAP a utilisé plusieurs terminologies commerciales pour désigner son offre telles que mySAP.com, mySAP ERP ou mySAP Business Suite. Les logiciels SAP reposent aujourd'hui sur une architecture technique commune appelée SAP NetWeaver dont le principal composant est le Web AS (Web Application Server). Les modules sont les composants fonctionnels du système SAP ERP. On peut distinguer trois familles de modules fonctionnels : logistique, gestion comptable et ressources humaines. En parallèle, SAP a développé une offre sur la mise en conformité réglementaire par rapport aux exigences de développement durable.

La société SAP a également étendu les fonctionnalités de son logiciel pour couvrir les processus propres à chaque secteur d'activité et l'a décliné en 23 solutions qui sont : Aérospatiale et défense, Automobile, Banque, Produits chimiques, Biens de consommation, Bâtiment et Travaux Publics, Services financiers, Santé (établissements de soin), Enseignement supérieur et recherche, Haute technologie, Équipement industriel, Assurances, Industrie des médias, Industrie textile, Industrie minière, Pétrole et gaz naturel, Industrie pharmaceutique, Services professionnels, Administration et secteur public, Commerce de détail et distribution, Prestations de services, Télécommunications, Production, transport et distribution d'énergie.

II.3.2. LES ERP GRATUITS (OPEN SOURCE)

Est un progiciel de gestion intégré pour entreprise, distribué sous licence libre (GPLv3), qui répond de manière efficace à la complexité et aux besoins croissants des entreprises agricoles. Il est basé sur une modélisation durable inspirée de la recherche CEMAGRIM et de l'étude d'exploitations agricoles pilotes. Ekylibre a été conçu dans l'esprit d'une consultation multi-utilisateurs et multiplateforme (Smartphone, tablette, ordinateur) sans avoir à installer d'application supplémentaire .Le leitmotiv du projet est «simple mais complet».

Au niveau technique, il utilise le frameworkhttp, la base de données Postgresq/ (avec le cartouche spatial Postgis). Les standards utilisés reposent sur HTML5, CSS3, SVG et XML.

Ekylibre permet de gérer toutes vos productions, votre comptabilité, vos ventes, vos approvisionnements, votre traçabilité, vos documents réglementaires... de façon collaborative au sein de votre entreprise.

ERP Axelor Business Suite, écrit en JAVA. Au menu, gestion de la relation clients, des ventes, des achats, du stock, de la production, comptabilité, RH, gestion documentaire, gestion de projets. Il inclut aussi un outil de conception graphique des processus (BPM).

Est un logiciel libre et open source intégré constitué d'une suite d'applications pour l'entreprise et utilisé pour automatiser de nombreuses procédures d'entreprise. C'est le seul projet de cette envergure (progiciel de gestion intégré) qui soit géré uniquement par une communauté internationale d'utilisateurs (individuels et entreprises) sans une entreprise unique en arrière-plan.

Ø Progiciel de gestion intégré (PGI ou ERP : Enterprise Ressource Planning)-planification des ressources ;

Ø Gestion de Maintenance Assistée par Ordinateur (GMAO ou CMMS) Gestion de l'architecture d'entreprise (EAM : Enterprise architecture management) ;

Ø Gestion de contenu (CMS) En relation avec les données de l'ERP. Permet une intégration directe, au sein de la gestion de contenu, de tableaux, graphiques... ;

Ø Point de vente (POS). Gestion de points de vente, éventuellement en réseau reliés à une base de données centrale. La gestion des points de vente peut se faire avec autant de niveaux (départementaux, régionaux, etc.) que nécessaire en utilisant une synchronisation sécurisée (reprise sur erreur) par Internet.

Est un logiciel libre de comptabilité en partie double et un progiciel de gestion intégré (PGI). Les données comptables sont stockées sur un serveur SQL et un navigateur web ordinaire sert d'interface utilisateur. Ce système utilise le langage Perl et un module Perl de traitement des bases de données ainsi que PostgreSQL, Oracle et DB2 pour le stockage des données.

SQL Ledger est distribué sous les termes de la licence publique générale GNU.

Est aujourd'hui le Progiciel de Gestion Intégré en licence libre le plus avancé du marché tant par l'étendue de sa couverture fonctionnelle que par les technologies qu'il met en oeuvre.

Ø Hautes Performances : ERP5 est utilisé par de grandes entreprises pour des applications critiques dans le secteur bancaire, aérospatial, de la santé, du transport, de l'habillement et du secteur public. La capacité de l'application à servir un grand nombre d'utilisateurs et des volumes de données importants est un facteur distinctif majeur d'ERP5.

Ø 100% Libre (Open Source) : tous les modules d'ERP5 sont diffusés sous licence GPL (GNU General Public Licence) et l'architecture logicielle d'ERP5 est constituée exclusivement de composantes libres : Linux, Python, Zope, MySQL, OpenLDAP.

Ø Couverture Fonctionnelle : ERP5 couvre tous les domaines de gestion de l'entreprise : la gestion comptable et financière, la gestion des achats et des ventes, la gestion des données produits et des stocks, la gestion de production et la logistique, la gestion de projets, la gestion des ressources humaines et de la paie ainsi que le Knowledge Management.

Ø Accessibilité : ERP5 est une application 100% web utilisable depuis n'importe quel PC ou terminal portable connecté à internet. ERP5 dispose d'une interface spécifique pour son utilisation depuis un téléphone mobile. Grâce au moteur de synchronisation SyncML d'ERP5, vous pouvez également synchroniser des données avec d'autres applications et notamment avec votre agenda ou carnet d'adresse de manière à accéder à vos données même lorsque vous n'êtes pas connecté.

Ø Environnement de Développement Rapide (RAD) : ERP5 peut être adapté rapidement à vos besoins par l'écriture de scripts Python. Le système peut être modifié à chaud et les toutes les modifications apportées deviennent effectives sans arrêt et redémarrage de l'application. L'environnement de configuration d'ERP5 est lui aussi 100% web et autorise le travail collaboratif d'équipes distantes sur un même projet.

Odoo, anciennement OpenERP1 et Tiny ERP, est initialement un progiciel open-source de gestion intégré comprenant de très nombreux modules permettant de simplifier la gestion d'entreprise dans son ensemble. Le logiciel est utilisé par plus de deux millions d'utilisateurs pour gérer leurs entreprises à travers le monde.

Dans un, un client est le logiciel qui envoie des demandes à un serveur. Il peut s'agir d'un logiciel manipulé par une personne. Est appelé client aussi bien l'ordinateur depuis lequel les demandes sont envoyées que le logiciel qui contient les instructions relatives à la formulation des demandes et la personne qui opère les demandes.

L'ordinateur client est généralement un ordinateur personnel ordinaire, équipés de logiciels relatifs aux différents types de demandes qui vont être envoyées, comme un navigateur web, un logiciel client pour le World wide web.

N'importe quel navigateur (Internet Explorer, Firefox Mozilla, google chrome) peut être utilisé comme client léger pour Odoo.

II.4 Architecture (serveur-client web)

Dans un réseau informatique, un client est le logiciel qui envoie des demandes à un serveur. Il peut s'agir d'un logiciel manipulé par une personne. Est appelé client aussi bien l'ordinateur depuis lequel les demandes sont envoyées que le logiciel qui contient les instructions relatives à la formulation des demandes et la personne qui opère les demandes.

N'importe quel navigateur (Internet Explorer, Firefox Mozilla, google chrome) peut être utilisé comme client léger pour Odoo.

Au-delà de ces acronymes, L'ERP est un progiciel qui permet de gérer l'ensemble des processus opérationnels d'une entreprise, en intégrant plusieurs fonctions dans un système. Autrement dit, à savoir qu'un ERP serait la « colonne vertébrale » d'une entreprise.

De manière globale, les logiciels ERP s'adressent aux entreprises menant des projets nécessitant de multiples compétences et devant coordonner le travail de plusieurs équipes ou au moins de plusieurs personnes. On peut considérer qu'un logiciel ERP est nécessaire pour conduire un projet où une dizaine de personnes doivent intervenir. Ils peuvent être gratuits ou propriétaires (payants) au niveau des licences.

Le choix d'un ERP ; le choix du bon système ERP représente un investissement important et le risque de se tromper peut avoir un impact non négligeable sur votre avenir. Certains critères de sélection peuvent être utilisés pour choisir la perle rare des systèmes. On peut citer : les activités métiers de l'entreprise, la préférence des utilisateurs, le coût, le nombre des fonctionnalités supportées etc.

CHAPITRE III. ETUDE ET ANALYSE DE L'EXISTANT

III.1 INTRODUCTION

Dans ce chapitre, nous allons présenter la SNEL qui est le cadre de notre projet. Nous allons également décrire le système existant pour le paiement de facture qui présente des limites dans le système de paiement évolué. En critiquant l'existant, nous allons proposer une solution pour pallier à ces problèmes et faire ressortir les besoins fonctionnels et non fonctionnels pour concevoir un nouvel outil de paiement pour le cas de la SNEL.

III.2 PRESENTATION DE LA SOCIETE NATIONALE D'ELECTRICITE

III.2.1 Historique de la SNEL.

La Société Nationale d'Electricité, SNEL en sigle est une société d'Etat dont le siège est situé sur l'avenue de la justice au numéro 2831 dans la commune de la Gombe à Kinshasa, capitale de la République Démocratique du Congo.

Cette entreprise a été créée par l'ordonnance loi n° 70/033 du 16 mai 1970. Elle est dotée d'une personnalité juridique et est placée sous un double tutelle, celle du Ministère de ressource hydraulique et électricité, en ce qui concerne la gestion technique, et celle du portefeuille pour la gestion administrative et financière.

Soucieux de répondre aux besoins énergétiques du pays, les pouvoirs publics, par ordonnance loi n°67- 391 du 23 septembre 1967, instituant le comité de contrôle technique et Financier pour les travaux d'Inga, lequel comité sera remplacé en 1970 par la SNEL.

A la suite de la mise en oeuvre de la centrale d'Inga I le 24 Novembre 1972, SNEL devenait effectivement productrice, transporteuse et distributrice d'énergie électrique â l'instar d'une société d'Etat, REGIDESO, et des sept sociétés commerciales privées existantes, ayant le même objet social.

C'est par ordonnance n°74/012 du 14 juillet 1974 portant reprise par la SNEL des droits, obligations des anciennes sociétés citées ci-dessus que la SNEL aura le monopole relatif à la gestion de l'ensemble des activités en rapport avec l'électricité en RDC.

Cette loi traduit la volonté de l'Etat d'assurer le contrôle direct de la production, du transport et de la distribution de l'énergie électrique, ressource stratégique en matière de développement économique et social du pays.

Toutefois, en ce qui concerne la REGIDESO, la reprise totale par SNEL des activités électriques de cette société, y compris ses centrales, n'interviendra qu'en 1979. Depuis lors, la SNEL contrôle en réalité toutes les grandes centrales hydroélectricités et thermiques du pays, seules quelques mini- centrales hydroélectricités du secteur minier et des petites centrales thermiques intégrées aux installations d'entreprise isolées continuent à relever du secteur privé.

Pour ce faire, partant des anciennes sociétés productrices et distributrices de l'énergie électrique ayant des structures et des cultures différentes, il a fallu :

ü Traduire dans les faits une véritable société d'électricité à l'échelon national et international;

ü Définir son développement à court, moyen et long termes en rapport avec les objectifs généraux lui assignés par l'Etat : produire transporter et distribuer l'énergie électrique â moindre cout. .

Accomplissant au mieux ces deux objectifs, la SNEL poursuivi sa mission de maitre d'oeuvre pour les travaux d'aménagement du site d'Inga dont la première phase, Inga 1 (351 MW), officiellement démarrée le 01 janvier 1968 fut inaugurée le 24 novembre 1972. La deuxième phase, Inga II (1424 MW), ses installations entre en service en 1982.

Cette période des grands travaux a été couronnée par la construction de la ligne plus moins 500 kV en courant continu Inga- Kolwezi (1704 km), la plus longue au monde.

Entrée en service industriel en 1983, cette ligne était initialement destinée à l'approvisionnement en énergie électrique des mines et usines du Katanga, dans le sud du pays.

Aujourd'hui, elle permet la desserte de quelques pays d'Afrique Australe (Zambie, Zimbabwe, et Afrique du sud). La nécessité de la SNEL, devenu aujourd'hui un acquit, était un préalable à la conception et à la définition d'un plan de développement à long termes de la société.

Ce processus plan de réformes, Accompagné d'une nationalisation progressive des cadres de direction et de commandement en remplacement de personnel expatrié, a abouti à la situation où, depuis 1989, la SNEL ne compte plus que des nationaux dans ses effectifs.

III.3OBJECFIFS, MISSION ET ORGANISATION DE LA SNEL.

III.3.1 Objectifs et mission

La SNEL a pour mission et objectifs qui lui sont confiés par l'Etat Congolais de produire, transporter et distribuer l'énergie électrique en en vue de la commercialisation sur toute étendue de la République Démocratique du Congo.

En plus de ce qui est repris ci-dessous, la SNEL s'occupe de la construction, de l'équipement et exploitation de tous les ouvrages, installations et usines servent au captage des eaux ou infrastructures des sources d'énergie.

Au-delà des activités techniques de production, transport, distribution et utilisation de l'énergie électrique sous toutes ses formes. La SNEL est chargée de promouvoir La vente de cette énergie en conformité avec les dispositions légales en la matière.

III.3.2 Organisation administrative et financière de la SNEL.

L'Organisation administrative et financière de la SNEL est dirigée par les Décrets n°09/2 du 24 avril 2009 portant respectivement mesures transitoires relatives à la transformation des entreprises publiques et liste des entreprises publiques transformées en sociétés commerciales, établissements publics et services publics tels que complétés et modifiés par les Décret n°10/12 du 29/04/2010.

III.3.2.1 Organes de gestion

L'Organisation administrative de la SNEL est structurée de la manière suivante :

Celui-ci investi des pouvoirs étendus pour poser tous les actes d'administration et de disposition en rapport avec l'objet social de l'entreprise.

Celle-ci gère les affaires courantes de l'entreprise suivant la délégation des pouvoirs conférés par le conseil d'Administration.

Elle est composée d'un Administrateur-Directeur Général et d'un Administrateur Directeur Général Adjoint.

Le comité de Direction estime structure consultative et technique composée, outre la Direction Générale, de tous les directeurs de Départements et est organisée suivant note de service n°DGJ1 08/09 du 22/06/2009.

III.4 DEPARTEMENT DE DISTRIBUTION DE KINSHASA

Le Département de distribution de Kinshasa (DDK) en sigle est installé à Kinshasa dans la commune de la GOMBE sur l'avenue du commerce au n°1097, il s'occupe de la distribution et de la commercialisation de l'énergie électrique dans la ville province de Kinshasa, Cette distribution s'effectue en moyenne et basse tension.

Le Département de Distribution de Kinshasa est constitué de cinq Directions centrales et cinq Directions Régionales appelées DKX.

Cette Direction de la distribution de l'énergie électrique du coté Est de la ville de Kinshasa et dans les communes ci-après :

Elle s'occupe de la distribution de l'énergie électrique du côté Ouest de ville de Kinshasa et de communes ci-après:
BANDALUNGWA, KINTAMBO, NGALIEMA, UNE PARTIE DE SELEMBAO et MONT- NGAFULA.

Elle s'occupe de la distribution de l'énergie électrique dans la partie centre de Kinshasa ; il s'agit des communes suivantes :

Cette Direction est chargée de la distribution de l'énergie électrique dans les communes ci-après : LIMETE, LEMBA, MATETE, KISENSO et NGABA.

Cette Direction s'occupe de la distribution de l'énergie électrique dans des communes ci-après : GOMBE, KINSHASA, BARUMBU, LINGWALA et Kasa-Vubu.

III.5 CRITIQUE DE L'EXISTANT

Au sein de la Société Nationale d'Electricité SNEL en sigle, le système de paiement de facture est totalement manuel. La société à un service des Agents de contrôle et de dépôt de facture auprès de leurs clients, et de l'autre côté, les clients doivent se diriger à la SNEL en vue de s'acquitter de leur paiement de facture, et même coté paiement bancaire les clients paient à la banque et doivent apporter leurs preuves de paiements aux services commercial et finance de SNEL. Ce qui ne permet pas aux clients de payer leurs factures de manière permanente. Bien que ce mode de paiement se fait suivant une bonne structuration de charge et service permettant la gestion et le contrôle des entités concernées.

Sans en tenir compte, les forces que l'on observe dans ce système, nous estimons qu'elle laisse encore à désirer car le temps d'exécution des taches demeure encore important et les résultats fournis sont peu fiables. (Perte de temps, perte de documents...)

III.6 SOLUTION PROPOSEE

Pour remédier à tous ces problèmes des longues procédures de notification des clients eux-mêmes pour les paiements bancaires du système actuel de paiement de facture de la SNEL, nous allons concevoir et implémenter une application intermédiaire (intergiciel) entre les banques et la snel, et aussi implémenter un ERP pour la gestion de la facturation coté snel.

C'est une solution qui épargnera les clients ou abonnés de faire les navettes de la banque à la snel apportant les bordereaux de paiement pour s'enregistrer et se régulariser. Et permettra à la banque de notifier la snelsur les informations des paiements bancaires de ses abonnés (clients), ainsi que faciliter la gestion de la facturation de la snel.

Tout compte fait, nous retenons que le système proposé demeure efficace et adapté pour un traitement rapide et fiable des informations au sein de la Société qui aspire au progrès.

III.7 ETUDES DES BESOINS

Dans cette étape, nous devons faire une bonne étude enfin de dégager les besoins qui nous faciliteront pour mieux réaliser notre application.

III.7.1 Besoins Fonctionnels

Après une étude de notre système, nous avons pu soulever les besoins fonctionnels ci - après :

III.7.1.1 Les problèmes à résoudre

III.7.1.2 Principe

III.7.2 Besoins non Fonctionnels

Nôtre solution doit être facilement utilisable pour permettre auxusagers concernés du côté des banques et du côté de la SNELqui manipule un ordinateurà être très à l'aise quand ils l'auront. Ce qui relève les besoins suivants :

Ø La convivialité : Nos applications doivent être conviviales c.à.d. facilement utilisables.

Ø La sureté : Nos applications doivent correctement fonctionner, sans erreurs ou sans difficultés.

3.1. CONCLUSION

Dans ce troisième chapitre, nous avons présenté le cadre de notre projet. Nous avons par la suite procédé à la description de l'existant afin de comprendre les défaillances de ce système, au critique de l'existant pour arriver à dégager toutes les défaillances de ce système et à la proposition d'une solution. Nous avons ressorti après étude de besoins, toutes les fonctions principales répondant aux besoins fonctionnels et non fonctionnels.

CHAPITRE IV. CONCEPTION ET IMPLEMENTATION DES APPLICATIONS

IV.1 INTRODUCTION

Après l'étape d'analyse, nous allons dans cette partie du travail concevoir et implémenter les futures applications. Nous présenterons le langage de modélisation et nos différents choix technique y compris les langages de programmations utilisés, et enfin nous présenterons les interfaces réelles de notre application.

IV.2 MODELISATION

IV.2.1 Spécification des besoins

Cette dernière représente la phase de départ pour le développement d'un logiciel, dans laquelle nous allons identifier les besoins de notre application. Nous distinguons des besoins fonctionnels qui présentent les fonctionnalités attendues de notre application et les besoins non fonctionnels pour éviter le développement d'une application non satisfaisante. Ici nous allons plus signifier les besoins fonctionnels

Notre travail consiste à concevoir et implémenter une application pour la vulgarisation du découpage territorial en république démocratique enfin de permettre aux utilisateurs d'accéder facilement aux informations liées à la nouvelle réforme territoriale

IV.2.1.1 Spécification des besoins fonctionnels

Il s'agit de la toute première étape du processus de développement et vise à effectuer un premier repérage des besoins fonctionnels du système à modéliser. Il est aussi valable de dire que cette partie est réservée à la description des exigences fonctionnelles des différents acteurs du système ; ces besoins se regroupent en deux parties selon l'utilisation. Nous citons donc en premier lieu le front office ou la partie client et le back office qui représente la partie administration.

Ø Connection : Cette fonction permettra aux utilisateurs (banque et/ou snel) de se connecter au middleware (intergiciel) ;

Ø Saisie : Celle-ci permettra à l'utilisateur banque de saisir les informations du paiement de la facture du le client ;

Ø Envoyer : C'est la fonction qui produira le messager et l'envoyer au consommateur ou récepteur (snel) ;

Ø Recevoir : C'est la fonction qui commencera à recevoir le message produit par la banque ;

Ø Stockage : C'est la fonction quipermettra à l'utilisateur banque et/ou snel d'enregistrer les informations de la paie sur la facture du client mais chacun dans sa base de données ;

Ø Gestion facture : Cette dernière permet à l'utilisateur snel de gérer toutes les informations de la facturation et du paiement du client.

Cette partie du système sera accessible que par l'administrateur ; il contient essentiellement les fonctionnalités suivantes :

IV.2.2 Langage de modélisation

Avant de programmer l'application et se lancer dans l'écriture du code ; il faut d'abord organiser les idées, les documenter, puis organiser la réalisation en définissant les étapes de la réalisation. Cette démarche antérieure à l'écriture, s'appelle modélisation.

Modéliser consiste à représenter virtuellement une situation du monde réel enfin de simplifier la démarche de conception d'un système. Il existe plusieurs méthodes d'analyse pour modéliser, nous pouvons cités entre autres : Merise, UML.

En regardant les objectifs fixés pour la réalisation de notre application, nous remarquons que nous sommes face à une application qui devra rester ouverte pour les améliorations futures. De ce fait, il est très important d'utiliser un langage universel pour la modélisation afin de clarifier la conception et de faciliter les échanges. Notre choix est donc porté sur le langage UML puisqu'il convient mieux.

UnifiedModelingLanguage (UML) est un langage de modélisation objet, il permet donc de modéliser vos objets et ainsi représenter votre application sous forme des diagrammes.

Notre choix s'est basé sur les points forts de ce langage notamment sa standardisation et les divers diagrammes qu'il propose. Aussi UML présente le meilleur outil pour schématiser des systèmes complexes sous un format graphique et textuel simplifié et normalisé.

IV.2.3 Middleware

Si on pouvait résumer l'intérêt d'un middleware en une seule phrase, nous dirons qu'il sert à créer la connexion entre plusieurs applications qui n'étaient pas forcément conçus pour communiquer entre eux, par échanges ou interopérabilité.

Ces entités peuvent être intégrées sur plusieurs réseaux pas forcément reliés entre eux, le middleware se chargera d'en assurer la connexion malgré tout.

Le middleware se doit d'assurer la communication entre les opérateurs et l'ERP. L'ERP (progiciel de gestion intégrée) restant lui dans son rôle de coordination des activités de l'entreprise.

Le middleware est l'outil terrain et grâce à cela, il permet au niveau de la ligne de production ou des utilisateurs de la logistique notamment, de proposer des écrans simplifiés permettant de faciliter les saisies et donc de les fiabiliser.

Et l'ERP est une application dont le but est de coordonner l'ensemble des activités dites verticales autour d'un même système d'information. Le middleware est dans ce cas, la « la brique Terrain» du système d'information(c'est en quelque sorte un connecteur d'entités distantes).

IV.2.4 Le diagramme de cas d'utilisation

Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d'un système logiciel. Ils sont utiles pour des présentations auprès de la direction ou des acteurs d'un projet, mais pour le développement, les cas d'utilisation sont plus appropriés. Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d'utilisation (use cases).

UML définit une notation graphique pour représenter les cas d'utilisation, cette notation est appelée diagramme de cas d'utilisation. UML ne définit pas de standard pour la forme écrite de ces cas d'utilisation, et en conséquence il est aisé de croire que cette notation graphique suffit à elle seule pour décrire la nature d'un cas d'utilisation. Dans les faits, une notation graphique peut seulement donner une vue générale simplifiée d'un cas ou d'un ensemble de cas d'utilisation. Les diagrammes de cas d'utilisation sont souvent confondus avec les cas d'utilisation, bien que ces deux concepts soient reliés, les cas d'utilisation sont bien plus détaillés que les diagrammes de cas d'utilisation.

IV.2.4.1 Les éléments d'un diagramme de cas d'utilisation

Un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système. Il se représente par un petit bonhomme (stickman); sous-titré par le nom de l'acteur.

Il est également possible de représenter un acteur sous la forme d'un rectangle lorsqu'il s'agit d'un système.

Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.

Un cas d'utilisation se représente par un ovale contenant le nom du cas (un verbe à l'infinitif), et optionnellement, au-dessus du nom.

IV.2.4.2 Relations entre les cas d'utilisation

Trois types de relations sont pris en charge par la norme UML et sont graphiquement représentées par des types particuliers de ces relations.

Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. Lorsque A est sollicité, B l'est obligatoirement, comme une partie de A.

Cette dépendance est symbolisée par : <<include>>. Par exemple, l'accès à l'interface de gestion de compte inclut nécessite une authentification.

La relation d'extension est probablement la plus utile, car elle a une sémantique qui a un sens du point de vue métier au contraire des deux autres qui sont plus des artifices d'informaticiens.

On dit qu'un cas d'utilisation A étend un cas d'utilisation B lorsque le cas d'utilisation A peut être appelé au cours de l'exécution du cas d'utilisation B. Exécuter B peut éventuellement entraîner l'exécution de A : Cette dépendance est symbolisée par le stéréotype <<extend>>.

Un cas A est une généralisation d'un cas B si B est un cas particulier de A, la consultation d'un compte via Internet est un cas particulier de la consultation; Cette relation de généralisation/spécialisation est présentée dans la plupart des diagrammes UML et se traduit par le concept d'héritage dans les langages orientés objet.

IV.2.5 Analyse du système (ERP)

IV.2.5.1 Identification des acteurs et cas d'utilisation

L'identification des acteurs en interaction avec le système simplifie grandement la collecte des besoins fonctionnels car il suffit alors d'analyser acteur par acteur et de vérifier pour chacun qu'il dispose de toutes les fonctionnalités qui lui seront utile au regard de sa mission et du périmètre du projet. Ainsi une analyse perspicace des fonctionnalités souhaitées et de l'environnement même du projet induit la détermination des cas d'utilisation répertoriés dans le tableau.

IV.2.5.2 Présentation de diagramme de cas d'utilisation

Ci-dessous nous présentons le diagramme de cas d'utilisation pour la compréhension du fonctionnement du système.

IV.2.5.3 Quelques descriptions des cas d'utilisations

Sommaire
Titre	Gérer facture
Résumé	Ce cas d'utilisation permettra aux utilisateurs (snel et/ou administrateur) de faire la gestion de facture de client de la snel.
Acteurs	Utilisateursnel et/ou l'administrateur
Description des enchainements
Pré condition	Post condition
S'authentifier	Faire tous les processus de la facturation (créer, valider facture)
Scénario nominal
1. L'utilisateur sollicite l'authentification ; 2. Le système affiche le formulaire d'authentification ; 3. L'utilisateur rempli le formulaire d'authentification et renvoi au système ; 4. Le système vérifie et l'authentification et donne accès au système ; 5. L'utilisateur sélectionne le menu (comptabilité) de la gestion de facture ; 6. Le système affiche les interfaces de la gestion facture
Scénario alternatif
4b. L'authentification non valide ; 7. Le système affiche une notification d'erreur ; 8. Retour à l'interface d'authentification.

Sommaire
Titre	Créer client
Résumé	Ce cas d'utilisation permettra aux utilisateurs (snel et/ou administrateur) de créer d'utilisateurs snel.
Acteurs	L'utilisateur snel et/ou l'administrateur
Description des enchainements
Pré condition	Post condition
S'authentifier	-
Scénario nominal
1. L'utilisateur sollicite l'authentification ; 2. Le système affiche le formulaire d'authentification ; 3. L'utilisateur rempli le formulaire d'authentification et renvoi au système ; 4. Le système vérifie et l'authentification et donne accès aux systèmes ; 5. L'administrateur sélectionne le menu de la gestion clients ; 6. Le système affiche les interfaces de la gestion clients ; 7. L'administrateur sélectionne le bouton créer clients ; 8. Le système affiche le formulaire de la création du client ; 9. L'administrateur rempli le formulaire et renvoi les informations rempli au système ; 10. Le système crée le client.
Scénario alternatif
4b. L'authentification non valide ; 11. Le système affiche une notification d'erreur ; 12. Retour à l'interface d'authentification.

Sommaire
Titre	Mettre à jourclient
Résumé	Ce cas d'utilisation permettra à l'utilisateur de modifierles informations desclients.
Acteurs	L'utilisateur snel et/ou l'administrateur
Description des enchainements
Pré condition	Post condition
S'authentifier	-
Scénario nominal
1. L'utilisateur sollicite l'authentification ; 2. Le système affiche le formulaire d'authentification ; 3. L'utilisateur rempli le formulaire d'authentification et renvoi au système ; 4. Le système vérifie et l'authentification et donne accès aux systèmes ; 5. L'administrateur sélectionne le menu de la gestion clients ; 6. Le système affiche les interfaces de la gestion clients ; 7. L'administrateur sélectionne le client ; 8. Le système affiche le formulaire du client; 9. L'administrateur modifie le formulaire et renvoi les informations rempli au système ; 10. Le système enregistre les modifications du client.
Scénario alternatif
4b. L'authentification non valide ; 11. Le système affiche une notification d'erreur ; 12. Retour à l'interface d'authentification.

Sommaire
Titre	Supprimer client
Résumé	Ce cas d'utilisation permettra à l'utilisateur de supprimerles clientssnel enregistrés.
Acteurs	L'utilisateur snel et/ou l'administrateur
Description des enchainements
Pré condition	Post condition
S'authentifier	-
Scénario nominal
1. L'utilisateur sollicite l'authentification ; 2. Le système affiche le formulaire d'authentification ; 3. L'utilisateur rempli le formulaire d'authentification et renvoi au système ; 4. Le système vérifie et l'authentification et donne accès aux systèmes ; 5. L'administrateur sélectionne le menu de la gestion client ; 6. Le système affiche les interfaces de la gestion client ; 7. L'administrateur sélectionne et supprimele client ; 8. Le système enregistre la suppression du client ;
Scénario alternatif
4b. L'authentification non valide ; 9. Le système affiche une notification d'erreur ; 10. Retour à l'interface d'authentification.

Sommaire
Titre	Gérer tables
Résumé	Ce cas d'utilisation permettra à l'administrateur de créer, modifier, supprimer les tables dans la base de données.
Acteurs	L'administrateur
Description des enchainements
Pré condition	Post condition
S'authentifier	-
Scénario nominal
1. L'utilisateur sollicite l'authentification ; 2. Le système affiche le formulaire d'authentification ; 3. L'utilisateur rempli le formulaire d'authentification et renvoi au système ; 4. Le système vérifie et l'authentification et donne accès aux systèmes ; 5. L'administrateur sélectionne le menu de la gestion DB ; 6. Le système affiche les interfaces de la gestion utilisateurs ; 7. L'administrateur sélectionne tables ; 8. Le système autorise l'accès au menu gestion tables.
Scénario alternatif
4b. L'authentification non valide ; 9. Le système affiche une notification d'erreur ; 10. Retour à l'interface d'authentification.

IV.2.6Le cycle de développement en V et Conception détaillée

IV.2.6.1 Le cycle de développement en V

De nos jours, la méthodologie adoptée dans l'analyse et la conception des systèmes représente un choix stratégique pour le bureau d'études afin de mener à terme les projets tout en respectant les délais annoncés au client et avec la qualité demandée.

Vu l'évolution des besoins des utilisateurs finaux, les applications d'entreprise deviennent de plus en plus complexes et difficiles à concevoir et à développer.

Pour la conception, le développement et la réalisation de notre application, nous avons opté pour l'application du processus de développement V qui demeure actuellement le cycle de vie le plus connu et certainement le plus convenable aux projets complexes.

Ce processus nous a accompagné du début de projet jusqu'à l'implémentation. Son principe est qu'avec toute décomposition doit être décrite la recomposition, et que toute description d'un composant doit être accompagnée de test qui permettront de s'assurer qu'il correspond à sa description. Ceci rend explicite la préparation des dernières phases (validation-vérification) par les premières (construction du l'application) et on sait progressivement si on s'approche de ce que le client désire.

IV.2.6.2 Conception détaillée

Cette étape se fera par étape afin d'aboutir à un système fonctionnel reflétant une réalité physique. Mais nous allons résumant les cas ou prendre qu'un seul cas d'utilisations.

Un diagramme de séquence est un diagramme d'interaction dont le but est de décrire comment les objets collaborent au cours du temps et quelles responsabilités ils assument. Il décrit un scénario d'un cas d'utilisation.

Un Diagramme de Séquence est une forme de diagramme d'interaction, ce qui montre que les objets comme des lignes de sauvetage réduisant la page. Interactions représentés au fil du temps sont dessinées comme des connecteurs de message de la source Ligne de Vie à la Ligne de Vie cible. Les diagrammes de séquence sont bonnes à montrer les objets qui communiquent avec d'autres objets. Et quels sont les messages déclencher ces communications.

Ø Ligne de vie : représentation de l'existence d'un élément participant dans un diagramme de séquence. Cela peut être un acteur ou le système en modélisation d'exigences, des objets logiciels en conception préliminaire ou conception détaillée.

Ø Message : élément de communication unidirectionnel entre objets qui déclenche une activité dans l'objet destinataire.

Ø La flèche pointillée représente un retour au sens UML. Cela signifie que le message en question est le résultat direct du message précédent.

Ø Message synchrone : l'objet émetteur se bloque en attendant la réponse de l'objet récepteur du message.

Ø Message asynchrone : l'objet émetteur n'attend pas la réponse de l'objet récepteur du message et continue son activité.

Dans UML, un diagramme d'activité est utilisé pour afficher la séquence des activités. Les diagrammes d'activité représentent le flux de travail à partir d'un point de départ au point d'arrivée. Détaillant les nombreux sentiers de décision, qui existent dans la progression des événements contenus dans l'activité. Ils peuvent être utilisés à des situations de détail, où le traitement parallèle peut survenir dans l'exécution de certaines activités. Les diagrammes d'activités sont utiles pour la modélisation d'entreprise où ils sont utilisés pour détailler les processus impliqués dans des activités commerciales.

IV.3 CHOIX TECHNIQUES

IV.3.1 Langages de programmation

JMS est une API, et cette API correspond à des services d'échange entre des producteurs et des consommateurs de messages, s'appuyant sur des concepts que nous avons présentés. Au-delà de l'API donc, JMS définit les fonctionnalités centrales des MOMs.

JMS spécifie le service, mais ne spécifie pas comment ce service est mis en oeuvre. Chaque fournisseur, JMS Provider, est libre de ses choix d'implémentation. Comme on l'a vu plus haut, les protocoles d'échanges peuvent également être considérés comme des choix d'implémentation propres à certains MOMs, même si nous considérons qu'ils ont une réelle importance.

La spécification JMS n'est pas en tous points complets. Certaines fonctions essentielles au fonctionnement d'une plateforme MOM ne sont pas décrites dans la spécification et font donc l'objet d'implémentations particulières. C'est le cas en particulier pour la configuration et l'administration du service de messagerie, pour la sécurité (intégrité et confidentialité des messages) et pour certains paramètres de qualité de service.

Par ailleurs, la plupart des MOMs proposent des fonctions additionnelles qui se présentent comme des atouts spécifiques par rapport aux offres concurrentes (par exemple les topics hiérarchisés, des fonctions de sécurité et des mécanismes de haute disponibilité, etc.). Bien sûr, la mise en oeuvre de ces fonctionnalités se fait au détriment de la capacité à changer de MOM, en respectant l'API JMS.Comme d'autres spécifications d'interface, comme le SQL par exemple, la promesse de pouvoir changer d'implémentation de MOM JMS de manière transparente, n'est pas facilement tenue. Mais ce n'est pas très grave.

La spécification commune apporte déjà le bénéfice d'une communauté de vision, d'approches, et de compétences. Un architecte peut raisonner sur la base d'un MOM sans savoir nécessairement de quelle « marque » il sera, et un développeur qui a pratiqué JMS avec un premier MOM, pourra presque immédiatement en pratiquer un second.

Python est un langage de programmation objet interprété, multi-paradigme et multiplateformes. Il favorise la programmation impérative structurée, fonctionnelle et orientée objet. Il est doté d'un typage dynamique fort, d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de gestion d'exceptions ; il est ainsi similaire à Perl, Ruby, Scheme, Smalltalk et Tcl.

Le langage Python est placé sous une licence libre proche de la licence BSD4 et fonctionne sur la plupart des plates-formes informatiques, des supercalculateurs aux ordinateurs centraux5, de Windows à Unix avec notamment GNU/Linux en passant par macOS, ou encore Android, iOS, et aussi avec Java ou encore .NET. Il est conçu pour optimiser la productivité des programmeurs en offrant des outils de haut niveau et une syntaxe simple à utiliser.

Il est également apprécié par certains pédagogues qui y trouvent un langage où la syntaxe, clairement séparée des mécanismes de bas niveau, permet une initiation aisée aux concepts de base de la programmation Il est également apprécié par certains pédagogues qui y trouvent un langage où la syntaxe, clairement séparée des mécanismes de bas niveau permet une initiation aisée aux concepts de base de la programmation.

IV.3.2 Base de données PostgreSQL

PostgreSQL un système de gestion de base de données relationnelle et objet (SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.

Depuis la version 8.0, PostgreSQL fonctionne également nativement sur Windows. Avant la version 8, il fallait une couche de compatibilité POSIX (par exemple cygwin) pour faire fonctionner PostgreSQL sur ce système d'exploitation.

PostgreSQL est largement reconnu pour son comportement stable, proche d'Oracle. Mais aussi pour ses possibilités de programmation étendues, directement dans le moteur de la base de données, via PL/pgSQL. Le traitement interne des données peut aussi être couplé à d'autres modules externes compilés dans d'autres langages.

PostgreSQL est la base de données utilisée par Odoo pour stocker les données système et utilisateur. Et utilise des plateformes pour l'administration, mais pour notre travail nous avons utilisés pgAdmin.

pgAdmin :

Est la plateforme d'administrateur et de développement libre la plus populaire et la plus riche pour PostgreSQL.

Conçu pour répondre aux besoins de tous les utilisateurs, de l'écriture de requêtes SQL simple aux développements de base de données complexes.

Nous permet de visualiser l'ensemble des données dans la base de données de l'application, enfin d'apporter les modifications possibles.

IV.3.3 Choix du MOM et de l'ERP

De tous les MOMset PGIsvu ci-haut nous optons pour ActiveMQ et Odoo par ce qu'ils remplissent beaucoup des critères qu'on a pu détaillés précédemment

IV.4 PRESENTATION DES APPLICATIONS

IV.4.1 ActiveMQ (Intergiciel)

MyBank représente l'application que la banque utilise et une fois les informations saisies, le bouton envoyer sert à enregistrer dans la base de données de la banque et envoyer le message à SNEL NOTIFY qui est du côté de la SNEL et ce dernier à son tour sert qu'à recevoir le message rien de plus.

Ø Interface SNEL NOTIFY connecté au broker (la partie en rouge sera désactive)

IV.4.2Odoo

IV.4.2.1 Installation et Configuration d'odooversion 11

C'est la première étape, le choix de la langue, il y en a que deux (Français et Anglais). Choisissez le French (français).

Appuyer encore sur le bouton Suivant pour accepter la licence, car elle est gratuite.

Cette fois-ci, il faut choisir le type d'installation (All In One) et cocher sur le Serveur odoo et Installation de la base de données PostgreSQL. Pour installer tout dans un.

Configuration des informations de connexion pour la base de données PostgreSQL.

Fin d'extraction de tous les fichiers système de l'application, vous devez appuyer sur le bouton Suivant pour terminer l'installation d'odoo et de PostgreSQL.

C'est la fin de l'installation de l'application. En appuyer sur le bouton Fermer l'application vous ramène dans un navigateur web et lance l'application automatiquement.

Après l'installation de l'application, la création de la base et la configuration des informations de l'entreprise. Nous avons configuré les serveurs de courriels sortants et la passerelle de messagerie pour la réception.

IV.4.2.2 Modules Comptabilité

Pour lancer l'application, il nous faut un navigateur ou un moteur de recherche vue que c'est une application web.

Adresse IP serveur Odoo : sera remplacé par l'adresse IP de la machine hébergeant le serveur Odoo.

Ainsi, nous pouvons aussi accéder à l'application à partir de n'importe quelle machine du LAN pouvant communiquer avec la machine serveur.

Nous n'avons pas utilisé la configuration de la passerelle car les machines sont directement connectées et sont dans le même sous-réseau. Dans le cas contraire, l'utilisation de la passerelle est indispensable.

Pour se connecter avec le P l'adresse de connexion est : http://192.168.1.1:8069. Ceci veut dire je lance l'application se trouvant dans le PC 192.168.1.1, accessible au port 8069.

Pour accéder dans l'application, il nous faut en avance être un utilisateur créé par l'administrateur avec un courriel et un mot de passe à mettre pour y avoir accès.

L'utilisateur peut ou ne pas être un employé, mais plutôt une personne qui est autorisé à l'application.

IV.4.2.3 pgAdmin

CONCLUSION GENERALE

Tout au long de notre stage au sein de la SNEL, nous avons remarqué un besoin réel d'informatiser le Système d'Information en générale, et en particulier la gestion de factures surtout pour les clients qui payent par voie bancaire. Ce désir a trouvé réponse au travers de projet proposé l'actuelledirection générale de la société qui a pour projet d'informatiserplusieurs processus entre-autre la notification des banques sur les factures payées.

La gestion de la facturation (ou la gestion de la comptabilité) est une tâche délicate dans l'entreprise compte tenu de l'importance du facteur finance dans une société. Une meilleure organisation au travers des outils adéquats permet auxcomptables d'être opérationnels et efficient dans leurs tâches quotidiennes.

Primo, dans ce travail, nous avons parlé des middlewares et par la suite nous avant choisi d'utiliser ActiveMQ qui est un middleware orienté message suivant les intérêts et les buts poursuivis dans notre travail.

Secundo, nous avons présenté un état de l'art sur les ERP au travers d'une étude comparative de quelques solutions après avoir brossé l'intérêt d'avoir un ERP au sein d'une entreprise cette comparaison nous a permis de choisir l'ERP Odoo qui est le progiciel le plus utilisé dans la catégorie « open source ». Au travers de cette plateforme, nous avons lancé l'informatisation du Système d'Information de la SNEL en se focalisant essentiellement sur « la mise en place des modules gestion de facture ».

A notre humble avis, la gestion de factures au sein de la Société Nationale d'Electricité pourra bien marcher avec les nouveaux outils de travail mis à leur disposition. Nous prierons aussi aux responsables de la SNEL de planifier une formation professionnelle avant la mise en place de l'application pour permettre aux agents particulièrement aux agents de finance, commerciale d'être aptes aux exigences de ces nouvelles applications.

En grosso modo, ce travail nous a permis de nous familiariser avec le middleware ActiveMQ et le progiciel Odoo qui nécessite de bonnes connaissances avant de pouvoir effectuer un travail de qualité. Aussi, mis à part l'apport technique, ce mémoire TFE nous a ouvert à la dynamique du logiciel libre.

Comme perspectives, nous comptons dans les années à venir approfondir notre connaissance sur ActiveMQ et finaliser l'application de notification et aussi coté ERP Odoo, intégrer le maximum des modules en vue de l'informatisation de la SNEL.

ANNEXES

textMessage.setText(textAreaNomClient.getText() + "@" + textAreaNumFact.getText() + "@" + textAreaMontantP.getText() + "@" + comboAreaDevise.getSelectionModel().getSelectedItem().toString() + "@" + cal.getTime());

int a = bankBD.insert(textAreaNomClient.getText(), textAreaNumFact.getText(), Double.parseDouble(textAreaMontantP.getText()), comboAreaDevise.getSelectionModel().getSelectedItem().toString(), cal);

JOptionPane.showMessageDialog(null, "Echecd'enregistrement", "Erreur", JOptionPane.ERROR_MESSAGE);

public intinsert(String nom_client, String numFact, double montant, String devise, Calendar date) {

String requete = "insert into gestion_facture(nom_client,numero_facture,montant_paye,devise_paye,date_eng) values(?,?,?,?,?)";

BIBLIOGRAPHIE

- Notes du cours d'Atelier de Génie Logiciel (AGL), P.A Blaise ANGOMA, 2017-2018 ;

- Rodian KABEYA, Conception et Implémentation d'une Application de Gestion des Ressources Humaines avec l'ERP Odoo, « cas de l'I.S.P.T.-KIN », 2015-2016 ;

- Manager avec les ERP, 3ème édition, Jean-Louis Lequeux NORMES ET AUTRES REFERENCES ;

- Dany KAMBERE, Conception et Implémentation d'une Application mobile pour la vulgarisation du découpage territorial « Cas de la RDC et ses 26 provinces »,2016-2017.

Refonte du système d'information de la snel par la mise en place d'un module ERP pour la gestion automatique de paiement des factures par voie bancaire grà¢ce à l'intergiciel ActiveMQ

Epigraphe