Mémoire de fin d’études

en vue de l’obtention du titre de

Bachelier en Informatique de Gestion

Année académique 2019-2020

Application mobile de suivi de

réalisation de tâche avec
communication serveur
asynchrone (WinDev)

Factory Systems Présenté par

Voie des Waides 8 4845 Sart-lez-Spa, Belgique Charles GARDIER

0
 Mémoire de fin d’études
en vue de l’obtention du titre de

Bachelier en Informatique de Gestion

Année académique 2019-2020

Application mobile de suivi de

réalisation de tâche avec
communication serveur
asynchrone (WinDev)

Factory Systems Présenté par

Voie des Waides 8 4845 Sart-lez-Spa, Belgique Charles GARDIER

J’adresse mes remerciements à toutes les
personnes qui ont aidé à l’aboutissement de ce
mémoire
Premièrement, je tiens à remercier M. Lauwers
qui en tant que promoteur m’a guidé dans la
rédaction de ce mémoire.
Je remercie également M. Locht qui en tant que
maitre de stage m’a supervisé et aidé pendant
toute la durée du stage et qui, malgré les
événements, a toujours été disponible pour me
conseiller
Je remercie aussi M. Jacquemin de m’avoir
permis de réaliser ce stage dans son entreprise
Et enfin, je remercie les employés qui m’ont
chaleureusement accueilli et aidé tout au long de
ce stage
Table des matières
Introduction................................................................................................................................ 6
Chapitre 1 : Présentation de l’entreprise ................................................................................... 7
Chapitre 2 : Présentation du TFE................................................................................................ 8
2.1 Contexte avant TFE........................................................................................................... 8
2.2 Sujet du TFE ...................................................................................................................... 9
2.3 Les besoins et les raisons du TFE .................................................................................... 10
2.4 Les objectifs du TFE ........................................................................................................ 10
2.5 User story ....................................................................................................................... 11
Chapitre 3 : Méthodologie ....................................................................................................... 12
3.1 Méthode de suivi ............................................................................................................ 12
3.2 Avis sur la méthodologie ................................................................................................ 13
Chapitre 4 : Analyse.................................................................................................................. 14
4.1 Fonctionnalités attendues.............................................................................................. 14
4.1.1 Identification ........................................................................................................... 14
4.1.2 Liste de tâches ......................................................................................................... 15
4.1.3 Le détail d’une tâche ............................................................................................... 16
4.1.4 L’ajout d’un commentaire, sa modification et sa visualisation .............................. 17
4.1.5 Valider une tâche .................................................................................................... 18
4.1.6 Contraintes .............................................................................................................. 18
4.2 Technologie et outil de développement ........................................................................ 19
4.2.1 WinDev mobile ........................................................................................................ 19
4.2.2 Autre ........................................................................................................................ 21
4.3 Architecture logicielle :................................................................................................... 22
4.3.1 Le web service WinDev ........................................................................................... 22
4.3.2 Le service Factory GME ........................................................................................... 22
4.3.3 L’application mobile ................................................................................................ 22
Chapitre 5 : Réalisation ............................................................................................................ 23
5.1 Préparation et découverte du projet ............................................................................. 23
5.2 Réalisation du projet ...................................................................................................... 24
5.2.1 Visualisation des informations ................................................................................ 24
5.2.2 Synchronisations ..................................................................................................... 27
5.2.3 La validation des tâches .......................................................................................... 27
 5.2.4 Les commentaires ................................................................................................... 28
5.2.5 La communication avec le serveur .......................................................................... 28
5.2.6 Les tests ................................................................................................................... 28
5.3 Synchronisation des données du serveur vers le téléphone ......................................... 29
5.4 Travail hors connexion ................................................................................................... 29
5.5 Synchronisation des données du téléphone vers le serveur ......................................... 32
5.5 GUID du téléphone ......................................................................................................... 34
5.6 Choix du serveur : ........................................................................................................... 35
5.7 Pistes d’amélioration ...................................................................................................... 37
Conclusion ................................................................................................................................ 40
Introduction
Les entreprises possédant des lignes de production doivent être capables de les gérer et
de les surveiller dans le but de réduire au maximum les temps d’arrêt des lignes et de
calculer le coût d’entretien des machines, ce monitoring passe par la journalisation des
problèmes et des solutions apportées, mais aussi par de la maintenance de ces machines
pour prévenir les problèmes.
L’application « Factory GME » pour ordinateur (qui permet de gérer et de collecter toutes
les informations utiles à l’optimisation) est lourde et complexe et elle demande une
connexion constante au serveur et balaye des dizaines de volets relatifs à la gestion de la
production.
Le but de ce projet est de répondre à une demande récurrente des clients. Ce projet
devrait permettre de grandement faciliter la vie des équipes de maintenance et de leur
faire gagner un temps précieux avec une application mobile simple à utiliser. L’application
mobile va utiliser un volet spécifique de l’application de bureau, tout en l’étoffant de
plusieurs fonctionnalités, et ainsi d’éviter des allers et retours entre le poste de travail et
la machine.
Les deux principales difficultés identifiées sont :
1) Le manque de couverture réseau sans fil dans les usines de production et la
nécessité de maintenir une cohérence dans le programme et sur le serveur
principal, le tout sur des périphériques mobiles dont la stabilité réseau n’est pas le
point fort. De plus, le volume de données gérées par l’application peut être
conséquent et il faut donc veiller à ce que la synchronisation ne soit pas trop
chronophage.
2) Le nombre d’informations présentes à l’écran dans le programme principal est
énorme et la place est bien moindre sur un écran de smartphone.
Cette application serait disponible pour toutes les entreprises utilisant le programme
principal

6
Chapitre 1 : Présentation de l’entreprise
Factory Systems est une société jalhaytoise créée en 2004 et associée au CRIG (Centre de
recherche de l’Institut Gramme).
Factory Systems propose une méthode de travail GME pour Global Manufacturing
Excellence) coordonnée par un logiciel FactoryGME, destiné tant aux opérateurs qu’aux
managers.
Ce logiciel est en amélioration continue et constitue le principal produit de la société
Le personnel plus administratif est basé au siège social à Jalhay, alors que les
développeurs sont quant à eux basés dans les locaux du GRIC, sur le campus d’« HELMo,
campus de l’Ourthe ».
Il n’y a à proprement parler qu’une seule équipe de développement composée de
3 développeurs, et il n’y a pas vraiment de grade dans l’équipe, il est rare que deux
développeurs travaillent sur la même amélioration, même si l’entraide est fortement
présente.
Beaucoup d’interactions avec les clients passent par le patron, mais certaines demandes
sont directement adressées au développeur et les contacts avec les clients pour le service
de maintenance sont surtout faits en direct auprès de l’équipe de développement.
Une très grande autonomie est laissée aux développeurs, et aucune surveillance n’est
mise en place, il faut juste que le produit final soit de qualité.

