Mémoire Entretien et développement d’une plateforme de gestion d…lipari/cs/iagl/memoires/... · 2019-06-27 · Master IAGL 2018-2019 - Université de Lille R e m e r c i e m

Pierric Cotton master 2 - IAGL - 2018/2019

Mémoire Entretien et développement d’une plateforme de gestion d’entreprise.

Référent entreprise : Michaël Macquart.

Référent université: Clément Quinton.

Master IAGL 2018-2019 - Université de Lille

Remerciements

Michaël Macquart, pour son encadrement durant cette alternance et son suivi dans la rédaction de ce mémoire.

Clément Quinton, pour sa réactivité, sa présence et ses conseils tout au long de mon alternance.

Frédéric Cotton et Catherine Hoeck, pour la relecture orthographique et le soutien continu. Thomas Carrara, pour son travail en tant que binôme et l’aide à la rédaction de la documentation.

L’équipe Giga dans son ensemble, pour cette expérience, la dynamique du groupe et l’aide mutuelle qu’on a su s’apporter.

Mémoire - Pierric Cotton 2


Table des matières

Introduction 4

Entreprise 5

Travail, équipe et déroulement 6

L’application : Giga 8 Aspect business de l’application 8 Aspect technologique de l’application 11

Back-end 11 Persistance 12 Front-end 12 Déploiement - mise en production 13

Méthodologie et environnement de développement. 13 Axes d’amélioration et ressenti. 14

Focus : la scission de commande 17 Commande 17 Ordre de Mission 18 Bon de Commande 18 Rapport d’activité 20 Implémentation 20

Conclusion 23

Annexes 24 Annexe 1 : Création de commande. 24 Annexe 2: Création d’ordre de mission 25 Annexe 3 : Création de bon de commande 26 Annexe 4: Rapport d’activité 26 Annexe 5 : Diagramme d’activité 27 Annexe 6: Manuel scission de commande 28 Annexe 7 : Exemple récapitulatif du fonctionnement 32



Introduction

Ce travail a pour but de présenter un résumé de mon alternance chez UNIS, une entreprise de consultance basée à Villeneuve d’Ascq. L’idée est de présenter mon travail, tant dans l'aspect pratique que de l'expérience personnelle que j'en ai retiré. J’ai été assigné, avec les autres alternants, au projet Giga, la plateforme de gestion de l’entreprise. L’objectif était de nous faire monter en compétence sur un projet en interne afin que les conséquences de nos apprentissages restent dans le cadre privé de l’entreprise. Durant mon alternance, j’ai donc pu apprendre à utiliser plusieurs framework ou outils, tels que Spring ou MyBatis, à travers l’entretien du logiciel ou le développement de nouvelles fonctionnalités sur Giga.

Pour vous rapporter mon travail, je commencerai par une présentation de l’entreprise pour ensuite passer à l’explication du fonctionnement de mon équipe et de mon travail de manière générale. Une fois le déroulement global connu, je présenterai le logiciel Giga dans son ensemble. Je passerai sur l’aspect technologique mais aussi l’aspect business de l’application et les axes d’amélioration que j’ai identifiés. Afin d’illustrer ma manière de prendre en main les implémentations sur la plateforme, un focus sur une amélioration conséquente clôturera ce travail. Il concerne la mise en place d’un système de scission de commande afin de faciliter le travail du secrétariat. Le passage sur les implications de l’implémentation et sur les détails de celle-ci permettra de se concentrer sur les difficultés que j’ai pu rencontrer lors du développement ainsi que sur les réactions que j’ai pu avoir pour passer outre, que ce soit concernant la reprise du code existant ou concernant l’implémentation en tant que telle.

Bien que ma mission soit de la TMA classique, l’expérience que mon stage m’a apportée est considérable. Tout au long de ce travail, j’ai essayé de mettre en avant mon analyse et mon ressenti concernant plusieurs sujets: l’application existante, la méthodologie de l’équipe, les pistes d’améliorations ou les choix technologiques. Giga s’est révélé être un projet très intéressant et très formateur, j’espère que ce travail pourra vous transmettre un aperçu du bienfait que m’a apporté mon alternance.



Entreprise

La société UNIS, qui m’a engagé, fait partie d’un groupe appelé Astrea Management basé à Villeneuve d’Ascq. Ce groupe est composé de quatre entités, avec chacune ses responsabilités :

● SKILLS : besoins fonctionnels et management. ● UNIS : technologies de l’information. ● ACSSI : intégration de solutions. ● KUBIK : intégration et consulting.

C’est une entreprise de consultance dont le but est d’accompagner ses clients

dans leurs projets d’évolution de leur système d’information. Elle propose des solutions

couvrant tout le cycle de vie d’un projet, à savoir, la compréhension du besoin, la

construction des solutions, la gestion des infrastructures, la maintenance des

applications (sous forme de TMA en centre de service) et la conduite du changement.

Son activité est présente dans le nord de la France ainsi qu’en Belgique depuis près de

trente ans et compte actuellement plus de deux cents collaborateurs.

L’entité dans laquelle j'étais s’occupe de l'intégration des solutions métiers, du

