plan rapport : - dept. info

BON Damien

Réalisation d’un gestionnaire de droits d’accès et d’authentification, sous forme de plug-in, pour une plateforme de travail collaboratif web

[Master Informatique]

[Année 2009/2010]

[Maître de stage :

Damien Roch]

[Enseignant tuteur :

Fabien Peureux]

Rapport de stage

UFR ST - Master Informatique Année 2009/2010

Rapport de stage – VT-Design

Remerciement

Je tiens tout d’abord à remercier M. Eric Binetruy, directeur de la société VT-Design, pour m'avoir accueilli dans son entreprise pour mon stage de fin d’étude.

Je remercie plus particulièrement Damien Roch, mon maître de stage, pour tout le temps qu'il a pu me consacrer, pour toute l'aide qu'il a pu me fournir et pour m’avoir guidé tout au long de mon stage.

Merci également à toute l'équipe de VT-Design pour leur accueil, leur soutien et pour avoir facilité mon intégration au sein de la société.



Sommaire

Remerciement ............................................................................................................ 2 Sommaire ................................................................................................................... 3 Introduction ................................................................................................................. 4 1. Présentation du stage ............................................................................................. 5

1.1. Présentation de l’entreprise ............................................................................. 5 1.2. Présentation du sujet ....................................................................................... 7

2. Adaptation et mise en situation ............................................................................... 8

2.1. Environnement de travail ................................................................................. 8 2.2. Les nouveaux concepts et notions ................................................................. 10 2.3. La plateforme de travail collaboratif « VT-Application Suite » ....................... 12

3. Déroulement du stage .......................................................................................... 15

3.1. Module de gestion électronique de documents .............................................. 15 3.2. Plug-in de gestion de droits d’accès et d’authentification ............................... 17

Bilan ......................................................................................................................... 29

Apports à l’entreprise ............................................................................................ 29 Apports personnel ................................................................................................. 29

Conclusion ................................................................................................................ 30 Bibliographie ............................................................................................................. 31 Table des matières ................................................................................................... 32 Annexe 1 .................................................................................................................. 33 Annexe 2 .................................................................................................................. 34



Introduction

Dans le cadre de l’enseignement à l’UFR Sciences et Techniques de Besançon, un stage de seize semaines doit être effectué dans une structure informatique. Ayant pour vocation première de valider nos connaissances, le stage permet surtout de les mettre en application dans un contexte professionnel.

J’ai choisi de mener le mien dans l’entreprise informatique VT-Design, située

à Besançon. Celle-ci s’est spécialisée dans la réalisation de sites web, de solutions collaboratives et la communication papier. Ce stage a attiré mon attention car, à l’inverse d’autres entreprises, le travail de celle-ci est exclusivement consacré au domaine de l’informatique appliqué à l’Internet et au multimédia. De plus, la société VT-Design suit les tendances et les évolutions des différents concepts, outils et langages du monde Internet pour faire évoluer ses projets afin de toujours rester à la pointe de la technologie. L’univers de l’Internet, mais particulièrement du web, a figuré comme un atout supplémentaire dans le choix du stage, qui sera d’autant plus formateur et enrichissant.

Ce stage peut m’apporter énormément sur le plan technique et pourrait ainsi se révéler être un atout évident pour ma future carrière professionnelle. De plus, il va me permettre de me former au travail de groupe et plus généralement au travail en entreprise.

L’entreprise VT-Design m’a donc proposé de contribuer au développement de leur plateforme de travail collaboratif. Au commencement, mon sujet de stage consistait en la réalisation d’un gestionnaire électronique de document pour la dernière version de leur plateforme. Mais après avoir analysé certain besoin nécessaire pour le bon fonctionnement de la GED, mon maître de stage et moi-même avons établi que le système de gestion de droits d’accès et d’authentification devait être complètement refait car non adapté pour les spécificités des nouvelles applications et sites web qui allaient être développés. Mon sujet de stage a donc été mis en pause afin que je puisse me consacrer pleinement à cette nouvelle tâche d’autant plus que la GED allait avoir grandement besoin de ce système de gestion de droits d’accès et d’authentification.

Mais avant de vous parler de manière plus détaillée des travaux qui m’ont été confiés, une présentation plus étoffée de l’entreprise et de l’environnement de travail paraît nécessaire afin de mieux comprendre les enjeux. Ensuite, je vous présenterai mes objectifs et mes réalisations effectués au cours de ce stage. Enfin, j’établirai un bilan, qui fera ressortir les nouvelles notions que j’ai pu apprendre ou améliorer durant ces seize semaines de stage.



1. Présentation du stage

Avant de vous rendre compte de mon adaptation et du travail que j’ai réalisé dans le cadre de ce stage de fin d’études pour la société VT-Design, je vais vous parler de mon intégration au sein de l'entreprise et vous présenter un peu plus l’outil et le lieu de travail sur lequel j’ai effectué mon stage.

1.1. Présentation de l’entreprise

Mon stage s'est déroulé au sein de la société VT-Design à Besançon qui,

depuis 2001, développe des sites Internet, des plateformes collaboratives et conçoit le design graphique pour de nombreuses entreprises. Je vais, dans un premier temps, présenter l'entreprise puis les différents services qu'elle propose à ses clients, avant de dresser un descriptif de mes sujets de stage.

Historique

VT-Design existe depuis 9 ans. C’est la fusion de deux structures : Tryphon

Développement, créée en 1997, et V Grafik créée en 2000. En 2005, VT-Design a reçu un label en or d’excellence du multimédia européen. Décerné par l’EMMAC, la convention des associations européennes du multimédia, ce prix est attribué sur la base de six critères :

- Innovation - Performance - Facilité d’utilisation et ergonomie - Intérêt pour l’utilisateur - Taux de pénétration du marché et potentiel de développement - Capacité de développement à l’international

C’est la plate-forme de travail collaborative de VT-Design, appelé VT-Oolkit,

qui a été récompensée pour la diversité de ses applications et son évolutivité. Il s’agissait d’un des seul outil du marché à intégrer à la fois une gestion de contenu de site web, des modules de travail collaboratif comme la gestion documentaire, le management de projet, les carnets d’adresses partagés et aussi une gestion de newsletter électronique.

Activité

La société VT-Design, est spécialisée dans la conception et la réalisation de

produits de communication et d’édition multimédia. Il s’agit d’un studio multimédia intégrant : conseil stratégique et marketing, conception graphique globale, développement web, promotion on-line.

Sa principale caractéristique peut se résumer plus simplement à la conception et réalisation de produits multimédia. Les domaines de compétences de l’entreprise sont néanmoins nombreux : Site Web, Applications Web, Intranet / Extranet. Le savoir-faire ne se limite pas à ces domaines, il s’étend à d’autres caractéristiques:



- Création graphique multi supports / Design graphique d’interfaces - Développement Web, Intranet / Extranet et portails dynamiques :

langage HTML / JavaScript / PHP auto administrables - Développement de catalogues produits on-line et off-line - Commerce électronique - Promotion en ligne, référencement, newsletter électronique

