Mémoire d alternance

Transcription

1 Université Toulouse 2 - Le Mirail 5 Allée Antonio Machado TOULOUSE Master 2 ICE Sogeti France Le Galilée, bât. A ZAC Andromède, Avenue Zigler BLAGNAC Business Unit Midi-Aéro Practice ADMS Mémoire d alternance PHP répond-il aux problématiques de développement industrialisé d applications? Le mémoire d alternance est complété d un rapport d activités du 17/06/2011 au 22/06/2012 Destinataires : M. Jean-Michel INGLEBERT, tuteur universitaire M. Jérôme RAMIER, tuteur entreprise M. Jean-Louis BAUDOIN, chef de projet encadrant Cyril PERRIN Promotion 2012

2 REMERCIEMENTS Avant de commencer ce mémoire d alternance, j aimerais remercier l entreprise Sogeti France dans son ensemble pour m avoir accueilli au sein de la Business Unit Midi-Aéro et plus localement au sein de la Practice ADMS dans le cadre de mes deux années d alternance en Master ICE. Plus particulièrement, je remercie mon responsable M. Jérôme RAMIER ainsi que les différents chefs de projets qui m ont suivi : M. Yoann SUC, M. Sébastien ASCON et M. Jean-Louis BAUDOIN. Je tiens à leur exprimer toute ma reconnaissance pour leur disponibilité et leur pédagogie tout le long de ces deux années d alternance. J aimerais également adresser ces remerciements à mes autres collègues de bureau pour l ambiance sympathique qu ils ont su apporter. 2

3 TABLE DES MATIERES Remerciements... 2 Table des matières... 3 Introduction... 4 L entreprise... 5 Structure... 5 Histoire... 5 Activités... 6 Implantations... 6 Clientèle... 7 Alliances... 7 Les projets... 8 Airbus - Service Catalogue... 8 Latécoère GECKO Pierre Fabre RBP Sogeti Gestion des compétences Sogeti Covoiturage Le mémoire Préambule Formation des équipes Environnement de travail Analyse et Développement Tests et Déploiement Conclusion Conclusion Index lexical Table des illustrations Sources documentaires

4 INTRODUCTION Dans le cadre du Master ICE, j ai effectué mes deux années d alternance au sein de Sogeti France, une SSII dont la société mère est Capgemini. J ai intégré l unité ADMS 1 de la Business Unit Midi-Aéro en tant qu analyste/développeur PHP et Java EE. Ce rapport présente brièvement les activités de ma deuxième année d alternance durant laquelle j ai été encadré par M. Jérôme RAMIER ainsi que M. Sébastien ASCON et M. Jean-Louis BAUDOIN respectivement en tant que responsable et chefs de projet. Ma première année d alternance fut l occasion pour moi de travailler sur la migration d une application en PHP pour le client ATR 2. Il s agissait d une base de données de pièces détachées à destination de ses magasiniers. Ma deuxième année, quant à elle, fut essentiellement consacrée à la refonte d une application en PHP pour le client Pierre Fabre 3. Il s agissait d une base de données de produits destinée à l un de ses pôles marketing et l un de ses pôles scientifiques. Au travers de ce projet, j ai pu suivre le processus de développement d une application dans son ensemble, c est-à-dire de la réponse à l appel d offres à la maintenance. J ai également travaillé pour le client Airbus 4 sur des scripts de synchronisation de bases de données ORACLE et ACCESS en PHP. J ai aussi travaillé pour le client Latécoère 5 sur la rétro-conception d une application PHP vieillissante. Cette dernière mission fut l occasion pour moi de travailler sur un site client. A la fin de ma deuxième année d alternance, j ai eu l occasion de participer à un projet interne visant à modéliser les connaissances de l entreprise. L objectif était la production de graphiques facilitant les prises de décision telles que l embauche ou encore la formation d employés. Ce projet a notamment été pour moi une opportunité de travailler sur la technologie Java EE. Durant ces deux années au sein de Sogeti, le langage PHP fut au centre de la majorité des projets auxquels j ai participé. J ai beaucoup appris de ces différentes expériences. Je profite de ce mémoire pour non seulement synthétiser mes acquis mais également pour effectuer un bilan des outils et des pratiques pour mener à bien un projet PHP. Ce sera l occasion d aborder la question «PHP répond-il aux problématiques du développement industrialisé d applications?». Dans ce rapport, nous ferons tout d abord une rapide présentation de Sogeti qui m a accueilli au cours de ces deux années d alternance. Nous aborderons ensuite les différents sujets que j ai eu à traiter au cours de ma deuxième année d alternance. Pour finir, nous répondrons à la problématique du mémoire sous différents aspects. 1 ADMS : Application Development & Management Services 2 ATR : constructeur aéronautique franco-italien 3 Pierre Fabre : groupe pharmaceutique français 4 Airbus : constructeur aéronautique européen 5 Latécoère : constructeur aéronautique français 4

5 L ENTREPRISE STRUCTURE Capgemini est l un des leaders mondiaux du conseil, des services et de l infogérance en informatique. Implanté dans plus d une trentaine de pays, Capgemini emploie plus de personnes. Le groupe Sogeti est une filiale à 100% du groupe Capgemini. Il s agit d une SSII qui assiste les entreprises et les organismes publics. Implémenté dans 13 pays en Europe, aux Etats Unis et en Inde, Sogeti emploie plus de personnes dont en France. En France, le groupe Sogeti est connu sous le nom de Sogeti France. Sogeti France est découpé en Business Unit elles-mêmes découpées en Practices. Le découpage en Business Unit correspond à un découpage géographique alors que le découpage en Practice correspond à un découpage en métiers. Chaque Business Unit est composée comme suit : Practice Managers (~5) Account Managers (~2) Delivery Manager (~1) Ressources humaines (~1) Business Unit Manager Ingénieurs commerciaux (~6) Professionels (200 à 400) Assistantes (~5) Figure 1 - Ressources d'une Business Unit Je fais partie pour ma part de la Practice ADMS de la Business Unit Midi-Aéro, récente unification des Business Units Midi-Pyrénées et EADS. HISTOIRE Sogeti a été initialement le nom de la maison mère Capgemini dans les années Suite au développement du groupe, la marque disparaît au profit de Capgemini avant d'être réutilisée à partir de 2002 pour la filiale des services de proximité du groupe. 5

6 Voici une liste des dates importantes : 1967 : création de Sogeti : fusion de Sogeti et Cap pour donner Cap Sogeti 1975 : fusion de Cap Sogeti et Gemini Computer Systems pour Cap Gemini Sogeti 1996 : Cap Gemini Sogeti, la maison mère, devient Cap Gemini 2001 : fusion de Cap Gemini, Gemini Consulting et Ernst & Young pour Cap Gemini Ernst & Young 2002 : reprise de l ancien nom Sogeti pour une filiale dédiée aux services de proximité 2003 : OPE de la filiale Sogeti sur Transiciel pour devenir Sogeti-Transiciel 2004 : Cap Gemini Ernst & Young, la maison mère, devient Capgemini 2005 : la filiale Sogeti-Transiciel reprend le nom de Sogeti Depuis, Sogeti a procédé à de nombreuses acquisitions dont : Ad-hoc (2006), InQA.labs (2007), Software Architects (2007), Insight Test Services (2008), Euratec (2008), Vizuri (2008). ACTIVITES Sogeti assiste les grandes entreprises au niveau local au travers d un ensemble de services. Ces services sont regroupés en trois secteurs complémentaires. High Tech Consulting : conseil en haute-technologie, informatique embarquée et R&D externalisée Application Services : intégration et développement de systèmes de gestion Infrastructure Services : o Infogérance et administration de systèmes et réseaux o Conseil dans la sécurité des systèmes d information et d autres solutions informatiques Ci-dessous l importance des trois secteurs en termes de chiffre d affaire : Hight Tech Consulting Application Services Infrastructure Services 25% 17% 58% Figure 2 - Secteurs d'activité de Sogeti IMPLANTATIONS Sogeti comporte plus de 200 implantations dans 15 pays à travers le monde. En France, Sogeti s appuie sur un réseau de 25 agences réparties en 6 régions économiques : La région Nord-Normandie La région Est La région Rhône-Alpes 6 Sogeti : SOciété pour la Gestion de l Entreprise et Traitement de l Information 6

7 La région Méditerranée La région Sud-ouest La région Ouest CLIENTELE Sogeti structure sa clientèle en quatre marchés : Média / Télécoms Aérospatiale / Défense Banque / Finance Energie Voici une liste des principaux clients de Sogeti : EADS, Orange, ING Bank, KPN Telecom, BNP Paribas, Renault, Fortis, Société Générale, Safran, Total, Rabobank, La Poste, SNS REAAL, SCNF, PSA, ABN AMRO, Crédit Agricole, ACHMEA, Alcatel Lucent, Vivendi. ALLIANCES Le groupe a noué deux alliances stratégiques au niveau international : Microsoft et IBM. Ces deux alliances permettent à Sogeti l accès privilégié aux technologies et Microsoft et IBM. Figure 3 - Sogeti partenaire de Microsoft Figure 4 - Sogeti partenaire d'ibm 7

8 LES PROJETS Au cours de ma deuxième année d alternance, j ai travaillé sur cinq différents projets. AIRBUS - SERVICE CATALOGUE Figure 5 - Logo d'airbus LE CONTEXTE Dans le cadre de la mise en application de la bibliothèque de bonnes pratiques ITIL 7, Airbus souhaite mettre en place une vitrine de services. Ces services concernent l installation des postes d utilisateurs. Par exemple, pour installer le poste d un développeur, il faut : une unité centrale, un clavier, une souris, un écran ainsi qu un téléphone fixe. Cette vitrine de services présente la liste des installations possibles ainsi que ce qui les composent. Jusque-là, cette vitrine était mise en place au travers d un site web manuellement développé en HTML. Ceci posait des problèmes de mise à jour pour deux raisons. La première est qu une personne avec des connaissances sur HTML est nécessaire, donc un problème de coût. La deuxième est que le processus n est pas automatisé, donc un problème de temps. Airbus a fait appel à la Business Unit EADS de Sogeti France, récemment fusionnée avec la Business Unit Midi-Pyrénées, pour développer une solution de mise à jour du site web de la vitrine de services. L équipe en charge de ce projet, ne disposant pas de ressources humaines suffisantes pour ce qui est du développement de la solution, a fait appel à la Business Unit Midi-Pyrénées de Sogeti France à laquelle je fais partie. C est dans ce contexte que j ai été intégré au sein de l équipe de ce projet dans les locaux de la Business Unit EADS de Sogeti France. LA SITUATION A mon arrivée sur le projet, les choix techniques avaient déjà été définis. Dans la mesure où Airbus ne peut pas fournir un serveur qui produit des pages dynamiques (PHP, J2EE, ), il n est pas possible de réaliser une application dynamique. L objectif est donc de générer un site web en HTML. Cette génération se fait en deux temps. Tout d abord, des données sont collectées au travers de fichiers EXCEL ainsi qu une base de données ORACLE et placées au sein d une base de données ACCESS. Par la suite, ces données présentes au sein de la base de données ACCESS sont utilisées pour générer le site web en HTML. 7 ITIL : Information Technology Infrastructure Library, ou Bibliothèque pour l Infrastructure des Technologies de l Information 8

9 Mon intervention s est située sur le développement des scripts d importation des données des fichiers EXCEL et de la base de données ORACLE vers la base de données ACCESS. Le script de génération du site web HTML depuis la base de données ACCESS quant à lui a été développé par un collaborateur. La technologie choisie pour développer ces scripts est PHP car il s agit d une technologie facile à manipuler et particulièrement bien adaptée à la rédaction de scripts. Ajouté à cela, Windows est la plateforme sur laquelle seront exécutés les scripts via le binaire PHP qui permet l exécution de scripts PHP sans installation nécessaire. Le lancement de ces scripts s effectue au travers de fichiers BAT. TRAVAUX EFFECTUES Comme je le disais précédemment, mon périmètre d intervention s est situé sur la réalisation de deux scripts PHP. Le premier permet l importation des données EXCEL vers ACCESS. Le deuxième permet l importation des données ORACLE vers ACCESS. ODBC est utilisé pour se connecter aux bases de données ACCESS et ORACLE alors que pour la lecture des fichiers EXCEL, j ai utilisé une librairie PHP. Le processus d importation du premier script était clairement défini avec le client. Ainsi j ai réalisé un script non configurable, c est-à-dire qu il ne sera pas possible de changer la structure des données de la cible ni celle de la source. Pour ce qui du second script, le processus d importation n a pas était clairement défini avec le client et celuici peut subir des modifications. C est pourquoi j ai réalisé un script très configurable, c est-à-dire qu il est possible de redéfinir tout le processus d importation à l aide d un fichier de configuration XML. Ce fichier de configuration est accompagné d un fichier DTD pour aider à sa compréhension. Notons que le fichier DTD est disponible en annexe. Figure 6 - Processus de synchronisation entre ORACLE et ACCESS 9