7
Chapitre 2 : Présentation du TFE
2.1 Contexte avant TFE
Factory Systems est une entreprise qui compte une équipe de 3 développeurs qui
travaillent majoritairement en WinDev, WinDev mobile et WebDev, le gestionnaire de
sources utilisé est celui intégré à la suite WinDev.
Le produit développé par l’entreprise est appelé Factory GME, c’est une application
Windows développée avec WinDev, avec une base de données MySQL.
Factory GME a commencé à être développé en 2004 et ne cesse d’être amélioré avec des
modules supplémentaires, ce qui en fait une application extrêmement complexe, à titre
d’exemple, la base de données contient plus ou moins 500 tables.
Cette application est utilisée par tous les employés d’une entreprise, soit par le personnel
de maintenance pour référencer les événements (maintenance effectuée ou problème
par exemple), mais aussi par les chefs d’équipe ou le patron pour avoir une vue
d’ensemble de l’usine.

Figure 1 : Interface de la liste des tâches (standard)

Il existe déjà des applications Android ou Windows CE qui développent des aspects de
Factory GME, mais pas celui des standards (maintenance).
Le développement en WinDev a comme gros avantage qu’il peut générer des applications
natives pour Android, iOS, Windows et énormément d’autres plateformes grâce à un
système de machine virtuelle qui est semblable au système de java, mais avec plus de
possibilités, cependant, toutes les fonctionnalités ne sont pas disponibles sur toutes les
plateformes et il faut toujours redévelopper l’interface utilisateur.

8
2.2 Sujet du TFE
L’objectif de mon stage était d’imaginer et de développer une application mobile
fonctionnant sous Android 5.0 et supérieure et développée en WinDev mobile 25.
Cette application a pour but de rendre accessible la fonctionnalité maintenance de
Factory GME sur un périphérique mobile.
Les fonctionnalités attendues sont les suivantes :
1. La consultation des listes de tâches, des tâches et des détails des tâches, afin de
pouvoir disposer de toutes les informations utiles pour réaliser les tâches qui sont
demandées et pouvoir voir quelle est la prochaine tâche à faire de la liste.
2. La possibilité de valider une tâche, il y a quatre façons de valider une tâche :
• Faite/pas faite
• Pas faite/faite sans problème/faite, mais nécessite une attention
particulière/faite, mais nécessite une intervention urgente
• Renseigner une valeur, comme une pression ou une température
• Effectuer une « calibration », exécuter une série de manœuvres et
renseigner les résultats.
3. La possibilité de laisser un commentaire relatif à une tâche.
4. La possibilité de modifier son dernier commentaire sur une tâche.
Cette application mobile ne communiquera pas directement avec Factory GME, mais
directement avec sa base de données. Cependant, les applications Android ne peuvent
pas directement interagir avec une base de données. Un web service doit donc être mis
en place. Pour des raisons de budget, le web service choisi fonctionne comme une
interface simple entre l’application et la base de données, mais ne vérifie pas la validité
de l’information, car un web service qui le permettrait serait payant en WinDev alors que
celui qui est utilisé est gratuit. Nous nous servons donc d’une table tampon et d’un service
Windows pour valider les informations. Cet élément sera expliqué en détail dans le
chapitre « réalisation ».
Les grosses contraintes opérationnelles de ce projet sont :
1. Cette application doit être utilisable sans être connectée au serveur ou à la base
de données, et donc de pouvoir valider elle-même les informations qu’elle reçoit
pour rester dans un état cohérant en attendant qu’une synchronisation soit
possible.
2. Le maintien de la cohérence, aussi bien de la base de données embarquée dans le
téléphone que celle sur le serveur principal est un des grands enjeux de ce projet.
3. Que l’envoi des données au serveur, même si l’application a été coupée ou que
même le téléphone a été coupé entre temps.
4. Le rapatriement des données du serveur vers le téléphone peut être très lourd à
cause d’un nombre impressionnant de données, il faut donc faire en sorte que ce
rapatriement soit le plus léger possible.

9
2.3 Les besoins et les raisons du TFE
La raison principale qui a justifié le développement de cette application est la demande
des clients qui utilise Factory GME, car cette application leur permettrait de réduire les
allers et retours au poste de travail pendant leur ronde de maintenance, ainsi que de
réduire les erreurs de transcription, et d’avoir les informations en direct sur une tablette
ou un téléphone, afin de réduire les oublis.
Ce à quoi s’ajoute la découverte de WinDev et de son « WLangage »

2.4 Les objectifs du TFE

L’objectif principal est qu’une fois le projet fini, il soit mis à la disposition des entreprises
qui utilisent Factory GME afin qu’elles puissent l’utiliser.
Mais aussi d’étudier la faisabilité de portée des blocs aussi conséquents de l’application
sur mobile, et de voir les temps de chargement et de synchronisation, ainsi que les
validations et les vérifications.
Les fonctionnalités de cette application pourraient être grandement élargies, en fonction
du résultat et de la facilité d’utilisation sur périphérique mobile.

10
2.5 User story
Voici les « user story » que j’ai dégagées :

• En tant qu’ouvrier de maintenance, je souhaite avoir accès aux données qui me

