Gestion des références commerciales

Rapport de stage - septembre 2004 DESS Réseaux d information et document électronique Gestion des références commerciales rédaction du cahier des charges & initialisation de l'application Caroline GODET Sous la direction de Fabrice SZUPER Ingénieur Principal au sein de la DO S3E - Unilog IT Services Unilog IT Services 12, rue Portalis - 75008 PARIS Maître de stage : Ramzi ABBES ATER à l'enssib

Remerciements Je souhaite dans un premier temps remercier Fabrice SZUPER pour la confiance qu'il m'a accordée et pour l'intérêt qu'il a montré pour le projet. Je tiens également à remercier Matthieu FOURET pour son investissement et son soutien tout au long de ce stage. Enfin, merci à l'ensemble des membres de la DO S3E qui m'ont prêté leurs concours pour la réalisation de ce projet. 2

Résumé : Temps significatif de recherche et de mise en œuvre, peu de garantie sur la pertinence et la validité, possible perte ou altération des données telles sont aujourd'hui les principales conséquences de l'absence d'une structure adaptée pour la gestion des références commerciales. Pour pallier à ces inconvénients et mettre en œuvre une application répondant aux attentes des utilisateurs, un cahier des charges a été rédigé. Les conclusions de cette analyse ont alors donné lieu à l'initialisation d'une application reposant sur un fichier de données xml géré par des interfaces en PHP. Descripteurs : Arguments de vente -- Bases de données -- Spécifications Bases de données -- Conception XML (langage de balisage) PHP (langage de programmation) Abstract : Time-consuming steps of query and implementation, no reliable relevance or validity, possible data loss or corruption those are the main consequences caused by the lack of an appropriate structure for business-oriented references management. Therefore, a project specification has been drawn up, intending to solve those drawbacks and to fulfil users' needs. Relying on its conclusions, the development of an application has started, involving an xml file for data storage and PHP interfaces running the procedures. Keywords : Sales presentations -- Database -- Specifications Database design XML (Document markup language) PHP (Computer program language) Toute reproduction sans accord express de l auteur à des fins autres que strictement personnelles est prohibée. 3

Sommaire INTRODUCTION... 6 PARTIE 1 CONTEXTE DE L'ÉTUDE... 7 1. Présentation de la société 7 2. Enoncé de la problématique 8 3. Conduite du projet 9 3.1. Equipe projet... 9 3.2. Méthodologie... 9 3.3. Planning de réalisation... 9 3.4. Comptes-rendus d'exécution... 10 3.5. Terminologie... 10 PARTIE 2 ETUDES PRÉALABLES... 11 1. Exploration du sujet 11 1.1. Recherche documentaire... 11 1.2. Consultation des utilisateurs... 12 1.2.1. Méthode d'enquête... 12 1.2.2. Préparation des entretiens... 12 1.2.3. Déroulement des entretiens... 12 1.3. Observation... 13 2. Analyse interne 14 2.1. Analyse de l'existant... 14 2.2. Analyse des besoins... 15 3. Analyse externe 16 4. Conclusions 17 4.1. Sur la méthodologie... 17 4.2. Sur la gestion des références... 17 4.3. Sur la mise en œuvre de l'application... 18 PARTIE 3 MAQUETTE DE L'APPLICATION... 20 1. Objectifs généraux 20 2. Format 20 2.1. Contenu... 20 2.2. Champs de la base... 21 2.3. Illustrations... 21 3. Traitements 21 4. Procédures 22 4

5. Spécificités techniques 23 6. Aspects réglementaires 23 PARTIE 4 MISE EN ŒUVRE DE L'APPLICATION... 24 1. Solution technique 24 1.1. Xml native ou relationnelle?... 24 1.2. Base de données ou full xml?... 24 2. Données et environnement techniques 25 2.1. Architecture et hébergement... 25 2.2. Développement xml... 25 2.3. Plateforme et logiciel de développement PHP... 25 3. Spécificités de l'application 25 3.1. Fichier de données... 25 3.1.1. Stockage des données... 25 3.1.2. Structuration et validation des données... 26 3.1.3. Arborescence... 26 3.1.4. Eléments du fichier... 26 3.1.4.1. Représentation graphique d'xmlspy 2004... 27 3.1.4.2. Elément "unilog" & ComplexType "Contact"... 27 3.1.4.3. Elément "clients"... 28 3.1.4.4. Elément "descriptifs"... 28 3.1.4.5. Elément "projets"... 30 3.1.4.6. Elément "relations"... 34 3.2. Traitements... 34 3.2.1. Alimentation du fichier... 34 3.2.1.1. Introduction au DOM... 34 3.2.1.2. Exemple sur la saisie d'un nouveau contact... 35 3.2.2. Consultation de la base... 38 3.2.2.1. Parcourir l'arbre de nœuds... 38 3.2.2.2. Exemple sur la recherche de contacts... 39 CONCLUSIONS... 41 1. Sur la gestion des références 41 1.1. Rédaction et conclusions du cahier des charges... 41 1.2. Mise en œuvre de l'application... 41 1.3. Perspectives pour le projet... 42 2. Sur le déroulement du stage 42 BIBLIOGRAPHIE... 44 ANNEXE...I 5

Introduction Le projet de gestion des références commerciales est né d'une simple constatation : alors qu'elles constituent un élément incontournable de l'argumentaire de vente, les références commerciales ne bénéficient pas, à l'heure actuelle, d'un système de gestion approprié; répondant aux besoins des membres de la Division Opérationnelle S3E d'unilog. L'objectif de ce projet est donc de mettre en œuvre une application dont les fonctionnalités et les procédures remédieront aux limitations actuelles et seront cohérentes avec les attentes et les activités des membres de la DO. Ce projet nécessite dans un premier temps la rédaction d'un cahier des charges, préalable à l'initialisation de l'application, et c'est dans ces perspectives que j'ai été accueillie au sein de la DO S3E. 6