10 Le fichier de configuration définit une liste d importations. Chaque importation précise la collecte de données dans la source ainsi que le placement de ces données dans la cible. Il est possible d effectuer des traitements intermédiaires entre la collecte et le placement des données. La compréhension de la configuration de ce deuxième script était importante. En effet, ma mission s est terminée au bout de deux semaines. Il fallait s assurer que les possibilités de configuration soient bien comprises par mes différents collaborateurs pour qu ils puissent effectuer les changements nécessaires si les besoins du client venaient à changer à nouveau. Je me suis donc entretenu avec l un de mes collaborateurs pour passer en revue les différents problèmes de compréhension. BILAN SUR LE PROJET D un point de vue technique, ce fut l occasion pour moi de mettre en place un script basé sur le binaire PHP ce qui permet de sortir du contexte habituel où PHP sert principalement à créer des applications WEB. De plus, j ai pu me familiariser avec l outil ODBC interfacé avec ORACLE et ACCESS. Au-delà de la technique, ce projet m a permis de changer de milieu. En effet, j ai toujours travaillé dans les locaux de la Business Unit Midi-Pyrénées de Sogeti. Bien que le client fasse également partie du groupe Sogeti, il s agit de ma première expérience en mission chez un client, si l on met de côté les interventions ponctuelles de livraison que j ai eu à faire pour le client ATR. LATECOERE GECKO Figure 7 - Logo de Latécoère LE CONTEXTE Latécoère est un partenaire de constructeurs aéronautiques. La société assemble différents composants d avions tels que des portes ou bien des portions de fuselage. Chacun de ces composants sont installés sur des séries de modèles d avion et sont uniques sur chacune d entre elles de par les différences des pièces qui les composent. Au cours du temps, des modifications peuvent être apportés sur ces différents composants. Afin de maitriser le cycle de vie des différents composants sur chaque série de chaque modèle d avion au cours du temps, Latécoère a mis en place l outil Gecko. Cet outil traite un large panel de fonctionnalités des spécifications à la maintenance des composants. Gecko a été mis en place il y a une dizaine d années et a subi de nombreuses modifications pour s adapter à des nouveaux besoins de la part des clients, des utilisateurs ainsi que de la législation. Ces modifications ont été essentiellement effectuées par des prestataires externes. Sachant qu aucune documentation n a été produite et qu aucune personne en interne n a suivi le projet depuis ses débuts, Latécoère n a plus la maîtrise de cette application. Ceci pose évidemment de gros problèmes de développement d évolutions et de corrections d anomalies. D autant plus que la qualité du code est exécrable et que de nombreuses parties L utilisation de prestataire a été justifiée pour des raisons de coûts mais cette économie pose à présent problème. Il faut faire un choix : recréer une nouvelle application ou bien continuer d utilisation de Gecko. 10

11 Latécoère a décidé dans un premier temps d effectuer une rétro-conception de l application qui pourra servir dans les deux cas. Cette rétro-conception a pour objectif la réalisation d une documentation des spécifications techniques et fonctionnelles. Une personne interne a été affectée à cette tâche. Pour aider cette personne, Latécoère a effectué un appel d offres à destination de différents prestataires externes. C est Sogeti qui a remporté l appel d offres. C est dans ce contexte que j ai été intégré au sein de l équipe de ce projet dans les locaux de Latécoère aux côtés d un collaborateur Sogeti. LA SITUATION A mon arrivée sur le projet, une première analyse avait déjà été effectuée. Celle-ci concerne la liste cas d utilisation ainsi qu une revue automatique du code. Il en résulte des données suivantes : 56 cas d utilisation lignes de code 50 tables de données 111 classes méthodes L application présente de nombreuses fonctionnalités réparties en 5 phases : spécifications, conception, planification, construction et maintenance. Le déroulement de rétro-conception a été défini comme suit : 1. «Requirements Model» : éléments de spécifications fonctionnelles et non fonctionnelles 2. «Use Case Model» : liste des fonctionnalités sous la forme de cas d utilisation 3. «HMI Model» : ergonomie des écrans ainsi que la navigation entre les écrans 4. «Domain Model» : liste des processus métier 5. «Data Model» : liste des tables de données et leurs relations 6. «Class Model» : liste des classes et leurs relations Un environnement de test a été mis en place pour que nous puissions effectuer tous les tests nécessaires sans impacter l environnement de production. Le logiciel utilisé pour la modélisation est Entreprise Architect. TRAVAUX EFFECTUES Mon périmètre d intervention s est situé sur les modèles «Use Case Model» ainsi que «HMI Model». J ai ainsi pu modéliser une petite dizaine de cas d utilisation. Pour chacun des cas d utilisation, j ai dû modéliser les écrans, diagrammes de séquence système ainsi que diagrammes de séquence associés. Ce travail n a pas été aisé à la fois d un point de vue fonctionnel, car le domaine est très technique, mais également d un point de vue technique, car la qualité du code est médiocre. En effet, il n y a pas aucune séparation en couche : HTML, SQL et PHP sont réunies au sein de mêmes fichiers. Les notions de couche de 11

12 données, couche métier, couche de présentation sont totalement absentes. De plus, aucune documentation n a été rédigée et il a fallu se baser sur les rares commentaires présents dans le code. Les différents diagrammes produits lors de ce projet étant confidentiels, il ne m est pas possible de les exposer au sein de ce document à titre d exemple. BILAN SUR LE PROJET Dans un premier temps, ce projet m a permis de me familiariser avec la rétro-conception au travers de différents modèles. J ai pu ainsi prendre un certain recul sur le code d une application et l appréhender d un point de vue fonctionnel et non d un point de vue technique. Dans un deuxième temps, j ai pu porter ma réflexion sur la vie d un projet. En effet, j ai pu constater les problèmes qui peuvent s accumuler au fil des années au sein d une application lorsque des bonnes pratiques ne sont pas ou mal respectées. Mettre en place les ressources nécessaires, en termes d outils et de professionnels, pour bien mener un projet est un véritable investissement. J ai également pu voir les dérives que peut avoir l utilisation d intervenants extérieurs sans garder la maitrise de l application. PIERRE FABRE RBP Figure 8 - Logo de Pierre Fabre PRESENTATION Pierre Fabre est un acteur majeur du paysage pharmaceutique. Dans le cadre de son activité, le service marketing ainsi que le service de recherche utilisent une base de données de produits issus de la concurrence. Cette base de données a été créée par un prestataire externe en 1998 sous WINDEV. Cette solution devait être temporaire mais n a jamais été remplacé jusqu à aujourd hui bien qu elle présente différents problèmes : l application comprend des bogues qui ont corrompus certaines données l application présente des soucis d ergonomie l accès aux données à tous les collaborateurs n est pas possible Ajouté à cela, le vieillissement de l application entraine des soucis d évolution et de maintenance. D autant plus que le responsable technique de l application a quitté ses fonctions. En parallèle à ces différents problèmes, l application se révèle malgré tout très pratique et de nombreux utilisateurs l utilisent au quotidien. Pierre Fabre a donc souhaité la refonte de l application avec reprise des données. Il s agit d un projet qui nécessite un budget conséquent mais l application est importante pour de nombreux employés, c est pourquoi les fonds ont été alloués au projet. 12

13 EXIGENCES EXIGENCES FONCTIONNELLES La base de données référence une liste de plus de produits. A chacun de ces produits est rattaché un ensemble de données : Segments de marché Sociétés Circuits de distribution Conditionnements Pays Indications Revendications Ingrédients Sans / 0% Caractéristiques L application permet la consultation, la modification et la suppression de ces données. En fonction de son profil, un utilisateur peut effectuer plus ou moins de ces actions. Notons qu ils possible de rattacher à un produit plusieurs fichiers de type JPG ou PDF. L application doit être capable : d exporter des données sous la forme de fichiers EXCEL : o résultat de recherche o liste de tous les utilisateurs o liste de tous les produits (exportation critique car il y a beaucoup de produits) o liste de toutes les caractéristiques o liste de tous les ingrédients (exportation critique car il y a beaucoup d ingrédients) d imprimer des fiches de produits d effectuer une recherche de produits à l aide d un grand nombre de critères EXIGENCES ERGONOMIQUES Il a été demandé d appliquer la charte graphique de Pierre Fabre notamment via l utilisation du logo de la société. Le logo de l application nous a également été imposé, à savoir une grenouille qui lève la main. Figure 9 - Logo de l'application 13

14 Afin de garder le fonctionnement de l application WINDEV, le responsable du projet chez Pierre Fabre a imposé l utilisation de tableaux à défilement infini. La pagination classique de données telle qu on la trouve sur de nombreuses applications web n a pas été retenue. Bien que certaines requêtes soient couteuses en termes de performances, l utilisateur ne doit pas ressentir de latence de la part de l application. Cette demande peut passer par des écrans invitant l utilisateur à patienter accompagné d un logo animé. Par exemple lors de l exportation de la liste de tous les produits ou bien de tous les ingrédients. EXIGENCES TECHNIQUES Dès les débuts du projet, l un des objectifs recherchés était l accès à l application via le navigateur internet. La technologie retenue est PHP/MySQL pour son faible coût d installation et de développement ainsi que la volonté pour Pierre Fabre d augmenter son parc d application utilisant ce langage. La réponse à l appel d offres envoyé par Sogeti a pris en compte les connaissances acquises sur les différents projets PHP réalisés jusque-là tels que le projet HistoSPAS pour ATR sur lequel j ai participé l année précédente. Sogeti a ainsi présenté une solution se basant sur Zend Framework. La plateforme de production cible est Debian. L application doit donc pouvoir s installer et fonctionner sur cette plateforme. L application doit être suffisamment robuste pour supporter plus de produits en base de données ainsi qu au moins 50 utilisateurs en simultanée. Les utilisateurs accéderont à l application via Internet Explorer 6 (ou supérieur) ainsi que Firefox 3.5 (ou supérieur), l application doit donc fournir du contenu compatible pour ces deux navigateurs. Figure 10 - Environnement de production 14

15 TRAVAUX EFFECTUES Mon périmètre d intervention s est relevé relativement large sur ce projet. VALIDATION DE LA REPONSE A L APPEL D OFFRES Le premier contact que j ai eu avec le projet fut la validation de la réponse à l appel d offres. Sogeti a acquis des connaissances dans le développement d applications PHP. Notamment au travers du projet HistoSPAS sur lequel j ai travaillé l année dernière qui reposait sur Zend Framework. C est pourquoi le collaborateur Sogeti, qui a rédigé la réponse à l appel d offres, a proposé une solution se basant sur Zend Framework et m a demandé de valider cette réponse. Ce fut l occasion pour moi de visualiser ce à quoi correspond une réponse à appel d offres. DEVELOPPEMENT DE L APPLICATION Dans ce chapitre, nous allons faire un rapide tour des principaux efforts effectués sur le développement de l application. Pour une meilleure compréhension des fonctionnalités évoquées, un ensemble de captures d écrans est présent en annexe. TABLEAUX A DEFILEMENT INFINI Pour réaliser les tableaux à défilement infini, j ai développé un plugin jquery. Celui-ci permet de construire un tableau infini à partir de données encodés en JSON. Ce plugin respecte le patron de conception MVC 8 dans la mesure où les paramètres de présentation sont situés au niveau de la vue et les données sont récupérées à partir des modèles puis restituées à la vue via le contrôleur. FORMULAIRE D EDITION DE FICHE PRODUIT L application porte principalement sur des fiches de produits. Nous avons donc du développer le formulaire d édition de fiche de produit. Pour ma part, mon travail s est principalement porté sur le traitement des fichiers associés à la fiche du produit en cours d édition. Ces fichiers sont les différentes photos et publicités du produit. Une des principales difficultés était de stocker ces fichiers de manière temporaire sur le serveur pour ne pas obliger l utilisateur à les renvoyer lorsque le formulaire a mal été saisi. Une des autres difficultés fut de permettre à l utilisateur d envoyer un nombre indéterminé de fichiers. RECHERCHE DE PRODUITS L une des grosses fonctionnalités de l application est la recherche de produits. Cette recherche existe en deux versions : la recherche simple et la recherche assistée. La première version propose à l utilisateur de spécifier les critères de recherche via des champs libres. Sur la deuxième version, certains de ces champs libres deviennent des listes où l utilisateur sélectionne les critères de son choix. La difficulté vient du nombre de critères qui entrent en jeu. Cela implique une construction de requête MySQL de sélection complexe. La complexité de la requête générée s associe à la nécessité d avoir un temps de réponse relativement rapide. Celle-ci fut donc l objet d optimisations poussées. L une des optimisations fut par exemple l utilisation de la 8 MVC : Modèle Vue Contrôleur 15

