Rapport de Stage - Simon Réthorésimon-rethore.fr/pdf/Rapport_Odiwi.pdf · 2019. 5. 23. · Ce rapport est l’aboutissement et la s Çnthèse du traail que j’ai réalisé durant

Rapport de Stage Réalisation d’un extranet client

RÉTHORÉ Simon

Bachelor Informatique 2ème année

Date : 7 Janvier au 8 Février 2019

Maître de Stage : Bertrand Ouary

Réthoré Simon – Réalisation d'un Extranet Client

2

Table des matières

I. Remerciements ...................................................................................................................3

II. Introduction .......................................................................................................................4

III. L’entreprise .......................................................................................................................5

A. ODIWI .........................................................................................................................................5

B. Groupe HERA-CLES ......................................................................................................................5

IV. Présentation du Projet......................................................................................................7

A. Cahier des charges ......................................................................................................................7

B. Environnement de travail ............................................................................................................8

C. Difficultés à résoudre, contraintes et limites ............................................................................. 10

V. Démarche suivie ..............................................................................................................11

A. Processus et méthodes suivies .................................................................................................. 11

B. Organisation du projet .............................................................................................................. 13

VI. Réalisation de la mission ................................................................................................15

A. Justification de solution retenue ............................................................................................... 15

B. Étapes essentielles .................................................................................................................... 17

VII. Évaluation des réalisations ............................................................................................24

A. Bilan de la mission .................................................................................................................... 24

B. Réaction des demandeurs ......................................................................................................... 24

C. Propositions d'améliorations ..................................................................................................... 25

VIII. Conclusion ....................................................................................................................26

Annexes ...............................................................................................................................27


3

I. Remerciements

Avant de commencer la présentation de ce rapport, je voudrais remercier l’ensemble des

personnes qui ont contribué et qui m’ont accompagné durant le stage.

En premier lieu, un grand merci à Bertrand OUARY mon maître de stage pour m’avoir fait

confiance et accueilli au sein de son entreprise. Je lui suis reconnaissant pour sa disponibilité

afin de m’aider et me conseiller.

Je tiens à remercier vivement Mathieu LE LUËT qui s’est tenu disponible tout au long du stage

afin de nous aider dans les difficultés que l’on a pu rencontrer.

Merci à Baptiste PAPA et Louis GAUTIER qui ont partagé ce stage et ce projet avec moi.

Je souhaite agréer mes sincères remerciements à Alan FERRONNIÈRE, mon professeur de

Symfony pour son soutien durant ce stage lorsque je rencontrais des soucis sur la technologie.

Enfin, dès le départ l'accueil chaleureux puis la gentillesse et la bonne humeur générale de

toute l’équipe HERA-CLES ont été remarquables.


4

II. Introduction

Durant ma seconde année de Bachelor informatique à l’EPSI, j’ai eu l’opportunité de réaliser

un stage de 5 semaines qui est une étape importante dans ma formation et mon projet

professionnel. Ce stage sera présenté pour la validation de mon BTS Services Informatiques

aux Organisations avec pour option Solutions Logicielles et Applications Métiers.

Le stage s’est déroulé du 7 janvier au 8 février 2019 au sein de la société ODIWI à Carquefou,

dans les locaux du Groupe HERA-CLES dans lesquels se situent d’autres sociétés (Intérim, RH,

Comptabilité …). Odiwi est une entreprise de service numérique qui réalise des projets dans

le domaine du développement web et mobile. Le but du stage est de mettre en application

les connaissances que j’ai apprises pendant tout le cursus universitaire et de développer de

nouvelles compétences.

J’ai réalisé ce stage en collaboration avec deux autres étudiants de ma promotion : Louis

GAUTIER et Baptiste PAPA.

Ce rapport est l’aboutissement et la synthèse du travail que j’ai réalisé durant ce stage de 5

semaines à ODIWI.


5

III. L’entreprise

A. ODIWI

ODIWI est une entreprise de service numérique qui réalise des projets dans les domaines du

web et du mobile. Cette organisation a été fondé en 2013 par Bertrand Ouary et Nicolas

Guillou accompagnés de deux développeurs. L’entreprise s’est développée et en 2015 elle

accueillit de nouveaux développeurs, une équipe de graphiste et une autre de communication.

De plus un pôle infrastructure est ouvert afin de se diversifier et d’offrir une plus grande

gamme de produits et de solution pour les clients d’ODIWI. En 2015 Odiwi rejoint aussi

l’incubateur HERA-CLES à Carquefou.

ODIWI à ce jour possède deux agences dont la principale et le siège social sont situés à

Carquefou. Celle-ci réalise l’ensemble des projets de développements web, mobile tandis que

la seconde située à Trignac est spécialisée dans le domaine de l’infrastructure réseau, elle

câble, déploie et installe des machines et réalise le service après-vente de ceux-ci. L’entreprise

comptabilise une vingtaine d’employés.

L’organisation offre plusieurs solutions diversifier à leurs clients : Odicloud est solution qui

permet d’accéder à un bureau à distance grâce à une connexion internet, Odiback permet le

contrôle des sauvegardes et des données dans son intégralité. Enfin Odi365, Odimail et

Odidrive sont des solutions qui offrent aux clients la possibilité d’accéder facilement à leurs

applications avec une connexion internet.

B. Groupe HERA-CLES

Le groupe HERA-CLES est un incubateur d’idées et de projets, il a été fondé en 2011. Il est situé

à Carquefou. Le groupe a été créé afin de faciliter le lancement de start-up, petite entreprise

et de leurs permettre de travailler ensemble dans le même établissement.

Les valeurs promulguées par HERA-CLES sont la responsabilité des collaborateurs. Ils doivent

être préoccupés par leurs travaux et leurs clients. Leur engagement accentue la relation client,

la confiance afin d’avoir des partenariats durables. Enfin le dynamisme : une entreprise

moderne enthousiaste et motivée qui a la volonté de toujours progresser et d’innover pour

mieux satisfaire ces partenaires.


6

Le groupe HERA-CLES regroupe donc plusieurs entreprises prometteuses dans différents