développement orienté objet, de l’intégration et la consultance SAP et de la gestion de

l’infrastructure. J’étais plus précisément engagé dans le pôle développement qui réunit

toutes les compétences autour des architectures sur des sujets tels que

Internet/Extranet, les solutions collaboratives et le développement d’applications JAVA,

.NET ou SOA.



Travail, équipe et déroulement

J’ai été engagé chez UNIS pour être développeur-analyste en Java. De manière théorique cela comprend plusieurs responsabilités telles que l’entretien de l’application Giga ou l’analyse, le testing et le développement de nouvelles évolutions sur ladite application.

Pour faire un bref récapitulatif de mon expérience, je suis monté en compétence

du mois de septembre au mois de novembre pour passer ensuite sur quelques petites implémentations ou corrections mineures jusqu’en février. Après cela, j’ai été assigné en binôme sur une évolution assez conséquente qui devait permettre à nos utilisateurs de scinder une commande ( nous reviendrons sur ce point plus tard dans ce travail). Une fois cette évolution terminée, je suis resté sur l’application par le biais de la résolution de divers bugs ou l’implémentation d’évolutions moins conséquentes. En parallèle, il fallait parfois agir sur l’application de manière ponctuelle pour gérer tous les imprévus que l’utilisation d’un tel logiciel peut engendrer. Il nous arrivait fréquemment de devoir tester les implémentations d’un autre développeur (peer test) ou simplement d’aider un collègue dans son travail.

Notre équipe s’est composée de sept à dix développeurs en fonction du moment

de l’année. Avant le mois de février, elle ne comprenait que des alternants et des développeurs en reconversion professionnelle. Un développeur senior nous a rejoint en cours d’année pour apporter un peu d’expérience dans l’application.

L’équipe étant donc principalement composée d’alternants, cela a impliqué une

gestion d’équipe assez compliquée. Il n'était pas vraiment possible de mettre en place de méthodes agiles ou de faire un suivi du travail des autres car chaque alternant avait un régime de travail différent. La majorité de la communication se faisait via l’outil de ticketing ou sur slack ce qui demandait un effort supplémentaire au développeur pour se tenir au courant de l’évolution de l’application. Il était très difficile de suivre toutes les évolutions simultanées et il n'était pas rare qu’un incident lié au manque de communication survienne dans une implémentation quelconque du projet. La deuxième partie de l’année a vu ces incidents se réduire car la majorité des alternants sont passés en plein temps et la communication au sein de l’équipe s’en est naturellement améliorée. Malgré l’absence de structure qu’aurait pu apporter l’agilité, la gestion du projet était correcte et notre travail de plus en plus efficace grâce à la proximité des développeurs.



L’application étant uniquement utilisée en interne, il faut comprendre que lorsqu’il

est question du client cela concerne des membres de l’entreprise. Plus précisément ce sont des corps de métiers liés à la gestion de l’entreprise :

● Le secrétariat qui s’occupe de l’encodage des commandes, ordres de missions, bons de commandes ou de la gestion des frais et remboursements des collaborateurs.

● La comptabilité pour tout ce qui concerne la gestion des factures et des paiements aux clients.

● Les ressources humaines pour l’encodage des collaborateurs et consultants ou la gestion de ceux-ci. A cela s'ajoutent les demandes des collaborateurs ou des responsables de

l’entreprise pour les évolutions (ou corrections) dans l’application. Le contact avec le client est donc facilité par la proximité géographique, tout le monde travaillant dans le même centre de service. Bien que la demande des clients passe par notre responsable, il est du ressort du développeur de contacter le client si le besoin s’en fait sentir. Il est fréquent qu’il faille prévoir un rendez-vous avec lui pour définir les maquettes ou pour redéfinir le besoin. Il faut bien comprendre que ce sont les clients qui définissent le besoin et que les évolutions du logiciel dépendent donc directement d’eux . A plusieurs reprises nous avons dû modifier notre développement pour qu’il soit plus en adéquation avec la demande. D’une part nous étions très libres des solutions logicielles que nous mettions en place mais d’autre part nous étions très contraints par le rendu visuel ou l’ergonomie de la solution.



L’application : Giga

Aspect business de l’application

L’application dont notre équipe s’occupe s’appelle donc Giga, elle est scindée en deux parties distinctes: Admin et Collab’. Globalement, la partie Admin est bien plus conséquente que la partie Collab’ puisqu’un administrateur sera capable de faire tout ce qu’un collaborateur peut faire en plus de toutes les fonctionnalités de gestion. L’application est subdivisée en cinq, une subdivision par entreprise et celle d’Astrea. Chaque collaborateur sera forcément connecté sur l’entreprise par laquelle il est employé mais côté administration, la première chose à faire, après la connexion, est de choisir l’entreprise pour laquelle on va travailler. La division n’implique pas de changement de fonctionnalité mais seulement un changement de design. Le fait de scinder l’application par entreprise a aussi pour but de faciliter le développement en back-end et d'alléger les accès à la base de données.



Commençons par détailler les fonctionnalités de la partie Collab’.

● Le dashboard reprend tous les éléments sur lesquels l’utilisateur doit encore avoir un impact ( s’il doit confirmer ou remplir un document par exemple).