concernent et pas à toutes les données.
• En tant qu’ouvrier de maintenance, je souhaite avoir accès à la liste des tâches qui
compose une liste.
• En tant qu’ouvrier de maintenance, je souhaite avoir accès aux tâches à faire.
• En tant qu’ouvrier de maintenance, je souhaite avoir accès au temps nécessaire
pour réaliser les tâches restantes d’une liste.
• En tant qu’ouvrier de maintenance, je souhaite avoir accès aux informations
relatives à une tâche.
• En tant qu’ouvrier de maintenance, je souhaite avoir accès aux consignes de
réalisation d’une tâche.
• En tant qu’ouvrier de maintenance, je souhaite avoir accès au commentaire relatif
à une tâche.
• En tant qu’ouvrier de maintenance, je souhaite pouvoir ajouter un commentaire
sur une tâche.
• En tant qu’ouvrier de maintenance, je souhaite pouvoir modifier mon dernier
commentaire sur une tâche.
• En tant qu’ouvrier de maintenance, je souhaite pouvoir signaler comme pas
nécessaire une tâche qui peut l’être.
• En tant qu’ouvrier de maintenance, je souhaite pouvoir signaler une tâche comme
faite.
• En tant qu’ouvrier de maintenance, je souhaite pouvoir signaler une tâche comme
non faite ou une tâche que j’ai signalée comme faite aujourd’hui.
• En tant qu’ouvrier de maintenance, je souhaite pouvoir mettre à jour à la demande
les données sur le téléphone.
• En tant qu’ouvrier de maintenance, je souhaite pouvoir trier les tâches par type.
L’ensemble des « user story » explicitées doivent être possibles en mode connecté et
déconnecté, excepté celle qui ne saurait pas l’être, comme la synchronisation par
exemple. Par contre les modifications des données saisies au préalable par l’utilisateur,
comme les validations ou les commentaires doivent être modifiables, qu’il ait été
communiqué au serveur ou pas.
Car même si la présence du travail hors connexion est très importante, il n’empêche pas
que s’il y a une connexion disponible, il n’y a pas de raison de travailler hors connexion.
L’accès aux informations n’est disponible qu’aux utilisateurs identifiés, seuls les
changements de serveur et les synchronisations peuvent se faire sans être connectés.

11
Chapitre 3 : Méthodologie
3.1 Méthode de suivi
La méthode de suivi était très basique, elle reposait surtout sur des présentations
hebdomadaires des fonctionnalités réalisées et d’un mini briefing sur ce qui allait devoir
être fait la semaine suivante. Cependant, après le début du confinement, il a été plus
difficile de montrer l’évolution du programme, même si les mini-briefings étaient toujours
effectués via des applications de vidéoconférence, de même que mes questions ou les
aides qui m’étaient apportées étaient souvent réalisées via ce mode de communication,
qui même s’il n’est pas optimal, reste bien plus efficace que via des échanges de mail.
Donc, si je devais définir notre méthodologie d’organisation de développement, ce serait,
je pense, assez proche du SCRUM, avec des tests effectués après chaque fonctionnalité
finie et une présentation régulière des fonctionnalités finies, cependant, il n’y a pas eu de
formalisation de la méthodologie, et nous n’avons jamais utilisé le vocabulaire lié à
SCRUM.
Cette absence de méthodologie bien définie m’a un peu décontenancé au début, surtout
que j’étais occupé à apprendre et à découvrir WinDev, cependant je m’y suis habitué. Et
au final, cela ne m’a pas gêné de me sentir un peu autonome et de voir que j’étais capable
d’avancer sans avoir en permanence quelqu’un qui me surveillait.
Nous n’avons pas eu recours à des programmes de planification comme Redmine.
Cependant la réussite de cette méthode de travail était peut-être due au fait que je
travaillais seul sur mon projet, car cela aurait été beaucoup plus problématique si nous
avions travaillé à plusieurs sur le même projet, de devoir appeler les gens pour savoir ce
que les autres avaient fait.
J’ai aussi remarqué que j’allais beaucoup plus vite poser une question quand nous étions
ensemble au bureau que quand nous étions en télétravail.

12
3.2 Avis sur la méthodologie
Le fait d’être dans un « open space » a sans doute l’avantage de pouvoir plus facilement
poser des questions et permet de recevoir de l’aide plus facilement.
Pour l’avoir expérimenté en milieux scolaires, la planification prend du temps et il était
rare de s’en approcher et encore moins de la respecter fidèlement, c’est pourquoi je ne
me suis pas forcé à me créer un Redmine, d’autant plus que ne connaissant pas la
technologie, mes estimations auraient été hasardeuses, certaines choses que je pensais
faciles m’ont pris des dizaines d’heures et a contrario, certaines choses que je pensais
quasiment impossibles étaient mises en place en quelques minutes, il est clair qu’avec un
peu d’expérience et une nécessité de prévoir le nombre d’heures que prendra une tâche,
la planification aurait eu beaucoup plus de sens.
Par contre, le gestionnaire de sources lui était assez utile, cependant, le passage en
télétravail et une panne serveur en même temps a fait qu’à partir de la septième semaine,
j’ai travaillé sans gestionnaire des sources, ce qui m’a posé un problème et m’a sans doute
fait perdre une bonne dizaine d’heures, de plus le gestionnaire des sources intégré à
WinDev (tant que l’on travaille seul) ne nécessite presque pas d’attention et fait toutes
les modifications sans que l’on doive lui dire comme avec GITHUB par exemple ce qui est
très confortable.
C’est pourquoi il me parait impensable aujourd’hui de travailler sans un gestionnaire de
sources sur des projets un peu conséquents, car le temps passé à le mettre en place n’est
rien comparer au temps qu’il peut permettre d’économiser.

13
Chapitre 4 : Analyse
4.1 Fonctionnalités attendues
4.1.1 Identification
Cette application a besoin de connaitre la personne qui l’utilise pour définir ce à quoi il a
accès, mais aussi qui réalise une action ou une autre. Les utilisateurs sont identifiés grâce
à leurs nom et prénom, mais aussi un mot de passe (qui est stocké en base de données)
déjà transformé via une fonction de hachage.
Les identifications qui ont déjà été réalisées dans les autres applications reposent sur un
« combo », ce qui explique le choix de s’identifier grâce à leurs nom et prénom et pas à
un login. Il faut donc mettre en place quelque chose de similaire.
Les demandes complémentaires sont que l’identification soit demandée à chaque
démarrage de l’application, pour être sûre de qui l’utilise. Mais que le dernier utilisateur
soit retenu afin de gagner du temps à l’identification.
L’interface utilisateur qui a été retenue est la suivante.

Figure 2 : Interface de connexion

Quand un utilisateur est sélectionné, l’application demande un mot de passe, le hash et

le compare au hash qu’elle connait, afin de ne pas stocker le mot de passe en clair sur le
périphérique pour d’évidentes raisons de sécurité.

