1. 1
DÉVELOPPEMENT FULL-STACK D'UNE
APPLICATION WEB TEMPS-RÉEL DE
GESTION D'AXES TEMPORELS
Master 2 Informatique Développement Logiciel
Hugues Odegaard
Année 2015-2016
Alternance effectuée du 14/09/2015 au 01/07/2016 au sein de DocDoku
Tuteur de stage universitaire : Mme Christelle CHAUDET
Maitre de stage : Yacine Merghoub

2. 2
Table des matières
Table des figures................................................................................................................................................4
Remerciements ..................................................................................................................................................5
Introduction........................................................................................................................................................6
Présentation du stage....................................................................................................................................... 7
DocDoku ......................................................................................................................................................... 7
Présentation du contexte...........................................................................................................................8
Timegene Web .........................................................................................................................................8
Environnement de travail......................................................................................................................9
Technologies et outils utilisés ..................................................................................................................... 10
JavaScript et ses bibliothèques............................................................................................................... 10
MongoDB...................................................................................................................................................... 10
AngularJS.......................................................................................................................................................11
Meteor............................................................................................................................................................ 12
Vis.js ................................................................................................................................................................13
Environnement de travail..........................................................................................................................13
Gestionnaire de versions ...........................................................................................................................13
Travail réalisé ....................................................................................................................................................15
Architecture Front-End de l’application..............................................................................................15
Intégration de Vis.js....................................................................................................................................17
Création d'une directive AngularJS...................................................................................................17
Modification de l'apparence de base.................................................................................................18
Problèmes rencontrés............................................................................................................................18
Axes numériques ........................................................................................................................................ 19
Relation Client .......................................................................................................................................20
Import d'axes standards et numériques .............................................................................................. 21

3. 3
Problèmes rencontrés...........................................................................................................................22
Autre tâches .................................................................................................................................................23
Placement des événements..................................................................................................................23
Performances...........................................................................................................................................23
Démarche méthodologique...........................................................................................................................25
SCRUM.........................................................................................................................................................25
Outils de gestion de projets.....................................................................................................................26
Redmine....................................................................................................................................................26
Trello .........................................................................................................................................................27
Tests ...............................................................................................................................................................27
Worflow Git ................................................................................................................................................28
Bilan.....................................................................................................................................................................30
Bilan de la mission......................................................................................................................................30
Bilan personnel............................................................................................................................................30
Conclusion .........................................................................................................................................................31
Lexique...............................................................................................................................................................32
Annexes..............................................................................................................................................................34

4. 4
Table des figures
Figure 1 : exemple d'axe temporel ................................................................................................................8
Figure 2 : Two-Way Data Binding..............................................................................................................11
Figure 3 : One-Way Data Binding ...............................................................................................................11
Figure 4 : interface utilisateur Timegene Web....................................................................................... 16
Figure 5 : architecture des parties principales de Timegene Web.................................................... 16
Figure 6 : apparence basique des axes temporels de Vis.js ..................................................................18
Figure 7 : exemple de série numérique (incomplète)............................................................................ 19
Figure 8 : série numérique après dé-zoome .............................................................................................20
Figure 9 : appel séquentiel de fonction asynchrone ..............................................................................22
Figure 10 : placement des événements en conflits .................................................................................23
Figure 11 : anomalies référencées sous Redmine.....................................................................................26
Figure 12 : liste des tâches par sprint sous Trello ..................................................................................27
Figure 13 : exemple de ficher de test ..........................................................................................................28
Figure 14 : état de routage à la base de l'architecture de Timegene Web .......................................34

5. 5
Remerciements
Tout d'abord je souhaite remercier M. Florent Garin, directeur technique et Mr Eric
Descargues, directeur de la relation client pour m'avoir permis d'effectuer mon alternance au
sein de leur entreprise.
J'exprime toute ma reconnaissance envers mon chef de projet M. Bertrand Boisvert pour son
humour et sa bonne humeur, ainsi que pour l'aide précieuse et les encouragements qu'il m'a
prodigués tout au long de mon stage.
Merci aussi à Lucas Bled et Guilhem Brouat pour leur bonne humeur et les conseils qu'ils
m'ont apporté.
Je remercie également l'ensemble des salariés de DocDoku pour avoir fait de mon année
d'alternant un réel plaisir.

