Vous êtes sur la page 1sur 36

Rapport de Stage

Concepteur / Developpeur d’Application


AFPA 2020 - Groupe CDA 19152-1910.313
stage SmarterPlan : 25 / 05 / 20 - 24 / 07 / 20
formation AFPA : 28 / 10 / 19 - 30 / 07 / 20

Maitre de Stage :
Thai-Bin Phan

Formateurs :
Duc-Ahn Pham
Marc Lambert
Constant Matsima
Stagiaire :
Maxime Richard Manager de formation :
maxime.j.richard@gmail.com Vanessa Sultan

P.1/36
Sommaire
Introduction
3 Avant Propos
4 Résumé
5 Présentation de l’entreprise
5 Présentation du stagiaire

Projet
6 Contexte du projet
7 Gestion et organisation
8 La méthode Agile
9 Typologie technique
10 Ressources humaines

Conception
11-13 Descriptif fonctionnel
14 Architecture technique
15 Maquette interactive

Développement
16-17 Le FrameWork Angular
Le composant : ticket-parent
18 - Le Modèle
19 - Le Service
20 - La Vue
Le composant : intervention-planning
21 - Le Modèle
22 - Le Services
23 - La Vues
24 - Le Formulaire

Conclusion
25 Succés
26 Analyse critique
26 Bonnes pratiques
27 Remerciements

Annexes
28-29 Diagrammes BPMN
30-31 Backlog Jira
32-33 Modèle de données
34 Le composant ticket-parent
35 Le composant intervention-planning
36 Journal de bord

P.2/36
Introduction
Avant propos
Mon stage en entreprise de neuf semaines s’est déroulé
dans le cadre de la conclusion d’une formation de Concepteur-Développeur
Informatique proposé par l’Afpa et financé par le Conseil Régional d’Ile-de-
France. En mars 2020 j’ai pu participer à plusieurs salons professionnels
informatiques et découvrir le marché de l’emploi de cette industrie. C’est lors
de l’événement du Hacking de l’Hôtel de Ville à Paris que j’ai eu mon premier
contact avec la société SmarterPlan qui présentait son produit innovant à ce
salon de l’entrepreneuriat local.

Pendant ma recherche de stage en confinement, j’ai reçu


plusieurs propositions pour cette période en entreprise, et j’ai choisi celle-ci
car elle me semblait le plus convenir au domaine de l’informatique de gestion
de données, vers lequel nous avait orienté la formation. De plus Smarter plan
touche à des technologies visuelles qui m’intéressent, telles que la computer
vision, la photogrammétrie et la 3d.

La recherche de stage et son commencement ont eu lieu


pendant la période très particulière du confinement et m’ont permis d’expéri-
menter les avantages et les limites du télétravail. Bien que la start-up et son
écosystème fonctionnait déjà selon des modes de communication virtuels,
j’ai dû travailler pendant plusieurs semaines et m’intégrer dans une équipe de
collaborateurs formée au préalable, sans parfois les rencontrer où même voir
leur visage.

Les échanges d’informations, la gestion du projet et l’orga-


nisation du travail se sont fait au-travers de nombreuses discussions et de
conférences sur internet mais aussi par l’utilisation d’outils dédiés aux produc-
tions informatiques. Pour mes collaborateurs, ces pratiques étaient tout à fait
apprivoisées et naturelles, et les rencontres dans le monde réel restent relati-
vement exceptionnelles dans cette équipe.

P.3/36
Introduction
Résumé
Smarter plan propose une nouvelle solution innovante dans
la gestion de maintenance assistée par ordinateur avec des photos à 360°, un
modèle 3d du bâtiment et des fonctions de computer vision qui permettent
de reconnaître les équipements. Durant ce stage j’ai pu découvrir plusieurs
dimensions dans un projet informatique. J’ai à la fois pu travailler à la concep-
tion et au développement.

Pendant le premier mois, j’ai fais l’analyse du besoin que


j’ai restitué sous forme d’un logigramme BPMN reprenant les cas d’utilisa-
tion. Nous avons mis en fabrication celui qui serait le plus fréquent et le plus
utile aux premières versions commercialisables de l’application, mais j’en ai
schématisé plusieurs autres qui pourraient être développés par la suite. Puis
j’ai élaboré 40 maquettes avec Photoshop pour la création des nouvelles
pages de l’application. J’ai renseigné toutes les demandes techniques dans
67 tickets Jira sous forme d’Epic, de Story et de Tâches qui précisent le cas
d’usage et l’utilisateur, le comportement actuel, les critères d’acceptations, et
d’autres informations additionnelles. Ainsi j’ai pu plonger dans les détails de
chaque point technique.

Enfin, dans le deuxième mois, j’ai développé avec l’équipe


