Mise en œuvre d’une application de merchandising\n[3 Janvier 2010] NOUVEAU SITE WEB\nCliquer sur l'image ci-dessous pour y accéder ...\nPrésenté en vue d’obtenir le\nDIPLÔME D’INGĖNIEUR C.N.A.M\nRéalisation d’un projet de merchandising\nSoutenu le jeudi 6 décembre 2007\nPrésidente : Isabelle COMYN-WATTIAU, Professeur\nMembres : Tatiana AUBONNET, Maître de conférence\nJacky AKOKA, Professeur\nPierre AUDOIN, Chef de service\nPierre ESTIVALET, Merchandiser Senior\nAujourd’hui, afin d’être plus compétitifs, les groupes de distribution ont besoin de se doter d’outils d’optimisation de la présentation des produits sur leurs surfaces de vente. C’est ce que permet l’application Merchandising. On gagne en productivité en automatisant les tâches manuelles et en simplifiant les outils.\nPour rester souple par rapport à l’utilisation d’une solution propriétaire, nous avons fait le choix de gérer les notions « métier » propres à l’entreprise dans une solution spécifique.\nETL, conception d’application J2EE, architecture, Open Source, tests\nToday, in order to be more competitive, distribution groups need tools to optimize product presentation in their stores. The Merchandising application allows this. With the automatisation of manual tasks and the use of simple tools, productivity has been increased.\nTo remain flexible compared to the use of an owner solution, we made the choice to manage the concepts with a solution specific to the company.\nThis application has been integrated into a heterogeneous information system with an ETL. The ETL reduces the system complexity, as it defines a precise development framework and it hides the various technical implementations.\nThe more the ETL is used, the more the system complexity decreases. However, ETL requires additional tools to satisfy all our needs.\nIn addition, we use J2EE to implement the WEB interfaces. It is an architecture which meets our HMI needs. It allows the development of structured applications, easy to support, but the development costs generated are very high.\nThe WEB architecture used is based on Open Source products. There is a financial advantage in using these products as there is no licence to pay.\nStress Tests have allowed the validation of the quality of services given to the users.\nThe implementation of the application has satisfied the essential needs. However, some evolutions are needed in order to have tools capable of answering requests of supervision, reporting and management of data quality.\nETL, J2EE application design, architecture, Open Source, tests\nJ’ai effectué mon « stage » au sein du service Reporting et Pilotage du département administratif de la Direction de l’informatique du Groupe MONOPRIX, sous la responsabilité de Jean-François Lemaire, chef de service et en collaboration avec Pierre Audoin, responsable du Merchandising PGC. Ce « stage » a débuté en septembre 2004.\nSuite à la réorganisation de la Direction de l’informatique, en début 2007, le projet Merchandising est désormais rattaché au service référentiel du département Marchandise dont la responsable est Isabelle Renoncet.\nA ma demande, j’ai été transféré dans l’équipe d’Isabelle Renoncet à partir du premier avril 2007 pour continuer à piloter le projet.\nCe mémoire n’aurait pu voir le jour sans le soutien de mes professeurs du CNAM, de mes collègues, de mes amis et de ma famille.\nParmi toutes ces personnes, je tiens à exprimer mes remerciements à Monsieur Jacky Akoka à qui je dois d’avoir pu présenter ce mémoire après neuf années de cours du soir.\nJe remercie tout particulièrement Monsieur Pierre Audoin pour son aide précieuse et son soutien sans faille tout au long du projet, ainsi que les ingénieurs d’étude qui ont travaillé sur le projet.\nJe remercie également Madame Isabelle Renoncet pour la compréhension dont elle a fait preuve dès mon arrivée dans son service.\nUn travail de si longue haleine suppose le soutien des proches. Je remercie mon épouse Xiao ping pour le soutien qu’elle m’a toujours apporté et sa patience. Merci également à Léona et Roland pour leur encouragement.\n1. Le projet 8\n1.1. Le merchandising. 11\n1.2. Pourquoi ce projet ?. 15\n1.3. Les contraintes. 19\n1.4. Les étapes importantes du projet 20\n2. Présentation des méthodologies, technologies et concepts utilisés. 24\n2.1. Gestion et management de projet 24\n2.2. Les modèles et les méthodes. 26\n2.3. Management des ressources humaines. 53\n2.4. ETL et EAI : généralités. 64\n2.5. Organiser une application J2EE. 77\n2.6. Ruby on Rails. 94\n2.7. L’architecture Web. 100\n2.8. Les stress tests. 117\n3. Mise en œuvre de l’application merchandising. 133\n3.1. Présentation de l’application merchandising. 133\n3.2. Gestion du projet merchandising. 143\n3.3. Illustration de la démarche. 153\n3.4. Intégration dans le Système d’Information existant. 190\n3.5. Mise en œuvre de l’architecture J2EE. 207\n3.6. Réalisation des tests de montée en charge. 210\n4. Bilan. 225\n4.1. Bilan ETL. 225\n4.2. Bilan J2EE. 230\n4.3. Bilan Architecture Web J2EE. 236\n4.4. Bilan Test de Charge. 241\n4.5. Bilan Rails. 244\n4.6. Bilan Gestion du projet 245\nAnnexe A : Exemples de développement ETL GENIO.. 300\nAnnexe B : Exemple de développement VBIS. 310\nAnnexe C : Exemple de développement J2EE. 320\nAnnexe D : Résultats des tests de montée en charge. 350\nAnnexe E : Publications dans Monop Infos, magazine interne, entre octobre 2005 et avril 2007. . 356\nAnnexe F : MLD de GDP. 363\nAnnexe G : Versions des logiciels. 366\nAnnexe H : Exemples de dossier de préconisations. 367\nAnnexe I : Illustration correspondant à un plan magasin. 374\nAnnexe J : Cartographie de l’application merchandising. 375\nAnnexe K : Liste des tables des bases de données de l’application spécifique. 378\nAnnexe L : Scoring correspondant au choix du logiciel 385\nAnnexe M : Cartographie macroscopique du Système d’Information de Monoprix. 389\nAnnexe N : Présentation des fonctionnalités principales du progiciel de KLEE. 392\nAnnexe O : Présentation des écrans de l’application spécifique. 417\nAnnexe P : MPD.. 449\nAnnexe Q : RAILS - contrôleur RO et CRUD CLASSIQUE. 467\nAnnexe R : Processus du projet – diagrammes d’activité. 499\nAujourd’hui, de nombreuses entreprises choisissent les meilleurs outils informatiques pour répondre à leurs besoins afin d’être le plus compétitif possible. Elles se dotent ainsi d’ERP ( Entreprise Resource Planning ) ou de suites logicielles spécialisées. En suivant cette démarche, leurs systèmes d’information gagnent en complexité. Choisir la meilleure solution pour répondre à chacun de ses besoins multiplie le nombre de technologies et de standards utilisés au sein de l’entreprise.\nNous allons nous intéresser aux problématiques liées à cette démarche d’entreprise, à travers la mise en œuvre de la suite logicielle SMART Office au sein du groupe de distribution de proximité MONOPRIX. Cette suite permet d’élaborer des dossiers de merchandising fournissant des préconisations de mise en rayon des produits à l’attention des magasins.\nDans un premier temps seront présentés le projet, les grands principes du domaine fonctionnel lié au merchandising, les raisons de l’origine du projet, ses contraintes, ainsi que les étapes importantes du projet, l’étape pour arrêter un choix sur une offre logicielle particulière.\nUne présentation des méthodologies, technologies et concepts utilisés sera suivie par l’exposé de la mise en œuvre de l’application merchandising. La démarche pour mener à bien le projet sera précisée.\nAprès avoir choisi la suite logicielle qui semble correspondre le mieux à nos besoins, il reste à l’intégrer dans le Système d’Information existant. Il faut alors récolter l’information nécessaire au bon fonctionnement de la suite logicielle, puis fournir les éléments permettant de diffuser les dossiers de préconisations de mise en rayon aux magasins. Après une présentation du Système d’Information existant, nous nous attacherons aux moyens d’intégrer différentes applications d’entreprise, en particulier à l’aide d’ETL ( Extract Transform and Load) et d’EAI (Entreprise Application Integration), dont le point fort est de faire cohabiter des systèmes hétérogènes.\nMais ces produits ne suffisent pas à eux seuls à fournir une solution applicative complète, il faut également se doter d’interfaces, afin de pouvoir administrer l’intégration des informations récoltées, de diffuser les documents de préconisations réalisés et de suivre l’élaboration des dossiers de préconisations. Il est alors nécessaire d’organiser son application [JOU05a] et de choisir des outils de développement. Nous avions une volonté forte d’utiliser des outils permettant de rendre le code plus lisible et ainsi de simplifier la maintenance de ce dernier afin de ne pas se retrouver avec des développements de type « spaghetti ».\nSe pose ensuite la question de l’architecture à mettre en place, dans laquelle nous allons déployer les développements réalisés. En fonction du nombre d’utilisateurs que nous souhaitons supporter, de la lourdeur des développements, du temps de réponse attendu, du niveau de sécurité désiré et de la tolérance de panne exigée, quelle architecture devons-nous mettre en œuvre ? Nous présenterons alors la solution Open Source basée sur Apache et Tomcat.\nEnfin, comment pouvons-nous savoir que les développements réalisés et déployés dans l’architecture, ainsi que cette dernière, vont vraiment offrir la qualité de service attendu ? La réalisation de stress tests permettra de répondre à cette question. Nous présenterons alors ce que sont des stress tests, leur utilité, des offres du marché permettant de les réaliser, la démarche utilisée et leurs limites.\nLe projet a pour but de renouveler l’application de merchandising PGC (Produit Grande Consommation). Cette application est utilisée au sein de l’enseigne de distribution de proximité MONOPRIX par une cellule merchandising de 10 personnes.\nElle permet d’élaborer des dossiers de préconisations de mise en rayon à destination des 250 magasins du groupe.\nEn se dotant d’un outil plus perfectionné, l’entreprise souhaite réduire les coûts associés aux processus « métier » liés à l’élaboration des dossiers de préconisations. Elle compte ainsi augmenter la productivité en limitant les interactions humaines et en raccourcissant la durée de ces processus.\nL’élaboration des dossiers de préconisations implique de nombreux acteurs. Elle est faite par la cellule merchandising en collaboration avec les bureaux d’achat, le marketing, les fournisseurs et la direction des ventes.\nEn amont, l’achat élabore les collections. Le marketing fournit une stratégie. Les fournisseurs font des propositions dans leurs spécialités.\nEn aval, la cellule merchandising organise la mise en scène des produits et la vente exploite les dossiers de préconisations.\nEnfin, les merchandisers travaillent étroitement avec les fournisseurs qui procurent les visuels et les caractéristiques de leurs produits.\nLe schéma ci-dessous positionne l’application de merchandising par rapport aux principaux acteurs, applications et systèmes centraux auxquels elle se rapporte.\nFigure 1 : Vision Globale Acteurs, Applications, Systèmes centraux\nLe sujet de ce mémoire est la « réalisation d’un projet de merchandising ». Le merchandising n’est pas le sujet principal de ce mémoire. Nous allons nous intéresser plutôt aux aspects techniques qu’aux aspects fonctionnels et à la démarche qui a été suivie pour mener à bien ce projet.\nLes problématiques auxquelles nous allons nous attacher sont :\n· La gestion et le management de projet\n· La façon d’intégrer une suite logicielle au sein d’un Système d’Information hétérogène existant.\n· Le choix de technologies WEB et d’outils de développement. Ainsi que les raisons de ce choix.\n· Le choix d’une architecture WEB et la validation de cette architecture.\nLe projet merchandising va permettre d’illustrer ces quatre problématiques. L’objectif n’est pas d’exposer dans ses moindres détails les problématiques liées à ce projet mais plutôt de se servir de ce cas concret pour apporter des réponses à ces problématiques.\nLe but de ce mémoire n’est pas non plus de traiter de ces sujets de façon exhaustive, mais de se concentrer sur les points réellement abordés lors du projet et qui ont permis de le mener à bien et de répondre de façon satisfaisante aux besoins des utilisateurs. Compte tenu des délais et des impératifs du projet, il est difficilement possible de maîtriser pleinement l’ensemble des technologies et des logiciels qui vont être utilisés lors de ce projet.\nL’important est de saisir l’essentiel de ce qu’apporte chacun des outils utilisés et de s’en servir le plus simplement possible afin que le projet reste évolutif et facilement maintenable.\n1.1. Le merchandising\nLe merchandising correspond à l’ensemble des techniques visant à optimiser la répartition et la présentation des produits en magasin afin d’optimiser la rentabilité et le trafic et de contribuer à l’expression de l’image de l’enseigne.\nEn effet, pour arriver à élaborer des dossiers de préconisations de mise en rayons à destination des magasins, le merchandiser a besoin de nombreuses informations relatives :\naux produits : prix, dimensions, nomenclature, caractéristiques, images des produits\naux points de ventes : mobilier, capacité des linéaires, assortiments des produits correspondant au point de vente, historiques de vente du produit, colisage de livraison, périodicité de livraison\nd’un modèle de vente : écoulement des ventes sur la semaine\nLe travail du merchandiser consiste, à partir de ces informations et en partenariat avec les bureaux d’achat de l’entreprise et la direction des ventes, à proposer une répartition des produits en magasin afin de répondre pleinement aux ventes et à ne pas avoir de rupture de produit en rayon. Il va faire des préconisations sur le nombre de facings à accorder à un produit dans le linéaire du magasin et sur son emplacement. Ces préconisations se font à partir de données quantitatives dont nous avons fait une liste non exhaustive ci dessus et qui vont être extraites du Système d’Information de l’entreprise mais également de notions qualitatives telles que les couleurs des visuels correspondant aux différents produits. Le merchandiser va par exemple chercher à obtenir le meilleur rendu visuel afin de rendre la répartition des produits la plus agréable possible pour le consommateur. L’aspect visuel est donc une composante importante de l’élaboration des dossiers de préconisations.\nDossiers de préconisations\nLes dossiers de préconisations à destination des magasins présentent toujours le même type de structure :\nune page de garde (Figure 2)\nun argumentaire (Figure 3)\nune présentation du marché national et de l’enseigne, l’évolution du marché\ndes plans de masse (Figure 4)\nles planogrammes en couleurs avec les visuels des produits (Figure 5). Il existe plusieurs planogrammes en fonction du linéaire du magasin. Un planogramme correspond à une représentation graphique des mobiliers en magasin sur lesquels on a positionné des produits. Les produits sont facilement identifiables à l’aide de photos les représentant.\nListe des produits du planogramme (Figure 6): numéro de produit sur le planogramme, ean du produit, désignation, nombre total de facing, colisage de réassortiment du produit\n(correspond à la quantité minimale que l’on peut livrer au magasin).\nLe magasin, à l’aide de ces dossiers, optimise de manière rapide la rentabilité de son point de vente sans avoir à faire des analyses complexes et fastidieuses. En effet, ces dossiers sont le fruit d’une analyse conjointe du merchandising, des bureaux d’achats et de la direction des ventes qui tient compte de la capacité des linéaires, de la rotation des stocks et des nouveaux assortiments des produits. Ces dossiers facilitent donc le travail des magasins mais permettent également d’avoir une offre homogène sur l’ensemble des points de vente de l’enseigne. Ils facilitent donc la mise en place de la politique de marketing de l’entreprise.\nFigure 2 : Page de garde\nFigure 3 : Le marché\nFigure 4 : Plan de masse\nFigure 5 : Exemple de planogramme\nFigure 6 : Liste des produits du planogramme\nD’autres exemples de dossiers sont présents dans l’Annexe H.\n1.2. Pourquoi ce projet ?\nLa solution existante.\nL’outil existant utilisé par les marchandisers est une vieille version de l’outil SPACEMAN de la société Nielsen qui se compose d’une application autonome installée sur chacun des postes utilisateurs.\nLes merchandisers alimentent cette application à l’aide de fichiers au format EXCEL ou TXT (texte).\nLe processus « métier » d’élaboration utilisé pour élaborer les dossiers de préconisations à l’attention des magasins est le suivant (Figure 7) :\n(1) Les informations relatives aux produits et aux ventes sont obtenues à l’aide de BI Query anciennement nommé GQL qui est un requêteur du marché. Les données sont extraites sous la forme de fichier EXCEL.\n(2) Les classements des magasins par chiffre d’affaire par périmètre de produits sont extraits à partir du produit Arthur Décision de Comshare. Cette solution repose sur une base Oracle. Elle permet entre autres d’avoir une vision multidimensionnelle des ventes selon les axes produits, magasins, temps et manifestations (les campagnes promotionnelles telles que Noël, Halloween sont des manifestations). Ces classements sont utilisés pour constituer des groupes de magasins qui représentent au mieux le parc de points de vente. Il est en effet impossible de faire l’ensemble des dossiers de préconisations pour chacun des magasins. Il faudrait 2 merchandisers par magasin pour mettre à jour ces dossiers une fois par an, ce qui n’est pas envisageable (la cellule merchandising ne comporte que 10 personnes et il y a 250 magasins). Le merchandiser doit effectuer de nombreuses manipulations sur les classements des magasins et les ventes correspondant aux produits afin de pouvoir utiliser ces informations dans l’application et réaliser les planogrammes.\n(3) Un référentiel des différents périmètres de planogrammes et des linéaires associés est géré à l’aide de fichiers au format EXCEL.\n(4) Le merchandiser a également besoin des visuels correspondant à son périmètre de produit. S’il lui manque des visuels, il doit lui-même prendre les photos manquantes des produits. Les photos sont enregistrées sur chacun des postes des merchandisers et ne concernent que leur périmètre.\n(5) Le merchandiser peut alors se consacrer à l’élaboration des planogrammes et des dossiers en collaboration avec les bureaux d’achat et la direction des ventes.\n(6) Le dossier une fois terminé est envoyé à la reprographie qui va en tirer un exemplaire papier pour chacun des magasins. Un exemplaire de chaque dossier est livré en magasin sans tenir compte du fait que le magasin est concerné par tout ou partie du dossier de préconisations : on envoie tout à tout le monde.\nFigure 7 : L’outil d’élaboration existant\nLes axes d’optimisation\nAu vu de ce processus « métier », il est possible d’identifier un certain nombre d’axes d’optimisation.\nOn peut réduire les coûts liés à ce processus d’élaboration des dossiers de préconisations, en minimisant les interventions manuelles effectuées par les merchandisers. Cela passe par l’automatisation systématique des procédures manuelles qui peuvent l’être.\nLa centralisation de l’information relative aux planogrammes dans une base de données, la mise en place d’un référentiel image unique et pas de déploiement sur les postes clients de l’application ou un déploiement minimaliste permettent de simplifier et de minimiser les tâches d’administration.\nLe choix d’une solution logicielle possédant une interface simple et conviviale diminue la durée de montée en compétence des merchandisers.\nSi, de plus, cette solution répond à de nouveaux besoins non couverts par la solution actuelle tels que l’élaboration de dossiers de préconisations pour les surgelés qui sont présentés dans des meubles spécifiques, il est alors possible d’élargir les périmètres concernés par les dossiers de préconisations.\nLe fait de souscrire un abonnement images auprès d’une société extérieure pour les périmètres nouvellement traités évite aux merchandisers de prendre eux-même en photo les produits pour lesquels on ne possède pas de visuel.\nL’abandon de l’impression papier pour la diffusion des dossiers planogrammes au profit d’une diffusion au format PDF permet de ne plus imprimer et livrer des dossiers aux magasins qui ne sont pas concernés.\nDans la solution cible, rien ne doit être installé sur le poste client. L’utilisateur accède à un serveur distant à partir de son poste de travail. Il s’identifie sur ce serveur et accède à l’application merchandising qui permet d’élaborer les dossiers planogrammes.\nLe processus d’élaboration cible est le suivant (Figure 8) :\n(1,2) Les informations correspondant aux produits et aux ventes sont directement disponibles dans l’outil d’élaboration. Le classement des magasins est géré de façon transparente, le merchandiser n’a plus à s’en soucier. Il n’a plus à faire de manipulation fastidieuse pour obtenir de l’information utilisable.\n(3) Les informations anciennement gérées dans des fichiers autonomes seront gérées dans une base de donnée au travers d’une interface WEB.\n(4) Les visuels correspondant aux produits sont livrés par un prestataire extérieur auprès duquel on souscrit un abonnement. Chaque mois, on lui envoie la liste des produits. En retour, les images manquantes sont envoyées puis intégrées dans la base image.\n(5) Le merchandiser peut alors se consacrer à l’élaboration des planogrammes et des dossiers de préconisations en collaboration avec les bureaux d’achat et la direction des ventes.\n(6) Une fois qu’un merchandiser a achevé un dossier de préconisations, un administrateur fonctionnel met à disposition le dossier dans l’application de diffusion au travers d’une interface d’administration WEB. Le magasin peut alors récupérer le dossier à l’aide d’un navigateur WEB et l’imprimer au besoin. Les dossiers ne sont plus envoyés au service de reprographie, ni livrés sous format papier à l’ensemble des magasins.\nFigure 8 : L’outil d’élaboration cible\nL’automatisation d’un certain nombre de traitements permet d’éliminer de nombreuses interventions humaines et ainsi de réduire la durée du processus.\nLa gestion centralisée évite d’avoir un éclatement de l’information sur l’ensemble des postes utilisateurs. Cette gestion centralisée facilite les tâches d’administration.\nLa souscription d’un abonnement image et la mise à jour automatique de la base image libèrent les merchandisers de la gestion des images.\nLa mise en place d’une diffusion numérique des dossiers de préconisations permet aux magasins de les avoir plus rapidement. Il n’y a plus de livraison au magasin. Le magasin n’a plus qu’à choisir ce dont il a besoin via l’Intranet. Il peut alors imprimer les dossiers directement en magasin. De plus, il existe des gains financiers puisque cette diffusion entraîne une consommation de papier moins importante et permet de faire des économies en ne sollicitant plus le service de reprographie et le service courrier.\nCe nouveau processus « métier » va donc permettre de gagner du temps et de supprimer des tâches inutiles. On améliore ainsi la productivité du service merchandising. Le nombre de dossiers de préconisations de mise en rayon pourra être plus important en conservant le même effectif dans la cellule merchandising.\n1.3. Les contraintes\nLes contraintes pour mener à bien ce projet sont nombreuses et de natures diverses. Ces contraintes sont essentiellement techniques, politiques et financières.\nLe Système d’Information est hétérogène. Toutes les informations nécessaires ne sont pas gérées dans ce dernier. De nombreuses informations relatives au merchandising sont dispersées dans des fichiers EXCEL sur chacun des postes des merchandisers. Il n’existe pas de référentiel centralisé contenant ces informations.\nLes dossiers planogrammes nécessitent l’existence d’un référentiel image. Or, ce référentiel devrait se composer d’environ 46 000 images occupant plus de 10 Go d’espace disque. Ce qui exclut le fait de dupliquer ce référentiel sur chacun des postes, la taille de ce référentiel étant trop volumineuse.\nLa qualité visuelle de ces images est très importante, il est nécessaire que l’applicatif puisse au moins afficher 65 000 couleurs pour obtenir un rendu visuel acceptable.\nOutre ces contraintes techniques, la DSI (Direction des Systèmes d’Information) préconise fortement l’utilisation d’un certain nombre de solutions et de standards. Le choix d’ORACLE est préconisé pour les bases de données relationnelles, ainsi que de J2EE pour les développements Web. Ces préconisations ont pour but de limiter l’hétérogénéité du système.\nLa DSI a également adopté une politique de déploiement minimaliste des différentes applications à mettre en place sur les postes utilisateurs. C’est pourquoi les solutions Web sont préférées aux applications Clients – Serveur.\nEnfin, malgré l’importance du projet, les moyens mis à notre disposition pour mener à bien ce projet sont très limités. Et la pression sur les délais à respecter est très grande.\n1.4. Les étapes importantes du projet\nChoix de la suite logicielle\nLa première étape de ce projet a consisté à choisir la suite logicielle qui répondait au mieux aux besoins identifiés des utilisateurs ou qui pouvait facilement être adaptée aux spécificités propres de leur métier.\nNous tenions à ce que le logiciel présente une interface intuitive, simple, conviviale, ceci pour diminuer la durée d’appropriation de l’application, dans le but de raccourcir la courbe de montée en compétence des merchandisers. Ils seront plus vite opérationnels si on met à leur disposition un outil simple, plutôt qu’un outil complexe et peu ergonomique.\nNous avons donc comparé les offres des principaux acteurs du marché : Prospace de JDA, SMART Office de KLEE Commerce, Apollo d’IRI et Spaceman de Nielsen. Les offres ne reposant pas sur des bases de données relationnelles et ne permettant pas de gérer un référentiel centralisé ont immédiatement été écartées.\nLes deux offres qui sont alors restées en liste étaient Prospace de JDA et SMART Office de KLEE commerce. Elles ont été analysées de manière plus approfondie. Nous avons identifié l’ensemble des points fonctionnels et techniques auxquels devait répondre la suite logicielle. Des pondérations ont été attribuées à chacun de ces points en fonction de leur niveau d’importance. L’attribution de notes nous a alors permis d’effectuer un scoring des deux solutions et de choisir, en fonction des résultats, la suite qui correspondait le mieux à nos attentes. Le scoring utilisé est fourni dans l’Annexe L.\nNotre choix s’est porté sur l’offre SMART Office de KLEE Commerce. C’est cette suite qui semblait répondre le mieux aux contraintes que nous avions et qui permettait d’améliorer au mieux le processus d’élaboration des planogrammes, selon les axes d’optimisation identifiés préalablement.\nCependant, cette suite ne permettait pas d’éviter les interventions sur les postes clients. En effet, on doit installer un applicatif client sur chacun des postes des utilisateurs. Ce problème a été contourné par l’utilisation de la technologie TSE de Microsoft. Cette technologie permet d’accéder à partir de n’importe quel poste Windows 2000, 2003 ou XP à des bureaux distants gérés par un serveur distant. Nous avons donc pu être en conformité avec les attentes de la DSI qui ne souhaitait pas d’intervention sur les postes clients.\nD’autres critères plus subjectifs ont également joué un rôle dans le choix du produit, tels que la disponibilité et la réactivité de l’éditeur, et aussi le fait que l’éditeur puisse fournir des prestations complémentaires comme un abonnement image. L’éditeur livre chaque mois les visuels des produits sous forme numérique correspondant à un certain périmètre.\nL’offre de KLEE repose sur un référentiel composé d’une base image, d’une base relationnelle de type ORACLE et d’un ensemble de modules. Les modules vont permettre d’administrer la base image, d’élaborer les dossiers planogrammes, de gérer la base de données et d’extraire de l’information de façon automatique.\nFigure 9 : Architecture de la suite logicielle SMART Office\nIntégration de cette suite dans le système\nLa seconde étape consiste à intégrer cette suite logicielle dans le Système d’Information existant. Il est possible d’alimenter les bases de données à l’aide de fichiers « texte » en paramétrant des fichiers XML, ce qui permet d’être assez souple au niveau de l’alimentation des données. Il ne reste donc plus qu’à collecter l’information nécessaire à l’élaboration des planogrammes.\nNous avons donc identifié les traitements à mettre en place pour alimenter le référentiel et précisé la fréquence à laquelle ils devaient être exécutés.\nLes grands groupes de traitements sont les suivants :\n· alimentation des informations relatives aux produits\n· récupération des classements des magasins en terme de ventes par ensemble de produits\n· récupération des ventes par produit correspondant à chacun des magasins\n· envoi de la liste des produits présents dans le référentiel à l’éditeur afin de recevoir les visuels des produits correspondant à l’abonnement image souscrit.\nHormis l’alimentation des informations relatives aux produits qui est exécutée chaque jour de la semaine, les autres traitements sont mensuels.\nEtant donné que l’information présente dans le Système d’Information n’est pas directement exploitable, nous avons, avant de créer les fichiers qui serviront à alimenter le référentiel de l’offre de KLEE Commerce, mis en place un Datamart.\nFigure 10 : Mise en place d’un Datamart\nC’est une base de données qui contient toutes les informations relatives au merchandising et à l’historique des ventes sur une période d’un an permettant l’élaboration des planogrammes. Ce Datamart était initialement prévu pour fournir le bon niveau d’agrégation de l’information nécessaire à la suite SMART Office. Mais, la prise en compte d’évolutions fonctionnelles telles que la gestion de regroupements particuliers de produits en univers ont eu pour conséquence d’élargir son utilisation à la gestion de notions propres au merchandising qui n’étaient pas gérées dans le Système d’Information existant.\nLa gestion des univers, qui sont des regroupements de produits propres au merchandising, permet de gérer des périmètres de produits correspondant exactement aux dossiers planogrammes envoyés aux magasins. Ce qui n’était pas le cas jusqu’alors, les périmètres des dossiers correspondaient à des regroupements de sous-ensembles de nomenclature produit utilisés dans l’entreprise. Ces regroupements étaient difficilement gérables par les merchandisers.\nOn veut également gérer, dans cette base, la liste des dossiers planogrammes et leurs caractéristiques telles que leurs fréquences de mise à jour ou la personne en charge du planogramme. Jusqu’à présent, cette gestion était faite à l’aide de fichiers EXCEL.\nLe fait de vouloir diffuser les planogrammes sous forme de fichiers PDF via l’intranet oblige également à gérer un ensemble de notions : une arborescence de diffusion, une identification des magasins pour pouvoir ensuite filtrer la liste des dossiers proposés en fonction de leurs caractéristiques.\nLa gestion de ces notions ne pouvait pas se faire dans l’offre SMART Office de KLEE Commerce car elles revêtent un caractère « métier » qui n’a pas lieu d’être géré dans un tel outil. Il est important que cet outil reste indépendant des données propres de l’entreprise.\nMise en œuvre d’interfaces Web\nLe fait de gérer ces notions au niveau du Datamart oblige à se doter d’interfaces qui vont permettre de les administrer et de suivre la bonne exécution des différents traitements.\nPour cela, il est nécessaire de choisir des normes et des outils de développement, de mettre en place une architecture et de valider cette architecture à l’aide d’un outil de stress test que nous aurons préalablement sélectionné. Cette validation servira à s’assurer que l’application offre la qualité de service attendu pour éviter de se retrouver avec un système indisponible le jour de sa mise en production parce qu’il n’aura pas tenu la charge générée par les utilisateurs.\n2. Présentation des méthodologies, technologies et concepts utilisés\n2.1. Gestion et management de projet\nLa gestion de projet informatique est fondée sur des travaux de modélisation et de collaboration. Un client demande à un fournisseur, qu’il soit interne ou externe à l’entreprise, de mettre en place une solution à sa problématique au travers d’un modèle. Les deux parties prenantes doivent alors collaborer en bonne intelligence afin d’atteindre un objectif commun.\nL’Informatique est une discipline jeune en comparaison des domaines millénaires du bâtiment et des systèmes de collaborations militaires. La réalisation d’un projet informatique traditionnel suppose en général la maîtrise des techniques de planification, des connaissances en ISO 9001 et d’UML. Il existe de nombreuses normes et méthodes utilisables dans la réalisation d’un projet informatique. On constate cependant que ces normes et ces méthodes convergent aujourd’hui vers certaines méthodes et techniques telles que les Design patterns, UML ou Java. Par le respect de règles et méthodes, on cherche à produire des solutions de qualité documentées afin de répondre aux problématiques rencontrées par les entreprises. La documentation est perçue comme un facteur permettant de contribuer à l’obtention d’une solution de qualité mais elle représente parfois un coût important.\nLa qualité de la collaboration et le maintien du dialogue entre le client et les fournisseurs d’un projet sont des conditions indispensables au bon déroulement du projet. La bonne réussite d’un projet informatique repose sur cette collaboration. Si le client est satisfait, il sera confiant et, en général, permettra au fournisseur d’être plus libre dans sa gestion de projet. Pour remplir pleinement son rôle le fournisseur doit se mettre à la place de son client. Il pourra ainsi effectuer une analyse pertinente de la problématique à laquelle il est confronté et répondre pleinement aux contraintes fonctionnelles et techniques. Le fournisseur doit avant tout préciser avec le client le contexte du projet et en définir le contenu. Il est nécessaire de bien définir l’alignement stratégique du projet et de dégager les différents processus « métier » cibles, ainsi que les règles « métier » associées.\nSuite à cette phase de pré étude, les dirigeants d’une entreprise décident ou non de lancer le projet.\nDans le cas d’une décision favorable, il faut conduire le projet. Il est alors nécessaire de mettre en place une organisation et une méthodologie de gestion de projet. Les grandes lignes de cette méthodologie consistent à analyser les besoins, évaluer les charges, définir et suivre les différents incréments à mettre en place, identifier et gérer les risques, définir l’architecture technique et applicative, gérer au mieux la réutilisation, et maîtriser les ressources humaines ainsi que les ressources logicielles.\nIl existe plusieurs types de projet : les projets de développement, les projets d’intégration et les projets de déploiement. Certains projets peuvent appartenir à plusieurs de ces types.\nC’est entre autres le cas du projet merchandising. Dans ce projet, il a été nécessaire de mettre en place une solution spécifique au travers de développement, d’intégrer un progiciel dans le Système d’Information de l’entreprise et de déployer ces solutions au sein de l’entreprise.\nIl est crucial que le projet ait un objectif clairement défini, limité et unique. En général, un projet est caractérisé par un niveau de complexité important. On peut caractériser cette complexité en identifiant les charges globales, les savoir-faire requis et les risques encourus.\nLes limites du projet doivent être définies de manière précise en terme de délais, de moyens financiers, de ressources et de personnels.\nLa gestion d’un projet Informatique commence par la précision du contexte, des acteurs, de leurs interactions et l’identification des processus « métier ». On s’intéresse tout d’abord à définir la démarche projet. Le projet suit un cycle de vie. Des modèles et méthodes sont utilisés pour décrire son contenu.\nLe cycle de vie comporte plusieurs étapes :\n· Pré étude\n· Evaluation des besoins et des charges\nDécomposition en tâches et détermination de lots.\nAssocier des coûts aux tâches. Déterminer des rubriques budgétaires globales et des réserves.\n· Rédaction de l’offre et du contrat\nDémarrage officiel du projet pour canaliser l’énergie des différents acteurs.\nDétermination d’un échéancier et du calendrier.\n· Implémentation et tests\nOn peut différencier les cycles de vie correspondant à des développements spécifiques ou à des développements de progiciel.\nCes deux types de développements se différencient essentiellement sur la phase de développement. Les phases de définition, d’exploitation, d’utilisation, de maintenance et d’évolution sont gérées de manière identique. Dans le premier cas, il s’agit de mener une étude préalable, suivie d’une étude détaillée, d’une étude technique de mise en œuvre et de la mise en œuvre à proprement parler. Dans le second cas, il s’agit de choisir un progiciel, d’effectuer le paramétrage afin de répondre au besoin, de tester les adaptations effectuées.\nD’autre part, dans le cas du développement d’un logiciel spécifique au sein d’une entreprise, la phase de « rédaction de l’offre et du contrat » est moins formelle.\n2.2. Les modèles et les méthodes\nIl existe plusieurs modèles de déroulements type de projet . Le déroulement d’un projet dépend de sa nature et de son contexte. Il n’y a pas de méthode universelle qui puisse être appliquée à tous les projets. On peut différencier deux types de méthodes de gestion de projets. Les méthodes traditionnelles suivent des cycles séquentiels et sont basées sur des contrats. Les méthodes plus modernes positionnent l’utilisateur comme un acteur clef du projet et préfèrent satisfaire ce dernier plutôt qu’honorer les clauses d’un contrat.\nCi-dessous, un diagramme illustrant le déroulement type d’un projet traditionnel [MAN06].\nFigure 11 : Déroulement type d’un projet traditionnel\nCycles de projet\nLors de la réalisation d’un logiciel, plusieurs types de cycles de développement sont possibles. Les grandes familles sont les cycles en cascade, les cycles en V et les cycles itératifs.\nFigure 12 : Cycle de vie en cascade\nCe cycle de vie en cascade (Figure 12) est hérité du bâtiment. Les phases traditionnelles de développement sont effectuées les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle. Chacune des phases produit des livrables définis au préalable et se termine à une date précise. Une étape de validation et de vérification des livrables permet de terminer une phase.\nFigure 13 : Cycle de vie en V\nDepuis les années 1980, le cycle en V (Figure 13) est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet.\nCe cycle limite les retours aux étapes précédentes afin de pallier le problème de réactivité du modèle en cascade. Les phases de la partie montante, renvoient de l'information sur les phases en vis-à-vis. Les livrables des étapes montantes sont préparés dans les étapes descendantes. Par exemple, les livrables des tests de validation sont définis lors des spécifications.\nFigure 14 : Cycle de vie itératif\nLe produit issu d'une activité est appelé un artéfact. On distingue les activités des artéfacts. Un cycle de type roue de Deming est appliqué sur la production des livrables : documentation, code, test.\nDans le cas d’une gestion de projet, on étudie la faisabilité d’un nouveau besoin. On élabore une solution. Une phase de fabrication permet ensuite de construire cette solution. La livraison au client correspond à la transition.\nDans un cycle itératif (Figure 14 ci dessus), les phases de faisabilité, d’élaboration, de fabrication et de transition correspondent respectivement aux phases de spécifications, de détermination de l’architecture, de développement et de tests. L'objectif est d’effectuer au plus tôt les livraisons au client afin qu’il puisse effectuer une recette.\nUne itération est plus courte et régulière qu'une roue de Deming (PDCA) qui, appliquée à une organisation importante, peut prendre plusieurs années.\nLe cycle en V a pour origine l'industrie lourde. Les phases de validation sont importantes car les phases successives du projet sont de plus en plus lourdes. Dans le cas de gros projets réunissant un nombre important de personnes, les décisions de la direction ou des architectes ont tellement d’impact en terme de charge et de durée qu'il est important de s'assurer de la validité de chacune des étapes.\nDans le cas d'un projet logiciel impliquant peu de personnes sur des durées courtes de l’ordre d’une à deux années, on dispose d'une plus grande réactivité du fait de la proximité géographique et d’une communication facilitée compte tenu de la taille de l’équipe. De plus, les coûts sont plus limités entre chaque étape. Dans ce contexte, il est possible d’utiliser des méthodes de développement dites agiles en diminuant le formalisme et en multipliant le nombre de cycles.\nTests et validation des logiciels\nLes tests sont une activité centrale. Ils permettent d’améliorer la qualité des logiciels. Le maître d’œuvre d’un projet peut mettre une stratégie de test en place qui se compose de tests unitaires, tests d’intégration, de vérification et de validation.\nLa validation met en évidence les défauts d’un logiciel et sa conformité par rapport à ses spécifications. Cette étape permet de gérer les anomalies, d’évaluer la conformité fonctionnelle et la fiabilité du logiciel.\nIl existe deux grandes familles de tests. Les tests fonctionnels qui permettent d’évaluer l’ergonomique, la robustesse, la réponse au stress ou le niveau de performance d’un logiciel et les tests structurels qui permettent des analyses de la couverture du code, des analyses statistiques ou des analyses de complexités. Ces différents tests peuvent être automatisés. Des outils permettent l’automatisation de tests, la capture et le rejeu (Opensta, Selenium), ou encore l’analyse de couverture (RCOV pour ruby).\nD’autre part, des techniques de vérification telles que les revues peuvent être effectuées par le client. A l’aide de ces revues, les dérapages sont limités, voire évités. Les coûts sont réduits par la correction des problèmes des résultats intermédiaires. Le résultat obtenu correspond d’avantage au résultat attendu. De plus, ces revues permettent de partager les responsabilités du projet entre le client et le fournisseur.\nLa réalisation de test permet de détecter les erreurs. Mais cette détection doit être réalisée au plus tôt. Plus une erreur est détectée tôt moins elle est coûteuse à corriger. Le coût de la correction d’une erreur au niveau de l’analyse est beaucoup moins important que le coût de la correction d’une erreur au niveau de la conception. Si la correction de cette erreur s’effectue dans les phases d’implémentation ou d’exploitation, les coûts de correction peuvent être 1000 fois plus importants.\nMéthode Agile : panorama des principales méthodes\nUne méthode agile est une méthode de développement informatique [BEN05]. Le client est impliqué un maximum dans le projet. La réactivité aux demandes est donc très bonne. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. On cherche à satisfaire un client plutôt que les clauses d’un contrat.\nLa méthode recherche la production d’un code de qualité. Les développements sont guidés par les tests.\nL’objectif de ces méthodes est de permettre de mieux maîtriser les délais, les coûts et la production des projets informatiques.\nLes développements sont effectués de façon itérative et incrémentale.\nLa méthode RAD est à l’origine des méthodes agiles. Les méthodes agiles sont le résultat de la recherche d’approches plus adaptées aux nouvelles technologies dans lesquels des cycles courts sont favorisés.\nLes méthodes agiles prônent 4 valeurs fondamentales qui sont présentées dans le manifeste agile:\n· L'équipe : « Personnes et interaction plutôt que processus et outils »\n· L'application : « Logiciel fonctionnel plutôt que documentation complète »\n· La collaboration : « Collaboration avec le client plutôt que négociation de contrat »\n· L'acceptation du changement : « Réagir au changement plutôt que suivre un plan »\nLes 4 valeurs se déclinent en 12 principes :\n· « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles ».\n· « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ».\n· « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ».\n· « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ».\n· « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail ».\n· « La méthode la plus efficace de transmettre l'information est une conversation en face à face ».\n· « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ».\n· « Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ».\n· « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité ».\n· « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle ».\n· « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto organisent ».\n· « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accordé et ajuste son comportement dans ce sens ».\nUn panorama des principales méthodes : RAD, Crystal Clear, Scrum, DSDM, XP, UP, RUP est présenté ci-dessous.\nRAD est l’acronyme de Rapid Application Development. C’est une méthode de développement de logiciels dont le cycle de développement est très court. Elle a été développée par James Martin dans les années 1980.\nLa réalisation et les tests de l’application sont effectués par morceau à intervalles réguliers. Dans cette méthode, des environnements graphiques sont utilisés afin d'obtenir rapidement des prototypes.\nCrystal clear est une méthode de gestion de projet crée par Alistair Cockburn. Cette méthode est adaptable aux spécificités des projets. Elle repose sur un certain nombre de principes auquel doit adhérer l'ensemble de l'équipe :\nLa communication a une place importante dans le projet afin de faire collaborer les différents acteurs du projet de manière efficace.\nLe nombre des membres d'une équipe est limité à six personnes pour améliorer la solidarité.\nl'équipe travaille dans une même pièce pour que la proximité facilite la communication.\nLes schémas de modélisation sont effectués en groupe sur tableau blanc pour une meilleure communication et une meilleure collaboration.\nLa collaboration avec le client est très importante. Les discussions entre les utilisateurs et les développeurs sont nombreuses.\nDes parties exécutables de l'application sont livrées fréquemment. Le client peut ainsi se rendre compte de l’avancement du projet et faire des retours sur les livraisons.\nLa méthode Crystal clear reste très souple au niveau des procédures à suivre et des normes à utiliser. La procédure est découpée en différentes étapes :\nLes utilisateurs sont observés dans leur travail afin de mieux comprendre leurs besoins et leur contexte. Les fonctionnalités sont classées par ordre de priorité en collaboration avec les utilisateurs. Les fonctionnalités avec la plus haute priorité sont développées en premier.\nAu début du projet, une ébauche de conception et une ébauche d’architecture sont réalisées.\nOn planifie les dates des itérations. Des livrables fonctionnelles sont définies à la fin de chacune d’elles.\nLa réalisation proprement dite de l'application se fait durant les itérations.\nLa méthode Crystal clear présente tous les avantages des méthodes agiles : flexibilité par rapport au changement, rapidité, livraisons fréquentes. Elle convient aux petites structures. Elle est très efficace dans les projets de petite taille mais n’est pas adéquate pour des projets importants.\nScrum est une méthode agile pour la gestion de projets. Elle a été conçue pour améliorer la productivité en évitant de paralyser les équipes par l’emploi de méthodologies trop lourdes.\nKen Schwaber et Jeff Sutherland ont mis au point les grands principes de Scrum au début des années 1990.\nLe terme Scrum est emprunté au rugby et signifie mêlée. L’utilisation de ce terme est une analogie au rugby du fait que le processus s'articule autour d'une équipe soudée, qui cherche à atteindre un but.\nDans cette méthode, on focalise l'équipe de façon itérative sur un ensemble de fonctionnalités. L’équipe doit réaliser ces fonctionnalités durant des itérations de l’ordre de 30 jours appelées Sprints.\nUn but à atteindre est défini dans chaque Sprint. On détermine un ensemble de fonctionnalités à implémenter. Le sprint aboutit à la livraison d'un produit proposant les nouvelles fonctionnalités.\nUn ScrumMaster a pour rôle de réduire les perturbations extérieures et de résoudre les problématiques non techniques de l'équipe.\nLe client participe de façon active. Il priorise la réalisation des fonctionnalités du logiciel. Il a la possibilité de changer la liste des fonctionnalités désirées à condition qu’elles ne soient pas en cours de réalisation.\nDynamic Systems Development Method (DSDM) est une méthode de gestion de projet de la catégorie des méthodes agiles. Cette méthode a été développée en Grande-Bretagne à partir de 1994\nLa méthode DSDM s'appuie sur 9 principes de base :\n· Implication des utilisateurs durant tout le cycle de développement. Ils font partie de l'équipe projet.\n· Autonomie. L'évolution des besoins peut être influencée par l’équipe projet.\n· Visibilité du résultat. Un feed-back rapide est possible par des livraisons fréquentes.\n· Adéquation. On cherche à livrer une application en adéquation avec le besoin « métier » du client.\n· Développement itératif et incrémental. L'évolution du développement est basée sur le feed-back des utilisateurs.\n· Réversibilité. Toute modification effectuée durant le développement doit être réversible.\n· Synthèse. Un schéma directeur définit le périmètre et les grandes lignes du projet.\n· Tests. Les tests sont effectués en continu, en parallèle du développement.\n· Coopération. Il est nécessaire d’être souple par rapport aux modifications des fonctionnalités demandées.\nL'Extreme Programming (XP) est une méthode agile de gestion de projet informatique [BEN05]. Elle est adaptée aux équipes de petite taille qui sont confrontées à des besoins changeants. Des principes simples sont poussés à l'extrême.\nL'Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries pendant un projet "C3" de calcul des rémunérations chez Chrysler entre 1996 et 1999.\nLe but principal est de réduire les coûts liés au changement. Dans les méthodes traditionnelles, les besoins sont définis et fixés, au départ du projet. Les coûts ultérieurs de modifications s’en trouvent accrus. Cette méthode fait en sorte de rendre le projet plus flexible et ouvert au changement. Elle introduit des valeurs de base et des principes. Elle repose sur un certain nombre de pratiques.\nElle utilise des principes qui ne sont pas nouveaux mais elle les pousse à l'extrême :\n· la revue de code est permanente et effectuée par binôme\n· les tests sont systématiques et effectués avant chaque implémentation\n· la conception se fait tout au long du projet (refactoring)\n· on choisit toujours la solution la plus simple\n· l’emploi de métaphores permet d’améliorer la compréhension\n· l'intégration des modifications s’effectue plusieurs fois par jour\n· pour s’adapter au changement, les cycles de développement sont très rapides.\nLes cycles de développement rapides impliquent des itérations très courtes qui peuvent durer moins d’une semaine. Une itération se compose d’un ensemble d’étapes qui permettent de :\n· déterminer les scénarios clients de l’itération\n· transformer les scénarios en tâches à réaliser et de déterminer les tests fonctionnels correspondants\n· réaliser les tâches en binôme\n· valider et livrer les fonctionnalités développées au client\nTant que le client fournit des scénarios, le cycle se répète. La première livraison est en générale la plus longue à réaliser mais peut aboutir après quelques itérations. Après avoir mis en production, les itérations peuvent être encore plus fréquentes.\nProcessus Unifié (PU) ou en anglais Unified Process (UP) est une méthode de prise en charge du cycle de vie des logiciels orientés objets. Elle est générique, itérative et incrémentale, contrairement à Merise ou SADT qui sont des méthodes séquentielles.\nRUP, proposé par la société Rational, est l’une des plus célèbres implémentations de la méthode PU. C’est une solution livrée clés en main qui permet d’avoir un cadre de développement logiciel. Cette méthode est guidée par les besoins des utilisateurs et centrée sur l’architecture logicielle.\nLes processus unifiés utilisent UML. UML est un langage de modélisation. Mais UML ne prend pas en charge le cycle de vie du logiciel, le processus de création et de conception des modèles. La prise en compte de la diversité des projets, des problématiques, des équipes et des cultures d’entreprise dans une seule et unique méthode n’étant pas aisée, PU tente de couvrir cette lacune. PU est générique et possède de nombreux avatars afin de répondre à la diversité des situations :\n· RUP : Rational Unified Process, processus défini par la société Rational Software (IBM)\n· EUP : Enterprise Unified Process, processus intégrant les phases de post-implantation et décrivant le cycle de vie du logiciel\n· XUP : Extreme Unified Process, processus intégrant UP avec l’extreme programming.\n· AUP : Agile Unified Process, processus mettant l’accent sur l’agilité des développements. Il s’appuye plus sur l’optimisation et l’efficience sur le terrain que sur la modélisation\n· 2TUP : Two Tracks Unified Process, processus proposé par Valtech prenant en compte les aléas et contraintes liés aux changements perpétuels et rapides des SI des entreprises.\n· EssUP : Essential Unified Process, par Ivar Jacobson, à l’initiative d'UML et RUP. Ce processus unifié intègre certains concepts des méthodes Agile.\nRUP repose sur 6 principes :\n· développement itératif\n· traitement et formalisation des exigences\n· architecture à base de composant\n· modélisation visuelle\n· vérification de la qualité du logiciel\nRUP est caractérisé par un découpage temporel en phases et itérations, l’utilisation d’un support entièrement informatique et un aspect générique et paramétrable.\nUML signifie Langage de Modélisation Unifié (Unified Modeling Language) [ROQ00] [ROQ07]. C’est un langage graphique de modélisation. Il représente une formalisation très aboutie et non propriétaire de la modélisation objet utilisée en génie logiciel. UML n'est pas une méthode.\nUML est issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson. Il est né de la fusion des langages de modélisation objet Booch, OMT, OOSE. UML est un standard défini par l'OMG (Object Management Group).\nLe modèle UML 2 est composé de 13 types de diagrammes alors que UML 1.3 n’en comportait que 9.\nUML se décompose en plusieurs sous-ensembles : les vues, les diagrammes et les modèles d’éléments.\nLes vues décrivent le système d'un point de vue donné (organisationnel, dynamique, temporel, architectural, géographique, logique …). Les vues sont des notions abstraites. La combinaison de ces vues définit le système complet.\nLes diagrammes décrivent le contenu des vues à l’aide d’éléments graphiques. Les diagrammes peuvent faire partie de plusieurs vues.\nLes modèles d'éléments tels que les cas d'utilisation, les classes ou les associations permettent d’élaborer les diagrammes UML.\nUne façon de mettre en oeuvre UML est de considérer différentes vues superposables pour collaborer à la définition du système : vue d’implémentation, vue logique, vue des cas d’utilisation, vue de déploiement et vue des processus (Voir Figure 15).\nFigure 15 : Les différentes vues dans UML\n· Vue des cas d'utilisation :\nElle représente le point de vue des acteurs du système et correspond aux besoins.\n· Vue logique :\nOn définit le système de l’intérieur. Elle explique la manière de satisfaire les besoins utilisateurs.\n· Vue d'implémentation :\nElle permet de définir les dépendances entre les modules.\n· Vue des processus :\nElle met en œuvre les notions de tâches concurrentes, stimuli, contrôles et synchronisations. Elle couvre des aspects temporels et techniques.\n· Vue de déploiement :\nElle décrit la position géographique et l'architecture physique de chacun des éléments du système.\nCes différents points de vues permettent de répondre aux questions suivantes : Quoi ? Qui ? Comment ? Où ? Seul le pourquoi n’est pas défini à l’aide d’UML.\nLes 13 diagrammes UML sont dépendants hiérarchiquement et se complètent (voir Figure 16 et Tableau 1). Ci-dessous est présentée la hiérarchie des diagrammes UML 2.0 sous forme d'un diagramme de classes.\nFigure 16 : La hiérarchie des diagrammes UML 2.0\nTableau 1 : Diagrammes UML 2.0\nNom du diagramme\nDiagrammes Structurels ou Diagrammes statiques (Structure Diagram)\nIl représente les classes intervenant dans le système.\nIl sert à représenter les objets utilisés dans le système.\nIl décrit le point de vue physique des composants du système. Il présente, en particulier, leur mise en œuvre (fichiers, bibliothèques, bases de données...)\nIl représente les éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage...), la répartition des composants du système sur ces éléments matériels et la façon dont ils interagissent.\nIl permet de représenter les dépendances entre regroupement d’éléments, ainsi qu’entre packages.\nLes relations entre composants d'une classe sont décrites sous forme de boîtes blanches.\nDiagrammes Comportementaux ou Diagrammes dynamiques (Behavior Diagram)\nIl identifie les possibilités d'interaction entre le système et les acteurs. Les fonctionnalités que doit fournir le système sont alors précisées.\nDiagramme états transitions\nLe comportement du système ou de ses composants est décrit sous forme de machine à états finis.\nLe comportement du système ou de ses composants est décrit sous forme de flux ou d'enchaînements d'activités.\nDiagramme d'interactions (Interaction Diagram)\nLe déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs est représenté de manière séquentielle.\nC’est un diagramme de séquence simplifié qui se concentre sur les échanges de messages entre les objets.\nCe diagramme décrit les enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences. Un diagramme de séquence est une variante du diagramme d’activité.\nIl décrit les variations d'une donnée au cours du temps.\nCi-dessous un tableau récapitulant les différents diagrammes utilisés en fonction des vues.\nTableau 2 : Diagrammes en fonction des vues\nDiagramme de classes et d’objets\nVue cas d’utilisation\nDiagramme d’activité, séquence, collaboration\nLe langage UML 2.0 a été lancé en 2003 [BOR04]. Il présente une avancée très intéressante du support de communication. On peut utiliser UML 2 comme on utilisait UML 1.3.\nUML 2 est très influencé par les processus MDA (Model Driven Architecture) et MDD (Model Driven Development). L'un des objectifs d’UML 2 est de parvenir à une automatisation du développement afin de passer directement du modèle au code source et donc de fournir un programme compilé, prêt à être lancé. C’est pourquoi les sémantiques des modèles UML ont été précisées afin d'éviter des problèmes d'interprétation. Selon le niveau d'abstraction, sans pour autant devoir programmer, les modèles se rapprochent des programmes eux-mêmes. Un autre objectif serait de générer également de façon automatique les tests cases qui accompagnent le programme.\nLe niveau d'abstraction du langage est donc plus élevé que dans la version précédente. UML 2 bénéficie d’un langage enrichi qui a été modularisé en différents sous langages qui peuvent être combinés.\nLa nouvelle version d’UML ajoute 4 autres diagrammes : le diagramme des paquetages (package diagram), le diagramme de structure composite (composite structure diagram), le diagramme global d'interaction (interaction overview) et le diagramme de temps (timing diagram).\nD’autre part, le diagramme de collaboration d'UML 1.4 est devenu diagramme de communication dans UML 2.0 et la plupart des diagrammes ont été revus pour répondre aux nouveaux besoins d’abstraction et d’automatisation...\n2TUP signifie 2 Track Unified Process [ROQ00] [ROQ07]. C’est un processus de développement logiciel qui implémente le Processus Unifié.\nLe 2TUP repose sur un cycle de développement en Y (Figure 17) permettant de dissocier les aspects techniques des aspects fonctionnels. Il commence par une étude préliminaire. Cette étude préliminaire permet d’identifier les acteurs qui vont interagir avec le système à construire, d’identifier les messages qu'échangent les acteurs et le système, de produire le cahier des charges et de modéliser le contexte. Ensuite, le processus s'articule autour de 3 phases essentielles : une phase technique (branche de droite), une phase fonctionnelle (branche de gauche) et une phase de réalisation.\nFigure 17 : Schéma en Y\nLe processus 2TUP repose sur une démarche itérative et incrémentale pour diminuer les risques et organiser la production des livrables. Il sépare les préoccupations fonctionnelles et techniques.\nLe processus 2TUP permet le développement de progiciels objet. C’est pour cette raison que l’analyse est très centrée sur la détermination de classes et que la modélisation objet est très présente dans chacune des étapes du processus (Tableau 3).\nTableau 3 : Description des différentes étapes du processus\nCapture initiale des besoins\nEffectuer un recueil initial des besoins fonctionnels et techniques\nPréciser le contexte, les acteurs, les interactions\nCompléter le recueil des besoins\nRechercher les classes candidates\nProduire un modèle des besoins\nQualifier les risques de non réponse aux besoins\nDéterminer les contraintes et les choix dimensionnant le système\nPrendre en compte des contraintes d’intégration\nPrendre en compte des contraintes techniques et logicielles\nDéterminer la configuration matérielle\nSélectionner les outils et les matériels\nDéfinir le style d’architecture en tiers\nEtablir la spécification logicielle (gestion des erreurs, sécurité, distribution, intégrité, utilisation de l’aide)\nDéfinir les couches logicielles (modèle en 5 couches et couche de synchronisation avec le SI)\nEtudier les spécifications fonctionnelles\nVeiller à ce que le résultat de l’analyse ne dépende d’aucune technologie\nDéfinir le modèle structurel d’analyse :\nDécouper les classes en catégories (cohérence, indépendance)\nDéfinir le modèle statique d’analyse :\nDétailler, compléter, optimiser les diagrammes de classes\nDéfinir le modèle dynamique :\nDéterminer la collaboration entre objets (diagramme interaction et diagramme d’état)\nItérer sur les deux derniers modèles\nDéfinir des composants nécessaires à l’architecture technique\nUniformiser et réutiliser les mêmes mécanismes pour tout le système\nDéterminer les Frameworks et les Design patterns\nOrganiser l’architecture technique et les composants\nVeiller à répondre à des objectifs de réutilisation, de fabrication et de déploiement\nDéterminer les couches, le modèle logique et le modèle d’exploitation\nValider avec un prototype\nIntégration de l’analyse et de la conception générique\nDéploiement du poste et des composants d’exploitation (composants distribués, applications, base de données)\nInterface EAI, intégration de progiciels\nIHM : vision précise des couches présentation et application\nCompléter la configuration logicielle\nDéterminer les modules\nEtudier comment réaliser chaque composant\nConcevoir et documenter le code qui va être produit\nProcessus de construction itératif qui s’applique successivement aux couches logicielles\nProduire les composants\nTester les unités de code\nEffectuer des tests d’intégration pour tester les IHM\nEffectuer des tests de recette pour valider les fonctions du système développé\nRéaliser la documentation à destination des différents acteurs : utilisateurs, administrateurs et personnes en charge du suivi d’exploitation…\nDiagramme UML dans 2TUP\nUML est utilisé pour modéliser le système. Ci-dessous, les diagrammes utilisés durant les différentes phases du processus.\nTableau 4 : Les diagrammes utilisés durant les différentes phases du processus.\nL’eXtreme Programming est une alternative à des méthodes plus lourdes dans le cas de projets de taille moyenne [BEN05]. Elle regroupe des bonnes pratiques de développement qui visent à améliorer la qualité des logiciels. Elle repose sur un processus projet en continu. Les phases de conception, de validation et d’intégration sont effectuées en continu. Des itérations sont effectuées au niveau du développement et des livraisons. Le code est sans cesse amélioré par la réécriture. Elle repose sur une rétroaction constante, le pilotage par les tests, une planification par les scénarios clients et l’intégration du client. Elle recherche une conception simple, s’appuie sur des conventions d’écriture et le code produit est une copropriété des membres de l’équipe. Les tests fonctionnels expriment les besoins et permettent d’effectuer la recette de l’application. Cette méthode recherche une meilleure maîtrise de l’environnement en s’inspirant du concept de cible mouvante (moving target).\nL’eXtreme Programming repose sur un ensemble de pratiques permettant de réaliser un logiciel, de la programmation à la planification. Cette méthode permet d’organiser l’équipe et de gérer les relations avec le client.\nElle est basée sur des principes qui ne sont pas nouveaux : livraisons fréquentes, relecture de code, tests automatiques.\nMais dans cette méthode, ces pratiques sont poussées à l’extrême.\nL’équipe se focalise sur la réalisation et ne perd pas son temps dans des activités imposées consommatrices de temps et de ressources comme la production de documents non exploités.\nLe contact humain est positionné au premier rang, dans l’équipe et avec le client.\nIl n’existe que très peu de projets pour lesquels les spécifications sont complètes et ne changent pas. Dans cette méthode, on n’attend pas d’avoir l’exhaustivité des spécifications pour commencer à réaliser l’application.\nLes modifications des spécifications du client sont acceptées et prises en compte tout au long du projet afin de répondre à ses besoins.\nXP définit 13 pratiques classées en 3 catégories :\n· les pratiques de programmation\no conception simple (simple design)\no remaniement (refactoring)\no développement piloté par les tests unitaires (unit tests)\no tests de recette (customer tests)\n· les pratiques de collaboration\no programmation en binômes (pair programming)\no responsabilité collective du code (collective code)\no règles de codage (coding standards, ownership)\no métaphore (metaphor)\no intégration continue (continuous integration)\n· les pratiques de gestion de projet\no livraisons fréquentes (frequent releases)\no planification itérative (planning game : planification effectuée par le client et l’équipe au cours de séances tout au long du projet)\no client sur site (on-site customer, whole team)\no rythme durable (sustainable pace)\nCes pratiques, plutôt d’ordre technique, sont destinées à mettre en place un environnement de travail basé sur les valeurs suivantes :\n· la communication pour une meilleure visibilité\nla communication directe est favorisée par rapport à l’écrit car elle permet un échange d’informations très important en un minimum de temps.\nLa documentation n’est cependant pas supprimée, elle est gérée comme un besoin comme un autre. Les différents problèmes rencontrés sont résolus par l’ensemble de l’équipe client et fournisseur.\n· la simplicité comme garantie de productivité\n· le feedback comme outil de réduction des risques\nL’objectif est d’améliorer continuellement le pilotage du projet.\n· le courage de prendre de bonnes décisions\nUne équipe XP doit remettre sans cesse en question ses méthodes de travail plutôt que de suivre des instructions à la lettre. Les pratiques XP doivent permettre l’amélioration de l’efficacité de l’équipe dans le respect des 4 valeurs d’XP.\nCompromis coût, délais, qualité, contenu.\nUn projet dépend de 4 variables interdépendantes : coût, délais, qualité, contenu [BEN05].\nLe fait de changer l’équipe ou l’environnement de travail peut à court terme ralentir l’équipe. La plupart du temps le coût d’un projet est fixé préalablement au lancement du projet, lors de la demande des budgets. Si le coût fixé est sous dimensionné, il y a de fortes chances que la qualité du logiciel en pâtisse. Les coûts de maintenance et d’indisponibilité, quant à eux, risquent d’exploser.\nDans la plupart des cas, la sous estimation du coût d’un projet peut conduire à une dérive conséquente des coûts. La détermination de coûts plus élevés dès le départ permet de limiter l’ampleur des dérapages.\nA l’opposé, si le coût du projet est sur dimensionné, on peut être amené à mettre en place une équipe trop importante qui sera difficile à coordonner. Et contrairement à ce que l’on espérait, la qualité de services sera dégradée et la durée du projet allongée.\nLe fait de repousser les dates de livraison peut induire des coûts de synchronisation et la confiance du client et de l’équipe peut s’en trouver diminuée.\nD’autre part, imposer des délais trop courts a pour conséquence de mettre la pression à l’équipe. Le risque est alors un manque de recul des membres de l’équipe et une baisse de leur niveau d’exigence.\nUne diminution du niveau de la qualité peut provoquer une démotivation de l’équipe ou une perte de la confiance du client qui finira par s’apercevoir de la dégradation du niveau de qualité. La démotivation de l’équipe peut avoir pour conséquence une augmentation du turn-over.\nCette dernière variable permet d’être très flexible. Il est possible d’adapter le contenu d’un projet en jouant sur le périmètre fonctionnel. La réduction du périmètre fonctionnel permet de conduire à une réduction des coûts, de la durée tout en préservant un niveau de qualité acceptable. C’est sur cette dernière variable que joue la méthode XP.\nEquilibre client et fournisseur\nUn équilibre doit s’instaurer entre les développeurs et le client.\nLe client ne doit pas avoir tous les pouvoirs sinon on tombe dans un projet « marche à mort » (deathmarch projet).\nL’équipe ne doit pas avoir trop de pouvoir sinon le projet risque de ne pas répondre aux besoins du client en cherchant à utiliser à tout prix les dernières technologies à la mode.\nDans une organisation XP, les responsabilités sont clairement séparées :\n· le client définit les fonctionnalités et leur ordre d’implémentation\n· les développeurs estiment les coûts et prennent en charge la réalisation\nLa mise en œuvre de la méthode XP peut être de chercher à résoudre les problèmes les plus sérieux de manière itérative et de traiter les problèmes restants jusqu’à parvenir à une situation stable.\nInfluence de la culture d’entreprise\nLa culture générale de l’entreprise est un facteur important de la réussite d’un projet XP.\nIl est difficile de tirer les bénéfices de la méthode XP dans le cas :\n· où le mérite se mesure aux heures supplémentaires et où on considère qu’une équipe ne fonctionne à plein rendement que sous forte pression\n· d’une culture centrée sur le jeu politique, où les relations de type gagnant / gagnant ne sont pas de mise\n· d’une culture attachée aux démarches linéaires où la qualité du logiciel s’exprime en nombre de documents produits.\nXP et le cycle en V\nUn comparatif simple entre le cycle en V et XP est effectué dans le tableau ci-dessous (Tableau 5).\nTableau 5 : Comparatif simple entre V et XP\nPartielle. Ajustement des spécifications à partir du feedback du client.\nA la fin de la conception\nTranche par tranche avec prise en compte du changement\nRésultat de la conception\nFabrication du logiciel\nSpécialisation des individus (spécification, conception, codage et tests)\nPolyvalence des individus. Chaque membre de l’équipe est responsable de l’ensemble de l’activité.\nXP et RUP\nUn comparatif simple entre RUP et XP est effectué dans le tableau ci-dessous (Tableau 6).\nTableau 6 : Comparatif simple entre XP et RUP\nDes valeurs et principes\nDes best practices\nRepose sur un cycle itératif\nItération sur des livraisons d’un logiciel incomplet\nItération sur des processus linéaires\nUn modèle en faisant l’abstraction du code\nCompléments de conception\nLors de la réalisation du projet, un certain nombre de compléments de conception peuvent être employés. On peut citer par exemple : les modèles de données Merise, les mappings ORM, la conception des écrans d’IHM, l’emploi de Design Patterns, l’utilisation de frameworks et la réutilisation de ce qui a déjà été mis en place.\nMerise est une méthode d'analyse, de conception et de gestion de projet. Son principal atout est d’être une méthode complètement intégrée. Elle fournit un cadre méthodologique et un langage. Elle est née dans les années 1970, à la demande du ministère de l'industrie. C’est une méthode spécifiquement française.\nElle préconise une analyse séparée des données et des traitements à plusieurs niveaux : conceptuel, logique et physique. Elle impose de vérifier la cohérence entre les deux analyses avant la validation et le passage au niveau suivant.\nElle est articulée simultanément selon 3 axes.\nLe projet suit :\n· un cycle de vie composé de phases de conception, de réalisation et de maintenance. Ensuite, un nouveau cycle de projet commence.\n· un cycle de décision comportant des choix : GO et NO GO.\n· Un cycle d'abstraction en trois parties : conceptuel, logique et physique. On prend d'abord les grandes décisions « métier » avant d’entrer dans les aspects techniques.\nDans cette méthode, on effectue une analyse critique de l'existant (démarche bottom-up), puis on décline la solution retenue (démarche top-down).\nCe recensement de l'existant allonge considérablement la durée du projet. Dans d’autres démarches reposant sur des méthodes itératives de type RAD ou sur l'adoption systématique des best practices observées dans d'autres entreprises, cette analyse préalable n’est pas effectuée.\nAu niveau conceptuel, on s'attache aux invariants de l'entreprise. On veut décrire, après l’abstraction, le modèle de l'entreprise ou de l'organisme.\nOn utilise alors deux types de schéma. Des schémas représentant la structure du Système d’Information du point de vue des données, les Modèles Conceptuels des Données (MCD) et des schémas représentant les traitements, les Modèles Conceptuels des Traitements (MCT).\nLe MCD repose sur les notions d'entités et d'associations et sur les notions de relations. L'entité est définie comme un objet de gestion. L'association ou relation est un lien sémantique entre une ou plusieurs entités.\nLe MCT repose sur les notions d'événements, d'opérations et de processus. L'événement est assimilable à un message. Un événement peut déclencher une opération ou être le résultat d'une opération. L'opération se déclenche sur un ou plusieurs évènements synchronisés. Elle est constituée d'un ensemble d'actions. Le processus correspond à un enchaînement d'opérations.\nAu niveau organisationnel, on précise comment on organise les données de l'entreprise et les tâches ou procédures.\nOn construit :\n· le Modèle Logique des Données (MLD) qui reprend le contenu du MCD mais précise la volumétrie, la structure et l'organisation des données. A ce stade, il est par exemple possible de connaître la liste exhaustive des tables de la base de données relationnelle.\n· un Modèle Logique des Traitements (MLT) qui précise les acteurs et les moyens qui seront mis en œuvre. Les traitements sont découpés en procédures fonctionnelles.\nAu niveau physique, on établit la manière concrète de mettre le système en place au travers de deux modèles :\n· le Modèle Physique des Données (MPD) permet de préciser les systèmes de stockage employés. On implémente le MLD dans le SGBD retenu.\n· le Modèle Opérationnel des Traitements (MOT) spécifie les fonctions telles qu'elles seront réalisées.\nSADT est l’acronyme de Structured Analysis and Design Technique. Cette méthode est également appelée IDEF0 (Integration DEFinition for transitions modeling). Elle est d'origine américaine. Elle a été développée par Doug Ross en 1977 pour la société Softech et était répandue dans la fin des années 1980. C’était l'un des standards de description graphique d'un système complexe par analyse fonctionnelle descendante. Dans cette méthode, l'analyse chemine du général vers le particulier et le détaillé. SADT est une démarche systémique de modélisation d'un système complexe ou d'un processus opératoire. Le principal avantage est de proposer une structure hiérarchisée par niveau permettant une clarification et une décomposition analytique de la complexité d'un système. Le principal inconvénient est l’absence de représentation séquentielle.\nClassification des méthodologies\nCi-dessous, une classification des méthodologies par rapport à leurs niveaux de formalisme et les natures des cycles suivis.\nFigure 18 : Classification des méthodologies\nCMM signifie Capability Maturity Model [LAB00]. C’est un système qualité qui vise à améliorer le processus de développement logiciel apparu en 1987. On peut ainsi évaluer la capacité de développement logiciel d’une organisation et la faire évoluer par pallier. Ce modèle se base sur une grille de maturité hiérarchisée. Une organisation d'évolution de processus logiciel en "échafaudage" a été inventée à partir des travaux de Watts Humphrey. Les améliorations réalisées à chaque étage fournissent la fondation de l’étape suivante. Cinq niveaux évolutifs ont été définis. Cette méthode permet d'atteindre des objectifs de coûts, de délais et de qualité. Contrairement à la norme ISO 9000, CMM a été conçu spécifiquement pour le développement logiciel. Ce modèle offre à une organisation bien définie proposant une structure d'évaluation de son niveau de maturité, un ensemble de procédures documentées pour améliorer son niveau de maturité et un ensemble de processus de contrôle pour valider les étapes de cette progression.\nCette méthode commence par la détermination du niveau de maturité actuel de l’organisation. Ensuite l’organisation dispose d'une liste détaillée des actions à entreprendre afin d’atteindre le niveau de maturité recherché. Les niveaux de maturité sont :\nL’organisation n’est pas dans un environnement stable pour l'évaluation, le développement et la maintenance de logiciels.\nLa gestion de nouveaux projets est basée sur l'expérience d'anciens projets similaires. C'est l'engagement permanent des ressources humaines qui garantit une pérennité du savoir-faire.\nLes directives de gestion de projet sont établies. Le processus standard de développement et d'évolution du logiciel a été documenté.\nDes objectifs qualitatifs et quantitatifs sont fixés. La productivité et la qualité sont mesurées.\nL'organisation toute entière est centrée sur l'amélioration continue des processus.\nL’emploi de la méthode CMM ne garantit pas la réussite d'un projet. Des aspects tels que la motivation des équipes, la diminution du turn-over ne sont pas couverts par cette méthode.\n2.3. Management des ressources humaines\nLe management permet au chef de projet de diriger l’équipe projet afin d’atteindre les objectifs du projet.\nLes acteurs du projet se répartissent en deux ensembles la MOA et la MOE.\nMOA désigne le Maître d'OuvrAge ou la Maîtrise d'OuvrAge. La maîtrise d’ouvrage est responsable de l’efficacité de l'organisation et des méthodes de travail autour des systèmes d’information. Elle fait appel à un Maître d’OEuvre (MOE) pour obtenir les produits (matériels, logiciels, services et solutions) nécessaires à la réalisation de sa mission. Dans un projet, le maître d'ouvrage décrit les besoins, le cahier des charges, établit le financement et le planning général des projets, fournit au MOE les spécifications fonctionnelles et valide la recette fonctionnelle des produits, assure la responsabilité de pilotage du projet dans ses grandes lignes et adapte le périmètre fonctionnel en cas de retard dans les travaux afin de respecter la date de la livraison finale.\nLa MOA a également des fonctions d’organisation (conduite du changement, formation des utilisateurs, organisation et modification des processus ou procédures) et doit s’assurer de la bonne adéquation entre la stratégie « métier » de l'entreprise ou de l'organisation (les objectifs, les enjeux...) et le Système d’Information.\nMOE désigne le maître d'œuvre ou l'organisation qui assure la maîtrise d'œuvre garante de la bonne réalisation technique des solutions. Il a un devoir de conseil auprès de la maîtrise d’ouvrage. C’est à la MOE de faire en sorte que le Système d’Information tire le meilleur parti des possibilités techniques et de garantir la qualité technique de la solution.\nTout projet nécessite la mise en place d’une équipe. Dans une équipe chaque membre de l’équipe a un rôle à tenir et donc la responsabilité d’un certain nombre de tâches à effectuer.\nLe chef de projet Informatique a pour responsabilité de planifier les ressources, de former, de développer et de diriger l’équipe projet.\nDans le cas d’une gestion de projet XP, l’équipe comprend 6 membres dont les responsabilités sont indiquées sur la figure ci-dessous [BEN05].\nFigure 19 : Organisation d’une équipe XP\nLe chef de projet doit organiser le suivi du projet et des individus composant l’équipe projet.\nAfin de suivre les différentes étapes du projet, il dispose de techniques de planification telles que les réseaux Pert afin de représenter les contraintes d’ordonnancement des tâches du projet, ainsi que les diagrammes de Gantt qui permettent de représenter les contraintes associées aux ressources.\nDe plus, le chef de projet peut réaliser un tableau de bord afin de rendre compte de l’activité, de l’avancement des lots et de l’évolution des charges restantes.\nIl doit diffuser ses rapports d’avancement à sa hiérarchie mais également à l’équipe. La diffusion de l’information au sein de l’équipe est un point crucial. Il est nécessaire de communiquer de façon régulière avec les différents acteurs du projet. La communication humaine est un facteur déterminant pour la bonne réussite d’un projet.\nPour bien conduire le projet, il est nécessaire de contrôler et de réguler le traitement des étapes en fonction des difficultés rencontrées et des modifications des besoins fonctionnels.\nLe pilotage d’un projet est cadré par un certain nombre de réunions : comité de direction, comité de pilotage et comité de suivi. Dans les comités de direction, la direction valide les choix stratégiques ou les grandes orientations du projet. Lors des comités de pilotage, les points bloquants sont levés et les décisions importantes sur les orientations de l’application sont prises. Le comité de suivi, quant à lui, permet de suivre la bonne marche du projet.\nLes réunions sont nécessaires pour mener à bien un projet mais il est toutefois important de limiter leur coût. Cela peut être fait en ne sollicitant que les personnes concernées. Avant une réunion, on peut également envoyer l’ordre du jour afin que les différents intervenants juge de l’intérêt d’assister ou non à la réunion. Après chaque réunion, un compte rendu doit être fait afin de garder une trace. Avant de diffuser le compte rendu, on peut demander une validation de ce dernier par les différents participants de la réunion.\nIl est essentiel que les réunions soient efficaces. Pour qu’elles débouchent sur des résultats, il est nécessaire que les tâches levées lors de ces réunions soient réalisables.\nOn peut employer des méthodes telles que la méthode Item Action qui consiste à identifier les différents points levés lors de la réunion à des tâches, des décisions à prendre, des recommandations ou des constatations.\nDes phrases complètes et compréhensibles par tous doivent être utilisées lors du compte rendu de la réunion. En face d’une action à effectuer sont indiquées son origine, les personnes qui doivent la prendre en charge et les dates d’exécution. Le quoi, le pourquoi, par qui et comment sont ainsi spécifiés. Il ne doit pas y avoir d’ambiguïté lors de la lecture du compte rendu.\nL’ensemble des comptes rendus ainsi que la documentation du projet et les livrables doivent être classés de manière ordonnée dans une arborescence de fichiers centralisée.\nToute collaboration humaine débouche sur des points de vue divergents ou des désirs incompatibles. Il est alors nécessaire de gérer les différentes positions et points de vue des parties prenantes tout particulièrement lorsque des conflits apparaissent.\nAfin d’estimer les délais, il est avant tout nécessaire d’évaluer les charges. La méthode la plus couramment utilisée est de faire une estimation par analogie aux projets que l’on a déjà effectués.\nUne fois cette estimation faite, on peut élaborer un échéancier et déterminer le chemin critique du projet.\nIl est préférable de conserver quelques marges de manœuvre au niveau de chacune des étapes. On peut alors estimer une durée probable du projet et de chacune des tâches qui le composent. On détermine ainsi une date de livraison et une date de mise en production probable.\nLe coût d’un projet peut être décomposé comme suit :\nCoûts conception / réalisation\nCoût de main d’œuvre client\nCoût de main d’œuvre projet\nCoûts de maintenance évolutive et corrective\nCoûts de débordement\nCoût de business du au débordement\nCoûts d’inadéquation aux besoins réels\nCoût de business dû à l’inadéquation des besoins\nCoûts de défaut de qualité\nCoût de business associé à un incident\nCoûts de turn-over\nLes coûts ont plus ou moins d’importance. Les coûts les plus forts correspondent à la main d’oeuvre informatique. Les coûts logiciel et d’infrastructure peuvent également être très importants.\nLes coûts engendrés par l’inactivité des utilisateurs, liés à la non disponibilité de l’application ou à l’inadéquation avec les besoins réels des utilisateurs ne sont pas simples à évaluer.\nDes différences de coût peuvent apparaître entre la méthode XP et une méthode basée sur un processus unifié reposant sur l’implémentation d’un modèle. Il n’est pas possible de dire quelle est la méthode la moins coûteuse, cela dépend beaucoup du projet et de son contexte. On peut néanmoins envisager des possibilités de coûts supplémentaires ou des diminutions des coûts sur certains des centres de coûts identifiés précédemment :\nLa présence du client sur site au sein de l’équipe génère un coût de main d’œuvre client plus important.\nLe recourt à la programmation en binôme augmente le coût de la main d’œuvre projet.\nSur les phases de déploiement et de maintenance, l’absence de documentation peut engendrer des surcoûts surtout dans le cas de renouvellement de l’équipe.\nLa formation continue de l’équipe tout au long du projet génère des coûts de formation conséquents.\nLa présence du client sur site au sein de l’équipe permet de minimiser les temps d’attente et les écarts entre les besoins réels et le logiciel obtenu.\nLe recours aux outils les plus simples possibles diminue les coûts de licences.\nL’intégration continue permet d’anticiper les problèmes de déploiement.\nLe client est un membre de l’équipe. Ses besoins de formation sont moins importants que s’il découvre le logiciel lors de sa livraison.\nL’utilisation de solutions simples et l’automatisation des tests permettent dans une moindre mesure de diminuer les coûts liés à la maintenance du logiciel.\nLa méthode XP permet de prévenir les débordements grâce à ses techniques de planification par fonctionnalités.\nL’écart entre les fonctionnalités proposées par le logiciel et les besoins du client est minimisé du fait de la forte implication de ce dernier tout au long du projet. Les coûts indirects engendrés par l’inadéquation aux besoins des utilisateurs sont donc fortement diminués.\nDe part la prise en compte permanente du changement tout au long du projet, il n’y a pas ou peu de coûts indirects liés au changement.\nLe recours aux tests automatisés réduit les défauts de qualité.\nLes coûts du turn-over sont réduits du fait de l’intérêt porté à chacun dans l’équipe. La dimension humaine a une place importante dans cette méthode. La motivation de chacun des membres est recherchée et favorisée.\nLe travail collaboratif diminue l’impact d’un départ.\nIl n’est pas toujours évident d’identifier les risques. Pourtant, on peut envisager que des tâches reposant sur des domaines fonctionnels ou techniques méconnus représentent des risques. Le fait de travailler pour la première fois avec une personne représente un risque. On peut donc dire que la nouveauté est associée à un risque majeur alors que ce que l’on a l’habitude de faire correspond à un risque moindre.\nL’estimation des risques ne peut se faire que sur la base d’une analyse qualitative. On cherche à imaginer les probabilités de risques, leurs impacts et à identifier les facteurs de risques.\nL’expérience de la conduite de projet permet de minimiser les risques mais ne les élimine pas pour autant. Les risques ne sont pas toujours prévisibles et peuvent être de nature très diverse telles que la démission d’un membre de l’équipe ou les pannes matérielles.\nLa gestion de la qualité est l'ensemble des activités qui permettent d’obtenir de la qualité dans un cadre de production de biens ou de services.\nOn parle de la qualité totale lorsque l’on cherche à satisfaire les différentes parties prenantes : les fournisseurs, les clients, les actionnaires, les employés et l'État.\nLa qualité optimale correspond à un équilibre au niveau des besoins de l'ensemble des parties prenantes. Le niveau de qualité optimal ne doit pas produire de coûts inadéquats. On parle alors de sur-qualité. La qualité est censée réduire le coût de la non-qualité. Une entreprise est performante lorsque les ressources qu'elle met en œuvre, sont justifiées et efficaces, et lui permettent de se positionner avantageusement sur un marché avec une marge d'avance sur la concurrence.\nLes normes internationales de la qualité se sont orientées vers la qualité totale (TQM : Total Quality Management), qui articule stratégie, système, performance, dimension humaine et sociale. En France, le déploiement de la démarche qualité a été tardif : vers 1990. Une version simplifiée de la démarche qualité a alors été élaborée et diffusée sous le nom d'Assurance Qualité, définie dans les normes ISO 9001.\nAssurance Qualité ou Quality Assurance (QA) couvre toutes les activités de production depuis la conception, le développement, la production, l'installation, les services et la documentation. L’objectif étant de bien faire les choses dès la première fois et d’aller droit au but.\nDe nombreuses méthodes sont utilisées pour améliorer la qualité. Parmi elles on peut citer la roue de Deming, le diagramme de Gantt, l’outil PERT et le brainstorming.\nLa roue de Deming permet de cadrer le pilotage d’une démarche qualité. Elle précise les étapes de mise en place de la maîtrise de la qualité. Elle est aussi désignée par PDCA (Plan - Do - Check - Act : concevoir, mettre en œuvre, contrôler, agir) ou encore par la "roue de la qualité". Cette méthode a été lancée par les qualiticiens JURAN et SHEWART de la société Bell Telephon en 1925.\nLe diagramme de Gantt permet d’optimiser et de sécuriser un processus. Le diagramme de Gantt est un outil permettant de modéliser la planification de tâches nécessaires à la réalisation d'un projet.\nLe diagramme de Gantt a été développé par Henry L. Gantt, ingénieur américain, vers 1910. Il est utilisé en ordonnancement et en gestion de projet. Il permet de visualiser dans le temps les tâches d’un projet. L’avancement du projet est alors représenté graphiquement. Son emploi permet de répondre à des objectifs de planification optimale, de communication sur le planning établi et de justification de choix.\nUn diagramme de Gantt permet de déterminer les dates de réalisation d'un projet, d'identifier les marges existantes, de visualiser le retard ou l'avancement des travaux.\nDe nombreux logiciels de gestion de projet utilisent ces diagrammes. On peut citer par exemple l’offre propriétaire Microsoft Projet ou la solution gratuite GANTT Projet.\nL'outil PERT est utilisé pour analyser un fonctionnement. C’est une méthode de gestion de projet permettant de définir les tâches et le délai d’un projet et d’en assurer le suivi. Elle a été créée en 1957 par l’US Navy.\nPERT signifie Program Evaluation and Review Technique. Il permet de visualiser la dépendance des tâches et de les ordonnancer. Il repose sur un graphe de dépendances. On indique une date de début et de fin au plus tôt et au plus tard de chacune des tâches. On peut en particulier, à l’aide de ce diagramme, déterminer le chemin critique conditionnant la durée minimale du projet. Des tâches critiques sont alors identifiées. Elles correspondent aux tâches qui ne doivent pas subir de retard sinon l’ensemble du projet sera retardé. Cet outil fournit donc une méthode permettant d'optimiser et de planifier l’ordonnancement des tâches du projet.\nLe brainstorming ou remue-méninges est une méthode de créativité.\nLa norme ISO 9001 fait partie des normes ISO 9000 relatives aux systèmes qualité. Elle donne les exigences organisationnelles qui sont requises pour l'existence d'un système de management de la qualité.\nDans la norme ISO 9001 version 2000, les exigences sont relatives à quatre grands domaines :\n· Responsabilité de la direction : exigences d'actes de la part de la direction.\n· Système qualité : exigences administratives permettant la sauvegarde des acquis. Exigence de prise en compte de la notion de système.\n· Processus : identification et gestion des processus contribuant à la satisfaction des parties intéressées.\n· Amélioration continue : mesure et enregistrement de la performance, engagement d'actions de progrès efficaces.\nLa mise en œuvre d’un système de management de la qualité selon les exigences de la norme ISO 9001-Version 2000 consiste à :\nChercher à accroître la satisfaction des clients par l'application efficace du système, et en particulier, mettre en œuvre un processus d'amélioration continue.\nLe texte de la norme ISO 9001 aborde les 4 processus principaux :\nLes processus de mesure, d'analyse et d'amélioration continue\nLa version 2000 de la norme ISO 9001 se différencie sur deux points par rapport aux versions précédentes.\nDans les versions précédentes, on définit par écrit ce que l'on doit faire et on fait ce que l'on a écrit. Alors que dans la version 2000, on définit le niveau de qualification (ou de compétence) nécessaire pour tenir un poste et on s'assure que les personnes tenant ce poste ont la qualification voulue et, si nécessaire, on met en œuvre des formations. On définit un niveau de qualification plutôt que de spécifier un mode opératoire à suivre.\nContrairement aux versions précédentes la satisfaction réelle de l'utilisateur final est plus importante et le client est positionné au sommet de la pyramide.\nLes normes ISO 9000 et XP\nOn peut faire un parallèle entre les principes des normes ISO 9000 avec les principes et valeurs de la méthode XP. Même si la méthode XP ne respecte pas dans les règles de l’art les principes des normes ISO, elle s’en inspire tout de même.\nTableau 7 : Positionnement de XP par rapport aux principes ISO 9000\nPositionnement de la méthode XP\nLa méthode XP est orientée client. Le client fait partie de l’équipe. La méthode cherche à comprendre le client et à répondre à son besoin\nLe bénéfice attendu du leadership est l’établissement de la confiance et l’élimination de la peur, ce qui rappelle les qualités de communication et de courage prônées par XP.\nLa méthode considère que les individus sont plus importants que les technologies et les processus. Cette méthode cherche à mettre en valeur les individus.\nXP peut être vu comme un processus avec un formalisme minimal.\nXP s’inspire d’une approche systémique.\nDe fait de l’utilisation d’itérations dans les développements et de la recherche continue de l’amélioration des compétences, XP respecte tout à fait ce principe.\nLa méthode XP se veut pragmatique par rapport aux observables.\nRelation mutuelle bénéfique pour les fournisseurs\nXP est basé sur des relations de type gagnant – gagnant plutôt que sur le respect de clauses d’un contrat initial.\nLa qualité des données se réfère à la conformité des données aux usages prévus, dans les modes opératoires, les processus, les prises de décision, et la planification.\nPour ce qui est de la qualité, la qualité livrée du logiciel peut être mesurée de différentes manières. En interne, le niveau de qualité est mesuré par le responsable qualité ou les équipes, alors qu’en externe, c’est le client qui mesure le niveau de qualité.\nUn certain nombre de mesures permettent de contrôler la qualité : la mesure de la conformité, de la satisfaction ou les enquêtes de satisfaction.\nLa qualité interne peut être améliorée en gérant la qualité de l’architecture et du code par : des lectures croisées, des inspections, des revues de code et d’analyse ou du refactoring.\nA force d’implémenter de nouvelles fonctionnalités dans une application, le code source tend à devenir de plus en plus complexe, d’autant plus que l’on emploie des techniques modernes de développement itératif et incrémental.\nLa refactorisation (refactoring) est une opération de maintenance du code informatique. Elle consiste à retravailler le code source pour améliorer sa lisibilité, simplifier sa maintenance sans pour autant ajouter de nouvelles fonctionnalités.\nLa qualité interne est également améliorée par l’établissement d’outils tels que les normes de codage, les guides de conception des composants ou les designs patterns.\nLa qualité externe, quant à elle, peut être améliorée en s’efforçant d’offrir le meilleur service possible à son client.\nLa qualité est obtenue au travers de\n· méthodes structurées\nil est important de déterminer les aspects à traiter, de les ordonner et de gérer le changement par la mise en place de versions de documents et de code.\n· la mise en œuvre de moyens et d’outils adaptés\nCVS peut être utilisé pour gérer les différentes versions du code et des documents. Microsoft Office permet d’élaborer de nombreux documents du projet.\nle recourt à la formation est un facteur d’amélioration de la qualité et de la productivité du fait de la montée en compétence des acteurs du projet.\nL’amélioration de la qualité peut passer par l’utilisation d’UML pour modéliser le système en simplifiant et uniformisant la modélisation, en améliorant la relation entre les différents acteurs et en s’appuyant sur des normes et méthodes.\nDe plus, il est important d’entretenir une culture de la qualité.\nTout projet commence en général par l’estimation du ROI (retour sur investissement). C’est un élément important de la prise de décision des dirigeants. Les gains financiers correspondant au projet sont estimés. On évalue également la date de retour sur investissement qui correspond à la date à partir de laquelle le projet permet des gains financiers.\nIl est important de réaliser une phase appelée « mémoire du projet » afin de préciser les aspects réutilisables de la démarche sur des problématiques similaires.\nCette étape permet de tirer parti de ce qui a été fait en évitant de reproduire les mêmes erreurs et en cherchant à réutiliser les points positifs de la démarche projet.\nC’est en quelque sorte un bilan du projet.\n2.4. ETL et EAI : généralités\nETL signifie Extract Transform and Load. Un ETL permet de construire de façon simple des processus qui permettent d’extraire des données de systèmes hétérogènes, de les transformer, puis de les charger dans un système cible.\nA l’aide d’un ETL, il est possible de connecter diverses sources de données à de multiples systèmes cibles à travers toute l’entreprise, afin d’alimenter un data warehouse, de gérer des méta-données ou d’intégrer des applications d’entreprise.\nOn peut exploiter de manière plus efficace les données et donc optimiser les processus « métier ». Il est possible de consolider les données afin d’en tirer une information fiable, cohérente et actualisée ou de les échanger entre applications, en ayant au préalable effectué des transformations et nettoyé ou enrichi les données.\nL’ETL que nous utilisons dans le projet est la version 4 de Genio d’hummingbird.\nSon architecture est de type client / serveur, construite sur un modèle Hub and Spoke. Le Hub se compose d’un moteur centralisé et d’un référentiel de données et méta-données. Les sources de données et les cibles entre lesquelles le Hub échange des données correspondent aux Spoke.\nFigure 20 : Architecture de GENIO\nGENIO se compose de différents éléments qui permettent de concevoir, de déployer et de maintenir les transformations de données et les processus d’échanges.\nCes composants sont : designer, administration manager, repository, engine, scheduler, metalink et datalink. Nous allons plus nous attacher dans ce qui suit au designer et au scheduler car ce sont les composants que nous utilisons le plus lorsque nous développons.\nL’engine est un moteur de transformation multithread de type broker. Il permet d’exécuter les processus.\nLe repository est un référentiel objet pouvant être hébergé sur les principaux SGBDR du marché. Dans notre cas, nous l’avons hébergé sur une base ORACLE 8. Dans ce référentiel sont stockés et gérés tous les aspects des transformations, les méta-données des processus d’échange, les objets créés au travers du designer, ainsi que les informations relatives aux exécutions des processus.\nAdministration manager (Console d’administration)\nL’interface d’administration permet d’initialiser l’environnement, le repository et de gérer l’administration des utilisateurs et leurs droits.\nLe scheduler permet\n· la planification temporelle et événementielle. Il est possible de programmer, déclencher et contrôler les processus dont l’exécution peut être planifiée par des événements externes tels que la modification de fichier, le transfert de fichier, à une heure donnée, à partir d’un calendrier, de façon périodique (journalière, hebdomadaire ou mensuelle) ou à la création d’un fichier. Il est un point d’entrée unique pour l’ensemble des planifications de l’architecture.\n· le contrôle et la surveillance des exécutions en temps réel au niveau du moteur de l’ETL.\n· la visualisation des comptes rendus d’exécution. On peut trier les exécutions par date, par nom de processus, par nombre d’erreurs.\n· l’accès à un historique complet\nMetalink permet de récupérer et de transformer des données et métadonnées provenant d’applications ou de divers ERP.\nDatalink propose une bibliothèque de liens aux SGBD relationnels ou multidimensionnels et aux systèmes de gestion de fichiers plats.\nLe Designer permet de concevoir les processus exécutables dans le moteur de l’ETL au sein de projets. Il est possible de créer de nombreux objets qui vont permettre de concevoir les différents processus.\nLe Designer est une interface graphique qui simplifie les opérations de mapping des données sources avec les structures cibles. Le temps d’apprentissage et les ressources nécessaires afin d’être opérationnel sont minimes par rapport à l’apprentissage d’un langage de programmation tel que Java. C’est un environnement multi utilisateurs qui permet d’élaborer des transformations de données, ainsi que des processus d’échange.\nLe designer permet de manipuler de nombreux objets simples qui vont permettre de concevoir les différents processus. Voici une liste non exhaustive d’objets les plus couramment utilisés :\nC’est un lien vers une base de donnée ou un fichier\nElles sont liées à une connexion et sont le reflet des tables d’une base de donnée ou de la structure d’un fichier.\nC’est un ensemble de tables d’une connexion avec la possibilité de faire des jointures. Dans le cas des bases de données, on peut utiliser des fonctions telles que somme, max, min … Les fonctions proposées restent très basiques. On peut néanmoins faire des jointures, des agrégations, des distinctions, des filtres ou des tris.\nIl accepte une table ou un dataset en entrée et plusieurs sources de données en sortie. Il permet la lecture d’informations présentes dans une base de données ou un fichier, de transformer ces informations ou de les mapper et de les écrire dans un ou plusieurs autres systèmes cibles (bases de données ou fichiers).\nC’est au niveau du module qu’est offerte la possibilité d’utiliser un langage simple. On dispose ainsi de fonctions analogues aux langages de programmation : fonctions mathématiques, de manipulation de chaîne ou de conversion.\nUn processus se compose de modules, de déclenchement d’exécutables, d’envois d’email ou d’événements …\nLes exécutables peuvent être des batch s externes ou des scripts Shell dans le cas où l’on aurait des besoins de transformations spécifiques.\nLes notions de transaction, de commit et de rollback à l’intérieur de ces programmes sont prises en charge.\nPossibilité de mise en œuvre de transformation complexe\nDes possibilités de scripting disponibles au niveau des modules permettent de mettre en œuvre des processus de transformation complexe de données. Ce langage simple permet d’utiliser des boucles, des tests, des variables et des instructions. On peut définir des variables ou utiliser des instructions logiques telles que for ou if. Un ensemble complet de fonctions de transformation permet de créer des programmes de transformation au même titre qu’un langage de programmation. Il offre de nombreuses fonctions utilisées pour construire des expressions avec des sources de données et des variables. Ces fonctions couvrent le spectre complet de la manipulation des chaînes, dates, nombres, et booléens. Des clauses complexes telles que des IF, THEN, ELSE et CASE peuvent également être utilisées dans les expressions. Les utilisateurs peuvent ainsi créer leurs propres macros afin de décrire leurs règles « métier ». Les objets créés sont stockés dans le repository afin d’être réutilisés.\nUne analyse d’impact des modifications effectuées sur les objets et les objets associés est réalisée par le designer. Si un changement touche l’intégrité d’un objet, l’objet devient invalide. Les modifications faites au niveau des structures de données sources et cibles sont également détectées. Ceci permet d’éliminer les risques de corruption de données ou d’échec pendant les processus de transformations.\nTransparence des implémentations techniques\nGENIO utilise les mêmes fonctions lorsqu’il manipule des fichiers ou des sources de données. Il ne fait pas de distinction sur le fait que la source ou la cible soient des fichiers « texte » ou des tables d’une base de données. L’utilisateur n’a pas à se soucier des implémentations techniques des fonctions qu’il utilise. C’est le moteur qui gère cet aspect et qui va utiliser la grammaire SQL native correspondant à une base de données précise afin d’exploiter les possibilités propres de la base de données pour accéder aux seules données que l’on souhaite transformer. Cette approche présente l’avantage de minimiser le trafic réseau.\nIl est possible de lever des exceptions et de gérer des erreurs. Un module peut retourner un code erreur permettant, au sein d’un processus, de conditionner l’exécution des modules qui le suivent.\nA l’aide de la commande write, utilisable dans les modules, il est possible d’écrire des messages dans le compte rendu d’exécution. De plus, le compte rendu d’exécution propose par défaut la visualisation de nombreuses autres informations qui facilitent la détection des erreurs : l’ensemble des ordres SQL effectués sur les différentes bases de données, des compteurs correspondant aux enregistrements lus, écrits, mis à jour …\nIl existe différents types d’implémentation. Soit l’essentiel des manipulations de données se fait au sein du module, soit on déporte une partie des transformations au niveau des bases de données sources ou cibles. Ou encore, on exécute des ordres SQL. Dans ce dernier cas, c’est le moteur de base de données qui fait tout le travail, et il n’y a pas de transfert d’information sur le réseau.\nEAI / VBIS\nL’EAI (Entreprise Application Intégration) désigne des processus et des progiciels permettant d’automatiser les échanges entre différentes applications d’une même entreprise ou entre les systèmes d’information d’entreprises différentes. Les applications et les entreprises peuvent ainsi s’échanger des données, des messages et collaborer à l’aide de processus communs.\nUne plate-forme EAI relie les applications hétérogènes du Système d’Information autour d’un bus logiciel commun, chargé du transport des données.\nDeux facteurs principaux poussent au développement de la mise en place de l’EAI dans les entreprises :\nLe premier est lié à la composition très diversifiée du Système d’Information de l’entreprise. L’EAI permet d’exploiter les données et le potentiel de ces différents systèmes, et également de faciliter la maintenance des passerelles existant entre ces systèmes.\nLe second facteur de développement de l’EAI est lié aux événements ou aux changements structurels qui poussent les entreprises à augmenter la flexibilité et la réactivité de leur Système d’Information, d’où la généralisation des besoins d’intégration entre les applications de production (ERP), de logistique (SCM), de relation client (CRM)… La chaîne de valeur se conçoit dans sa globalité.\nOn distingue deux grandes familles de technologies EAI : les EAI tactiques et les EAI d’infrastructure.\nL’EAI tactique intervient dans un périmètre limité, généralement comme une brique d’un projet fonctionnel de l’entreprise. C’est un outil, un composant qui va permettre d’automatiser un ensemble de traitements localisés, sans impact sur le Système d’Information global de l’entreprise.\nL’EAI d’infrastructure implique une prise en compte et une évolution éventuelle du système global de l’entreprise et de ses processus. On parle alors de Business Process Management. Ce sont des solutions qui se justifient dans des environnements applicatifs complexes ou des environnements critiques, de grandes entreprises. L’EAI devient alors l’un des piliers de l’architecture du Système d’Information.\nNous allons présenter dans cette partie une solution logicielle de la société Vignette qui permet d’automatiser un ensemble de traitements localisés. Si on va sur le site de l’éditeur, ce logiciel est présenté comme étant un ETL. Mais comme nous le verrons dans la suite de part ses caractéristiques il s’assimile davantage à un EAI tactique. La frontière entre les ETL et les EAI n’est pas très nette et nombre d’ETL et d’EAI présentent les mêmes fonctionnalités. Une chose est sûre : il est préférable, pour des raisons marketing, de mettre en avant les fonctionnalités ETL de ces produits, les ETL ayant la réputation d’être beaucoup plus stables que les EAI.\nCet outil se compose d’un environnement de développement VBIS (Vignette Business Intégration Studio).\nIl permet d’intégrer des applications d’entreprise, des procédures et de l’information de façon rapide. Il offre des possibilités d’intégration et d’unification des systèmes d’information d’entreprise.\nIl est possible d’intégrer de l’information à partir - ou vers - des applications, des entrepôts de données ou d’autres sources de données présentes à l’intérieur ou à l’extérieur de l’entreprise.\nA l’aide d’une interface graphique simple, il permet de réduire les temps de développement, de recette et de déploiement et donc de réduire les coûts liés à la mise en œuvre et à la maintenance des applications.\nL’environnement graphique permet le développement de programmes à l’aide d’adaptateurs sans la moindre ligne de code.\nLes adaptateurs sont associés aux diagrammes de flux. Les diagrammes de flux qui forment les processus d’adaptation sont exécutés comme une séquence d’étapes. Il existe donc un ordre d’exécution entre eux. Les adaptateurs correspondent aux étapes, et la direction des connexions entre les adaptateurs détermine de quelle façon les étapes sont exécutées. L’exécution des diagrammes de flux est contrôlée à l’aide de ports de contrôle tels que l’exécution port qui prend la valeur true ou false. Si une valeur false est levée, les adaptateurs qui suivent ne sont pas exécutés.\nUn diagramme de flux particulier est associé à l’exécutable pour indiquer le premier diagramme de flux à exécuter. L’ensemble des diagrammes de flux est regroupé au sein d’un projet.\nL’environnement se compose :\nd’une fenêtre des librairies d’adaptateur\nde fenêtres permettant l’édition des diagrammes de flux\nd’une fenêtre projet\nCes adaptateurs peuvent être testés à l’aide de VBIS. Le débuggeur permet de gérer des points d’arrêt, de suivre pas à pas les opérations, les valeurs, de visualiser et de se déplacer entre différents niveaux des diagrammes de flux.\nLibrairies des Adaptateurs\nLes adaptateurs se présentent sous forme de modules. Ils permettent de se connecter à des applications d’entreprise spécifiques et à diverses sources d’information. Il existe des adaptateurs pour de nombreuses applications et plateformes. Ils permettent d’intégrer diverses applications d’entreprise (ERP, CRM, système back office), applications gros système, bases de données et autres entrepôts de données internes ou externes à l’entreprise. Il existe également des adaptateurs spécialisés pour de nombreux standards : COM, EDI, EJB, FTP, Flat Files, HTTP, CORBA (Iona Orbix), JavaBean, JDBC, JMS, LDAP, ODBC, SNMP et XML (Figure 21).\nUn ensemble d’adaptateurs est disponible afin de contrôler les flux et la logique, de surveiller et de gérer les erreurs des processus d’intégration et des applications. Ce qui permet d’implémenter la logique « métier » de façon graphique.\nIl est possible de réutiliser les processus d’intégration en tant qu’adaptateurs à l’intérieur d’autres processus d’intégration. On peut ainsi imbriquer les procédures « métier ».\nFigure 21 : Différentes librairies d’adaptateurs existants\nCes adaptateurs permettent de connecter un large panel de composants, de systèmes et d’applications. Il est donc possible de gérer des flux de données et de les contrôler au travers d’applications et de sources de données.\nLes processus sont élaborés à l’aide de diagrammes de flux. Les diagrammes de flux sont des programmes composés d’éléments visuels (adaptateurs et autres diagrammes de flux) connectés les uns aux autres pour tenir compte de flux de données et de contrôles au travers des applications et des sources de données. Les diagrammes de flux fournissent une méthode simple et rapide d’accéder à l’information existante et de la transformer. VBIS se compose d’un ensemble d’éléments visuels qui correspondent à des données, des applications et des opérations.\nLes éléments fournissent des informations sur la façon dont ils sont exécutés. Il est possible de surveiller les adaptateurs, de déterminer si un adaptateur s’exécute, de jauger la progression par rapport à un but connu, de détecter les erreurs, de mesurer la performance, de récolter des statistiques et d’effectuer des audits.\nIls permettent également de visualiser la façon dont se propage l’information entre les applications.\nLes adaptateurs sont les éléments fondamentaux des diagrammes de flux, on peut sélectionner des méthodes sur ces adaptateurs afin d’effectuer des opérations spécifiques. Les adaptateurs peuvent avoir plusieurs méthodes mais on ne peut en sélectionner qu’une seule à la fois.\nLes adaptateurs sont connectés à l’aide de ports. Un port peut recevoir des entrées d’un autre adaptateur et envoyer des sorties vers d’autres ports. Dans le cas de l’adaptateur d’accès aux bases de données via ODBC, les ports correspondent aux colonnes d’une table relationnelle.\nUn port peut être obligatoire ou optionnel, recevoir ou envoyer une ou plusieurs valeurs à la fois. Les connexions entre les ports sont représentées par des flèches.\nLe déploiement des projets, une fois réalisés, est très souple. Il est possible de déployer les processus d’intégration de contenu sous la forme de programmes Java standards (EJB, JavaBean,.jar), ou de programmes Windows (COM,.exe), ou de services Web, sur des systèmes d’exploitation variés, sans écrire de code. Un même diagramme de processus d’intégration peut être déployé sous de multiples formes dans de multiples environnements d’exploitation, sans changement. Il n’est pas nécessaire de gérer la complexité de l’implémentation.\nComparatif ETL /EAI\nETL et/ou EAI\nIl existe aujourd’hui plusieurs types d’outils sur le marché de l’intégration de données. Les deux principales catégories qui sont utilisées pour implémenter les échanges de données sont les outils ETL et EAI. Les architectures des ETL et des EAI partagent de nombreux concepts communs. Cependant, ils correspondent à des besoins « métier » différents et offrent des fonctionnalités spécifiques. En général, les ETL sont des solutions de traitement automatique d’échange de données axées sur des données techniques et travaillant principalement avec des RDBMS (Relational DataBase Management System).\nD’un autre côté, les outils d’EAI sont considérés comme des solutions d’échange de données en temps réel, axées sur des données « métier » et qui travaillent principalement avec des MOM (Message Oriented Middleware).\nCependant, les deux catégories de produits ont souvent affaire aux mêmes données et implémentent les mêmes règles « métier ».\nGENIO est un ETL qui offre un certain nombre d’extensions provenant des EAI en proposant un certain nombre d’adaptateurs à diverses applications d’entreprises. Il permet d’éviter dans une certaine mesure de se doter d’une solution ETL et d’une solution EAI distinctes.\nPlusieurs cas de figures peuvent faire en sorte que l’on ait recours à un EAI tactique en complément d’un ETL tel que GENIO.\nEn effet, la bibliothèque d’adaptateurs proposée permet de se connecter à diverses solutions du marché mais est moins riche que celle des EAI. On peut donc être obligé de se doter d’une solution EAI, en plus de cet ETL, afin de bénéficier d’adaptateurs correspondant à des applications qui ne sont pas proposées par l’ETL.\nD’autre part, GENIO peut ne pas permettre de gérer pleinement les besoins d’intégration d’applications dans le cas où l’on souhaiterait mettre en œuvre des programmes, sous forme d’exécutables, manipulant des données sans vouloir utiliser de langage de programmation.\nTraditionnellement, les ETL permettaient d’extraire, de transformer et de charger des données en mode batch, afin d’alimenter des entrepôts de données utilisés par des applications décisionnelles.\nPar contre, la nécessité d’augmenter les fréquences de rafraîchissement de l’information qui se rapprochent de plus en plus du temps réel, fait que les ETL répondent désormais à des problématiques plus larges d’intégration de données, à la fois batch et en temps réel. Ils se rapprochent ainsi des problématiques traitées par les EAI.\nLes ETL sont utilisés pour les mouvements de données en mode batch, principalement pour :\nle chargement des Datawarehouse\nles opérations de réplication et de migration entre bases de données\nla mise à disposition de données auprès de systèmes décisionnels\nl’intégration de données hétérogènes plutôt en mode batch mais parfois en temps réel\nl’analyse préalable des données afin d’obtenir des statistiques sur la fiabilité des données. On peut vouloir déterminer le type des données ou les index utilisés pour y accéder. On caractérise alors les données par un profil.\ngérer la qualité des données. On peut rediriger des erreurs dans des tables d’anomalies en vue de les retraiter.\nMême si les ETL et EAI ont tendance à converger sur certains aspects, il existe cependant des différences importantes entre ces deux catégories de produit.\nLes EAI permettent de résoudre l’hétérogénéité du Système d’Information en intégrant et en faisant collaborer les différentes applications ou progiciels.\nIl est possible d’intégrer des données en temps réel. La mise en correspondance des formats d’entrée et de sortie se fait à l’aide de graphiques.\nAvec un EAI on peut gérer des données de référence de façon cohérente et unifiée, et inclure dans les processus « métier » des validations d’utilisateurs par le biais de workflow.\nCertaines solutions EAI permettent également de gérer des cadres d’échange pour chaque type de partenaire de l’entreprise afin de répondre aux besoins d’intégration inter entreprise.\nLes EAI proposent trois grandes couches de services :\nle transport et la connectivité : ils proposent une large bibliothèque de connecteurs permettant de relier la plupart des grands progiciels ERP et CRM du marché.\nle routage et la transformation : transformer un format de donnée d’une application source en un format compréhensible par l’application cible.\nBPM (Business Process Management) : permet de se détacher de la technique et de voir les processus sous un angle « métier ».\nLes deux familles de produit que sont les EAI et les ETL tentent toutes deux de répondre aux problématiques d’intégration des données hétérogènes en temps réel et aux problématiques de gestion des données de références MDM ( Master Data Manager). Ce sont les deux problématiques sur lesquelles ces produits se recouvrent.\nL’ETL, initialement mis en œuvre pour extraire des données de production, les transformer et les charger dans un Dataware house en mode batch, peut aujourd’hui récupérer en instantané les données dans les systèmes de production (ERP, CRM) ou être utilisé dans des problématiques de migration d’applications, d’urbanisation ou d’homogénéisation du Système d’Information.\nDe plus, les Datawarehouse deviennent une application du Système d’Information comme une autre à partir de laquelle on peut répercuter des changements dans le système de production et ainsi modifier les données de départ.\nLes EAI, quant à eux, évoluent pour devenir la plate forme constitutive de nouvelles architectures orientée service (SOA) auprès des annuaires de services, avec l’intégration dans un portail et via l’orchestration des services grâce aux couches de BPM.\nTableau 8 : Comparatif des caractéristiques EAI/ETL d’un point de vue général\nBasé sur la mise en œuvre de règles « métier »\nBasé sur la mise en correspondance de schémas de données différentes\nVolumétrie gérée à l’aide de l’outil\nVolumétrie faible de l’ordre de 100 000 enregistrements dans le cas de VBIS afin d’obtenir des temps d’exécution raisonnables\nCapable de gérer des volumétries importantes de données. De l’ordre de plusieurs millions d’enregistrements dans le cas de GENIO.\nPossibilité d’analyse des données\nles EAI étant basés sur une approche orientée « métier », ils ne permettent pas d’analyser les types des données et les index utilisés\nReposant sur la mise en correspondance de schémas de données, des possibilités d’analyse des données sont offertes par les ETL.\nCertaines possibilités existent mais sont très limitées\nIl est possible de nettoyer les données et de mettre en place des mécanismes de gestion des erreurs.\nPossibilité de transformation des données\nIl existe des fonctions simples permettant de transformer de l’information. Les possibilités d’agrégation des données sont limitées\nLes fonctions de transformation et d’agrégation des données sont plus nombreuses et plus élaborées.\nPossibilité d’utilisation de format PIVOT\nPas encore couvert\nIl existe de nombreux connecteurs\nQuelques connecteurs mais moins nombreux que dans le cas des EAI\nBus d’échange et de transformation\nGestion des processus « Métier »\nPossible dans certains EAI mais pas dans le cas de VBIS\nIntégration inter entreprise\nTemps réel asynchrone\n2.5. Organiser une application J2EE\nComment organiser une application WEB ?\nJ2EE est une plateforme, c’est à dire une base générique qui fournit un ensemble de fonctionnalités utilisables dans une majorité d’applications. Les développeurs ont à leur disposition un ensemble d’outils qu’ils n’ont pas besoin de concevoir eux même.\nJ2EE, qui signifie Java 2 Enterprise Edition, est une norme proposée par la société Sun. Elle a été adoptée par de grands groupes mondiaux tels que : IBM, Oracle, BEA …\nExistant depuis 1998, elle est stable et fiable. Elle évolue constamment. Sun a mis en place un système de spécifications permettant d’être à l’écoute des besoins, des propositions ou critiques des développeurs.\nL’utilisation de Java permet de rendre les applications totalement indépendantes de la plateforme système utilisée. Une même application peut aussi bien tourner sous Windows que sous Unix.\nDe plus, les développements ont l’avantage d’être plus facilement maintenables que d’autres langages tels que le C par exemple.\nJ2EE comprend les spécifications du serveur d'application [JOU05b] (son environnement d'exécution).\nLa plateforme propose des services offrant un certain nombre de fonctionnalités au travers d’API. Les API présentent l’avantage d’être faciles à prendre en main. Elles permettent de cacher la complexité d’accès aux ressources et donc de gagner considérablement du temps. Les développeurs peuvent ainsi consacrer plus de temps aux aspects « métier ».\nIl existe deux types de services : des services d’infrastructure et des services de communication. Les deux tableaux suivants décrivent les différentes API de chacun de ces types.\nTableau 9 : Services d’infrastructure\nAPI d’accès aux bases de données. Son utilisation diminue le nombre de lignes de code à écrire. De plus, les accès peuvent être optimisés à l’aide des pools de connexions fournis par les serveurs d’application.\nAPI d'accès aux services de nommage et aux annuaires d'entreprises (DNS, NIS, LDAP, …).\nJTA / JTS - Java Transaction Api / Java Transaction Services\nAPI définissant des interfaces standards avec un gestionnaire de transactions.\nAPI de connexion au Système d'Information de l'entreprise (ERP…).\nAPI permettant de développer des applications WEB de supervision d'applications.\nTableau 10 : Services de communication\nJAAS (Java Authentification and Authorization Service)\nAPI de gestion de l'authentification et des droits d'accès.\nAPI permettant la communication synchrone entre objets.\npermettent de « partager » un ensemble de méthodes qui pourront être appelées à distance. Cette technologie utilise XML, ce qui permet de l’employer avec n’importe quel langage et n’importe quelle plateforme.\nAPI fournit des fonctionnalités de communication asynchrone (appelées MOM pour Middleware Object Message) entre applications.\nAPI permettant l'envoi de courrier électronique.\nJ2EE repose sur des composants. Ce qui permet :\nd'étendre l'architecture de façon simple\nd’obtenir une bonne qualité de service par la mise en place de mécanismes de haute disponibilité\nde faciliter la maintenance des applications\nOn peut distinguer 2 catégories de composants : les composants Web et les composants « métier ».\nLes composants Web correspondent à la partie présentation d’une application. Ils permettent d’implémenter des Interfaces Homme Machine (IHM) et les traitements qui leur correspondent.\nPour permettre d’avoir un code performant, robuste et maintenable, différentes technologies sont utilisées telles que les JSP et les servlets.\nJSP signifie Java Server Page. Ces pages servent à générer le code HTML de l’IHM. On peut utiliser dans ces pages des scriplets Java ou des balises personnalisées.\nLes Servlets sont des classes Java qui permettent le traitement des requêtes utilisateurs.\nIls sont chargés des traitements des données propres à un secteur d'activité. Ils doivent également assurer l'interfaçage avec les bases de données. Les EJB (Entreprise JavaBean) sont un exemple de composant « métier ».\nLes composants standards que nous venons de voir peuvent parfois être assez lourds à utiliser. Ils sont conçus pour de grandes architectures et peuvent être mal adaptés aux applications moins importantes.\nOn peut alors utiliser des frameworks servant à simplifier l’utilisation des technologies standards. Ils sont souvent plus limités, mais leur utilisation est plus simple.\nArchitecture basique d’une application\nFigure 22 : Exemple d’architecture basique d’application\nCette architecture permet de décomposer le système en sous-systèmes. Elle se compose de 5 couches :\nC’est l’interface utilisateur (HTML, WML, PDA…). Du fait qu’elle ne gère pas les règles fonctionnelles, on peut la faire évoluer facilement.\nElle permet de traiter le fonctionnel de l’application. Elle utilise les services de la couche Entreprise. La couche Application permet de gérer le fonctionnel spécifique à partir de vues d’objets « métier ». Elle peut être implémentée à l’aide de Servlets ou de Web Services.\nElle correspond aux objets structurants de l’entreprise. Ces objets sont transversaux à toute l’entreprise. Elle propose des services d’accès aux objets au travers de méthodes de création, de modification, de suppression et de recherche. On peut utiliser des classes DAO ou EJB.\nCette couche est liée à la structure des données. Dans le cas d’un SGBDR, on utilise un outil de mapping relationnel objet tel que Hibernate.\nCette couche correspond à la structure physique des données : SGBD tel que ORACLE, CICS, LDAP…\nLe schéma ci-dessus (Figure 22) est un exemple d’architecture d’application basique. Cette architecture n’est pas générique. Elle est adaptable en fonction du projet que l’on a à mener. Les noms utilisés pour les différentes « couches » peuvent varier suivant les personnes. On peut trouver le terme de couche de Présentation pour désigner la couche gérant l’interface homme / machine. La couche « métier » est également appelée « couche de Domaine ».\nL’architecture que nous utiliserons (Figure 23) est simplifiée par rapport à cette version basique.\n· une couche Présentation\n· une couche DAO\n· une couche Physique\nFigure 23 : Architecture utilisée\nDans les sections suivantes, nous allons détailler la couche Application & Présentation et la couche « métier ».\nCouche Application & Présentation\nCette couche est très liée au type de client utilisé.\nLorsque l’application n’a pas besoin d’utiliser des composants très spécifiques, on met en place des applications WEB avec un client léger pour les utilisateurs. Il est en effet très simple de générer les interfaces de façon rapide à l’aide d’HTML.\nL’inconvénient de l’utilisation de client léger peut être que, dans certains cas, les flux réseaux sont beaucoup plus importants qu’avec une solution basée sur un client riche. Il est alors nécessaire de palier à cet inconvénient en recourant à un réseau possédant des débits plus importants.\nLa couche Application ne constitue pas toujours une couche indépendante. Elle sert à assurer la communication entre la couche Présentation et la couche « métier ». Elle permet également de contrôler l’enchaînement des différentes tâches. Elle a la charge de connaître l’état des sessions des clients. Dans notre cas nous parlerons uniquement de couche Présentation pour désigner la couche prenant en charge les interfaces utilisateurs.\nPour mettre en œuvre cette couche, il existe deux possibilités :\n· Utiliser les Servlets et les JSP\nCeux sont des composants de bas niveau qui n’offrent que des fonctionnalités de base. Les Servlets serviront de « Contrôleur ». Ils devront exécuter les traitements liés aux requêtes utilisateurs, ainsi que les appels aux modèles « métier ».\nLes JSP permettront de gérer la partie présentation en générant du HTML à envoyer au client. Elles ne devront avoir qu’un minimum de code Java afin d’être optimales.\n· Utiliser un framework\nOn peut par exemple utiliser le framework Struts qui repose sur une architecture MVC (Model View Controller) [FEL06]. Ce framework est basé sur les Servlet / JSP. A l’aide de cette architecture MVC, le travail du développeur est simplifié.\nDans le cas d’applications importantes et si l’on doit utiliser un ensemble de clients très différents tels que des clients WEB, clients riches ou des clients programmés avec des langages divers et variés, l’utilisation des Entreprise JavaBean (EJB) peut être utile.\nCependant, si l’application WEB n’a besoin que d’un seul type de client, on pourra alors utiliser des solutions plus légères telles que Hibernate.\nLes patterns - ou modèles de conception - permettent de répondre à un problème particulier [FRE06]. Le principal intérêt des patterns est de permettre la manipulation d’artefacts plus élaborés que les objets et les classes. Ils augmentent la force d’expression des langages de modélisation.\nLe concepteur d’un pattern propose une solution générique pour un problème donné, qui est souvent rencontré dans divers développements. Cette solution est présentée sous une forme indépendante d’un langage de programmation particulier, ce qui oblige de l’implémenter pour une application donnée.\nIl existe un nombre important de patterns. Ils apportent généralement des solutions aux problèmes critiques. Mais une bonne compréhension de ces derniers est nécessaire afin de ne pas les utiliser dans de mauvaises conditions.\nIls sont généralement représentés sous forme de diagramme UML [ROQ06].\nLors de la mise en place d’une application, on est amené à utiliser un certain nombre de patterns. Nous allons maintenant voir les patterns qui ont été employés dans le cadre de la mise en place de l’application merchandising :\nMVC est l'abréviation de Model View Controller. Le modèle MVC est plutôt un Architectural Pattern qu’un Design Pattern. Il concerne l'architecture globale d'une application et non pas une de ses fonctionnalités.\nMVC organise une application interactive en trois modules séparés. Un premier module permet de gérer le modèle de l’application, la représentation des données et la logique du métier. Un second module permet de gérer les vues qui présentent les données à l’utilisateur et recueillent ses saisies. Le dernier module est un contrôleur qui achemine les requêtes et les flux de contrôle.\nEn utilisant dans nos développements le Framework Struts, nous nous intéresserons à la version 2 de ce modèle (Figure 24) qui a été proposée pour la première fois par Sun Microsystem : MVC 2. La différence entre les deux versions est essentiellement due au fait que dans la seconde version le contrôleur est unique, alors que dans la première il existait une multitude de contrôleurs.\nDans l’approche MVC 2,\nLe Modèle correspond à des JavaBean\nLes Vues sont des pages JSP\nLe Contrôleur est un servlet unique\nFigure 24 : MVC version 2 adapté au développement Web\nL'utilisateur envoie une requête à l'application à l’aide de son navigateur. Il déclenche une action.\nLe Contrôleur reçoit la requête, l'analyse et effectue l'opération sur le Modèle.\nIl fournit ce Modèle à la Vue.\nLa Vue se met à jour en utilisant le Modèle.\nLa Vue est envoyée à l'utilisateur en réponse à sa demande initiale.\nDAO ( Data Access Object)\nLe pattern DAO permet de regrouper les différents modes d’accès aux données persistantes : stockées en base de données, dans des fichiers, dans des annuaires … Ces modes d’accès sont gérés dans des endroits bien distincts de l'architecture et non pas dispersés dans toute l’application.\nDe cette manière, le changement du mode de stockage ne remet pas en cause le reste de l'architecture. Mais cette souplesse a pour inconvénient de rendre la mise en oeuvre des appels plus complexe.\nLe schéma suivant présente le pattern (Figure 25).\nFigure 25 : Design pattern DAO (Data Access Object)\nAbstract Factory (Fabrique Abstraite)\nLe pattern Fabrique Abstraite fournit une interface pour créer des familles d’objets apparentés ou dépendants sans avoir à spécifier leurs classes concrètes (Figure 26).\nLe client est découplé de tous les détails des produits concrets.\nLes fabriques concrètes implémentent les différentes familles de produits.\nPour créer un produit, le client utilise l’une de ces fabriques.\nIl n’a donc jamais besoin d’instancier un objet produit.\nLes méthodes de la fabrique permettant de récupérer un produit doivent renvoyer le type d’interface et pas le type de la classe d’implémentation.\nFigure 26 : Design Pattern fabrique abstraite\nLe singleton est une classe pour laquelle on ne souhaite créer qu’une seule et unique instance pendant toute la durée de l’exécution de l’application. Pour cela, on limite les accès au constructeur qui est déclaré comme privé (private). On implémente une méthode static nommée par convention getInstance() pour obtenir une instance de la classe.\nUn framework est une ossature générale pour le développement d’une application dans un domaine particulier.\nLes frameworks facilitent le travail du développement en fournissant un squelette d’application qu’il suffit de remplir pour l’adapter à ses besoins. Un framework est une surcouche de tous les besoins génériques. On est obligé de supporter un grand nombre de choses même si l’utilisation que l’on en fait est réduite. De plus, du fait de l’ajout de cette surcouche, le temps pris par le développeur pour monter en compétence sur l’environnement sera plus important.\nStruts est un projet Open Source très populaire. De nombreuses entreprises l’utilisent. Il existe énormément de livres, articles, tutoriaux traitants de Struts. Les développeurs l’utilisant bénéficient donc d’une base d’information importante.\nStruts peut être assimilé à une surcouche de Servlet/JSP. Il comble une bonne partie des lacunes du modèle Servlet/JSP.\nIl s'appuie sur MVC version 2. Il met à disposition un ensemble d’outils destinés à organiser de façon simple le modèle MVC au sein d’une application WEB. Il permet de centraliser la navigation du site à un seul endroit. Le comportement de la totalité de l’application WEB est donc configuré dans un seul fichier. Ce fichier, nommé struts-config.xml, est au format XML et est placé dans le répertoire WEB-INF de l'application.\nCe fichier manipule 3 types d'éléments:\nLes ActionForms :\nElles étendent la classe org.apache.struts.action.ActionForm. Elles servent essentiellement de contenant et sont utilisées par le Contrôleur et les Vues. On peut les considérer comme étant des "JavaBeans" spécialisés.\nElles étendent la classe org.apache.struts.action.Action. Elles héritent d'une méthode execute(...) dans laquelle est placé le code à exécuter. Il existe des actions pré-définies pour effectuer des traitements courants tels que les uploads de fichier.\n· Les Forwards :\nIls étendent la classe org.apache.struts.action.ActionForward. Lorsque l'action a terminé ses traitements, ils permettent de déterminer la page vers laquelle l'utilisateur doit être redirigé.\nCycle requête /réponse\nFigure 27 : Cycle requête/réponse classique\nNous allons maintenant voir un cycle requête/réponse classique avec Struts (Figure 27):\nL’utilisateur envoie une requête HTTP à l’aide de son navigateur. Le contrôleur unique, qui est en fait un servlet, intercepte la requête HTTP.\nLe contrôleur sélectionne un ActionForm. Les données de la requête HTTP permettent alors de renseigner l’ActionForm.\nLe contrôleur sélectionne une action à exécuter et lui fournit l'ActionForm.\nL'action utilise l'ActionForm pour mettre à jour le modèle.\nEn fonction du résultat, l'action sélectionne la page JSP à retourner. Elle fournit ensuite l'ActionForm correspondant à la page JSP.\nLa page JSP se génère en utilisant l'ActionForm.\nL'utilisateur reçoit le résultat de sa demande.\nDans une application Web, l’ensemble des pages possède en général un élément central variable entouré d’éléments plus ou moins statiques : barre de navigation, en-tête, colonnes à gauche …\nLa bibliothèque Tiles est un plug-in intégrable à Struts. Elle permet de créer des modèles de page réutilisables pour l’ensemble de l’application à l’aide d’un document XML central.\nCette bibliothèque peut également être utilisée indépendamment de Struts.\nHibernate est un framework Open Source permettant de gérer la couche d’accès aux données [BAU05] [PAT05] [ARN05]. Il est complémentaire au framework Struts qui lui gère l’Interface Homme Machine.\nFigure 28 : Schéma simplifié du fonctionnement d'Hibernate\nIl facilite le travail entre les deux univers que sont l'orienté objet et la base de données relationnelle (Figure 28). Il joint ces deux univers, à travers le mapping objet/relationnel. Le mapping objet/relationnel ou ORM sert à faire le lien entre la représentation objet des données et sa représentation relationnelle.\nHibernate s'occupe du transfert des classes Java dans les tables de la base de données. Il permet également de mettre en correspondance des types de données Java avec les types de données de la base de données relationnelle. De plus, il propose des moyens de requêter et de récupérer les données.\nHibernate est assimilable à une surcouche de JDBC qui permet d’ajouter une dimension objet.\nAu sein d’un outil unique, les IDE (Environnements de Développement Intégrés) donnent la possibilité d'écrire le code, de l'exécuter et de le débuguer. Ils peuvent également permettre la conception d’application de façon graphique.\nPour développer en Java