14
4.1.2 Liste de tâches
La première fonctionnalité attendue est la mise à disposition de liste de tâches relevant
de la maintenance et étant donc à effectuer de manière régulière, la fréquence étant liée
à la tâche et non à la liste de tâches, il faut savoir pour chaque tâche si elle est à faire ou
si elle a déjà été effectuée.
L’interface utilisateur qui a été retenue est la suivante :

Figure 3 : Interface Liste de Listes

Les informations disponibles sont le type de tâches via l’icône, le titre, mais aussi le
nombre de tâches en retard, à faire, mais aussi le temps que cela prendrait de les
effectuer, en cliquant, sur une des listes, on affiche la liste des tâches, de manière assez
sobre, en sélectionnant une tâche, on ouvre les détails définis dans la fonctionnalité
suivante.

15
4.1.3 Le détail d’une tâche
Les détails qui doivent être affichés permettent de savoir ce qu’il faut faire en plus, d’où
il faut le faire, ainsi que les recommandations de protection.
L’interface utilisateur qui a été retenue est la suivante :

Figure 4 : Interface tâche détaillée

Les trois petites icônes sont cliquables et permettent d’afficher les détails par rapport aux
consignes de sécurité. Le bouton « commentaire » permet d’afficher les commentaires,
mais aussi d’en créer un. La fonctionnalité des commentaires est la suivante qui sera
détaillée.
Les autres boutons seront expliqués plus tard.

16
4.1.4 L’ajout d’un commentaire, sa modification et sa visualisation
Ajouter une remarque ou une constatation est primordial de même que pouvoir consulter
les commentaires laissés lors de la dernière réalisation d’une tâche.
Une fonctionnalité présente dans Factory GME et qui doit être présente ici aussi est la
possibilité de modifier un commentaire si et seulement si c’est le dernier commentaire de
la tâche et que l’utilisateur qui veut le modifier est celui qui l’a écrit.
L’interface utilisateur qui a été retenue est la suivante.

Figure 5 : interface liste de commentaires

Les commentaires sont affichés par ordre, du plus récent au-dessus, au plus ancien en
dessous
Le bouton « ajouter un commentaire » est disponible tout le temps. Par contre, le bouton
« modifier mon dernier commentaire » n’est visible que si les conditions sont réunies.

17
4.1.5 Valider une tâche
La dernière fonctionnalité concrète est la possibilité de valider une tâche. Comme
explicité précédemment, il y a 4 moyens de valider une tâche, mais certaines tâches
peuvent également être définies comme « pas nécessaire », mais il faut aussi renseigner
le temps que la tâche a pris.
La validation des modifications est effectuée en balayant la fenêtre, ce qui affiche la tâche
suivante ou précédente en fonction du sens du balayage.
L’interface utilisateur qui a été retenue est la suivante.

Figure 6 : Interface validation de tâche

4.1.6 Contraintes
La contrainte principale est de mettre en place toutes ces fonctionnalités tout en étant
hors ligne et que les opérations réalisées soient communiquées le plus vite possible au
serveur principal tout en ne perdant pas les modifications et en essayant que la fermeture
de l’application ou du GSM impacte le moins possible cette mise à jour.
Une autre contrainte est de faire en sorte que le rapatriement des données sur le GSM et
leurs mises à jour ne soient pas trop chronophages.

18
4.2 Technologie et outil de développement
4.2.1 WinDev mobile
Le choix de l’outil de développement WinDev mobile a été surtout motivé par le fait que
c’était le seul outil vraiment utilisé dans cette entreprise et qu’il est très polyvalent pour
la réalisation d’applications sur un grand nombre de plateformes.
Mais ces avantages sont nombreux, premièrement, j’ai pu réutiliser les bibliothèques qui
avaient déjà été développées en interne pour l’application Windows (Factory GME),
malheureusement il y a eu quand même 3 semaines de correction de bugs dus au
changement de plateforme, mais qui étaient dus à des indisponibilités de certaines
fonctionnalités en Android, mais cela reste en dessous du temps qu’il aurait nécessité
pour développer ou traduire entièrement ce code, de plus la bibliothèque n’a pas été
dupliquée, mais adaptée pour être utilisable dans les deux cas de figure, ce qui permet de
ne devoir maintenir qu’une seule fois chaque fonction, cela a été réalisé grâce à des blocs
de code optionnels, qui sont exécutés en fonction de la plateforme

Figure 7 : exemple de code optionnel

Un autre avantage lié, est la capacité de générer une application IOS de manière simple,
et cela prendrait un temps considérablement réduit par rapport à en développer une
autre, alors que les deux applications seraient natives, car WinDev traduit en fait chaque
ligne dans le langage cible (ci-dessous le java).

Figure 8 : exemple de code traduit

19
Cependant, le défaut de ce système est, comme déjà cité ci-dessus, que si une
fonctionnalité n’existe pas en java, elle n’existera pas en WinDev, un exemple de ça, est
le champ combo avec recherche, qui n’est pas disponible en java (Android) et donc pas en
WinDev Android alors qu’il l’est en WinDev Windows, la seule solution est donc d’en écrire
un en WinDev et de l’utilisé, celui que j’ai utilisé avait été développé par un membre de
l’équipe par exemple

Figure 9 : combo fait maison

Il est composé d’une liste et d’un champ de saisie, et la liste se réactualise dès que quelque
chose est écrit.
Un autre aspect inédit pour moi avec cet outil, c’est qu’il est payant, et même s’il y a une
belle documentation sur leur site internet et que tout est en français, la société qui
développe l’outil est française, il n’y a pour ainsi dire pas d’aide d’utilisateur à utilisateur
sur internet comme on pourrait la retrouver sur https://stackoverflow.com/ par exemple,
le nombre d’utilisateurs doit aussi y être pour quelque chose. La difficulté qui ressort de
cela, c’est que quand on veut savoir si quelque chose est possible ou comment le faire,
soit cela a été prévu par les employés de PC soft (société éditrice de WinDev) soit il n’y a
aucune trace de cette question. À l’inverse, je ne l’ai pas expérimenté moi-même, mais
j’ai vu des membres de l’équipe téléphoner à un service après-vente pour des questions
WinDev ou des suggestions d’amélioration.
Un point amusant quand on prend en main le langage pour la première fois est la
possibilité d’écrire l’intégralité du code en français, même s’il est possible de développer
en anglais, étant donné que l’équipe développait en français, je m’y suis mis aussi même
si le changement n’est qu’anecdotique.