domaines, voici un aperçu des entreprises incubées par HERA-CLES à ce jour :


7

IV. Présentation du Projet

A. Cahier des charges

La mission principale de ce stage est de réaliser une application web qui permettra aux clients

de se connecter à un extranet afin d’accéder au compte de leur entreprise. Elle leur permettra

aussi de consulter facilement l’ensemble de leurs interactions avec Odiwi à l’aide d’une

interface simple et épurée. Cette application remplacera Dolibarr (seule solution actuelle) qui

n’est pas un logiciel intuitif.

L’utilisateur en se connectant pourra alors consulter l’ensemble des devis, contrats,

commandes, interventions, factures et tickets liés à Odiwi. Ces informations seront

récupérées à l’aide de l’API REST de Dolibarr. De plus l’utilisateur pourra créer des tickets pour

ces besoins (ex. : demande d’intervention, renouvellement, devis, commandes …).

Cependant cette application pourra être aussi utilisée par un membre interne d’ODIWI afin de

donner, de résilier l’accès de l’extranet à un client ou de régénérer son mot de passe en

aléatoire. L’Utilisateur interne pourra se connecter à l’intranet d’un client choisi pour

consulter lui aussi l’ensemble des devis, contrats, commandes, interventions, factures et

tickets liés à un client spécifique.

Enfin, l’application permettra la signature électronique de PDF, elle aura des tâches qui

tourneront en fond qui permettra d’envoyer sur DocuSign (un outil de signature électronique)

les PDFs des devis, des commandes et des interventions à signer par le client. Ces PDFs seront

envoyés automatiquement dès la création de ceux-ci sur Dolibarr. Il y’aura une seconde tâche

qui vérifiera si les PDFs ont été signés par les clients et si c’est le cas elle renverra les PDFs sur

Dolibarr.

La mission annexe qui nous a été confiée en cas de réussite de la première est de réaliser une

application mobile qui permettra aux techniciens d’Odiwi d’accéder à leur planning depuis

leur portable, cette application sera composée d’un espace de connexion relié à l’API de

Dolibarr et d’un planning regroupant l’ensemble de leurs tâches de la semaine. Cette

application permettra aux techniciens d’avoir une solution simple et efficace pour consulter

leurs plannings. De plus, ils pourront le consulter depuis n’importe où grâce à leur portable.


8

B. Environnement de travail

1) Base de départ

Mathieu LE LUËT nous a mis à disposition une version du Dolibarr de l’entreprise afin que l’on

puisse réaliser l’ensemble des tests dont on avait besoin sans pour autant altérer les données

de l’entreprise.

Il nous a créé un compte administrateur sur Dolibarr afin que l’on puisse naviguer et découvrir

cet ERP. Ce compte administrateur est aussi nécessaire pour faire appel à l’API dans notre

code.

Il nous a aussi mis à disposition un git pour le projet afin que l’on puisse échanger notre code

facilement, une adresse mail interne à l’entreprise et il nous a invité sur le Teams de

l’entreprise afin que l’on puisse échanger plus simplement entre nous.

Enfin, il nous a donné l’accès au serveur de préproduction afin que l’on puisse mettre notre

application sur un serveur et ainsi faire des tests, voire les premiers retours sur notre

application.

Pour commencer nous avons dû installer notre environnement de travail local, nous avons

utilisé la version 18.04 d’Ubuntu pour le système d’exploitation, pour l’IDE nous avons choisi

Visual Studio Code que l’on avait déjà utilisé auparavant dans d’autres projets.

2) Technologies utilisées

a) APIs

Dolibarr est un ERP libre et gratuit qui permet d’avoir une totale gestion

des clients, fournisseurs, devis, commandes, factures, stocks,

comptabilité d’une entreprise. Ce logiciel possède une API REST et SOAP

qui permet de récupérer, de modifier, d’insérer ou de supprimer

l’ensemble de ces données.

DocuSign est un logiciel de signature électronique qui permet de

simplifier l’ensemble des signatures entre les acheteurs et vendeurs de

services, matériels … Ce logiciel possède une API REST et SOAP qui

permet de créer et de récupérer des enveloppes signées

automatiquement.


9

b) Outils de développement

Gitlab est une plateforme gratuite qui permet de gérer un projet et un

dépôt git (la gestion de versions de fichiers et de projets).

Microsoft Teams est une application qui permet de créer, partager et

collaborer en équipe sur une plateforme. Ce logiciel offre la possibilité

aux utilisateurs de discuter, de réaliser des réunions en visioconférence,

des notes et des pièces jointes.

Ubuntu est un système d’exploitation Linux basé sur la distribution

Debian.

Visual Studio Code est un éditeur de code extensible développé par

Microsoft pour Windows, Linux et MacOS.

c) Langages de développements et frameworks

Symfony est un framework PHP qui permet de faciliter et d’accélérer le

développement d'un site web. Symfony utilise le modèle MVC qui est

une méthode de développement fragmenté en 3 parties : Modèle, Vue

et Contrôleur.

Materialize est un framework CSS responsif basé sur le Material Design

de Google.

Xamarin est un framework de Microsoft basée sur le .net. Ce framework

permet de convertir du langage .net en langage natif pour chaque

système d’exploitation (IOS, Android).


10

C. Difficultés à résoudre, contraintes et limites

1) Difficultés à résoudre

Les principales difficultés à résoudre avant de démarrer le projet étaient tout d’abord de

découvrir et de monter en compétences sur les APIs Dolibarr et Docusign qui était nouvelle

pour nous. De plus, l’utilisation du framework .net Xamarin était elle aussi une épreuve à

surmonter.

La principale difficulté technique est pour la signature électronique, il faut récupérer les PDF

de Dolibarr et les envoyer automatiquement sur Docusign afin qu’ils soient signés. Puis les

faire revenir sur Dolibarr une fois signés par les clients automatiquement aussi. Ces deux

tâches doivent donc être exécutées en tâches de fond tout le temps sur le serveur.

2) Contraintes du projet