6. 6
Introduction
Dans le cadre des mes études en Master en Informatique (Développement Logiciel) à
Toulouse, j'ai eu la possibilité d’effectuer ma dernière année en alternance du 15 septembre
2015 au 01 Juillet 2016 à Toulouse (31) au sein de DocDoku (créateurs de solution digitales
pour l'industrie).
Ayant travaillé sur le développement d’une application hybride dans le domaine du web à
l’aide du framework Cordova durant mon stage de M1, c’est tout naturellement que j’ai été
affecté à un projet utilisant les mêmes bases afin d’améliorer mes compétences dans ce
domaine.
J’ai ainsi eu l’occasion de travailler sur le projet Timegene Web au sein d’une équipe de quatre
personnes. J’ai eu le plaisir de participer activement à toutes les phases du développement de
l’application, du choix (difficile) des outils à la mise en production du produit en passant par
la phase de recette.
J’espère qu'à la suite de ces presque dix mois d’alternance j’aurai une vision claire du monde
professionnel, et ainsi être près pour entamer le début de ma vie active de la manière la plus
enrichissante possible.
Ce rapport est composé de quatre parties. La première présente l’application Timegene Web
et mon environnement de travail. La deuxième fait état des technologies utilisés pour ce
projet. La suivante décrit une partie du travail réalisé. Enfin, la dernière partie parlera des
différentes méthodes mises en place pour la réalisation du projet.
Il est fortement conseillé de lire attentivement la partie décrivant l'application et son utilité,
sans quoi il n'est pas possible de comprendre l'intégralité de mon rapport.
Les mots en gras ont été expliqués plus en détail dans le lexique situé en fin de rapport.

7. 7
Présentation du stage
DocDoku
DocDoku a été créée en octobre 2006. C’est une PME composée d’une vingtaine de salariés
spécialisée dans le digital, créatrice de solutions et de services pour l’industrie. Elle est aussi
spécialisée dans d’autres domaines comme le Web, le mobile ou encore les systèmes
d'information.
Elle est située à Toulouse, 37 rue Lancefoc, proche du centre ville et de l’université Toulouse 1
Capitole.
Elle développe DocDokuPLM qui est une plateforme innovante Open Source de PLM (primée
à l’Open World Forum en 2012 et l’OW2 en 2015), autour de laquelle l’entreprise construit
certains de ses logicielles, apportant ainsi une plus-value conséquente tel que :
 Visualisation interactive de la maquette numérique
 gestion des nomenclatures produits et des documents
 Collaboration en temps réel
 ...

8. 8
Présentation du contexte
Timegene Web
Presque l’intégralité de mon alternance a été consacrée à la conception et au développement
du projet Timegene Web. Celui-ci est un projet au forfait commandé par un client de
DocDoku au début du mois de Novembre.
Il s’agit ici de développer une application web s’inspirant d’une application Android/iOs déjà
existante, apportant ainsi de nombreuses améliorations par rapport aux versions mobiles
tout en gardant une étroite comptabilité entre les deux.
L’idée principale de l’application est de visualiser différents types de données via un critère
universel : le temps. L’objectif est de représenter le temps différemment que sous la forme
classique jours/mois/années afin d’améliorer grandement notre productivité globale qui est
relatif à la manière dont nous nous organisons et donc à notre gestion de temps.
Timegene permet de gérer ces données sous la forme d’axes temporels horizontaux
dynamiques, sur lesquels se placent des événements classés par ordre chronologique.
Figure 1 : exemple d'axe temporel
Ces axes temporels peuvent être vus comme des frises chronologiques digitales. Grâce à ces
dernières, il est possible de visualiser des données d’agendas (rendez-vous, réunions, comptes
rendus, tâches à réaliser…) mais aussi des mails, des documents divers, des images, des
données numériques, des tweets, ou encore des messages RSS.
L’application fournit de nombreuses fonctionnalités d’agrégation de données, d’import /
export (pour la comptabilité avec les versions tablettes) tout en permettant une interaction
sociale via son chat.

9. 9
Environnement de travail
Pour mener à bien ce projet, une équipe de quatre développeurs a été mise en place par
l’entreprise :
 Scrum master / Chef de projet : Yacine Merghoub puis Bertrand Boisvert
 Expert JS Front-End : Guilhem Brouat
 Deux développeurs juniors : Lucas Bled et moi même.
 Un stagiaire validant son DUT
Notre équipe a subit quelques changements au cours du développement de l’application.
L’expert JavaScript est arrivé deux mois après le début du projet. Ce dernier et notre chef de
projet on été positionnés par la suite sur un autre projet, plus conséquent et exigeant que
celui-ci.
Bertrand Boisvert a pris la relève à la fois en tant que chef de projet et Scrum Master.
Nous étions tous dans un petit open space, nous permettant ainsi de mieux collaborer.
Entraide et bonne ambiance faisaient partie de notre quotidien à tous, rendant ainsi ce projet
d’autant plus agréable à réaliser.

10. 10
Technologies et outils utilisés
JavaScript et ses bibliothèques
JavaScript est un langage de script léger, orienté objet à prototypes,
principalement connu comme le langage de script des pages web.
Les bases du langage et ses principales interfaces sont fournies par
des objets qui ne sont pas des instances de classes, mais qui sont
chacun équipés de constructeurs permettant de créer leurs
propriétés, et notamment une propriété de prototypage qui permet d’en créer des objets
héritiers personnalisés.
Les bibliothèques permettent d’automatiser et d’abstraire certains concepts. Voici les
bibliothèques JS que j’ai été amené à utiliser :
 jQuery est une bibliothèque JavaScript libre et multi-plateforme créée pour faciliter
l'écriture de scripts côté client dans le code HTML des pages web (parcours et
modification du DOM, gestion des événements, effets visuels et animations, etc).
 Underscore.js fournit des fonctions utilitaires pour des tâches de programmation