Partie 1 - Contexte de l'étude Partie 1 Contexte de l'étude 1. Présentation de la société Unilog est une Société de Services d'ingénierie Informatique (SSII) dont les prestations s'appuient sur trois pôles d'activités afin d'assurer une offre globale et cohérente : - le conseil pour définir de la meilleure solution, - l'ingénierie pour la réalisation effective du projet, - le training pour accompagner le déploiement auprès des utilisateurs. Unilog repose sur une organisation en Business Units elles-mêmes composées de Directions Opérationnelles (DO), structures autonomes et composées de 50 à 200 collaborateurs. A Chaque DO correspond un domaine d'intervention spécifique portant soit sur une nature de prestation, soit sur un secteur métier, soit sur un périmètre géographique. L'organisation en DO permet une certaine souplesse tout en s'appuyant sur les ressources et la notoriété d'un grand groupe. Un des points forts d'unilog réside dans ses offres, "prestations packagées bâties sur la recherche de réponses économiquement performantes et d engagements contractuels, s appuyant sur des centres de compétences transverses dédiés" [1]. Il y a trois grands types d'offres qui se retrouvent au sein des différentes DO : les offres d'intégration et de maintenance, les offres fonctionnelles et les offres technologiques. Fondé en 1968 par cinq personnes, dont l'actuel Président du Directoire, Gérard PHILIPPOT, le groupe comptait en décembre 2003 plus de 6600 employés, répartis pour la majorité dans les agences françaises, mais également en Allemagne, en Suisse, en Autriche, au Luxembourg et au Royaume-Uni [2]. 7

Partie 1 - Contexte de l'étude Le projet concerne la DO S3E, du pôle Ingénierie. Cette DO traite les demandes issues des métiers de l'eau, de l'energie et de l'environnement, des activités de Tourisme et de Loisirs ainsi que de celles émanant du monde des Médias. Parmi ses principaux clients, on peut citer la Lyonnaise des Eaux, la Compagnie Générale des Eaux, le Club Med, le PMU, Lagardère, M6 La DO dirigée par Bodgan GOILAV compte environ 150 personnes, réparties soit, pour les ingénieurs encadrants et commerciaux, sur le site rue Portalis à Paris (lieu du stage), soit chez le client pour une majorité des ingénieurs opérationnels. 2. Enoncé de la problématique Dans le cadre de son activité, Unilog est amenée à répondre à des appels d'offre ou à effectuer des présentations de ses prestations auprès de clients potentiels. Un élément constitutif de ces démarches vers le client sont les références commerciales, véritables reflets de l'expérience et de la réussite d'unilog sur une thématique donnée (technique, secteur ou client). Tous les projets réalisés ne sont pas pertinents dans un contexte donné et l'élaboration des références requiert donc une phase préalable de sélection. Or aujourd'hui, il n'y a pas de structure dédiée à cette tâche. Les outils de capitalisation disponibles ne remplissent pas les attentes des utilisateurs en matière de gestion des références et il n'y a pas de procédure adaptée. C'est pour pallier à ce manque de structure, et aux inconvénients qui en découlent, que ce projet de mise en œuvre d'un système de gestion des références a été engagé. A terme il s'agit d'obtenir une application et de définir les procédures permettant la consultation, la mise à jour et l'édition de références. Les gains attendus s'exprimant en terme de pertinence de sélection, d'actualisation des données et de facilité et de rapidité de mise en œuvre des références. 8

Partie 1 - Contexte de l'étude 3. Conduite du projet 3.1. Equipe projet Le sujet a été proposé et supervisé par Fabrice SZUPER, ingénieur principal au sein de la DO S3E. L'encadrement du stage a été assuré par Matthieu FOURET, ingénieur analyste. Jacques NHOUYVANISVONG, expert technique junior, a été consulté sur les aspects techniques de l'application. Le présent document expose ma contribution au projet. 3.2. Méthodologie La démarche adoptée pour traiter le sujet repose sur les étapes élémentaires de la conduite de projet. Dans un premier temps, les analyses préalables, par l'exploration du sujet et les analyses interne et externe, ont permis de rédiger un cahier des charges prévisionnel. La validation de celui-ci a permis de définir les modalités techniques et fonctionnelles de la base et de rédiger ainsi le cahier des charges détaillé. C'est en s'appuyant sur les conclusions de ce dernier que la phase de mise en œuvre a pu être amorcée. Au moment de la rédaction du présent rapport, les choix techniques ont été arrêtés, notamment concernant la structure de la base et les modalités de traitement, et certains scripts rédigés. 3.3. Planning de réalisation Un diagramme de Gantt a été établi en début de projet pour permettre d'en cadrer la progression. Les différentes échéances en ont globalement été respectées. Un délai supplémentaire a toutefois été accordé à la réalisation des entretiens pour s'adapter aux congés de certains audités. NB : la semaine du 12 au 16 juillet a été consacrée à la finalisation d'un projet débuté en juin, avant le démarrage du présent projet de gestion des références. 9

Partie 1 - Contexte de l'étude étude des documents existants préparation, réalisation & analyse des interview s rédaction et validation du cahier des charges reflexions et choix techniques mise en œuvre rédaction du mémoire 1/7 16/7 31/7 15/8 30/8 14/9 29/9 3.4. Comptes-rendus d'exécution Comme précisé précédemment, la rédaction du cahier des charges s'est effectuée en deux étapes, chacune ayant donné lieu à la rédaction d'un document transmis à la société. Un troisième rapport est en cours de réalisation sur la phase de mise en œuvre de l'application. Le présent rapport n'a pas pour objectif de reprendre dans le détail les résultats obtenus lors de la conduite du projet, ceux-ci figurent dans le cahier des charges joint à cette intention. En revanche, il expose les démarches entreprises et le cas échéant, la justification de certaines décisions. Seules les principales conclusions sont reprises dans le corps du document pour permettre de suivre l'évolution du projet. 3.5. Terminologie Le sujet met en jeu d'un côté 'la référence' et de l'autre 'les références' : la référence étant le descriptif d'un projet donné et un élément constitutif des 'références'. Pour éviter toute ambiguïté, la référence sera désignée dans ce rapport par l'expression "synthèse projet", les références étant alors une sélection de synthèses projet composée dans un but commercial donné. 10