Nous n’avons pas eu beaucoup de contraintes lors de ce projet, les seuls qui sont à noter sont

l’environnement Ubuntu, l’utilisation de Symfony 4 et du modèle MVC. Il y’a aussi la

manipulation de l’API de Dolibarr pour l’extranet client. Enfin en ce qui concerne l’application

mobile il faut utiliser le framework Xamarin.

3) Limites du projet

Les limites de ce projet sont qu’il a été un peu rébarbatif en ce qui concerne les onglets de

l’extranet client : devis, contrats, commandes, interventions et factures ont un

fonctionnement très similaire. Ils ont chacun une liste d’éléments, un détail et pour la plupart

le téléchargement de PDF.


11

V. Démarche suivie

A. Processus et méthodes suivies

Le processus que nous avons suivi se déroule en quatre grandes étapes :

- La première étape est l’analyse du besoin, dans cette étape on retrouve la rédaction

d’un cahier des charges et la création d’un Modèle Conceptuel des Données pour le

système d’information.

- La seconde étape est le développement en local des applications qui répondent au

besoin initial. Cette étape est caractérisée par de nombreux tests.

- L’étape suivante est la mise en préproduction de ce qui a été développé en local avec

de nouveau des tests pour vérifier que tout fonctionne correctement.

- Enfin, l’étape finale est la mise en production de l'application afin qu’elle puisse être

utilisée de tout le monde.

1) Analyse du besoin

Cette étape de conception est très importante, car elle consiste à analyse et prendre en

compte les contraintes et les risques du projet ainsi que les souhaits du client.

Dans notre cas nous avons commencé par réaliser une étude des besoins sur la solution voulue

par les clients. Nous avons défini l’ensemble des pages : leurs dispositions, contenues grâce à

des mockups (FIGURE 1). Enfin nous avons réalisé un Modèle Conceptuel de Données de la

base de données afin d’avoir une représentation du système d’information du projet (FIGURE

2).

2) Développement en local

Le développement en local est la partie où l’ensemble des fonctionnalités et des interfaces

utilisateurs doivent être réalisées par les développeurs.

En ce qui concerne le développement nous avons commencé lorsqu’il était nécessaire par

nous documenter sur les technologies que nous ne connaissions pas (Dolibarr, Docusign et

Xamarin), regarder des tutoriels afin de comprendre les technologies et comment elles

fonctionnent. Puis nous avons codé les différentes pages et fonctionnalités que nous avions

définies lors de l’analyse du besoin. Tout au long du projet nous avons réalisé des tests sur les

fonctionnalités et les possibles moyens de contourner le but principal de l’application afin que

la sécurité soit maximale. Enfin, nous avons essayé d’améliorer l’ergonomie et l’expérience


12

utilisateur en proposant une interface simple d’utilisation qui facilite la compréhension de

tout utilisateur.

3) Mise en préproduction

La mise en préproduction est la dernière étape avant de livrer le résultat au client.

Lorsque le développement en local était terminé, nous avons mis le projet sur un serveur de

préproduction. Cela a permis de constater des bugs back-end que l’on a corrigés. Nous avions

aussi quelques petits soucis d’ergonomie, car certaines fonctionnalités n’étaient pas assez

intuitives ce qui a engendré des corrections. Certains employés de l’entreprise ont aussi pu

essayer l’application, les fonctionnalités et ainsi nous faire des retours sur l’application durant

le développement.

4) Mise en production

Enfin la dernière étape est de mettre l’application sur le serveur de production et donc de

livrer cette application au client.

Dans notre cas nous n’avons pas eu le temps de pouvoir mettre l’application en production,

mais cela aurait été l’étape finale de notre projet.


13

B. Organisation du projet

1) Planning

Un diagramme de Gantt est un diagramme prévisionnel qui permet de visualiser dans le temps

les diverses tâches qui composent le projet. Cela permet aussi de se projeter en avance sur les

tâches à accomplir, l’avancée du projet (dans les temps, en retard).

Ce Gantt montre que l’on avait prévu les 5 semaines pour la réalisation de l’extranet client qui

comprend une analyse du besoin et de conception de l’application (interface), une

familiarisation avec Dolibarr et DocuSign. Cela prend en compte aussi le design de

l’application, l’ensemble des modules que comprend l’extranet (Commande, Contrat, Devis,

Facture, Intervention, Profil, Ticket). Enfin nous avons prévu si possible en fin de stage de

réaliser l’application mobile en Xamarin.

2) Séparation des tâches

En ce qui concerne la séparation des tâches cela a été plutôt simple, Louis Gautier préfère le

développement front-end tandis que moi et Baptiste nous favorisons le développement

back-end. Ensuite en ce qui concerne les fonctionnalités à développer nous nous sommes

séparé les tâches au moment venu, pour ma part j'ai beaucoup travaillé sur la partie

connexion, sur les onglets contrat, devis, factures, tickets. De plus, j'ai réalisé l'une des deux


14

tâches qui tournent en continu pour DocuSign : celle qui renvoie le document de DocuSign

vers Dolibarr.

De plus, la mise en place d'un git nous a faciliter la séparation des tâches, car il était plus

facile de réunir les fonctionnalités et le code. Gitlab nous a aussi permis d'avoir un système

de versionning de fichiers qui nous a quelquefois sauvés lorsque nous faisions des erreurs,

cela permet de revenir en arrière sur des versions stables.

3) Compte-Rendu

Nous avons réalisé des comptes-rendus hebdomadaires (tous les lundis matin) à l’ensemble

de l’entreprise afin qu’il puisse prendre connaissance de l’avancée du projet. Ainsi ils ont pu

savoir sur quelles technologies nous travaillions et constater les difficultés rencontrées. Cela

a permis d’avoir un suivi du projet et aux développeurs d’Odiwi de nous aider, de nous

conseiller quand le besoin s’en faisait sentir.

4) Formation

En ce qui concerne la formation, Bertrand OUARY nous a laissés libres. Pour ma part, j’ai donc