d’information - Charte graphique et ergonomie de produits connectés

Il faut savoir que chaque projet pour la partie « solutions collaboratives »

représente de très gros dossiers qui nécessite un important travail d’analyse et développement où les tâches se succèdent sur de grandes périodes comptées en mois voir en années.

L'équipe

VT-Design est une structure où chaque membre de l'équipe a de multiples

compétences qu'il met au service de la clientèle. Ainsi, chaque personne est susceptible d'intervenir dans diverses activités toujours dans un même souci d'efficacité et de réactivité. La société est composée de dix salariés :

- Eric Binetruy : directeur de la société / commercial. - Julien Brugger : chef de studio / concepteur / développeur. - Mohand Ait-Hatrit, Aurélien Cametti et Paul Dubois : développeurs /

intégrateurs. - Adrien Perret, Damien Roch et Aurélien Seguin : chefs de projet /

analystes / concepteurs / développeurs. - Laurent Bole : création graphique, illustrations. - Anne-Marie Santiago : comptable administrative.



1.2. Présentation du sujet

Afin d’être plus précis et dans le but de parfaitement situer mon travail, il faut

savoir que ce stage se décompose en deux sujets. Le premier est le sujet de base, sur lequel je devais normalement travailler et qui à été mis en « pause » afin de passer sur un sujet plus urgent et plus important. C'est sur ce second sujet que j’ai passé le plus clair de mon temps durant ces seize semaines de stages.

Sujet de base

Lors de mon arrivée à VT-Design, mon sujet principal qui avait été défini lors

de l’entretien était la réalisation d’une GED (Gestionnaire Electronique de Documents) pour la dernière version de leur plateforme de travail collaboratif.

Etant donné que le module actuel (développé pour la version 2 du Framework)

est devenu obsolète, il était obligatoire pour l’entreprise de développer un nouveau module répondant aux besoins des clients. Il ne s’agissait pas de repartir de l’existant mais de l’oublier complètement et de débuter par l’étude des besoins.

Je vous parlerai plus précisément par la suite des quelques travaux que j’ai eu

le temps d’effectuer sur ce sujet avant d’être réorienté vers un nouveau sujet.

Nouveau sujet

Quelques temps après avoir commencé l’analyse de la réalisation de la GED

pour la version 3 de leur plateforme de travail collaboratif, mon tuteur de stage est venu me voir pour parler d’un autre sujet de développement qui serait plus important et plus urgent que la GED.

Etant donné que mon adaptation à leur environnement de développement et à

leur Framework se passait plutôt bien, ils ont décidé de me confier la réalisation de la partie « sécurité & authentification » pour la toute dernière version de leur plateforme. C'est-à-dire la gestion des connections mais aussi la gestion de tout ce qui pourrait posséder une restriction d’accès (peut importe « qui » demande l’accès et peu importe « sur quoi » l’accès est demandé) sur les sites ou les applications Web qui seront développées par la suite. De plus, tout cela doit être réalisé sous forme de « plug-in » afin que celui-ci puisse s’intégrer dans n’importe quel projet au bon vouloir du développeur car tous les projets ne nécessitent pas forcement une gestion de droits.

Ce sujet était d’autant plus important et urgent que le premier car la GED allait

avoir besoin d’un système de gestion de droits très précis afin de gérer facilement « qui » et « sur quoi » chaque utilisateur de la GED aurait accès; ce que le Framework actuel de VT-Design ne permettait pas.

Je vais maintenant vous parler de mon adaptation et mon intégration dans

l’entreprise VT-Design.



2. Adaptation et mise en situation

Avant de vous rendre compte du travail que j’ai réalisé dans le cadre de ce stage de fin d’études pour la société VT-Design, je vais vous parler de mon intégration au sein de l'entreprise et vous présenter un peu plus l’outil et le lieu de travail sur lequel j’ai effectué mon stage.

2.1. Environnement de travail

L’Entreprise

L'intégration dans l'entreprise s'est très bien passée. L'ambiance y est très conviviale. L’espace de travail est un « open-space » ce qui facilite grandement la communication entre tous les développeurs, que celle-ci soit en rapport avec le travail ou non.

Du point de vue de mon espace de travail, j’ai été logé à la même enseigne

que tous les autres développeurs. Les espaces de travail son formés par des bureaux regroupés 4 par 4. On obtient donc des groupes de 4 développeurs répartis plus ou moins par spécialité. J’ai donc été placé dans la partie « recherche et développement » de VT-Design.

Afin d’organiser et de planifier le travail de la semaine, une réunion a lieu tous

les lundis matin, où chacun fait l’état d’avancement de son projet et planifie dans la semaine les prochaines tâches à effectuer.

Chaque développeur possède un espace de développement spécifique sur le serveur de développement de VT-Design appelé « vtdave », ceci afin d’éviter tout problème de bug/crash/compatibilité sur des versions en ligne de projets lors des phases de développement. Chaque projet possède donc sa version « DEV » et sa version « PROD ». De plus, chaque réalisation de projet peut être amenée à être développée par plusieurs personnes en même temps. VT-Design utilise donc un serveur SVN afin de pouvoir gérer facilement le partage et le regroupement de données. La plateforme de travail collaboratif étant potentiellement amenée à être utilisée en dehors de la France, le développement et les commentaires de code devaient être obligatoirement réalisés en Anglais afin que tout cela puisse être lisible par un maximum de personnes.

Matériels et Logiciels

A mon arrivée dans l’entreprise, j’ai tout de suite eu à disposition un

environnement complet de développement. C'est-à-dire un PC sous Windows XP avec connexion internet ainsi que la plupart des logiciels par défaut présents sur un ordinateur. Mon maître de stage m’a quand même proposé de formater le PC si je le



souhaitais et d’installer dessus l’OS que je voulais afin que je travaille dans les conditions de mon choix. Etant familier du développement sous Windows XP, j’ai préféré garder l’OS actuel et réinstaller par-dessus tous les logicielles avec lesquels j’avais l’habitude de développer. (Eclipse, NotePad++, FileZilla, Putty, TortoiseSVN, etc.…)

Après quelques jours d’adaptation, j’ai pu constater que la plupart des

développeurs chez VT-Design utilisaient comme IDE (Integrated Development Environment) NetBeans plutôt que Eclipse. Après discussion avec eux, ils m’ont expliqué que celui-ci était plus adapté pour le développement en PHP. De plus, le plugin de gestion SVN de NetBeans était bien plus facile d’utilisation que le Plugin SVN d’Eclipse. Après avoir essayé les deux IDE en phase de développement, je me suis rendu compte qu’ils avaient raison et je suis donc passé sous NetBeans à mon tour.

Par la suite, j’ai aussi du installer un logiciel (Visual Paradigm) permettant de