en charge du Front-End et programmé 5 composant Angular répondant à
certains besoins que nous avions identifiés. Parmis eux, le composant inter-
vention-planning permet d’envoyer un email avec une date de demande d’in-
tervention à un profil sélectionné dans une liste, et le composant ticket-parent
permet de lier plusieurs tickets de signalement d’incidents ensemble. J’ai col-
laboré avec d’autres développeurs en utilisant Gitlab et en travaillant sur des
branches différentes pour chaque component. Nous avons utilisé la méthodo-
logie Agile pour nous répartir le travail et se fixer des objectifs.

P.4/36
Introduction
Présentation
de l’entreprise
Smarter Plan est une start up formée autour de la vision de
trois associés : Thai-Binh Phan, Jean-Baptiste Dumont, et Philippe Boyer-Nar-
don. A partir de leur expériences respectives du pilotage de projet informa-
tique innovant, de la gestion de maintenance assistée par ordinateur et du
marché de la gestion immobilière, ils ont imaginé une gamme de produits au
croisement de tous leur domaines.
Alors qu’elle est agée de quelques mois, l’entreprise m’in-
tègre a une période charnière de sa croissance. Une première version de
démonstration est présentée à des clients potentiels depuis quelques temps,
et le besoin de pouvoir vendre une application fonctionelle se fait de plus en
plus ressentir. Les équipes de développement du Front-End (Just A.I.) et du
Back-End (Odin Core) ont travaillé chacune de leur côté et elles vont devoir
rentrer dans une phase de synchronisation intense afin d’uniformiser les
différentes versions commercialisables. Un premier produit, développé par un
seul technicien, SmarterPlan Essentiel, est fini a 80%. SmarterPlan Plateforme
a été développé intensément en front durant les 6 derniers mois et va devoir
maintenant implémenter le back end dont la conception est en train d’aboutir.
Enfin, SmarterPlan Bim reste à l’état de projet en recherche et développement
car il repose sur une technologie très lourde et normalisé, le BIM, et que le
projet SmarterPlan se veut dans un premier temps plus libre et adaptable à la
demande.

Présentation
du stagiaire
J’ai d’abord suivi des études de philosophie afin de passer
une license où je m’intéressais particulièrement aux spécialités de la logique
et de l’esthétique. En parallèle, je travaillais en tant que libraire, ce qui m’a
donné un sens de l’organisation et du classement assez rigoureux. Puis avec
plusieurs associés j’ai ouvert un studio de post-production et de motion-de-
sign tout en suivant des formations professionnelles dans les effets spéciaux
et le graphisme. Freelance depuis plusieurs années dans ces domaines, j’ai
continué à m’intéresser et à me former en autodidacte à la programmation en
python et en JavaScript. J’ai voulu certifier cette compétence de développe-
ment en suivant une formation qui m’apporterait des bases théoriques et des
bonnes pratiques professionnelles. Je n’avais pas comme projet d’aller vers
une reconversion professionnelle, mais plutôt d’apprendre à utiliser des ou-
tils numériques dans une industrie que je connais bien, celle de l’audiovisuel.
J’aimerais désormais acquérir des compétences qui m’orienteraient vers le
métier d’Ingénieur Vision (DIT).

P.5/36
Projet
Contexte du projet
La GMAO (gestion de maintenance assistée par ordinateur)
est un domaine industriel informatique qui a pour objectif d’organiser et de
faciliter la résolution de problèmes techniques liés au bâtiments. Les clients
principaux sont des gestionnaires immobiliers qui sont en charge de plusieurs
bâtiments et dont ils doivent assurer l’intégrité au niveau des normes de
confort, de sécurité et de législation. D’autres clients potentiels peuvent être
les sociétés de location de bureaux, mais aussi les entreprises de services, de
maintenance et de ménage.

Dans le domaine de l’architecture, deux changements im-


portants ont eu lieu ces dernières années. D’abord l’émergence d’un besoin
d’inventer un système de normes internationales dans la représentation 3d
des immeubles, qui porte avec lui tous les sous-domaines techniques des
différents métiers du bâtiment. C’est le BIM, technologie rigide est lourde qui
s’installe progressivement comme une référence incontournable mais difficile
à mettre en place.

La deuxième évolution dans l’immobilier en découle et


s’appuie sur l’apparition de l’intelligence artificielle. Ce sont les Building Intelli-
gents, qui sont une forme de double digitaux d’immeubles entiers. Il s’agit de
numériser et de centraliser tous les capteurs possibles d’un immeuble ainsi
que les équipements qui le composent afin de permettre à des algorithmes de
maintenance prédictive d’améliorer l’entretien du matériel.

Dans ce contexte, Smarter plan propose une nouvelle solu-


tion innovante. Le processus est complexe et en cours d’élaboration. A l’aide
de la captation visuelle de plusieurs points de navigation avec des photos en
360, un processus de photogrammétrie va générer un modèle 3d du bâtiment.
Une fonction de computer vision entraînée spécialement à reconnaître des
élément spécifiques au métier va analyser les images et placer dans l’espace
3d les fiches techniques d’équipement qui auront été reconnus. Enfin, les
outils de GMAO spécifiques au bâtiment seront reliés manuellement par les
techniciens de SmarterPlan afin de completer la gémellité numérique.