quand le besoin était nécessaire regarder des tutoriels notamment pour les API (Dolibarr,

Docusign). Pour les tutoriels, je me suis beaucoup aidé des éléments partagés par

communauté sur YouTube ou sur des forums tels que OpenClassrooms, Stack Overflow.

De plus durant le projet nous avons réalisé une conférence téléphonique avec un développeur

de Docusign afin d’en apprendre plus et de nous orienter sur les solutions aux soucis que l’on

a rencontrées.

Enfin les membres l’équipe de développeurs étaient toujours prêt à nous aider ou à répondre

à nos questions si cela était nécessaire. Notamment Mathieu LE LUËT et Bertrand OUARY ont

été très présent pour nous conseiller tout au long du projet.


15

VI. Réalisation de la mission

A. Justification de solution retenue

1) Plateforme de signature électronique

Bertrand OUARY voulait intégrer à notre application une solution qui permettrait aux clients

de signer les contrats, devis et interventions depuis l’espace client de notre application. Pour

cela, il nous a proposé deux solutions possibles qui pouvaient réaliser ce souhait : Yousign et

DocuSign. Il nous a laissés faire une étude afin de savoir laquelle des deux était la plus apte à

utiliser dans ce cas.

Yousign est une solution de signature électronique française qui a été créée en 2013 tandis

que DocuSign est une entreprise américaine qui est le leader mondial de la signature

électronique depuis sa fondation en 2003.

Voici le tableau qui retranscrit le comparatif réalisé :

Support technique Français Anglais

Envoi d’email automatique ✔ ✔

Multisignataire ✔ ✔

Archivage ✔ ✔

Intégration dans une application ✔ ✔

API REST REST

Coût 40 € / Mois 38 € / Mois

Nous en avons donc fait notre rapport à Bertrand OUARY en lui disant que les deux solutions

étaient assez équivalentes puisqu’elles possédaient les mêmes fonctionnalités à plus où moins

les mêmes coûts. Il nous a orientés vers DocuSign, car il avait déjà eu un contact avec cette

entreprise et il était donc plus simple d’échanger en cas de question et soucis avec l’un de

leurs techniciens. De plus, ils ont un pôle français qui comporte des techniciens français ce qui

annule le seul possible point ou Yousign surpassait DocuSign.


16

2) Choix pour la réalisation de l’interface de l’application

a) Interface

Pour l’interface, nous avons privilégié une interface sobre, nous avons une page de

connexion où l’on peut demander une inscription si nous ne possédons pas de compte.

De cet écran de connexion découlent deux parties, la partie extranet pour les clients

d’Odiwi où ils pourront consulter l’ensemble des interactions réalisées avec Odiwi. De plus

ils pourront réaliser des demandes avec un système de tickets qui sera relié au Dolibarr de

l’entreprise. De l’autre côté, les utilisateurs internes pourront accéder à la liste des clients

et une liste d’actions sur chacun des utilisateurs des entreprises clientes (donner un accès,

retirer un accès, réinitialiser un mot de passe et se connecter en tant que l’utilisateur).

De plus, l’interface est simple une barre de navigation verticale en haut et les informations

de chaque page en dessous. Un bouton en bas à droite pour remonter en haut de la page

lorsque nous sommes en bas.

b) Design

En ce qui concerne le design de l’application, Bertrand OUARY nous a laissés libres, ces

exigences étaient d’avoir une application sobre, facile de compréhension et fonctionnelle.

Nous avons donc essayé de réaliser une application en material design avec Materialize.

Nous avons opté pour ce framework CSS, car nous l’avions déjà utilisé lors de précédents

projets et il répondait parfaitement au besoin que l’on avait pour cette application.

c) Couleurs

Enfin pour le choix des couleurs nous avons repris les couleurs de l’entreprise et de leur

logo qui sont l’orange, le vert et le rose. Malheureusement, nous n’étions pas au courant,

mais l’entreprise en interne est en train de refaire complètement leur site web ainsi que

leur charte graphique qui est donc différente de la précédente. Voici l’ancien et le nouveau

logo :

Sinon pour le reste de l’application nous avons gardé le blanc, le noir et un gris clair afin

d’avoir une application épurée et simple de compréhension.


17

B. Étapes essentielles

1) Prise en main de Dolibarr et de son API Rest

Pour la prise en main de l’ERP Dolibarr nous avons tout d’abord exploré l’interface de Dolibarr

qui est très complète, elle possède une page de connexion, un tableau de bord (FIGURE 3) et

une partie pour chacun des modules que l’entreprise a choisi d’implémenter dans leur ERP.

Dans notre cas, l’ERP est très complet puisqu’il rassemble l’ensemble des données liées à

l’entreprise. On peut y retrouver l’agenda du personnel de l’entreprise, la liste des clients et

de leurs contacts, l’ensemble de la partie économique (devis, commandes, contrats,

interventions, factures, caisses) et enfin les projets, services et biens mis à dispositions.

Il a fallu ensuite se renseigner sur le fonctionnement de l’API de Dolibarr. Cette API est de type

REST, ce qui signifie que cette API est basée sur des requêtes HTTP qui vont être envoyées au

serveur qui va lui nous retourner une réponse différente selon la requête envoyée. Les

réponses du serveur sont encodées en format JSON qu'il est ensuite possible de convertir dans

le format que l'on souhaite. Ce type d’API est donc utilisé grâce au web.

Pour faire n’importe quelle requête avec l’API, il faut tout d’abord se connecter et récupérer

son "token". Il s'obtient à l'aide de l'identifiant et du mot de passe de l'utilisateur. Cette en

quelque sorte une connexion qui va permettre d'accéder à l'API. Ce "token" doit être passé en

paramètre de chaque requête afin que celle-ci puisse être exécutée. De plus, le "token" en

fonction des droits liés à l'utilisateur peut restreindre ou non les accès et les actions de

l'utilisateur.

Une fois le "token" acquis il faut alors construire ces requêtes HTTP. Pour cela l’API de Dolibarr

possède 4 méthodes pour permettredema de séparer les types d'actions possibles : GET, PUT,

POST et DELETE. La méthode GET permet de consulter, d'accéder aux informations d'un ou