Partie 2 - Etudes Préalables Partie 2 Etudes préalables Avant de procéder à toute opération de réalisation, il importait dans un premier temps d'approfondir la connaissance du sujet et de définir les différentes constituantes de la problématique. A cette fin, l'étude a débuté par une phase préliminaire d'exploration du sujet, découlant sur une analyse de l'interne (en matière d'existant et de besoins), complétée par une analyse externe. 1. Exploration du sujet Cette phase d'investigations et de recherches a eu pour objectif d'aboutir à une connaissance suffisante du sujet des références et de leurs contextes de mise en œuvre pour permettre une analyse de l'existant la plus représentative et complète possible. Trois approches complémentaires ont été mises en œuvre à cette fin : une recherche documentaire, la consultation des utilisateurs et l'observation des pratiques et usages. 1.1. Recherche documentaire C'est par cette étape que le premier contact avec le sujet a été engagé. Les documents sont principalement disponibles sous forme numérique, il n'existe pas de gestion à proprement parler des documents papiers. Au-delà de la simple collecte de documents, cette recherche a permis dans un premier temps d'approcher la notion de 'références' et de recadrer ainsi le sujet avec le commanditaire. Cette étape m'a par ailleurs donné l'occasion de me familiariser avec les outils disponibles pour la gestion des documents : le serveur de la DO, qui gère les documents à l'échelle de la DO, et Sésame, l'intranet d'unilog. Ces connaissances ont ensuite été mises à contribution lors de la consultation des utilisateurs et de l'analyse des informations collectées par ce biais. 11

Partie 2 - Etudes Préalables 1.2. Consultation des utilisateurs 1.2.1. Méthode d'enquête La consultation des utilisateurs représentait la meilleure perspective pour comprendre comment étaient gérées les références au sein de la DO. Il a été initialement envisagé d'élaborer un questionnaire pour l'ensemble des utilisateurs et de le compléter par des entretiens auprès d'une fraction d'entre eux. Au cours de la préparation du questionnaire, il est apparu que cette méthodologie n'était pas la plus appropriée. En effet comment : mettre en évidence une procédure, sans demander à l'audité de fournir des efforts de rédaction? ; cerner des limites sans influencer ses décisions par une liste de choix? ;... La liste des questions s'allongeant et se compliquant au fur et à mesure des thèmes à aborder, et compte tenu du nombre d'utilisateurs concernés, la solution des entretiens de l'ensemble des utilisateurs a finalement prévalue ; solution par ailleurs plus compatible avec la disponibilité des audités. 1.2.2. Préparation des entretiens Sur la quinzaine de personnes de la DO manipulant des références commerciales, 10 personnes ont été auditées : l'ensemble des ingénieurs d'affaires, des ingénieurs commerciaux et des directeurs de projet ont été retenus, complété par l'entretien d'un membre du comité de direction, responsable commercial de la DO. Préalablement aux entretiens, les personnes auditées ont été informées par mail des grandes lignes du projet de gestion des références et invitées à me transmettre, avant la date de rendez-vous fixée, un document représentant pour eux ce que devrait être une référence commerciale. 1.2.3. Déroulement des entretiens Les entretiens ont été réalisés sur la période du 22 juillet au 11 août, en fonction des disponibilités respectives. Dans la plupart des cas, les entretiens se sont déroulés dans les bureaux des audités qui pouvaient ainsi disposer de leurs 12

Partie 2 - Etudes Préalables ressources numériques. L'un de ces entretiens n'a pu être réalisé en présentiel et s'est tenu par téléphone. Après une présentation plus détaillée du projet, portant notamment sur les possibilités d'une base xml, les audités ont été invités à se prononcer aux travers d'une série de questions sur différents points tels que : - objectifs et usages des références - fond et forme d'une synthèse projet - leur gestion actuelle (outils, documents, procédure ) - intérêts et portée d'une base de références La finalité de ces entretiens était de pouvoir répondre aux interrogations suivantes : - comprendre l'utilisation des références - comprendre les limites de la procédure actuelle - définir les avantages attendus d'un nouvel outil - définir les champs d'une référence et de la base (sa portée) - définir le graphisme général Programmés pour une heure, les entretiens ont duré entre 40 minutes et 1h45, pour une moyenne de 1h10. 1.3. Observation Bien que relativement subjective, cette méthode s'est avérée enrichissante en matière de collecte d'informations, notamment au niveau des comportements et des pratiques. Les observations ont principalement portées sur une typologie d'utilisateurs, en assistant au quotidien à leurs échanges et à l'expression de leurs satisfactions et/ou contrariétés. 13

Partie 2 - Etudes Préalables 2. Analyse interne Cet état des lieux a été rédigé sur la synthèse des différentes étapes mises en œuvre pour l'exploration du sujet. 2.1. Analyse de l'existant En compilant les différentes informations collectées lors de la phase précédente, il a été possible de dresser un bilan de l'existant pour ce qui concerne la gestion des références, en matière : - de structure - de moyens matériels et humains - de sources d'informations et de références - de flux de communication et de procédures Bien qu'assimilables à des moyens matériels, les sources d'informations et les références ont été traitées à part, pour permettre de mieux souligner leurs particularités. L'analyse de l'existant a permis de définir les principales limites auxquelles l'application devra remédier et les spécificités du contexte avec lesquelles il faudra composer : - absence de gestion centralisée des synthèses projet, - comportements autonomes et hétérogènes dus au manque de procédure - existant difficilement capitalisable et exploitable - possible silence dans les références éditées et perte de données dans le temps - contexte et gestion électronique des documents peu compatibles avec un processus de capitalisation - approche relativement négative des outils disponibles, induite par une inadéquation et un manque de communication 14

Partie 2 - Etudes Préalables 2.2. Analyse des besoins Un certain nombre de besoins ont été mis en évidence au travers des étapes précédentes, exprimés ou non, communs ou conflictuels. Il importait pour la rédaction du cahier des charges détaillé de statuer au préalable sur les "besoins conflictuels". Ceux-ci découlent des différents comportements adoptés par chacun en l'absence de procédure. Pour les points suivants, des opinions "pour" et "contre" se sont exprimées de manières équivalentes : - validation des synthèses projet : à un souhait d'homogénéité et de garant de qualité des uns s'oppose celui d'une procédure simple, justifiée par la compétence de ses acteurs. - gestion des droits en écriture sur les données de la base : perçues par certains comme inutiles, voire constituant un risque de rejet de l'outil, les restrictions en écriture sur les synthèses projets sont considérées par ailleurs comme nécessaires, dans une certaine mesure pour garantir la fiabilité des données - intégration des projets en cours comme synthèse projet potentielle : il apparaît à la fois judicieux et périlleux de ne pas attendre le terme d'un projet pour en extraire une synthèse projet ; judicieux au regard de l'évolutivité du secteur et périlleux en raison des incertitudes quant à sa conclusion. Les décisions ont été prises après concertation au sein de l'équipe projet sur la base de données contextuelles et techniques, pour être ensuite intégrées au cahier des charges détaillé et donc repris dans la maquette. D'une manière unanime, au-delà de la résolution des limites actuelles, les usagers considèrent l'application comme une source de connaissance sur les projets, de la DO S3E et idéalement des autres DO. Les principales attentes sur l'outil sont un accès efficace aux synthèses projet pertinentes, la fiabilité des données, l'homogénéité des références émises et la rapidité de mise en œuvre. 15

Partie 2 - Etudes Préalables Pour en garantir la pérennité et le bon usage, les fonctionnalités de la base et les procédures associées devront être cohérentes et réalistes avec son contexte d'exploitation. Les processus devront être rapides et simples à mettre en œuvre, la procédure devra être personnifiée et régulée. Par ailleurs, une campagne de communication et d'accompagnement doit être menée auprès des futurs utilisateurs pour les sensibiliser tant à l'outil qu'à la capitalisation. 3. Analyse externe Cette section étudie l'environnement du projet en terme d'acteurs et de secteur, afin de mettre en évidence les éventuelles opportunités à saisir et menaces à prendre en compte pour son bon développement. Dans ce contexte, il apparaît que le principal obstacle pour l'application réside dans l'organisation en DO qui développe chez certains un sentiment de préservation. Paradoxalement, tous ont exprimé un besoin de transversalité dans l'origine des synthèses projet ; les projets menés dans les autres DO pouvant potentiellement augmenter la pertinence de la réponse d'unilog dans un contexte donné. Les missions d'o4b 1 ne remettent pas en question la conduite du projet, elles lui offrent même de nouvelles perspectives de développement. Des deux options possibles, il a été décidé de d'abord traiter le projet en local et d'éventuellement envisager par la suite le développement d'une application concrète à l'échelle de la société, en partenariat avec O4B. Se lancer directement dans un projet à l'échelle de la société, semblait offrir moins de garantie sur la conduite et l'aboutissement du projet. 1 "Offers For Business" est une Direction Fonctionnelle qui a pour mission principale de créer les outils de commercialisations des savoir-faire d'unilog, dont des extraits de références thématiques. 16

Partie 2 - Etudes Préalables 4. Conclusions 4.1. Sur la méthodologie L'enchaînement des étapes - recherche documentaire, entretiens, observation - a permis une progression cohérente dans la compréhension de la problématique :! la recherche documentaire a permis de collecter une somme importante d'informations, tant sur les documents en eux-mêmes que sur les outils disponibles. Il était cependant difficile d'en évaluer l'usage et la pertinence.! grâce aux entretiens, il a été possible, d'une part, de distinguer parmi la masse de données celles qui correspondaient aux attentes des usagers et, d'autre part, de comprendre l'utilisation qui était faite des outils. En contrepartie, les connaissances acquises lors de la phase de recherche ont permis de dynamiser les entretiens et d'approfondir les réponses des audités en donnant matière à réagir à leurs observations. Les objectifs fixés pour ces entretiens ont tous été atteints et, en considérant les résultats obtenus, la décision de privilégier ce mode de consultation aux questionnaires s'en est trouvée confortée.! enfin, l'observation en situation d'une fraction des audités a permis d'encore affiner la connaissance du sujet et la pertinence des conclusions de l'analyse interne. 4.2. Sur la gestion des références Résultant de l'activité commerciale de plusieurs années, il existe aujourd'hui un nombre significatif de références mais celles-ci sont non homogènes, non mises à jour, non centralisées, principalement stockées dans les présentations pour lesquelles elles ont été établies. Il est délicat alors de parler de gestion de ces références. Les outils de capitalisation que sont le répertoire "Documentation" du serveur S3E_commerce$ et l'intranet Sésame ne répondent pas, pour des raisons pratiques ou contextuelles, aux attentes des audités et sont; de fait, peu exploités. 17

Partie 2 - Etudes Préalables De plus, l'absence de procédure impacte la synthèse projet à chaque étape de sa vie, de sa sélection à son actualisation, en passant par sa rédaction, sa validation ou son utilisation. Rédigée "au besoin" et directement intégrée à des références contextuelles, elle est, à terme, difficilement capitalisable. Au-delà des considérations techniques c'est également l'absence d'une procédure "appuyée" qui explique le faible taux de capitalisation. Au moment de la mise en œuvre des références, la priorité n'est généralement pas à la capitalisation, mais à une réponse dans les délais au client. Ne s'agissant pas d'une tâche opérationnelle, le retour ultérieur à une éventuelle démarche de capitalisation est régulièrement remis. Les audités admettent ne simplement pas y penser, ne pas prendre le temps ou ne pas saisir l'intérêt qu'ils auraient à le faire. La capitalisation n'est donc pas intégrée aux méthodes de travail, que ce soit sciemment ou par défaut. Paradoxalement, le moyen privilégié des audités pour constituer des références repose sur la mise en commun des savoirs au travers de la mémoire collective et du réseau de relations, à l'intérieur et à l'extérieur de la DO. Ils mettent donc à profits les avantages de la capitalisation, mais selon une approche non structurée et non formalisée. C'est peut être à la dimension humaine du réseau de relations, tant d'un point de vue numérique que dans la nature des échanges, que peut être attribuée cette amorce de capitalisation. 4.3. Sur la mise en œuvre de l'application Comment justifier la mise en place d'une application dédiée à la gestion des références alors que deux outils sont d'ores et déjà disponibles, sans compter les dossiers 'offres' que propose O4B désormais? En ce qui concerne le répertoire "Documentation" du serveur S3E_Commerce$, son manque de fonctionnalité et sa rigidité de classement justifient sa non exploitation et il serait difficile de remédier à ces inconvénients. En revanche, Sésame, grâce à son moteur de recherche et à la typologie des documents, répond à une partie significative des attentes des audités. Avec une meilleure communication sur l'outil et ses possibilités, il serait probablement plus 18

Partie 2 - Etudes Préalables spontanément utilisé, dans le cadre de la consultation du moins. Et il est plus simple et plus rapide de prévoir la formation d'une quinzaine de personnes déjà familiarisées avec l'outil que de complètement mettre en place une nouvelle application. Deux arguments cependant, par leurs conséquences en terme de réactivité et de capitalisation, justifient la poursuite du projet : l'exploitabilité et la proximité. D'une part, les données sont actuellement disponibles sous la forme de références contextuelles et non de synthèses projet, ce qui pénalise la recherche et induit systématiquement des étapes fastidieuses pour la sélection, l'adaptation et la mise en page. L'outil tel qu'il est envisagé aujourd'hui en gérant et en centralisant les données sous forme de synthèses projet factuelles permettra d'optimiser les recherches et de limiter les pertes d'informations. De plus, grâce à l'utilisation de masques d'édition spécifiques, les manipulations de mises en forme seront également simplifiées, quelque soit le support d'édition final. Avec une meilleure prise en charge à chacune des étapes de leurs mises en œuvre, les bénéfices à retirer en terme de réactivité sur la constitution de références confèrent un intérêt tout particulier au projet. D'autre part, les audités ont unanimement exprimé un besoin de spécificité et de pertinence des synthèses projet. Les références à l'échelle du groupe telles qu'elles sont disponibles sur Sésame (et maintenant plus facilement accessibles pour une partie des audités) ne sont pas adaptées à une réponse 'projet' dans le secteur spécifique de la DO. C'est pour répondre à un souhait de proximité tant dans le contenu que dans le public ciblé que le projet garde une grande part de sa pertinence. Loin d'être une démarche néfaste à la capitalisation, ce développement initial en local, restreint à une certaine population, peut au contraire permettre l'intégration de la capitalisation aux méthodes de travail. C'est dans cette optique que le projet peut être raisonnablement maintenu. Le chapitre suivant propose une maquette de l'application et les principales fonctionnalités déduites des résultats des analyses préalables. 19

Partie 3 - Maquette de l'application Partie 3 Maquette de l'application Cette maquette a été élaborée pour synthétiser, au terme des analyses préalables, les caractéristiques attendues de l'application et servir de support à son développement en terme de format, de traitements et de procédures. 1. Objectifs généraux L'application doit non seulement combler les limites actuelles et répondre aux attentes et besoins exprimés, mais aussi faire mieux que le réseau de relations et les bases personnelles, en termes de réactivité et de pertinence. Appuyée par la procédure, les bénéfices retirés de l'application doivent également amener les utilisateurs à intégrer la capitalisation dans leur méthode de travail. Pour convaincre les utilisateurs, l'application devra donc prendre en compte les deux compromis suivants : Richesse de la base / Temps de manipulation Fiabilité des données / Liberté de manœuvre 2. Format 2.1. Contenu Pour permettre de gérer la synthèse projet aux différents stades de sa vie, il est envisagé de recenser l'ensemble des projets menés par la DO. Il pourrait ainsi être indiqué de manière formelle si le projet doit être référencé ou non, par qui et dans quel délai. Il sera alors également possible, à l'appréciation du rédacteur, d'intégrer des projets en cours dans les références. Idéalement, les synthèses projet gérées ne seront pas restreintes à celles émanant de la DO et la base intègrera. 20

Partie 3 - Maquette de l'application 2.2. Champs de la base Si les audités attendent globalement une source de connaissance sur les projets référencés, le degré d'information et la nature des champs attendus diffèrent. Un juste milieu est à trouver entre la richesse informationnelle de la synthèse projet et d'une part, son temps de saisie et d'autre part, son temps de consultation. Le tableau présenté en annexe reprend les champs retenus pour la base et/ou pour la synthèse projet (en gras), pondérés par le nombre de sollicitation. Au terme des entretiens, la notion de champ obligatoire ne semble pas judicieuse. Pénaliser un geste de capitalisation en bloquant l'enregistrement d'une synthèse projet pour une donnée manquante n'aurait que des conséquences néfastes sur l'outil. Un guide de saisie précisant les champs principaux "recommandés" et ceux complémentaires serait plus envisageable. C'est plus au niveau de la procédure que devrait s'opérer le contrôle de la bonne alimentation de la base. 2.3. Illustrations Seuls les logos, unitaires ou sous forme de mosaïques ont été retenus. Les captures d'écran, compte tenu de leur proportion d'utilisation par rapport aux démarches de demandes d'autorisation et de dépersonnalisation ne justifient pas d'être intégrées aujourd'hui. 3. Traitements Les principales attentes sur l'outil sont l'accès aux synthèses projet pertinentes, la fiabilité des données, l'homogénéité des références émises et la rapidité de mise en œuvre. Pour satisfaire à ces critères, les fonctionnalités suivantes peuvent être envisagées : - Indexation des champs principaux pour optimiser les résultats du moteur de recherche - Statistiques d'édition des références - Utilisation de listes de choix et de typologie de champs pour la saisie 21

Partie 3 - Maquette de l'application - Gestion de masques d'édition pour différents formats de sortie et niveaux de détails - Gestion des illustrations Complétées dans une version ultérieure par : - Gestion des droits en écritures - Planification des tâches - Système de validation pour les modifications apportées dans la base (*) (*) : dans un premier temps, seule une notification de l'état "validé" ou non sera mise en place. 4. Procédures Pour compléter les fonctionnalités, les procédures suivantes pourraient être engagées. au niveau de la synthèse projet, préciser : - qui définit de référencer ou non un projet, sur quel(s) critère(s)? - par qui, à quel moment et dans quel délai elle doit être rédigée - qui est en charge de son actualisation au niveau de la gestion de la base, pour en garantir la pérennité, définir les modalités et personnes : - garantes de la bonne alimentation et actualisation de la base - responsables de sa mise à jour (élimination des synthèses projet désuètes) NB : Compte tenu du planning et du probable conditionnement de la procédure par les fonctionnalités de l'outil, il a été décidé de se concentrer dans un premier temps sur l'approche technique et concrète de la réalisation ; les aspects de procédure seront traités ultérieurement. 22

Partie 3 - Maquette de l'application 5. Spécificités techniques D'un point de vue technique, l'application doit répondre aux critères suivants : - portabilité : initialement développée comme une solution autonome, l'application pouvant être à terme intégrée dans d'autres applications - gratuité : il n'y a pas de budget alloué au projet, l'application doit donc être élaborée sur la base des ressources d'ores et déjà disponibles et sur des solutions OpenSource. 6. Aspects réglementaires Dans le cadre de la gestion de références commerciales, deux aspects réglementaires sont à prendre en considération : - le droit des marques, pour l'utilisation des noms et logos, conformément au code de la propriété industrielle - la loi 78-17 "informatique et libertés" du 6 janvier 1978, pour la création de fichiers nominatifs La gestion du droit des marques intervient au niveau de l'établissement des contrats entre le client et Unilog, en amont de l'application. En ce qui concerne les déclarations auprès de la Commission nationale de l'informatique et des libertés (CNIL), une action a été entreprise au sein de la société pour s'informer des modalités d'intégration des fichiers nominatifs de la base au sein des déclarations existantes. Toutefois, les objectifs et exploitations de la base rentrent dans les critères de tolérance de non-déclaration concédée par la CNIL [3]. 23

Partie 4 - Mise en Œuvre de l'application Partie 4 Mise en Œuvre de l'application Les choix technologiques ont été établis en s'appuyant sur la maquette et sur les ressources disponibles. Au moment de la rédaction du présent document, cette phase de réalisation venait juste d'être commencée et de nombreux points étaient encore en cours de validation et/ou de développement. 1. Solution technique Afin de répondre aux exigences de portabilité de la base et de budget, la solution xml semble la plus appropriée. Trois solutions se présentent alors : - une base de données xml native Open Source, comme exist [4] ou Apache Xindice [5] - un SGBDR Open Source compatible xml, comme MySQL [6] ou PostgreSQL [7] - full xml avec traitements sous langage de programmation, java, asp.net ou php par exemple. 1.1. Xml native ou relationnelle? D'une base de données xml native ou d'un SGBDR, quelle solution est la plus adaptée à la problématique? Contenu structuré, axé sur les données, strictement décrit par un schéma ; structure prévisible et relativement fixe ; modalités de recherche basiques ; les caractéristiques de la base potentielle orientent plutôt vers un SGBDR que vers une base de données xml native [8]. 1.2. Base de données ou full xml? En s'appuyant sur les recommandations de l'expert technique consulté, c'est la seconde option qui a été retenue : elle permet une totale indépendance de tout outil ou de version de base de données. Pour la DO, elle offre par ailleurs une certaine plus value car ce type de projet n'y a pas encore été développé. 24

Partie 4 - Mise en Œuvre de l'application Le langage de traitement initialement envisagé était l'asp.net. Cependant, pour des impératifs de planning, il était difficilement envisageable d'intégrer au projet une phase de formation à ce langage, l'application a donc été initialisée en PHP et sera éventuellement développée ultérieurement en asp.net. 2. Données et environnement techniques 2.1. Architecture et hébergement L'application fonctionnera sous un modèle d'architecture clients/serveur. La DO dispose d'ores et déjà d'un serveur d'application sur lequel l'application pourra être hébergée. 2.2. Développement xml Les différents fichiers xml ont été rédigés sous xmlspy 2004 Home Edition, de la société Altova [9]. 2.3. Plateforme et logiciel de développement PHP Le choix de la plateforme de développement s'est orienté vers WAMP5 [10], pour "Windows - Apache - MySQL- PHP5" ; choix. motivé par la présence de la version 5.0.1 de PHP, plus compatible avec le xml que les versions antérieures. Les scripts ont été rédigés sur une version d'essai de PHP Expert Editor 3.2 [11]. 3. Spécificités de l'application 3.1. Fichier de données 3.1.1. Stockage des données L'ensemble des informations est stocké dans un fichier plat xml, dans une orientation documents, plutôt que données, compte tenu des perspectives d'exploitation sélective et multi-formats [12]. 25

Partie 4 - Mise en Œuvre de l'application En terme de volumétrie, le nombre de références qui seront intégrées et maintenues dans la base n'étant pas encore déterminé, il serait délicat d'estimer l'espace de stockage à prévoir pour ce fichier. Néanmoins, l'absence de cette donnée n'est pas réellement problématique compte tenu du nombre relativement limité de synthèses projet concernées à terme et de la faible taille relative des fichiers xml et php. 3.1.2. Structuration et validation des données Pour la validation du fichier, un schéma xml a été préféré à une DTD pour les avantages qu'il présentait en matière de typologie de données et de contraintes sur leurs valeurs. Par ailleurs, si l'application est intégrée ultérieurement à un autre outil, la prise en charge des espaces de noms par le schéma pourra s'avérer relativement utile. 3.1.3. Arborescence Au moment de la rédaction du mémoire, l'arborescence du fichier n'est pas encore définitive, plusieurs modèles sont encore à l'étude. 3.1.4. Eléments du fichier Le tableau des champs dressé au terme des entretiens a été affiné et ponctuellement réorganisé pour aboutir à 5 éléments principaux. Ces éléments sont pour l'heure provisoires dans la mesure où ils dépendent du modèle de schéma qui sera finalement adopté, mais les variations éventuelles ne portant que sur la position de quelques éléments fils, ils constituent une bonne représentation de ce que sera le fichier final. Pour conférer une certaine souplesse de saisie à la base, un maximum de champs est optionnel. Comme établi dans le cahier des charges, c'est une approche procédurale et non technique qui devra garantir la bonne alimentation de la base, il appartiendra donc au rédacteur et/ou validateur de s'en assurer. Les différents éléments sont présentés dans les paragraphes suivant, en utilisant la représentation graphique de schéma que propose xmlspy 2004, qui permet de saisir rapidement l'arborescence et les occurrences des différents éléments. 26

Partie 4 - Mise en Œuvre de l'application 3.1.4.1. Représentation graphique d'xmlspy 2004 Les principaux symbolismes mis en œuvre sont les suivants : élément obligatoire, non répétable élément facultatif, non répétable élément obligatoire, répétable un nombre infini de fois élément facultatif, répétable un nombre fini de fois introduit une séquence induit un choix 3.1.4.2. Elément "unilog" & ComplexType "Contact" Cet élément recense l'ensemble des membres d'unilog et leurs coordonnées. La description d'une personne, quelque soit son niveau d'intervention reste la même. Pour ne pas redéfinir ces différentes constituantes à chaque fois, on définit un type complexe qui pourra être appliqué à chaque fois qu'une personne aura besoin d'être décrite. xmlspy 2004 27

Partie 4 - Mise en Œuvre de l'application 3.1.4.3. Elément "clients" Cet élément comprend toutes les caractéristiques du client, indépendamment du projet dans lequel il est engagé. Les différentes données clients peuvent être organisées ainsi : xmlspy 2004 3.1.4.4. Elément "descriptifs" Cet élément constitue un référentiel des différentes techniques qui peuvent être rencontrées ou mises en œuvre chez le client (l'environnement technique du projet) ainsi que des offres que va proposer Unilog. Pour cet élément, de nombreux champs peuvent être prédéterminés au travers de l'enregistrement de valeurs d'attribut. Par exemple, pour les offres support, l'attribut "type_support" ne peut prendre que les valeurs : BI,Collaborative Business, Dot Solutions, EAI, EDM-KM ou Mobile Business. 28