représenter de manière simple et facile n’importe quels types de diagrammes UML (dans mon cas, diagrammes de classes, diagrammes de séquences, diagrammes d'activités et diagramme d'entité-relation) permettant l’analyse d’un projet. Ne connaissant pas du tout ce logiciel, j’ai pu bénéficier de l’aide de mon maître de stage pour me guider lors de mes premiers essais. Celui-ci se prenant très facilement en main, j’ai pu rapidement devenir autonome. L’avantage de ce logiciel est qu’il intègre de base une gestion SVN ce qui permet un partage très facile des diagrammes réalisés.

Une « Debug-bar » (implémenté en JavaScript) est aussi fourni par le

Framework de VT-Design et est utilisable pour chaque application ou site développé à partir de la plateforme de travail collaboratif. Celle-ci regroupe toutes les informations qui transitent entre le client et le serveur lorsque celui-ci effectue une requête. Cette « Debug-bar » m’aura été vraiment très utile tout au long de mon stage d’autant plus qu’elle fournit un système de « trace » afin de pouvoir afficher très facilement tout ce que l’on veut durant l’exécution des phases de tests pour vérifier que ce que l’on développe fonctionne bien.

Voilà pour mon environnement de travail, je vais maintenant vous parler des

nouveaux concepts et des nouvelles notions que j’ai dû apprendre à maîtriser durant mon stage, en particulier, le Framework PHP "VT-Application Suite" (Version 3) développé par VT-Design et sur lequel tout mon stage à été consacré.



2.2. Les nouveaux concepts et notions

Le Framework

Un Framework est un ensemble d'outils et de composants qui aident au

développement d'application, pour un contexte donné. Par définition, il est structurant pour l'application, c'est à dire qu'une application développée pour un tel Framework n'est pas aisément transposable sur un autre. Plus simplement nous pouvons dire qu’il s’agit d’un ensemble de bibliothèques et de conventions permettant le développement rapide d'applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et facile à maintenir. Ces composants sont organisés pour être utilisés en interaction les uns avec les autres.

Le modèle MVC

Le Modèle-Vue-Contrôleur (en abrégé MVC, de l’anglais Model-View-

Controller) est une architecture et une méthode de conception qui organise l'Interface Homme-Machine (IHM) d'une application logicielle. Cela permet d'avoir non seulement des objets réutilisables pour d'autres applications, mais aussi de pouvoir faire évoluer aisément une application ; par exemple, si l'on souhaite modifier la base de données il suffit de revoir simplement le modèle. Le modèle MVC utilisé dans les architecture de développement Web est appelé MVC Model 2. (Cf. Figure 1) Les trois parties autonomes sont :

- Un modèle (modèle de données) : il représente les données de l'application mais également l'interaction avec la base de données et le traitement de ces données.

- Une vue (présentation, interface utilisateur) : elle représente l'interface utilisateur, (les interactions). Elle n'effectue aucun traitement, elle se contente simplement d'afficher les données que lui fournit le modèle.

- Un contrôleur (logique de contrôle, gestion des événements, synchronisation) : il gère l'interface entre le modèle et le client. Il va interpréter la requête de ce dernier pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle et les vues.



Figure 1 : Interaction dans un Model MVC : Model, View, Controller

Les Design Patterns

Les design patterns sont des architectures de classes permettant d'apporter une solution à des problèmes fréquemment rencontrés lors des phases d'analyse et de conception d'applications. Ces solutions sont facilement adaptables (donc réutilisables), elles sont utilisables dans la grande majorité des langages de programmation orientés objet et très utilisés dans les services que fourni un Framework.

ORM et CRUD

Un autre concept très utilisé par les Framework est les ORM (Object Relational Mapper) pour PHP. Il établit une correspondance entre les lignes d'une base de données et les objets créés dans un script PHP. Un ORM assure l'abstraction de la base de données, en fournissant des objets, indépendamment de celle-ci, pour améliorer la réutilisation de code. Il permet de simplifier l'accès aux données, tout se fait au moyen de classes dans le code PHP. Le CRUD (Create, Read, Update et Delete) quant à lui est le résultat de l’implémentation d’un ORM. On obtient donc très facilement une gestion générique de n’importe quelles données stockées en BDD.



Dojo : Framework JavaScript

Lorsque l’on développe des sites ou des applications web, on est forcément

amené à devoir utiliser le langage JavaScript. Dojo est un Framework en JavaScript. Son but est le développement rapide d'applications exécutées côté client et communiquant avec le serveur avec une granularité inférieure à la page grâce à Ajax. Les fonctionnalités les plus notables de Dojo sont :

- Un système évènementiel pour l'exécution des évènements DOM (Document Object Model) mais aussi pour des évènements arbitraires tels que les appels à une fonction particulière.

- Un système de widgets qui permet la création de composants réutilisables complexes, et propose de nombreux widgets préfabriqués (par exemple, un sélectionneur de dates fondé sur un calendrier, et un éditeur de texte riche).

- Une bibliothèque d'animations, incluant à la fois des effets d'animation préconstruits et des possibilités de construire soi-même des effets.

- Une bibliothèque d'utilitaires de manipulation du DOM. Nous allons maintenant voir quelles sont les caractéristiques du Framework

développé par VT-Design.

2.3. La plateforme de travail collaboratif « VT-Application Suite »

VT-Design développe et commercialise une plateforme de travail collaboratif « VT-Application Suite » dont le développement a été fait sur la base d’un Framework. C’est ce dernier qui est l’acteur majeur de mon sujet de stage.

Versions et évolutions

Pour répondre aux attentes des clients, VT-Design a développé, dès 2001, sa propre suite de travail collaboratif nommée VT-Modules. Cette application, comme son nom l’indique, était organisée en modules tels que le module de gestion d’actualités, de contenu, de projets, de produits, etc. Celle-ci était développée en PHP 4 associé à une base de données MySQL. Elle présentait ainsi comme principal avantage d’être utilisable via un navigateur Internet et de ne pas nécessiter d’achat de licence. De plus, sa structure modulaire lui conférait une grande souplesse puisqu’elle permettait d’une part de n’installer et configurer que les modules nécessaires aux besoins du client et, d’autre part, de pouvoir apporter des modifications ou évolutions à un module sans perturber le fonctionnement des autres. Après réflexion, les développeurs de VT-Design ont convenu de la nécessité de créer une nouvelle version de leur application VT-Modules, qui en étendrait les fonctionnalités par l’ajout de nouveaux outils. C'est donc en 2005 que le projet VT-Oolkit a démarré, suite à ces nouveaux besoins, avec un nouveau langage : PHP 5 qui intègre la notion du développement orienté objet.

Lors de ces dernières années, VT-Oolkit a su combler les attentes d’un grand nombre de clients. Mais, ces derniers deviennent de plus en plus exigeants en



exprimant la volonté d’utiliser des outils induisant la notion d’espaces collaboratifs multiples sur la même plateforme : permettre le « multi extranet » sur le même outil, par le biais d’espaces collaboratifs distincts, publics ou privés. VT-Oolkit a donc été repensée par l’équipe et en est maintenant à sa troisième version appelée « VT-Application Suite » qui intègre une refonte complète des fonctionnalités, et propose également de nouveaux concepts.

Fonctionnalités

Voici quelques-unes des différentes fonctionnalités manipulées par cette