plusieurs enregistrements selon les filtres renseignés en paramètres. La méthode PUT quant

à elle permet la modification d'un enregistrement unique. La méthode POST permet elle de

créer un enregistrement et enfin la méthode DELETE supprime un enregistrement de la base

de données de Dolibarr.

Dans un premier temps, nous avons donc essayé de récupérer des données, pour cela nous

avons utilisé la méthode POST comme expliquée ci-dessus. Nous nous sommes alors

confrontés à un premier souci qui était que Bertrand OUARY est le dirigeant de plusieurs

sociétés et pour faciliter son travail il utilise un module externe à Dolibarr "Multi-Company"

qui permet de rassembler plusieurs sociétés sur le même serveur afin d'avoir un meilleur

confort lors de l'utilisation. Ce module cependant oblige à mettre le numéro de la société dans

chacune des requêtes HTTP que l'on veut envoyer au serveur. Cette particularité du module

nous était inconnue ainsi qu'à Bertrand OUARY. Nous avons donc envoyé un mail à Régis

HOUSSIN le créateur de ce module qui nous a répondu très gentiment et expliqué la démarche

à suivre afin de régler ce problème. Une fois ce souci réglé nous avons réussi à récupérer des

données de devis, contrats, commandes …


18

2) Réalisation de la page de connexion

La page de connexion a été la seconde étape de ce projet, le but étant d'avoir une seule

interface de connexion qui permettent selon les informations rentrées par l'utilisateur de se

connecter soit à une partie extranet pour un client soit à une partie intranet pour un utilisateur

interne à l'entreprise.

Pour cela j'ai dû réaliser une connexion en deux parties la première qui va regarder dans la

base de données de Dolibarr avec le système de "token" si l'utilisateur existe si c'est le cas cela

signifie qu'il est interne à l'entreprise. L'utilisateur peut alors accéder à la partie intranet de

l'application.

La seconde partie de la connexion quant à elle va regarder dans une base de données liée

uniquement à cette application si l'utilisateur est présent si c'est le cas l'utilisateur accède

alors à un extranet lié à l'entreprise auquel il appartient. Ceci est possible uniquement si les

contacts ont été enregistrés préalablement dans le tiers concerné sur Dolibarr et qu'il possède

une adresse email. De plus, il faut qu'un administrateur interne à l'entreprise lui donne un

accès sur l'extranet. Sans ces deux conditions, le contact n'est pas enregistré dans la base de

données, il ne peut donc pas se connecter.

De plus, la page de connexion possède une partie inscription pour l'extranet. Pour cela il faut

renseigner son adresse mail et la société à laquelle on appartient, à partir de ceci nous avons

réalisé un envoi de mail automatique sur la boite mail d'Odiwi qui permet à un membre

interne de consulter les personnes qui demandent un accès et ainsi leurs donner si le besoin

se fait sentir. Il y'a donc une vérification avant de donner un accès afin de maximiser la sécurité

de l'application.

Enfin, la page de connexion possède un bouton "Mot de passe oublié" qui permet à

l'utilisateur de recevoir un nouveau mot de passe par mail lorsqu'il a oublié le précèdent. Le

mot de passe que reçoit l'utilisateur est un mot de passe généré aléatoirement qui est ensuite

haché en sha256 afin d'avoir une sécurité si quelqu'un de malveillant accède à la base de

données de l'application.

3) Réalisation des pages de l'Extranet (sauf Tickets)

Nous avons ensuite réalisé l'ensemble des pages de l'extranet : commandes, contrats, devis,

factures et interventions. Ces différentes pages reprennent la même interface : une liste des

enregistrements liée à l'entreprise avec pour chacun des enregistrements un bouton "+" qui

permet d'accéder au détail de cet enregistrement et un bouton " " qui quant à lui permet de

télécharger le PDF lié à cet enregistrement extrait de Dolibarr. Enfin tout en haut à droit il y'a

pour les pages commandes, devis et factures des boutons qui permettent de filtrer les

enregistrements afin de faciliter les recherches des utilisateurs et d'avoir un meilleur confort

lors de l'utilisation de l'application.


19

Pour récupérer la liste des enregistrements de chaque page et leur détail, nous avons utilisé

une requête HTTP avec la méthode POST. De plus, on rajoute un filtre qui permet de récupérer

uniquement les enregistrements qui ne sont pas en statut "brouillon", car les ceux-ci ne sont

pas encore validés. Les données récupérées sont en format JSON on doit alors les convertir en

un tableau puis il faut pour certaines les traiter afin qu'elles puissent être plus facilement

comprises par l'utilisateur (ex : les statuts sont sous forme de chiffre, les dates sont en format

nombre dans la base de données de Dolibarr). De plus, on ajoute des couleurs afin que

l'expérience utilisateur soit meilleure.

Pour la partie téléchargement, nous récupérons les PDFs de Dolibarr à l'aide d'une requête

HTTP en passant comme paramètre la référence de l'enregistrement concerné. Les PDFs que

l'on récupère sont encodés en base64, il faut donc les décoder puis on fait télécharger

automatiquement par le navigateur le fichier qui correspond à l'enregistrement sélectionné.

4) Réalisation de la partie Tickets de l'Extranet

La page des tickets de l'extranet est différente des autres, car elle se découpe en trois blocs :

le premier est celui des tickets "ouverts", les soucis ou requêtes qui n'ont pas été pris en

compte ou qui ne sont pas encore résous. De plus, il y'a le bloc des tickets "fermés", ce sont

les tickets qui ont déjà été traités par Odiwi. Enfin, il y'a un troisième bloc qui permet d'avoir

des statistiques sur les différents tickets avec des diagrammes circulaires qui permettent

d'avoir un aperçu rapide sur le statut et la sévérité des tickets.

Elle est aussi différente techniquement, car le module utilisé est un module externe à Dolibarr

qui a été rajouté "ticketsups". Ce module a pour particularité d'avoir des tickets entre des

clients et une structure et d'envoyer automatiquement des mails aux personnes concernées