16 capacité de MySQL à indexer des textes en grande quantité, via l option FULLTEXT, et à pouvoir ainsi effectuer des recherches rapides dans les descriptions des produits. COMPATIBILITE IE6 Au premier abord, cela peut paraître étrange de placer la compatibilité de l application avec le navigateur Internet Explorer 6 parmi les principaux axes de développement. Mais il s avère qu il a fallu fournir de nombreux efforts pour supporter ce navigateur à la fois en termes de rendu des pages mais aussi en termes de performances. La lenteur d exécution venait principalement des difficultés d Internet Explorer 6 à traiter du code JavaScript. Par exemple, là où Firefox affiche les tableaux infinis en 250ms, Internet Explorer 6 mettait 2 secondes ce qui est énorme si l on souhaite obtenir une navigation fluide. Après des optimisations du code et l utilisation d astuces JavaScript, Internet Explorer affiche désormais ces tableaux infinis en 500ms ce qui bien meilleur. Ces optimisations portent principalement sur la manipulation du DOM ainsi que les chaînes de caractères. GENERATION DE FICHIERS XSL, PDF ET PPT Lors de la rédaction des spécifications, le client a exprimé le besoin de pouvoir exporter certaines données au sein de fichier XSL, PDF et PPT. A titre d exemple, il a fallu exporter les résultats de recherche de produits sous la forme de fichier XSL et PPT, les fiches de produits sous la forme PDF. Les principales difficultés rencontrées furent dans la génération de fichiers XLS pour les gros volumes ainsi que pour la génération des fichiers PPT. Le premier problème venait de l incapacité de la librairie utilisée à générer des fichiers XSL de grosse taille avec une consommation raisonnable de mémoire. Celui-ci a été résolu via l adoption du format CSV, en accord avec le client, pour la génération des gros volumes. Le deuxième problème venait de l impossibilité de générer des fichiers PPT sans passer par les objets COM 9 disponibles uniquement sous l environnement Windows alors que l environnement cible est Linux. Celui-ci a été résolu via la génération de fichiers HTML respectant un format défini et compatible avec PowerPoint. TESTS Bien que je n aie pas réalisé la phase de tests de l application, je vais en parler brièvement. Deux types de tests ont été effectués : tests des fonctionnalités et tests de montée en charge. Les tests unitaires et d intégration n ont pas été mis en place. Ces tests ont été effectués dans le cadre de la phase de pré-recette. A cette occasion, un serveur de pré-recette a été mis en place au sein de Sogeti pour tester l application sur la plateforme de production cible. Le document de spécifications fonctionnelles défini un ensemble de règles de gestion que l application doit supporter. Chacune de ces règles de gestion ont été testées sur l application. Dès lors qu un souci est détecté, la personne en charge des tests remonte l erreur au niveau de l outil de suivi de problèmes et un est envoyé dans ma boîte de réception. Je suis ainsi prévenu des anomalies à corriger. Dès lors que l anomalie est corrigée, je le signale sur l outil de suivi de problèmes et la personne en charge des tests test à nouveau la règle de gestion concernée. 9 COM : Component Object Model, technique de Microsoft permettant de communiquer entre programmes 16

17 Pour ce qui des tests de montée en charge. La personne en charge des tests a configuré des scénarios d utilisation de l application puis a simulé 50 utilisateurs qui parcourent l ensemble de ces différents scénarios en simultanée. La série de tests effectués a montré que l application se comporte bien. REALISATION DU SCRIPT DE REPRISE DE DONNEES Il a fallu reprendre les données de l application WINDEV pour les intégrer dans la nouvelle application. Cette opération s est concrétisée par le développement d un script PHP de reprise de données. Deux problèmes sont alors apparus : la qualité des données est déplorable et le modèle de données source ne correspond pas au modèle de données cible. La solution adoptée est de compléter la base de données WINDEV, sur laquelle nous allons récupérer les données qu il est possible d extraire, par des fichiers EXCEL, sur lesquels nous allons récupérer les données restantes. Ces fichiers sont remplis manuellement, à l aide d extraction de données depuis la base de données WINDEV, par Pierre Fabre. Cette opération fut très laborieuse pour les personnes qui en été chargées car cela représente des centaines de millier de lignes à traiter. C est principalement pour cette raison que le projet a subi des retards. La reprise de données est l occasion de régler des problèmes liés à l application WINDEV. C est pourquoi le script de reprise de données effectue une batterie de tests sur les données récupérées. Toutes les erreurs détectées sont remontées au sein de fichiers EXCEL. Ces fichiers sont ensuite transmis à Pierre Fabre qui se charge de corriger les erreurs au sein de l application WINDEV et dans ses fichiers EXCEL, puis une nouvelle reprise de données est effectuée. La récupération des données WINDEV se fait au travers des pilotes ODBC de WINDEV. La reprise de données comprend également l intégration des photos de l ensemble des produits. Celles-ci sont au nombre de Cette fois ci, le script de reprise de données ne se base pas sur l application WINDEV mais sur un dossier de photo structuré fournit par Pierre Fabre. L intégration de ces photos s effectue en deux étapes : redimensionnement et restructuration des photos. Le redimensionnement permet d éviter aux utilisateurs d attendre trop longtemps le chargement des photos et au serveur d être surchargé. En effet, certains photos de produits sont effectuées par un professionnel à l aide d un appareil photo professionnel et peuvent atteindre 11mo. Le redimensionnement est effectué au travers d un outil de traitement d images par lot. L opération, qui dure deux heures, permet d obtenir pour chaque photo une photo en 1024*768 ainsi qu une miniature en X*300. La restructuration des photos quant à elle permet d obtenir une structure de photos compatible avec la nouvelle application. Cette opération dure une heure. Comme évoqué précédemment, la reprise de données s est effectuée en itérations. Les dernières itérations ont été effectuées sur l un des sites de Pierre Fabre situé à Lavaur avec le responsable du projet chez Pierre Fabre. Ces dernières itérations ont pris une journée. A la fin, aucune erreur n est remontée. REDACTION DE DOCUMENTS Au cours de ce projet, j ai eu l occasion de préparer des paquetages à destination de la plateforme de recette ainsi que de la plateforme de production. Ces paquetages comprennent : le script MySQL de création de la base de données les sources de l application PHP les tâches CRON à installation sur la plateforme 17

18 la documentation de l application Dans ce dernier point, nous retrouvons : Spécifications fonctionnelles détaillées Spécifications techniques détaillées Document de reprise de données Manuel d installation Manuel d exploitation Modèle conception/physique de données Je me suis chargé de rédiger le document de spécifications techniques détaillées, le manuel d installation ainsi que le manuel d exploitation. SUPPORT TECHNIQUE POUR LA REDACTION DE SPECIFICATIONS La majorité des spécifications fonctionnelles ont été traitées sans mon intervention. Cependant, j ai effectué un support technique auprès de mon chef de projet et participer à l élaboration de spécifications concernant certaines problématiques fonctionnelles ainsi que sur le processus de reprise de données. J ai ainsi participé à deux réunions de quatre heures chacune sur un des sites Pierre Fabre situé à Lavaur. Les intervenants étaient : le responsable du projet ainsi que le responsable technique chez Pierre Fabre, le chef de projet ainsi que moi-même chez Sogeti. SUPPORT TECHNIQUE POUR LA MISE EN RECETTE Lors de la première mise en recette de l application sur la plateforme de recette de Pierre Fabre, j ai assisté le responsable technique pour régler les éventuels problèmes non documentés dans le manuel d installation. Ce support s est effectué sur l un des sites de Pierre Fabre situé à Castres. CORRECTION D'ANOMALIES Suite à la mise en recette de l application, des employés de Pierre Fabre ont effectué une batterie de tests sur l application. Notre outil de suivi de problèmes a été spécialement configuré pour permettre aux employés de transmettre les erreurs détectées via cet outil. Ce fut très pratique à la fois du côté de Pierre Fabre mais également du côté Sogeti car toute erreur fut tracée et suivie. De la même manière que la phase de pré-recette citée précédemment, la phase de recette s est déroulée en plusieurs itérations. Je me suis chargé de prendre en charge l ensemble des erreurs validées par mon chef de projet. DEVELOPPEMENT D'EVOLUTIONS Au cours des différents tests effectués sur l application lors de la phase de recette, le responsable du projet chez Pierre Fabre a demandé des ajustements plus ou moins importants. Je me suis chargé de prendre en charge l ensemble des anomies validées par mon chef de projet. 18

19 OUTILS UTILISEES Figure 11 - Logo de Zend Framework L application se base sur Zend Framework et profite ainsi : du support du patron de conception MVC (via Zend_Controller) d un système de configuration (via Zend_Config) d un système de logs (via Zend_Log) d un système d authentification (via Zend_Auth) d un système de droits utilisateur (via Zend_ACL) d un système d envoi d s (via Zend_Mail) Figure 12 - Logo de WebProjectHelper L outil WebProjectHelper a été utilisé pour générer les diverses classes de persistance. A l aide d un simple script de description de diagramme des classes, l outil est capable de générer le script MySQL de création des tables ainsi que les classes PHP associées. Figure 13 - Logo de TeamForge Nous avons utilisé TeamForge et notamment ses outils de gestion de sources, de gestion de documents ainsi que de suivi de problèmes. Pour ce qui est du suivi de problèmes, nous l avons utilisé à la fois en interne lors de la phase de pré-recette mais également avec le client lors de la phase de recette. En termes de librairies, nous avons utilisé PHPExcel et TCPDF pour la génération des fichiers XLS et PDF. Sur nos postes nous avons utilisé : Eclipse pour l édition des sources PowerAMC pour la modélisation du diagramme des classes JMeter pour les tests de montée en charge XnView pour le redimensionnement des photos par lots BILAN SUR LE PROJET D un point de vue technique, ce projet m a permis de confirmer mes compétences avec Zend Framework ainsi que jquery. Ce fut pour moi également l occasion de manipuler différentes librairies de génération de 19

20 fichier PDF et XLS. Ajouté à cela, j ai pu appréhender les problématiques de reprise de données d une application vieillissante. Au-delà du côté technique, ce projet fut pour moi l occasion d avoir une vue global sur le développement d une application, de la spécification à la mise en production en passant par le développement et la recette. J ai pu ainsi rencontrer le client à de nombreuses reprises, que ce soit au téléphone au bien lors de réunions dans des locaux de Pierre Fabre à Lavaur. SOGETI GESTION DES COMPETENCES PRESENTATION Comme toute SSII, ce que vend Sogeti à ses clients est l ensemble des compétences de ses professionnels mises en pratique au sein de projets. Avoir une bonne vision sur ces compétences est donc un plus indéniable. Les outils existant au sein de Sogeti sur ce terrain ne permettent pas une analyse fine des compétences revendiqués par la société. Il s agit notamment d entrepôts de CVs permettant la recherche de professionnels possédant une liste de compétences donnée. L objectif de ce projet est de fournir une application permettant de réaliser une telle analyse permettant de prendre des décisions stratégiques sur l embauche et/ou la formation de professionnels en vue de confirmer sa présence sur certains secteurs du marché ou d en conquérir de nouveaux. Il s agit d un outil d aide à la décision. Ce projet a une deuxième finalité. Il permet d occuper les professionnels de Sogeti en attente d affectation à une mission. Le bénéfice est double. D une part, ils contribuent à l autofinancement de la société via la production d une application à usage interne. D autre part, c est une occasion pour eux de se former aux technologies mises en pratique pour ce projet. N ayant pas été affecté à une mission à la suite du projet RBP pour le client Pierre Fabre, c est donc tout naturellement que j ai rejoint ce projet interne au sein d une équipe de trois autres professionnels. Le projet en était à ses débuts, il nous a donc fallu l initier. EXIGENCES EXIGENCES FONCTIONNELLES Comme je l expliqué précédemment, le projet n en était qu à ses débuts à mon arrivée. Les exigences fonctionnelles avaient été exprimées via une liste peu détaillée de la part des décideurs. Nous avons dû reprendre cette liste et rédiger un document d exigences fonctionnelles. Ce document nous a permis d obtenir la liste des tâches à effectuer. Nous avons divisé l application en deux catégories d exigences fonctionnelles : la saisie de données et la génération de graphiques. Dans un premier temps, l utilisateur rentre l ensemble des données au travers de formulaires et/ou de fonctionnalités d importation. Dans un deuxième temps, l utilisateur génère les graphiques qu il souhaite. L une des exigences exprimées par les décideurs fut de pouvoir demander au système une vue sur les compétences des professionnelles à la fois à un instant donné mais également dans le temps. Nous avons donc porté notre réflexion sur l élaboration de différents graphiques en prenant en compte cette contrainte. Ci-dessous la liste des graphiques : 20