20
4.2.2 Autre
J’ai aussi été amené à manipuler d’autres programmes, comme « MySQL Workbench »
qui sert à accéder à une base de données serveur de test, ou bien encore Android studio
(uniquement pour la fonctionnalité d’explorateur de fichier, protégé sur Android) que
nous avions déjà manipulé au cours de la formation académique.
Cependant, WinDev étant très complet, la gestion de la base de données HFSQL
embarquée dans l’application mobile se fait directement dans WinDev et le gestionnaire
de sources est aussi celui intégré à WinDev, de même que pour le simulateur Android, qui
est lui aussi fourni par WinDev, mais qui malheureusement ne réagit pas comme un vrai
téléphone, à ce jeu-là, le simulateur Android studio est beaucoup plus fiable, au point
qu’on teste principalement sur un vrai GSM, le débuggage sur périphérique est disponible,
il n’est cependant pas très stable, et malheureusement, débugger sur le périphérique
prend quand même un petit peu de temps.

21
4.3 Architecture logicielle :
Voici le schéma détaillé de l’architecture logicielle, la seule partie qui existait déjà avant
la réalisation de ce projet était la base de données qui était déjà utilisée par Factory GME

Figure 10 : Schéma détaillé de l’architecture logicielle

Les trois autres parties ont été ajoutées pour ce projet.

4.3.1 Le web service WinDev
C’est un web service par défaut, fourni par WinDev, il n’a pas été modifié et ne fait donc
que transmettre les requêtes SQL à la base de données, il est utilisé ici, car une application
WinDev mobile Android ne peut pas accéder de manière directe à une base de données
MySQL, il pourra à terme être remplacé par un web service plus complexe qui traiterait et
répondrait directement, mais ce genre de web service chez WinDev coûte de l’argent.
C’est la raison principale pour laquelle nous avons privilégié cette approche.
4.3.2 Le service Factory GME
Ce petit service a pour but de traiter les demandes écrites par l’application dans la table
de demande de modification et de renvoyer une réponse. Cependant, les demandes sont
analysées pour être triées entre les demandes valides et les non valides, et les
modifications sont faites sur la base de données avant de rendre la réponse.
4.3.3 L’application mobile
C’est le seul module qui n’est pas exécuté sur le serveur, il envoie les demandes de
modification via le web service à la base de données.

22
Chapitre 5 : Réalisation
Dans ce chapitre, je vais rapidement expliquer ma préparation et les cours que j’ai suivis.
Ensuite ce que j’ai développé et puis détaillé plusieurs problèmes que j’ai rencontrés, et
comment je les ai solutionnés et enfin des pistes d’amélioration.

5.1 Préparation et découverte du projet

Avant de commencer mon stage, Monsieur Locht (mon maitre de stage) m’avait fourni de
la documentation papier avec la présentation de la logique WinDev, mais aussi de
l’autoformation pour WinDev mobile et WinDev. J’avais donc commencé cette
autoformation et cela a occupé mes trois premières semaines environ. J’ai aussi réalisé
des tests pour l’interface utilisateur.
Cependant, je me suis vite rendu compte que WinDev possédait beaucoup de fonctions
toutes faites et la possibilité de générer du code de manière quasi complète. L’aide
WinDev permet de créer des programmes en restant dans les clous.
Mais on se rend vite compte que dès que l’on veut faire quelque chose d’un peu plus
compliqué, on doit se passer de cet aide qui est pourtant fortement mise en avant. Un
exemple de cela est la fonctionnalité des requêtes SQL, que l’on peut créer via un
générateur de requêtes, et qui permet de générer des requêtes sans maitriser le langage
SQL. Ce générateur s’utilise en sélectionnant des options, et même si sur le papier cela a
l’air sympathique, on se rend vite compte que dès qu’il y a plus de 2 « JOIN » dans la
requête, cela ne va plus et on se retrouve vite à écrire toutes ces requêtes en SQL.
Un autre exemple est la liaison de données par exemple dans une liste il suffit de lier une
table de la base de données avec une liste, et la liste se remplit toute seule, et gère même
la réponse à un clic et la possibilité d’ouvrir une fenêtre de détails, mais si vous voulez par
exemple rajouter une itération dans la liste, ça ne va plus, et vous vous retrouvez à la
coder vous-même, ça a l’air très bien fait et pensé, mais cela sert surtout à mon avis pour
des gens qui veulent réaliser très vite une application simple, mais c’est inutilisable des
que l’application devient un peu plus complexe.

23
5.2 Réalisation du projet
5.2.1 Visualisation des informations
La première partie du développement a été consacrée au développement de l’interface
utilisateur et à la disposition des informations qui repose sur un double système de liste.

Figure 11 : Schéma d’une liste

J’ai ajouté une option de tri pour la liste des listes est la liste des tâches, afin de réduire le
temps de recherche de la tâche voulue, le tri s’opère soit par ordre alphabétique ou par
numéro d’ordre, chaque liste ayant un numéro d’ordre et chaque tâche ayant un numéro
d’ordre dans sa liste.

Figure 12 : interface de tri

24
J’ai aussi ajouté une option de filtre, basée sur le type des listes sur écran glissant.

Figure 13 : interface de filtre

Ici c’est nettoyage qui est sélectionné, et donc seules les listes de nettoyage sont
présentes, la liste à droite est mise à jour en temps réel, ce qui permet de voir le nombre
de résultats.
Les options de filtre et de tri sont cumulatives sans problèmes et indépendantes.
Les deux options sont dans les fenêtres latérales à la fenêtre liste des listes. Elles sont
accessibles, soit par balayage, soit par les boutons que l’on voit en haut de la capture
d’écran de l’interface du tri.

25
Pour l’affichage des détails, j’ai dû rajouter une fenêtre avec la liste des consignes de
sécurité, car même si elles sont affichées sous forme de symbole sur la page principale, il
fallait donner accès aux légendes et aux précisions.

Figure 14 : Interface liste de protections