standards (manipuler un tableau, une collection, etc).
MongoDB
MongoDB est un SGBD (Système de Gestion de Base de Données) de type NoSQL (Not Only
SQL) orientée documents. Il gère des objets structurés au format BSON (JSON Binaire).
Sa grand force est qu'il ne nécessite pas de schéma prédéfini des données, laissant au
développeur une souplesse qu'il est difficile de trouver avec des SGBD relationnels.

11. 11
AngularJS
La partie Front-End de Timegene a été conçue en utilisant AngularJS.
Il s’agit d’un framework MVC JavaScript libre et open-source
développé par Google. Il permet de créer "facilement" des SPA (Single
Page Applications), ce qui permet d'éviter le chargement d'une
nouvelle page à chaque action demandée, et de fluidifier ainsi
l'expérience utilisateur.
AngularJS repose sur plusieurs principes, notamment celui du "Data First" qui implique que la
mise à jour des données entraînera une modification du DOM (à l'instar de jQuery). Une
autre philosophie au cœur du framework est celle du "Data Binding" qui est la
synchronisation des données entre le modèle et les vues.
Une application AngularJS se compose de différentes parties dont principalement :
 Contrôleurs : ils sont liés à des éléments HTML (ou des pages entières). Ils
contiennent les données du modèle et les fonctions permettant d'interagir avec leurs
vues.
 Directives : principal atout du framework, il est possible d'étendre du contenu HTML
avec de nouvelles balises et/ou attributs (Ex : ng-if supprime ou recrée une portion du
DOM en fonction d'une expression booléenne).
Figure 3 : One-Way Data Binding Figure 2 : Two-Way Data Binding

12. 12
 Services : permet de déplacer la logique métier de l'application ainsi que la gestion du
modèle.
 Routing : affecte les différentes vues au contrôleur, de façon statique ou dynamique.
 Modules: encapsulent toutes ces parties (souvent un seul module pour une
application).
Meteor
La partie serveur quand a elle a été développé grâce à
Meteor. Ce dernier est un framework JavaScript se basant
sur Node.js et est utilisé pour la création d'applications web temps-réel (chaque
modification du modèle entraîne automatiquement une mise à jour des clients concernés).
Bien qu'intégrant un gestionnaire de templates pour la partie Front-End, seul son application
serveur nous est utile.
La même API est utilisée côté client et serveur, il est donc possible d'effectuer un traitement
sur l'un ou l'autre. Suivant cette logique, Meteor intègre une base de donnée côté serveur mais
aussi côté client offrant plusieurs fonctionnalités :
 Compensation de latence : lorsque le client est modifié, le client va simuler
instantanément la mise à jour en base de donnée avant son envoie au serveur
supprimant donc une quelconque latence.
 Mode déconnecté : il est possible d'effectuer des opération de CRUD tout en étant
déconnecté du serveur.
La logique de tout cela repose sur deux fonctionnalités qui sont la publication de collections
MongoDB côté serveur, et la souscription à ces dernières côté client.
Pour pouvoir gérer la souscription côté client, un module "angular-meteor" indispensable a
été utilisé pour être compatible avec l'utilisation d'AngularJS.

13. 13
Vis.js
Vis.js est une bibliothèque développée entièrement à base de prototypes
JavaScript. Elle permet la visualisation et la manipulation de données sous
différentes formes : graphiques 2D et 3D, réseaux dynamiques et axes
temporels.
Ce sont les axes temporels qui nous intéressent pour Timegene Web.
Environnement de travail
L’IDE (Integrated Development Environment ) utilisé pour ce projet est
WebStorm (dérivé de Intelliji Idea et spécifique au développement
web). Il permet d’obtenir un rendement plus élevé grâce aux
nombreuses fonctionnalités qu'il propose, comme la possibilité d'aller
directement à la déclaration d'une fonction (Ctrl+clic gauche) qui est
selon moi une fonction indispensable si l'on ne veut pas perdre de temps inutilement. Cette
version "web" permet l'autocomplétion de tous les langages et frameworks utilisés :
AngularJS, Meteor, HTML, CSS, ...
Ses outils de debug, de recherches approfondies mais aussi son client Git intégré offre un
environnement de développement optimal.
Gestionnaire de versions
Le projet utilise Git comme gestionnaire de versions de code source. L'entreprise héberge son
propre serveur Git. Tout le travail que j'ai effectué durant cette année peut être retracé grâce
à cet outil.

14. 14
Grâce à Git, le développement se fait de manière très structuré et sécurisé. Des versions de
logiciel peuvent être créés (TAG), et si besoin est il est possible de revenir à des précédents
commits afin de chercher à quel moment une régression a été faite.
Le workflow Git étant un processus assez complet et fondamental pour le travail collaboratif,
il sera décrit plus loin dans le rapport.

15. 15
Travail réalisé
Ci-dessous une liste non exhaustive des fonctionnalités que j'ai été amené à développer
durant ces neuf mois d'alternance.
Architecture Front-End de l’application
Une fois que les frameworks furent tous choisis, ma première tâche fut de mettre en place
toute l'architecture Front-End de l'application une fois l'utilisateur connecté.
Le client a ainsi divisé son interface utilisateur en quatre parties distinctes :
 Barre de navigation : située en haut, elle permet de se déconnecter, de créer des axes
temporels, d'effectuer des actions sur ceux-ci, ...
 Volet d'exploration : il apparaît à gauche et permet de naviguer dans l'espace public
(axes créés et publiés par d'autre utilisateurs), dans l'espace privé (axes de
l'utilisateur) et dans le chat. Il est possible de fermer et d'ouvrir ce volet pour
améliorer la visibilité.
 Volet de consultation et de saisie : situé à droite, il doit permettre de visualiser et
d'éditer des événements ou des axes temporels.
 Bureau Timegene : c'est ici qu'apparaissent les axes ouverts de l'utilisateur.

16. 16
Figure 4 : interface utilisateur Timegene Web
Pour réaliser cela, j'ai utilisé un module de gestion de routes : ui-router. Contrairement au
gestionnaire de routes proposé par défaut, il permet de gérer un ensemble d'état auxquels
sont affectés différentes vues. Pour cela, il faut déclarer au sein de balises <div> des attributs
nommés "ui-view" auxquels seront affectés des vues (cf annexe).
J'ai donc crée un état générique, permettant d'affecter à chaque parties décrite plus haut une
vue. Voici le fichier HTML à la base de l'application :
Figure 5 : architecture des parties principales de Timegene Web
Les <div> contenant la partie "top" et "main" ont chacun une vue qui leurs est associée. Elles ne
varient jamais.

17. 17
La partie "left" correspondant au volet d'exploration est divisé en trois parties (décrites plus
haut). Un autre fichier HTML du même genre va donc définir trois autres <div> contenant
chacune un attribut "ui-view" afin d'affecter un template particulier aux espaces privé, public
et au chat.
Enfin, la partie "right" aura elle aussi un fichier HTML contenant une seul <div>. Cependant,
cette partie diffère des autres puisque que le volet de consultation et de saisie change en
fonction des actions de l'utilisateur. Ainsi, il existe un autre état pour la visualisation d'un
événement ou encore l'édition d'un axe.
Une fois tout cela mis en place et fonctionnel, je me suis attaqué directement à l'interface et
aux interactions que celle-ci devait fournir : lorsque le volet de gauche ou de droite s'ouvrent,
ils doivent décaler le contenu. J'ai utilisé LESS et de nombreuses classes pour arriver à un
résultat très proche des attentes du client.
Intégration de Vis.js
Présenté précédemment, Vis.js est la bibliothèque permettant de générer des axes temporels.
C'est pour ainsi dire la partie la plus important de l'application puisque tout ou presque
tourne autour des ces axes. L'intégration de cette bibliothèque s'est faite en deux parties.
Création d'une directive AngularJS
La première partie de cette intégration consiste en la création d'une directive (décrite
brièvement plus haut) AngularJS. En effet, l'instanciation d'une timeline (terme utilisé par
Vis.js) se fait normalement en jQuery, après sélection de l'élément html censé accueillir l'axe.
Il est donc nécessaire de passer par une directive puisqu'il n'est pas possible d'instancier un
objet JavaScript dans un contrôleur AngularJS.

18. 18
Pour chaque axe ouvert sur le bureau, une instanciation de cette directive est ajoutée
dynamiquement dans la page html correspondante. Cette directive prend en paramètre les
informations d'un axe stocké en base de données. C'est elle qui s'occupera de gérer toutes les
interactions de l'utilisateur, via un menu qui lui est propre (créer événement, voir axe,
supprimer axe, ...).
Modification de l'apparence de base
Les besoins du client étant très spécifiques sur le design de ces axes temporels, nous avons dû
modifier grandement l'apparence des axes proposés par Vis.js à l'aide de nombreuses
propriétés CSS et de classes.
Figure 6 : apparence basique des axes temporels de Vis.js
Comme le montre la figure ci-dessus, un grand nombre de modification on été nécessaires
pour satisfaire les besoins du client.
Problèmes rencontrés
L'intégration ne s'est pas déroulée sans encombre. En effet, étant peu expérimenté dans les
technologies AngularJS et Meteor, la directive que j'ai crée était assez limitée.
Lorsque l'expert JS de l'équipe est arrivé, il s'est occupé de l'améliorer en modifiant une bonne
partie de la directive.