lorsque l'échange ou le statut du problème évolue. Le souci étant que ce module lorsque nous

sommes arrivés il y'avait un conflit entre l'API REST de Dolibarr et ce module alors que sur la

description du produit il y était écrit qu'ils étaient compatibles. Nous avons donc dû

rechercher dans le code source de ce module où était le problème. Nous avons finalement

trouvé que la partie API était codée en partie, mais pas pour l'utilisation dont on en avait

besoin. Nous avons donc dû rajouter quelques lignes au code source afin que celui-ci puisse

être compatible avec Dolibarr.

Il a donc fallu dans un premier temps réaliser une requête avec la méthode POST afin de

récupérer l'ensemble des tickets. Nous avons ensuite dû réaliser un traitement qui permettait

de séparer en deux parties les tickets ouverts et les tickets fermés. Ce traitement a ensuite

permis de réaliser les diagrammes de statistiques.

La seconde particularité de cette page est qu'il est possible pour les clients de créer un

nouveau ticket grâce au bouton . L'utilisateur arrive alors sur un formulaire où il doit

renseigner le type de sa demande, sa catégorie, la sévérité et il peut alors renseigner le sujet

et une description du souci qu'il rencontre. Cette fonctionnalité permet aux clients d'Odiwi

une autre solution pour signaler les problèmes qu'il rencontre.


20

Enfin, la dernière particularité de l'onglet tickets est que lorsque l'on clique sur l'un d'eux pour

avoir le détail on peut accéder à une conversation entre le client et un utilisateur interne qui

peut être utile pour résoudre un problème ou pour mieux comprendre le souci que rencontre

l'utilisateur externe. Cette conversation nous a posé quelque soucis à mettre en place, car sur

Dolibarr les conversations du module ticket se font uniquement entre utilisateurs alors que

dans notre cas la conversation doit être entre un utilisateur et un contact lié un tiers. Pour

remédier à cela, nous avons opté pour créer un utilisateur "client" qui serait utilisé dans tout

l'extranet afin de pouvoir converser entre l'extranet et Dolibarr.

5) Partie Intranet de l'application

Pour la partie intranet de l'application, elle possède uniquement deux pages la première

représentant sous forme d'un tableau l'ensemble des clients d'Odiwi avec leurs coordonnées

(adresse, mail et téléphone). Il y'a ensuite la seconde page qui le détail de chaque client, celle-

ci comporte une liste des contacts avec leur mail et leur numéro de téléphone. De plus sur ces

contacts il y'a 4 actions possibles représentées par des boutons :

Activation de l'accès

Désactivation de l'accès

Régénération du mot de passe du contact

Se connecter en tant que le contact

Le bouton d'activation d'accès permet à l'utilisateur de donner ou de redonner un accès à

l'extranet si celui-ci a été désactivé. Pour cela le programme génère aléatoirement un mot de

passe qui sera envoyé au contact. Il pourra alors se connecter à l'extranet grâce à son adresse

mail et ce mot de passe.

Le second comme son nom l'indique sert à désactiver l'accès à l'extranet d'un contact.

L'avant-dernier bouton sert quant à lui à réinitialiser le mot de passe d'un utilisateur lorsque

celui-ci l'a oublié. Le programme va alors générer un mot de passe aléatoire qu'il enverra au

contact choisi.

Enfin, le dernier bouton sert à se connecter à la session du client depuis l'intranet, cela permet

de voir la même interface que le client et donc de voir les possibles soucis ou

incompréhensions. Cette session est à l'identique à celle du client mise à part la partie ticket

où là l'utilisateur interne ne peut pas créer de ticket au nom d'un contact ni parler dans la

discussion à la place du contact. Cependant il peut tout de même parler au nom d'un

utilisateur interne et ainsi échanger depuis ici avec le client. De plus, il existe un bandeau vert

(FIGURE 4) juste en dessous de la barre de navigation qui permet à l'utilisateur de signaler qu'il

est sur la session d'un contact. Ce bandeau permet aussi en cliquant dessus de revenir sur

l'intranet. Nous avons rencontré quelques difficultés à établir ce système de connexion factice


21

en tant qu'un contact, car il fallut pour la partie ticket différencier l'affichage et surtout il a

fallu créer un bouton qui déconnecte de la session contact, mais pas de la session interne.

6) Prise en main de DocuSign

Pour la prise en main de DocuSign nous nous sommes tout d'abord documentés sur

l'application et l'API afin de savoir ce qu'il était possible et comment elle fonctionnait. En

conséquence, nous nous sommes rendu compte que l'API de DocuSign était de type REST soit

le même type que celle de Dolibarr ce qui à faciliter l'appréhension et l'utilisation de celle-ci.

De plus, DocuSign utilise un système d'enveloppe où l'on peut ajouter des documents à signer.

Ces enveloppes sont assignées à des destinataires qui eux seuls peuvent consulter et signer

les documents. Nous avons ensuite réalisé nos premiers tests qui étaient en vue de pouvoir

récupérer les documents de Dolibarr, de les signer puis après ceci de les renvoyer sur Dolibarr.

Cette prise en main a été difficile bien que l'API ressemble à celle de Dolibarr par son

fonctionnement, car le fonctionnement des requêtes HTTP est différent de celle de Dolibarr.

Pour celle-ci, il faut se connecter avec un compte (email et mot de passe) ainsi que la clé

d'intégrateur qui est la chaine de caractère qui permet d'utiliser l'API. À partir de cette

connexion, le serveur nous renvoie une URL qu'il faut alors rajouter dans toutes nos requêtes

HTTP. Au départ, nous n'avions pas compris ce système et nous cherchions le "token" comme

sur Dolibarr.

Un technicien de DocuSign a réalisé une conférence avec nous et Bertrand OUARY qui nous a

permis de mieux comprendre le fonctionnement de l'API et ce qu'il était possible de réaliser

avec. Il nous a notamment montré quelques pistes à explorer afin d'améliorer l'intégration de

DocuSign pour notre application.

7) Réalisation des tâches "cron"