SmarterPlan a présenté sa problématique et le laboratoire


d’Informatique, Systèmes, Traitement de l’Information et de la Connaissance
(LISTIC) a proposé de recruter Sofiane pour travailler pendant 15 mois sur
cette technologie. La complexité de travailler avec un labo public est effa-
cé grâce à la Société d’Accélération du Transfert de Technologies (SATT de
Grenoble). L’objectif est de faire rencontrer des porteurs de projets avec des
chercheurs pour développer des nouvelles technologies. En terme de proprié-
té intellectuelle, chaque cas est négocié en license.

P.6/36
Projet
Gestion et organisation
L’organisation du travail pendant ce stage a été tout à fait
inédite pour moi. J’avais l’habitude en tant que freelance en motion-design de
faire du télétravail, mais aussi que toute mission commence habituellement
par un brief dans les bureaux du client. Pour ce projet, tous les collaborateurs
étaient dans une ville différente : Paris, Chartres, Nantes, Rouen, Grenoble, etc

Jira est un outil de division et de suivi du travail. Il fonctionne


avec sa propre méthodologie qui implémente la méthode agile, et tout tourne
autour de Tickets, qui peuvent être des Epics, des Storys ou des Tâches. Les
grande évolutions de l’application sont des Epics, elles sont mises en place
sur des périodes longues et sont issues des visions stratégiques de la direc-
tion qui répondent directement aux demandes des clients. Pour chaque Epic
on subdivise l’objectif en plusieurs Story, qui représentent directement les
fonctions du cas d’utilisation en décrivant les acteurs et leur motivations. En-
suite on fait la liste précises des Tâches qui devront êtres exécutées pour que
la Story soit fonctionnelle : design de maquette, création du template de vue,
création de logique métier, routing, implémentation de composants.

Des workflows spécifiques peuvent être élaborés pour


chaque projet afin de mettre en place des boucles de validation des tickets et
en assignant des responsables différents à chaque étape. On peut aussi défi-
nir des liens entre les tickets afin d’établir l’ordre logique dans lesquels ils faut
les réaliser. Cet outil très efficace permet de suivre avec une certaine transpa-
rence le travail des équipes à distance, mais demande de consacrer du temps
à la rédaction du besoin et à la gestion du projet.

P.7/36
Projet
La méthode Agile
La méthode Agile ne prend pas en compte la notion de
risque quand on fonctionne avec des prestataires, le commanditaire en porte
la charge entièrement. Une petite société limitée en budget et en temps ne
peut pas vraiment se permettre cette organisation, car il faut un produit fini au
plus vite.

Le manifeste Agile a un principe : privilégier l’humain, le


concret, plutôt que la procédure. Cela amène un protocole de résolution de
problème prenant en compte la temporalité. Avec la méthode SCRUM on
charge des Sprint avec de la complexité en fonction de la bande passante de
l’équipe des développeurs. Au fur et à mesure de l’avancement, il faut faire des
Backlog Grooming pour nettoyer les taches obsolètes, c’est à dire dans mon
cas archiver les ticket Jira dont on a plus besoin. On analyse et on améliore la
méthode de travail en cours de production en faisant des boucles de feedback
qui sont les différentes réunions du rituel Agile, aussi appelées cérémonies.

Pendant le Sprint Planning, tout le monde est là et il ne faut


faire attention à ne pas les faire durer trop longtemps, où alors les faire uni-
quement avec les seniors pour avoir un repère avant d’obtenir le consensus de
l’équipe. Les Demo sont la présentations hebdomadaires du code. La Retro-
demo est le retour sur la Demo, et les discussions entre développeurs pour
débrieffer. Le Daily Standup est un appel quotidien de 5 minutes aux membres
de l’équipe pour savoir comment évoluent les projets. Pour chaque cérémonie
on fait un ROI noté de 1 à 5 sur le fait que la réunion ait été pertinente.

Avec la méthodologie Kanban on va lister sans notion tem-


porelle, sans Sprint, en notant par priorité l’ordre des Tickets qui ont le plus
de retour sur investissements. Les développeurs choisissent plus librement
les domaines qu’ils travaillent. On fait des démo à la fin des Epics, souvent en
jallons trimestriels.

Le Cycle V prépare un cadre très large en listant toutes les


étapes dès le départ et en demandant beaucoup de documentation. Cette
façon de fonctionner est très procédurière, robuste pour la maintenance, mais
manque de fluidité. Cette méthode de gestion de projet Waterfall, en cascade,
provoque des effets tunnel, c’est à dire que sans Feedback on peut produire
une application qui n’est plus en accord avec le besoin du client. Pour éviter
cela on met plus d’attente et d’exigence sur les résultats et moins sur les pro-
cédures.