● Dans absences, le collaborateur peut prendre ou consulter ses jours de congé, RTT et ponts. Il peut aussi consulter l’historique de sa prise de congés.

● Ordres de mission reprend toutes les missions auxquelles le collaborateur est assigné ( en cours ou révolues).

● Avances de frais permet de faire des demandes d’emprunts à l’entreprise. ● Notes de frais permet au collaborateur de renseigner ses dépenses

remboursables (totalement ou partiellement) par l’entreprise. Il faut remplir une note de frais chaque mois.

● Rapports d’activité est un des onglets les plus utilisés. Cela permet au collaborateur de renseigner, jour par jour, ce sur quoi il a travaillé. Nous aurons l’occasion d’en reparler.

● Placements concerne tout ce qui est intéressement et réinvestissement dans l’entreprise.



● Profil permet tout simplement de consulter les informations relatives à son propre profil sur Giga. On ne peut pas les modifier, c’est réservé à la partie Admin.

La partie Admin quant à elle mérite qu’on s'arrête un peu plus longuement sur ses fonctionnalités.

● Le Dashboard reprend également tous les éléments sur lesquels le gestionnaire est censé avoir un impact. Validation de rapports, notes de frais, congés,... la liste est longue. Concrètement cela reprend tous les éléments qui sont normalement ailleurs dans l’application et pour lesquels il y a du traitement à faire.

● Gestion des collaborateurs comprend la gestion des collaborateurs eux-mêmes mais aussi la gestion de leurs congés, leurs arrêts maladie et leurs visites médicales.



● Gestion des sociétés permet de configurer les informations de l’entreprise de manière générale. Cela comprends les comptes, le paramétrage de la société,...

● Gestion des clients comprend la gestion des informations des clients mais aussi des commandes et des factures. Ces trois entités sont fortement liées, elles se retrouvent donc au même endroit.

● Gestion des frais concerne tant les avances de frais que les notes de frais. Le gestionnaire doit valider les demandes des collaborateurs mais ils peuvent aussi être créateurs à sa place.

● Gestion des activités englobe tout ce qui concerne les rapports d’activités. ● Gestion des rémunérations comprend deux grandes parties distinctes : les

salaires et l'intéressement. ● Gestion des sous-traitants permet d’ajouter un sous-traitant ou de

modifier ses informations. ● Profil permet de voir nos droits sur l’application et sur les diverses

entreprises en fonction du compte connecté. ● Restrictions permet de voir les droits sur l’application d’un autre compte

que le sien. ● Paramètres contient tous les paramétrages possibles de l’application

(environ 25 onglets). ● Patch note est simplement une page HTML reprenant les changements

de l’application en fonction des mises en production. Il est arrivé que de nouvelles fonctionnalités soient présentes sans que l’utilisateur le sache. C’est pour répondre à cette problématique qu’est apparue la patch note.

Aspect technologique de l’application

Back-end

Giga, d’un aspect plus technologique, est une application spring boot donc développée en J2E avec le framework spring. La gestion des dépendances est assurée par Maven. C’est une application monolithique, ce qui n’est pas idéal mais les conditions dans lesquelles le projet a été lancé rendent ce choix compréhensible. En effet, le projet débuté il y a un peu plus de 5 ans, a été entretenu uniquement par des alternants ou des développeurs juniors. Une architecture en microservices ou hexagonale était un choix trop dangereux pour le lancement de l’application et il est relativement coûteux de changer l’architecture de l’application en cours de développement. Dangereux parce qu’il est plus compliqué pour des programmeurs sans expérience de quitter l’architecture monolithique qui leur est plus familière. La montée en compétence aurait été meilleure mais dans la mesure du possible il fallait un



produit fonctionnel au plus vite donc les développeurs se sont tournés vers ce qu’ils connaissaient le mieux. Pour le changement d’architecture, il faudrait modifier le back-end pour en faire une API ( ce qui n’est pas le cas actuellement) tout en gardant un logiciel fonctionnel. Une fois fait, il serait nettement plus simple de partir sur une architecture différente ou de changer de technologie, notamment en front mais nous y reviendrons. Il semble que ce soit en projet pour Giga mais je ne serai probablement plus sur cette application d’ici le lancement des changements.

Persistance

La base de données (DB) est une instance PostgreSql, englobée par MyBatis (un framework Java pour la persistance des données et qui s’occupe de l’intégrité de la DB ). La majorité du travail concernant ce genre de software est la configuration, celle-ci étant déjà faite, je n’ai pas été amené à travailler énormément avec ce framework.

A la différence d’un ORM, MyBatis s’occupe de lier directement une interface

Java à des méthodes SQL stockées dans un fichier XML. Cela nous permet d’avoir la main sur nos queries et donc de les optimiser mais cela implique par contre qu’il faille les écrire nous-mêmes. C’est donc à double tranchant car nous avons la possibilité d’optimiser nos requêtes, comme un ORM ne nous le permettraient pas, mais en contrepartie, nous en sommes entièrement responsables.

Front-end