Pour la réalisation des commandes qui permettent de passer les documents de Dolibarr vers

DocuSign et de les retourner une fois signés, nous avons utilisé des tâches nommées "cron".

Ces tâches sont une façon cotée serveur d'exécuter une commande, un script, un programme

de façon régulière. Dans notre cas nous voulons exécuter deux commandes Symfony qui

permettent de synchroniser les documents (devis, contrats et interventions) et leurs

signatures des deux applications : Dolibarr et DocuSign. Pour cela, nous avons réalisé une

tâche pour chacune commande qui s'exécute tous les quarts d'heure afin de regarder s'il y'a

de nouveaux documents à faire signer et si ceux déjà présents ont été signés.

Cependant pour cette connexion entre les deux applications nous avons dû créer une table

qui permet de stocker des informations afin de relier les deux applications. Cette table garde

en mémoire si le document a été déjà envoyé pour être signé et s'il a déjà été retourné après

être signé. Ces deux informations sont importantes pour éviter d'avoir des doublons, des

tâches serveur qui ne s'exécutent pour rien et qui peuvent créer un peu de latence.


22

La première commande télécharge les nouveaux PDFs depuis Dolibarr sur le serveur, elle les

ajoute ensuite dans DocuSign en créant une enveloppe. Pour la création de l'enveloppe, on

renseigne la position où le contact devra signer ainsi que son adresse mail afin qu'il soit

contacté par mail. Enfin, la commande supprime le PDF télécharger sur le serveur pour ne pas

surcharger inutilement le serveur.

Pour ma part j'ai réalisé la seconde commande qui elle vérifie si le statut des enveloppes de

DocuSign a changé durant les 7 derniers jours (sécurité en cas de coupure de courant), si c'est

le cas elle vérifie une seconde fois si le statut est complété. Elle ajoute alors le fichier sur

Dolibarr afin que depuis Dolibarr on puisse voir les deux versions (signé et non signé). De plus,

elle change le statut de Dolibarr à signer afin que tout le monde puisse savoir que le document

a bien été validé.

Ces deux commandes sont donc effectives pour les devis, mais malheureusement nous

n'avons pas pu les adapter pour les contrats et les interventions comme prévu. Pour ceux-là,

le problème est que leurs statuts sur Dolibarr ne sont pas les mêmes. Pour les devis il y'a un

statut "validé" et un statut "signé" qui permet de savoir à quel moment on doit faire signer le

devis. La signature des PDFs permet donc de passer du statut validé a signé. Le souci est que

les contrats et les interventions n'ont pas de statut signé il passe du statut "brouillon" a "en

activité. On ne peut donc à aucun moment mettre le document sur DocuSign. Nous en avons

donc conclu avec Bertrand OUARY que pour l'instant nous laissons de coter les contrats et les

interventions pour la signature électronique.

8) Mise en préproduction

Pour la mise en préproduction, nous avons dû mettre l'application sur un des serveurs d'Odiwi.

Nous étions un peu perdus, mais grâce à Mathieu LE LUËT nous avons réussi. Il nous a

beaucoup aidés, car il a fallu réaliser un script bash qui permet de déployer l'application. Il

nous a montré un script d'un autre site et nous a aidés à l'adapter pour nous. De plus, il nous

a indiqué où fallait mettre les fichiers de configuration pour les tâches "cron" et pour apache.

9) Prise en main de Xamarin

Durant le stage nous avons eu un moment où nous n'avions plus rien à réaliser sur l'extranet,

cela nous a permis de commencer le projet annexe qui était de réaliser une application mobile

qui grâce à une connexion donne l'emploi du temps des techniciens d'Odiwi. Pour cela

Bertrand OUARY nous a conseillé d'utiliser la technologie Xamarin qui permet de créer des

applications mobiles compatibles avec tous les environnements. Cette technologie est basée

sur le langage C#.

Il y'a donc d'abord eu une première phase de test et d'exploration de la technologie. Durant

cette phase nous avons réussi à créer un projet et réaliser la connexion avec l'API de Dolibarr.

Nous avons créé un programme qui permet de faire une requête HTTP à l'API qui permet de


23

savoir si l'utilisateur existe ou non dans Dolibarr. Cependant, nous nous sommes arrêtées ici

afin de continuer l'extranet qui était la priorité pour Odiwi.

10) Préparation de l'après-stage

Pour la pérennité de l'application et les évolutions qu'on peut lui réaliser au fil du temps nous

avons réalisé deux documentations, la première est une documentation utilisateur (FIGURE 5)

qui permet de comprendre et de savoir comment utiliser les fonctionnalités de l'application.

Tandis que la seconde est une documentation plus technique qui explique de quelle manière

nous avons mis en place le code, les points importants.

De plus, nous avons respecté l'arborescence qu'utilise Odiwi en mettant le code du site dans

un dossier PHP et à l'intérieur de celui-ci nous avons créer deux répertoires, le premier

englobe l'ensemble des fichiers concernant l'extranet et le second comprend lui ceux liés à

l'intranet. Cela permet d'avoir une vision plus claire sur quel fichier correspond à quelle partie

de l'application.

J'ai aussi réalisé un fichier de configuration au sein du projet qui permet de configurer

l'ensemble de l'application : les comptes pour les APIs et les liens. Ce fichier va permettre à

Odiwi de plus facilement adapter le programme à une migration sur un autre serveur ou pour

un changement de compte pour les API.

Enfin, l'application a été réalisée entièrement avec le modèle MVC que Symfony propose.

Cette architecture logicielle est universelle, elle est connue de tout le monde, il est donc plus

simple pour un développeur qui reprend le projet de comprendre facilement l'utilité des

fichiers. Le modèle MVC (Modèle Vue Contrôleur) consiste à séparer en 3 l'ensemble des

fichiers du projet. Dans un premier répertoire Modèle (Entity pour Symfony) on retrouve

l'ensemble des données, dans le second : Vue (Templates pour Symfony) se trouve l'ensemble

des fichiers qui permettent de créer l'interface utilisateur, ce que l'utilisateur peut apercevoir.