Partie 4 - Mise en Œuvre de l'application Elément "descriptifs" : xmlspy 2004 29

Partie 4 - Mise en Œuvre de l'application 3.1.4.5. Elément "projets" C'est l'élément le plus 'conséquent' de la base. Il recueille toutes les données spécifiques au projet, que l'on peut répartir sur deux axes comme le montre l'extrait suivant : xmlspy 2004 Gestion du projet Cet élément gère le projet dès son initialisation, sollicitation du client ou démarchage. Il indique s'il a été gagné ou non (élément "decision") et s'il doit ou non donner lieu à la rédaction d'une synthèse projet et selon quelles modalités (élément "referencable"). Cet élément est obligatoire, contrairement à l'élément "synthese_projet" dans la mesure où les projets ne sont pas tous référençables. xmlspy 2004 30

Partie 4 - Mise en Œuvre de l'application Synthèse projet A son tour, la synthèse projet peut être abordée sous deux axes :! du point de vue du client Cet élément reflète la relation avec le client tout au long du projet : les enjeux qu'il constitue, les résultats qui en découlent, en terme de bénéfices et d'accueil de la solution apportée et enfin les modalités d'utilisation du projet comme référence, notamment éventuels critères de confidentialité et souhait ou non de devenir un référant consultable ou visitable. xmlspy 2004 31