nouvelle version de la plateforme collaborative.

A chaque fois que l'utilisateur exécute une requête HTTP sur une application basée sur le Framework, ce dernier convertit la requête sous la forme d'un objet WebRequest. Cet objet permet de récupérer les données en entrée envoyées par le client grâce à la méthode GET ou POST, telles que des données de formulaires, des fichiers envoyés, et les paramètres permettant de déterminer le module et l'action à exécuter.

Un objet Response représente la couche vue du modèle MVC et est chargée

de générer la réponse à renvoyer à l'utilisateur correspondant à sa requête : page HTML, fichier PDF, etc. Le Framework fournit en standard un certain nombre d'objet Response pour renvoyer aux navigateurs des contenus dans des formats courants.

Les filtres d'exécution permettent d'automatiser un traitement à appliquer à une action ou un ensemble d'action. Ils peuvent être utilisés pour la sécurité, loguer les actions, calculer le temps d'exécution, etc.

Certaines classes du Framework notifient un événement à différents moments de leur vie. Ensuite, il est possible de faire quelque chose de spécifique au moment où l'événement est déclenché. Pour cela, il faut enregistrer un objet chargé d’observer, et qui s'exécute lorsque l'événement est notifié. Il s’agit du pattern Observer : des observateurs.

Certaines modifications du modèle sont génériques et peuvent être réutilisées, comme des méthodes permettant le tri d'objets et optimisant le verrouillage prévenant ainsi la collision d'objets. Il s'agit alors d’extensions génériques pouvant être ajoutés à une multitude de classes. Ces extensions sont regroupées dans des Behaviors qui sont alors considérés comme des classes externes. Les Behaviors sont plus ou moins une façon de greffer des comportements ou des fonctionnalités à des modèles (couche d’accès aux données) et de les partager entre eux.

Un des nouveaux concepts de la troisième version du Framework est notamment l’utilisation de Doctrine. Il s’agit d’un ORM pour PHP très évolué. Doctrine s’occupe de gérer tout ce qui est en rapport avec le stockage des données et leurs réutilisations, en fournissant des objets, indépendamment de la base de donnés, qui sont créés grâce à un langage de sérialisation (YAML). Il propose aussi son propre langage de requête SQL appelé DQL, pour améliorer la réutilisation de code.



VT-Design a choisi une nouvelle manière d’aborder la création de projets et

d’applications depuis peu de temps. Il souhaite que chaque projet soit indépendant mais que les différentes applications/modules que ceux-ci possèdent et qui ont les mêmes utilités restent communes. C'est-à-dire que chaque projet posséderait une partie indépendante et une partie commune. L’avantage de ce fonctionnement est que la partie commune serai stockée en dehors de chaque projet sous forme de « plug-in » et que les évolutions de celle-ci seraient automatiquement répercutées sur tous les projets ce qui éviterait de devoir les faire évoluer un par un. (Cf. Figure 2)

Figure 2 : Représentation schématique d’une application utilisant « VT-Application Suite »

Ma formation à « VT-Application Suite » (versions 3) ainsi qu’à tous les autres

concepts et notions manipulés par cette plateforme de travail collaboratif a été longue (quasiment 1 mois) mais nécessaire car il s’agit d’un outil complexe avec de multiples possibilités. Je vais maintenant vous présenter mon travail réalisé au sein de VT-Design.



3. Déroulement du stage

3.1. Module de gestion électronique de documents

Le premier sujet, pour lequel était prévu mon stage, consistait à l’analyse, la

conception et le développement d’un module de gestion électronique de documents (GED) pour la dernière version de la plateforme collaboratif de VT-Design. Celle-ci possédait déjà, dans ses versions antérieures, un tel module mais qui n’est plus compatible avec la version actuelle de « VT-Application Suite ». Compte-tenue du fait que la troisième version va être utilisée dorénavant et que ce module ne répond plus aux demandes des clients et aux contraintes techniques (Sécurité, partage, etc.), une refonte était obligatoire. Afin de partir sur des bases solides, il était décidé de repartir de zéro, de ne pas s’inspirer de la version existante et de commencer par l’étude des besoins en analysant les outils existants, les règles et conditions à respecter pour les GED et pour finir l’établissement du cahier des charges.

Etudes des besoins

Afin de déterminer les besoins exactes et connaître les outils existants pour en

tirer le meilleur, j’ai analysé les différentes solutions déjà disponibles sur Internet. J’ai tout d’abord effectué une approche générale des notions sous-jacentes à la gestion documentaire puis listé les grandes fonctions (et leurs enjeux) attendues dans ce type de projet.

Etablissement des principales fonctionnalités attendues

Les « métadonnées » : Elles permettront l’indexation. C’est une fonction centrale des outils de GED,

elle consiste en premier lieu à attacher des métadonnées aux documents. Chaque type de document peut être qualifié par un ensemble de métadonnées et être associé éventuellement à des règles de gestion particulières, s’appuyant sur ces métadonnées. Un schéma générique appelé « DUBLIN CORE » liste les différentes informations permettant de décrire des ressources numériques sous forme de métadonnées.

La gestion des versions d’un document : C’est l’un des domaines où la GED apporte un bénéfice important. En effet,

dans un contexte de travail en groupe, qui plus est avec des échanges d’emails multiples, il devient rapidement complexe de connaître avec certitude la dernière version d’un document. La gestion des versions permet à la fois de tracer les évolutions d’un document et, par un système de réservation (le check-in/check-out), de garantir qu’un utilisateur peut prendre la main sur un document et le modifier dans la base documentaire sans qu’il n’y ait de modification concurrente, simultanée.



Le moteur de recherche : C’est une brique essentielle des applications de gestion d’information, les

moteurs de recherche associés aux solutions de GED présentent comme caractéristique principale de pouvoir faire des recherches sur le contenu de la base documentaire. Ces principales fonctionnalités devront être de :

- Indexer les fiches documentaires, c'est-à-dire toutes les métadonnées ou la fiche d'un document.

- Indexer les documents électroniques en texte intégral (ou « full text »), c’est à dire en prenant en compte le contenu des documents pour tous ceux qui incluent du contenu textuel.

- Permettre les recherches utilisant plusieurs critères associés avec des opérateurs booléens (ET, OU, SAUF), ainsi que des parenthèses.

- Autoriser les troncatures centrales et à droite, c'est-à-dire l’utilisation de caractères génériques pour remplacer un ou plusieurs caractères quelconques (classiquement l’étoile « * » ou le « ? ») en milieu et en fin la chaîne de caractère qui sert à la recherche.

La gestion des droits : Dans la GED comme dans une majorité d’applications de gestion susceptibles

d’avoir une diversité d’utilisateurs, la gestion des droits est une fonctionnalité très importante. La gestion des droits des utilisateurs par rapport à l’application passe par l’association d’autorisations sur des sous-ensembles définis de la base documentaire souvent des répertoires ou des arborescences. Ces associations doivent pouvoir être réalisées par groupes ou individuellement.