Concernant les technologies front-end, nous sommes sur des choix un peu plus anciens. Le visuel de l’application est géré par des Java Servlet Pages (JSP) et Jquery, une librairie javascript. Ce sont d’anciennes technologies qui ont quelque peu pâle allure en comparaison avec les nouveaux framework comme Angular. L’utilisation des JSP s’explique aussi par l’ancienneté du projet simplement parce qu’à l’époque les nouveaux framework émergents n’étaient pas encore suffisamment stables que pour être choisis pour le développement de Giga. Un changement vers une nouvelle technologie serait préférable. Il est envisagé actuellement mais cela demanderait beaucoup de ressources en terme de temps. D’autant plus que le back n'étant pas une API, il faudra attendre un changement de ce côté avant d’envisager une migration du front-end.

L’ensemble de l’application, au niveau esthétique, est pris en charge par un

thème Metronic ( bootstrap), il suffit juste au développeur de reproduire l’HTML de sa JSP en fonction des pages déjà existantes.



Déploiement - mise en production

D’un aspect plus orienté infrastructure, l’application n’est pas en déploiement continu. Dans un premier temps, le déploiement était du ressort du pôle infrastructure. Nous nous arrangions avec eux et le client pour définir les mises en production de l’application. Actuellement, les mises en production sont prises en charge par le développeur senior qui nous a rejoint et leur programmation ne dépend plus que de la communication avec le client. Le client est en effet concerné car la mise en production implique forcément une interruption du service.

Nous n’avons pas de système spécifique pour établir les mises en production. Comme elles sont relativement simples à mettre en oeuvre, nous en faisons régulièrement quand un nombre correct de tickets est résolu. Il arrive parfois qu’un ticket urgent demande une mise en production immédiate s’il corrige un bug handicapant ou si la fonctionnalité est urgente. Pour ce faire, nous générons simplement un fichier war de la branche master de l’application et nous la transférons au responsable du déploiement du fichier sur le serveur. Cela concerne également les mises en recette qui suivent le même processus.

A l’instar de la DB, l’application est hébergée sur un des serveurs du centre de service. Leur maintenance est donc assurée par le pôle infrastructure. Méthodologie et environnement de développement.

Côté méthodologie, comme je l’ai dit précédemment, nous ne sommes pas en philosophie agile. Nous travaillons uniquement avec des tickets, sur une des applications de l’entreprise. La responsabilité de produire les tickets est principalement celle de notre supérieur et, par après, du développeur senior puisque c’est à lui que sont communiqués les besoins du client. Le développeur peut cependant créer des tickets s’il se rend compte qu’un travail doit être fait et qu’il n’a pas le temps de s’en occuper directement. Il est usuel qu’un besoin de refactoring issu d’une incohérence ou d’une erreur dans le code soit découvert pendant le développement d’un autre ticket et soit remonté sur notre outil de ticketing.

Le partage de code et la concurrence sont gérés par Git. Chaque ticket est développé sur une branche dédiée et une fois l’implémentation terminée, elle est fusionnée sur la branche master de notre répertoire Git.

La prise en charge d’un ticket implique parfois l’analyse du problème. Quand ce n’est pas le cas c’est à notre responsable que revient la rédaction d’un cahier de charge documentant l’évolution ou la correction requise. Les tâches sont principalement gérées par une seule personne mais quand la quantité de travail le justifie, nous sommes parfois en peer programming ou en binôme (deux développeurs sur deux machines). Le testing unitaire de l’implémentation est du ressort du programmeur également.



Une méthode d’orienté aspect passe, au lancement des tests, sur toutes les

méthodes des services et des data access object (DAO) vérifiant qu’au minimum un test de succès et un test d'échec soient implémentés. Une fois l’implémentation terminée et testée, un autre développeur passe sur la branche pour vérifier et pour tester (en tant qu’utilisateur) les diverses fonctionnalitées impactées. Le but étant à la fois de tester l’implémentation mais aussi de vérifier que celle-ci n’impacte pas l’existant. Pour les grosses implémentations nous faisons une mise en recette sur un serveur dédié pour faire un test utilisateur plus poussé. Cela permet aussi à notre responsable d’appliquer une supervision. Les mises en recette sont effectuées par l’infrastructure également.

Pour nous aider dans le développement et l’entretien de l’application, nous utilisons plusieurs outils. L’outil de ticketing ou la gestion des logs se font sur des logiciels développés en interne et nous sommes amenés à utiliser un logiciel de gestion de tickets (GLPI) pour contacter l’infrastructure.

Axes d’amélioration et ressenti.

Si nous résumons les axes d’améliorations, ils concernent le suivi de l’implémentation, le déploiement et l’état du code de manière générale.

● Le déploiement demanderait une révision afin d’améliorer le processus et d’éviter les interruptions de service. La volonté de se diriger vers du déploiement continu serait la plus logique. Le pôle infrastructure est cependant, lui aussi, principalement constitué d’alternants. Les restrictions de l'hébergement et le manque d’expérience n’ont pas permis d’envisager ce genre de solution. Dans l’état actuel ce n’est pas vraiment une priorité, le système actuel étant fonctionnel. Notons cependant la volonté de l’entreprise de se diriger vers le déploiement continu. Nous l’avons constaté lors des diverses présentations ou formations dispensées pendant notre alternance. J’ai moi-même participé à une formation docker avec l’équipe infrastructure.