19. 19
Axes numériques
Les axes temporels de type numérique on pour but d'afficher des séries de nombres
(considérés comme des événements). Ces séries peuvent avoir plusieurs fréquences :
quotidienne, hebdomadaire, mensuelle, trimestrielle et enfin annuelle. Chaque axe numérique
est lié à une unité (€, $, Kg, ...) qui est valable pour chaque série.
Ces axes contenant des données particulières, il a fallu que je modifie le modèle pour prendre
en compte ces spécifications. J'ai donc rajouté un tableau de série, chaque série contenant :
 Fréquence : écart entre chaque événements (quotidiens, hebdomadaire, ...).
 Unité : l'unité de la série (dans un premier temps l'unité était variables d'une série à
l'autre, pour ensuite devenir universelle à la demande du client).
 Occurrence : nombre d'événements/valeurs de la série.
 Date de début : date à laquelle commence la série.
 Date de fin : date à laquelle finit la série.
Cet axe fut un challenge, à la fois pour arriver à greffer ces particularités au modèle et à
l'interface utilisateur, mais aussi algorithmiquement parlant. Pour cela, j'ai crée un service
AngularJS où toutes les contraintes peuvent être gérées.
Figure 7 : exemple de série numérique (incomplète)
Si l'utilisateur souhaite créer une série commençant à la date du trou de la figure ci-dessus
(01/07/2016), il faut que ce dernier soit redirigé vers la page d'édition de la série en question
plutôt que de créer une nouvelle série qui se cofonderait avec celle déjà existante.
Ce type d'axe possède une autre fonctionnalité permettant d'améliorer la lecture de ses séries.
Il s'agit de l'agrégation des données des séries lors du dé-zoom/zoom, si les conditions sont
réunies. Les données peuvent s'agréger soit en moyenne, soit par addition.