P.8/36
Projet
Typologie technique

J’ai schématisé des diagrammes Le modèle de données est conçu


BPMN avec Camunda Modeler. sous dbgramm.io. Le serveur est
hébergé sur Amazon AWS.

J’ai maquetté les différentes pages La base de données est créé en


avec Photoshop et ajouté de l’inte- DynamoDB avec une interface
raction avec MarvelApp. GraphQL.

J’ai développé les composant du Le visualiseur 3d a été développé


front-end avec Angular et Bootstrap avec Matterport pour SmarterPlan
sur Visual Code et le Terminal de Essentiel et Cupix pour SmarterPlan
Mac OSX. Plateforme.

Nous avons organisé les plannings Les fonctions de computer Vision


de travail avec Jira. Nous avons ont été développées avec les librai-
géré les versions du code sur Git- ries Tenserflow et Mask_RCNN.
lab.

P.9/36
Projet
Ressources humaines

P.10/36
Conception
Descriptif fonctionnel 1
Lors des différentes réunions nécessaires à la compréhen-
sion du besoin, j’ai pris en notes les synthèses des visions de mes collabora-
teurs. A l’aide de plusieurs cas d’usages qui ont étés rédigés sur l’application
StoriesOnBoard et de l’analyse des échanges avec les trois associés de Smar-
terPlan, j’ai élaboré les logigrammes des fonctions attendues pour la V1 en
utilisant la codification BPMN. J’ai d’abord détaillé des processus en faisant la
liste exhaustive des fonctions demandées et des possibilités de parcours. Ce
sont les diagrammes du signalement d’incident, de la gestion d’un incident, de
la validation d’une intervention, de l’inspection réglementaire, et de la commer-
cialisation.

Mais pour représenter un aspect complet de l’application,


j’ai du répondre à la demande de proposer une vue plus macroscopique des
fonctions. J’ai donc fais le diagramme du cas d’usage d’un incident nécessi-
tant une intervention. Ce document est devenu le plan à suivre pour élaborer
le MVP (Minimum Viable Product), qui serait une version fonctionnelle utile
pour des démarches commerciales précédant la première version complète.
La mise par écrit de façon logique de cette liste de fonctions a aussi permis
de vérifier que tout était possible autant avec le Back-End que le Front-End, et
de faire les ajustements nécessaires avant la connection de ces deux parties
de l’application qui avaient été développées indépendamment.

La notation Business Process Model and Notation permet


de très bien modéliser les différentes activités spécifiques d’un métier, et de
représenter à la manière d’un diagramme de séquence UML, l’enchaînement
des processus, l’attente, les flux de contrôles. Mais il permet aussi d’ajouter
des nuances, comme dans les diagrammes de cas d’utilisation internes UML,
en particulier en précisant différents acteurs, leurs collaborations, leurs activi-
tés. On peut aussi chorégraphier les envois d’information, les objets de la base
de données, et exprimer des conditions ainsi que des branchements logiques.
Cette notation peut être comparée au diagrammes d’activité UML car leurs
éléments sémantiques et leur lecture sont semblables. Le BPMN a pour
avantage d’être facilement compréhensible par les différents collaborateurs,
des spécialistes du métier, aux développeurs techniques, en passant par les
utilisateurs finaux du produit.

P.11/36
Conception
Descriptif fonctionnel 2
Le cas d’usage qui sera reproductible dans le MVP est le
signalement d’un incident nécessitant une intervention. Il représente 4 acteurs
de sociétés différentes. Un visiteur des locaux qui va signaler un problème
sur un équipement. Un responsable des services généraux d’une société qui
loue les locaux et qui va faire de la gestion de données manuelle à partir du
signalement. Un gestionnaire de propriété qui va gérer les aspects financiers
et techniques de l’incident, et qui va planifier la réparation. Enfin un artisan en
charge de la maintenance qui va intervenir dans les locaux et clôturer l’inter-
vention.

La gestion de ce signalement sera renseignée dans la base


de données par une entrée de la table ticket, dont tout l’historique est stocké
dans des enregistrements de la table event. Ce ticket change son champ type
chaque fois qu’une étape du BPMN est franchie : cela dépend de l’acteur qui
doit entreprendre le traitement et des actions qu’il faut effectuer pour qu’il évo-
lue. Il passera par les types signalement, demande de maintenance, demande
d’intervention, intervention. Des documents peuvent être ajoutés au ticket à
l’aide d’enregistrement dans la table note, comportant des hyperliens vers
Amazon SimpleStorageService.

Pour des versions futures, il a été envisagé la création d’une


messagerie interne à l’application, mais sur le premier MVP c’est un service
d’Amazon, Simple Email Service, qui sera utilisé. Différents template de mails
seront élaborés, et des déclencheurs seront ajoutés directement dans le
Front-End afin de faire les envois.