● Le suivi du travail des développeurs n’est pas idéal non plus. N’ayant pas assez d’expérience dans l’équipe, il nous était difficile d’estimer la qualité du travail des autres. Notre responsable s’occupait du suivi fonctionnel des choses et notre développeur senior n’avait pas le temps de s’occuper d’une tâche aussi conséquente. C’est probablement ce manque de suivi qui implique le problème suivant.

● L’état du code de manière globale est également à améliorer. C’est un travail de longue haleine et chaque intervenant sur l’application en est responsable. L’application était truffée de bugs et était d’une lenteur inexpliquée quand le logiciel a été pris en main en début d’année scolaire. Bien que ce ne soit pas encore tout à fait réglé, nous avons identifié et corrigé beaucoup de code superflu ou de traitement incorrect. Nous pensons que ces bouts de codes en plus de la qualité des accès DB ont provoqué ladite lenteur de l’application. Nous devions donc en permanence être attentifs sur le code existant et nous devions nous assurer de sa qualité avant de s’en inspirer pour de nouvelles implémentations. La qualité du code s’est cependant améliorée au fil du temps. L’équipe s’étant étoffée tout au long de l’année, nous avons pu sporadiquement assigner plusieurs développeurs à la gestion du peer test ou du refactor ce qui nous a permis d’améliorer l’existant petit à petit.

● L’application est testée unitairement. Il n’existe pas de test d’intégration ou de test end to end. Ce qui rend le développement assez difficile puisqu’on n’a aucune vérification de l’impact que cela aura sur l’existant. Le pourcentage de couverture du code par les tests n’est pas très haut non plus, environ 30%. Il y a donc une grosse amélioration possible sur le test de l’application.

● La DB, quant à elle, est assez difficile à prendre en main de part sa taille

et de l’imbrication des objets business. En effet, nous parlons d’une centaine de tables en interaction. C’est de loin la plus grosse DB sur laquelle il m’a été donné de travailler, tout simplement parce qu’il est presque impossible de travailler sur de si grosses architectures dans un cadre pédagogique.Il n’est pas rare de découvrir une requête mal faite dans Giga, nous avons même dû prévoir une révision complète de nos DAO car l’application était trop lente. Plusieurs développeurs se sont occupés de journaliser chaque accès à la DB pour identifier les méthodes



trop lentes afin de les revoir et de les optimiser. C’est donc un axe d’amélioration constant.

La difficulté de prendre en main une grosse structure s’applique à toute

l’application de manière générale : la majorité des difficultés rencontrées pendant mon alternance étaient plus issues de la taille de l’application plutôt que de la technologie en tant que telle. Il est un fait évident qu’il est compliqué de faire travailler, dans le cadre des cours, des étudiants sur des applications de cette taille mais c’est un manque assez significatif dans nos compétences pour commencer à travailler correctement. Ce n’est cependant en rien insurmontable, d’autant plus que certains alternants travaillaient déjà sur l’application à mon arrivée et j’ai pu profiter de leur expérience pour évoluer plus rapidement. Il y a cependant d’autres points pour lesquels j’étais bien assez préparé. Par exemple la prise de responsabilités d’une aussi grosse application sur le répertoire Git était assez conséquent mais les cours et l’expérience sur ce logiciel étaient largement suffisants pour être à l’aise avec l’outil. Il en va de même pour les logiciels aidant au développement tels que Maven ou Jenkins.

Le projet était cependant formateur. Le fait d’être sur une grosse structure, de

devoir se retrouver dans le code d’un autre et d’avoir un contact direct avec l’utilisateur a été très intéressant.



Focus : la scission de commande Pour expliquer plus en détails notre manière de travailler, un focus sur un de mes

tickets est, me semble-t-il, la meilleure solution. Après s’être fait la main sur des tickets de petite envergure, notre responsable a déterminé un besoin utilisateur qui demandait assez de travail et qui consistait en la scission des commandes. Sachant que je suis arrivé en même temps qu’un autre développeur et que nous avons majoritairement fait notre montée en compétence à deux, notre responsable a attribué ce ticket à notre binôme. C’était donc la première fois qu’une de nos implémentations aurait autant d’influence sur l’application existante.

Pour expliquer l’implémentation, je vais d’abord passer sur le contexte business des commandes et des entités qui sont atteintes par la fonctionnalité mais sachez que le but, dans les grandes lignes, est de scinder une commande d’une durée de plusieurs mois en plusieurs commandes d’une durée d’un mois, tout en gardant les informations de la commande initiale.

● Commande (annexe 1)

UNIS étant une entreprise de consultance, l’un des concepts les plus importants est la commande. C’est sous cet objet que le lien entre une demande client et l’entreprise qui la développe est représenté dans notre logiciel. Il contient toutes les informations nécessaires à la mission que représente la demande du client. Les points qui se sont révélés êtres importants sont:

○ les dates qui bornent la mission ○ les jours offerts qui sont des jours de prestation que l’entreprise offre au

client ○ le type de prestation ○ l'état de la commande qui est temporaire ou finalisée.