L’étape suivante a été de récupérer les informations dans la base de données locale, pour
ce faire, j’ai importé les tables qui m’intéressaient grâce à l’outil WinDev et j’ai utilisé les
fonctions qui avaient déjà été développées par l’entreprise, fonction que j’ai dû modifier
sensiblement pour qu’elle soit compatible avec Android
À ce stade, la première fonctionnalité était en grande partie remplie, car les données
étaient affichées, il manquait juste à les synchroniser pour que cette fonctionnalité soit
complètement opérationnelle.

26
5.2.2 Synchronisations
Cette étape avait pour but de travailler avec les vraies données du serveur, et donc de
mettre en place un rapatriement des données, les choix posés sont expliqués dans le
chapitre 5.3.
Mais cette étape a aussi nécessité de créer une page de connexion au serveur et aussi la
possibilité de changer les identifiants du serveur. Ces identifiants sont stockés sur le
téléphone afin de ne pas les redemander à chaque démarrage, ce qui aurait été très lourd.
De l’optimisation dans la synchronisation est sans doute encore possible, mais une partie
a déjà été mise en place.
5.2.3 La validation des tâches
Pour cette partie, les ajouts à l’interface utilisateur ont été minimes, puisque l’unique
modification a été de rajouter les boutons ci-dessous sur la fenêtre de détails des tâches.

Figure 6 : Interface validation de tâche

Par contre, afin de limiter les interactions inutiles, mais aussi les modifications à la base
de données, le fait d’appuyer sur un bouton ou de changer la durée ne valide pas l’action,
pour la valider il faut, soit quitter la fenêtre, soit passer à la fenêtre suivante ou
précédente en glissant le doigt vers la gauche ou la droite.
Au clic sur le bouton principal, soit l’état change, soit un champ texte apparait pour rentrer
les informations complémentaires à la validation si elles sont nécessaires.
De plus les fonctions qui modifient la base de données sont-elles aussi des fonctions déjà
développées que j’ai dû modifier afin de les rendre compatibles.
Une fois cette partie du développement finie, on pouvait valider les données, mais
uniquement en local, à cet instant, les modifications n’étaient pas encore communiquées
au serveur.

27
5.2.4 Les commentaires
Avant de s’atteler à la communication avec le serveur, il fallait encore s’atteler à la mise
en place du système des commentaires.
Tout comme les consignes, les commentaires ont été affichés sur une autre fenêtre afin
de ne pas encombrer la fenêtre « détail d’une tâche »
Les trois fonctionnalités liées aux commentaires sont la visualisation, la création et les
modifications du dernier commentaire, ces trois fonctionnalités ont été implémentées
avec succès, un commentaire est lié à un utilisateur (qui l’a rédigé) qui est le seul à pouvoir
le modifier, à une tâche, seul le dernier commentaire de la tâche peut être modifié. Ces
contraintes reflètent les demandes et non des contraintes techniques.
5.2.5 La communication avec le serveur
La dernière partie était de faire en sorte que la modification apportée à la base de données
locale le soit aussi au niveau de la base de données principale.
Les demandes sont créées au même moment que les modifications locales, mais sont
traitées par un autre thread. Les choix et les problèmes rencontrés sont expliqués dans le
chapitre 5.5.
La communication a été la partie qui a nécessité le plus de tests, afin de vérifier si tout se
passait bien comme prévu, un grand nombre de problèmes ont été résolus.
Avec cette fonctionnalité qui fonctionne, le plus gros de l’application est opérationnel, il
reste à améliorer ou ajouter des fonctionnalités.
5.2.6 Les tests
Jusqu’ici, la plupart des tests ont été effectués sur un seul GSM, nous avons donc
commencé les tests avec un autre téléphone, mais un test sur tablette serait aussi un plus,
ainsi que vérifier que l’interface utilisateur y réponde bien, même s’il y a eu une réflexion
à ce sujet tout au long de sa création.

28
5.3 Synchronisation des données du serveur vers le téléphone
Le premier défi à régler a été celui des données, car l’application utilise une trentaine de
tables dont certaines qui peuvent compter plusieurs centaines de milliers de lignes. Alors,
même si la première fois, il est difficile de ne pas charger l’intégralité des données. Les
synchronisations suivantes ne peuvent pas prendre des heures à chaque fois, il fallait donc
trouver une solution qui permettrait de ne charger que les données modifiées.
Pour répondre à ce problème, l’application contient 3 synchronisations différentes :
1. Une synchronisation qui ne concerne que les deux tables qui bougent le plus et
qui concerne les validations des tâches, et pour ne pas recharger tout chaque fois,
car c’est une des tables les plus lourdes, elle contient une ligne par fois qu’une
tâche est faite et devra être faite, on a ajouté des « timestamp » (marqueur
temporel qui indique la date de la dernière modification ou de la création) qui
n’étaient pas encore en place à fin de voir quelles sont les lignes nouvelles et
modifiées et ne charger que celles-là.
Cette synchronisation est lancée à chaque démarrage de l’application.
2. Une synchronisation qui ne charge aussi que les lignes nouvelles et modifiées,
mais cette fois de toutes les tables, car même si c’est plus rare, des tâches peuvent
apparaitre.
Cette synchronisation est lancée sur demande et automatique à partir d’un
certain temps
3. Une synchronisation qui écrase toutes les données du téléphone et copie celle du
serveur, très longue, mais permet de repartir sur une base saine.
Cette synchronisation n’est automatique que la première fois que l’application est
lancée, mais est aussi disponible sur demande.
Mais les deux premières synchronisations avaient toujours un problème ; elles
n’effaçaient pas les données qui étaient disparues sur le serveur, on a alors mis en place
une table des suppressions, qui retient toutes les lignes supprimées, pour pouvoir les
supprimer aussi sur le téléphone.
Toutes ces synchronisations ne font que mettre à jour les données du téléphone par
rapport à celles du serveur, mais pas inversement

5.4 Travail hors connexion

Une des particularités de cette application est de travailler hors connexion ce qui veut dire
que l’envoi des modifications doit se faire de manière différée, et le plus tôt possible, mais
il faut être sûr que la modification soit envoyée, même si l’application devait être fermée,
et il faut aussi que la modification ne disparaisse pas lorsque le GSM est éteint.
Pour ce faire, on stocke les modifications dans une table de la base de données locale, et
un thread les envoie dès qu’il a une connexion, et ce thread ne se ferme que quand il n’a
plus de modifications à envoyer et se lance dès qu’on crée une modification (il est lancé
aussi au démarrage de l’application au cas où il resterait des modifications non traitées).