P.12/36
Conception
Descriptif fonctionnel 3
Afin de pouvoir gérer les statuts des différentes tables de la
base, nous avons utilisé la méthodes des Enum. Ce sont des ensembles sta-
tiques de valeurs dans un ordre spécifique qui seront utilisées de façon sys-
tématique et invariable. Les jours de la semaine sont un ensemble de valeurs
idéales pour une énumération de ce type, aussi appelé liste de données. Pour
finaliser le développement de la base, en concertation avec les différents col-
laborateurs, j’ai rédigé les listes exhaustives des statuts qui seraient utilisés,
renseignant ainsi 16 champs ayant chacun une liste de données différente.

Cette analyse en profondeur des fonctions a permis de sou-


lever des demandes de modifications sur la base de donnée avant la livraison
finale. Il a fallu rajouter une table de jointure entre la table ticket et la table
équipement, afin de pouvoir créer des liens entre ces deux types d’objets.
Cette pratique avait jusqu’alors été évitée dans la base car toutes les autres
relations peuvent être limitées, mais celle-la était la seule qui pouvait devenir
très nombreuse et changeante facilement, de type Unbound.

P.13/36
Conception
Architecture technique

P.14/36
Conception
Maquette interactive
Pour guider les développeurs sur ce qui sera attendu, j’ai
réalisé les maquettes de toutes les pages nécessaires pour le MVP et apporté
des changements à partir de captures d’écrans de la version démo actuelle-
ment en ligne. En suivant précisément le logigramme du MVP et en reprenant
les éléments graphiques déjà développés et validés, j’ai fait le design des 40
pages de l’application, en appliquant les variations sur chaque vue condition-
nelle, en fonction de l’acteur connecté à l’application et de l’évolution du ticket
dans le Workflow.

Durant cette phase de travail j’ai proposé dès façons gra-


phiques de représenter certaines fonctions qui restaient floues. En particulier
pour la manière de lier deux tickets entre eux et de supprimer ce lien, j’ai pro-
posé de faire une liste de tickets, puis de représenter ce lien par des capsules
avec le nom du ticket, et de supprimer ce lien avec une icône présente sur
chaque capsule.

Toutes ces maquettes ont été mises en ligne sur l’applica-


tion MarvelApp. Cela m’a permis de faire très rapidement des liens entre les
pages à l’aide de boutons, et d’organiser ainsi un parcours logique entre toutes
les vues. Ce parcours est mis en parallèle avec le diagramme BPMN afin
de pouvoir identifier le nom de chaque fonction. Chacune des fonctions du
diagramme a aussi donné lieu à une ou plusieurs Story sous forme de Tickets
dans Jira afin de pouvoir organiser toutes les tâches de développement à
venir. Chacun de ces Tickets renvoie vers la maquette visuelle sur MarvelApp.
Il y a ainsi toutes les données et les demandes de la phase de conception qui
sont disponibles facilement à l’équipe de développement.

P.15/36
Développement
Le FrameWork Angular
Angular est une plateforme de développement en Javascript
qui se structure avec des components. En théorie, elle violes plusieurs règles
de l’architecture MVC, et elle est associée à une architecture Modèle-vue-vue
modèle, mais en pratique elle permet de la même manière de séparer la vue
de la logique et de l’accés aux données. Pour ce projet j’ai utilisé l’interface par
ligne de commande sous mac OSX pour créer les composants sur lesquels
j’ai travaillé.

Chacun d’entre eux est composé d’un fichier typeScript (.ts)


qui contient le Modèle et dans lequel on met la logique de l’application, à la
manière du Contrôleur. Il exporte une classe avec des variables et qui contient
un constructeur et une fonction ngOnInit() qui lance le chargement des don-
nées. Un fichier .html et .scss composent la vue et présentent ces données,
puis renvoient des formulaires au contrôleur. Les services sont gérés en
dehors, dans d’autres fichier .ts, qui communiquent avec la base de donnés en
appelant les fonctions du fichier API.service.ts.

Les Subscriptions permettent d’avoir la mise à jour en temps


réel de la base, et aussi de communiquer en asynchrone, mais il faut les fer-
mer avec une fonction ngOnDestroy(). Angular permet de bien structurer ses
documents avec des directives qui permettent de faire des listes, mais aussi
de modifier les attributs du html en fonction des attributs d’un l’objet en ajou-
tant des classes css.

Les formulaires laissent faire facilement de l’envoi de don-


née aux services et on peut les valider directement dans les vues avec des
formControl. La navigation est gérée depuis le fichier app-routing.module.ts
où l’on déclare chacune des URL que l’on veut rendre accessibles. Enfin c’est
le fichier app.component.html qui est lancé, contenant la barre de navigation,
le viewer 3d Cupix dans un <iframe>, et le menu de navigation latéral dans une
balise <router-outlet>.