Les deux premiers points nous intéressent car ce sont les seules informations qui devront être différentes dans les commandes scindées (avec l’identifiant de la commande bien évidemment). Toutes les autres informations qui caractérisent la commande seront simplement dupliquées. La troisième information qui nous intéresse est le type de prestation, uniquement parce qu’une mission de type “nombre de jours” n’est pas scindable ( contrairement au type “date à date”).

La dernière information qui nous importe est donc l’état de la commande. Souvent les secrétaires ne disposent pas de toutes les informations de la mission en même temps. Elles remplissent donc la commande avec les informations qu’elles possèdent tout en laissant la commande en “temporaire”. Une fois que tous les champs requis sont remplis, la commande peut passer en “finalisée”. Une commande ne peut



être scindée que si elle est finalisée. Ce qui est tout à fait logique car sinon il faudrait ajouter les champs manquants dans toutes les commandes dupliquées ce qui allongerait le travail plutôt que le réduire.

Il y a également des objets directement liés aux commandes qui subiront un traitement : les ordres de mission et les bons de commandes.

● Ordre de Mission (OM - annexe 2) Un ordre de mission est le lien qui est créé entre la mission émanant de la

commande et le ou les développeurs assignés à la mission. Il faudra les scinder et les lier à la commande correspondante afin que les informations restent cohérentes. Les informations qui nous intéressent sont:

○ les dates ○ son état qui peut être validé ou non validé. Un OM doit être validé par

quelqu’un d’autre que son créateur, c’est une sécurité demandée par le client.

Il a été déterminé par notre responsable qu’une commande ayant des dates différentes de son ou ses ordres de mission ne sera pas scindée. Cela n’arrivant pas souvent, il a été jugé que ce n'était pas rentable tout simplement parce que la complication que cela amène dans le développement n’en vaut pas la peine au vu de la fréquence d’apparition. Une erreur sera donc lancée au cas où la scission est prévue par l’utilisateur et que les dates ne correspondent pas. Dans le même ordre d’idée que l’état d’une commande, si l’ordre de mission n’est pas validé il faut absolument que l’utilisateur soit conscient qu’il faudra qu’il valide chaque ordre de mission lié à chaque commande scindée. Un message d’alerte prévient donc l’utilisateur si l’OM n’est pas validé mais l’algorithme ne l’empêche pas de scinder s’il valide son choix.

● Bon de Commande (BDC - annexe 3) Pour comprendre l'intérêt des bons de commandes, il faut s'arrêter quelque peu

sur le concept de sous-traitance. La sous-traitance consiste à assigner un développeur d’une autre entreprise à la mission. Comme vous le savez ASTREA est composée de plusieurs sous-entreprises, donc une commande de chez UNIS pourrait bien être assignée à un développeur de chez ACSSI. C’est ce qu’on appelle la sous-traitance interne. Il se peut aussi que la ressource assignée sur la mission vienne d’une autre entreprise, hors d’ASTREA, on parle dès lors de sous-traitance externe. Le lien entre la mission et le développeur sera représenté par un BDC dans le logiciel. Il faut savoir qu’en cas de sous-traitance interne, le logiciel va automatiquement créer une commande et un OM dans la société concernée. Dans notre implémentation, si l’utilisateur veut scinder une commande, nous devrons être attentif à scinder la



commande et l’OM généré de la même manière pour garder une cohérence des données. Donc les informations qui nous intéressent dans un BDC sont :

○ les dates qui devront concorder. ○ l’origine du développeur assigné pour traiter la scission en conséquence.

Les autres données seront simplement dupliquées et la commande ou l’OM généré sera traité comme un objet décrit ci-dessus.



● Rapport d’activité ( annexe 4) Le rapport d’activité est une sorte de calendrier qu’un collaborateur doit remplir

mois par mois afin de spécifier ce sur quoi il travaille. Plus précisément, il doit spécifier l’ordre de mission pour lequel il a travaillé, jour par jour. Cela ne semble pas lié à la scission des commandes mais le fait qu’un rapport soit lié à un ou plusieurs ordres de mission aura des conséquence que j’expliquerai plus tard. Implémentation

Voilà pour l’explication business de la partie de l’application concernée par notre refonte. Nous enchainerons sur le but et son origine.

Le besoin de scission de commande est apparu quand notre responsable s’est rendu compte que l’utilisateur ne se servait pas du logiciel comme prévu à l’origine. En effet, à l’époque, les besoins avaient été déterminés et il n’avait jamais été question de faire des commandes par mois. C’est à force d’utilisation et par souci de facilité de gestion que l’utilisateur a déterminé qu’il était préférable de faire de multiples petites commandes plutôt qu’une plus grande. Cependant, le travail était fastidieux puisque la création de la commande d’environ trois mois prend 10 minutes et que l’estimation de la création d’une commande est d’environ 3 minutes.