20. 20
Exemple : prenons une série quotidienne commençant le 20/03/16 et terminant le 10/07/16.
Plutôt que de voir 30 événements du 01/04/16 au 30/04/16, lorsque l'utilisateur dé-zoomera il
n'y aura plus qu'un seul événement d'un mois, qui aura comme valeur soit la moyenne soit
l'addition des 30 événements. Si l'utilisateur dé-zoome encore, alors plutôt que de voir 3
événements (chacun étant l'agrégation d'un mois), il n'y aura plus qu'un événement pour le
deuxième trimestre du 01/04/16 au 30/06/16.
Figure 8 : série numérique après dé-zoome
Normalement, les événements visibles sur un axe sont tous des événements stockés en base
de données. Hors ici ce sont des événements créés "artificiellement" à partir des événements
de base. Pour cela, j'ai du m'intéresser de plus près à la bibliothèque Vis.js. Il s'agit d'un
fichier .js d'environ 100 000 lignes, un certain temps m'a donc été nécessaire afin de
comprendre cette gestion d'événements.
Relation Client
Le cahier des charges fournit par le client étant très évasif et peu détaillé, je n'avais pas tous
les éléments en main pour réaliser ce qu'il demandait. En effet, de nombreux aspects des
fonctionnalités demandées (création/modification de série, agrégation) n'était soit pas clair
soit manquant.
C'est pourquoi j'ai pris l'initiative, avec l'accord de mon chef de projet, d'appeler directement
le client afin d'avoir des réponses dans les plus brefs délais (plutôt que de passer par des
mails, qui auraient pris beaucoup plus de temps).
Une fois que le client m'ai expliqué clairement ce qu'il souhaitait, j'ai été amené à proposer
des solutions directement au client afin de combler tous les trous.