P.16/36
Développement
Le FrameWork Angular

P.17/36
Développement
Le composant
link-ticket-parent Le Modèle
link-ticket-parent.component.ts
Ce composant intervient dans le processus de liaison entre
deux tickets de signalement. C’est une opération “manuelle” qui requiert une
intervention humaine et une prise de décision qui nécessite une connaissance
pratique des locaux. Chaque component ticket-détail contient un bouton qui
redirige le contenu de la balise <router-outlet> pour permetre l’affichage du
composant ticket-parent.

Ce contrôleur contient une variable tickets qui porte une


liste de tickets sous forme d’un tableau JSON renseigné par tickets.service.ts.
Cette variable est mise à jour en continu depuis la base de donnée grâce à un
objet Subscription importé depuis la librairie RxJS. Cette Subscription prend
en compte toutes les modifications sur un objet défini comme Observable, et
met à jour automatiquement l’objet qui exécute cette Subscription. Comme il
est permis de définir plusieurs ticket enfant à la fois, un tableau d’id userSelect
est créé en variable pour être renseigné par la vue et envoyé par la validation
du formulaire.

P.18/36
Développement
Le composant
link-ticket-parent Le Service
tickets.service.ts
La variable tickets ayant une Subscription est privée afin
d’assurer la sécurité de ce canal de communication. Le fichier tickets.service.
ts va interroger la base de données pour obtenir un tableau JSON de tickets,
et interpréter chaque objet avec différentes fonctions. Elles servent par
exemple à donner un sens intelligible aux listes de données des Enums. Ce
service trie aussi les tickets en fonction de leur statut, en ne faisant pas ap-
paraître ceux qui sont archivées, ou ceux dont le statut est terminé. Enfin il va
aussi corriger leur date en fonction du fuseau horaire.

Un fois que les fonctions de mise en forme ont eu lieu pour


chacun d’entre eux, on renvoie la liste au contrôleur qui l’avait appelé, et qui
pourra le transmettre à la vue. C’est l’approche API first qui permet de dévelop-
per le Front selon le besoin et de le faire évoluer facilement tout en s’intégrant
aux systèmes existants grâce l’utilisation d’un intermédiaire : une API REST.

P.19/36
Développement
Le composant
link-ticket-parent La Vue
link-ticket-parent.component.html
Cette vue va utiliser la directive ngFor afin de faire une
boucle dans la liste des tickets. Pour chaque ticket elle va afficher les infor-
mations suivantes : la couleur dépendante de sa priorité, son titre, son statut,
les équipements liés, son type, et les informations horaires qui le concernent.
Pour obtenir la couleur, un attribut [style.color] va exécuter la fonction getPrio-
rityColor(ticket) qui retourne une couleur correspondant à sa priorité.

Sur chaque ticket est aussi placé une checkbox, dont le


changement d’état va déclencher la fonction getUserSelect() en lui envoyant
l’événement et l’id du ticket auquel elle appartient. Cette fonction va d’abord
vérifier si l’objet qui a déclenché l’événement est checked, auquel cas elle va
ajouter son id au tableau userSelect. Si la checkbox est déselectionnée, alors
une boucle est faite dans userSelect afin de retirer l’id du ticket qui vient d’être
déselectionné. Lorsque l’on clique sur le bouton valider, on peut renvoyer
directement la liste des tickets sélectionnés, afin de faire apparaître ses cap-
sules dans la fiche detail-equipement, et de stocker ce tableau dans le champ
parent de l’entrée de la table ticket sur laquelle on travaillait.

Cette relation d’un ticket à d’autres tickets est dite relation ré-
cursive. On la retrouve dans un autre objet de la base de donnée : l’équipement
qui peut être lié à un sous équipement qui le compose, dont chacun aurait une
entrée différente dans la base de donnée.

P.20/36
Développement
Le composant
intervention-planning Le Modèle
intervention-planning.ts
Ce processus de l’application sert à transformer un ticket du
type “demande de maintenance” en type “demande d’intervention”. Pour cela,
un acteur ayant l’autorisation de prendre des décisions financières (Property
Manager) doit renseigner 5 informations indispensables.

Il va choisir un domaine technique issu de la table domaine,


remplie manuellement pour chaque client. La sélection de ce domaine va
filtrer la liste des différentes missions qui ont lieu dans le bâtiment, afin de ne
proposer que celles liée à ce domaine, et le Property Manager pourra choisir
une mission s’il en reste plusieurs. Cela filtrera la liste des différentes organi-
sations qui sont en charge de cette mission, afin de permettre de sélectionner
quelle société sera en charge de l’intervention. On permet enfin à l’utilisateur
de choisir à quel profil de cette organisation sera envoyé la demande d’inter-
vention, en listant avec un filtre les différents employés de cette société qui
ont un compte SmarterPlan.

Enfin, le Front a développé un calendrier qui affiche les jours