21 Radar de compétences Répartition des professionnels par compétences Répartition des professionnels par niveaux par compétences Evolutions des compétences par nombres de professionnels Evolution des compétences par niveaux EXIGENCES ERGONOMIQUES Pour ce qui est de l ergonomie de l application, nous avons dû réaliser une interface élégante pour convaincre les décideurs et respecter la charte graphique de Sogeti. Ce respect de la charte graphique passe notamment par l utilisation des couleurs et du logo de Sogeti. EXIGENCES TECHNIQUES D un point de vue technique, nous sommes partie sur une solution Java EE 7 basée sur JBoss AS 7 accessible depuis les navigateurs Internet Explorer 7 et plus ainsi que Firefox 3.5 et plus. Dès le début, notre chef de projet nous a orientés vers les technologies suivantes : Gestion des dépendances : MAVEN Construction des graphiques : BIRT 10 Aide à l application de MVC : STRUTS Persistance des données : JPA/Hibernate et PostgreSQL Pour ce qui est de la plateforme cible, il s agit de CentOS. EXIGENCES ORGANISATIONNELLES Dans la mesure où l application vit des développements effectués par des professionnels qui vont et qui viennent, il est impératif de mettre en place des mesures pour faciliter les transferts entre les différentes équipes qui y contribuent. Nous avons rédigé de la documentation pour aider les nouveaux professionnels sur le projet à mieux le cerner au niveau fonctionnel et conceptuel ainsi que des guides. Nous avons également mis en place une machine virtuelle sur laquelle est installé l environnement de développement : Eclipse Indigo, JBoss AS 7 ainsi que tous les autres outils nécessaires au projet. Dès lors qu un professionnel est affecté à ce projet, il lui suffit de récupérer la machine virtuelle pour être opérationnel. Le gain de temps lié à l installation de l environnement de développement est considérable. TENDANCES AGILES Le besoin n était pas clairement défini et le projet avait besoin de méthodes souples quant aux possibles changements d orientations. Dès de début, notre chef de projet nous a orientés sur la pratique de l agilité. Nous ne l avons pas pratiqué dans l état de l art mais plutôt au travers de certaines techniques. Nous nous sommes notamment inspirés de certaines facettes de SCRUM telles que : l utilisation des rôles SCRUM Master et Product Owner ainsi la mise en pratique des SCRUM Meetings. Ajouté à cela, nous avons procédé par prototypages ce qui a permis au Product Owner de mieux évaluer l avancement du projet. 10 BIRT : Business Intelligence and Reporting Tools 21

22 Nous avons également utilisé une variante du Kanban. Cette variante consiste à placer l ensemble des tâches restantes sur un bureau parmi lesquelles chaque développeur doit piocher celle dont il s occupera. Une fois qu un développeur a fini sa tâche, il la place au sein d un contenant. De cette technique, nous avons pu en tirer une visualisation rapide des tâches restantes, affectées et effectuées. Pour ce qui est des tests unitaires et d intégration, nous n avons pas réussi à les mettre en place. Malgré tous les efforts que nous y avons consacrés, nous nous sommes heurtés à des problèmes d ordre technique. Pour information, nous avons tenté de mettre place la plateforme de test Arquillian développée par la communauté JBoss. C est regrettable pour trois raisons. Dans un premier temps, l application aurait pu voir sa qualité augmenté. Dans un deuxième temps, la maitrise des tâches restantes à effectuer aurait pu être accrue via la mise en place du développement dirigé par les tests. Pour finir, les tests auraient pu faciliter la compréhension du code pour tout nouveau développeur qui arrive sur le projet. Figure 14 - Logo d Arquillian Quant aux tests fonctionnels, nous avons utilisé TestLink. Il s agit d un outil de suivi de tests au travers duquel on peut saisir un ensemble de fonctionnalités à tests avec un descriptif des exigences pour chacune de ces fonctionnalités. Les testeurs se basent sur ces données pour effectuer leurs tests et les valident ou non en fonction des résultats obtenus. TRAVAUX EFFECTUES CONCEPTION DU MODELE DE DONNEES L une des premières tâches que nous avons effectuées est la modélisation des compétences. Cela peut sembler banal mais cela requiert du temps avant d obtenir un modèle de données suffisamment aboutit. Nous avions deux objectifs. Le premier objectif est de rendre la saisie de données facile et rapide. Il ne faut pas que cette saisie des données n empiète trop sur le temps des personnes chargées de cette tâche. Il ne faut pas non plus que cette saisie de données soit ambiguë. Le deuxième objectif est d offrir des possibilités d exportation intéressantes. Pour effectuer ce travail, nous nous sommes penché sur l article «Construction d une ontologie basée compétence pour l annotation des CVs et offres d emploi» écrit par des membres du laboratoire LIRE de l université de Mentouri de Constantine en Algérie. Cet article propose une ontologie pour la modélisation du contenu sémantique de CVs et offres d emploi en vue d effectuer un rapprochement. Il propose une modélisation avancée des compétences. Nous l avons simplifié pour éviter une saisie des données trop contraignante et modifié pour prendre en compte l aspect temporel de l acquisition des compétences. Le modèle de données produit est disponible en annexe. 22

23 REALISATION DE L INTERFACE GRAPHIQUE Comme vu précédemment, l interface de l application doit véhiculer l image de Sogeti au travers du logo et des couleurs utilisées. Pour cela, j ai repris des éléments d interface du site WEB officiel de Sogeti. Les technologies que j ai utilisées sont HTML et CSS. Un écran de l interface graphique est disponible en annexe. SEPARATION EN COUCHES Dans la mesure où le projet est destiné à recevoir principalement des développeurs de passage, l application doit être rapidement abordable et ne pas paraître aux yeux des nouveaux venus comme un «plat de spaghettis». Notre chef de projet nous a ainsi orientés vers une séparation de l application en cinq couches distinctes. Chaque couche permet de s abstraire d une problématique. Figure 15 - Séparation en couches La première couche est la couche de persistance qui permet le chargement et la sauvegarde de données sur un support physique (une base de données PostgreSQL dans notre cas). A ce niveau, les données n ont pas encore de sens et aucun traitement avancé ne peut être effectué sur les données. Au sein de cette couche, nous avons utilisé Hibernate comme implémentation JPA 11. La deuxième couche est la couche métier qui possède la logique métier. Elle fournit un point d accès aux données (mise en pratique du patron de conception DAO 12 ). Cette fois-ci, les données ont un sens et c est à ce niveau que l on retrouve des traitements avancés sur les données. C est au sein de cette couche que l on retrouve notamment les requêtes JPQL 13 qui permettent des sélections de données relativement complexes. Les objets qui composent cette couche sont sous la forme d EJB 14 et pourront donc à l avenir prendre facilement place au sein d un environnement d applications distribuées. La troisième couche est la couche contrôleurs qui joue le chef d orchestre de l application. Elle réceptionne la requête de l utilisateur, fait appel à la couche métier si nécessaire puis passe la main à la couche vues. On peut considérer cette couche comme le point centrale de l application. Au sein de cette couche, nous avons utilisé STRUTS (les actions). 11 JPA : Java Persistance API 12 DAO : Data Access Object 13 JPQL : Java Persistance Query Language 14 EJB : Entreprise Java Bean 23

24 La quatrième couche est la couche vues qui permet l affichage des écrans. Celle-ci ne doit s occuper que d affichage et doit éviter tout traitement trop complexe. Pour cela, il faut par exemple que la couche contrôleurs ait suffisamment préparé les données pour les afficher sans avoir à les traiter au sein de la couche vues. Au sein de cette couche, nous avons utilisé STRUTS (les vues) et BIRT. Pour finir, la cinquième couche est la couche services WEB qui permet à d autres applications de communiquer avec notre application. Celle-ci effectue un travail semblable à la couche contrôleurs avec la particularité de ne pas être en relation avec un utilisateur humain mais une application. UTILISATION DE MAVEN Nous avons utilisé Maven, de la fondation Apache, pour : initialiser le projet et ses sous-projets gérer les dépendances de librairies construire l EAR à déployer Figure 16 - Logo de Maven Pour ce qui est de l initialisation du projet, Maven propose un mécanisme d archétypes. Un archétype correspond à un squelette de projet prêt à l emploi. N importe qui peut proposer des archétypes au travers de répertoires d archétypes en ligne. L objectif de ce mécanisme est d éviter de perdre du temps sur la mise en place d un projet. En effet, le développeur qui doit mettre en place un projet n a plus qu à choisir parmi la liste des archétypes à sa disposition l archétype qui correspond à ses besoins. Maven télécharge ensuite l archétype sélectionné. Dès lors que l archétype est récupéré, les développeurs peuvent commencer à développer sans avoir eu à se soucier de l arborescence et la configuration propre au type de projet. Dans la mesure où n importe qui peut proposer des archétypes, on peut très bien mettre en place des serveurs d archétypes d entreprise. On pourrait y retrouver des archétypes propres à certains clients et/ou certaines technologies. Pour le projet, j ai sélectionné un archétype, depuis le répertoire d archétypes JBoss, qui permet la création d un projet EAR avec ses différents sous-projets EJB, JPA, WEB et WEB Services. Quant à la gestion des dépendances des librairies, Maven met à disposition un mécanisme de gestion des dépendances avancé. Plutôt que de spécifier l emplacement des librairies utilisées par le projet sur l ordinateur du développeur, celui-ci spécifie la liste des dépendances au sein d un fichier de configuration XML («pom.xml»). Ces dépendances correspondent à des librairies présentes sur des répertoires de librairies en ligne. Un tel mécanisme présente plusieurs intérêts. Tout d abord, les développeurs n ont plus à se soucier d obtenir les librairies nécessaires au projet dans la mesure où elles sont récupérées automatiquement par Maven tout en gérant la problématique des dépendances de dépendances. Ensuite de la même manière que pour les archétypes vus précédemment, n importe qui peut proposer son répertoire de librairies Maven. On peut donc créer des répertoires d entreprise de librairies Maven propres à certains clients et/ou technologies. 24

25 Pour finir, Maven est un outil d automatisation des tâches répétitives que l on retrouve tout le long du cycle de développement d un projet. Sur ce point, il peut être comparé à l outil Ant de la fondation Apache. On peut installer automatiser la compilation, le déploiement, la documentation, les tests, Nous utilisons Maven pour construire l EAR qui sera déployé sur le serveur d applications JBoss AS 7. J ai rencontré des difficultés sur la cohabitation de Maven avec SVN. Alors que la publication du projet sur le dépôt SVN n a pas posé de problèmes, la récupération du projet avec les outils SVN classiques fournis au sein du plugin SVN d Eclipse était impossible. En effet, il est impossible de récupérer un projet Maven multimodule via un simple CHECKOUT. Il m a fallu pour cela exploiter les capacités du plugin Maven d Eclipse pour effectuer la récupération du projet. UTILISATION DE STRUTS Nous avons utilisé le framework STRUTS, de la fondation Apache, pour faciliter la mise en pratique du patron MVC. Nous en avons tiré un bon nombre d avantages parmi lesquels trois principaux avantages. Le premier avantage est la description facilitée des traitements effectués suite à la réception d une requête de l utilisateur au travers d un fichier XML («struts.xml»). Comme le montre le schéma ci-dessous, STRUTS capture la requête de l utilisateur et détermine quelle action (classe JAVA) doit être appelée en fonction de l URL de la requête. Les actions jouant le rôle de contrôleurs. Par la suite, STRUTS affiche la vue (fichier JSP 15 ) correspondant au code de retour de l action. Ce mécanisme permet un bon découpage entre les vues et les contrôleurs tout en offrant une abstraction sur l appariement entre l URL d une requête et les traitements correspondant. Figure 17 - Traitements effectuées suit à la requête de l utilisateur Le deuxième avantage est la possibilité d utiliser une alternative au code Java pour récupérer et afficher les données envoyées par l action via les TagLibs. Afin de pousser les développeurs à éviter d insérer du code Java au sein des vues, STRUTS met à leur disposition des balises XML qui permettent d effectuer des traitements tels que l affichage de données, la construction d éléments HTML ou encore des boucles de 15 JSP : JavaServer Page 25

26 contrôle. Grâce à ce mécanisme, aucun code Java n est présent au sein des vues ce qui permet une meilleure lecture de celles-ci. Ci-dessous un exemple d utilisation pour une meilleure compréhension : <table> <s:iterator value="collaborateurs"> <tr> <td><s:property value="prenom" /></td> <td><s:property value="nom" /></td> </tr> </s:iterator> </table> Figure 18 - Exemple d'utilisation des TagLibs Le troisième avantage est la possibilité de créer des vues de manière modulaire via le plugin Tiles. Cela permet une factorisation des parties du code HTML telles que l entête, le pied de page ou encore le menu. Ainsi, aucun code HTML n est dupliqué et seul le code HTML propre à chaque écran est placé au sein de la vue correspondante. La configuration de cette factorisation est placée dans un fichier XML («tiles.xml») où chaque écran est décrit comme combinaison de plusieurs JSPs. Le nom de chaque écran est réutilisé au sein de fichier de configuration «struts.xml» vu précédemment. Figure 19 - Exemple de factorisation avec le plugin Tiles UTILISATION DE BIRT Nous avons utilisé BIRT, de la fondation Eclipse, pour la génération des graphiques. Plus qu une simple librairie, il s agit d un projet complet de BI 16 permettant la génération de rapports à partir de différents types de sources de données : fichiers XML, bases de données via JDBC, services WEB, objets Java,... Ces rapports sont constitués d éléments tels que des tableaux, des graphiques, BIRT repose sur trois sous-projets : un éditeur de rapport WYSIWYG 17 intégré à Eclipse ainsi qu un moteur de génération de rapport et un moteur de génération de graphiques. Ces derniers sont disponibles sous la forme de librairies Java. 16 BI : Business Intelligence, ou Informatique décisionnelle 17 WYSIWYG : What You See Is What You Get 26