21. 21
Import d'axes standards et numériques
L'application propose d'importer des axes standards et numérique depuis plusieurs types de
fichiers : .tmgn (fichier XML), .csv et .ods.
Cette partie fut celle qui m'occupa le plus longtemps. J'ai pour cela utilisé deux plugins, l'un
fournit par Meteor et l'autre par AngularJS, respectivement Papa Parse et x2js (XML to
JSON).
Afin d'être le plus générique possible, la même page d'import a été utilisé pour les deux axes.
Pour gérer les retours de l'import (gestion des erreurs ou du succès) , j'ai crée une fonction de
callback universelle qui affiche un retour utilisateur dans la fenêtre d'import en cas d'erreur,
ou qui affiche l'axe sur le bureau en cas de succès.
En fonction du type de ficher, une fonction spécifique est appelé dans un service dédié à
l'import d'axe. Une fois que le fichier est lu, les informations sont traduite sous forme d'un
objet JSON.
Pour créer un axe et l'afficher sur le bureau, il faut que l'utilisateur ai les droits nécessaire. Il
faut donc demander au serveur si l'utilisateur :
 a le droit de créer un axe supplémentaire (nombre de création d'axe limité en fonction
du type de compte souscrit)
 a le droit d'afficher un axe sur le bureau
 a le droit d'afficher un axe du type standard (ou numérique) sur le bureau
Pour cela trois fonctions on été crée, chacune effectuant une demande spécifique au serveur.
Si la première renvois une erreur, il n'ai pas nécessaire d'appeler la suivante. C'est pourquoi il
faudrait appeler la deuxième fonction dans le callback de la première en cas de succès, et la
troisième fonction dans le callback de la troisième.
Bien que trois imbrication ne soit pas ingérable, j'ai préféré utilisé le système de promesse
d'angular : $q. Les promesses permettent de chainer des fonctions séquentiellement et d'agir
en fonction du résultat. Cette solution est selon moi plus "propre", c'est pourquoi je l'ai
choisis.

22. 22
Figure 9 : appel séquentiel de fonction asynchrone
Une fois les vérifications effectuées, la fonction d'import est appelé. Cette dernière insérera
l'axe dans la base MongoDB et l'affichera (ou non) sur le bureau.
Problèmes rencontrés
L''import fut fonctionnel rapidement. Néanmoins, lorsque l'utilisateur souhaite importer des
fichiers avec un nombre d'événements conséquents, l'importation nécessitait en un temps de
traitement beaucoup trop long. Deux raisons à cela :
 Nous avons utilisé pour chaque collections MongoDB un schéma définissant quels