de façon hebdomadaire, et c’est à partir de cet élément que le property mana-
ger va choisir une date pour cette demande d’intervention. Lorsque le formu-
laire est validé, on envoie un mail au profil sélectionné à partir d’un template
qui contient toutes les informations nécessaires à l’intervention.

P.21/36
Développement
Le composant
intervention-planning Le Service
tickets.service.ts - API.service.ts
Ce Component appelle le fichier tickets.service.ts afin de
porter les informations principales utiles à la prise de décision sur l’interven-
tion. Le ticket sélectionné sera appelé par le modèle (intervention-planning.
ts) à l’aide de son ID et transmis à la vue (intervention-planning.html) avec son
titre et sa description.

Une fois le formulaire rempli sur la page et validé, il déclen-


chera plusieurs actions. D’abord le changement de type de ticket, mais aussi
la création d‘un event lié à ce changement, de type “request for intervention” et
au statut “planned” avec sa date de création dans le champ createdDate et la
date sélectionné par l’utilisateur dans le champ estimateStartDate. Le champ
asignee du ticket sera aussi mis à jour avec l’id du profil qui aura été sélection-
né par le filtrage des 4 listes. Enfin, un mail est est envoyé à l’adresse rensei-
gnée par le profil assigné.

P.22/36
Développement
Le composant
intervention-planning La Vue
intervention-planning.html
Comme toutes les vues de l’application, ce sont des élé-
ments Bootstrap qui sont utilisés, et c’est à l’aide de row et de col que sont
organisé les balises <div> de la page. Pour intervention-planning.html, c’est
la création d’un calendrier hebdomadaire décalable en incrémentant et en
décrémentant les semaines qui m’a demandé le plus de travail. J’ai repris un
élément du composant dashboard qui avait déjà été développé auparavant et
qui affichait le jour actuel dans un style différent.

Je l’ai fait évolué pour ajouter 2 interactions : le changement


de semaine, et la sélection d’un jour. Pour cela, il va falloir envoyer au template
HTML un objet week de type array, qui contiendra tous les jours de la semaine
en cours, dont le jour actuel. Pour cela on obtient un number avec la fonc-
tion getDate() qui équivaut au jour du mois, puis le jour de la semaine avec
la fonction getDay() qui est compris entre 1 et 7. En soustrayant le deuxième
au premier, on obtient le premier jour de la semaine courante, et on fait une
boucle de sept tours pour avoir tous les jours de la semaine. Mais pour pou-
voir décaler la semaine jusqu’à changer de mois, cette opération ne suffit pas
car un décalage se produit lorsque getDay() repasse à zéro.

J’ai pour cela convertit ces deux valeurs en horodatage


Unix, c’est à dire en nombre de secondes écoulées depuis le 1er janvier 1970
à minuit UTC avec la fonction getTime(). Ainsi la date du premier jour de la
semaine devient absolue et n’est plus relative au début du mois. Enfin j’ai
créé une variable offset, qui représente le nombre de semaines de décalage
par rapport à la semaine courante, et qui va multiplier par 7 les valeurs de
la boucle qui ajoute les jours dans le tableau week. Cette variable offset est
incrémentable et décrémentable par des icônes cliquables dans la vue en
appelant des fonctions du contrôleur qui réinitialisent la semaine, la calculent
et la renvoient à la vue.

P.23/36
Développement
Le composant
intervention-planning Le Formulaire
intervention-planning.html
Cette vue permet de renseigner un formGroup angular du
nom de planIntervention qui a été déclaré et initialisé dans le Côntroleur.
Chacune des listes, domaine, mission, organisation, intervenant, enregistre le
choix de l’utilisateur et renvoie la valeur associée à sa clef.

De même, chaque fois qu’un jour est sélectionné dans le


calendrier, on attribue la date à la variable select du contrôleur, et si dans la
vue cette date apparaît dans le calendrier, son style est modifié pour que le
chiffre soit en exergue. Lorsque l’on appuie sur le bouton valider, on exécute la
fonction onSubmitForm() que l’on a associé à la balise <form> contenant un
bouton de type=”submit”. Elle récupère sous forme de tableau JSON les paires
clef-valeurs ainsi que le contenu de la variable select, équivalent au dernier
jour sélectionné dans le calendrier.

P.24/36
Conclusion
Succés
Durant ce stage j’ai pu découvrir plusieurs dimensions dans
un projet informatique. J’ai à la fois eu la chance de pouvoir travailler à la
conception et au développement. D’abord en faisant l’analyse du besoin que
j’ai restitué sous forme d’un logigramme BPMN reprenant le cas d’utilisation
qui serait le plus fréquent et le plus utile aux premières versions commerciali-
sables de l’application. Puis j’ai élaboré les 40 maquette avec Photoshop et j’ai
renseigé toutes les demandes dans 67 tickets Jira détaillant le cas d’usage,
le comportement actuel, les critères d’acceptations, et d’autres informations
additionnelles. Ainsi j’ai pu plonger dans les détails de chaque tâche technique
qui allait être nécessaire pour réaliser les fonctions du workflow. Enfin, dans
le deuxième mois, j’ai pu développer avec l’équipe en charge du Front-End et
réaliser cinq composants différents répondant aux besoins que nous avions
identifiés.