Partie 4 - Mise en Œuvre de l'application! du point de vue d'unilog pour les conditions de réalisation et l'évaluation globale du projet Les conditions de réalisation précisent le(s) positionnement(s) sur le projet (assistance maîtrise d'œuvre amont maîtrise d'œuvre exchange tierce maintenance applicative) ainsi que les modalités d'un éventuel partenariat. L'évaluation du projet complète ici les résultats recensés au niveau de l'approche client et s'adresse plutôt à un public interne qu'à une exploitation en terme de référence. xmlspy 2004 32

Partie 4 - Mise en Œuvre de l'application pour la réalisation du projet Cet élément détaille les modalités de réalisation du projet en terme d'équipe, de dimensionnement xmlspy 2004 33

Partie 4 - Mise en Œuvre de l'application 3.1.4.6. Elément "relations" Par rapport aux autres éléments présentés précédemment, cet élément est celui qui sera le plus impacté par la décision du modèle de schéma. Sa fonction sera de construire une référence complète à partir des données des constituants qui la compose : données unilog, clients, descriptifs et synthèse projet. C'est à cette fin que sont établis les différents attributs - key_contact, key_client, key_descriptif, et key_projet - qui sont repris pour définir l'élément "ref" donné : <xs:element name="relations"> <xs:complextype> <xs:sequence> <xs:element name="ref" maxoccurs="unbounded"> <xs:complextype> <xs:attribute name="key_ref"/> <xs:attribute name="key_projet"/> <xs:attribute name="key_client"/> <xs:attribute name="key_descriptif"/> <xs:attribute name="key_contact"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> 3.2. Traitements Les traitements sont assurés par des scripts en PHP5. Cette partie du projet est la moins avancée et seuls des scripts-tests, sur des extraits du fichier sont actuellement opérationnels, pour son l'alimentation et sa consultation. 3.2.1. Alimentation du fichier 3.2.1.1. Introduction au DOM Le DOM ou Document Object Model est une interface de programmation d'application (API), indépendante des langages et plateformes de développement 34