27 Figure 20 - Génération d un rapport avec BIRT Le gros avantage de BIRT est l abstraction qu il offre sur la génération des rapports. Grâce à l éditeur de rapport, j ai pu construire des rapports très facilement et relativement complexes sans avoir eu à me soucier de la technique sur laquelle repose BIRT. Dès que le fonctionnement de celui-ci est compris, la seule problématique à régler est la production des données. Pour cela, j ai mis en place pour chacun des graphiques une source de données alimentée via un objet Java. Ces objets Java font le lien avec la couche métier que nous avons vu précédemment. L utilisation de BIRT ne compromet donc pas la séparation en couches. REDACTION DE GUIDES La plupart des technologies mises en pratique au cours de ce projet ne sont pas évidentes au premier abord le chef de projet m a donc demandé d écrire deux guides permettant de mieux les appréhender. L objectif est d éviter la perte de temps pour les professionnels qui seront affectés à ce projet. Le premier guide concerne la mise en place de l environnement de développement. Par la suite, l environnement de développement a été porté sur une machine virtuelle et ce guide a donc perdu de l intérêt. Le deuxième guide, quant à lui, présente la marche à suivre pour créer un rapport via l éditeur de rapport de BIRT tout en respectant la séparation en couches vue précédemment. De nouveaux graphiques devront probablement être développés pour couvrir de nouveaux besoin et ce guide permettra une prise en main facilité de BIRT. BILAN SUR LE PROJET Ce projet fut pour moi une porte d entrée sur la technologie Java EE. Jusque-là, l ensemble des projets qui m ont été confiés reposaient sur PHP. Non seulement j ai pu faire mes premiers pas sur cette technologie en entreprise mais également sur des outils qui gravitent autour tels que JPA/Hibernate, STRUTS, BIRT ou encore Maven et des bonnes pratiques telles que la séparation en couches. D un point de vue technique, ce projet fut donc très formateur. D un point de vue organisationnel, j ai pu appréhender certains concepts d agilité dans un environnement professionnel. J ai pu constater la nécessité d un outil de gestion de projet agile pour épauler la démarche. En effet, nous avons rencontré des difficultés quant au suivi du projet : estimation du temps restant et passé avec précision. A l avenir, je serais favorable à l établissement d un premier sprint incluant la mise en place d un tel outil. J ai également pu constater qu il était difficile de développer en parallèle à de la gestion de projet. A l avenir, je serais également favorable à une meilleure segmentation de ces deux activités. 27

28 SOGETI COVOITURAGE PRESENTATION Ce dernier projet concerne le développement d une plateforme de covoiturage à destination de téléphones mobiles. Les périphériques de nos villes sont de plus en plus saturés. Le prix du carburant est de plus en plus important. Des solutions tels que le covoiturage ont ainsi vu le jour. L objectif de ce projet est de permettent à un ensemble d utilisateurs de fournir des trajets en tant conducteur et/ou de chercher des trajets en tant que passager. Cet outil sera voué à une utilisable en mobilité et c est pourquoi il faut privilégier l accessibilité aux téléphones mobiles. L appel d offre n a pas encore été remporté par Sogeti. L objectif du projet est de réaliser une démonstration technique à présenter au client. Pour des raisons stratégiques, le client de ce projet ne peut être cité. Lorsque je suis arrivé sur le projet, les choix techniques avaient déjà été effectués. C est la solution d une application WEB qui a été retenu. Le principal avantage est le faible coût de développement pour une très bonne compatibilité avec les plateformes mobiles du marché. Celle-ci sera composée de : un serveur Apache : o délivrant du contenu statique (HTML, JavaScript, CSS, ) o délivrant des données cartographiques via Mapnik et stockées via PostGIS 18 un serveur Tomcat offrant des services WEB applicatifs et de résolution de trajets Les écrans seront réalisés à l aide du framework jquery Mobile. Les cartes seront affichées au sein des écrans à l aide de la librairie OpenLayers. Les données qui alimentent la base de données cartographique viennent d OpenStreetMap. Ci-dessous un schéma pour mieux comprendre les interactions entre les différents composants de l application : Figure 21 - Interactions entre les différents composants Comme nous pouvons le voir, les pages de l application sont délivrées par le serveur Apache et sont dénuées de toute donnée. C est au JavaScript (utilisation des capacités AJAX de jquery) de récupérer ces données auprès des services WEB (production de JSON) et de les intégrer aux pages. 18 PostGIS : plugin de PostgreSQL permettant le traitement d objets spatiaux 28

29 A mon arrivé sur le projet, une phase exploratoire quant à la mise en pratique de jquery Mobile et de la librairie OpenLayers. Ainsi, je n ai pas eu à me soucier des problématiques liées à l intégration de ces deux technologies. De plus, la couche de persistance et une partie de la couche métier avaient déjà été développées. Dans la mesure où ma participation à ce projet est toute récente, je ne ferais qu en parler brièvement et n exprimerais pas de bilan. TRAVAUX EFFECTUES Au cours des dernières semaines, j ai travaillé avec un autre collaborateur qui s est chargé de développer un service WEB permettant le tracé d un trajet entre deux points au format GeoJSON. L intérêt de ce format est qu il largement répondu dans le domaine de la cartographie. Il est notamment compatible avec la librairie d affichage des cartes utilisée : OpenLayers. Mon travail quant à moi fut principalement orienté sur le développement des services WEB applicatifs. Pour cela, mon chef de projet m a orienté sur l utilisation de la librairie Jersey qui facilite grandement ce travail au travers de l utilisation d annotations. Ces annotations permettent non seulement la description d un service WEB mais également de la sérialisation des objets retournés en JSON. Pour information, Jersey est une implémentation de JAX-RS 19, une API 20 Java pour la construction de services WEB avec une architecture REST 21. Je suis me suis également occupé du développement des écrans avec jquery Mobile et leur alimentation auprès des services WEB. Après avoir régler quelques soucis de communication avec les services WEB (cf. CORS 22 ), l une des problématiques fut la complexité générée par le nombre grandissant de sources JavaScript au fil des développements des écrans. Pour régler cela, j ai mis en place une architecture modulaire où chaque écran dispose d un espace de nom qui lui est propre, par exemple : «com.sogeti.covoiturage.monecran». Chaque espace de nom est associé à un ensemble de fonctions et de données. Ceci permet un bon cloisonnement des sources JavaScript. Dans la mesure où chaque espace de nom est défini dans un fichier, il en résulte un nombre important de fichiers à charger de la part du navigateur. J ai donc développé un outil très simple qui permet la concaténation de toutes les sources JavaScript en un seul fichier. De même pour les sources CSS. J ai combiné cet outil à l outil YUI Compressor qui permet de compresser des fichiers JavaScript et CSS. Nous obtenons ainsi deux avantages : moins de requêtes et des sources plus légères. A ce jour, j ai pratiquement terminé les traitements applicatifs. La prochaine étape est l intégration du travail du deuxième collaborateur sur ce projet, c est-à-dire l ajout des cartes interactives au sein des écrans pour afficher des trajets. 19 JAX-RS : Java API for RESTful Web Services 20 API : Application Programming Interface 21 REST : REpresentational State Transfert 22 CORS : Cross-Origin Resource Sharing 29

30 LE MEMOIRE Figure 22 - Logo de PHP PREAMBULE PHP a été créé en 1994 par Rasmus Lerdof pour élaborer son curriculum vitae. PHP n était à ses débuts qu un ensemble de binaires écrits en C facilitant la création d un site WEB. Ces binaires furent publiés et utilisés par un nombre conséquent d utilisateurs. Au fil du temps, de plus en plus de fonctionnalités supplémentaires sont demandées par les utilisateurs. A l écoute des utilisateurs, Rasmus Lerdof améliore progressivement les binaires de PHP. Les sources de PHP furent publiées en 1995 pour en faire profiter la communauté. En 1996, Rasmus Lerdof reprend entièrement le code de PHP. Il en résulte un vrai langage de programmation. En 1997, Andi Gutmans et Zeev Suraski reprennent les sources de PHP et développent la version 3 en 1998 puis la version 4 en C est à l occasion de cette version que le moteur Zend 23 Engine fut développé. C est en 2004 que PHP 5 est publié apportant son lot de nouvelles fonctionnalités parmi lesquelles le support de la POO 24. A ce jour, la dernière version stable de PHP est la Année après année, PHP a bénéficié de nombreuses contributions le rendant plus mature : fonctionnalités, performances, bogues, failles, qualité, documentation, Ajouté à cela, des extensions PEAR 25 et PECL 26 furent développées et apportent des fonctionnalités supplémentaires à PHP. De nombreux outils, frameworks et librairies furent également développés et complètent l écosystème PHP. Le langage est ainsi devenu progressivement une solution viable auprès des entreprises. Dans un premier temps, PHP s est introduit dans l entreprise pour son côté pragmatique. En effet, l installation et le développement sont accessibles. De plus, il s intègre très bien au milieu de technologies déjà mises en place et fournit des services immédiats (accès à une base de données, envoie de courriers électroniques, ). Ces qualités ont fait de PHP une solution intéressante pour des petites applications du quotidien qui nécessitent peu de temps de développement : gestion de notes de frais, carnet de contacts, gestion de planning Par la suite, ces applications ont pris de plus en plus d importance. Une récente étude sur l adoption de PHP en entreprise commandée par Zend et publiée le 12 juin 2012 confirme que PHP est bien implanté dans le monde professionnel. Pour cette étude, ce sont 232 décideurs en informatique qui ont été interrogés dont 50% font partie d une entreprise de plus de 500 salariés et 20% de plus de salariés. Il en ressort que les domaines d utilisation sont variés : Gestion de contenu (50% des sondés) Base de données et administration système (46% des sondés) 23 Zend : contraction de ZEev et ANDi 24 POO : Programmation Orientée Objet 25 PEAR : PHP Extension and Application Repository (extensions développées en PHP) 26 PECL : PHP Extension Community Library (extensions développées en C/C++) 30

31 Visualisation de données (33% des sondés) Applications financières (28% des sondés) E-Commerce (25% des sondés) Ressources humaines (20% des sondés) Il en ressort également les différents avantages de PHP face à d autres technologies : Cycle de développement plus rapide (88% des sondés) Plus apte pour le développement WEB (81% des sondés) Temps d apprentissage plus rapide (79% des sondés) Plus simple à administrer (76% des sondés) Du point de vue des développeurs, PHP est très facile à prendre en main de par sa simplicité et sa permissivité. Ce sont deux choses appréciées mais qui amènent bien souvent à un manque de rigueur. Il est très facile de réaliser une petite application sans pour autant avoir respecté de bonnes pratiques. Les développeurs débutants sont ainsi très vite opérationnels et se reposent bien souvent sur cette facilité. Mais ce qui est valable pour une petite application ne l est pas pour une application de taille plus importante. Car si l on ne s impose pas un minimum de règles et de conventions, cela entraine des complications telles que : des difficultés de travail en équipe, des problèmes de maintenabilité, une complexité croissante du code, Du point de vue des DSI 27, les applications PHP peuvent également poser problème : Applications hétérogènes : architecture, conventions, Qualité de code variable : documentation, performances, sécurité, Pas de procédures unifiées : déploiement, tests, Manque d indicateurs : qualité, performance, maintenabilité, L écosystème de PHP apporte de nombreuses solutions quant à la résolution de ces problèmes. Il s agit de solution permettant l industrialisation des développements. Qu est-ce que le développement industrialisé d applications? Considérons qu il s agit d un ensemble de pratiques et d outils dont l objectif est la production de d applications robustes (performance et sécurité) et maintenables (qualité) dans des délais et coûts maitrisés (rentabilité). Tout au long de ce mémoire nous détaillerons les différents moyens qui mènent à cet objectif : S assurer des compétences des équipes (formation, veille, ) Mettre en place des environnements de travail productifs (outils, serveurs, ) S assurer de la rentabilité du projet (gestion de projet) Réutiliser des outils qui ont fait leurs preuves (frameworks, librairies, ) Suivre des bonnes pratiques (conventions, patrons de conception, ) S assurer de la qualité de l application (intégration continue, analyse du code, ) Automatiser les tâches récurrentes (déploiement, tests, ) Nous tâcherons de savoir si PHP répond aux problématiques de développement industrialisé d applications. 27 DSI : Direction des Systèmes d Information 31