J’ai aussi dû m’assurer que toutes les fonctions nécessaires


aux diagrammes pouvaient être retenues de façon persistante dans la base.
Ainsi j’ai souligné la difficulté à lier un ticket à un équipement en analysant le
modèles des données. Cette fonction était pourtant prévue par l’équipe Front.
Cela à donné lieu à une évolution de la base en créant une nouvelle table.

La connaissance du workflow du ticket m’a aussi permis de


remplir les différentes listes de données pour les Enum, en m’assurant que
tous les cas logiques pouvaient être représentés sur chaque objet de la base.

Enfin, je suis content d’avoir pu travailler en Javascript sans


l’avoir étudié pendant l’anné. La réalisation du calendrier hebdomadaire fut
une expérience amusante, car les dates sont un sujet intéressant pour en ap-
prendre plus sur les principes de fonctionnement d’un langage.

P.25/36
Conclusion
Bonnes pratiques
Le travail en collaboration avec d’autres professionnels de
l’industrie informatique m’a appris des méthodes pour pratiquer ce métier
correctement. La méthodologie Agile est très intéressante, et j’ai pu expéri-
menter ce processus de création très ritualisé. J’ai pu utiliser Git sur un projet
avec plusieurs participants et un besoin de changement permanent, et j’ai
appris à travailler mieux avec les Branches ainsi que les ajouts de fichiers
à chaque Commit. Enfin j’ai compris qu’il était très important de formaliser
les cas d’usages assez tôt dans le développement, ceci afin de pouvoir faire
communiquer ensemble les différents membres d’un projet informatique, et
d’assurer que tous les besoins soient implémentés à la fois dans le Front-End
et le Back-End.

Analyse critique
En revenant sur la répartition de mon temps de travail et le
déroulement de mon stage, il me reste des points à améliorer.

Le travail avec git est très complexe, mais permet d’être


efficace. Même si je me suis amélioré, je n’ai pas réussi à mettre sur le Reposi-
tory le résultat de mon travail pour la première Sprint Demo. Il reste des zones
d’ombres sur l’utilisation de cet outil qui s’éclairciront avec la pratique.

Le cas nouveau du télétravail ne me permet pas d’envisager


des collaborations d’une autre manière que celle qui a eu lieu. Toutefois, je n’ai
pas l’assurance que les procédures de la méthode Agile et Scrum sont indis-
pensables pour des groupes de travail restreints. J’ai aussi trouvé que nous
avions fait parfois des réunions trop longues. Pour éviter cela il faut absolu-
ment faire la liste des points à aborder et très vite recadrer les conversations
quand elles dérivent, pour passer au sujet suivant. Mais comme ces temps
sont les seuls où l’équipe communique de vive voix, ils étaient indispensables.
Tout ne peut pas s’échanger avec des emails et des tickets Jira.

Enfin je suis déçu de ne pas avoir pu aborder plus en détail


les sujets qui m’avaient initialement attirés vers ce stage, c’est à dire la com-
puter vision et la photogrammétrie. Mais ces domaines sont vastes, et la for-
mation ne m’avait pas donné les connaissances pour pouvoir les comprendre
facilement.

P.26/36
Conclusion
Remerciements
Thai-Bin Phan
mon maître de stage, qui m’a donné la chance de participer à
l’aventure SmarterPlan et qui m’a montré ce qu’était piloter un projet informa-
tique à partir d’une vision analytique.

Duc-Ahn Pham
formateur à l’AFPA, pour son entraînement intensif des es-
prits à la communication avec les ordinateurs.

Marc lambert
formateur à l’AFPA, pour ses connaissances dans la science
informatique et son humour inimitable.

Arnaud Palin Sainte Agathe


collaborateur de Smarter Plan qui a eu la pédagogie de m’ap-
prendre tout ce qu’il pouvait et que je lui demandais.

Vanessa Sultan
manager à l’AFPA, qui a su maintenir l’organisation de la for-
mation malgré la période d’urgence sanitaire.

Samir Akarioh
mon camarade de stage plein de bonne volonté qui travaille
à des heures improbables.

P.27/36
Cas d’usage MVP :
Incident et Intervention

P.28/36
P.29/36
P.30/36
P.31/36
P.32/36
P.33/36
Le composant
intervention-planning La Maquette

Le composant
intervention-planning La Page

P.34/36
Le composant
link-ticket-parent La Maquette

Le composant
link-ticket-parent La Page

P.35/36
P.36/36

Vous aimerez peut-être aussi