Partie 4 - Mise en Œuvre de l'application qui contribue ainsi à l'interopérabilité du web. Ses spécifications sont régies par les recommandations du W3C 2. PHP5 propose un parser DOM (Document Object Model), entièrement basé sur les recommandations du W3C, qui permet de manipuler un fichier xml : parcourir sa structure, extraire, ajouter, modifier ou supprimer des éléments. Le DOM représente le document xml sous la forme d'un arbre de nœuds dont l'ordre et la structure sont mis en correspondance avec les éléments du document. Le ''documentelement" correspond à l'élément racine du document et possède un ou plusieurs "childnodes" qui représentent les branches de l'arbre. A son tour un ChidNode peut posséder un ou plusieurs descendants, si sa définition l'autorise. Il est possible d'accéder à n'importe lequel de ces nœuds individuellement. 3.2.1.2. Exemple sur la saisie d'un nouveau contact Le script présenté ci-après à pour objectif, à partir d'un formulaire de saisie codé en html, d'implémenter le fichier "contact_light.xml" avec les coordonnées d'un nouveau contact. Pour l'exemple, on considèrera chacun des éléments comme unique et on limitera les éléments à renseigner aux suivants : <?xml version="1.0" encoding="iso-8859-1"?> <contacts> <contact> <civilite>m</civilite> <nom>szuper</nom> <prenom>fabrice</prenom> <fonction>ingénieur Principal</fonction> <mail>fabrice.szuper@unilog.fr</mail> </contact> <contact> <civilite>m</civilite> <nom>fouret</nom> <prenom>matthieu</prenom> <fonction>ingénieur Analyste</fonction> <mail>matthieu.fouret@unilog.fr</mail> </contact> </contacts> 2 W3C : World Wide Web Consortium 35