29
Ce thread s’appelle en WinDev un thread persistant, car il survit à la fermeture de
l’application, il est l’équivalent d’un service Android.
Avec ce dispositif, on réduit considérablement la possibilité de perdre des modifications,
tout en ayant un thread qui ne fonctionne que s’il a du travail, de plus avant de lancer le
thread, on vérifie toujours s’il n’y en a pas déjà un en cours d’exécution, afin de ménager
la batterie et l’utilisation des ressources. Cette vérification se fait avec ce code.

Figure 15 : code pour lancer le thread d’envoi des données

Dans ce code, on peut voir que l’exécution de ce thread génère une notification qui restera
présente tant que le thread est en exécution, mais aussi qu’en cliquant sur cette
notification, on peut mettre fin au thread de manière sécurisée (si par exemple, on sait
que l’on n’aura pas de réseau tout de suite, cela permet d’économiser la batterie)

Figure 16 : notification d’exécution de thread

Pour le reste du code, « ThreadEtat » renvoie -1 si le thread n’est pas en exécution ou

n’existe pas.
« gbFermer » est une variable globale booléenne qui est mise à « vrai » quand on veut
fermer le thread par fonction.
La fonction « tuer le thread synchro » qui est appelée quand on clique sur la notification.
« ThreadExécute » sert à nommer et lancer le thread. « threadContexteGlobal » sert à ce
que le thread ne soit pas lié à une fenêtre, mais à l’application, et donc ne soit pas tué au
changement de fenêtre, mais il ne survivrait pas à l’application et « ThreadPersistant »
permet de rendre le thread résistant à la fermeture de l’application.

30
Ce thread a pour code principal ceci :

Figure 17 : code du thread de synchro

On peut voir que la condition d’arrêt du thread est la variable « gbFermer » (que j’ai déjà
abordée) qui peut passer a vrai par le biais de la notification, mais aussi si « hEnDehors »
(qui regarde s’il y a encore des modifications à envoyer). Ce thread s’arrête donc de lui-
même si toutes les modifications ont été envoyées.
Le « quand exception dans » fait office de « Try catch », et donc permet ici de juste refaire
l’itération de la boucle qui aurait levé une exception, en sachant que la cause principale
de l’exception est une perte de connexion.
Le choix a été fait de se connecter et de se déconnecter du serveur à chaque itération de
la boucle, car comme c’est un thread séparé, le temps d’exécution n’est pas une priorité,
et cela permet d’être certain que l’on est bien connecté et en cas de déconnexion non
générée par l’application, la reconnexion est automatique, et dernière sécurité, une
demande de modification n’est supprimée que si la requête est bien passée, ainsi on
réduit les chances qu’une modification disparaisse, par contre on augmente la possibilité
qu’une demande soit envoyée deux fois ou plus au serveur.
Et pour finir avec ce code, « threadpause » est l’équivalent d’un « Wait » et donc permet
si la connexion est un échec d’attendre un petit peu avant de réessayer, ce qui permet
d’économiser la batterie, mais ce « Wait » n’est pas appelé entre chaque modification, si
la connexion se passe sans problème.

31
5.5 Synchronisation des données du téléphone vers le serveur
Comme expliqué plus haut, il n’y a pas de service REST ou équivalents entre les GSM et la
base de données, en fait, c’est comme si le GSM allait directement modifier les données
de la base de données. Ce qui du point de vue de la sécurité est très mauvais, il a donc
fallu trouver un moyen de faire une zone tampon.
On a donc créé une table de communication dans laquelle le GSM va écrire ce qu’il veut
faire et le web service va traiter les demandes et écrire dans la table le résultat. Ensuite,
le GSM n’a qu’à aller lire le résultat dans la table si cela l’intéresse.

Figure 18 : Exemple de table « communication web service »

Dans cette table, le GUID est un identifiant unique du téléphone, ce qui permet
d’identifier qui fait la demande et de ne pas la traiter par exemple, les GUID sont stockés
dans une table, et tout périphérique doit s’inscrire sur base de son numéro EMEI
(International Mobile Equipment Identity), toutes les données qui sont présentes dans la
table le sont dans les XML, afin de faciliter au mieux une transition vers un vrai web
service.

32
Le format de fichier XML qui a été retenu est le suivant :

Figure 19 : exemples de fichier XML

Ici pour l’ajout d’un commentaire, seul les balises présentes dans « <data> » sont
susceptibles de changer pour effectuer les autres actions.
Ce choix a été motivé par la facilité de pouvoir changer vers un web service plus élaboré
et de pouvoir envoyer plusieurs requêtes à la fois en mettant plusieurs balises
« <operation> » dans « <operations> », ce fichier XML n’a pas été pensé pour résoudre les
problèmes actuels, mais pour pouvoir prévenir les problèmes du futur.
Ce système fonctionne bien, et la réponse n’est pas vraiment nécessaire puisque
normalement le serveur et le téléphone font la même chose et dès qu’il y a une
synchronisation les données sont validées, ce qui permet de travailler en déconnecté,
enfin, tant que l’on modifie des données. Mais si on crée quelque chose, on n’a aucune
certitude que ce sera la même référence d’un côté comme de l’autre et c’est dans ce cas
que la réponse est utile, ainsi un élément créé sur le téléphone aura une référence
supérieure à 10 000 000 ce qui permet de savoir que c’est une référence temporaire. Ce
qui permet de les supprimer pendant la synchronisation et de ne pas avoir de doublons.
Mais il reste un dernier cas qui peut poser problème, si on modifie un commentaire que
l’on a créé hors connexion et qui n’est pas encore synchronisé, car dans ce cas, la
référence du commentaire à modifier sera une référence propre au GSM et donc le
serveur ne la connaitra pas, il faut donc aller modifier la requête de création directement
dans la pile de modifications à envoyer.

33
5.5 GUID du téléphone
Même si la sécurité n’est pas une chose prioritaire dans cette application, il est quand
même bon de savoir qui envoie quoi, alors on a donc créé une table qui stocke les
informations d’un téléphone et son GUID, afin qu’il soit reconnaissable.

Figure 20 : exemple de table périphérique

Ce GUID est bien évidemment stocké sur le téléphone, dans les fichiers de l’application,
mais aussi dans un fichier public, afin qu’il ne soit pas supprimé avec l’application et que
s’il y a réinstallation il puisse retrouver son GUID facilement.