Il est intéressant de constater que c’est bien l’utilisateur qui détermine comment le logiciel va évoluer et pas lui qui doit s’adapter à l’application. C’est un exemple concret de la manière d’envisager le développement de Giga, l’application est faite pour l’utilisateur final et il a le dernier mot en cas de divergence d’opinion. C’était très intéressant de travailler dans ce contexte car la majorité des projets sur lesquels j’ai été amené à travailler n’étaient pas sujets aux changements. Il serait peut être judicieux d’appliquer ce genre de contraintes dans certains projets scolaires où un utilisateur fictif changerait l’énoncé en cours de développement. C’est un test assez significatif de la qualité du code. Le fait que notre architecture soit permissive aux changements prouve que le code est modulable et donc bien construit.

Comme je l’ai dit précédemment, c’est notre responsable qui a identifié le besoin. Avant de nous confier le développement, il avait déjà analysé le problème et avait identifié la majorité des difficultés que nous allions rencontrer. Il nous a donc expliqué comment les objets business interagissaient et comment gérer la plupart des cas spécifiques. Notre attention s’est donc portée sur la génération automatique des commandes et OM, le concept de finalisation de commandes et les liens entre OM,



BDC et commandes. Les cas où une commande ne pouvait pas être scindée et ceux pour lesquels il fallait prévenir l’utilisateur étaient également déjà listés. Pour s’assurer que le processus demandé soit bien compris, nous avons commencé par dessiner un diagramme d’activités qui a été validé avant que le développement ne commence (annexe 5).

Ensuite nous avons établi la liste des points chauds du développement de la scission et nous avons réfléchi à l’agencement de notre code pour qu’il puisse être de la meilleure qualité possible. Une fois l’algorithme conçu et toutes les solutions pour la résolution des points chauds définies, nous nous sommes lancés dans le développement.

Le premier constat quand l’implémentation a commencé a été que la fonctionnalité de la gestion de commandes de manière générale pouvait être réécrite. Il faut savoir que le concept de finalisation des commandes n’est arrivé qu'après le développement initial des commandes. Cependant l’ajout de cette fonctionnalité n’était pas implémenté tout à fait correctement. Il y avait des méthodes de controller en trop et certaines méthodes du service auraient pu être simplifiées. Après avoir identifié les problèmes, nous avons averti notre responsable. Il a cependant été déterminé qu’il valait mieux en faire un ticket et que nous nous concentrions sur notre implémentation. Cela nous a permi de ne pas mélanger deux implémentations compliquées et nous a assuré de quelle implémentation viendrait un éventuel bug sur l’existant.

Malgré notre préparation, nous nous sommes rendus compte d’un effet de bord qu’aurait la scission sur l’application. Il est rare qu’une commande soit directement finalisée à la création. C’est en effet compréhensible car les OM ou les BDC ne sont créables qu’une fois la commande créée elle-même. Quand bien même, c’est très rare qu’UNIS ait toutes les informations directement. Cependant, ce n’est pas parce qu’une commande est temporaire que la mission ne se lance pas. Il est donc fréquent qu’un collaborateur travaille sur une mission liée à une commande temporaire. Comme spécifié plus haut, le collaborateur se doit de renseigner tous les jours l’OM sur lequel il travaille. Donc si la finalisation d’un commande prend plus d’un mois, ce collaborateur aura donc plusieurs rapports d’activités liés à cet OM. Une fois que la commande se finalise, si l’utilisateur veut la scinder, cela entraîne une perte de données car l’OM existant est ramené sur un mois puis dupliqué sur les mois suivants. Le collaborateur a donc lié plusieurs mois d’activités sur un OM d’un mois uniquement. Nous n’avons pas eu le loisir d’essayer afin de voir l’impact que cela aurait sur l’application mais nous étions sûrs que l’application planterait. Pour pallier ce problème, nous avons déterminé qu’au lieu de scinder mois par mois depuis la date de création de la commande, nous ferions une première commande de la date initiale jusqu'à la fin du mois pendant lequel la commande est finalisée pour ensuite scinder mois par mois comme prévu. La suite du développement s’est passée sans soucis.



Pour terminer l’implémentation, nous avons complètement testé mais surtout

documenté notre code. C’est en effet quelque chose qui manque énormément à Giga, il y a beaucoup de codes assez compliqués sans indication aucune du développeur. Il n’est donc pas rare de perdre beaucoup de temps uniquement pour comprendre le travail d’un de nos prédécesseurs. Nous nous sommes ensuite attaqués à la documentation “extra-code”. Pour ce faire nous avons un manuel utilisateur (annexe 6) et une feuille de calcul qui résument le comportement de l’algorithme (annexe 7).

Les missions prennent en moyenne trois mois, c’est donc le chiffre le plus représentatif mais le temps perdu reste constant. Il ne se réduit ou n’augmente pas réellement en fonction du temps de la mission. L’entreprise compte environ 1900 commandes par an. Sur base de ces chiffres, la perte de temps d’une commande est de 6 minutes, soit environ 190 heures par an ou environ 27 jours de travail. L’implémentation nous ayant pris environ 35 jours-hommes, l’implémentation devient rentable après moins d’un an et demi. C’est une estimation car les chiffres ne sont probablement pas tous exacts et l’impact de la scission des OM/BDC n’est pas prise en compte car trop difficilement calculable. Il est toutefois intéressant de constater que notre travail a un impact réel sur la situation.



Conclusion