Partie 4 - Mise en Œuvre de l'application Le script du formulaire de saisie correspondant s'écrit alors : <head> <title>saisie d'un nouveau contact</title> </head> <body> <h1><u>saisie d'un nouveau contact</u></h1> <form name="profil" method="post" action="<?php $PHP_self?>"> <p>civilité : <input type="text" size="5" maxlength="5" name="civi"></p> <p>nom : <input type="text" size="30" maxlength="30" name="nom"></p> <p>prénom : <input type="text" size="30" maxlength="30" name="prenom"></p> <p>fonction : <input type="text" size="30" maxlength="30" name="fonction"></p> <p>mail : <input type="text" size="60" maxlength="60" name="mail"></p> <br/> <div><input type="submit" value="valider"></div> <br/> <?php //formulaire pour alimenter un fichier xml existant $CIVILITE=$_POST["CIVI"]; $NOM=$_POST["NOM"]; $PRENOM=$_POST["PRENOM"]; $FONCTION=$_POST["FONCTION"]; $MAIL=$_POST["MAIL"]; // récupère les données du formulaire /* pour éviter l'insertion d'un jeu de valeurs vides dans le fichier xml au chargement de la page */ if (!isset ($CIVILITE)) // message d'accueil au chargement de la page { echo "<i>"."saississez les données du nouveau contact"."</i>"; } else { // charge le fichier xml dans un nouvel objet DOM $dom = new DomDocument (); $dom->load("contact_light.xml"); // en suivant l'arborescence, crée un nouvel élément "contact" $contact=$dom->createelement("contact"); // puis les fils : crée un nouvel élément "civilite" $civilite=$dom->createelement("civilite"); 36