L’importation de documents : Idéalement, l’import devrait permettre d’intégrer plusieurs documents au moment de « l’upload » et de leur affecter des métadonnées en lot.

Réflexion sur la réalisation des fonctionnalités

Comme vous pouvez le constater, la réalisation d’une GED demande un

grand nombre de fonctionnalités assez complexes. Une partie de ces fonctionnalités sont déjà présentes dans le Framework de VT-Design mais deux problèmes nous empêchent de les utiliser. D’une part, ces fonctionnalités ne sont pas compatibles avec la dernière version du Framework et d’autre part, certaines ne sont pas assez évoluées pour gérer complètement les besoins listés pour chacune des fonctionnalités.

Après en avoir discuté avec mon maître de stage, nous avons conclu qu’une

fonctionnalité importante devait être développée en priorité car utile dans la plupart des sites et des applications qui seront développés par la suite. Il s’agit de la gestion des droits d’accès associée à une partie d’authentification.

Mon sujet de stage à donc été mis pour un moment de coté afin que je puisse

m’occuper de réaliser la gestion des authentifications et des droits d’accès.



3.2. Plug-in de gestion de droits d’accès et d’authentification

La gestion de droits d’accès est une chose que l’on retrouve un peu partout en informatique. Dans certains cas, elle est très simple à mettre en place, lorsqu’elle concerne quelque-chose de précis et donc sera développée en statique. Dans mon cas, celle-ci devait pouvoir s’adapter de manière dynamique à n’importe quels sites ou applications qui utiliseraient « VT-Application Suite » ce qui allait rendre la tâche beaucoup plus difficile.

Etudes des besoins et de l’existant

En parallèle des réunions que j’avais avec mon maître de stage pour établir

précisément ce que devrait fournir le futur gestionnaire de droits, je devais aussi regarder les différentes solutions que les autres Framework PHP avaient choisi de mettre en place pour leur gestion de droits. Après avoir effectué mes recherches et plusieurs réunions avec mon maître de stage, et après avoir vu comment cette gestion était effectuée actuellement dans VT-Oolkit, nous en sommes arrivés aux conclusions suivantes :

D’une part, l’implémentation actuelle ne permet pas la gestion fine des droits. C'est-à-dire qu’elle ne permet pas de gérer une par une chaque ressource qui peut être extraite de la base de données mais gère cela de façon générique, sous forme de droit globaux. On peut par exemple empêcher quelqu’un de voir la liste d’un type de ressource, mais on ne peut pas l’empêcher de voir une ressource précise.

Conclusion : Il faudra donc dans la nouvelle version que l’on puisse gérer les droits d’accès jusqu'à la plus petite granularité. Mais aussi, pouvoir les gérer de façon globale lorsqu’ils ne concerneront pas une donnée.

D’autre part, l’attribution des droits est complètement statique. Elle respecte le

schéma suivant : Attribution de droits pour des espaces puis pour des groupes et enfin pour des utilisateurs. Peut importe si l’application n’a pas besoin de gestion d’espace et de groupe, on devra quand même respecter ce schéma là. Il n’y a donc aucun moyen de rendre prioritaire les droits suivant sur qui ils sont attribués.

Conclusion : Il faudra d’une part pouvoir gérer dynamiquement sur qui sont attribués les droits. C'est-à-dire que chaque application/site pourra avoir une architecture d’espaces/groupes/utilisateurs différente et il faudra aussi pouvoir préciser l’ordre de priorité en fonction de ces architectures.

De plus, elle ne permet pas non plus la gestion de droits complexes. Comme

par exemple, de donner le droit de suppression d’une ressource uniquement au propriétaire de la ressource.

Conclusion : Il faudra ajouter une fonctionnalité pour pouvoir gérer facilement des cas spécifiques de tests comme « qui est le propriétaire de la donnée ? »



Pour finir, elle ne permet pas aux futurs utilisateurs de l’application de gérer eux-mêmes les droits d’accès sur telle ou telle chose. Etant donné que tout est fait de manière statique, il n’est pas possible de modifier facilement des droits.

Conclusion : Un module d’ajout de droits d’accès devra pouvoir se greffer facilement aux différents modules de création de données que possèdera le site ou l’application.

On obtient donc 5 fonctionnalités à implémenter en complément d’une gestion basique de droits :

- Attribution de droits sur la plus petite granularité - Attribution de droits peu importe le type de gestion des utilisateurs - Gestions des priorités entre les droits en fonction de « qui » les

possède. - Attribution de droits complexes - Permettre aux futurs utilisateurs de gérer eux-mêmes les droits sur les

données qu’ils créeront.

Etant donné que la gestion des droits fournis par VT-Oolkit n’est pas du tout adaptée pour les différentes fonctionnalités listées ci-dessus, une refonte complète du système de droits sera beaucoup plus facile à réaliser plutôt qu’une adaptation qui serait peut être même impossible ou bien trop compliquée.

Cahier des charges

Durant l’analyse des gestions de droits déjà existante, à plusieurs reprises, le

mot « ACL » est apparu. « ACL » voulant dire « Access Control Lists ». Elles sont une façon de gérer les permissions d'une application d'une manière très précise et pourtant facilement maintenable et manipulable.

Gérer les droits de manière générique :

Les listes de contrôles d'accès, ou ACL, manipulent deux concepts principaux. Les demandeurs qui veulent accéder à des éléments et les éléments auxquels on cherche à accéder. Dans le jargon ACL, les demandeurs qui veulent accéder à des éléments (le plus souvent des utilisateurs) sont appelées « Access Request Objects » ou ARO. Les éléments du système auxquels on veut accéder (le plus souvent des actions ou des données) sont appelées « Access Control Objects » ou ACO. Les entités sont appelées « objets », car le demandeur n'est pas forcément une personne.

Généralement, les ACL sont utilisés pour décider quand un ARO peut obtenir

l'accès à un ACO. Afin de vous aider à comprendre comment toutes ces choses fonctionnent ensemble, voici un exemple simple :

Le chef d’un groupe, veut gérer les biens du groupe, tout en maintenant un

bon niveau de confidentialité et de sécurité entre les autres membres de l'équipe.



La première chose dont il a besoin est de créer une liste d'ARO qui comprendrait par exemple :

- Chef-1 - Lieutenant-1 - Lieutenant-2 - Lieutenant-3 - Soldat-1 - Soldat-2 - Soldat-3 - Soldat-4 - Esclave-1 L’étape suivante est de créer une liste initiale des choses, ou ACO, que le

système va contrôler. La liste pourrait ressembler à quelque-chose comme ça : - Les armes - La nourriture - La diplomatie - La bière Gérer les droits en masse : Traditionnellement, les systèmes de gestion de droits étaient gérés en utilisant

une sorte de matrice, qui présentait un ensemble basique d'utilisateurs et de permissions en relation avec les objets. Si ces informations étaient stockées dans un tableau, il ressemblerait à une matrice de taille (« nb_utilisateurs » x « nb_choses »). Dans notre cas, on obtient une matrice de 9 par 4. Mais dans des applications web, on peut très vite obtenir un très grand nombre d’utilisateurs et de choses à contrôler ce qui donnerait une matrice énorme et prendrait un temps fou pour retrouver un droit dedans.