34
5.6 Choix du serveur :
Une petite subtilité de cette application est que Factory Systems ne gère pas le serveur
qui contient la base de données, mais la plupart du temps, ce serveur appartient à
l’entreprise, et tous les serveurs peuvent avoir des données de connexions différentes,
c’est pourquoi on a dû créé la possibilité d’entrer les données de connexion, mais aussi la
possibilité de la changer, il est évident que vu la complexité de ces données, elles sont
stockées sur le périphérique afin de le pas les redemander à chaque fois.
L’écran qui y est associé et le suivant.

Figure 21 : interface de choix du serveur

Cette fenêtre est appelée à la première exécution de l’application sur un téléphone, mais
peut aussi être appelée depuis l’écran de connexion.
Cependant, en cliquant sur le bouton « valider », une vérification est lancée pour vérifier
si le serveur est atteignable avant de sauvegarder les informations, mais la vérification de
base (sqlconnect) vérifie juste que le serveur existe, mais ne vérifie pas si « utilisateur »
ou « mot de passe » sont valides, mais rejettera les requêtes SQL si les identifiants ne
l’étaient pas.

35
J’ai donc écrit une fonction pour vérifier si toutes les données étaient les bonnes.

Figure 22 : code de vérification de la connexion

« MySQLConnect » est une fonction maison qui va chercher les informations de connexion
elle-même.
« SQLExec » et « SQLAvance » sont des fonctions WinDev qui permettent respectivement
d’exécuter une requête SQL et de lire le prochain résultat dans la liste de résultats, ici il
n’y en a qu’une grâce au « limit 1.1 » dans la requête SQL.
La seule chose à ajouter à « MySQLConnect » a été de faire la requête la plus basique
possible afin de vérifier qu’elle était acceptée et si c’est le cas, alors la synchronisation
commence, après un changement de serveur, la synchronisation est complète afin de ne
pas avoir de données qui pourraient provenir de serveurs différents sur le périphérique.

36
5.7 Pistes d’amélioration
L’amélioration la plus importante serait de rendre disponibles les documents qui
permettent de faciliter les maintenances tels que les procédures et les plans, cependant
il nécessite un moyen de les afficher, mais surtout un moyen de les charger sans
encombrer de manière inutile la mémoire du GSM, tout en minimisant le temps de
synchronisation.
La deuxième amélioration serait d’implémenter la visualisation de l’usine et la possibilité
de fouiller pour trouver la machine qui nous intéresse comme sur Factory GME.
Exemple d’arborescence :

Figure 23 : Niveau d’arborescence « liste de lignes »

37
Figure 24 : Niveau d’arborescence « ligne »

Figure 25 : Niveau d’arborescence « machine »

38
Cependant, cette amélioration aurait aussi le problème de devoir synchroniser beaucoup
de photos. Une des possibilités serait de permettre de désactiver cette fonctionnalité, afin
de permettre une utilisation qui ne monopoliserait pas trop la mémoire.
Une autre amélioration pourrait être de se lancer dans un support tablette pousser et
tester, voire même un portage IOS, qui ne prendrait pas énormément de temps, comme
WinDev permet cela, mais certains morceaux de code seraient à revoir, comme celui du
thread persistant qui n’est pas utilisable tel quel en IOS. Mais aussi un peu changer
l’interface pour qu’elle soit plus en adéquation avec les standards IOS.
Enfin, une dernière amélioration serait de changer de web service pour ajouter une
couche de sécurité et rendre la communication plus en phase avec les habitudes
modernes.

39
Conclusion
Ce stage a été enrichissant et la motivation de travailler sur un projet qui allait vraiment
être utilisé par des gens et qui était attendu, m’a vraiment motivé.
La découverte d’un nouveau langage dont je n’avais jamais entendu parler aurait pu être
un vrai obstacle, mais avec l’aide de mon maitre de stage et de ses collègues ça n’a pas
été un problème, de plus le projet était assez intéressant et regorgeait de défis que je
n’avais pas cernés au début.
Je trouve WinDev vraiment intéressant par rapport à ses promesses de développement
multiplateformes, et même si les promesses de portage grâce à un clic ne sont pas
respectées, force est de constater que si j’avais dû réécrire toutes les fonctions maison en
Java ou en Kotlin, je n’aurais sans doute fait que ça. C’est donc une bonne surprise, même
si ce n’est pas la solution tant attendue de développement multiplateforme.
C’est une méthodologie qui m’a bien plue, et la liberté qui en résultait était assez agréable.
Je pense que ça a été aussi parce que j’étais la plupart du temps le seul à travailler sur
mon projet et que le projet était plutôt bien défini depuis le départ, par contre, le
télétravail a été beaucoup plus difficile à gérer, et là, peut être qu’une méthodologie un
peu plus restrictive m’aurait aidé à canaliser mon temps et mon attention.
Par rapport au projet, je suis content d’être arrivé à un résultat concluant, même s’il
manque encore un peu de travail pour pouvoir le mettre en production, et quelques petits
bugs doivent encore être réglés.
Le télétravail a été une expérience intéressante, car même si je gagnais du temps sur les
trajets, j’ai eu beaucoup de mal à garder des plages horaires fixes pour travailler et à ne
pas être dérangé, pour avoir fait 7 semaines en travail présentiel et 8 semaines en
télétravail, je préfère vraiment le travail présentiel, pour la facilité à rester concentré et
le nombre réduit de distractions. Et ce malgré les trajets.
Dans l’ensemble, je suis content de l’avancement du projet, même si le télétravail a un
peu ralenti ma productivité. Je suis parvenu à ne pas rester calé trop longtemps sur des
problèmes et le plus souvent j’ai réussi à proposer des solutions, qui étaient parfois
améliorées par mon maitre de stage, mais j’étais souvent sur la bonne voie. Une de mes
craintes était de rester calé sur des problèmes, et donc de ce point de vue là je suis
satisfait.
Un gros changement par rapport au projet scolaire a été de me consacrer à un seul projet
pendant aussi longtemps et le fait de ne pas devoir jongler entre les projets a été fort
appréciable.
Enfin, je suis reconnaissant d’avoir pu réaliser ce stage dans ces très bonnes conditions
d’encadrement malgré les événements, et de pouvoir en retirer autant d’expérience
positive.

40