Partie 4 - Mise en Œuvre de l'application // crée un élément textuel qui prend la valeur saisie ds le formulaire $civilitetext=$dom->createtextnode($civilite); // rattache l'élément textuel à l'élément "civilite" $civilite->appendchild($civilitetext); // rattache l'élément "civilité" à l'élément "contact" $contact->appendchild($civilite); // et ainsi de suite $nom=$dom->createelement("nom"); $nomtext=$dom->createtextnode($nom); $nom->appendchild($nomtext); $contact->appendchild($nom); $prenom=$dom->createelement("prenom"); $prenomtext=$dom->createtextnode($prenom); $prenom->appendchild($prenomtext); $contact->appendchild($prenom); $fonction=$dom->createelement("fonction"); $fonctiontext=$dom->createtextnode($fonction); $fonction->appendchild($fonctiontext); $contact->appendchild($fonction); $mail=$dom->createelement("mail"); $mailtext=$dom->createtextnode($mail); $mail->appendchild($mailtext); $contact->appendchild($mail); //enfin, rattache le nouvel élément "contact" à la racine $dom->documentelement->appendchild($contact); //et pour enregistrer le nouveau contact dans le fichier : print $dom->save("contact_light.xml"); };?> </body> </html> Juste avant que la saisie ne soit validée et le nouveau contact enregistré dans la base, l'écran correspondant donne : 37

Partie 4 - Mise en Œuvre de l'application De nombreuses améliorations peuvent être apportées à ce type de formulaire de saisie, comme un menu déroulant pour les valeurs de la civilité, le format de la saisie champs des numéros de téléphone, sans compter un soupçon de convivialité à l'attention des utilisateurs. 3.2.2. Consultation de la base 3.2.2.1. Parcourir l'arbre de nœuds En plus du DOM présenté précédemment, PHP5 offre deux autres possibilités pour sélectionner et retourner les valeur d'éléments du fichier : XPath et SimpleXML XPath Selon le W3C, l'objectif principal du XPath est d'identifier et d'accéder à des portions ou des sous-ensembles de documents xml. Ce langage fonctionne à la manière des chemins de localisation de fichiers sous UNIX où l'arbre du fichier xml remplace l'arborescence des répertoires. La commande xpath peut retourner soit toutes les occurrences d'un élément donné, soit un nœud spécifique en fonction de sa position dans l'arborescence ou de la valeur de son attribut. L'utilisation de chemin de localisation rend plus précise la requête notamment lorsque des éléments portent le même nom alors qu'ils sont enfants de nœuds différents. 38