32 FORMATION DES EQUIPES PHP est facile à prendre main et donne souvent la sensation aux développeurs débutants la maitrise du langage. Lors du développement d une application, ils auront à faire des choix conséquents et leur manque d expérience posera problème. Ceci peut être un véritable danger : mauvaise architecture de l application, performances médiocres, failles de sécurité, Pour mener à bien un projet, il faut avant tout s assurer d avoir un bon niveau de compétences techniques et méthodologiques au sein de l entreprise. FORMATION PROFESSIONNELLE Une formation professionnelle en PHP est un véritable investissement. Deux solutions sont possibles : Payer un organisme de formation pour effectuer des sessions auprès des collaborateurs Désigner un développeur suffisamment compétant en tant que formateur Généralement, une formation dure moins d une semaine et alterne entre cours magistraux et mise en pratique. Il est important que ces deux points soient bien respectés pour éviter la volatilité des nouvelles compétences acquises. Il faut ensuite assurer un suivi pour évaluer l impact de la formation auprès des développeurs et en programmer une nouvelle si des points importants ont mal été intégrés. Il ne faut pas croire qu une formation suffira pour transformer des débutants en expert. Il faut plutôt considérer une formation comme un premier pas pour permettre aux développeurs de partir sur de bonnes bases pour les prochains développements. VEILLE TECHNOLOGIQUE La veille technologie est essentielle dans le monde informatique qui est en constante évolution. De manière générale, elle consiste à observer et analyser son environnement pour en déduire les potentielles menaces et opportunités. De manière plus concrète, elle permet d anticiper face aux futures évolutions technologiques (identification d outils et de pratiques émergentes). Elle permet également de d augmenter la qualité des produits et de diminuer les coûts de production (repérage de bonnes pratiques, recueillement de retours d expérience, ). Il ne s agit pas de se tenir simplement au courant. La veille est un véritable outil stratégique d aide à la prise de décision. Est-ce que cette technologie est suffisamment viable pour une application d une durée de vie de 10 ans? Est-ce que cette pratique sera facilement acceptée par nos équipes? Pour ce qui est des moyens, certaines entreprises sont spécialisées dans la veille et offrent un panel de services intéressants tels que la mise à disposition d un tableau de bord, l évaluation d impact d une nouvelle technologie, l analyse de futurs concurrents potentiels, Cette solution peut paraitre séduisante mais n est pas à conseiller dans la pratique car il faut impliquer les acteurs dans la veille technologique. Pour cela, deux solutions sont possibles. Soit chacun effectue sa propre veille. Soit une personne est désignée pour effectuer la veille. Cette personne fera profiter au reste de l équipe des informations récoltées qu elle considère comme importantes. Une autre personne est ensuite désignée. Qu importe la solution choisie, l un des points importants est le partage des informations récoltées. L information doit circuler auprès des différents collaborateurs. 32

33 D un point de vue méthodologique, il faut définir le périmètre de la veille, identifier les sources de données, mettre en place le dispositif de surveillance, traiter les informations récoltées et partager les informations jugées pertinentes. Définir le périmètre de la veille permet de définir les thématiques à observer. L objectif est d identifier les mots clés qui nous permettront de trouver les sources de données à utiliser. Exemples de mots clés : gestion de projet, développement PHP, développement JavaScript, ergonomie WEB, L utilisation d un outil de cartographie euristique peut s avérer très utile pour bien définir le périmètre de la veille. Il en existe des gratuits (FreeMind, XMind, ) et des payants (imindmap, MindManager, ). Il existe également des versions en ligne (Bubble.us, MindMeister, ). Les sources de données sont variées. La source principale est le WEB au travers de sites spécialisés, de blogs de professionnels, de liste de diffusions,... D autres sources sont également disponibles : livres, magasines, articles, rapports, Il est aussi envisageable d assister à des conférences données mais celle-ci sont généralement données lors d évènements dont l entrée est payante. Exemples d évènements : Forum PHP, LeWeb, Paris Web, Les dispositifs de surveillances sont également variés. On retrouve principalement des agrégateurs de flux RSS en ligne (Google Reader, Netvibes, ) et hors-ligne (FeedReader, RSS Owl, ). Il existe également des outils partage de liens (Twitter, Digg, Delicious, ). Ces derniers sont très intéressants dans la mesure où il suffit de s abonner aux personnes (ou listes de personnes) qui ont les mêmes intérêts que nous pour que l information vienne à nous déjà filtrée et ce qui se traduit par un gain de temps considérable. Quant au traitement et au partage des informations récoltées, il est possible de mettre en place un blog qui présente de nombreux avantages telles que la catégorisation, la centralisation, la diffusion et la capitalisation de l information. Exemples de blogs : Wordpress, DotClear, Pour finir, le travail de veille technologie doit initier des actions concrètes. Il faut expérimenter les outils et les pratiques pour juger de leur pertinence en pratique, valider leur bonne intégration au sein de l environnement existant et les adopter si les précédentes étapes sont concluantes. CAPITALISATION DES COMPETENCES Maintenant que nos équipes ont acquis suffisamment de connaissances et se tiennent au courant des évolutions technologique de leur secteur d activités, il faut s assurer de garder ce capital de connaissances au sein de l entreprise. La capitalisation des connaissances dans le monde informatique est un point important à ne pas négliger. La connaissance est ce qui fait la valeur d une équipe et d une entreprise. Elle se gagne (lors de formations, d embauches, ) et se perd (lors de départs, d inactivités, ). La connaissance peut se qualifier de manière horizontale et verticale. Dans le premier cas, cela détermine la variété de problèmes qu il est possible de solutionner. Dans deuxième cas, cela détermine la qualité de la solution. S assurer d un bon niveau de compétences (horizontal et vertical) est important pour conserver une bonne force de proposition, de décision et de production. Ce capital de connaissances est constitué d hommes et d informations. Pour ce qui est des hommes, il faut s assurer de conserver et/ou d embaucher des collaborateurs compétents. Il ne faut pas perdre de vue qu il 33

34 s agit de la principal source de connaissances. Quant aux informations, il faut mettre en place des outils d indexation rendant l information suffisamment accessible pour permettre une diffusion efficace. Pour cela, il faut privilégier une approche centralisée pour éviter la dispersion de l information. Il faut également s assurer de bien catégoriser l information. Attention cependant, il ne suffit pas simplement d accumuler de l information sans penser au besoin. L adéquation entre le besoin en information et l information cumulée définit une capitalisation efficace. Plusieurs outils sont disponibles pour indexer l information : Blogs (Wordpress, DotClear, ) Wikis (MediaWiki, DokuWiki, ) Répertoires partagés (FTP, Samba, ) Pour ce qui est de l alimentation en données de ces outils, on peut se baser sur des éléments de formation des équipes (supports, guides, ) et de veille technologique (articles, rapports, ) vus précédemment. ENVIRONNEMENT DE TRAVAIL POSTE DU DEVELOPPEUR Le poste du développeur est son outil de travail au quotidien. La souplesse de PHP est une nouvelle fois source de problèmes. Une application peut très bien être réalisée à l aide d un simple éditeur. Mais il en faut bien plus pour être véritablement efficace. Le développeur est comme le mécanicien, la qualité de ses outils est un élément déterminant dans la qualité de son travail. SYSTEME D EXPLOITATION De manière générale, il n y a pas de meilleure solution pour le choix du système d exploitation. Windows, Linux et Mac OS X conviennent très bien. Cependant, il faut considérer le fait que la majorité des applications PHP fonctionnent sur un serveur Linux. Ainsi, il préférable d utiliser un environnement Linux pour garder de la cohérence entre les environnements de développement, de recette et de production. De plus, l environnement Linux est plus propice au développement de scripts d automatisation de tâches récurrentes via l écriture de scripts shell 28. L interpréteur linux proposant des fonctionnalités plus avancées et intuitives. Ajouté à cela, la boite à outils du développeur est plus garnie sur un environnement Linux (indisponibilité de certains outils sous Windows). Cependant, l utilisation de l environnement Linux restreint les possibilités de test des applications au travers d Internet Explorer dont la compatibilité reste encore très demandée par les clients. La majorité des postes en entreprises fonctionne avec l environnement Windows (XP ou 7) et les politiques des DSI n autorisent généralement pas l installation d autres systèmes d exploitation. Une solution pour remédier à ce problème est possible : l utilisation d une machine virtuelle (VirtualBox, VMware, Parallels Desktop, ). A noter qu il est possible que l installation d une machine virtuelle soit également interdite. L utilisation d une machine virtuelle apporte de nombreux avantages : 28 Shell : interface utilisateur du système d exploitation 34

35 Possibilité d installation du système d exploitation de son choix Le système hôte n est pas impacté par les modifications sur le système invité Possibilité d effectuer des sauvegardes de l état du système invité La machine virtuelle encapsule l environnement de développement Le dernier point est très important car il permet de gagner un temps considérable sur l installation de l environnement de développement. Dès qu un nouveau développeur intègre un projet, il lui suffit de récupérer la machine virtuelle pour être opérationnel. Cependant, gérer un ensemble de machines virtuelles peut rapidement devenir complexe. Il existe deux solutions pour cela : utiliser un ou plusieurs répertoires partagés (Samba, FTP, ) pour stocker l ensemble des machines virtuelles pour chaque projet ou utilisateur un serveur de machines virtuelles (VMware Server, Hyper-V, ). Cette deuxième solution est préférable mais requiert un investissement plus conséquent. Il est à noter que l utilisation de machines virtuelles pénalisera les développeurs en termes de performances car il s agit de faire fonctionner deux systèmes sur une machine physique. Il faut donc bien mesurer les avantages et les inconvénients d une telle démarche. NAVIGATEURS WEB Lorsque l on développe une application WEB, on développe pour un ensemble de navigateurs WEB accompagnés de leurs spécificités. On peut aller plus loin en considérant les systèmes d exploitation sur lesquels fonctionnent les navigateurs WEB. C est le cahier des charges qui doit stipuler la compatibilité attendue (noms et versions). Il est donc nécessaire de se prémunir des navigateurs WEB cibles pour tester leur compatibilité avec l application développée. De nombreux outils existent pour tester une application sur différents navigateurs parmi lesquels : Adobe Browser Lab : payant, en ligne, captures d écran IETester (uniquement pour IE 29 ) : gratuit, hors ligne, navigateurs simulés Microsoft SuperPreview (uniquement pour IE) : payant, hors ligne, navigateurs simulés Spoon Browser Sandbox : payant, en ligne, navigateurs simulés Browsershots : gratuit, en ligne, captures d écran CrossBrowserTesting : payant, en ligne, captures d écran et navigateurs simulés Une autre option consiste à utiliser des machines virtuelles dédiées à ces tests de compatibilité. ENVIRONNEMENT DE DEVELOPPEMENT INTEGRE Un environnement de développement intégré, ou IDE 30, est un outil qui améliore grandement la productivité du développeur. Il s agit de l extension d un simple éditeur de texte via l ajout de fonctionnalités telles que la colorisation syntaxique, l auto-complétion, l analyseur syntaxique, l indentation automatique, l intégration 29 IE : Internet Explorer 30 IDE : Integrated Development Environment 35

36 avec les VCS 31, l intégration avec un débuggeur, l intégration avec un profileur, la recherche de code avancée, le formatage automatique des sources, Cette liste ne s arrête pas là car la grande force des IDE est leur modularité. Il est facile d éteindre les fonctionnalités fournies de base à l aide d extensions (gratuites ou payantes). Il faut considérer l IDE comme un outil qui fait partie de la chaine de production. Il est conseillé de définir un IDE de référence qui sera utilisé par tous les développeurs de l entreprise. L objectif est de standardiser l environnement de développement et donc de fixer les outils qui le composent. Les principaux IDE sont : Eclipse PDT (gratuit) NetBeans (gratuit) Zend Studio (payant) Aptana Studio (gratuit) Komodo IDE (payant) Cependant, il faut bien comprendre qu il s agit d un outil relativement lourd à utiliser qui ne convient pas à tous les usages. Il convient donc de toujours garder sous la main un éditeur plus léger pour des travaux ponctuels (administration système, ). OUTILLAGE Tout comme le mécanicien, le développeur possède sa propre caisse à outils. Chacun de ces outils répond à un besoin particulier. L outil de base étant un serveur WEB constitué de : un serveur HTTP (Apache, NGINX, LIGHTTPD, ), l interpréteur PHP et un SGBD 32 (PostgreSQL, SQLite, MySQL, ). Il est à noter que PHP peut être utilisé en dehors d un serveur WEB (il ne s agit que d un interpréteur) et qu il possible que certains projets utilisent le langage PHP comme tel. Pour faciliter la mise en place d un serveur WEB, il existe des solutions qui installent toute la pile d outils nécessaires. En voici une liste : WAMP : Windows, Apache, MySQL, PHP MAMP : Macintosh, Apache, MySQL, PHP SAMP : Solari, Apache, MySQL, PHP LAMP : Linux, Apache, MySQL, PHP LAPP : Linux, Apache, PostgreSQL, PHP Il est également utile d utiliser un outil de visualisation et d édition du contenu et de la structure des bases de données. Certains sont accessibles via un client WEB (PHPMyAdmin, PHPPgAdmin, SQLiteManager, ) et d autres via un client lourd (MySQL Workbench, SQL Developer, pgadmin, ). D autres outils bien pratiques sont généralement déjà intégrés au sein des navigateurs modernes ou disponibles via l installation d extensions. Parmi ces outils nous retrouvons la console d erreurs JavaScript, l analyseur de requêtes HTTP, l examinateur HTML, le navigateur DOM, le débuggeur JavaScript, 31 VCS : Version Control Systems, ou Systèmes de Gestion de Versions 32 SGBD : Système de Gestion de Base de Données 36