Pour contrer cela, les ACL sont implémentés de façon à être considérés comme une structure en arbre, mais ne seront pas stockés pour autant sous forme d’arbre en base de données afin de permettre la présence de « branches manquantes » dans l’arbre. Il y a généralement un arbre d'ARO et un arbre d'ACO. En organisant vos objets en arbres, les permissions peuvent toujours être distribuées d'une façon granulaire, tout en maintenant encore une bonne cohérence de l'ensemble. On pourrait donc représenter notre exemple de la manière suivante :

Tout le monde (Refuser : tout) o Chef (Autoriser : tout)

Chef-1 o Lieutenant (Autoriser : Armes, Bière, Nourriture)

Lieutenant-1 Lieutenant-2 Lieutenant-3

o Soldat (Autoriser : Armes, Nourriture) Soldat-1 Soldat-2 Soldat-3 (Autoriser : Bière) Soldat-4

o Esclave (Autoriser : Nourriture) Esclave-1



Vous constaterez que de cette manière, on attribue facilement des droits à

des ensembles, mais aussi à des entités bien précises. Nous avons donc décidé, mon maître de stage et moi-même, que ce serait de cette façon que nous allons intégrer la gestion de droits dans la plateforme de travail collaboratif. En pensant bien sur que tout cela devra être sous forme de « plug-in ».

Analyse

Afin de visualiser au mieux comment mon travail allait s’intégrer au

Framework existant, une analyse sous forme de différents diagrammes semblait obligatoire.

Abstraction et relation entre les entités :

Comme je l’ai déjà précisé, le plugin que je dois réaliser devra s’intégrer au Framework déjà existant sans pour autant y être indispensable. J’ai donc commencé à me poser des questions sur la manière dont tout cela allait être mis en place. La première des difficultés fut déjà d’établir de quel manière les ACL allaient être managés et comment ceux-ci allaient être architecturés afin de pouvoir fonctionner de la manière la plus polyvalente possible.

D’une part, il fallait que les ACL puissent s’adapter a tout type de projet. C'est-à-dire, à des projets qui possèdent une base de données comme à des projets qui n’en possèdent pas. D’autre part, il fallait que les ACL fonctionnent, peu importe le type de base de données fourni. (MySQL, Oracle, Postgresql, etc.)

Pour cela, je me suis tourné vers les différents types de Design Patterns afin de trouver le meilleur d'entres-eux à même de fournir ce modèle d’architecture. Le problème, est que certains patterns se ressemblent beaucoup, et même après, avoir lu un livre spécialement dédié à ceux-ci, je n’étais pas encore en mesure de savoir précisément quel pattern je devais utiliser. Mon maître de stage m’a alors expliqué que souvent, les même Design Patterns n’étaient pas forcément définis ni expliqués de la même manière en fonction du livre ou du site internet lu. Il ne fallait donc pas se baser uniquement sur un nom de pattern en particulier, mais reprendre plutôt le concept général de celui qui se rapprocherait le plus du résultat attendu.



Au final, c’est le Design Pattern « Adapter » (appeler parfois « Bridge ») qui à été retenu. Il permet de faire le lien entre une partie statique que nous allons appeler « AclManager » défini comme abstraite et une partie dynamique, qui permet d’implémenter de différentes manières le fonctionnement général qui sera utilisé par la partie abstraite. (Cf. Figure 3)

Figure 3 : Diagramme de classe, le gestionnaire d’ACL

Dans le même genre, il fallait aussi que le système d’authentification puisse s’adapter a n’importe quel type de système de stockage des « identifiants & mots de passes », du plus classique en BDD, en passant par les systèmes LDAP, jusqu’aux system de stockage dans des fichiers. Nous avons donc repris le même principe du Design pattern « Adapter » appliqué cette fois à ce système (Cf. Figure 4)



Figure 4 : Diagramme de classe, le système d’authentification La 2eme étape consistait à trouver comment pouvoir adapter le plus

facilement possible les ARO et ACO à n’importe quels types de données. La solution la plus simple a consisté à faire deux interfaces, une pour les ACO et une pour les ARO. Chaque classe qui représentera un objet pouvant recevoir des restrictions d’accès devra implémenter l’interface ACO et chaque classe qui représentera un objet pouvant demander un accès devra implémenter l’interface ARO. (Cf. Figure 5)



Figure 5 : Diagramme de classe, Les interface ARO et ACO et leur Listener De plus, afin de gérer les interactions de toutes ces classes avec le système de stockage, un « Listener » pour les ajouts et les suppressions de ces éléments a été mis en place dans le but d’éviter tout conflit ou erreur. (Cf. Figure 5) Une autre étape a consisté en la surcharge de la classe « User » (Cf. Figure 4) car de base, elle n’à pas de système de gestion d’authentification, ni de système de gestion de droits. Le Framework développé par VT-Design permet de réaliser cela assez facilement. Il, suffit d’étendre la classe de base, et grâce à un système de fichier de configuration, le « Core » du Framework s’adaptera automatiquement au type d’utilisateur en fonction des paramètres stipulés dans la config du plugin. (Vous pouvez retrouverer en Annexe 1, le diagramme de classe complet que j’ai réalisé pour représenter mon plug-in.)

Modélisation des processus :

Maintenant que les bases étaient établis, il fallait que je décide comment allait fonctionner les priorités entre les ACL car une demande de droit peut avoir plusieurs ACL correspondants et donc il faudra uniquement retenir le plus prioritaire. Pour cela, j’ai décidé de réaliser un diagramme d’activité afin de m’y retrouver dans toutes les différentes possibilités d’attributions de droits. La figure 6 vous montre l’ordre de priorité retenu.



Figure 6 : Diagramme d'activités, Priorité entre les différents ACL

Comme vous pouvez le voir dans la figure 6, il existe 3 types d’ACL possible : - Les ACL concernant uniquement un « Grant » et qui sont donc