Enfin dans le dernier répertoire Controller on retrouve les fichiers qui concernent les actions

effectuées par les utilisateurs, c'est le lien entre le Modèle et la Vue.


24

VII. Évaluation des réalisations

A. Bilan de la mission

La mission qu'on nous avait confiée était de réaliser un extranet pour l'entreprise Odiwi qui

permettrait aux clients de visualiser l'ensemble de leurs interactions avec l'entreprise et de

pouvoir faire des demandes au support à l'aide de ticket. Pour cette partie, c'est un succès les

clients peuvent visualiser l'ensemble de leurs devis, contrats, commandes, interventions,

factures et tickets. De plus, ils peuvent créer des tickets et converser avec un membre interne

à l'entreprise depuis l'extranet.

Il y'avait une seconde partie pour cette mission qui était de permettre aux clients de signer

électroniquement les devis, contrats et interventions depuis l'Extranet. À ce jour, cette

mission est en partie un succès, elle demande quelques modifications afin d'être parfaite. Il

est actuellement possible d'envoyer automatiquement les devis à sur la plateforme DocuSign

qui va envoyer un mail au client afin qu'il vienne signer. Une fois, la signature faite le PDF va

être automatiquement retournée sur Dolibarr comme prévu. Le seul mauvais coté de ceci est

que cela a été réalisé uniquement pour les devis et non pour les contrats et les interventions,

car leur fonctionnement est différent dans Dolibarr et il fallait revoir la conception pour le

Dolibarr.

Enfin pour la mission annexe qui était de créer une application mobile permettant aux

techniciens d'accéder plus facilement à leur emploi du temps nous en étions qu'aux prémices,

il faut donc approfondir pour cette tâche.

B. Réaction des demandeurs

La réaction de Bertrand OUARY au résultat de notre mission a été très bonne, il nous a assuré

que nous avons dépassé ses espérances pour des stagiaires de seconde année. Il était très

content de ce que l'on a pu produire sur cette petite période de temps (5 semaines).

Cependant comme dit précédemment certains points sont encore à finaliser ou à améliorer,

c'est pourquoi pour le moment l'application n'est pour l'instant pas en ligne. Il nous a confié

que certaines personnes internes ou de nouveaux stagiaires allaient être mis sur le projet afin

de poursuivre le projet.


25

C. Propositions d'améliorations

Plusieurs améliorations son possible pour notre application, la première est d'incorporer la

signature des documents de contrats et d'interventions pour cela il faut rajouter un statut

validé sur les deux afin d'avoir une étape de signature.

Une autre amélioration possible est d'intégrer complètement la signature des documents

dans l'Extranet. Le technicien de DocuSign nous a expliqué que l'on pouvait intégrer l'interface

qui permet de signer dans n'importe quelle application, cela permet d'éviter d'avoir des

redirections où l'utilisateur peut être perdu et c'est plus rapide.

Il serait aussi possible de créer un tableau de bord dans l'intranet qui permettrait de recenser

l'ensemble des devis, contrats, commandes, interventions, factures et tickets et de réaliser

des statistiques sur ces interactions afin d'avoir un meilleur aperçu des services qui

fonctionnent et ainsi pouvoir plus se spécialiser ou proposer aux entreprises des offres qui

leurs conviendront plus facilement.

Une autre possibilité serait de créer un système de notification ou de mail qui préviendrait

directement l'entreprise qu'un ticket a été créer par une entreprise afin d'avoir un service de

réparation, d'aide ou de création de nouveaux projets plus rapide.

Enfin pour la partie plus technique il y'a certaine partie de code qui pourrait surement être

optimisé afin d'avoir des temps de génération de page plus courts et ainsi une meilleure

expérience utilisateur.


26

VIII. Conclusion

Pour conclure, les conditions de travail au sein d'Odiwi et du groupe HERA-CLES était optimal,

elles nous ont permis de vite nous intégrer à l'équipe. Ils nous ont mis en confiance au travers

de leur aide et de leur gentillesse. Ils ont été très attentifs durant tout le projet aux soucis,

problématiques que l'on a rencontrées et ils ont su nous aider quand le besoin s'en faisait

ressentir. Ils ont ainsi pris de leurs temps de travail pour nous aider dans les moments clés.

La mission m'a beaucoup plus, elle m'a permis de découvrir des technologies telles que l'ERP

Dolibarr ainsi qu'une application de signature électronique : DocuSign. De plus, j'ai pu

progresser dans des langages et des frameworks que j'avais déjà utilisés, j'ai notamment

beaucoup progressé en PHP et en Symfony. J'ai aussi pu nettement progresser sur git où j'étais

néophyte avant le stage. Cependant, je reste un peu déçu de ne pas avoir pu finaliser et mettre

en production l'application.

D'un point de vue plus personnel, cette mission m'a aussi permis de prendre un peu plus

confiance en moi, de découvrir le monde du travail au sein d'une startup. Ce stage m'a aussi

confirmé sur mon orientation qui est de devenir développeur. J'ai aussi pu comprendre durant

ce stage que je préférais le développement back-end au front-end : je préfère récupérer,

formater des informations, créer des fonctionnalités que designer une interface.


27

Annexes

Figure 1

Réalisation de mockups en prévision de l'application.

Page d'accueil

Partie Intranet : Liste des clients


28

Partie Intranet : Détail d'une fiche client

Partie Extranet : Onglet Devis


29

Partie Extranet : Onglet Tickets

Figure 2

Réalisation d'un Modèle Conceptuel des Données.


30

Figure 3

Tableau de bord de l'application Dolibarr.

Figure 4

Connexion en tant qu'un contact (EPSI dans ce cas) depuis l'intranet.

Onglet Ticket du contact EPSI


31

Figure 5

Réalisation d'une documentation utilisateur.


32


33


34


35


36


37


38


39


40


41

Documents

Rapport de Stage - Simon Réthorésimon-rethore.fr/pdf/Rapport_Odiwi.pdf · 2019. 5. 23. · Ce rapport est l’aboutissement et la s Çnthèse du traail que j’ai réalisé durant