37 SYSTEMES MUTUALISES SYSTEMES DE GESTION DE VERSIONS Comme dans tout projet de développement en informatique, le travail en équipe signifie la mise en commun du code source auprès des différents intervenants. Chacun pouvoir y accéder pour le modifier et l exécuter en vue d apporter de nouvelles fonctionnalités, corriger des bogues, combler des failles ou bien améliorer la qualité de celui-ci. Une première approche serait la mise à disposition du code source au travers d un répertoire partagé sur le réseau (Samba, FTP, ). Cette solution règle notre problème initial mais en apporte un nouveau qui est le risque de conflit lors de l édition d un même fichier. Ce problème peut être toutefois résolu manuelle lorsqu il s agit d une petite application. Mais cela devient vite humainement impossible à gérer pour une application de plus grande envergure avec un nombre de fichiers et de collaborateurs plus important. Cette solution est donc inenvisageable. Il existe pour cela les systèmes de gestion de versions dont l objectif est de régler nos problèmes tout en apportant des fonctionnalités supplémentaires très utiles. De manière générale, ils permettent : La mise à disposition partagée du code source La conservation de l historique du code source La résolution de conflits d édition (automatique ou assistée) La possibilité de figer une version à un instant donné La création de branches de développement On distingue deux types de systèmes de gestion de versions : les dépôts centralisés (SVN 33, CVS, ) et les dépôts décentralisés (Git, Mercurial, Bazaar, ). La différence entre ces deux types tient principalement au dépôt de référence. Pour le système de dépôts centralisés, il n y a qu un seul dépôt qui fait référence. Quant au système de dépôts décentralisés, il n y a pas de dépôt de référence à proprement parler car chaque développeur possède son propre dépôt qu il peut synchroniser (UPDATE et/ou COMMIT) avec un autre dépôt s il le souhaite. Ci-dessous un schéma explicatif : Figure 23 - Différences entre un système de dépôts décentralisés (à gauche) et centralisés (à droite) 33 SVN : SubVersioN 37

38 APPLICATION DE GESTION DE PROJET La simplicité de PHP donne parfois l impression d une certaine maitrise des développements et laisse croire aux développeurs qu ils n ont pas besoin de mettre en place un outil de gestion de projet. Ils pensent que l utilisation d un tableur (Excel, Calc, ) suffit à leurs besoins. Mais il s agit d une pratique qui comporte de nombreux problèmes : inaccessibilité de la part des autres intervenants, planification manuelle des tâches, risques de complexification du document du fil du temps, Des outils de gestion de projets existent et permettent de régler ces différents problèmes. Ils s avèrent très utiles pour s assurer d un travail d équipe efficace dans des délais et des coûts maitrisés. Ces outils encapsulent généralement un ensemble de fonctionnalités intéressantes telles que la planification de tâches, la prise en charge de de tickets, l affectation de ressources, le stockage de fichiers, l intégration d un système de gestion de versions, l édition collaborative de documentation, la gestion de sous-projets, l intégration d une méthode de développement Les principaux outils de gestion de projet sont : Redmine (gratuit) : à héberger soi-même JIRA (payant) : à héberger soi-même Microsoft Project (payant) : hors-ligne TeamLab (payant) : en solution SAAS 34 Basecamp (payant) : en solution SAAS Freedcamp (gratuit) : en solution SAAS Il existe également des outils intermédiaires qui ne couvrent que certains aspects. Il s agit d outils d appoint pour une utilisation ponctuelle. Il reste préférable d utiliser une solution plus complète. En voici une liste : Yodiz (gratuit/payant) : gestion de tâches au travers de la méthode SCRUM Asana (gratuit/payant) : liste de tâche collaborative en temps réel Gantter (gratuit) : planification de tâches sous la forme d un Gantt TeamBox (payant) : liste de tâche collaborative et partage de fichiers Trello (gratuit) : organisation de tâches à la manière d un Kanban SERVEURS DE DEVELOPPEMENT, RECETTE ET PRODUCTION Le manque de rigueur, de moyen et/ou de temps peut parfois conduire à ne pas mettre en place un serveur de recette. L application développée passe ainsi directement du serveur de développement au serveur de production. Bien souvent, les caractéristiques (système d exploitation, valeurs de configuration, composants installés, ) de ces derniers sont suffisamment différentes pour avoir des comportements inattendus lors du déploiement en production. Le problème peut-être bien plus conséquent : ces différences de comportement peuvent être détectées bien plus tard entrainant corruptions de données, fonctionnalités indisponibles, Ainsi, utiliser un environnement de recette est avant tout une sécurité supplémentaire avant la mise en production. 34 SAAS : Software As A Service 38

39 De plus, installer un environnement de recette, c est préparer la futur installation de l environnement de production (outils à installer, configurations à appliquer, scripts à lancer) dans la mesure où ces deux environnements se doivent d être identiques. On peut notamment en profiter pour rédiger le manuel d installation de l environnement de production. Ajouté à cela, effectuer des déploiements réguliers sur l environnement de recette permet de mieux appréhender le déploiement en production. Figure 24 - Serveurs de développement, de recette et de production Pour finir, le serveur de recette est avant tout destiné à des tests de recette. Ainsi, mettre en place une telle plateforme permet au client de valider les différentes fonctionnalités de l application. Cette dernière notion est importante car il en résulte une certaine implication du client dans le processus de développement. Cela permet de détecter les erreurs d interprétation des besoins du client au plus tôt. ANALYSE ET DEVELOPPEMENT REUTILISATION Le langage PHP propose de base un nombre important de fonctionnalités qui permettent de répondre à des problématiques techniques variées lors du développement d une application WEB : accès à une base de données, affichage de pages HTML,... Les développeurs peuvent ainsi être amenés à ne pas chercher de solutions à leurs problèmes au-delà de ces fonctionnalités car elles s avèrent suffisamment complètes pour répondre à leurs besoins. Pourtant la réutilisation d outils (frameworks et librairies) apporte de nombreux avantages : standardisation, qualité, performance et sécurité. FRAMEWORKS Le langage PHP n impose aucune règle stricte de développement. Il est tout à fait possible de mélanger du code HTML, des requêtes SQL et divers traitements au sein d un même fichier PHP. Procéder ainsi rend difficile la maintenance, les évolutions, De plus, une entreprise qui souhaite s assurer de la sécurité de son parc applicatif aura de grandes difficultés à évaluer les applications développées de la sorte. Pour régler ces problèmes, les développeurs peuvent utiliser un framework. Il s agit d une boite à outils de composants servant de base technique aux projets. Ils répondent principalement à deux besoins : des fonctionnalités de haut niveau ainsi que des méthodologies standardisées et éprouvées. D une part, cela permet de se reposer sur des librairies éprouvées pour les tâches récurrentes et porter ses efforts de développement sur ce qui porte la valeur métier. D autre part, cela contraint les développeurs à respecter des règles de développement ce qui améliore le travail en équipe et la qualité du code. Les principaux frameworks PHP sont : 39

40 Zend Framework Symfony CakePHP Plusieurs critères sont déterminants lors du choix d un framework : sa maturité, la qualité de sa documentation, l importance de sa communauté, sa facilité de prise en main, Le choix d un framework n est pas sans conséquences car il s agit de définir le squelette de l application et il sera difficile de faire machine arrière. Cependant, il ne faut pas perdre de vue que la complexité de ces outils peut être un frein. Il faut avant tout s assurer de leur acceptation au sein des équipes de développement et procéder à des formations cinécessaire. Il ne suffit pas d imposer un framework pour que celui-ci soit utilisé, il faudra bien souvent mettre en place un accompagnement. Plutôt que de choisir un framework existant, une autre approche consiste à développer son propre framework. Les principaux avantages sont la maitrise de son fonctionnement et la possibilité de définir ses propres règles et conventions. Grâce à la simplicité de PHP, le choix d une telle démarche est abordable et le retour sur investissement sera rapide. Dans la mesure où s agit de développer la base technique des futurs projets, il faudra bien s assurer de la qualité, de la sécurité et des performances de celui-ci. Pour ce qui est fonctionnement, il possible de s inspirer des frameworks existants et partir ainsi sur de bonnes bases. LIBRAIRIES Le langage PHP est fort d une communauté importante. Cela se traduit notamment par un nombre conséquent de librairies aux usages variés (génération de graphiques, génération de fichiers PDF, ). Dès que le cahier des charges est établit, il convient donc de rechercher des librairies qui pourraient correspondre aux besoins de l application. Moins les développeurs auront à développer et moins l application sera susceptible de contenir des bogues. Il faudra cependant bien faire attention à la qualité et la pérennité de celles-ci. SNIPPETS Un snippet désigne une partie de code réutilisable qui répond à une problématique. Généralement, plus un développeur progresse dans son secteur s activité et plus il s entoure de ces portions réutilisables de code. Dans un premier temps, il est intéressant d utiliser des outils permettant de l organiser et d annoter ses propres snippets pour une recherche ultérieure plus rapide. Dans un deuxième temps, on peut étendre cette démarche et utiliser des outils permettant le partage de ces snippets au sein d un groupe (pourquoi pas au sein de toute l entreprise?). Voici une liste d outils pour répondre à ce besoin : SnippetManager (gratuit) Code Bank (gratuit) jcodecollector (gratuit) Code Warehouse (payant), 40

41 BONNES PRATIQUES CONVENTIONS DE CODAGE Le langage PHP est très flexible et chaque développeur peut appliquer ses propres habitudes. D une part, le code n est pas homogène. D autre part, la lisibilité n est pas forcement au rendez-vous car ce qui peut sembler lisible pour un développeur ne l est pas toujours pour les autres. Il faut donc fixer des conventions d écriture de code source qui standardisent l écriture de code et améliorent ainsi la lisibilité. Celles-ci définissent la manière dont doivent s écrire le nom des variables, les structures de contrôle, le nom des classes, le nom des méthodes, Il est possible de choisir une convention existante. Il est également possible de créer sa propre convention pour un peu plus de souplesse. Dans les deux cas, il faut s y tenir. Ci-dessous une liste des principales conventions pour PHP : PEAR coding standard PHP coding standard Zend Framework coding standard Il ne suffit pas de choisir une convention. Pour qu elle soit adoptée par les développeurs, il faut le notifier en début de projet mais également s assurer qu elle ne tombe pas dans l oubli. Pour ce dernier point, il est bon de le rappeler dans les sources du projet via un fichier «Lisez-moi» (ou «Read me»). Ce fichier est d ailleurs un endroit propice où placer toutes les informatiques relatives aux pratiques de développement. OPTIMISATIONS Le langage PHP propose un très grand nombre de fonctions. Nombre d entre elles permettent d effectuer les mêmes tâches. Les développeurs n y prêtent pas forcement attention et optent ainsi pour les fonctions avec lesquelles ils ont l habitude de développer. Sans s étaler sur le côté technique de la chose, il est bon de savoir que toutes n ont pas les mêmes performances. De même que certaines pratiques sont à prohiber. Les temps gagnés peuvent paraître faibles (de l ordre de quelques ms) mais la plateforme cible est un serveur WEB qui sera potentiellement utilisé par des centaines, des milliers, d utilisateurs. Chaque optimisation qui pourrait réduire le temps de traitement est à considérer. Il est donc conseillé de se renseigner sur ces différentes possibilités d optimisation et de les appliquer lorsque c est possible. CONVENTIONS D ARCHITECTURE Le langage PHP est très souple et chaque développeur peut adopter sa propre architecture. Avec l adoption d un framework, nous avons vu que cette souplesse est réduite avec l introduction de règles de développement. Malgré cela, les développeurs ont encore la possibilité de partir sur de mauvaises bases. Il est donc conseillé de fixer une (ou plusieurs) convention d architecture qui sera adopté pour les futurs projets. Celle-ci doit, en prenant en compte les spécificités du framework utilisé, définir pour la majorité des problématiques (séparation en couches, communication entre les couches, communication avec des services WEB, ) une solution. Cette standardisation d architecture permet non seulement un démarrage plus rapide des projets mais également un temps de prise en main des applications moins long lors de la maintenance. La convention utilisée peut faire l objet d une note au sein du fichier «Lisez-moi» (ou «Read me») du projet. 41