applicables à n’importe quoi. (Exemple : le « Grant » « SendMail » qui donne accès a un formulaire d’envoie de mail uniquement aux utilisateurs qui possèdent ce « Grant ».

- Les ACL concernant un « Grant » et un type d’ACO. C'est-à-dire un « Grant » qui s’applique à tout un type de ressources. (Exemple : le « Grant » lire pour toutes les ressources de type « Newsletter ».



- Les ACL concernant un « Grant » et un ACO précis. C'est-à-dire un « Grant » sur une ressource en particulier. (Exemple : Le « Grant » supprimé sur une Newsletter particulière.

Bien sûr, tous ces ACL sont applicables sur n’importe quel type d’ARO, que ce

soit un utilisateur, un groupe, etc. L’ordre de priorité entre les ARO étant fixé par le développeur, ils n’interviennent pas dans l’ordre de priorité des ACL. Ils se surchargeront juste entre eux.

Un autre processus, consistait à établir la relation entre le système

d’authentification et le système de gestion de droits. Les 2 systèmes fonctionnant de concert, il fallait que je crée un lien entre eux. (Cf. Figure 7)

Le Framework me fournissait de base un système de redirection, je n’ai donc

eu qu’à implémenter deux méthodes de « check » différentes dans l’AclManager. L’une ne retourne qu’un booléen qui précise si le demandeur a l’autorisation ou pas et ce sera au développeur de gérer ce qu’il souhaite faire en fonction du résultat. La deuxième ne retourne rien, mais par contre, elle effectue une redirection dans le cas où le demandeur n’a pas les droits suffisants pour sa requête.

Suivant si le demandeur est déjà authentifié ou pas, la redirection ne s’effectue pas au même endroit.

- Dans le cas où le demandeur n’est pas identifié, la redirection se fait sur le système d’authentification en gardant bien sûr tous les paramètres de la requête. Si l’utilisateur réussi son authentification, il sera alors à nouveau redirigé vers sa requête principale. Sinon, un message d’erreur lui notifie le problème rencontré.

- Si l’utilisateur est déjà identifié, alors il ne peut pas posséder plus de droits, la redirection s’effectue donc sur une page l’informant qu’il ne possède pas le droit nécessaire pour sa demande.



Figure 7 : Diagramme d'activités, interaction entre le système de droits et le système

d’authentification

Représentation : Le système de stockage des ACL allait être assez simple. Il suffisait de créer

quatre entités. Une pour stocker les ARO, une pour les ACO, une pour les GRANT et enfin, une pour les ACL puis faire les liens entre-elles. (Cf. figure 8)



Figure 8 : Diagramme entité-relation, Gestion des droits

Tout un système de module de gestions de ces différentes entités devait donc être implémenté afin de pouvoir ajouter, supprimer et éditer (autrement dit administrer) tout cela facilement. Pour finir, le plugin devait fournir de base un système de gestion d’utilisateurs et de groupes (rien de bien compliqué) afin de pouvoir s’intégrer à n’importe quels sites et être administrable directement tout en s’auto-protégeant car la gestion des droits ne doit pas être accessible à tout le monde.

Développement

Le système de plugin respecte une arborescence bien particulière qui ressemble un peu à l’arborescence d’une application. (Vous pouvez retrouver en annexe 2 l'arborescence complète du plug-in) Ce système d’arborescence est important à respecter car le plugin possède des fichiers de « config », de « schemas » et de « fixtures » qui seront utilise par l’application afin qu’elle puisse s’adapter et intégrer parfaitement le plugin.

Je ne vais pas m’étendre sur la partie technique qui serai bien trop compliquée à expliquer de façon claire sans intégrer des gros morceaux de code qui seraient illisible et au final ne serviraient à rien.



Ce que je peux dire, c’est que j’ai dû me remettre en question une bonne dizaine de fois durant tout le développement du plugin. Même après la grande partie d’analyse que j’avais pu réaliser avant de commencer à développer, j’ai pu me rendre compte de certains nouveaux problèmes et disfonctionnements dans les choix que j’avais faits uniquement au moment ou j’ai été face à eux. Les problèmes et disfonctionnements n’ont pas été les seuls à impliquer une grande refonte ou modification du fonctionnement de mon plug-in. Les problèmes de performance (nombre de requêtes à effectuer) et de quantité d’informations stockées en base de données ont aussi beaucoup joué en ce sens. Et malheureusement, on ne peut se rendre compte de cela qu’une fois que certains cas de tests ont été pensés ou réalisés. Le but final étant bien sûr de pouvoir réaliser les vérifications de droits d’accès en utilisant le moins de requêtes possibles en base de données et aussi d’éviter de devoir stocker un grand nombre de données pour gérer toutes les différentes restrictions et autorisations possibles que les utilisateurs seront amenés à instaurer. En parallèle de mon développement du plugin, mon maître de stage développait de nouvelles fonctionnalités pour le Framework. J’ai été amené aussi à effectuer quelques modifications et améliorations dessus ce qui m’a permis d’appréhender plus en profondeur son fonctionnement. Pour finir, je devais aussi rédiger tout une documentation pour l’utilisation de mon plugin, afin que celui-ci puisse être facilement utilisable par tous les membres de l’équipe. La rédaction du manuel d’utilisation se fait en ligne, sur un wiki collaboratif dédié à l’explication du fonctionnement et de l’utilisation du Framework développé par VT-Design. A l’heure actuelle, mon plugin est quasiment terminé. Du moins, sa version « Beta », et il est entrain d’être mis en place dans un projet en cours de développement. Je vais donc pouvoir migrer à nouveau vers mon premier sujet qui est la réalisation d’une GED étant donné que je continue mon stage chez VT-Design jusqu’aux mois d’Août.



Bilan

Apports à l’entreprise

Au cours de ce stage, j’ai pu réaliser le gestionnaire de droits d’accès et

d’authentification qui pourra être intégré, sous forme de plug-in, dans n’importe quel projet développé par la suite avec « VT Application Suite ».

Mon stage se poursuivant encore jusqu’en Août, je vais pouvoir repasser sur

la réalisation du gestionnaire électronique de documents, une fois que les tests de fonctionnement de mon plug-in seront terminés (et les erreurs/bugs corrigés si il y en a)

Les diverses autres mises à jour et créations réalisées pour le Framework de

VT-Design représentent le travail quotidien des développeurs présents dans l’entreprise. Ma présence a donc accéléré l’intégration des évolutions ponctuelles de « VT-Framework ».

Apports personnel

Il est bien évident que le travail en entreprise constitue un vrai changement

par rapport au travail effectué à l’université. Cette période de seize semaines de stage (pour le moment) a été très enrichissante autant au niveau professionnel qu’humain.

D’un point de vue humain, j’ai pu apprendre à travailler en groupe par les

interactions durant les phases d’analyses, réalisées avec mon maître de stage, pour chacune des différentes tâches qui m’ont été confiées. Cela m’a fait comprendre l’importance des mises au point et du partage d’avis ou de ressentie durant l’analyse car sans cela, il est quasiment impossible d’avoir au final une bonne qualité de produit.

D’un point de vue technique, ce stage a été une réussite. La découverte de

l’environnement de travail fût assez rapide puisque j’avais déjà été amené à travailler avec la plupart des logiciels, dans mon cursus universitaire ou lors de stages précédents, dont les principaux sont l’IDE NetBeans pour PHP (qui ressemble beaucoup à ECLIPSE), PHPMyAdmin et Subversion (SVN) pour le travail en équipe. Un point important durant mon stage fût la découverte et la compréhension des concepts utilisés par VT-Oolkit : le modèle MVC, les ORM avec Doctrine, la notion de modules et plugins, de Design Pattern, et bien sur, le développement en PHP orienté objet. En effet durant mes années de formation, je n'avais jamais travaillé à l’aide de ces derniers et j’ai donc pu apprendre de nouveaux concepts grâce à ce stage.



Conclusion Le bilan de mes seize semaines de stage est très satisfaisant, dans la mesure où le travail effectué ma enrichi tant sur le plan professionnel que personnel et que les objectifs définis avec mon maître de stage ont été atteints.

L'accueil de toute l'équipe, la bonne ambiance permanente, ainsi que la place qui m'a été réservée au sein de la société ont largement contribué à mon intégration rapide et au bon déroulement de mon stage. Je tiens à préciser que la réalisation des différentes tâches qui m'ont été confiées a réclamé une très grande phase de découverte des outils et du mode de développement de VT-Design tant l’architecture MVC, les Design Patterns, la notion de Framework et bien d’autres concepts m’étaient complètement étrangers. Il m’a fallu effectuer de nombreuses recherches en plus de lire toutes les documentations disponibles des différents outils et concepts utilisés dans le but de m’auto-former et d’en synthétiser le résultat afin de bien comprendre leur fonctionnement en prévision de leurs utilisations. Un grand changement que j'ai pu constater, comparé aux travaux réalisés à l'université, est la durée de l'analyse (réalisée avec mon maître de stage) que nécessitaient les tâches qui m'ont été confiées. Et même après ces longues phases d'analyse, il arrivait encore que je tombe sur des problèmes auxquels nous n'avions pas pensé, impliquant une modification du fonctionnement du plug-in durant son développement. Actuellement, le plug-in de gestion de droits d'accès et d'authentification est constitué de toutes les fonctionnalités nécessaires à son utilisation mais il reste quand même en version « Beta » pour le moment. Il faut maintenant le tester en « grandeur nature » en l'intégrant dans une application en cours de développement afin de s'assurer du bon fonctionnement et de la bonne intégration de celui-ci. C'est ce qui va être réalisé dans les semaines qui viennent. Ce stage n’aurait pas pu être plus intéressant, plaisant et bénéfique d'autant plus qu'il m’a vraiment fait prendre conscience des évolutions d’internet et des techniques de développement de dernière génération dans ce domaine. Je me suis donc trouvé dans des conditions idéales pour améliorer et valoriser le profil que je me suis forgé durant ces années d'études.



Bibliographie

VT Application Suite :

- VT Application Suite (documentation Wiki en intranet) - VT-Framework, Guide du développeur (DocBook en Intranet)

Design Patterns :

- http://www.fluffycat.com/PHP-Design-Patterns/ - Souplesse et modularité grâce aux Design Patterns (par P. Caboche) - Design patterns par la pratique (par A. Shalloway et J.R. Trott)

Framework PHP :

- http://www.symfony-project.org/ - http://jelix.org/ - http://framework.zend.com/ - http://bakery.cakephp.org/

Framework JavaScript :

- http://www.dojotoolkit.org/

ORM PHP :

- http://www.doctrine-project.org/projects/orm/1.2/docs/en PHP :

- http://php.developpez.com/ - http://www.phpindex.com/ - http://php.net/manual/fr/

Divers :

- http://fr.wikipedia.org

http://www.fluffycat.com/PHP-Design-Patterns/

http://www.symfony-project.org/

http://jelix.org/

http://framework.zend.com/

http://bakery.cakephp.org/

http://www.dojotoolkit.org/

http://www.doctrine-project.org/projects/orm/1.2/docs/en

http://php.developpez.com/

http://www.phpindex.com/

http://php.net/manual/fr/

http://fr.wikipedia.org/



Table des matières

Remerciement ............................................................................................................ 2 Sommaire ................................................................................................................... 3 Introduction ................................................................................................................. 4 1. Présentation du stage ............................................................................................. 5

1.1. Présentation de l’entreprise ............................................................................. 5 Historique ............................................................................................................ 5 Activité ................................................................................................................. 5 L'équipe ............................................................................................................... 6

1.2. Présentation du sujet ....................................................................................... 7 Sujet de base ...................................................................................................... 7 Nouveau sujet ..................................................................................................... 7

2. Adaptation et mise en situation ............................................................................... 8 2.1. Environnement de travail ................................................................................. 8

L’Entreprise ......................................................................................................... 8 Matériels et Logiciels ........................................................................................... 8

2.2. Les nouveaux concepts et notions ................................................................. 10 Le Framework ................................................................................................... 10 Le modèle MVC ................................................................................................. 10 Les Design Patterns .......................................................................................... 11 ORM et CRUD ................................................................................................... 11 Dojo : Framework JavaScript ............................................................................ 12

2.3. La plateforme de travail collaboratif « VT-Application Suite » ....................... 12 Versions et évolutions ....................................................................................... 12 Fonctionnalités .................................................................................................. 13

3. Déroulement du stage .......................................................................................... 15 3.1. Module de gestion électronique de documents .............................................. 15

Etudes des besoins ........................................................................................... 15 Etablissement des principales fonctionnalités attendues................................... 15 Réflexion sur la réalisation des fonctionnalités .................................................. 16

3.2. Plug-in de gestion de droits d’accès et d’authentification ............................... 17 Etudes des besoins et de l’existant ................................................................... 17 Cahier des charges ........................................................................................... 18 Analyse .............................................................................................................. 20 Développement ................................................................................................. 27

Bilan ......................................................................................................................... 29 Apports à l’entreprise ............................................................................................ 29 Apports personnel ................................................................................................. 29

Conclusion ................................................................................................................ 30 Bibliographie ............................................................................................................. 31 VT Application Suite : ............................................................................................... 31 Table des matières ................................................................................................... 32 Annexe 1 .................................................................................................................. 33 Annexe 2 .................................................................................................................. 34



Annexe 1

Diagramme de classe complet du plug-in de gestion d’accès et d’authentification



Annexe 2

Arborescence complet du plug-in de gestion d’accès et d’authentification

Résumé Faciliter la communication entre les individus, tel est l’objectif des solutions

collaboratives que propose VT-Design. L’utilisation de ces logiciels par ses clients permet d’améliorer leur communication, leur coopération, et leur coordination pour amener à plus de productivité. Basé sur les technologies web, ces solutions sont souples, performantes, et s’adaptent à tous les besoins.

Intégré dans une équipe de professionnels du web, pluridisciplinaire, j'ai pu

mettre en pratique et améliorer mes connaissances en développant de nouvelles fonctionnalités et plugins (en particulier un système de gestion de droits d'accès et d'authentification) pour la plateforme de travail collaboratif qui est en constante évolution.

Mots clés : PHP5, Framework, BDD, MVC, ORM, Doctrine, Design Pattern,

ACL, GED, SVN, UML.

Abstract Facilitate communication between individuals, is the goal of collaborative

solutions provided by VT-Design. Using this software allows its customers to improve their communication, cooperation, and coordination to bring in more productivity. Based on web technologies, these solutions are flexible, efficient, and adaptable to all needs.

Integrated in a team of web professionals, multidisciplinary, I was able to

practice and improve my knowledge by developing new features and plugins (as a managing access credentials and authentication system) for the collaborative platform which is constantly evolving.

Key words: PHP5, Framework, DB, MVC, ORM, Doctrine, Design Pattern,

ACL, GED, SVN, UML.