attributs elle contenait (type de l'attribut, optionnel ou non, ... ). La validation de ce
schéma prend un certain temps, et dans le cas ou il y a de nombreux événements d'un
seul coup, ce temps est excessivement long.
 L'envoi de l'objet contenant les informations de l'axe à importer au serveur prend lui
aussi beaucoup de temps s'il y a beaucoup d'événements.
Pour résoudre ces soucis, j'ai d'abord essayé de déplacer l'import sur le serveur, sans réel
succès. J'ai finalement décidé d'insérer l'axe dans la base de données côté client.

23. 23
Autre tâches
En plus des tâches principales définit plus haut, j'ai développé de nombreuses autre
fonctionnalités. Parmi elles, voici les deux plus intéressantes selon moi.
Placement des événements
J'ai eu l'occasion de m'intéresser de plus près à Vis.js afin de modifier l'affichage des
événements. Le client souhaitait gérer l'affichage des événements en conflits comme sur la
version mobile de l'application. Si deux événement se chevauchent sur une même durée, alors
leurs tailles sont divisées par deux afin qu'ils soient tous les deux visibles.
Pour cela, j'ai dû modifier le DOM directement dans des fonctions de Vis.js, plus
spécifiquement dans les fonctions devant redessiner les événements.
Figure 10 : placement des événements en conflits
Performances
Lorsque la plupart des fonctionnalités on été intégré, nous avons constaté que lorsque des
axes contenant un grand nombre d'événements et que plusieurs d'entre eux était ouvert en
même temps sur le bureau, l'application devenu de plus en plus lente, perturbant l'expérience
utilisateur.
J'ai exploré quelques points afin d'essayer d'améliorer les performances :

24. 24
 Lorsqu'un certain nombre d'événement (fixé temporairement à 50) sont affichés en
même temps sur l'axe, les événements sont supprimé et un message d'erreur apparaît.
L'utilisateur est alors invité à zoom ou se déplacer pour voir de nouveau les
événements.
 J'ai amélioré l'algorithme de placements des événements. Ce dernier était effectué à
chaque mise à jour de l'affichage. Pour cela, l'algorithme est maintenant appelé
uniquement lors qu'un nouvel événement est affiché.

25. 25
Démarche méthodologique
Cette partie décrit la démarche que toute l'équipe et moi-même avons mis en place tout au
long du développement de l'application.
SCRUM
Ce projet a été gouverné grâce aux méthodes agiles, de plus en plus utilisées pour ce type de
projet puisqu'elles favorisent le développement itératif des produits.
Nous avons choisis d'utiliser la méthode SCRUM pour ce projet. Cependant, tout n'a pas été
respecté à la lettre puisque seul le Scrum Master participait au rendez-vous avec le client.
Voici les événements auxquels notre équipe était sujette :
 Daily Scrum : réunion tous les matins à 9h30, chaque développeur décrivait les
fonctionnalités qui l'on occupé la veille, pour ensuite aborder ce qu'il comptait
effectuer pour la journée à venir.
 Sprint : Hormis un premier sprint d'une durée d'un mois, nous sommes partis sur des
sprint d'une durée de trois semaines.
 Planification d'itération : à chaque début de sprint, toute l'équipe se réunit afin de
décider qu'elle serait les fonctionnalités à développer. De plus, chacune de ces tâches
sont "notés" en suivant la suite de Fibonacci. Ces notes prennent en compte toutes les
phases de développement de la fonctionnalité (phase de conception à la rédaction de
tests).
 Revue de sprint: à la fin d'un sprint, l'équipe présente quelles fonctionnalités ont été
achevées, celles qui sont en cours et celles qui n'ont pas été entamées afin de valider
l'incrément du produit.

26. 26
Outils de gestion de projets
Pour la gestion de projet, deux outils ont été utilisé, Redmine et Trello.
Redmine
Il s'agit d'une application de gestion de projets presque complète en mode web. Nous l'avons
principalement utilisée pour gérer l'ensemble des bugs et évolutions tous au long du
développement. De plus, sa fonctionnalité "Wiki" nous a permis de rassembler tous les
tutoriaux, workflows et processus de développement au même endroit.
Redmine est directement hébergé sur les serveurs de DocDoku.
Figure 11 : anomalies référencées sous Redmine

27. 27
Trello
Trello est lui aussi un outil de gestion de projet, mais orienté méthodes agiles. Il est basé sur
une organisation des projets en planches listant des cartes, chacune représentant des tâches
(généralement associable à des fonctionnalités). Les cartes sont assignables à des utilisateurs
et sont mobiles d'une planche à l'autre, traduisant leur avancement.
A chaque carte est associé une valeur entière qui a pour but d'indiquer approximativement la
charge de travail relative à la tâche en question.
Figure 12 : liste des tâches par sprint sous Trello
Tests
Étant donné le retard et l'importante charge que nous avions, nous n'avons fait aucun test
automatique. Cependant, nous avons suivis un processus de tests croisés fonctionnels

28. 28
complet permettant de s'assurer que les fonctionnalités développées correspondant aux
attentes du client.
Les deux derniers jours de chaque sprint ont donc été réservé au tests. Une feuille Excel a été
crée pour chaque sprint. Chaque développeur y a écrit tous ses tests en fonction du cahier des
charges. Une fois tous les tests rédigés, nous réalisions les tests d'un autre développeur afin
d'avoir un œil nouveau et donc plus critique. Les navigateurs Chrome et Firefox on été
priorisé.
A partir du sprint 7, il a été décidé de rédiger les tests d'une fonctionnalité directement après
réalisation de celle-ci, sans quoi il n'était pas possible de clore la carte associé sur Trello. Cela
a permis de gagner du temps en fin de sprint, tout en permettant l'écriture de tests plus
adapté.
Figure 13 : exemple de ficher de test
Worflow Git
Afin de gérer et de minimiser au mieux les conflits engendrés par l'utilisation d'un
gestionnaire de version tel que Git, nous avons mis en place un workflow git. Chaque
membre de l'équipe doit suivre le plus possible ce processus.

29. 29
Il y a deux branches principales : master et dev. La branche master est mise à niveau à chaque
fin d'itération, où un tag est crée. La branche dev est celle utilisé lors de la phase de
développement.
Une branche doit être créée pour chaque fonctionnalité. Nous avons choisis la méthode du
"rebase" pour fusionner ces branches à la branche principale (dev). Cette méthode permet
d'appliquer les commits distants aux commits locaux, permettant de gérer les conflits sur la
branches plutôt que sur la branche principale.
Voici les étapes qu'il faut suivre :
 Créer une branche puis programmer la fonctionnalité à laquelle elle est dédié.
 Mettre à jour la branche principale, puis effectuer le "rebase" sur l'autre branche.
 Gérer les conflits.
 Sur la branche principale effectué un merge de la deuxième branche.
 Envoyer les nouveaux commits au serveurs.

30. 30
Bilan
Bilan de la mission
Le projet Timegene Web est finalement arrivé à son terme. Bien que tout ne soit pas encore
terminé, je pense que l'on peut considérer la réalisation de ce projet comme étant un succès.
Nous avons effectué la recette, qui a été validé par le client.
Ma contribution au projet est effective. Toutes les fonctionnalité que j'ai développé ont été
intégrées à l'application.
Bilan personnel
La pratique réel de l'informatique dans le cadre de l'entreprise est totalement différente de
celle que l'on peut apprendre durant nos études. Cet alternance m'a permis de mettre en
application certaines pratiques acquises au cours du master. Néanmoins, les technologies
utilisés dans le cadre de ce projet n'ont pas été vu durant ma dernière année, car trop
spécifique au domaine du web.
Cependant certains UE de l'année de M1 m'ont été utiles, comme pour l'utilisation de Git et
des méthodes agiles.
Ce projet fut très intéressant sur de nombreux point. Tout d'abord car il m'a permis de
découvrir un grand nombre de technologies qui sont au cœur du développement web de ces
dernières année. Ensuite car il m'a permis d'intégrer une vraie équipe, me permettant ainsi de
découvrir le travail d'équipe plus que jamais.
J'ai pu m'améliorer dans plusieurs domaines, tels que la communication et l'entraide
(notamment avec le stagiaire qui nous a rejoins) et bien entendu dans le développement
d'application web.

31. 31
Conclusion
Cet alternance représente ma troisième réel expérience professionnelle dans le monde de
l’informatique. J’attendais avec impatience cette partie de la formation, car je pense que c’est
celle-ci la plus formatrice. Grâce à cette période, on aborde l’informatique d’un œil différent
ce qui est selon moi une bonne chose.
Bien qu’ayant déjà travaillé en groupe durant certains projet de cette année, j’ai pu constater
que le travail d’équipe est un fondamental dans le domaine de l’informatique. En effet,
pendant les neufs mois que j’ai effectué chez DocDoku, la communication entre les membres
de l'équipe et le client était primordial.
Ainsi, cet alternance est pour moi une concrétisation de tout ce que j’ai appris durant ma
formation. Il m’a aussi permis de me réconforter dans mon choix d’étude.
Enfin, je serais encore amené à travailler sur ce genre de projet au sein de DocDoku puisque je
serais embouché chez eux une fois mon diplôme obtenu.

32. 32
Lexique
Au forfait : engagement contractuel d'une entreprise sur un résultat attendu.
Tweets : message envoyé via le réseau social Twitter
MVC (Modèle Vue Controller) : patron de conception logiciel
Node.js : plateforme logicielle libre et événementielle en JavaScript orienté réseau.
Temps-réel : mise à jour des données entre client et serveur très rapide.
CRUD : désigne les quatre opération de base pour la persistance des données (Create, Read,
Update, Delete)
Autocomplétion : affiche dynamiquement les choix possible.
Commits : enregistrement des modification apportées à Git.
Less : langage dynamique de génération de feuille de style CSS.
Classe : permet d'affecter des propriété CSS à un élément HTML.
Fonction de callback : Fonction appelé à la fin d'un traitement asynchrone.
Promesse : permet d'effectuer un appel séquentiel de fonction JavaScript asynchrone.
Suite de Fibonacci : suite d'entiers dans laquelle chaque terme est la somme des deux termes
qui les précèdent.
Tag : sauvegarde l'était d'une branche en lui assignant un numéro de version.
Application hybride : à partir du même code source, application qui fonctionne sur
différentes plate-formes (Android, iOs, Windows Phone, ...).
Framework: ensemble de composants logiciels structurels, qui sert à créer les fondations
ainsi que les grandes lignes de tout ou d’une partie d’un logiciel.
DOM : standard duW3C qui décrit une interface indépendante de tout langage de
programmation et de toute plate-forme, permettant à des programmes informatiques et à

33. 33
desscripts d'accéder ou de mettre à jour le contenu, la structure ou le style de
documents HTML et WXML.
JSON : (JavaScript Object Notation) est un format de données textuelles dérivé de la
notation desobjets du langage JavaScript.

34. 34
Annexes
Figure 14 : état de routage à la base de l'architecture de Timegene Web