42 PATRONS DE CONCEPTION Le langage PHP mélange la programmation procédurale et la programmation objet. Cette dernière est à préférer pour sa facilité d intégration au sein du processus de développement (méthodes et outils de conception, relations avec la base de données, ) et pour ses principes d encapsulation, délégation,... Pour soutenir la POO, il existe les patrons de conception. Il s agit de solutions éprouvées à des problèmes récurrents. Il en existe des prêts à l emploi (fabrique, adaptateur, décorateur, ) mais il est possible d en créer. Pour définir un patron de conception, il faut préciser : le nom, le problème, la solution et les conséquences. Il est envisageable de créer un répertoire de partons de conception relatif à un projet, une équipe ou encore à l entreprise. Cette démarche permet d apporter une nouvelle fois de la standardisation aux développements. MODELISATION Bien souvent, développer en PHP et modéliser sont deux choses que les développeurs ont du mal à associer pour la simple raison que PHP n a pas été créé dans cette optique. Comparativement, Java et C# ont avancé des concepts compatible avec la modélisation dès le début : la POO par exemple. PHP quant à lui est passé du statut de langage de script à celui de langage de développement. Avec l arrivée de la POO, il devient possible de modéliser des applications PHP au même titre que des applications Java et C#. Pour de gros projets, une telle démarche est essentielle pour garder la maitrise technique et fonctionnelle. Pour cela, il existe notamment UML qui propose des diagrammes que l on peut utiliser dans le cadre d un projet PHP : diagrammes de séquence et d activité (pour la navigation), diagramme de composants (pour l architecture), diagramme de déploiement (pour l infrastructure), diagramme de classes (pour le modèle de données), Pour ce qui est des outils UML, il en existe qui fonctionnent seuls (Entreprise Architect, Modelio, ) et d autres qui sont intégré au sein d un IDE (Eclipse Model Development Tools, NetBeans IDE UML). Notons qu il est possible de retourner le problème. C est-à-dire générer les diagrammes UML à partir du code source. Certains outils permettent une telle démarche avec PHP (ArgoUML, BOUML, ). L intérêt est de ne pas perdre de temps avec l élaboration de schémas UML tout en gardant la possibilité de s y référer en les générant. Cette méthode est à utiliser avec précaution car la phase de conception, qui permet de prendre du recul (fonctionnel, architectural, ) avant la phase de développement, est ainsi mise en côté. DOCUMENTATION Certaines applications PHP accusent de problèmes de maintenabilité car très peu (ou pas) de documentation sur leur fonctionnement est disponible. C est souvent par manque de rigueur, de moyen et/ou de temps que la rédaction de documentation est mise de côté. Pourtant, elle est essentielle. De la documentation peut être rédigée sur plusieurs niveaux : documentation pour les développeurs, documentation pour l installation, documentation pour la production et documentation pour les utilisateurs. C est la documentation pour les développeurs qui présente des risques de négligence. Celle-ci comprend des éléments fonctionnels, conceptuels et techniques. Les autres documentations sont généralement bien traitées car requises par le client au niveau du contrat (dans le cadre d une sous-traitance). Plusieurs approches sont possibles. Tout d abord, il important de commenter correctement son code. Il ne faut pas perdre de vue que le code est la base d une application et qu il doit pouvoir être lu comme un livre 42

43 de manière à faciliter le travail en équipe ainsi que les opérations de maintenance. Il existe différents standards de commentaires : PHPDoc, Zend Framework, PEAR, Symfony, Doxygen, Les avantages d utiliser ces standards sont l homogénéité des commentaires, la possibilité de générer un fichier de documentation en se basant sur les annotations et la prise en charge des annotations par certains IDEs (inférence sur le type d un paramètre d entrée/sortie par exemple). Il existe principalement deux outils pour générer de la documentation sous différents formats (HTML, PDF, ) : PHPDocumentor et Doxygen. Une autre approche consiste à s inspirer du monde de l open-source via la mise en place un système de wiki 35. Ses avantages sont de proposer une documentation centralisée (pas de problèmes de versions) en lecteur et édition. Ses inconvénients sont la nécessité de mettre en place un environnement wiki (MediaWiki, KmWiki, ) et la difficulté à réunir toute la documentation au sein d un même document (en vue de l imprimer par exemple). Une dernière approche consiste à rédiger un document. La première solution est la création d un (ou plusieurs) fichier de type Word (Microsoft Office) ou Writer (LibreOffice/OpenOffice). Mais il existe d autres possibilités telles que DocBook (reposant sur la technologie XSLT 36 ) et AsciiDoc. Ces deux derniers ont l avantage d être au format texte (donc une possible intégration avec un système de gestion de versions) tout en offrant la possibilité de générer de la documentation sous différents formats (HTML, PDF, ). Quelques que soient les approches adoptées, il est conseillé de rédiger un document à part qui permet une brève introduction à destination des futurs développeurs pour qu ils être rapidement opérationnels. GENERATION DE CODE La génération de code permet de gagner un temps considérable et de produire du code standardisée. Avec PHP, il est possible de générer du code sur plusieurs niveaux. Il est possible de générer des classes PHP avec des outils de modélisation UML prenant en charge cette fonctionnalité (ArgoUML, BOUML, ). Cette approche permet une suite logique entre la conception et le développement tout en facilitant l initialisation d un projet. Cependant, il faut savoir qu il est difficile de faire des allers et retours entre la conception et le code. A l image d autres langages tels que Java avec Hibernate, PHP dispose d implémentations du concept d ORM 37. Il s agit d une technique qui fait correspondre le contenu d une base de données à un ensemble d objets. L objectif est de créer une couche d accès aux données et se s abstraire de ces problématiques dans les couches supérieures (métier, ). Différentes solutions existent pour PHP et certaines d entre elles permettent la génération, à l aide d un fichier de configuration XML (possibilité d aspirer la structure d une base de données), d une couche d accès aux données. Les principaux ORMs PHP sont Doctrine et Propel. Des solutions plus abordables sont également disponibles (WebProjectHelper, ). Il est possible de créer ses propres outils de génération si ceux déjà existant ne répondent pas à besoin identifié ou bien si la maitrise du fonctionnement de ces outils est important. Notons qu il est tout à fait possible d utiliser PHP pour générer du PHP. Il est envisageable de mettre à disposition ces outils auprès des 35 Wiki : site WEB dont les pages sont éditables de manière collaborative 36 XSLT : extensible Stylesheet Language Transformations 37 ORM : Object Relational Mapping, ou Mapping Objet-Relationnel 43

44 autres collaborateurs de l équipe et/ou de l entreprise. Un répertoire partagé de tels outils favorise grandement la réutilisation. Les frameworks PHP sont généralement accompagnés d outils permettant la création de différents composants (contrôleurs, modules, ) et de construire ainsi la structure d une application très rapidement. Ces outils de génération de code sont bien pratiques. Cependant, il y a un risque de dépendance. Si le projet vient à prendre des orientations incompatibles avec ceux-ci, il faut pouvoir s en séparer facilement au risque de devoir reprendre entièrement la partie de l application concernée. Il est donc conseillé d éviter les outils trop engageant ou bien s assurer que leur utilisation ne soit pas remise en cause. Cette évaluation n est pas aisée car il s agit de se projeter dans l avenir pour évaluer la viabilité d un outil. TESTS ET DEPLOIEMENT QUALITE Malgré ses qualités, l image d un langage de script pour curriculum vitae et pour livre d or est longtemps restée collé à PHP. Notre objectif est ici de montrer qu il est tout à fait possible d associer PHP à de la qualité. TESTS DE L APPLICATION Une application PHP est bien souvent tester manuellement directement via son interface. Cette pratique est à éviter pour de multiples raisons : non-exhaustivité des tests, périmètre restreint au fonctionnel, intervention humaine et contraignante obligatoire,... Pourtant l écosystème de PHP s est doté d outils permettant la mise en place de tests automatisés (créations ou empreints d outils à d autres langages). Il en existe de plusieurs types : Unitaires : PHPUnit, SimpleTest, Atoum, PHPSpec, IHM : Selenium, Tellurium, Watir, Sikuli, Fonctionnels : Behat, GreenPepper, Fitnesse, Montée en charge : JMeter, The Grinder, Siege, Notons qu il est possible d intégration PHPUnit à l IDE Eclipse via le plugin PTI 38. Cette intégration permet aux développeurs de lancer très facilement des tests unitaires de la manière qu avec JUnit pour Java. Au-delà de leur objectif de base qui est de valider le bon comportement d une fonctionnalité, ces tests permettent d évaluer l avancement d un projet (développement dirigé par les tests) et de vérifier la nonrégression lors de modifications. Ceux-ci doivent être lancés aussi souvent que possible pour révéler tout leur intérêt. Le lancement de ces tests doit éviter la nécessité d une intervention humaine. ANALYSE DU CODE La syntaxe de PHP est très souple. Il existe des conventions de codage qui permettent de standardiser le formalisme à adopter lors de l écriture du code source. L écosystème de PHP propose un ensemble d outils 38 PTI : PHP Tool Integration 44

45 qui permettent non seulement de vérifier le respect de la convention de codage choisie mais également de recueillir des métriques et de détecter des problèmes. Pour vérifier le respect de la convention adoptée, il existe PHP Code Sniffer qui passe en revue : documentation, indentation, nom des variables, nom des classes, Celui-ci propose la validation de standards existants (PEAR, Zend Framework, ) mais il est également possible de définir son propre standard à valider. Après exécution, l outil remontra tous les problèmes détecté sous forme textuelle. Notons qu il est possible de l intégré à Eclipse via PTI. Cette intégration permet aux développeurs de lancer très facilement des vérifications de la même manière qu avec Checkstyle et PMD pour Java. De plus, il est possible de détecter les redondances de code avec PHP Copy/Paste Detector. Le nombre de lignes dupliquées est un bon indicateur de qualité code qui doit s approche de 0. Il est également possible d évaluer la complexité du code avec PHP Depend qui se base sur le nombre de structures de contrôle, le nombre de lignes de code, le nombre de méthodes, Cet outil permet notamment d obtenir la complexité cyclomatique 39. Ajouté à cela, il est possible de repérer les problèmes dans le code source avec PHP Mess Detector : code mort, variable inutilisées, code trop complexe, Pour finir, il est possible de détecter des failles avec RATS et Nikto. Notons qu il est possible de regrouper les informations récoltées par certains des précédents outils (PHP Unit et PHP Depend) au sein d une seule et même interface grâce à Sonar. Ceci dit, cet outil ne remplace par un serveur d intégration continue. INTEGRATION CONTINUE L intégration continue consiste à vérifier automatiquement que chaque modification du code source ne provoque pas de régression. Au-delà de cette définition quelque peu encyclopédique, cela permet de suivre efficacement l avancement d un projet, de détecter les erreurs au plus tôt et de présenter des bilans chiffrés. Il s agit d un véritable tableau de bord doté d un ensemble de graphiques (nombre de tests réussis, nombre de violations de convention de codage, ). L intégration continue s intègre particulièrement bien dans un développement incrémental. Dans la mesure où ce qui définit l avancement du projet est la validation de tests prédéfinis, les développeurs sont incités à procéder par ajout de fonctionnalités successives en vue de valider progressivement ces tests. L intégration continue est donc un bon support pour les méthodes de développement agiles. D un point de vue technique, il faut que le code source soit accessible via un système de gestion de versions et que des tests puissent être déclenchés. Il est possible pour cela d utiliser des outils parmi ceux vues au précédant chapitre (PHP Unit, PHP CodeSniffer, ). Il faut également installer un serveur d intégration continue. Il existe pour cela des outils généralistes que l on peut adapter pour un projet PHP (Jenkins) ou bien des outils spécialisés et déjà configurés (PHPUnderControl, Xinc). 39 Complexité cyclomatique : indicateur de complexité d un logiciel développé par Thomas McCabe en

46 EXPLOITATION AUTOMATISATION La mise en production est bien souvent une étape considérée comme difficile. La souplesse de PHP n oblige en rien l adoption d outils facilitant cette étape et c est l intervention humaine est qui est retenue la plupart du temps. C est un risque car il est facile de faire une erreur (oubli d une étape, faute de frappe, ) aux conséquences importantes (perte de données, accès impossible, ). C est une perte de temps notamment lorsque le déploiement concerne de nombreux serveurs. Pour répondre à ceux deux problématiques, il existe des outils d automatisation de la mise en production d applications PHP. Les principaux outils de déploiement automatisé sont Phing et Capistrano. Il est possible d associer ce dernier à Webistrano pour lancer des tâches depuis une interface WEB. Il est également possible de créer son propre outil de déploiement. A l image d outils tels que Ant ou Maven, automatiser un déploiement consiste à décrire les différentes étapes à suivre au sein d un fichier de configuration (XML, ) : la récupérer des sources depuis le système de gestion de version, l exécution de scripts, l envoie sur un serveur FTP, SCALABILITE La scalabilité d une application tient en sa capacité à conserver un bon niveau de performances quelle que soit la charge d utilisation et les volumes de données à traiter. Dans la pratique, ce problème est résolu via une allocation de ressources physiques adaptée en nombre (scalabilité horizontale) et/ou en capacités (scalabilité verticale). Le requête utilisateur étant prise en charge par un serveur frontal qui la répartie parmi la grappe de serveurs applicatifs en fonction de l utilisation de ceux-ci et des politiques d équilibrage. Figure 25 - Infrastructure pour la scalabilité des applications 46