Le bilan de mon alternance chez UNIS est globalement positif. La montée en compétence n’a pas été négligeable, tant d’un aspect purement technologique que d’un aspect plus humain. Plus précisément le contact avec le client, la vie en entreprise et le développement en équipe plus conséquente que ce à quoi l’enseignement nous a habitué.

J’ai eu l’occasion d’être assigné au projet Giga, qui est de loin l’application de la plus grande ampleur sur laquelle il m’a été donné de travailler. Cela consistait en développement, test et débogage en fonction des besoins. Comme expliqué, j’ai eu la chance de pouvoir développer une fonctionnalité conséquente plutôt que d’être cantonné à des petits tickets tout au long de mon expérience. Cela m’a permis de mettre plus à l’épreuve mes compétences de développeur en terme d’analyse et d’architecture de code que si j’étais resté sur des petites implémentations.

J’ai également pu me rendre compte de la différence significative entre le développement appris aux cours et le développement en milieu professionnel. Que ce soit concernant l’implémentation ou le testing, il n’a pas été rare que les contraintes soient telles qu’on ne puisse pas s’appliquer à coder convenablement pour privilégier la mise en production rapide. Ce qui n’est pas sans conséquence, le manque d’expérience des alternants ajouté aux bouts de codes de moins bonne qualité ont créé une application lente et difficilement entretenable. Nous avons donc dû mettre beaucoup d’énergie dans la réécriture du code et dans l’amélioration de l’existant en parallèle du développement tout en documentant chacun de nos changements.

Il y a d’autres points qui auraient pu être améliorés aussi. Notamment mon contact avec le client, qui était bon mais qui n’existait uniquement que quand cela était nécessaire pour mon travail. Un contact plus fréquent et une attention plus poussée sur leur manière de travailler avec notre logiciel aurait peut-être pu me permettre de proposer plus de changements et de faire preuve de plus d’initiative.

Je sors néanmoins gagnant d’une expérience conséquente et je me sens tout à fait prêt à entrer dans le monde professionnel.



Annexes

Annexe 1 : Création de commande.



Annexe 2: Création d’ordre de mission



Annexe 3 : Création de bon de commande

Annexe 4: Rapport d’activité



Annexe 5 : Diagramme d’activité



Annexe 6: Manuel scission de commande

Manuel d’utilisation pour scinder une commande 1. Qu’est-ce que c’est ? 1

2. Comment ça marche ? 2 Vérifications à faire avant de finaliser une commande à scinder : 2 Résultat d’une scission : 3

1. Qu’est-ce que c’est ? La scission permet de transformer une commande qui occupe plusieurs mois en plusieurs commandes d’un mois chacune. Toutes les caractéristiques renseignées dans la commande initiale seront récupérées, seules changeront la date de début et celle de fin des commandes scindées qui sont générées automatiquement. Les jours offerts seront répartis au mieux dans la première commande, puis, s’il en reste à attribuer, dans la commande du mois suivant, et caetera... jusqu’à ce qu’il n’y ait plus de jours offerts restants. Les ordres de missions seront également impactés par la scission d’une commande, de même que les bons de commande (ainsi que les commandes & OM créés automatiquement si le bon de commande concerne un de nos collaborateurs).



2. Comment ça marche ? Lorsqu’une commande est créée, il est possible d’activer l’option ci-contre (sur la page de création/modification de commande). Une commande marquée “à scinder” sera enregistrée telle quelle, c’est seulement lors de sa finalisation qu’elle sera découpée en plusieurs commandes. Vérifications à faire avant de finaliser une commande à scinder :

● Si la durée de la commande ne dépasse pas 1 mois, il n’est pas logique de la marquer “à scinder”, même si l’application est capable de le faire.

● Si la finalisation de la commande ne se fait pas dans le même mois que sa création, la commande ne sera pas découpée en x commandes d’un mois (pour respecter l’intégrité des ordres de missions sur le ou les mois déjà travaillés).

○ Une première commande sera générée, depuis la date de début de la commande jusqu'à la fin du mois en cours.

○ Les autres commandes seront coupées par mois jusqu’à la date de fin de la commande.

● Si une commande possède 1 ou plusieurs ordre(s) de mission ou bon(s) de commande, les dates de début et de fin de ce(s) dernier(s) doivent concorder avec les dates de la commande initiale.

● Si une commande doit avoir plusieurs OM plus courts que la commande ( un premier OM sur la moitié de la commande, un second pour la suite), il faudra créer deux commandes distinctes, plus courtes, avec chacunes son OM.

● Lors de l’ajout d’un bon de commande, ce dernier ne sera scindé qu’au moment où la commande elle-même sera finalisée (et donc scindée).

● Une commande en “nombre de jours” n’est pas scindable car ce n’est pas nécessaire.



Résultat d’une scission :

L’exemple ci-dessous montre le résultat d’une scission de commande (possédant un OM) :



Avec l’OM lié à la commande :



Annexe 7 : Exemple récapitulatif du fonctionnement


Documents

Mémoire Entretien et développement d’une plateforme de gestion d…lipari/cs/iagl/memoires/... · 2019-06-27 · Master IAGL 2018-2019 - Université de Lille R e m e r c i e m