Auberson Thierry PDF

Conception d’une application
permettant la gestion des processus de production

dans une boucherie de campagne
TRAVAIL DE BACHELOR
MÉMOIRE
PÉRIODE DE RÉALISATION DE MARS À OCTOBRE 2018
FILIÈRE INFORMATIQUE
ORIENTATION SYSTÈMES DE GESTION
RÉALISÉ PAR
Thierry Auberson
Professeur responsable :
M. Nicolas Glassey
Entreprise d’accueil :
Boucherie-Charcuterie Eric Peguiron

Centre Formation de Base
Travail de Bachelor
Préambule
Ce travail de Bachelor est réalisé en vue de l'obtention du titre de Bachelor of
Sciences en Ingénierie.
Son contenu, sans préjuger de sa valeur, n'engage ni la responsabilité de

l'auteur, ni celles du jury du travail de Bachelor et de l'Ecole.
Aucune utilisation, même partielle, de ce travail ne peut être faite sans

l'autorisation écrite préalable de la Direction. Toutefois, l'entreprise ou
l'organisation qui a confié un sujet de travail de Bachelor peut utiliser les
résultats du travail pour ses propres besoins.
Doyenne du
L. Larghi
Yverdon-les-Bains, novembre 2017
_______________________________________________________________________________
HEIG-VD, av. Sport 20, 1401 Yverdon-les-Bains
Tél. 024/557 76 09 / 07 Fax : 024/557 76 01
Département FEE
Filière Informatique
Orientation Systèmes de gestion
Candidat Auberson Thierry
Responsable Glassey Nicolas
TRAVAIL DE BACHELOR 2017 - 2018
Conception d'une application permettant la gestion des processus de

production dans une boucherie de campagne
Entreprise Boucherie -Charcuterie Eric Peguiron (Peguiron Eric)
Résumé publiable
L'entreprise Boucherie-Charcuterie Eric Peguiron est une entreprise individuelle située à

Fey dans le canton de Vaud, sur l’axe Echallens-Bercher. Elle est active dans le secteur
“commerce de détail de viandes et de produits à base de viande en magasin spécialisé”.
La boucherie est aujourd’hui gérée et dirigée par son propriétaire, Monsieur Eric Peguiron, et
emploi trois collaborateurs. Elle connaît un succès grandissant dans la région, si bien que des
clients de tout le canton de Vaud se déplacent pour acheter ses produits et spécialités.
Eric Peguiron jadis âgé d’à peine 20 ans, s’est vu contraint de reprendre les rennes de
l’entreprise suite au décès prématuré de son père, Monsieur Alfred Peguiron. Ne comptant
alors pour seul employé que son propriétaire, la gestion du travail, la planification de la
production et la gestion des commandes s’effectuaient à l’aide de supports papiers, tels que des
post-it et un agenda. Le jeune boucher-charcutier a ainsi dû faire face très jeune à une charge
colossale de travail pour reprendre et moderniser l’entreprise de son père. Ce qui ne lui a pas
permis de concentrer ses efforts sur l’optimisation des tâches de gestion administrative et de
planification de son entreprise.
La boucherie compte aujourd’hui 4 collaborateurs, Eric Peguiron le propriétaire et ses 3

employés. La quantité de travail réalisée aujourd’hui au quotidien par la boucherie-charcuterie
va de paire avec le nombre de personnes qui y travaillent. Il en découle donc que les méthodes
de gestion ne sont plus très adaptées aux besoin de l’entreprise et au volume croissant de ses
tâches administratives.
Ce projet, du nom de “Peguiplan”, a pour objectif d’implémenter un outil de gestion

informatique de planification de la production, des commandes clients et des commandes
fournisseurs. L’objectif étant de réduire la charge de travail et la répétition des tâches
administratives et non lucratives de l’entreprise. Le projet permettra ainsi de conserver les
données de clients afin de capitaliser le travail de saisie déjà effectué. Il réduira également la
forte dépendance aux connaissances tacites de son propriétaire qui le rend quasi indispensable
au bon fonctionnement de son entreprise. Et ceci en particulier lors de fortes demandes, telles
que les périodes estivales ou de fin d’année.
09.09.2018 - Travail de Bachelor de Auberson Thierry - Page 1 / 2
Les normes d’hygiène alimentaire sont également au coeur de ce projet. La viande est une
denrée rapidement périssable, elle peut être source de bactéries et tout ce qui peut être
manipulé en laboratoire doit pouvoir être lavé et désinfecté. C’est pourquoi le système actuel
avec l’agenda en papier a pour but d’être éliminé. Car il peut être en contact avec les mains non
lavées des collaborateurs, ne peut pas être lavé et est disposé toute l’année dans le laboratoire.
La solution qui sera développée dans le cadre de ce projet sera une application web, ayant
comme cadre les fonctionnalités de base d’un progiciel de gestion intégré pour effectuer la
partie de la gestion d’entreprise faite aujourd’hui sur des supports en papier. La solution
permettra ainsi de laisser libre choix futur quant au matériel de l’infrastructure informatique
cliente. Des composants tels que des écrans web ou ordinateurs répondant au normes
agroalimentaires pourraient ainsi être utilisés en laboratoire. Ces composants sont
généralement intégrés dans des boîtiers en INOX et peuvent ainsi être lavés et désinfectés avec
les produits de nettoyage spécifiques de la boucherie-charcuterie.
Pour terminer, l’application implémentera la possibilité d’extraire des statistiques de production

afin que Monsieur Eric Peguiron puisse calculer l’amortissement de ses infrastructures de
laboratoire.
Candidat
Auberson Thierry Date: 10.09.2018 Signature:
Responsable
Glassey Nicolas Date: 14.09.2018 Signature:
Boucherie -Charcuterie Eric Peguiron

Peguiron Eric Date: 10.09.2018 Signature:
09.09.2018 - Travail de Bachelor de Auberson Thierry - Page 2 / 2

3 Remerciements
En premier lieu, je remercie Monsieur Eric Peguiron, propriétaire de l’entreprise d’accueil

Boucherie-Charcuterie Eric Peguiron, d’avoir accepté de prendre part à cette aventure. Sa
disponibilité, sa participation et son infatigable enthousiasme pour ce projet ont été un élément clé
de la réussite de ce travail de Bachelor.
Je remercie Madame Sonia Zahnd, Monsieur Lionel Favre et Monsieur Jacques Rochat,
collaborateurs de l’entreprise d’accueil Boucherie-Charcuterie Eric Peguiron, pour leur
participation active pendant toute la durée de la réalisation de ce travail de Bachelor. Leur
expérience métier, leurs conseils et leurs recommandations m’ont permis d’avoir une meilleure
compréhension de leur environnement de travail, ce qui m’a permis d’adapter au mieux ce projet à
leurs besoins.
Je remercie Monsieur Nicolas Glassey, enseignant en informatique au Centre professionnel du

Nord Vaudois. En tant que professeur responsable et conseiller, il m’a guidé et soutenu durant
toutes les phases de ce travail de Bachelor. La rigueur, la motivation et le soutien qu’il a apporté tout
au long de ce projet ont été les facteurs déterminants qui m’ont permis de me surpasser et de le
réaliser.
Enfin, je tiens à remercier du fond du coeur Madame Elodie Auberson, ma très chère épouse, ainsi
que Luca et Elio Auberson, mes deux enfants, de m’avoir soutenu sans relâche tout au long de la
réalisation de ce travail de Bachelor, mais également et surtout durant ces quatres dernières années
d’études. Sans leur amour inconditionnel, leur force de caractère et leur courage infaillible, la
concrétisation de cette formation en emploi n’aurait jamais pu aboutir. Je leur dédie ce travail de
Bachelor.
Thierry Auberson 7 / 160

4 Table des matières
1 Préambule 3
2 Résumé 5
3 Remerciements 7
4 Table des matières 9
5 Introduction 17
6 Pré-requis de lecture 19
7 Présentation de l’entreprise 21
7.1 Historique de l’entreprise 21
7.2 Succès de l’entreprise 22
7.3 Organisation 22
7.4 Activités 23
8 Cahier des charges 25
8.1 Rappel des spécifications fonctionnelles 25
8.2 Rappel des spécifications techniques 25
8.2.1 L’infrastructure matérielle 26
8.2.2 La sauvegarde et la restauration du système 27
8.3 Rappel des Technical Stories 27
8.3.1 Mise en place du serveur 27
8.3.1.1 Installer le serveur web 27
8.3.1.1.1 Story 27
8.3.1.1.2 Tests d’acceptation 27
8.3.1.2 Installer l’application sur le serveur web 28
8.3.1.2.1 Story 28
8.3.2 Mise en place de l’outil de gestion de versions 28
8.3.2.1 Configurer l’outil de gestion de versions sur la machine de développement 28
8.3.2.1.1 Story 28

8.3.2.2 Configurer l’outil de gestion de versions sur le serveur 28
8.3.2.2.1 Story 28
8.4 Rappel des User Stories 29
8.4.1 Gestion des produits 29
8.4.1.1 Gérer les composants 29
8.4.1.1.1 Story 29
8.4.1.2 Gérer les articles 29
8.4.1.2.1 Story 29
8.4.2 Gestion des clients 30
8.4.2.1 Gérer les comptes clients 30
8.4.2.1.1 Story 30
8.4.2.2 Gérer les contacts 30
8.4.2.2.1 Story 30
8.4.3 Gestion des commandes 31
8.4.3.1 Gérer les commandes clients 31
8.4.3.1.1 Story 31
8.4.3.2 Imprimer les commandes clients 31
8.4.3.2.1 Story 31
8.4.3.3 Gérer les commandes fournisseurs 32
8.4.3.3.1 Story 32
8.4.3.4 Historiser les commandes clients 32
8.4.3.4.1 Story 32

8.4.4 Gestion des sauvegardes automatiques (Backups) 32
8.4.4.1 Sauvegarder les données de la base de données 32
8.4.4.1.1 Story 32
8.5 Nouvelle(s) User Story ajoutée(s) en cours d’implémentation 33
8.5.1 Gestion des commandes clients 33
8.5.1.1 Imprimer les commandes clients 33
8.5.1.1.1 Story 33
9 Démarche de projet 35
9.1 Méthode Agile 35
9.2 Le framework Scrum 35
9.3 La planification du projet 37
9.4 Différences par rapport à la planification 37
10 Les outils et technologies utilisés 39
10.1 Le serveur d’application RASPBERRY 39
10.2 Le système d’exploitation RASPBIAN 40
10.3 Le serveur HTTP Apache 2 40
10.4 Le langage de programmation PHP 41
10.5 Le langage de programmation JavaScript 41
10.6 La base de données MariaDB 41
10.7 Le schéma Apache-PHP-MariaDB 42
10.8 L’outil de gestion de versions Git 42
10.9 Le service Web d’hébergement de dépôt Bitbucket 44
10.10 Le framework Web PHP Laravel 44
10.10.1 Le principe modèle-vue-contrôleur 45
10.10.2 L’organisation de Laravel 45
10.10.2.1 Accessibilité 46
10.10.2.2 Le dossier app 46
10.10.2.3 Le dossier public 47
10.10.3 Traitements des requêtes 48

10.10.3.1 Les requêtes GET - demandes de formulaires 48
10.10.3.2 Les requêtes POST - envoies de formulaires 50
10.10.4 Les outils intégrés de Laravel 52
10.10.4.1 Artisan, la boîte à outils de Laravel 52
10.10.4.2 Le constructeur de contrôleurs 53
10.10.4.3 Le gestionnaire de migrations de la base de données 54
10.10.4.4 Le gestionnaire de population de la base de données 56
10.10.4.5 Le générateur de requêtes SQL Query Builder 57
10.10.4.5.1 Exemple de requête simple sur une ressource 57
10.10.4.5.2 Exemples complexes avec des jointures sur les tables 58
10.10.4.6 Le moteur de template Blade 59
10.11 Le framework de mapping objet-relationnel Eloquent 61
10.11.1 Exemple de requête simple sur une ressource 61
10.11.2 Exemple d’une requête avec jointure sur deux tables 62
10.12 Le framework de design graphique Bootstrap 63
10.13 Le framework de tests unitaires PHPUnit 63
10.14 L’environnement de développement 65
11 Réalisation 67
11.1 L’architecture globale 67
11.2 La préparation de l’infrastructure 68
11.3 La base de données 69
11.3.1 Le modèle logique des données (MLD) 69
11.3.2 Descriptif des tables et de leurs relations 70
11.3.2.1 La table des comptes clients - accounts 70
11.3.2.2 La table des contacts clients - contacts 70
11.3.2.3 La table des produits - products 70
11.3.2.4 La table des composants - components 70
11.3.2.5 La table des compositions - compositions 70
11.3.2.6 La table des commandes - orders 71
11.3.2.7 La table des lignes de commandes - order_lines 71
11.3.3 La création de la base de données 72

11.4 L’application Web avec le framework Laravel 73
11.4.1 Le gestionnaire de routes 73
11.4.2 Les modèles 74
11.4.3 Les contrôleurs 75
11.4.4 Les gestionnaires de données 76
11.4.5 Les règles de validations 76
11.4.6 La règle de validation spécifique pour les durées 77
11.4.7 Le script JavaScript pour filtrer la saisie 78
11.4.8 Les vues 79
11.4.8.1 L’affichage des dates en langue française dans les vues 80
11.4.8.2 L’export pdf des commandes clients 81
11.5 Les interfaces utilisateur 82
11.5.1 Menu de navigation 82
11.5.2 La gestion des clients 83
11.5.2.1 Index des comptes clients 83
11.5.2.3 Création d’un compte client 84
11.5.2.5 Création d’un contact client 85
11.5.2.6 Détails d’un compte client 86
11.5.2.8 Modification d’un compte client 87
11.5.2.9 Détails d’un contact client 88
11.5.2.10 Modification d’un contact client 89
11.5.2.11 Index des contacts clients 90
11.5.2.12 Convention pour la suppression 90
11.5.3 La gestion des articles 91
11.5.3.1 Index des composants 91
11.5.3.2 Création d’un nouveau composant 92
11.5.3.3 Détails d’un composant 92
11.5.3.4 Modification d’un composant 92
11.5.3.5 Index des produits 93
11.5.3.6 Création d’un nouveau produit 93
11.5.3.7 Détails d’un produit 94

11.5.3.8 Modification d’un produit 94
11.5.3.9 Création d’une nouvelle composition pour un produit 95
11.5.3.10 Convention pour la suppression 95
11.5.4 La gestion des commandes clients 96
11.5.4.1 Index des commandes clients 96
11.5.4.2 Filtre sur l’index des commandes clients 97
11.5.4.3 Création d’une nouvelle commande client 98
11.5.4.4 Détails de la commande 99
11.5.4.5 Ajouter un assortiment à la commande client 100
11.5.4.6 Choix des composants dans la composition du produit 100
11.5.4.7 Détails des lignes de commandes 101
11.5.5 La gestion des commandes fournisseurs 102
11.5.5.1 Affichage de la commande fournisseur 102
11.5.6 La fonction de statistiques 103
11.5.7 La fonction d’aide à la recherche 104
11.6 La sauvegarde des données - Backup 105
12 Bilan 107
12.1 La gestion de projet 107
12.2 Le respect de la planification 107
12.3 La solution réalisée 107
12.4 Les connaissances acquises 108
12.5 Les problèmes rencontrées 108
12.5.1 La conciliation entre les impératifs du projet et la vie familiale 108
12.5.2 La conciliation entre les impératifs du projet et l’activité professionnelle 108
12.5.3 Les difficultés techniques 109
12.5.3.1 La configuration du serveur 109
12.5.3.2 La prise en main du framework Laravel 109
12.5.3.3 Le filtrage de l’affichage des données dans les formulaires 109
12.5.3.4 L’outil de gestion de version Git 109
12.6 Les perspectives d’évolution 110
13 Conclusion 111

14 Dossier de gestion 113
14.1 Le déroulement du travail réalisé 113
14.1.1 Sprint 1 113
14.1.2 Sprint 2 114
14.1.3 Sprint 3 114
14.1.4 Sprint 4 115
14.1.5 Sprint 5 115
14.2 Le journal de travail 117
14.3 Rendez-vous et contacts avec le Conseiller et l’entreprise d’accueil 125
15 Informations du document 135
15.1 Historique des versions 135
15.2 Définitions, acronymes et abréviations 135
15.3 Vocabulaire métier 136
15.4 Vocabulaire technique 136
16 Exploitation des sources bibliographiques 139
16.1 Livres 139
16.2 Sources en ligne 140
16.3 Logiciels utilisés 142
17 Annexes 143
17.1 Installation du server Raspberry Pi 143
17.2 Préparation du dépôt Git sur Bitbucket 149
17.3 Configuration du NAS 153
17.4 Règles de validation spécifiques pour les valeurs TIME et Database 157
18 Authentification 159

5 Introduction
Ce travail de Bachelor a pour but d’apporter un soutien et une avancée technique dans la gestion
des processus de production d’une boucherie de campagne. La Boucherie-Charcuterie Eric
Peguiron, comme beaucoup de TPE, ne possède aucun outil informatique pour l’aide à la gestion de
son entreprise et n’est pas du tout familière avec l’utilisation de ce type de moyens dans son travail
quotidien.
Plus qu’un simple développement informatique, un outil de gestion d’entreprise requiert de

comprendre parfaitement les processus et méthodes de travail actuels du client afin de lui apporter
une solution adaptée à ses besoins dans ses tâches. La première étape consiste à se mettre à sa
place et de se synchroniser avec son vocabulaire métier afin de bien saisir la problématique
détaillée dans son ensemble. Puis il s’agit de transcrire ses besoins métiers en une solution
informatique et de le faire se projeter vers le futur avec une nouvelle solution ainsi qu’une nouvelle
manière d'appréhender son travail.
Un point important fut également d’apporter une attention toute particulière aux différentes parties
prenantes de ce projet, à savoir les collaborateurs de l’entreprise, qui en seront les futurs
utilisateurs. Car le succès de ce travail réside en grande partie dans son adoption par les
collaborateurs de la boucherie. La solution doit s’approcher au maximum des méthodes de travail
actuelles afin de leur éviter le plus possible un changement radical qui se traduirait par de la
résistance, voire même un refus d’utilisation.
Ce travail s’inscrit ainsi parfaitement dans la branche de “l’informatique orientée systèmes de

gestion”, car il met en pratique l’ensemble des compétences apprises au cours de cette formation. Il
fait ainsi appel à de la communication, à de la gestion d’entreprise et ses processus ainsi qu’à du
développement informatique ciblé sur les besoins du client.
Ce mémoire présentera ainsi le développement de l’application proprement dite, ainsi que les
différences avec ce qui avait été planifié dans le cadre de la pré-étude. Car dans cette phase, lors
de la conception, certaines difficultés techniques n’avaient pas pu être prévues et la solution finale
diffère légèrement.

6 Pré-requis de lecture
Ce mémoire traite de la phase d’implémentation du projet et des résultats obtenus en rapport avec
ce qui avait été planifié dans la phase de pré-étude. Il décrit le déroulement de ce qui a été
développé, les éléments qui ont été ajoutés ou modifiés en cours d’implémentation ainsi que le
retour d’expérience de ce projet.
Le contexte particulier de ce projet imposait le fait que la pré-étude devait intégrer une analyse
détaillée et figer les choix techniques, les modèles de bases de données et les interfaces
graphiques. Cela dans le but d’avoir un cadre clairement défini quant à ce que ce projet devait
réaliser et également ne pas réaliser, et de s’y tenir.
La lecture de ce mémoire nécessite d’avoir lu et pris connaissance de l’analyse afin de comprendre

son contenu et les développements qui en découlent.
Les différents chapitres de ce mémoire feront ainsi référence au document de pré-étude et

apportera des compléments ou des explications quant aux raisons des différences entre ce qui avait
été prévu et ce qui a été effectivement développé.
Les éléments principaux de la pré-étude sont :
● Le contexte et les besoins du mandant ;

● Les objectifs métier principaux et secondaires de ce projet ;
● L’identification de l’environnement métier du mandant et les diverses contraintes ;
● Les facteurs de risques de ce projet ;
● Le cahier des charges détaillé ;
● Les fonctionnalités sous forme de “User Story” à implémenter pour atteindre les objectifs du
mandant ;
● Les critères d’acceptation pour définir si les fonctionnalités livrées répondent à ce qui est
attendu ;
● L’analyse des solutions existantes et les choix techniques pour le développement de la
solution ;
● La planification générale avec l’ordonnancement des “Sprint” pour l’implémentation avec la
méthode Agile.

7 Présentation de l’entreprise
La Boucherie-Charcuterie Eric Peguiron est une raison individuelle qui a été fondée en mars 2007
par son titulaire, Monsieur Eric Peguiron.
Elle se situe à Fey, dans le canton de Vaud, sur l’axe du LEB, la compagnie du chemin de fer
Lausanne-Echallens-Bercher.
L’entreprise est composée d’un laboratoire pour la production et la transformation de la viande et

d’un magasin pour la vente de ses produits.
7.1 Historique de l’entreprise

Jadis nommée “Boucherie-Charcuterie Alfred Peguiron”, l’entreprise familiale était dirigée par ses
parents, Alfred et Ariane Peguiron. A cette époque, Monsieur et Madame Peguiron travaillaient seuls
dans l’entreprise.
Dès sa plus tendre enfance, Eric Peguiron rêvait de devenir boucher-charcutier pour un jour
reprendre les rennes de “l’entreprise de papa”. A sa sortie de l’école obligatoire, il a effectué son
apprentissage à la boucherie Plancherelle d’Orbe. Il comptait ensuite rester y travailler quelques
années, et éventuellement travailler dans d’autres boucheries de la région, afin d’acquérir de
l’expérience en dehors de l’entreprise familiale. Ceci dans le but d’être mieux préparé le jour où il
devrait reprendre l’entreprise de ses parents et devenir patron à son tour.
Mais la vie en a voulu autrement et le parcours qu’il avait prévu a été complètement renversé. Ce fut
en 2006, alors qu’il terminait à peine son apprentissage et avait alors tout juste 20 ans, quand son
père décède subitement. Ce fut donc sans pouvoir prolonger sa formation qu’il s’est trouvé dans
l’obligation de reprendre du jour au lendemain l’entreprise familiale.
C’est alors avec un courage exemplaire et un travail titanesque que Eric a repris l’entreprise de son
père. Les infrastructures étant déjà vieillissantes, notre jeune boucher est reparti de zéro et a vécu
sans salaire pendant une année pour se préparer à redémarrer.
Il lui a ainsi fallu reprendre contact avec les fournisseurs, moderniser ses machines et
infrastructures, se mettre à jour sur le plan administratif et refaire sa clientèle. Après 12 ans,
l’entreprise jouit d’une excellente renommée dans la région, si bien que des clients s’y déplacent de
tout le canton de Vaud. En plus d’avoir repris ses activités, la boucherie-charcuterie s’est agrandie,
car en plus de son titulaire, elle compte aujourd’hui trois employés et un apprenti boucher-charcutier.
L’entreprise génère aujourd’hui un chiffre d’affaires trois fois plus élevé qu’à l’époque où elle était
dirigée par ses parents. Ce volume d’affaires est en constante croissance, si bien que Monsieur Eric
Peguiron doit commencer à songer à d’éventuels futurs agrandissements.

7.2 Succès de l’entreprise
Le 5 novembre 2012, alors que Monsieur Lionel Favre venait tout juste d’achever son apprentissage
de boucher-charcutier avec le deuxième meilleurs résultat du canton, il s’est vu remettre le prix de
“Champion suisse” lors du “Championnat suisse des jeunes bouchers-charcutiers” qui s’est déroulé
à Thoune dans le cadre de l’exposition NeuLand.
Ce prix a été gagné à un concours, placé sous le patronage de la fondation “ swiss skils “
(www.swiss-skills.ch), qui vise à promouvoir le système de formation professionnelle duale suisse
auprès du grand public. Chaque année, tous les apprentis qui terminent leur formation
professionnelle avec une note supérieure à 5,5 sur 6 sont invités à participer à ce championnat
suisse.
Eric Peguiron éprouve une grande fierté et ne tarit pas d’éloges lorsqu’il évoque le succès de Lionel,
son second, qui a effectué sa formation auprès de lui.
7.3 Organisation
L’entreprise est dirigée par son propriétaire, Monsieur Eric Peguiron. Elle est divisée en deux
secteurs d’activité principaux, le laboratoire où s’effectue la préparation des produits et le magasin
où ils sont vendus.
La conduite des travaux en laboratoire est assurée par Monsieur Lionel Favre, avec l’appui de
Monsieur Eric Peguiron. Ensemble, ils prennent en charge la formation de leur apprenti, Monsieur
Alex Duplan.
La conduite de la vente en magasin est assurée par Monsieur Jacques Rochat, avec l’appui de
Madame Sonia Zahnd.
Lorsqu’il est en déplacement, Monsieur Eric Peguiron transmet la conduite de son entreprise à son
second, Monsieur Lionel Favre, qui se charge du bon déroulement des activités pendant son
absence.
Organigramme de la Boucherie-Charcuterie Eric Peguiron

7.4 Activités
La Boucherie-Charcuterie Eric Peguiron est active dans le désossage, la fabrication, la préparation
et la vente de produits à base de viande.
Le processus d’abattage ne fait pas partie des activités de l’entreprise, il est effectué par des
abattoires partenaires.
La viande est livrée par camion sous la forme de quartiers qui seront ensuite utilisés pour la
fabrication des différents produits vendus en magasin.

8 Cahier des charges
8.1 Rappel des spécifications fonctionnelles

Tel qu’il a été décrit dans la phase de pré-étude, il s’agit d’apporter une solution à la perte de temps
due à la répétition des tâches de saisies manuscrites des informations et à la forte dépendance du
savoir tacite du propriétaire de l’entreprise.
Le but de ce projet est d’implémenter une solution, sous la forme d’une application Web, dont les
fonctionnalités de base s’apparentent à ce que propose un progiciel de gestion intégré (ERP) sous
la forme de modules. Les fonctionnalités attendues sont :
● La gestion des commandes clients ;

● L’automatisation de la génération des commandes fournisseurs ;
● L’historisation des produits commandés pour effectuer des statistiques.
Tout comme dans tout ERP, les diverses fonctionnalités ont des dépendances les unes avec les
autres. Une commande client est destinée, et donc liée à un client, et contient un ou plusieurs
articles commandés. La gestion des commandes clients dépend ainsi de la gestion des clients et
des articles.
Pour pouvoir fonctionner, ces fonctionnalités nécessitent que l’application intègre d’autres
fonctionnalités sur lesquelles elles seront basées telles que :
● La gestion des clients ;

● La gestion des produits fabriqués pour la vente.
Le résultat attendu de ce projet permettra de répondre au besoin métier spécifique du client, sans
alourdir le processus actuel.
8.2 Rappel des spécifications techniques

La Boucherie-Charcuterie Eric Peguiron ne possède actuellement aucun outil informatique pour la
gestion de ses processus. Le choix des technologies était libre mais la solution doit pouvoir
s’interfacer avec l’infrastructure matérielle informatique existante.
Les seules contraintes sont les moyens financiers et la disponibilité du système. L’investissement
financier de matériel doit être le plus faible possible et le système doit proposer un moyen de
restauration en cas de dommage.

8.2.1 L’infrastructure matérielle
L’entreprise est équipée d’une infrastructure informatique. Elle est constituée d’un ordinateur de
bureau, d’une imprimante, de l’ordinateur portable du propriétaire et d’un disque de stockage réseau
NAS (type Synology). Tous ces composants sont connectés au réseau local, et reliés au
modem/routeur du fournisseur d’accès internet.
Infrastructure informatique actuelle
L'infrastructure matérielle à installer doit compléter l’infrastructure actuelle sans modifier ce qui est
existant. Le serveur d’application vient s’insérer dans le réseau et doit être accessible par les
composants existants.
Ajout du serveur d’application à l’infrastructure informatique

8.2.2 La sauvegarde et la restauration du système
A partir de l’instant où l’entreprise aura basculé définitivement sur la nouvelle solution, les données
saisies dans l’application seront vitales pour le bon déroulement des activités. Le système doit
effectuer régulièrement une sauvegarde de ses données pour une éventuelle restauration en cas de
dommage du matériel ou de crash du système.
Le stockage réseau NAS connecté au réseau de l’entreprise sera utilisé comme serveur de
sauvegarde des données de l’application. Ce NAS est équipé de deux disques durs montés en
RAID 1 (copie miroir, 1 à 1). En cas de dommage de l’un des deux disques, l’intégrité des données
est assurée car elles sont entièrement enregistrées sur chacun des deux disques durs.
Afin de décharger le propriétaire de l’entreprise et ses employés, le serveur hébergeant la base de

données doit effectuer cette tâche automatiquement. Un script de sauvegarde de la base de
données ainsi qu’un script de transfert automatique de ces sauvegardes sur le NAS doivent être
créés.
8.3 Rappel des Technical Stories
8.3.1 Mise en place du serveur
8.3.1.1 Installer le serveur web

8.3.1.1.1 Story
En tant que développeur, je veux installer un serveur web, afin de pouvoir héberger mon application
et sa base de données.
8.3.1.1.2 Tests d’acceptation

1. Le système d’exploitation est installé, lorsque je démarre le serveur et que j’arrive sur la
page de connexion, je peux me connecter avec les données de connexion du mandant et
accéder à sa session.
2. Le serveur Http est installé, lorsque j’entre l’adresse IP du serveur dans un navigateur web
d’une machine cliente connectée au réseau local, le serveur web me renvoie sur la page
d’accueil par défaut du serveur Http.
3. Le serveur PHP est installé, lorsque j’entre l’adresse IP du serveur dans un navigateur web
d’une machine cliente connectée au réseau local, le serveur web me renvoie sur la page
d’accueil du serveur PHP.
4. La base de données est installée, lorsque je m’y connecte avec les données de connexion
du mandant, je peux visualiser les bases de données et leurs tables.

8.3.1.2 Installer l’application sur le serveur web
8.3.1.2.1 Story
En tant que développeur, je veux installer le Framework sur le serveur web, afin de pouvoir
héberger, exécuter et tester mon application.

1. Le Framework est installé sur le serveur, lorsque j’entre l’adresse IP du serveur dans un
navigateur web d’une machine cliente connectée au réseau local, le serveur web me
renvoie sur la page d’accueil du Framework.
8.3.2 Mise en place de l’outil de gestion de versions
8.3.2.1 Configurer l’outil de gestion de versions sur la machine de développement

8.3.2.1.1 Story
En tant que développeur, je veux installer un outil de gestion de versions, afin de pouvoir gérer les
versions de développements de la solution sur un serveur décentralisé.

1. Le dépôt du projet est créé sur un serveur décentralisé, lorsque je transferts mon application
via mon terminal de commande, la nouvelle version de l’application est transmise et
disponible sur le serveur décentralisé.
2. La paire de clés SSH est créée (privée et publique) et la clé privée est ajoutée au dépôt du
projet sur le serveur décentralisé, lorsque je transfert l’application sur le serveur décentralisé
avec le terminal de commande, l’application est transmise via SSH sans devoir entrer le mot
de passe du dépôt décentralisé.
8.3.2.2 Configurer l’outil de gestion de versions sur le serveur

8.3.2.2.1 Story
En tant que développeur, je veux installer un outils de gestion de versions, afin de pouvoir
facilement mettre à jour la solution sur le serveur avec les dernières versions transmises sur le
dépôt décentralisé.

1. Le projet est disponible sur le dépôt décentralisé, lorsque je récupère le projet sur le serveur
distant, le projet sur le serveur local est mis à jour et l’application contient les dernières
modifications.
2. La paire de clés SSH est créée (privée et publique) et la clé privée est ajoutée au dépôt du
projet sur le serveur décentralisé, lorsque je récupère l’application sur le serveur
décentralisé avec le terminal de commande, l’application est récupérée via SSH sans devoir
entrer le mot de passe du dépôt décentralisé.

8.4 Rappel des User Stories
Les divers Stories suivantes seront issues du diagramme des cas d’utilisations fourni précédemment
et contiendront les scénarios ainsi que leurs critères d’acceptations. Ces stories indiqueront le
bénéficiaire du produit, leur besoin ainsi que la valeur métier qui est visée.
8.4.1 Gestion des produits
8.4.1.1 Gérer les composants

8.4.1.1.1 Story
En tant que collaborateur je veux pouvoir gérer les composants, afin de pouvoir les créer et les
modifier en base de données.

1. Je suis sur la page des composants, lorsque j’enregistre un nouveau composant avec les
champs renseignés, ce composant est enregistré en base de données.
2. Le composant est enregistré, lorsque je le sélectionne, je peux visualiser ses données.
3. Le composant est enregistré, lorsque je modifie ses informations, ses données sont
modifiées en base de données.
4. Des composants sont enregistrés, lorsque je clique sur lister les composants, je peux
visualiser tous les composants enregistrés en base de données.
8.4.1.2 Gérer les articles

8.4.1.2.1 Story
En tant que collaborateur, je veux pouvoir gérer les articles, afin de pouvoir les créer et les modifier
en base de données.

1. Je suis sur la page de création des articles, lorsque j’enregistre un nouvel article avec les
champs renseignés, cet articles est enregistré en base de données.
2. Je suis sur la page de création des articles, lorsque j’ajoute un composant dans cet article,
la composition est enregistrée en base de données.
3. J’ajoute un composant dans un article, lorsque je renseigne le prix de la préparation, ce prix
est enregistré en base de données dans la composition.
4. Un article est enregistré, lorsque je le sélectionne, je peux visualiser les composants qui en
font partie.
5. Un article est enregistré, lorsque je le modifie, ses données sont modifiées en base de
données.
6. Un article et sa composition sont enregistrés, lorsque j’ajoute un nouveau composant,
l’article est enregistré en base de données avec ce nouvel article.
7. Un article et sa composition sont enregistrés, lorsque je supprime un composant, l’article est
enregistré en base de données avec ce composant en moins.

8.4.2 Gestion des clients
8.4.2.1 Gérer les comptes clients

8.4.2.1.1 Story
En tant que collaborateur, je veux pouvoir gérer les comptes clients, afin de pouvoir les créer et les
modifier dans la base de données.

1. Je suis sur la page de création d’un nouveau compte, lorsque j’enregistre un nouveau
compte avec les champs renseignés, ce compte est enregistré en base de données.
2. Le compte client est enregistré en base de données, lorsque je le sélectionne, je peux
visualiser ses données.
3. Le compte client est enregistré en base de données, lorsque je modifie ses informations,
ses données sont modifiées en base de données.
4. Des comptes clients sont enregistrés, lorsque je clique sur lister les comptes clients, je peux
visualiser tous les comptes clients enregistrés en base de données.
8.4.2.2 Gérer les contacts

8.4.2.2.1 Story
En tant que collaborateur, je veux pouvoir gérer les contacts pour un compte client donné, afin de
pouvoir les créer et les modifier dans la base de données.

1. Je suis sur la page d’informations d’un compte client, lorsque je crée un nouveau contact, je
peux créer un nouveau contact dans ce compte client.
2. Je suis sur la page de création d’un nouveau contact, lorsque j’enregistre un nouveau
contact avec les champs renseignés, ce contact est enregistré dans la base de données
sous le compte client.
3. Le contact est enregistré, lorsque je le sélectionne, je peux visualiser ses données.
4. Le contact est enregistré, lorsque je modifie ses informations, ses données sont modifiées
en base de données.
5. Des contacts sont enregistrés pour un compte client, lorsque je suis sur la page
d’information du compte client correspondant, je peux visualiser les contacts qui y sont
rattachés.

8.4.3 Gestion des commandes
8.4.3.1 Gérer les commandes clients

8.4.3.1.1 Story
En tant que collaborateur, je veux pouvoir gérer les commandes clients, afin de pouvoir suivre et
planifier les commandes de chaque client.

1. Je suis sur la page d’informations d’un contact, lorsque je crée une nouvelle commande, je
peux saisir des articles pour cette commande dans des lignes de commande.
2. Je suis sur la page de saisie d’une nouvelle commande, lorsque j’ajoute des articles, le
nouvel article s’ajoute à la commande dans une nouvelle ligne de commande en base de
données.
3. Je suis sur la page de saisie d’une nouvelle commande, lorsque je supprime un article, cet
article s’enlève de la ligne de commande en base de données.
4. Je suis sur la page des commandes clients, lorsque j’enregistre la commande avec la date
de livraison renseignée, cette commande est enregistrée en base de données.
5. Je suis sur la page des commandes clients, lorsque je clique sur lister les commandes, je
peux visualiser toutes les commandes clients ouvertes dans l’ordre des dates de livraisons.
6. Une commande client est enregistrée en base de données, lorsque je modifie ses
informations ou son contenu, les modifications sont enregistrées en base de données.
8.4.3.2 Imprimer les commandes clients

8.4.3.2.1 Story
En tant que collaborateur, je veux pouvoir imprimer les commandes du lendemain ou d'un jour
donné, afin de pouvoir les prendre au laboratoire, y inscrire des notes et les transmettre au client
avec la livraison pour information.

1. Je suis sur la page d'informations d'une commande client, lorsque je clique sur le bouton
imprimer la commande, l’'application génère un fichier (pdf ou autre) contenant les
informations de la commande client.
2. Je suis sur la page des commandes à produire le jour suivant, lorsque je clique sur le
bouton imprimer les commandes, l'application génère un fichier (pdf ou autre) contenant
toutes les commandes clients dont chacune sur une page différente.
3. Je suis sur la page des commandes d'un jour défini par le collaborateur, lorsque je clique
sur le bouton imprimer les commandes, l'application génère un fichier (pdf ou autre)
contenant toutes les commandes clients dont chacune sur une page différente.

8.4.3.3 Gérer les commandes fournisseurs
8.4.3.3.1 Story
En tant que collaborateur, je veux pouvoir lister les produits en commande pour les jours à venir,
afin de pouvoir générer les commandes fournisseurs facilement.

1. Des commandes sont saisies dans le système, lorsque je clique sur le bouton commande
fournisseurs pour les 3 prochains jours, la liste des produits à commander chez le
fournisseur est affichée.
2. Des commandes sont saisies dans le système, lorsque je sélectionne la période (date de
début et date de fin) pour laquelle je veux lister les commandes, la liste des produits à
commander chez le fournisseur est affichée.
8.4.3.4 Historiser les commandes clients

8.4.3.4.1 Story
En tant que propriétaire, je veux pouvoir lister les produits commandés sur une période donnée, afin
de pouvoir faire des statistiques des consommations de chaque produit.

1. Des commandes sont saisies dans le système, lorsque je clique sur le bouton statistiques
annuelles, la liste de tous les produits commandés sur l’année en cours sont affichés.
2. Des commandes sont saisies dans le système, lorsque je sélectionne une année d’activité
et que je clique sur le bouton statistiques annuelles, la liste de tous les produits commandés
l’année choisie sont affichés.
3. Des commandes sont saisies dans le système, lorsque je sélectionne une période d’activité
(date de début et date de fin) et que je clique sur le bouton statistiques partielles, la liste de
tous les produits commandés durant la période choisie est affichée.
8.4.4 Gestion des sauvegardes automatiques (Backups)
8.4.4.1 Sauvegarder les données de la base de données

8.4.4.1.1 Story
En tant que propriétaire, je veux disposer d’un système de sauvegarde automatique des données de
l’application, afin de pouvoir disposer de sauvegardes de mes données à des fins de restauration du
système en cas de dommage du serveur.

1. Le serveur est fonctionnel et actif, lorsque le serveur hébergeant l’application effectue son
processus de sauvegarde automatique en fin de journée, le fichier de sauvegarde est
enregistré sur mon NAS.
2. Un nouveau serveur est installé, lorsque je restaure les données de sauvegarde sur ce
serveur, toutes les données qui figuraient dans l’ancien serveur sont à nouveau disponibles.

8.5 Nouvelle(s) User Story ajoutée(s) en cours
d’implémentation
8.5.1 Gestion des commandes clients
8.5.1.1 Imprimer les commandes clients

8.5.1.1.1 Story
En tant que collaborateur, je veux pouvoir imprimer les commandes du lendemain ou d'un jour
donné, afin de pouvoir les prendre au laboratoire, y inscrire des notes et les transmettre au client
avec la livraison pour information.

1. Je suis sur la page d’informations d’une commande client, lorsque je clique sur le bouton
imprimer la commande, l’application génère un fichier (pdf ou autre) contenant les
informations de la commande client.
2. Je suis sur la page des commandes à produire le jour suivant, lorsque je clique sur le
bouton imprimer les commandes, l’application génère un fichier (pdf ou autre) contenant
toutes les commandes clients dont chacune sur une page différente.
3. Je suis sur la page des commandes d’un jour défini par le collaborateur, lorsque je clique
sur le bouton imprimer les commandes, l’application génère un fichier (pdf ou autre)
contenant toutes les commandes clients dont chacune sur une page différente.

9 Démarche de projet
9.1 Méthode Agile

La démarche suivie pour le développement et l’implémentation de ce travail de Bachelor s’est
effectuée selon une méthode Agile. Cette méthode permet d’impliquer le ‘Product Owner’
(propriétaire du produit, le mandant) le plus possible tout au long du processus de développement
afin qu’il puisse suivre l’évolution de son produit. Cela lui permet de pouvoir faire partie du projet et
de donner son avis et ses impressions sur la solution en cours de développement.
Cette méthode consiste à découper l’ensemble du projet en fonctionnalités métier, décrites sous la
formes de ‘User Stories’, qui sont implémentées de manière itérative. Contrairement à un
développement conventionnel avec une méthode ‘Waterfall’, les fonctionnalités peuvent être livrées
ou mises en production chez le client au fur et à mesure du développement. Cela lui permet de
pouvoir valider si les fonctionnalités livrées correspondent à son besoin et à ses attentes. Il peut
également disposer de l’application, la tester et prendre en main son nouvel outil de travail.
De manière générale, cette méthode permet de conserver un contact proche et régulier avec le
client. Elle lui permet ainsi de pouvoir demander des modifications ou des ajouts de fonctionnalités
durant la phase de développement. Il peut ainsi avoir une meilleure garantie que son produit
correspondra bien à ses besoins métier.
9.2 Le framework Scrum

Scrum est un Framework et un ensemble de bonnes pratiques qui permet le développement de
produits complexes et qui répond à la plupart des préconisations Agile. Le découpage d’un projet
selon Scrum se fait sur le principe de “Release”, “Sprint”, “User stories” et “Tasks”.
Une Release correspond à une version d’un produit. Ce travail de Bachelor est développé dans une
seule Release et correspond à la solution complète attendue par le mandant.
Cette Release est découpée en plusieurs Sprints qui correspondent à des phases de
développement de la solution, les itérations. Le principe est de procéder à un Sprint Planning avec
le client avant de démarrer le sprint en question et de convenir des fonctionnalités, les user stories,
qui seront implémentées. La durée du sprint est fixe et définie à l’avance, et l’estimation se fait sur le
nombre de fonctionnalités qui pourront être implémentées pendant cette itération. Contrairement à
une méthode Waterfall qui tente d’estimer le temps nécessaire pour réaliser un travail défini.
Au terme du sprint, une démonstration est faite au client lors d’une sprint review. Ce sprint review
permet au client de confirmer si le développement répond ou pas à ses attentes. Les fonctionnalités
développées correspondent ainsi à des livrables potentiels. Ces fonctionnalités, les User stories,
sont décrites sous la forme de scénarios utilisateurs. Le but étant d’apporter une solution à un
besoin métier.

Les développeurs créent ensuite des ‘Tasks’ pour chaque story qui leur permettent de définir les
tâches qu’ils auront à effectuer pour implémenter les fonctionnalités de la story.
En résumé, cette méthode de découpage permet d’obtenir une granularité la plus fine possible d’un
projet complexe de grande envergure. Cela permet ainsi de pouvoir estimer facilement ce qui pourra
être développé durant les sprints de durées fixées auparavant.
Déroulement d’une démarche Scrum
Scrum fait également intervenir les notions de ‘Sandbox’, ‘Product Backlog’ et ‘Sprint Backlog’.
Ce sont des sortes de containers à fonctionnalités dans lesquelles se trouvent les stories en attente.
La Sandbox peut être vue comme une boîte à idées dans laquelle les diverses requêtes de
fonctionnalités y sont déposées. Les stories se trouvant dans la Sandbox n’ont pas encore été
validées par le client et pourraient très bien ne jamais être développées.
Les stories se trouvant dans le Product Backlog sont des fonctionnalités qui se trouvaient dans la
Sandbox et qui ont été validées par le client. Cela signifie qu’il souhaite qu’elles soient
implémentées car il en a le besoin mais qu’elles n’ont pas encore été planifiées. Les stories qui
figurent dans le product backlog doivent contenir de critères d’acceptation, qui serviront de base
pour le client et l’équipe de développement. Ces critères d’acceptation permettront de valider si ce
qui a été développé correspond ou pas à ce qui est attendu.
Le Sprint Backlog contient les stories qui ont été planifiées pour un sprint en particulier. Elles sont
ainsi transférées du Product Backlog lors des Sprint Planning en accord entre le client et l’équipe de
développement.
Cycle de vie d’une fonctionnalité (ou produit)

9.3 La planification du projet
La planification et le plan de travail du projet avaient été clairement définis lors la pré-étude.
L’ordonnancement des sprints et des stories à livrer tenaient compte de la logique métier et de leurs
dépendances techniques.
Planification générale des Sprints
Les sprints doivent généralement tous avoir une durée identique qui varient de deux à quatre
semaines. Mais la planification de ce projet était légèrement différente. Le premier et le cinquième
sprints avaient une durée de une semaine alors que le deuxième, troisième et le quatrième avaient
une durée de trois semaines.
Cette planification était principalement due au fait que le client a fermé l’entreprise pendant deux
semaines pour les vacances d’été du 2 au 19 août. L’objectif était de pouvoir achever les deux
premiers sprints et livrer les fonctionnalités avant la fermeture estivale. Le développement des
fonctionnalités du troisième sprint pouvait ainsi se poursuivre pendant les vacances de l’entreprise
et être mis en production à leur retour.
9.4 Différences par rapport à la planification

Le déroulement réel de l’implémentation s’est réalisé conformément à la panification définie lors de
la pré-étude. Les stories ont ainsi été implémentées et mises en production selon les prévisions et
attentes du client.
Il y a cependant de légères modifications dans le contenu des fonctionnalités développées. Lors du

‘Sprint review’, à la livraison des fonctionnalités du deuxième sprint, le client a émis le souhait de
pouvoir imprimer les commandes clients sur des feuilles de papier.
Cette fonctionnalité n’avait pas été prévue lors de la pré-étude et a été ajoutée en cours
d’implémentation. Cela a conduit à la création d’une nouvelle story avec ses critères d’acceptation.
Cette fonctionnalité ayant une grande importance pour le mandant, elle a été directement ajoutée
dans le sprint backlog afin d’être mise en production en même temps que la gestion des
commandes clients.
Le mandant a fait une demande d’ajout de fonctionnalité supplémentaire au terme du troisième

sprint, lors de la mise en production des commandes clients. Prenant conscience à ce moment du
problème auquel il ferait face en cas de crash de son serveur, le mandant a demandé de pouvoir
disposer d’une redondance de son application. Ceci afin de pouvoir remonter très rapidement son
système et de ne pas être bloqué dans ses activités si un tel événement venait à se produire. Une
story a ainsi été créée dans la Sandbox. Elle sera traitée hors travail de Bachelor, avant le passage
définitif sur la nouvelle solution.

10 Les outils et technologies utilisés
Le contexte particulier de ce travail de Bachelor comportait un risque quant à son cadre et à son
contenu. Le fait que le développement partait de “feuille blanche”, il était important que les différents
outils et technologies aient été clairement définis dans la phase de pré-étude. Le but étant de
pouvoir démarrer directement le développement de l’application dès le début de la phase
d’implémentation et d’empêcher des modifications durant cette phase.
Les différents outils et technologies utilisés dans le cadre de ce travail de Bachelor ont été définis et
choisis dans le cadre de la pré-étude et sont décrits dans ce chapitre.
10.1 Le serveur d’application RASPBERRY

Le serveur d’application est un nano-ordinateur de type RASPBERRY Pi 3 model B+. Cet appareil
contient tous les composants de base d’un ordinateur et a l’avantage d’être très compact et bon
marché.
RASPBERRY Pi 3 model B+
Il existe de nombreuses applications pour lesquelles ce type d’appareil peut-être utilisé. Il est équipé
des composants suivants :
● Un processeur 64 bit de 1,4 GHz ;

● 1 Gb de RAM DDR2 ;
● Une carte réseau “LAN Gigabit Ethernet” ;
● Une carte réseau sans fil “wireless LAN ;
● Un port HDMI pour connecter un écran ;
● 4 ports USB 2.0 ;
● etc…
Il existe plusieurs types de systèmes d’exploitation (OS) qui peuvent être installés, dont Windows 10
ou différentes distributions GNU/Linux. L’OS proposé de base par la communauté Raspberry se
nomme “RASPBIAN”, qui est la contraction de “RASPBERRY” et “Debian” dont RASPBIAN est
dérivé.
Ceci le rend parfaitement adapté à une utilisation en tant que serveur Web pour des applications
pas trop conséquentes. Le fait qu’il soit muni d’une interface WLAN donne également la souplesse
de pouvoir l’installer où l’on veut, il suffit simplement de le brancher à une source d’alimentation
électrique et il peut ensuite être accédé et configuré par réseau sans fil.

10.2 Le système d’exploitation RASPBIAN
Le système d’exploitation installé sur le serveur d’application est celui proposé de base par la
communauté RASPBERRY, l’OS RASPBIAN.
Dans le cadre de la pré-étude de ce travail de Bachelor, il avait été fait mention d’utiliser la
distribution “UBUNTU MATE” qui est une distribution dérivée de DEBIAN, tout comme l’est
RASPBIAN. L’avantage de UBUNTU MATE est qu’il contient l’ensemble des applications, ou la
collection de logiciels, fournies par les distributions UBUNTU destinées aux ordinateurs de bureau.
Mais la version pour RASPBERRY demande plus de ressources que la version de base RASPBIAN
et la mise à jour du système ne fonctionnait pas. Et cette collection de logiciels n’avait aucune utilité
dans l’utilisation de ce projet.
C’est donc la distribution RASPBIAN qui a été retenue et installée sur le serveur d’application de ce
projet.
Logo de la distribution RASPBIAN
10.3 Le serveur HTTP Apache 2

Le serveur HTTP utilisé est Apache version 2, un logiciel libre créé et maintenu au sein de la
fondation Apache. Ce logiciel est très largement utilisé et est l’un des plus populaire du “World Wide
Web”.
Logo de Apache HTTP Server
Il fonctionne principalement sur des systèmes d’exploitation de type UNIX sur lequel est basé
RASPBIAN. Il est également conçu pour prendre en charge de nombreux modules tel que PHP
utilisé dans ce projet.
Ces caractéristiques font de Apache 2 un logiciel parfaitement adapté à ce projet. Son rôle est de
recevoir les requêtes HTTP sur le port 80 venant de l’application, et de les rediriger vers la racine de
l’application Web.

10.4 Le langage de programmation PHP
L’application Web est développée avec le langage de programmation libre PHP, qui signifie
“Hypertext Preprocessor”. Il est principalement utilisé pour produire des pages Web dynamiques via
un serveur HTTP.
Logo de PHP
PHP permet d’accéder à une base de données et fait office d’interface entre les pages Web et la
base de données de l’application.
Ce langage est très populaire et est considéré comme une des bases pour la création de sites et
applications Web. Il a notamment été utilisé pour créer des sites célèbres tels que Facebook ou
Wikipedia.
10.5 Le langage de programmation JavaScript

Certaines fonctions nécessitant une interactivité du côté client, dans le page Web de l’application,
ont été développée avec le langage de programmation de scripts “JavaScript”.
Logo de JavaScript
Ces fonctions sont celles de recherches dynamiques de ressources dans les champs de saisies de
formulaires des interfaces utilisateurs. Lorsque l’utilisateur entre deux caractères ou plus dans un
champs de saisie, le programme réalisé en JavaScript filtre et affiche les données contenant ce
texte uniquement. Ceci rendant les pages Web dynamiques du point du vue de l’utilisateur.
10.6 La base de données MariaDB

Le système de gestion de base de données relationnelles (SGBDR) utilisé est “MariaDB”. Il s’agit
d’un fork du SGBDR “MySQL”, il est édité sous licence GPL et sa gouvernance est assurée par la
fondation “MariaDB”. La raison de ce fork est due au rachat de MySQL par Sun Microsystems en
2009.
MariaDB assure une interopérabilité avec MySQL afin de pouvoir le remplacer. Plusieurs
distributions GNU/Linux ont ainsi abandonné MySQL au profit de MariaDB telles que “Fedora”,
“openSuse” et “Debian”, qui sont les acteurs principaux dans le domaine.
Logo de MariaDB
Ce SGBDR a été rapidement adopté à large échelle, si bien que Google a annoncé son adoption en
2013 et a affecté un de ces ingénieurs à la Fondation MariaDB.

10.7 Le schéma Apache-PHP-MariaDB
Schéma d’interactions Apache-PHP-MariaDB
10.8 L’outil de gestion de versions Git

L’outil de gestion de versions de développement utilisé est le logiciel libre “Git”. Il a été développé
par l’auteur du noyau Linux, “Linus Torvalds”. Il est le logiciel de gestion de versions décentralisé le
plus populaire et il est utilisé par plus de douze millions de personnes.
Logo de l’outil de gestion de versions Git
Cet outil est très apprécié dans le cadre de développements faisant intervenir de multiples
développeurs. Git stocke toutes les informations du projet dans un dépôt local, comme le code
source de l’application et les différentes versions de développement. Ce dépôt local peut ensuite
être transféré sur un dépôt distant d’un service Web d’hébergement, afin de le partager entre
différents membres d’une équipe de développeurs.
Un dépôt contient une branche de base, la branche “master”, qui contient la version du logiciel qui
est mise en production.
Il est généralement de coutume de créer une branche “develop” sur laquelle figure la version de
développement de l’application.

Il est ensuite possible de créer différentes branches temporaires basées sur le développement de
base, le temps du développement d’une fonctionnalité, qui seront ensuite migrées et insérées dans
la branche “develop” avant d’être supprimées. Ceci permettant de bien séparer les différentes
fonctionnalités à développer entre les différents membres d’une équipe de développement.
Ce type de scénario est connu sous le nom de “Workflow”. Il définit le processus de créations et de
migrations des branches de développement d’une application.
Exemple d’un Workflow de développement avec Git

10.9 Le service Web d’hébergement de dépôt Bitbucket
Il existe de nombreux services Web d’hébergement de dépôts Git. Le plus populaire est “GitHub car
il héberge de nombreux projets libres tels que le noyau Linux ou le Framework Laravel utilisé pour le
développement de ce projet.
Bitbucket offre de nombreuses fonctionnalités semblables à GitHub, mais il favorise plutôt les petites
équipes de développements. Il présente l’avantage d’être gratuit et de n’avoir aucune limite de
dépôts privés pour des équipes inférieures à 5 développeurs. Contrairement à GitHub où seuls les
dépôts publiques sont gratuits.
Logo de Bitbucket
Le développement de cette application, dans le cadre de ce travail de Bachelor, ne nécessitait pas

absolument d’utiliser cet outil. Mais son usage a permis d’apprendre les rudiments d’un tel scénario
et a également simplifié le transfert de l’application sur le serveur en production chez le mandant.
L’application développée est ainsi stockée dans le dépôt local de la machine de développement.
Lorsqu’une version de développement est achevée, elle est transférée sur le dépôt distant hébergé
sur Bitbucket pour pouvoir être récupérée par le serveur d’application en production chez le
mandant.
10.10 Le framework Web PHP Laravel

L’application réalisée a été principalement développée à l’aide du framework Web open-source
Laravel. Ce framework est écrit en PHP et est entièrement développé en programmation orientée
objet.
Logo de Laravel
L’utilisation de ce framework présente l’avantage de développer une application Web avec une
structure standard et connue de tout développeur Web. Il respecte des principes de développements
standards et est constitué de plusieurs outils intégrés qui facilitent le développement d’une
application. Cela permet de se concentrer uniquement sur le développement des fonctionnalités de
l’application et de ne pas devoir tout développer de zéro.

10.10.1 Le principe modèle-vue-contrôleur
Laravel respecte le principe modèle-vue-contrôleur (MVC) qui est un design pattern de conception
connu de tout développeur Web. Ce design pattern permet de respecter un ensemble de bonnes
pratiques dans la structure et l’interaction des fichiers de code source de l’application.
Schéma du principe MVC
Ce modèle définit clairement le rôle de chaque partie du code de l’application :
● Le modèle représente les données en base de données ou les entités de l’application.

● La vue est chargée de la mise en forme pour l’utilisateur. Ce sont les pages Web.
● Le contrôleur est chargé de gérer l’ensemble. Il a le rôle de “chef d’orchestre” de
l’application.
10.10.2 L’organisation de Laravel

Lors de son installation, Laravel contient plusieurs dossiers contenant les différentes parties de
l’application.
Structure des dossiers à la racine de l’application Laravel
● app : ce dossier contient les éléments essentiels de l’application ;

● bootstrap : les scripts d’initialisation de Laravel pour le chargement automatique des
classes, la fixation de l’environnement et des chemins, et pour le démarrage de l’application
;
● config : toutes les configurations : application, authentification, cache, base de données,
espaces de noms, session…
● database : les fichiers de migrations et de populations de la base de données ;
● public : tout ce qui doit apparaître dans le dossier public du site Web : images, fichiers CSS,
fichiers de scripts…
● resources : les vues, fichiers de langages et assets ;
● routes : les fichiers de routage de l’application
● storage : les données temporaires de l’application : vues compilées, caches, clés de
session…

● tests : fichiers de tests unitaires ;
● vendor : tous les composants de Laravel et de ses dépendances.
10.10.2.1 Accessibilité
Pour des raisons de sécurité sur le serveur, seul le dossier public doit être accessible par les clients
de l’application. Les autres dossiers ne sont accessibles que par l’application Laravel elle-même.
Accessibilité des dossiers de l’application Laravel
10.10.2.2 Le dossier app

Le dossier app contient les dossiers principaux de l’application ainsi que les modèles représentant
les entités en base de données :
● Http : Ce dossier contient les dossiers Controllers et Requests

○ Controllers : contient les différents contrôleurs de l’application. Ils sont chargés de
recevoir les requêtes utilisateurs, d’effectuer le traitement souhaité et de renvoyer
les informations à l’utilisateur ;
○ Requests : contient les différentes règles de validations des saisies de l’utilisateur.
Ceci afin de garantir que les données saisies soient dans le format attendu ;
Contenu du dossier app de Laravel

● Repositories : contient les fichiers de gestion des ressources de l’application. Leur rôle est
de séparer la gestion des données de l’application des contrôleurs, comme les requêtes en
base de données par exemple. Ceci afin de pouvoir les utiliser dans plusieurs contrôleurs
différents et d’éviter duplication de code.
Contenu du dossier Repositories
● Account, Contact, … : modèles représentant les données en base de données.
10.10.2.3 Le dossier public

Le dossier public contient le fichier index.php qui est le point d’entrée de l’application. Les requêtes
aboutissent généralement sur ce fichier.
Contenu du dossier public
Puis le fichier routes.php est chargé et ce dernier se charge d’analyser la requête et de la rediriger.
Ce fichier contient généralement les différentes routes de l’application avec les différentes méthodes
(get, post, …). Les requêtes sont ainsi triées et redirigées vers les contrôleurs et ses méthodes.
Schéma du cycle d’une requête

10.10.3 Traitements des requêtes
10.10.3.1 Les requêtes GET - demandes de formulaires

Le scénario d’une requête de type GET est destiné à récupérer des données pour les afficher sur
l’interface utilisateur ou de récupérer un formulaire.
La récupération de données est utilisée pour effectuer un index sur une collection de données par
exemple. Plus concrètement, il peut s’agir de récupérer la liste des contacts clients en base de
données pour les afficher dans un tableau.
Dans le cas d’une requête de formulaire, il s’agit par exemple de récupérer le formulaire de création
d’une ressource, comme de définir un nouveau contact client.
Le scénario ci-dessous représente l’ajout d’un nouveau contact client lié à un compte client déjà
existant en base de données. Ceci tout en respectant le principe ‘modèle-vue-contrôleur’.
Scénario d’une requête GET

Description du scénario
1. L’utilisateur souhaite ajouter un nouveau contact client lié à un compte client existant. Le
bouton fait appel à la route nommée ‘account.createContact’.
2. Le gestionnaire de route redirige la requête vers la méthode du contrôleur correspondante. Il
s’agit de la méthode ‘create’ du contrôleur ‘ContactController :
‘ContactController@create’.
3. Le contrôleur fait appel au gestionnaire de données des comptes clients,
‘AccountRepository’, afin de récupérer le modèle du compte client ‘Account’ pour lequel
un nouveau contact sera ajouté.
4. Le gestionnaire de données récupère le modèle d’un compte client ‘Account’ avec ses
attributs.
5. Le gestionnaire de données récupère les données du compte client dont l’identifiant ‘id’
fourni et le copie dans le modèle ‘Account’.
6. Le contrôleur reçoit les données du compte client du gestionnaires de données.
7. Le contrôleur retourne la vue contenant le formulaire de création d’un nouveau contact
client. Le modèle du compte client ‘Account’ est transmis avec l’argument ‘compact’ à la
vue de création du contact client.
8. La vue contenant le formulaire de création d’un nouveau contact client, avec les données du
compte client correspondant, sont affiché à l’écran de l’utilisateur.
Cet exemple met parfaitement en scène la séparation de la gestion des tâches proposées par
Laravel. Là où d’autres framework effectuent tout le traitement de la récupération des données dans
le contrôleur, Laravel permet de séparer ces tâches entre le contrôleur et le gestionnaire de
données.
Dans ce cas précis, c’est le contrôleur des contacts clients qui récupère les données avec le
gestionnaire des données des comptes clients. Cela permet d’éviter d’avoir une duplication de code
entre le contrôleur des comptes clients et le contrôleur de contacts clients. Si tout le traitement était
effectué à l’intérieur des contrôleurs, le contrôleur de comptes clients et celui des contacts clients
contiendraient le même code pour récupérer les données d’un compte client en fonction de son
identifiant.
Le contrôleur a ainsi un rôle de coordinateur et fait appel aux différentes méthodes des
gestionnaires de données. Tout le code de gestion de la récupération des données propres aux
comptes clients est écrit dans le gestionnaire de données ‘Repository’ et le contrôleur n’a pas à
savoir comment cela est réalisé.
Cette organisation permet de séparer très clairement les rôles de chaque partie du code pour ainsi
respecter le principe ‘DRY’ (Don’t Repeat Yourself) qui signifie de ne jamais dupliquer le code. Cela
causerait des complications en cas de modifications dans la gestion des données d’une ressource.
Le code devrait ainsi être modifié à divers endroits et ceci est à proscrire.

10.10.3.2 Les requêtes POST - envoies de formulaires
Le scénario d’une requête de type POST est destiné à transmettre des données saisies par
l’utilisateur vers l’application.
L’exemple ci-dessous décrit le scénario d’enregistrement d’un nouveau contact client dont les
données ont été saisies par l’utilisateur.
Scénario d’une requête POST

Description du scénario
1. L’utilisateur a rempli les champs du formulaire avec les données du nouveau contact client
et a cliqué sur le bouton ‘Enregistrer’. Ce bouton fait appel à la route nommée
‘account.storeContact’.
2. Le gestionnaire de route redirige la requête vers la méthode du contrôleur correspondante. Il
s’agit de la méthode ‘store’ du contrôleur ‘ContactController :
‘ContactController@store’.
3. Les valeurs des données saisies dans le formulaire sont vérifiées à l’aide des règles de
validation décrites dans la méthode ‘rules’ de ‘ContactCreateRequest’.
4. Cet méthode renvoie un tableau contenant les données et leur format au contrôleur pour
s’assurer qu’elles correspondent à ce qui est attendu.
5. Le contrôleur fait appel au gestionnaire de données des contacts clients,
‘ContactRepository’, afin d’enregistrer les données du nouveau contact client saisi dans le
formulaire.
6. Le gestionnaire de données récupère le modèle d’un contact client ‘Contact’ avec ses
attributs.
7. Le gestionnaire de données crée une nouvelle ressources ‘Contact’ et l‘enregistre en base
de données.
8. Le contrôleur reçoit les données du contact client nouvellement créé du gestionnaires de
données.
9. Le contrôleur appel la route pour l’affichage du compte client lié au contact client
nouvellement créé. Le modèle du compte client ‘Account’ est transmis avec l’argument
‘compact’ à la vue d’affichage du compte client..
10. La vue contenant d’affichage du compte client est affiché à l’écran de l’utilisateur.
Cet exemple correspond à celui de la requête POST avec en plus, la validation des données saisies
par l’utilisateur dans le formulaire. Cette opération permet de garantir que les formats des données
sont corrects et cohérents, et évite que les données en base de données soient corrompues.
Il démontre également l’importance de la séparation des tâches dans les différentes parties du code.

10.10.4 Les outils intégrés de Laravel
Le framework Laravel propose toute une série d’outils et de fonctions qui permettent de grandement
simplifier le développement du code. Le but est de pouvoir rapidement créer des classes de tous
types, comme des contrôleurs ou des validations, sans avoir à définir les dépendances et les
héritages nécessaires.
10.10.4.1 Artisan, la boîte à outils de Laravel

Laravel dispose de la boîte à outils ‘Artisan’ dont l’objectif est de créer les éléments de bases des
différentes classes de l’application.
Pour afficher la liste des fonctions ou outils disponibles avec Artisan, il suffit d’ouvrir un terminal de
commande (le terminal Linux par exemple), de se positionner dans le dossier racine de l'application,
et d’entrer la commande :
php artisan
Le résultat affiché est le suivant :
Liste de quelques commandes disponibles avec Artisan
Une partie de ces fonctions permettent de construire les différentes parties du code avec leur
squelette de base.

Les principales fonctions utiles à la réalisation de ce projet sont les suivantes :
php artisan make:controller Pour la création d’une classe contrôleur

php artisan make:request Pour la création d’une classe de validation
php artisan make:migration Pour la création d’une classe de migration de base de données
php artisan make:model Pour la création d’un modèle de ressource
php artisan make:seeder Pour la création d’une classe de population de données en base de
données
10.10.4.2 Le constructeur de contrôleurs

La création de classes de types contrôleurs s’effectue très facilement en entrant la commande
suivante :
php artisan make:controller TestController
La classe générée ressemble à ceci :
Squelette d’une classe Controller généré par Artisan
Le squelette de la classe générée contient déjà le bon espace de nom, inclut la classe ‘Request’ qui
pourra être utilisée dans le code, et hérite de la classe ‘Controller’ déjà définie dans le framework.
Cela permet de s’affranchir de toutes ces définitions dites “de plomberie” et de se focaliser sur le
développement du code proprement dit. Les classes générées font ainsi usage des fonctionnalités
déjà fournies par le framework.

10.10.4.3 Le gestionnaire de migrations de la base de données
L’outil de migration de Artisan permet la création des tables de la base de données à l’aide de
classes en langage PHP. Il n’est ainsi plus du tout nécessaire de les générer en langage SQL. Il
suffit uniquement de créer la base de données avec le nom voulu et de définir l’utilisateur et ses
droits.
La commande Artisan suivante créera la classe de migration souhaitée :
php artisan make:migration create_contacts_table
Il est important de respecter certaines conditions de nommage. Le mot clé ‘create’ au début ainsi
que le mot clé ‘table’ à la fin indiquent qu’il s’agit de la création d’une table. La classe ainsi générée
sera créée à cet effet.
Il s’agit ensuite de définir les colonnes de la tables en langage PHP comme ceci :
Exemple de la création d’une table avec une classe de migration
Cette classe contient la méthode ‘up’ qui créera la table souhaitée avec les différentes colonnes et
types de données qu’elle doit contenir. La gestion des clés étrangères est également gérée par la
migration.
Les informations de connexion à la base de données doivent figurer dans le fichier caché ‘.env’ à la
racine de l’application. Ces informations seront nécessaires à Artisan pour accéder à la base de
données et pour créer et modifier son contenu :
Exemple de configuration d’accès à la base de données dans le fichier caché .env

Une fois toutes les classes représentant les tables générées et complétées, il suffit de démarrer la
migration avec la commande suivante :
php artisan migrate
L’outil de migration procédera ainsi à la création (ou à la modification si cela est le cas) des tables
dans la base de données.
Et lors de la première migration, une table avec le nom ‘migration’ est également créée dans la
base de données. Cette table permet de conserver un historique des migrations qui ont déjà été
effectuées dans la base de données. Il est ainsi possible d’ajouter des tables ou de les modifier en
cours de développement, sans interférer sur les données qui pourraient déjà être présentes sur le
serveur en production. La table de migration se présente comme ceci :
Contenu de la table migration créée par l’outil de migration de Laravel
L’outil de migration tient ainsi compte des migrations déjà effectuées sur la base de données en
question et exécute uniquement les migrations qui n’ont pas encore été faites. De cette manière, il
est possible d’ajouter des tables, de les modifier (modifications de colonnes par exemple), de
modifier les contraintes de clés étrangères, etc…
Lors du transfert de l’application sur le serveur en production, il suffit d’exécuter la commande :
php artisan migrate
et la base de données en production est immédiatement modifiée en fonction.
L’outil de migration permet également de revenir sur ses pas en cas d’erreur, dans la classe de
migration par exemple, à l’aide de la commande de ‘rollback’ par exemple.
Voici les différentes fonctions disponibles de migrations :
Liste des fonctions disponibles avec la commande php artisan migrate

10.10.4.4 Le gestionnaire de population de la base de données
Une fois les migrations effectuées, les tables sont créées en base de données mais elles sont vides,
elles ne contiennent aucune données. Afin de pouvoir facilement et rapidement ajouter des données
dans ces tables, Artisan permet de créer des classes de populations, appelées ‘Seeder’. Cela peut
s’avérer fort utile pour tester l’application au début du développement.
Pour créer une classe de population, il suffit d’entrer la commande suivante :
php artisan make:seeder ContactsTableSeeder
La classe est automatiquement créée dans le dossier ‘seeds’ du dossier parent ‘database’ :
Contenu du dossier seeds
Ce dossier contient les classes de population créées ainsi qu’une classe ‘DatabaseSeeder.php’ qui
sera chargée d’appeler les différentes classes seeder.
Classe DatabaseSeeder pour l’appel des classes de population
Les classes Seeder permettent ainsi de remplir les données souhaitées. Lorsque cela est requis, il
est important que le Seeder renseigne les différentes contraintes telles que les clés étrangères :
Exemple d’une classe de population de table de la base de données
Pour que ces données soient enregistrées en base de données, il suffit d’exécuter la population
avec la commande suivante :
php artisan db:seed

10.10.4.5 Le générateur de requêtes SQL Query Builder
Laravel dispose d’un outil de génération de requêtes SQL, le ‘Query Builder’ qui a une syntaxe
explicite en PHP. Le but est de s’affranchir de générer les string de requêtes SQL dans l’application.
Sur le principe, la syntaxe est un peu similaire à celle qui serait utilisée en langage SQL. La
différence est que les commandes SQL s’effectuent au travers de méthodes de la classe ‘Model’
héritée par l’objet modèle en question.
Le Query Builder va ainsi procéder à la génération de la requête SQL à la place du développeur.
10.10.4.5.1 Exemple de requête simple sur une ressource

L’exemple ci-dessous illustre une recherche en base de données des contacts dont le nom ou le
prénom contient le text fourni dans la variable ‘$search’.
L’objet retourné est une collection d’objets de la classe modèle ‘Contact’ :
Exemple d’une requête simple avec le Query Builder
La requête générée par le Query Builder est la suivante :
SELECT *
FROM contacts
WHERE name LIKE ‘%text_recherché%’
OR firstname LIKE ‘%text_recherché%’
ORDER BY name ASC;

10.10.4.5.2 Exemples complexes avec des jointures sur les tables
Le Query Builder permet d’effectuer des requêtes plus complexes, avec des jointures sur des tables
ou des fonctions agrégatives comme des sommes ou des moyennes par exemple.
L’exemple ci-dessous effectue une jointure sur la tables des compositions avec la table des
composants et celle des produits. Ensuite une sélection est effectuée, avec les colonnes choisies,
sur les lignes dont le produit correspond à l’identifiant passé en paramètre et dont le composant ne
doit pas correspondre à la valeur passée en paramètre.
Exemple d’une requête complexe avec des jointures avec le Query Builder
L’exemple ci-dessous effectue une requête en utilisant une fonction agrégative de somme sur
certaine valeurs.
Exemple d’une requête complexe avec des fonctions agrégatives avec le Query Builder
Le Query Builder permet ainsi d’effectuer toutes les requêtes qui seraient possibles en langage
SQL, et tout cela en langage PHP avec des méthodes définies dans le framework Laravel.

10.10.4.6 Le moteur de template Blade
Laravel possède un moteur de template élégant qui se nomme Blade qui permet de simplifier la
syntaxe des pages HTML.
L’interprétation de code PHP dans une vue HTML devient plus élégante avec l’usage d’un système
de doubles accolades à la place des balises ‘<?php … ?>’. Les instructions Blade dans les pages
HTML sont donc exécutées avant d’être envoyées à l’utilisateur pour l’affichage à l’écran.
La syntaxe suivante :
Exemple d’accès à une ressource avec les balises standards PHP
peut se simplifier de la manière suivante :
Exemple d’accès à une ressource avec les instructions Blade
Il est également possible d’interpréter du code logique dans une page HTML lorsque cela peut être
nécessaire :
Exemple d’interprétation d’instructions PHP avec les instructions Blade
Mais il est important de ne pas en abuser, car la logique du code doit être effectuée au niveau des
contrôleurs ou des repositories et non dans les pages HTML. Cette fonctionnalité a principalement
son utilité lorsque l’affichage sur l’interface graphique change en fonction des valeurs des variables
à afficher.

Une fonction fondamentale de Blade est également de permettre de faire du templating avec des
modèles de conception.
Les différentes pages HTML n’ont pas besoin de contenir toute la syntaxe complète de la page. Il
suffit de définir un modèle de base, appelé ‘layout’ dans lequel sont définies les balises communes
à toutes les pages comme le <head> ou le <title> par exemple. Ce layout peut également contenir
la bannière principale avec le menu de navigation.
Les pages HTML de l’application font appel au layout avec l’instruction ‘@extends(‘nom du
layout’)’ et lors de l’appel à cette page, Blade se charge de récupérer ce layout et d’y insérer son
contenu.
Ci-dessous une page HTML faisant appel au layout :
Exemple de la structure d’une vue HTML avec l’utilisation du template ‘app_layout’
Le layout doit contenir une balise ‘@yield(‘nom du contenu’)’ qui lui indique où doit être inséré le
contenu de la page HTML :
Balise d’inclusion du contenu de la vue dans le template ‘app_layout’
Cette fonction permet ainsi d’économiser un temps précieux pour générer les différentes vues de
l’application. Et cela respecte également le principe DRY (Don’t Repeat Yourself) pour éviter la
duplication de code.
Ainsi, en cas de modification dans le design des interfaces graphiques, la modification ne doit être
effectuée qu’à un seul endroit, dans le layout.

10.11 Le framework de mapping objet-relationnel Eloquent
Laravel propose nativement ‘Eloquent’, un framework de mapping objet-relationnel (ORM en
anglais pour Object-Relational Mapping).
Un ORM est un programme qui joue le rôle d’interface entre un programme applicatif et une base
de données relationnelle. Il permet de simuler une base de données orientée objet et simplifie
grandement l’association entre les tables de la base de données et les modèles objets de
l’application.
L’avantage majeur est que cela permet de réduire la quantité de code nécessaire à écrire pour lier
des objets de l’application et les tables de la base de données au travers des requêtes SQL.
10.11.1 Exemple de requête simple sur une ressource

L'exemple ci-dessous image le mécanisme pour récupérer un contact client dans la base de
données en fonction de son identifiant, et le transforme en objet selon le modèle ‘Contact’.
1. La classe modèle ‘Contact’ doit hériter de la classe ‘Model’ du framework Laravel.
Squelette d’une classe Model générée par Artisan
2. La classe ‘ContactRepository’, qui joue le rôle entre le contrôleur et la base de données,

doit inclure le modèle ‘Contact’.
Exemple d’inclusion des classes Model dans la classe de gestion de données
3. La classe ‘Model’ de Laravel définit une méthode ‘findOrFail’ dont le modèle ‘Contact’ a
accès par héritage. Cette méthode permet de convertir la ligne complète du contact dont
l’identifiant est fourni en un objet de la classe ‘Contact’.
Il est ainsi possible de s’affranchir de la préparation du string de requête SQL ainsi que de
copier une à une les valeurs des colonnes de la table dans les attributs de la classe modèle.
Exemple de l’appel à une méthode de la classe Model

10.11.2 Exemple d’une requête avec jointure sur deux tables
L'exemple ci-dessous image le mécanisme pour récupérer la liste des contacts clients avec jointure
sur les comptes clients dans la base de données. La liaison est de type ‘1 à n’, un compte peut avoir
plusieurs contacts et un contact appartient à un seul compte. La table des contacts contient ainsi
une clé étrangère qui référence l’identifiant du compte auquel il est rattaché.
L’objet retourné sera une collection d’objets ‘Contact’.
1. La classe modèle ‘Contact’ doit définir une méthode ‘account’ qui décrit la relation qu’un
contact a avec un compte client. Dans ce cas, un contact appartient à un seul compte client.
Méthode pour la liaison du modèle Account au modèle Contact
2. La requête s’effectue simplement à l’aide de méthode fournies par le framework Laravel et

retourne la collection des contacts avec les comptes clients en une seule ligne de code.
Exemple d’appel à une méthode de la classe Model avec relation à un autre modèle
3. Le modèle ‘Contact’ peut ainsi être utilisé dans les vues HTML. Dans l’exemple ci-dessous,
il s’agit d’une itération sur la collection d’objets ‘Contact’ pour les afficher un à un dans un
tableau.
Les cinq premières lignes récupèrent les attributs du modèle ‘Contact’. Les deux dernières
récupèrent les attributs du modèle ‘Account’ au travers de la méthode ‘account’ du modèle
‘Contact’.
Exemple d’utilisation d’un objet de type Model avec relation dans une vue
Il devient ainsi très simple et rapide d’interagir avec la base de données au travers de l’application
développée avec Laravel.

10.12 Le framework de design graphique Bootstrap
La mise en page graphique des pages HTML est généralement assurée par des feuilles de style en
cascade CSS. L’édition de ce type de fichiers peut être très fastidieux, chronophage et n’apporte
aucune plus-value fonctionnelle à l’application. Ces fichiers ne servent qu’à la mise en page
esthétique des pages HTML.
Laravel intègre nativement le framework Bootstrap qui est une collection complète d’outils utiles à
cet effet. Il suffit ainsi simplement de définir des attributs ‘class’ aux balises HTML avec les
arguments corrects pour que le design des interfaces graphiques soit élégant et uniforme.
Logo de Bootstrap
Bootstrap est disponible sous licence de logiciel libre MIT (pour Massachusetts Institute of
Technology). Il peut donc être utilisé, copié et modifié à souhait, sous réserve d’indiquer les auteurs
avec la notice copyright.
La communauté Bootstrap met à disposition des exemples de pages Web mises en page avec ce
framework sur leur site internet, qui sont gratuitement téléchargeables et utilisables. Le
développement de ce projet s’est inspiré de l’un de ces modèles afin d’économiser un temps
précieux dans la définition de sa mise en page.
10.13 Le framework de tests unitaires PHPUnit

Lors de l’apparition de PHP, il n’était pas possible de scripter des tests au milieu du code HTML car
les développeurs PHP inséraient leur code directement dans les pages HTML.
Le langage PHP s’est peu à peu développé en un langage évolué et permet aujourd’hui de
programmer en orienté objet. Un framework de tests unitaires nommé ‘PHPUnit’ dédié au langage
PHP a été développé et permet ainsi de tester les différentes fonctions d’une application.
Laravel est entièrement développé en programmation orientée objet et intègre nativement le

framework de tests unitaires PHPUnit. Les types de tests se distinguent selon s’ils sont du type
‘tests de fonctionnalités’ ou du type ‘tests unitaires’.
La création d’un test de fonctionnalité s’effectue avec la commande Artisan suivante :
php artisan make:test ExempleTest
La création d’un test unitaire s’effectue avec la commande Artisan suivante :
php artisan make:test ExempleTest --unit
Structure des dossiers de tests

La différence entre les deux types de tests réside dans le dossier dans lequel ils sont créés. Les
tests unitaires sont créés dans le dossier ‘Tests\Unit’ alors que les tests de fonctionnalités sont
créés dans le dossier ‘Tests\Feature’.
Ces deux types de tests ne doivent pas nécessairement être séparés mais Laravel recommande
fortement de le faire. C’est pour cette raison que Artisan procède de cette manière.
Les tests unitaires sont généralement destinés à tester des fonctions particulières de l’application,
comme le résultat retourné par une méthode par exemple.
Les tests de fonctionnalités sont plutôt destinés à tester un comportement d’ensemble de

fonctionnalités intégrées. Ces tests sont parfois également appelés tests d’intégration et permettent
de valider une partie de l’application sous la forme de scénarios.
Exemple de squelette d’une classe de test unitaire générée par Artisan :
Squelette d’une classe de test unitaire
Exemple de squelette d’une classe de test de fonctionnalité générée par Artisan :
Squelette d’une classe de test de fonctionnalité

10.14 L’environnement de développement
Le langage PHP utilisé pour développer l’application de ce projet est un langage dit ‘interprété’.
Cela signifie qu’il n’est pas compilé mais qu’il est interprété par le serveur avant de retourner des
pages HTML. Le développement d’une application PHP ne nécessite aucun environnement de
développement intégré (EDI en anglais) et peut être réalisé avec n’importe quel type d’éditeur de
texte.
L’éditeur de texte utilisé dans la réalisation de ce travail de Bachelor se nomme ‘Atom’, un éditeur
de texte libre multi-plateformes édité par ‘GitHub’. Atom présente l’avantage de supporter de
multiple ‘plug-ins’ (ou modules d’extensions en français), ce qui le rend très complet et multi-usages.
Logo de Atom
Atom reconnaît la syntaxe de plusieurs langages et définit la coloration syntaxique du code en

fonction de l’extension des fichiers.
Exemple de la coloration syntaxique avec Atom
Il implémente le plus-in ‘Git Control’ et indique les informations du dépôt local du gestionnaire de
versions Git. Il est ainsi possible de changer de branches ou d’en créer de nouvelles directement au
travers de son interface.
Gestion du dépôt local Git avec Atom

11 Réalisation
11.1 L’architecture globale

L’infrastructure globale est divisée en quatre groupes principaux, connectés les uns aux autres au
travers du réseau local de l’entreprise ou de Internet :
1. L’infrastructure informatique déjà existante dans l’entreprise est équipée de deux

ordinateurs, d’une imprimante et d’un stockage réseau NAS, tous connectés au réseau
local. Le point central étant le Modem/Routeur fourni par le fournisseur d’accès à internet.
2. Le serveur d’application Raspberry qui est connecté au réseau local de l’entreprise.
3. La station de développement qui accède au réseau local au travers de internet avec une
connexion sécurisée SSH.
4. Le dépôt distant Git hébergé chez Bitbucket, dont l’accès par la station de développement et
par le serveur d’application est effectué au travers d'internet avec une connexion sécurisée
SSH.
Schéma de l’architecture globale du projet

11.2 La préparation de l’infrastructure
Le développement de l’application Web Laravel nécessitait d’avoir une station de développement et
un serveur fonctionnels installés avec les différentes applications énumérées dans le chapitre des
outils et technologies utilisés.
Afin d’alléger la bonne lecture de ce mémoire, les marches à suivre ainsi que les scripts utilisés pour
la réalisation de cette étape sont fournis avec les annexes. Ces documents peuvent être utilisés afin
de pouvoir reproduire l’installation complète de ce qui a été réalisé.
La station de développement a été utilisée pour tester l’application avant sa mise en production sur
le serveur. Les mêmes applications ont de ce fait été installées autant sur le serveur que sur la
station de développement.
Les étapes de préparation de l’infrastructure étaient les suivantes :
1. Installation du système d’exploitation sur la machine. La distribution GNU/Linux ‘Ubuntu

Mate’ a été installée sur la station de développement. La distribution GNU/Linux
‘RASPBIAN’ a été installée sur le serveur Raspberry.
2. Installation du serveur HTTP Apache 2.
3. Installation de l’interpréteur PHP version 7.
4. Installation de la base de données MariaDB.
5. Création de la base de données avec le script de base.
6. Installation du framework Laravel.
7. Configuration de Apache pour rediriger les requêtes HTTP vers le point d’entrée de
l’application Laravel.
8. Configuration des droits d’accès de Apache et de l’utilisateur local sur les différents dossiers
de l’application Laravel.
9. Création du dépôt Git distant sur Bitbucket.
10. Configuration des accès des 2 stations au dépôt Git distant sur Bitbucket avec SSH pour un
transfert et une récupération aisée et sécurisée.
11. Création du script de montage du dossier NAS de backup sur le serveur Raspberry
12. Configuration du job automatique journalier ‘Cronjob’ pour effectuer la sauvegarde de la
base de données sur le NAS.
La pré-étude faisant mention d’utiliser la distribution Ubuntu Mate sur le serveur. Le Raspberry
n’étant utilisé que comme serveur web, il était inutile d’installer la distribution Ubuntu Mate, qui est
plutôt destinée à une utilisation sur des ordinateurs de bureau. C’est donc Raspbian qui été utilisée
dans le cadre de ce projet.

11.3 La base de données
11.3.1 Le modèle logique des données (MLD)

Le modèle ci-dessous décrit les différentes tables de la base de données qui ont été créées pour
gérer la persistance des données de l’application.
Modèle logique des données de l’application

11.3.2 Descriptif des tables et de leurs relations
Afin d’éviter des modifications en cours de développement, ce qui aurait pu fortement nuir au
respect des délais, la modélisation et la conception de la base de données de l’application avaient
été définies pendant la phase de pré-étude.
Cependant, pour des raisons de simplifications d’usage et d’efficacité, certains ajouts et

modifications ont tout de même été apportés à ce modèle.
11.3.2.1 La table des comptes clients - accounts

La table des comptes clients a fait l’objet d’une simple adaptation dans la taille de certaines de ses
données. Les colonnes ‘web_site’ et ‘email’ devaient avoir un format ‘varchar(255)’. Mais 80
caractères étant suffisants, leur format a été défini avec ‘varchar(80)’.
11.3.2.2 La table des contacts clients - contacts

Tout comme pour la table ‘accounts’, la table ‘contacts’ a fait l’objet de modifications dans le
format de certaines colonnes. Il s’agit des colonnes ‘function’, ‘city’, ‘phone’ et ‘email’ dont les
formats ‘varchar’ ont été raccourcis.
Une colonne ‘fax’ a été ajoutée au modèle de base, car dans la logique du modèle, un contact client
pourrait avoir son propre numéro de fax.
11.3.2.3 La table des produits - products

Le format ‘varchar’ de la colonne ‘unit’ a été augmenté pour pouvoir contenir 20 caractères au lieu
de 10 initialement prévu.
Suite à la mise en production de la fonctionnalité de gestion des produits, et selon entente avec le
mandant, les contraintes de certaines colonnes ont été modifiées pour être NULLABLE. Il s’agit des
colonnes ‘family’, ‘unit_price’ et ‘unit’ car dans ce contexte, il n’est pas nécessaire de devoir les
renseigner.
La colonne ‘name’ s’est vue attribuer la contrainte ‘UNIQUE’ afin d’éviter des duplications de
produits en base de données.
11.3.2.4 La table des composants - components

Tout comme pour la colonne ‘unit’ de la table ‘products’, le format ‘varchar’ de la colonne ‘unit’ de
la table ‘components’ a été augmenté pour pouvoir contenir 20 caractères au lieu de 10
initialement prévu.
La colonne ‘name’ s’est également vue attribuer la contrainte ‘UNIQUE’ afin d’éviter des
duplications de composants en base de données.
11.3.2.5 La table des compositions - compositions

Une colonne supplémentaire ‘work_type’ a été ajoutée à la table ‘compositions’. Cette colonne
permet de définir quel est le type de travail ou de tâche que les collaborateurs doivent effectuer dans
la préparation du produit. Par exemple le tranchage dans le cas des tranches de jambon.

11.3.2.6 La table des commandes - orders
Le format décimal de la colonne ‘total_price’ de la table ‘orders’ a été augmenté de ‘5,2’ à ‘7,2’.
Ceci est dû à une mauvaise interprétation de départ des formats décimaux. Le format ‘7,2’
correspond à des valeurs ayant 7 digits dont 2 d’entre-eux sont la précision. Et non 7 digits + 2 qui
donneraient 9 au total. Le format ‘5,2’ créait des erreurs car les montants totaux d’une commande
doivent pouvoir aller au-delà de CHF 1’000,00.
Une nouvelle colonne ‘remark’ a été ajoutée à la table ‘orders’ afin que l’utilisateur puisse indiquer
une remarque spécifique pour cette commande. Il pourrait s’agir d’un souhait du client d’emballer le
contenu de sa commande sous vide ou de trancher très fin son salami par exemple.
11.3.2.7 La table des lignes de commandes - order_lines

La table ‘order_lines’ est celle qui a subi les modifications les plus conséquentes, pour des raisons
pratiques, de simplicité de codage et l’accès aux données dans le code de l’application.
La table des lignes de commandes devaient initialement contenir deux clés étrangères faisant
références aux clés primaires des tables ‘orders’ et ‘products’. Le concept était qu’une ligne de
commande est rattachée à une seule commande et concerne un seul produit.
Mais la relation entre un produit et un composant est de type ‘N à N’, ce qui signifie qu’un produit
peut être constitué de plusieurs composants, et qu’un composant peut être utilisé dans la
composition de plusieurs produits. Ce type de relation nécessite d’avoir une table de liaison qui
contient la paire de clés étrangères référençant les deux clés primaires des deux tables concernées.
Une ligne de commande contient le prix du composant commandé. La commande d’un produit
composé de plusieurs composants crée ainsi plusieurs lignes de commandes dont chacune
concerne un composant. La clé étrangère référençant la clé primaire de la table des produits rendait
la récupération des composants plus complexe. Il aurait fallu itérer sur la liste de ses composants à
chaque écriture, ce qui aurait eu des conséquences sur la charge de travail du serveur et sur les
performances de l’application.
C’est pourquoi la table des lignes de commande contient une clé étrangère qui référence la clé
primaire de la table ‘compositions’. La table composition contenant la paire de clés étrangères sur
les tables de produits et de composants, il est de cette manière très facile et rapide de récupérer les
données concernées.
La dernière modification conséquente est l’ajout de la colonne ‘assortment_number’ qui

correspond au numéro de la position du produit dans la commande. Du point de vue de l’application,
tous les produits sont considérés comme des assortiments, d’où le nom de la colonne.
Cette nouvelle colonne a son utilité dans la modification détaillée des lignes de commandes. Elle
rend possible les modifications à tous les niveaux, à savoir la suppression d’une ligne seule ou de
tout l’assortiment d’un seul coup. Elle permet également l’ajout d’un composant pas encore
sélectionné ou de modifier les composants séparément dans les lignes de commandes.
La valeur dans ‘assortment_number’ est incrémentée de 1 à chaque ajout d’un nouvel assortiment
à la commande.

11.3.3 La création de la base de données
Conformément à ce qui a été décrit dans le chapitre décrivant les outils et technologies utilisées, la
création des tables de la base de données a été effectuée à l’aide de l’outils de migration intégré au
framework Laravel.
Cependant, Laravel ne se charge pas de la base de donnée proprement dite. C’est pourquoi un
court script SQL a tout de même été nécessaire pour la créer. Ce script se charge de créer la base
de données et de donner les privilèges à l’utilisateur souhaité :
Script de création de la base de données
Le reste a été généré par les classes de migrations que l’on peut retrouver dans le dossier
‘database\migrations’ qui se trouve à la racine de l’application Laravel.
Liste des classes de migrations
L’accès à la base de données par le framework Laravel se configure via le fichier caché de
configuration de l’environnement ‘.env’ situé à la racine l’application :
Données d’accès à la base de données dans le fichier ‘.env’

11.4 L’application Web avec le framework Laravel
Tel qu’il a été décrit dans le chapitre présentant les outils et technologies utilisés, Laravel propose
une structure très organisée des différentes parties du code source de l’application. Chaque fichier a
un rôle bien défini.
Les différents fichiers de l’application pour la gestion des différentes ressources, qui correspondent
aux tables de la base de données, sont tous organisés de la même manière.
La quantité de fichiers de code source étant élevée, ce chapitre ne fera mention que de leur nom, de
leur rôle et de leur emplacement. Ceci dans l’objectif de pouvoir aisément les retrouver et qu’un
autre développeur soit en mesure de reprendre et poursuivre le développement de cette application
(le code source est fourni avec les annexes).
11.4.1 Le gestionnaire de routes

La gestion des différentes routes de l’application se trouve dans le fichier ‘web.php’ qui se trouve
dans le dossier ‘routes’ à la racine de l’application.
ichier web.php
F Exemple de quelques routes

11.4.2 Les modèles
Les classes des modèles de l’application correspondent aux différentes tables de la base de
données. Il y a ainsi une classe par table, dont les propriétés correspondent aux colonnes de
chaque table. Ces classes se trouvent dans le dossier ‘app’ qui est à la racine de l’application.
Les propriétés indiquées dans le tableau avec la variable ‘$fillable’ sont celles qui peuvent être
mises à jour en masse. C’est-à-dire que ce sont les champs qui peuvent être modifiés lors de la
création d’une nouvelle ressource. Cela empêche de propager des informations erronées jusqu’à la
table dans la base données.
Les modèles définissent des méthodes qui gèrent leurs relations avec les autres modèles de
l’application. Dans l’exemple ci-dessous, une commande client concerne un seul contact client. Et
une commande client est concernée par plusieurs lignes de commandes :
Modèles de l’application

11.4.3 Les contrôleurs
Les contrôleurs ont le rôle de coordinateur entre l’interface graphique et l’application. Ils définissent
des méthodes qui sont appelées par le gestionnaire de routes et renvoient les vues avec les
données à l’écran.
Il y a un contrôleur pour chaque type de fonctionnalité. Il y a donc un contrôleur par table de la base
de données pour la gestion des ressources, mais il peut en exister d’autres également. Ils se
trouvent dans le dossier ‘app\Http\Controller’ qui est à la racine de l’application.
Par exemple, la gestion des statistiques et des commandes fournisseurs ne sont pas référencées
par des tables en base de données. Ces contrôleurs s’appuient sur les données des tables des
commandes clients pour retourner les informations dans les vues.
Liste des classes Controllers avec exemple d’une méthode

11.4.4 Les gestionnaires de données
Les gestionnaires de données (Repositories) contiennent la logique de traitement des données de
l’application. Ces classes contiennent la logique de traitement des différentes requêtes en base de
données.
Il y a une classe par ressource, par analogie une classe par table de la base de données. Elles se
trouvent dans le dossier ‘app\Repositories’ qui est à la racine de l’application.
Liste des classes Repositories avec exemple d’une méthode
11.4.5 Les règles de validations

Les règles de validations ont le rôle de vérifier les données envoyées par les formulaires. Chaque
ressource peut être créée ou modifiée. Il y a ainsi deux classes par type de fonctionnalité.
Elles se trouvent dans le dossier ‘app\Http\Request’ qui est à la racine de l’application.
Liste des classes Requests avec exemple

11.4.6 La règle de validation spécifique pour les durées
Laravel ne définissait pas de règle de validation correspondant au format ‘time’ de la colonne
‘working_duration’ de la table ‘products’. Il a ainsi fallu définir une nouvelle règle de validation.
Cette nouvelle règle de validation est définie dans la méthode ‘boot’ de la classe
‘AppServiceProvider’ du framework Laravel. Cette classe se trouve dans le dossier
‘app\Providers’ qui est à la racine de l’application.
Classe AppServiceProvider la règle de validation du format time

11.4.7 Le script JavaScript pour filtrer la saisie
Lors de la création d’une nouvelle composition ou de l’ajout d’un nouvel assortiment à une
commande client, les interfaces graphiques proposent un champs de saisie (input) qui filtre les
données proposées en fonction de la valeur en cours de saisie.
Cette fonction de filtrage est exécutée dans la page Web elle-même, du côté du client, et a
nécessité de développer un script en JavaScript. Il se trouve dans le ‘public\js’ à la racine de
l’application.
Script pour le filtrage des données dans les champs de saisies

11.4.8 Les vues
Les vues contiennent le code HTML des pages Web de l’application, les instruction Blade et l’appel
des différentes routes. Elles ont le rôle d’interface direct entre l’application et les interactions de
l’utilisateur, et sont responsable de la mise en page de ce qui est affiché à l’écran.
Les vues se trouvent dans le dossier ‘resources\views’ à la racine de l’application. Ce dossier

contient un sous-dossier par type de ressource dont chacun contient les mêmes types de vues :
● index : pour afficher la liste des ressources ;

● create : pour afficher le formulaire de création d’une ressource ;
● edit : pour afficher le formulaire d’édition (ou de modification) d’une ressource existante :
● show : pour afficher les informations propres à une ressource donnée.
Liste des vues avec exemple

11.4.8.1 L’affichage des dates en langue française dans les vues
Pour une meilleure lisibilité des dates de commandes clients par les utilisateurs de l’application, les
dates doivent être affichées en texte plein, avec le mois et le jour de la semaine en langue française.
Affichage des dates en langue française
Ce type d’affichage requiert de faire appel à la méthode ‘formatLocalized()’ de la classe ‘Carbon’

du framework Laravel, qui permet la manipulation des dates. Cette méthode nécessite de lui passer
le format d’affichage en paramètres.
Exemple d’utilisation de la méthode formatLocalized de la classe Carbon
Afin de respecter le principe DRY, la définition de ce format d’affichage a été ajouté à la classe de
configuration globale des vues ‘view.php’ qui se trouve dans le dossier ‘config’ à la racine de
l’application.
Classe de configuration globale des vues avec définition du format de date

11.4.8.2 L’export pdf des commandes clients
Le processus pour l’export des commandes clients dans un fichier pdf ne diffère du reste de
l’application que par les méthodes utilisées et le type de vue qui est retourné.
Lorsque l’utilisateur clique sur le bouton “Imprimer”, le contrôleur fait appel au gestionnaire de
données pour récupérer les données nécessaires. Le contrôleur récupère la vue avec la mise en
page pour l’impression et génère un fichier qui est affiché dans un nouvel onglet du navigateur.
Méthode du contrôleur pour l’impression des commandes dans un fichier pdf
Cette fonctionnalité nécessite d’installer un package (paquet de logiciels) nommé

‘barryvdh/laravel-dompdf’ qui permet d’exporter le contenu d’un fichier HTML dans un fichier pdf.
Ces vues se trouvent dans le même dossier que les autres vues des commandes clients. La
différence avec les autres vues est que ce package n’assure pas la compatibilité avec le framework
CSS Bootstrap. Ces vues font ainsi appel à un autre layout dans lequel la définition des styles de
mise en page ont dû être défini.
Vues d’export pdf Layout des vues pdf Style de mise en page

11.5 Les interfaces utilisateur
11.5.1 Menu de navigation

Le menu de navigation de l’application est divisé en 3 sections qui correspondent aux 3 domaines
de gestion principaux. Ces 3 domaines sont divisés en sous-sections qui donnent accès aux
différentes fonctionnalités.
1. La gestion des clients de l’entreprise :

a. La gestion des comptes clients. Ces comptes clients correspondent aux entreprises
clientes.
b. La gestion des contacts clients. Ce sont les collaborateurs qui travaillent dans les
entreprises définies en tant que comptes clients.
2. La gestion des articles :

a. La gestion des produits. Ce sont les produits finis qui sont vendus à la clientèle de la
boucherie ou qui se trouvent en vitrine du magasin.
b. La gestion des composants. Ce sont les composants de base qui entrent dans la
composition des produits finis.
3. La gestion des commandes :

a. La gestion des commandes clients. Ce sont les commandes destinées à la clientèle
ou les commandes internes destinées à être disposées en vitrine du magasin.
b. La gestion des commandes fournisseurs. Ce sont les commandes destinées aux
fournisseurs de viande. Cette fonction se base sur les commandes clients
enregistrées pour préparer les commandes fournisseurs sur une période donnée.
4. Les statistiques :
a. La génération des statistiques. Ce sont les additions de tous les composants
commandés sur une période donnée.

De manière générale, chacune des ces sous-sections permet d’effectuer les 4 opérations de base
CRUD (Create-Read-Update-Delete) sur chaque type de ressource, à savoir les clients, les articles
et les commandes.
Il est ainsi possible de créer une ressource, de l’afficher ou d’en lister plusieurs, de la modifier ou de
la supprimer. Ces différentes ressources peuvent avoir des dépendances. Il faut par exemple créer
un compte client avant de pouvoir créer un contact client.
11.5.2 La gestion des clients
11.5.2.1 Index des comptes clients

Lors de la sélection des comptes clients, la liste des comptes enregistrés est affichée par ordre
alphabétique dans un tableau. Les identifiants ainsi que les noms de comptes affichés contiennent
un lien pour afficher les détails.
Un clic sur le bouton ‘Nouveau compte’ permet de créer un nouveau compte client et un clic sur le
bouton ‘Effacer’ dans le tableau effacera le compte en question.
Index des comptes clients

11.5.2.3 Création d’un compte client
Le formulaire de création d’un compte client est conçu dans le but que la saisie se fasse le plus
rapidement possible. Cela permet d’optimiser le temps passé avec un nouveau client au téléphone.
Il s’agit ainsi de renseigner si le compte est une entreprise ou non. Si non, il s’agit d’un compte client
privé. Une entreprise peut être identifiée par deux noms, qui représentent la raison sociale et des
informations complémentaires. Dans le cas d’un compte client privé, ces 2 champs représentent le
nom et le prénom du client. Un compte client privé est considéré comme une entreprise du point de
vue de l’application.
Saisie d’un compte client “entreprise”
Saisie d’un compte client “privé”

11.5.2.5 Création d’un contact client
Lors de l’enregistrement d’un nouveau compte client, l’application redirige l’utilisateur vers le
formulaire de saisie d’un nouveau contact.
Dans le cas où la case ‘Est une entreprise’ était sélectionnée, ce formulaire est vide et contient le
minimum de champs nécessaires à renseigner. Ceci toujours dans l’objectif de minimiser le temps
de saisie.
Saisie d’un contact client d’un compte de type “Entreprise”
Dans le cas d’un client privé, lors la case “Est une entreprise” n’était pas sélectionnée, ce formulaire
est déjà pré rempli avec le nom et le prénom du client repris des 2 noms du compte créé.
Saisie d’un contact client d’un compte de type “privé”
Le but de ce flux de navigation est de correspondre exactement au processus suivi jusqu’alors avec
la saisie manuscrite des informations du client.

11.5.2.6 Détails d’un compte client
En cliquant sur un nom ou un identifiant de compte, le lien renvoie vers l’affichage des informations
détaillées de ce dernier. Cette interface permet ensuite de modifier les informations du compte avec
un clic sur le bouton ‘Modifier’.
La liste des contacts faisant partie de ce compte client sont listés en dessous. Un clic sur le bouton
‘Ajouter contact’ permet de créer un nouveau contact client qui travail pour ce compte client.
Les noms des contacts affichés contiennent un lien pour afficher les détails de ce contact et le
bouton ‘Effacer’ permet de supprimer ce contact. Il est ainsi non seulement retiré du compte client,
mais est également supprimé de la base de données.
Affichage d’un compte client

11.5.2.8 Modification d’un compte client
Le formulaire de modification d’un compte client permet de compléter ou de modifier toutes les
informations qui n’ont pas été saisies lors de la création. Toutes ces données sont complémentaires,
mais non obligatoires au bon fonctionnement de l’application.
Il est également possible de modifier l’information si le client est de type entreprise ou pas, ainsi que
de définir s’il est actif ou non. Cette dernière information est très importante car dans le cas où un
compte venait à ne plus exister, en cas de fermeture ou de faillite de l’entreprise par exemple, le
compte ne devrait en principe jamais être effacé. Car si ce client aurait passé des commandes par le
passé, lors de son effacement, toutes les commandes qui lui seraient affiliées seraient effacées
également. Cela aurait pour conséquence de modifier l’historique des commandes et ainsi de
fausser les statistiques.
Modification d’un compte client

11.5.2.9 Détails d’un contact client
Cette interface permet d’afficher toutes les informations relatives à un contact client ainsi que les
deux noms du compte auquel il est rattaché. Le ‘Nom de compte - 1’ contient un lien qui permet à
l’utilisateur de naviguer vers la page d’information de ce compte client.
Deux boutons permettent de modifier ce contact ou de lui saisir un nouvelle commande. Une
commande sera ainsi rattachée aux contacts clients, et non directement aux comptes, afin d’avoir
une traçabilité détaillées des commandes.
Tout comme pour les comptes clients, un contact client ne devrait en principe jamais être supprimé.
Cela afin de ne pas supprimer les commandes qui lui sont affiliées et de garantir l’historique pour les
statistiques.
Affichage d’un contact client
Plusieurs champs propres aux contacts clients peuvent être renseignés en option et ne sont pas
obligatoires pour le bon déroulement de l’application. Cela permet une certaine souplesse dans le
cas où une entreprise aurait plusieurs adresses ou que des collaborateurs auraient une adresse
différente de celle de l’entreprise. L’adresse ainsi que le numéro de téléphone ou le portable
seraient différents de ceux du compte auquel il est rattaché.
Il est également possible de renseigner un titre particulier que ce contact pourrait avoir, tel que
“Docteur”, “Professeur” ou “Maître” dans le cas d’une personne exerçant une activité juridique.

11.5.2.10 Modification d’un contact client
Le formulaire de modification d’un contact client permet de compléter ou de modifier toutes les
informations qui n’ont pas été saisis lors de sa création. Toutes ces données sont complémentaires
et ne sont pas obligatoires au bon fonctionnement de l’application.
Dans le cas où ce contact ne ferait plus partie de ce compte, si cette personne quittait l’entreprise
par exemple, il serait possible de le désactiver afin de ne pas le supprimer.
Modification d’un contact client

11.5.2.11 Index des contacts clients
Lors de la sélection des contacts clients dans le menu principal, la liste des contacts enregistré est
affichée par ordre alphabétique dans un tableau. Les identifiants ainsi que les noms de comptes
affichés contiennent un lien pour afficher les détails.
Index des contacts clients
11.5.2.12 Convention pour la suppression

Afin de garantir fiabilité de la cohérence des données de l’application et de ne pas altérer l’historique
des commandes clients, un contact client ne peut pas être supprimé si une commande client est
enregistrée pour ce dernier.
Par analogie, un compte client ne peut pas être supprimé si une commande client est enregistrée
pour l’un de ses contacts.
La convention veut qu’un client ne doit jamais être supprimé, sauf cas de force majeure, mais qu’il
doit être désactivé.

11.5.3 La gestion des articles
Cette fonctionnalité a pour but de permettre au mandant de créer la structure de ses produits
fabriqués pour la vente. Il peut ainsi définir les compositions de composants dont chaque produit est
constitué.
Ces produits seront utilisés pour la gestion des commandes. Le mandant doit ainsi prendre le temps
de saisir tous ses composants afin de pouvoir ensuite les ajouter dans les compositions de produits.
Cette tâche sera très sollicitée avant l’utilisation de l’application en production et devrait être moins
utilisée par la suite. L’usage de cette fonctionnalité se fera dans le but de modifier certains articles,
comme un changement de prix des matières premières par exemple, ou si le mandant venait à créer
une nouveauté dans ses articles.
11.5.3.1 Index des composants

Lors de la sélection des composants dans le menu de navigation, la liste des composants
enregistrés est affichée par ordre alphabétique dans un tableau. Les identifiants ainsi que les noms
des composants affichés contiennent un lien pour afficher les détails.
Un client sur le bouton ‘Nouveau composant’ permet de créer un nouveau composant et un clic sur
le bouton ‘Effacer’ dans le tableau effacera le composant en question.
Index des composants

11.5.3.2 Création d’un nouveau composant
Le formulaire de création d’un nouveau composant permet de saisir le nom de ce composant, son
prix unitaire, l’unité de mesure (généralement le kilogramme), la quantité de viande à prévoir par
personne ainsi que le temps de préparation par unité.
La quantité de viande à prévoir par personne ainsi que le temps de préparation sont optionnels. Leur
objectif est de prévoir une éventuelle future nouvelle fonctionnalité qui pourrait calculer la charge de
travail journalière en fonction des commandes saisies.
Création d’un nouveau composant
11.5.3.3 Détails d’un composant

Cette interface permet d’afficher les informations relatives à un composant. Cette interface est
munie d’un bouton ‘Modifier’ qui permet de modifier ce composant.
Détails du composant
11.5.3.4 Modification d’un composant

Lors de sa création, toutes les informations concernant un composant peuvent être saisies. Le
formulaire de modification d’un composant est ainsi identique à celui pour sa création.

11.5.3.5 Index des produits
Lors de la sélection des articles dans le menu de navigation, la liste des articles enregistrés est
affichée par ordre alphabétique dans un tableau. Les identifiants ainsi que les noms des produits
affichés contiennent un lien pour afficher les détails.
Un bouton ‘Nouveau produit’ permet de créer un nouveau produit et un clic sur le bouton ‘Effacer’
dans le tableau effacera le produit en question.
Index des produits
11.5.3.6 Création d’un nouveau produit

La création d’un nouveau produit requiert de renseigner si ce produit est composé ou non, de lui
donner un nom et d’indiquer la famille de produit dont il fait partie. Ceci afin de pouvoir plus
facilement les catégoriser. Le prix et l’unité de mesure doivent également être indiqués.
Des indications optionnelles peuvent encore être renseignées, la quantité suggérée par personne
pour simplifier la saisie des commandes ou le temps de préparation nécessaire à sa préparation. Ce
dernier pourrait être utilisé afin de calculer la charge de travail journalière par exemple.
Création d’un nouveau produit

11.5.3.7 Détails d’un produit
Cette interface affiche les information d’un produit ainsi que la liste des compositions de composants
qui le compose. Les compositions contiennent également les informations des préparations qui
pourraient être nécessaires pour chaque composant.
Par exemple, dans le cas d’un assortiment où un composant devrait être tranché, comme dans une
fondue chinoise par exemple, un coût de CHF 2.00 par kg est ajouté au prix de ce composant.
Le bouton ‘Modifier’ dans la zone de détails de produit permet de modifier le produit lui-même. Le
bouton ‘Ajouter composition’ dans la liste de compositions du produit permet d’ajouter une
nouvelle composition à ce produit.
Pour les produits dont le composant est revendu tel quel sans préparation, comme un filet de poulet
par exemple, la liste ne contient qu’une seule composition avec un coût de préparation à CHF 0.00.
Dans la table des compositions, un bouton ‘Supprimer’ et un bouton ‘Modifier’ permettent de

supprimer ou de modifier la composition correspondante.
Détails d’un produit
11.5.3.8 Modification d’un produit

Lors de sa création, toutes les informations concernant un produit peuvent être saisies. Le
formulaire de modification d’un produit est ainsi identique à celui pour sa création.

11.5.3.9 Création d’une nouvelle composition pour un produit
Le formulaire de création d’une nouvelle composition d’un produit ne requiert que la saisie du nom
du composant souhaité. Le champs de saisie filtre et propose les composants dès que 2 caractères
sont saisis. Ceci afin de simplifier et d’épurer le plus possible l’affichage des choix possibles. Il est
donc nécessaire que les composants aient été créés auparavant.
Création d’une nouvelle composition - filtre sur la liste des composants
Une fois le composant choisi, son prix est affiché juste à côté du champs de saisie afin de pouvoir
vérifier s’il a été correctement renseigné lors de sa création.
Il reste ensuite à renseigner les informations relatives à la préparation de composant dans cette
composition de produit.
Si aucune préparation n’est nécessaire, le prix et le type de la préparation peuvent rester vides.
L’application enregistrera le prix de la préparation à CHF 0.00 et le type de la préparation avec
‘Rien’.
Création d’une nouvelle composition - informations sur la préparation
11.5.3.10 Convention pour la suppression

La convention de suppression d’un produit ou d’un composant est la même que pour la suppression
d’un client. Un produit ou un composant ne peut être supprimé s’il a déjà été saisi dans une
commande.
Ceci également afin de garantir la cohérence de données de l’application et de ne pas altérer

l’historique des commandes clients.

11.5.4 La gestion des commandes clients
Cette fonctionnalité permet au mandant d’atteindre l’objectif principal de ce projet, d’éliminer les
différents supports en papier. L’usage de l’agenda et des post-it peuvent ainsi être remplacé par la
solution développée.
La saisie de commande nécessite que la base de données de l’application ait été alimentée avec
des clients et des produits. Ceci afin de pouvoir attribuer une commande à un client et d’ajouter des
produits à la commande.
Elle est la base sur laquelle s’appuient les fonctionnalités qui répondront aux objectifs secondaires,
d’automatiser la préparation des commandes fournisseurs et l’historisation des produits commandés
à des fins de statistiques.
11.5.4.1 Index des commandes clients

Lors de la sélection des commandes clients dans le menu de navigation, la liste des commandes
clients est affichée dans l’ordre chronologique des dates de livraisons. Seules les commandes à
livrer à partir du jour en cours et les dates futures sont affichées.
Le formulaire en tête du tableau permet de sélectionner la période pour laquelle les commandes
doivent être affichées. Ceci afin de pouvoir afficher les commandes antérieures qui ont déjà été
livrées.
Cette interface affiche les informations générales relatives aux commandes clients comme les
numéros de commandes, le nom du compte et du contact, la date de la commande et de la livraison,
les remarques particulières et le prix total de la commande.
Un bouton ‘Effacer’ dans le tableau permet d’effacer la commande client concernée.
Index des commandes clients

11.5.4.2 Filtre sur l’index des commandes clients
La sélection d’une période définie par l’utilisateur dans le formulaire en tête du tableau permet de
n’afficher que les commandes clients dont la date de livraison est dans cet intervalle. L’objectif est
d’avoir une vue d’ensemble du travail planifié durant cette période.
Une fois les deux dates renseignées et validées par un clic sur le bouton ‘Afficher’, un bouton
‘Imprimer’ apparaît et permet d’imprimer ces commandes dans un fichier pdf. Ces commandes
peuvent ainsi être imprimées sur des feuilles de papier et sont utilisées comme tâches à faire pour
les collaborateurs de la boucherie-charcuterie en laboratoire.
Index des commandes clients avec filtre sur les dates de livraisons
Ces commandes imprimées sont ensuite transmises au client lorsqu’il vient récupérer sa commande
en magasin. Elles permettent au client d’avoir un récapitulatif de leur commande et d’être informés
des prix des produits qui leur sont vendus.
Les prix exactes sont ajoutés manuellement lorsque chaque composant est pesé à la préparation.
Les quantités affichées correspondent à ce qui a été commandé et ne sont jamais 100% exactes
lors du pesage.
Export pdf d’une commande client

11.5.4.3 Création d’une nouvelle commande client
Une commande client étant liée à un contact client, lui-même lié à un compte client, le compte et le
contact doivent avoir été créés au préalable. Une fois créés, l’utilisateur doit commencer par
naviguer vers l’affichage du contact client et cliquer sur le bouton ‘Nouvelle commande’.
Détails d’un contact client pour la saisie d’une nouvelle commande client
La création d’une commande demande de renseigner la date de livraison de cette dernière ainsi
qu’une remarque particulière si nécessaire. Il pourrait s’agir d’un souhait particulier quant à
l’emballage ou à une modalité de livraison par exemple.
Saisie d’une nouvelle commande client

11.5.4.4 Détails de la commande
Une fois créée, l’application renvoie vers l’affichage des détails de la commande. Un numéro de
commande est automatiquement généré et la date de la commande correspond au jour lors de sa
saisie. La remarque particulière est affichée en dessous des détails de la commande.
Le numéro de commande est constitué du texte ‘PO’ pour Purchase Order (commande d’achat), de
la date de la saisie de la commande en format ‘Année-Mois-Jour’ (YYYYMMDD) et d’un numéro
qui s’incrémente automatiquement. Il est ainsi possible de saisir jusqu’à 9’999 commandes par jour.
Le prix total de la commande est également affiché. Il est à CHF 0.00 lors de sa création et est mis à
jour à chaque ajout, suppression ou modification de son contenu.
Cette interface contient trois boutons, ‘Modifier’ pour modifier la date de livraison ou la remarque,
‘Supprimer’ pour la supprimer de la base de données et ‘Imprimer’ pour imprimer uniquement
cette commande.
Sous les détails de la commande sont affichés les lignes de commandes. Chaque ligne de
commande correspond à un produit et à ses composants. Lors de la création de la commande, le
tableau ne contient aucune ligne de commande.
Un bouton ‘Ajouter assortiment’ permet d’ajouter des articles à la commande. Il est fait mention
d’assortiment car du point de vue de l’application, tous les produits sont considérés comme
assortiments.
Détails de la commande

11.5.4.5 Ajouter un assortiment à la commande client
La sélection d’un produit à ajouter à la commande s’effectue simplement en saisissant le nom du
produit souhaité. Dès que 2 caractères sont saisis, l’application effectue un filtre sur les produits
contenant ces caractères et il est ainsi facile de le saisir.
Choix du produit à ajouter à la commande
11.5.4.6 Choix des composants dans la composition du produit

La deuxième étape consiste à sélectionner les composants souhaités. Un assortiment peut être
composé de plusieurs composants et le client peut ainsi avoir le choix de commander les
composants qu’il souhaite. Il peut également définir les quantités de chacun de ces composants en
fonction de ses préférences.
Les assortiments deviennent ainsi personnalisables, ce qui correspond à l’ancienne méthode de

commande sur format papier.
Dans le cas d’un produit composé d’un seul composant, un seul composant est à sélectionner.
Sélection des composants d’un assortiment
Sélection du composant dans un produit non composé

11.5.4.7 Détails des lignes de commandes
Une fois les articles ajoutés à la commande, le tableau indique le contenu des articles et ses
compositions. Il est dès lors possible d’effectuer diverses actions sur ces lignes de commandes.
Un clic sur l’édition du produit, avec le bouton ‘+’, permet d’ajouter des composants pour ce produit.
Lors de la saisie, seuls les composants n’ayant pas déjà été sélectionnés peuvent être ajoutés.
Un clic sur le l’édition de composant, avec le bouton ‘O’, permet de modifier la quantité commandée
pour ce composant.
Un clic sur l’effacement, avec les boutons ‘X’, permettent soit de supprimer le composant en
question, soit de supprimer l’article au complet avec tous ces composants de la commande.
Index des lignes de commandes
A chaque ajout ou modification des lignes de commandes, l’application recalcule le montant total de
la commande et l’indique dans le tableau des détails de la commande.
Détails de la commande avec le montant total

11.5.5 La gestion des commandes fournisseurs
Cette fonctionnalité permet d’atteindre un des deux objectifs secondaires de ce projet, automatiser
la préparation des commandes fournisseurs.
Auparavant, cette tâche s’effectuait sur la base des commandes clients saisies dans l’agenda en
papier et ses post-it. Les collaborateurs de la boucherie-charcuterie devaient additionner les
différents composants commandés pour les jours suivants sur une feuille de papier. Sitôt l'addition
faite, ils pouvaient appeler leur fournisseur et lui passer la commande.
Ces commandes sont généralement effectuées deux fois par semaine, le mardi et le vendredi, pour
les 3 jours suivants.
11.5.5.1 Affichage de la commande fournisseur

L’application fonctionne sur le même principe, elle se base sur les commandes clients enregistrées
dans la base de données. Le calcul de la génération des besoins s’effectue sur la base des dates de
livraisons, qui entrent dans le même intervalle de temps que la préparation en laboratoire.
L’utilisateur a 3 possibilités pour préparer sa commande, soit sur une période définie avec une date
de début et de fin, soit une fonction rapide sur 3 jours ou soit sur un nombre de jours au choix. Ces
options permettent une souplesse en cas de périodes particulières, comme lors de jours fériés dans
la semaine en cours.
Liste vierge des composants à commander
Une fois l’une des trois options sélectionnée, la “liste de courses” est directement affichée à l’écran,
ce qui simplifie grandement sa préparation.
Liste des composants à commander chez le fournisseur

11.5.6 La fonction de statistiques
Cette fonctionnalité permet d’afficher des statistiques des composants commandés sur une période
définie par l’utilisateur.
Son objectif est de pouvoir avoir un aperçu des consommations par composants, pour que le
propriétaire de l’entreprise puisse calculer les amortissements de ses installations.
Lorsque l’utilisateur de l’application affiche la page des statistiques, un formulaire est affiché. Il y a 3
possibilités pour afficher les statistiques des commandes de composants, avec une date de début et
de fin, avec une fonction rapide de l’année en cours, ou d’entrer une année choisie.
Sélection de l’intervalle de temps pour afficher les statistiques des commandes de composants
Lorsque l’intervalle de temps est sélectionnée, l’application affiche un tableau avec les quantités
additionnées de chaque composants :
Statistiques des commandes de composants dans un intervalle de temps donné
Ces valeurs sont la base sur laquelle M. Eric Peguiron s’appuiera pour ses différentes analyses
d’utilisations de ses installations.
Cette fonctionnalité est une plus-value de l’application par rapport au système manuscrit
actuellement en utilisation. La tâche d’additionner toutes ces valeurs sur un format manuscrit sur
une année complète prendrait un temps colossal, et c’est pour cette raison qu’elle n’est pas
effectuée.

11.5.7 La fonction d’aide à la recherche
Afin de simplifier la recherche de ressources dans l’application, un champs de saisie pour la
recherche figure dans le menu principal. Cette fonction permet de retrouver facilement des
ressources en saisissant uniquement quelques caractères contenus dans ce qui est recherché.
Champs de recherche dans le menu principal
Par exemple, en saisissant le texte ‘au’, l’application affichera un tableau pour chaque type de
ressources pour lesquelles le texte saisi est contenu.
Les ressources affichées contiennent des liens qui permettront d’afficher leurs détails à l’aide d’un
simple clic.
Liste des ressources contenant le texte recherché
Cette fonctionnalité est particulièrement utile lorsqu’un client téléphone pour passer une commande.
L’utilisateur peut ainsi très rapidement accéder aux détails d’un contact afin de pouvoir créer une
commande client, et ainsi gagner un temps précieux dans la navigation.

11.6 La sauvegarde des données - Backup
Le serveur d’application fait une sauvegarde de la base de données de l’application une fois par
jour. Ce fichier de ‘backup’ est sauvegardé dans le disque dur réseau NAS de l’entreprise.
L’exécution de ce mécanisme nécessite d’écrire un script de sauvegarde et de procéder à quelques

configurations du serveur pour que cette tâche soit démarrée automatiquement, sans manipulation
d’un utilisateur.
1. Créer les dossiers locaux sur le serveur qui auront la fonction de point de montage distant
sur le NAS. Ces dossiers se trouvent dans ‘ /mnt/NAS/peguiplan/backup/ ‘ :
Dossier locaux pour les points de montage sur le NAS
2. Ajouter une instruction pour ajouter un point de montage du dossier de sauvegarde du NAS
depuis le serveur d’application. Cette instruction est ajoutée dans le fichier ‘ /etc/fstab ‘ et
elle est exécutée directement lors du démarrage du serveur :
Point de montage vers le NAS dans le fichier /etc/fstab
3. Cependant, lors du démarrage, cette instruction ne fonctionne pas car lors de son
exécution, le serveur n’est pas encore connecté au réseau sans fil (WiFi) de l’entreprise. Un
‘cronjob’ doit être ajouté dans le fichier ‘ /etc/crontab ’ qui ré-exécutera le fichier ‘
/etc/fstab ‘. Le délai est configuré à une minute (60 secondes) après le redémarrage du
serveur :
Cronjob dans la crontab pour exécuter le montage 60 secondes après le démarrage du serveur
4. Créer le script de sauvegarde de la base de données et l'enregistrer dans le dossier ‘

/usr/local/sbin/ ‘. Ce fichier de script shell est nommé ‘ mysql_backup.sh ‘.
Un deuxième script est créé pour la sauvegarde de l’entier de la carte mémoire microSD du
serveur Raspberry. Cette sauvegarde permettra d’effectuer une réplication complète du
serveur si cela était nécessaire.
Scripts de backups dans le dossier /usr/local/sbin/

5. Créer deux ‘cronjob’ dans la ‘crontab’ pour que ces deux scripts soient exécutés
automatiquement par le serveur :
Cronjob dans la crontab pour exécuter les scripts de backups
6. L’exécution de ces scripts enregistrera les fichiers de sauvegardes directement dans le

dossier du disque réseau NAS. Les copies d’écrans ci-dessous indique leur bon
fonctionnement :
Exemples de backups de la base de données depuis l’explorateur de fichiers du NAS
Exemple de backup de l’entier de la carte microSD depuis l’explorateur de fichiers du NAS

12 Bilan
Ce chapitre présente le retour d’expérience global de la phase d’implémentation et réalisation de ce
travail de Bachelor. Il a pour but de comparer le déroulement et les résultats obtenus avec ce qui
avait été planifié durant la phase de conception (pré-étude).
12.1 La gestion de projet

La méthode Agile utilisée se prêtait parfaitement à la typologie de ce projet. Étant découpé en
fonctionnalités métier, n’ayant pas toujours une dépendance les unes avec les autres, il était aisé de
les développer et de les mettre en production l’une après l’autre.
Ces fonctionnalités décrites sous la forme de scénario, ou Stories, ont permis d’avoir une granularité
plus fine de l’ensemble du projet. Le temps et l’effort nécessaire à la réalisation de chacune de ces
fonctionnalités était plus simple à estimer. Et les critères d’acceptation définis au préalable simplifiait
grandement la validation de ces fonctionnalités par le client lors de la livraison.
L’utilisation de l’outil iceScrum n’était par contre pas nécessaire. Outre le fait que ce fut intéressant
de l’utiliser dans le but d’en apprendre son fonctionnement, son usage m’a pris du temps
inutilement. Dans le contexte où j’étais seul sur le développement, la création des tâches ne
m’apportait aucune plus-value, les stories uniquement auraient été largement suffisantes.
12.2 Le respect de la planification

Le cadre de ce projet avait été très bien défini lors de la phase de pré-étude, tout comme l’ordre
dans lequel les différentes Stories seraient développées et mises en production. L’implémentation
de ce projet a ainsi respecté la planification et n’a subi aucun retard.
Malgré la demande du mandant d’ajouter une fonctionnalité en cours de développement, il a été très
simple de l’intégrer au cours de l’un des sprints. Il en ressort que le succès réside dans la
préparation.
12.3 La solution réalisée

D’un point de vue fonctionnelle et métier, la solution développée convient très bien au mandant.
Selon ses dires, cette application lui apportera une réelle plus-value dans la gestion de son
entreprise et dans le déroulement des travaux journaliers.
La solution est simple d’utilisation, ergonomique et répond à son besoin. Pour Monsieur Eric
Peguiron, les objectifs fixés ont été entièrement atteints et il en est pleinement satisfait.
Les perspectives d’évolution de l’application le réjouissent également. Il songe déjà à étendre

l’application avec une gestion des recettes de fabrication, ce qui pourra se faire au terme de ce
travail de Bachelor.

12.4 Les connaissances acquises
Le développement de cette application faisait appel à beaucoup de connaissance qui n’avaient pas
été enseignées dans le cadre de ma formation à la HEIG-VD. La configuration d’un serveur Linux, le
développement d’une application MVC avec le framework Laravel ou la création de scripts de
backups étaient pour moi des sujets nouveaux. J’ai souvent dû sortir de ma zone de confort pour me
former sur toutes ces technologies avant de pouvoir réaliser cette solution.
L’outil de gestion de version Git n’était pas maîtrisé et m’a également demandé un effort
d’apprentissage conséquent. Git prend surtout son sens lorsque plusieurs développeurs travaillent
sur le même projet, mais son utilisation m’a permis d’en apprendre les rudiments et les principes.
Et de manière plus générale, j’ai acquis beaucoup de connaissance sur la complexité et les
difficultés rencontrées dans la mise en place d’un ERP dans une entreprise. Ce type de projet
demande bien plus que des compétences en informatique. Un ERP agit sur la gestion d’entreprise
et ses processus. Il est donc primordial de bien en comprendre tous les tenants et aboutissants.
C’est seulement après avoir bien cerné quels sont les défis et difficultés auxquels font face les
collaborateurs qu’il devient possible de proposer la bonne solution qui répond à leurs attentes.
12.5 Les problèmes rencontrées
12.5.1 La conciliation entre les impératifs du projet et la vie familiale

Etant marié et père de deux garçons de 3 et 5 ans, ces 12 semaines de travail de Bachelor ont été
extrêmement difficiles à vivre pour ma famille et moi-même. Le nombre d’heures investies dans la
réalisation de ce projet ont eu pour conséquence que je rentrais souvent très tard et que j’ai été très
peu présent à mon domicile.
12.5.2 La conciliation entre les impératifs du projet et l’activité

professionnelle
La charge de travail importante nécessaire à la réalisation de ce travail de Bachelor a été très
difficile à concilier avec mes activités professionnelles. En tant que Sales Manager dans l’entreprise
qui m’emploie et avec un secteur de vente très étendu, il m’a été très difficile d’allouer du temps
régulier à la réalisation de ce projet.
Mon emploi du temps et mes horaires irréguliers ont fait que j’ai dû investir du temps sur ce travail
de Bachelor quand il m’était possible de le faire. C’est pour cette raison que j’ai beaucoup travaillé
de nuit ou en fin de semaine.

12.5.3 Les difficultés techniques
12.5.3.1 La configuration du serveur

La mise en place et la configuration du système d’exploitation GNU/Linux sur le serveur Raspberry
ont fait appel à beaucoup de notions que je ne maîtrisais pas. Un temps de documentation et
d'autoformation m’ont été nécessaires pour réaliser cette partie de ce travail.
Il s’agissait de la configuration de l’application HTTP Server Apache qui réceptionne les requêtes
HTTP de l’utilisateur et les renvoie vers la structure des fichiers de l’application Laravel. Une
configuration des utilisateurs et groupes du système d’exploitation Linux a été source de difficultés.
La fonction d’exécution automatique des scripts de backup m’ont également demandé un effort
important d’apprentissage. J’ai dû apprendre ce qu’était le logiciel Cron et comment créer des
scripts Shell pour Linux pour que la sauvegarde automatique de la base de données puisse
s’enregistrer sur le NAS.
12.5.3.2 La prise en main du framework Laravel

Laravel est un outil très complet qui permet de réaliser des applications complexes. Mais comme
tout framework, sa prise en main m’a demandé un effort important d’apprentissage.
Les principales difficultés auxquelles j’ai été confronté étaient la gestion de l’affichage des dates en
français avec la classe Carbon de Laravel, la création de certaines requêtes complexes avec
jointures entre les tables ou l’impression des commandes dans un fichier pdf.
12.5.3.3 Le filtrage de l’affichage des données dans les formulaires

Dans les formulaires de certaines vues de l’application, l’utilisateur doit saisir le nom d’un composant
dans un champs de saisie. Sitôt que deux caractères ou plus sont saisis, l’application effectue un
filtre et affiche uniquement les données qui contiennent cette chaîne de caractères.
Cette fonction étant exécutée du côté client, dans l’explorateur Web, elle devait être programmée en
langage JavaScript. Le développement de ce script m’a demandé beaucoup d’effort pour atteindre le
résultat attendu.
12.5.3.4 L’outil de gestion de version Git

Bien que très performant, cet outil nécessite d’en comprendre les principes de base et la philosophie
de développement en équipe pour l’utiliser. La prise en main de l’outil de gestion de version Git ainsi
que les bonnes pratiques de l’utilisation du système de branches m’ont demandé un important effort
d’apprentissage.

12.6 Les perspectives d’évolution
Grâce à sa structure modulaire et à la séparation claire des rôles de chaque partie de son code,
Laravel permet d’apporter de nombreuses perspectives d’évolution de cette application.
Certaines fonctionnalités supplémentaires pourraient être implémentées à la suite de ce travail de

Bachelor avaient déjà été mentionnées dans la pré-étude. Ces fonctionnalités métier sont :
1. La gestion des commandes d'abattage ;

2. La gestion des recettes pour la fabrication des produits.
Ces fonctionnalités apporteraient une plus-value métier supplémentaire à l’entreprise et pour des
raisons de limitation de temps, elles n’ont pas été implémentées dans le cadre de ce travail de
Bachelor.
La gestion des recettes faisant partie des secrets de fabrication de l’entreprise, Monsieur Eric
Peguiron souhaite que l’accès à ces données ne soient réservées qu’à certains de ses
collaborateurs. Cela implique qu’une fonctionnalité supplémentaire devrait être implémentée :
● La gestion des utilisateurs et les droits d’accès aux données.
Le développement de l’application ‘ Peguiplan ‘ ne s’achèvera donc pas au terme de ce travail de

Bachelor et sera complétée au cours des mois qui suivront.

13 Conclusion
L’objectif global de ce travail de Bachelor était d’apporter un outil informatique fonctionnel pour la
gestion des processus de production de la Boucherie-Charcuterie Eric Peguiron. Il s’agissait
d’apporter une solution simple et pratique qui permette aux collaborateurs de l’entreprise de gagner
du temps dans leurs tâches quotidiennes.
Cet outil devait s’approcher le plus possible des méthodes de travail actuelles de l’entreprise afin de
minimiser au maximum l’effet de changement pour les employés. Ce point était déterminant dans
l’acceptation de l’outil par ses utilisateurs. Car dans le contexte actuel, les employés de la boucherie
ne sont pas habitués à l’usage de l’ordinateur pour gérer leurs activités au quotidien. Un
changement trop brutal aurait pu conduire à un refus d’adoption de la solution, ce qui était un des
facteurs de risques important pour ce projet.
Arrivé au terme de ce projet, le constat est que le résultat correspond parfaitement à ce qui était
attendu. L’application apporte beaucoup de satisfaction à ses futurs utilisateurs. Lors des mises en
production, le propriétaire de l’entreprise et ses employés ont eu l’occasion de tester et prendre en
main la solution. Leur retour d’information est très positif et ils se réjouissent de pouvoir en faire
usage.
Monsieur Eric Peguiron est très enthousiaste et a déjà présenté cette application à quelques uns de
ses amis propriétaires d’une boucherie-charcuterie de la région. Il en découle que ce
développement a également du potentiel pour d’autres entreprises.
Je tire un bilan très positif de cette expérience. Le résultat obtenu et la satisfaction du client
m’indique que ce projet a atteint ses objectifs, tant sur le plan fonctionnel que sur le plan technique.
La conception et la réalisation d’une telle application m’a énormément appris de choses. Car un outil
de gestion est bien plus qu’un développement informatique. Il agit sur l’ensemble des processus de
l’entreprise et des méthodes de travail de ses employés.
J’ai ainsi dû commencer par bien m'imprégner de la philosophie de l’entreprise et bien comprendre
quelles sont les difficultés et les attentes de ses collaborateurs. Ceci afin de pouvoir adapter au
mieux l’application à leurs besoins. Je suis ensuite passé par une étape d’explication de ce que je
voulais leur apporter. Pour cela, il m’a fallu vulgariser le plus possible les concepts de ce qui serait
réalisé, afin qu’ils en comprennent les rudiments et les raisons de la structure de l’application.

Je constate par la même occasion que la méthode Agile est un parfait moyen pour intégrer le client,
les parties prenantes, pendant toute la durée du développement du projet. De cette manière, les
collaborateurs de l’entreprise avaient un contact régulier avec le projet et son évolution, ce qui leur
permettait de vivre cette expérience avec moi.
Sur le plan personnel, ce projet m’a permis de mettre en pratique de nombreuses connaissances
acquises durant ces quatre années de formations. De la gestion de projet et de processus en
passant par de la communication avec le client, le tout autour du développement d’un programme
informatique. Une excellente mise en situation de l’informatique de gestion.
Yverdon, le 27 septembre 2018 Thierry Auberson

14 Dossier de gestion
14.1 Le déroulement du travail réalisé

La méthode Agile selon un schéma Scrum qui a été utilisée pour réaliser ce projet se prêtait
parfaitement à mon contexte de travail. Engagé à 100 %, avec aucune possibilité d’allouer du temps
sur ce projet pendant mes heures de travail, souvent à l’extérieur de mon bureau et dépendant des
disponibilités de mes clients, il m’était impossible d’en planifier le déroulement au jour près.
La granularité du déroulement de ce travail était ainsi ramenée au niveau des Sprints pour lesquels
les fonctionnalités à développer étaient définies. Cela me donnait ainsi la flexibilité de pouvoir
investir du temps sur la réalisation de ce travail quand cela était possible, et de ne pas être lié à une
planification trop détaillée.
Pour une meilleure vue d’ensemble du déroulement des ces douze dernières semaines, le travail
accompli sera donc présentée selon une vision Scrum par Sprint avec le temps investi pour chaque
Story (fonctionnalités).
Le journal de travail détaillé avec une vision linéaire des heures investies par jour est livré avec les
annexes de ce mémoire.
14.1.1 Sprint 1
Durée : 1 semaine
Dates : du 9 au 13 juillet 2018
Stories Temps [h]
Installer le serveur Web Raspberry 2h 00’
Installer et configurer les applications sur le serveur Web 7h 30’
Configurer l’outil de gestion de version sur la station de développement 1h 00’
Configurer l’outil de gestion de version sur le serveur Web 1h 00’
Total : 11h 30’

14.1.2 Sprint 2
Durée : 3 semaines
Dates : du 14 juillet au 3 août 2018
Stories Temps [h]
Gestion des comptes clients 15h 00’
Gestion des contacts clients 24h 00’
Gestion des produits 4h 00’
Gestion des composants 6h 00’
Gestion des compositions 8h 30’
Total : 72h 30’
14.1.3 Sprint 3
Durée : 3 semaines
Dates : du 4 au 24 août 2018
Stories Temps [h]
Gestion des commandes clients 29h 30’
Impression des commandes clients 24h 00’
Sauvegarde automatique de la base de données sur le NAS 8h 00’
Total : 61h 30’

14.1.4 Sprint 4
Durée : 3 semaines
Dates : du 25 août au 14 septembre 2018
Stories Temps [h]
Gestion des commandes fournisseurs 4h 00’
Statistiques des commandes clients 1h 00’
Total : 5h 00’
14.1.5 Sprint 5
Durée : 1 semaine
Dates : du 15 au 21 septembre 2018
Stories Temps [h]
Tests réels en production et formation des utilisateurs 3h 00’
Total : 3h 00’

Récapitulatif des heures de travail
Date Horiare nuit Horaire matin Horaire après-midiHoraire soir Horaire nuit Somme d'heures Phase Travail effectué
09.01.2018 1700-1800 1800-1900 2,00 Sujet Client - Discussion du mandat
20.01.2018 1100-1200 1330-1730 5,00 Sujet Définition du mandat
20.01.2018 1730-1800 1800-1830 1,00 Sujet Conseiller - Discussion du mandat
27.01.2018 0930-1200 2,50 Sujet Modifications du mandat
12.02.2018 2100-2200 2200-0000 3,00 Sujet Finalisation du mandat
13.02.2018 1300-1400 1,00 Sujet Client - Signature du mandat
15.02.2018 Sujet Dépôt du mandat au secrétariat de la HEIG-VD
Total sujet : 19,00
29.03.2018 1045-1115 0,50 Préétude Conseiller - Planif initiale
14.04.2018 0900-1100 2,00 Préétude Conseiller - Point de situation
14.04.2018 1100-1200 1200-1400 3,00 Préétude UML - Use Case boucherie
14.04.2018 1400-1700 3,00 Préétude UML - Activity Diag Fabrication
14.04.2018 1100-1200 1200-1300 2,00 Préétude Planification pré-étude
14.04.2018 1300-1430 1,50 Préétude UML - Activity Diag Commande
14.04.2018 1430-1630 2,00 Préétude Document de pré-étude
23.04.2018 2200-0000 2,00 Préétude UML - EntityDiag Database
24.04.2018 1600-1700 1,00 Préétude Conseiller call - point de situation
24.04.2018 2200-0000 2,00 Préétude UML - Activity Diag Facturation
28.04.2018 0930-1100 1300-1500 3,50 Préétude Document de pré-étude
28.04.2018 1500-1530 0,50 Préétude Corrections UML
05.05.2018 1600-1700 1,00 Préétude UML - Conceptual Diag
10.05.2018 1400-1730 3,50 Préétude IHM - maquettes graphiques
11.05.2018 1530-1800 1800-1900 3,50 Préétude IHM - maquettes graphiques
11.05.2018 1900-1930 0,50 Préétude UML - corrections
11.05.2018 2000-2100 1,00 Préétude UML - Logical Diag
20.05.2018 1000-1200 1330-1700 2300-0000 6,50 Préétude Document de pré-étude
24.05.2018 1730-1800 1800-1830 1,00 Préétude Conseiller - Backlog
Total Pré-étude 62,00
09.07.2018 1700-1800 1800-1900 2,00 Implémentation Installation du serveur Web
09.07.2018 1900-2200 2200-0000 5,00 Implémentation Configuration des applications sur le serveur Web
10.07.2018 2030-2200 2200-0000 2,50 Implémentation Configuration des application sur le serveur Web
10.07.2018 2300-0000 1,00 Implémentation Configuration de Git sur le PC de développement
11.07.2018 0000-0100 1,00 Implémentation Configuration de Git sur le serveur
11.07.2018 1400-1600 2,00 Implémentation Conseiller - Sprint planning
12.07.2018 1800-2200 2200-2230 4,50 Implémentation Installation du serveur chez le mandant
14.07.2018 1400-1800 2000-2200 2200-0000 8,00 Implémentation CRUD comptes clients
15.07.2018 0000-0100 1,00 Implémentation CRUD comptes clients
16.07.2018 2200-0000 2,00 Implémentation CRUD comptes clients
17.07.2018 0000-0200 2200-0000 4,00 Implémentation CRUD comptes clients
18.07.2018 0000-0200 2,00 Implémentation CRUD contacts clients
21.07.2018 0900-1200 1200-1800 9,00 Implémentation CRUD contacts clients
24.07.2018 1700-1800 1800-2200 2200-0000 7,00 Implémentation CRUD contacts clients
25.07.2018 0000-0100 1900-2200 2200-0000 6,00 Implémentation CRUD contacts clients
26.07.2018 0000-0100 1600-1800 1800-1900 4,00 Implémentation CRUD produits
27.07.2018 1600-1800 2000-2200 2200-0000 6,00 Implémentation CRUD produits, composants
28.07.2018 0000-0100 1000-1200 1200-1300 1,00 Implémentation CRUD compositions
28.07.2018 1000-1200 1200-1300 3,00 Implémentation Client - Mise en pré-production
30.07.2018 1400-1800 1800-1900 5,00 Implémentation Modifications selon mandant
30.07.2018 2000-2100 1,00 Implémentation Client - Retrospective avec le mandant
30.07.2018 2130-2200 2200-2300 1,50 Implémentation CRUD compositions
31.07.2018 1600-1800 1800-2000 4,00 Implémentation CRUD compositions
02.08.2018 1600-1800 2,00 Implémentation CRUD compositions
03.08.2018 1600-1800 1800-2000 4,00 Implémentation Documentation code de l'application
04.08.2018 1000-1200 1200-1500 5,00 Implémentation Documentation code de l'application
04.08.2018 1500-1800 3,00 Implémentation Backup DB sur le NAS
06.08.2018 1500-1800 1800-2000 5,00 Implémentation CRUD commandes clients
07.08.2018 1700-1800 1800-2200 2200-0000 7,00 Implémentation CRUD commandes clients
09.08.2018 1600-1800 1800-2200 6,00 Implémentation CRUD commandes clients
11.08.2018 0000-0100 1,00 Implémentation Impression des commandes clients
23.08.2018 1700-1800 1800-1900 2,00 Implémentation Conseiller - client : mise en production
25.08.2018 1200-1400 2,00 Implémentation Résumé avec dépôt sur GAPS
25.08.2018 1400-1800 4,00 Implémentation Mémoire - rédaction
01.09.2018 1100-1200 1200-1600 5,00 Implémentation Mémoire - rédaction
05.09.2018 1800-2100 3,00 Implémentation Affiche
08.09.2018 1200-1600 4,00 Implémentation Afficher commandes fournisseurs
08.09.2018 1600-1700 1,00 Implémentation Statistiques des commandes clients
15.09.2018 1100-1200 1200-1400 3,00 Implémentation Modifications restrict sur delete ressources
15.09.2018 1400-1600 2,00 Implémentation Documentation code de l'application
15.09.2018 1600-1800 1800-1900 3,00 Implémentation Mise en production solution finale et formation
20.09.2018 0000-0200 0900-1100 1400-1800 1800-2100 11,00 Implémentation Mémoire - rédaction
24.09.2018 1600-1800 1800-1900 2100-2300 5,00 Implémentation Mémoire - rédaction
Total Implémentation 236,50
Total TB 317,50
14.3 Rendez-vous et contacts avec le Conseiller et l’entreprise
d’accueil
Date / heure Personne(s) de contact Objectif

Phase
29.09.2017 Conseiller : Nicolas Glassey Première rencontre avec le mandant et

1030-1200 Mandant : Eric Peguiron prise de connaissance du projet
Avant-projet Etudiant : Thierry Auberson
Rapport
Première rencontre entre le professeur conseiller M. Nicolas Glassey et le mandant M. Eric

Peguiron.
M. Eric Peguiron nous a présenté sa boucherie-charcuterie ainsi que ses processus et méthodes de
travail actuel. Nous avons ainsi pu nous plonger dans son univers afin d’identifier et comprendre
quels étaient les besoins métier dans ce projet.
Le point central se trouve être la gestion des commandes clients et fournisseurs. Pour cela, la
solution doit intégrer la gestion des données des clients et des produits manufacturés et vendus par
la boucherie-charcuterie.
La gestion de la facturation ne doit pas faire partie de la solution car la boucherie-charcuterie
possède déjà un système de balance qui permet de peser les articles et de les facturer directement.
Un point essentiel pour M. Peguiron est que la solution doit être la plus simple possible et ne doit en
aucun cas ajouter du travail supplémentaire aux méthodes actuelles.
M. Peguiron nous a également rendu attentif aux différentes contraintes d’hygiène qu’il doit
respecter. Ces contraintes sont un impératif dans son type d’activité car en cas de non respect, les
risques sanitaires peuvent avoir des conséquences graves pour l’entreprise.
Actions à entreprendre
1. Créer le projet sur la plateforme de gestion de projet “IceScrum”

2. Prendre en main le Framework Laravel
3. Me former sur l’outil de gestion de version “Git”
4. Livrer un schéma de flux du projet
5. Trouver 2 ou 3 ERP libres avant Noël pour les tester dès la mi-janvier

Phase
20.012018 Conseiller : Nicolas Glassey Définir le cadre du mandat du projet

1730-1830 Etudiant : Thierry Auberson
Mandat
Rapport
Conférence téléphonique au sujet de la première esquisse du mandat de projet. Le mandat doit

rester très général et focalisé sur le besoin métier du mandant. Tout ce qui concerne l’analyse de la
solution et les outils doit se faire dans la phase de pré-étude.
1. Condenser le mandat afin de le focaliser sur les besoins métier du mandant.

Phase
13.02.2018 Mandant : Eric Peguiron Signature du mandat par le mandant

Mandat
Rapport
Présentation du mandat au mandant. M. Eric Peguiron a validé le mandat et les objectifs du projet et
a signé le document.
1. Faire signer le mandat par le professeur conseiller.

Phase
29.03.2018 Conseiller : Nicolas Glassey Définir les ERP libres à tester

Pré-étude
Rapport
Conférence téléphonique au sujet des ERP libres à tester. L’objectif est d’effectuer une analyse des
produits existants sur le marché afin d’identifier si l’un d’entre-eux pourrait être utilisé et adapté dans
le cadre de ce travail de Bachelor.
Dans le cas où aucune solution existante n’apporterait satisfaction et ne répondrait aux besoins et
attentes du clients, la décision de développer une application de feuille blanche serait justifiée.
Les ERP libres qui seront testés et analysés seront “Odoo” et “Dolibarr”, qui sont deux ERP libres
largement répandus.
1. Tester et analyser les ERP libres “Odoo” et “Dolibarr”

2. Analyser si ces outils répondent aux attentes du mandant

Phase
14.04.2018 Conseiller : Nicolas Glassey Définir la solution, ERP existant ou feuille

0900-1000 Etudiant : Thierry Auberson blanche, qui sera utilisée dans le cadre
Pré-étude de ce travail de Bachelor
Rapport
Présentation de mes résultats d’analyses des ERP libres “Oddo” et “Dolibarr” :

● Les deux outils nécessitent de renseigner trop d’information des clients qui non souhaitées
par le mandant, tel que l'assujettissement à la TVA ou le numéro du registre du commerce.
● Il en est de même pour les produits auxquelles il faut renseigner les dimensions (pour
l’emballage), les taux de TVA ou autre.
● La gestion des commandes est trop compliquées pour les besoins du mandant. Elle ont
plusieurs status, “brouillon”, “validée”, “en cours”, “livrée” et “annulée”. Ce qui n’apporte
aucune plus-value au mandant mais lui ajoute des tâches jusqu’alors inexistantes.
● Les 2 outils ne gèrent pas les nomenclatures inversées, qui est la difficulté majeur dans
l’activité d’une boucherie-charcuterie. Ils doivent par conséquent être sujets à des
développements supplémentaires payants.
1. Définir les modèles conceptuels des données, les diagrammes de flux.

2. Définir les modèles logiques de la base de données.
3. Définir les interfaces graphiques.

Phase
24.04.2018 Conseiller : Nicolas Glassey Valider les diagrammes et modèles de

1630-1730 Etudiant : Thierry Auberson données pour démarrer la rédaction de la
Pré-étude pré-étude.
Rapport
Conférence téléphonique au sujet de différents diagrammes et modèles de données. Les

diagrammes sont dans l’ensemble bons et doivent être finalisés avec les derniers détails.
1. Ajouter des cartouches aux différents schémas.

2. Indiquer les validation des choix dans les diagrammes de flux.
3. Alléger le diagramme des cas d’utilisation en enlevant certaines bulles et en les mettant en
commentaire, comme le cas du login par exemple.
4. Générer un modèle conceptuel des données sur la base du modèle logique des données.

Phase
15.05.2018 Conseiller : Nicolas Glassey Définir la planification AGILE

Pré-étude
Rapport
Conférence téléphonique au sujet de la planification du projet qui doit être décrite dans la pré-étude.
Les scénarios, les stories et les critères d’acceptation des différentes fonctionnalités qui seront
traités durant la phase d’implémentation doivent être décrits et planifiés. Ils seront ensuite utilisés
pour alimenter les stories et les critères d’acceptations de la plateforme de gestion de projet
IceScrum .
1. Définir les scénarios et stories.

2. Définir les critères d’acceptation.
3. Planifier les différentes stories (fonctionnalités) dans les sprints qui seront réalisés durant
l’implémentation.,

Phase
24.05.2018 Conseiller : Nicolas Glassey Valider la planification pour la phase

1730-1830 Etudiant : Thierry Auberson d’implémentation.
Pré-étude
Rapport
Présentation finale de la planification de la phase d’implémentation du travail de Bachelor. Les

sprints sont définis avec des durées variables en fonction des degrés de complexité de chacune des
fonctionnalités qui seront développées dans chacun des sprints. Les délais de livraison des
fonctionnalités sont également définis et planifiés en fonction de la période de fermeture estivale de
l’entreprise du mandant, du 2 au 19 août 2018.
Le but étant d’avoir livré les fonctionnalités de la gestion des clients et des produits avant les
vacances d’été de la boucherie-charcuterie. Ceci afin de pouvoir développer la gestion des
commandes pendant cette période et de pouvoir la livrer au retour des vacances.
1. Finaliser le document de pré-étude

2. Déposer la pré-étude au secrétariat de la HEIG-VD avant 1er juin 2018 à 16h00.

Phase
11.07.2018 Conseiller : Nicolas Glassey Sprint planning du sprint 1

Implémentation
Rapport
Clôture de la release qui était en cours pour la pré-étude et création d’une nouvelle release pour la
phase d’implémentation. Puis nous avons défini les sprints en fonction de la planification qui a été
définie dans la pré-étude.
La plateforme IceS
1. Démarrer la phase d’implémentation

2. Documenter le travail effectué sur la plateforme IceScrum pour le suivi de l’avancement des
travaux.

Phase
12.07.2018 Mandant : Eric Peguiron Mise en production du sprint 1 :

1900-2200 Etudiant : Thierry Auberson Technical stories pour l’infrastructure
Implémentation
Rapport
Installation du serveur Raspberry dans la boucherie-charcuterie. Le serveur web est fonctionnel, est
connecté au réseau interne de l’entreprise et est configuré pour récupérer l’application sur le dépôt
décentralisé de gestion de version “Git”.
Le serveur web est accessible via un navigateur web sur un poste client, celui de la
boucherie-charcuterie.
1. Stopper le sprint 1.
2. Planifier les stories de gestion des clients et des produits dans le sprint 2.
3. Démarrer le sprint 2.
4. Développer les fonctionnalités du sprint 2, la gestion des clients et des produits.

Phase
30.07.2018 Mandant : Eric Peguiron Mise en production du sprint 2 :

2000-2100 Etudiant : Thierry Auberson User stories de la gestion des clients et
Implémentation des produits
Rapport
Démonstration et formation du mandant sur l’utilisation des premières fonctionnalités de

l’application.
M. Eric Peguiron peut dès à présent alimenter sa base de données avec les différents produits,
composants et compositions que fabrique son entreprise.
Il peut également renseigner les données de ses clients principaux afin de se faire à l’outil.
Nous constatons qu’au départ, il y a une confusion pour M. Peguiron quant aux notions de produits
et composants. Il doit à présent faire un effort mental de formaliser dans l’application ce qu’il a
toujours fait de tête.
Les produits correspondent aux produits finis qui sont vendus aux clients ou qui se trouvent en
vitrine du magasin.
Les composants sont les éléments de base utilisés dans la fabrication des produits finis et les
compositions permettent de lier des composants à des produits. Dans le cas d’un produit simple, il
n’y a qu’un seul composant. Et dans le cas d’un assortiment, il y en a plusieurs.
Cela lui paraît être compliqué au départ et je lui ai expliqué pourquoi cela doit être comme cela.
C’est principalement pour le futur, en cas de modification d’un composant ou de son prix au kg, qu’il
puisse faire la modification sur un seul composant et que tous les produits dérivés soient
directement modifiés sans devoir faire les modifications une à une dans chaque produit.
Nous nous projetons ensuite dans un scénario d’utilisation de l’outil au sein de son entreprise et M.
Peguiron me fait part qu’il souhaite pouvoir également imprimer les commandes. Ceci afin de les
avoir sur un bout de papier en laboratoire, comme il le fait actuellement avec ses post-it. Idéalement
en format A5 ou plus petit, A4 étant trop grand. Ces papiers seraient ainsi transmis aux clients avec
la commande.
Cette fonctionnalité n’était pas prévue au départ lors de la définition du cahier des charges. Je lui
propose donc d’ajouter cette fonctionnalité au product backlog du sprint 3 et de tenter d’implémenter
cette fonctionnalité supplémentaire. Lors de la prochaine livraison, si j’y suis parvenu, je pourrais
mettre en production la gestion des commandes ainsi que l’impression de ces dernières sur papier.
1. Stopper le sprint 2.
2. Planifier les stories de gestion des clients et des produits dans le sprint 3.
3. Démarrer le sprint 3.
4. Développer les fonctionnalités de la gestion des commandes clients.

Phase
23.08.2018 Conseiller : Nicolas Glassey Mise en production du Sprint 3 :

1700-1900 Mandant : Eric Peguiron Présentation de la gestion des
Implémentation Employé : Lionel Favre commandes clients
Etudiant : Thierry Auberson
Rapport
Nous avons commencé par faire une rétrospective sur les fonctionnalités qui avaient été mises en
production lors du sprint précédent :
● Gestion des comptes et contacts clients ;
● Gestion des produits, composants et compositions ;
● Rappel de la structure des clients et des produits afin de synchroniser les vocabulaires et la
compréhension globale du système.
J’ai ensuite fait jouer des scénarios de saisie de clients et des produits à M. Eric Peguiron et à son
employé, Monsieur Lionel Favre, afin qu’ils puissent tester l’outil eux-mêmes. La gestion des clients
et des produits correspond ainsi parfaitement avec leurs méthodes actuelles.
Nous sommes ensuite passé à l’utilisation de la gestion des commandes clients, qui est le contenu
du sprint en phase de livraison. Nous avons ainsi joué quelques scénarios réels, dans lequel des
clients les appellent et leur passe une commande. Ils ont constaté que les flux de navigation au
travers de l’application sont réalisés de manière optimale en fonction de leurs processus de travail.
Ils ont ensuite pu ajouter des produits composés ou non à leurs commandes, les modifier, en ajouter
ou en supprimer et faire les choix des composants des assortiments. Ils ont également pu tester
l’impression des commandes sur papier. Le résultat est très satisfaisant car il permet une souplesse
dans les choix des composants des assortiments, tout comme ils le font aujourd’hui.
Cette fonctionnalité est le noyau principal de ce qui est attendu de ce projet et a donné une
excellente satisfaction. Elle répond au besoin réel de l’entreprise.
J’ai ensuite fait la démonstration du bon fonctionnement des sauvegardes automatiques de la base
de données sur son NAS tous les jours à 1h du matin. Le résultat correspond à ce qui est attendu.
Le point critique majeur est la difficulté pour M. Eric Peguiron de restaurer le système en cas de
crash. Si cela devait arriver, il a besoin d’une méthode très simple et très rapide pour remonter son
système, afin de ne pas être arrêté dans ses activités.
En ce qui concerne les risques liés à la foudre, ils sont en principe inexistant car la
boucherie-charcuterie est équipée d’un parasurtenseur à gaz.
1. Réfléchir à un moyen d’installer un serveur redondant ou à créer un script qui permettrait de

récupérer automatiquement les données sauvegardées de la base de données.
2. Ajouter la saisie du numéro de téléphone lors de la saisie d’un contact client.
3. Supprimer la pagination dans l’index des produits et composants.
4. Ajouter une restriction sur la suppression des clients et produits pour ne pas perdre
l’historique des commandes.
5. Supprimer les sommes par position dans les commandes imprimées sur papier.
6. Ajouter une note sur les commandes sur papier que les indications de poids ne sont que
indicatifs.

Phase
15.09.2018 Mandant : Eric Peguiron Mise en production du Sprint 4 :

1600-1800 Etudiant : Thierry Auberson Présentation de la gestion des
Implémentation commandes fournisseurs et statistiques
Rapport
Présentation des dernières fonctionnalités de l’application :

● Génération automatique des commandes fournisseurs ;
● Génération des statistiques de composants commandés sur une période choisie ;
● Restriction de suppression de ressources Articles et Clients auyquelles des commandes ont
été enregistrées.
La solution est désormais prête à être utilisée en production chez le client. Ces deux dernières
fonctionnalités lui plaisent beaucoup car elles vont lui permettre de gagner un temps précieux dans
ses activités.
Eric Peguiron a également relevé un point auquel il n’avait pas fait mention auparavant, les
commandes des sociétés locales. Certaines sociétés locales, comme des sociétés de tir ou de
jeunesses campagnardes, lui commandent souvent “la même chose que l’année passée”, car ils ne
se souviennent pas forcément des quantités commandées. Actuellement, Eric Peguiron doit
effectuer des recherches dans ses agendas papier et ses post-it afin de retrouver quel était le
contenu de la commande. L’application Peguiplan lui permettra de retrouver ces informations
beaucoup plus rapidement. Pour cela, il serait utile d’ajouter une fonction pour lister les commandes
par client.
Il reste encore à trouver un moyen d’avoir une redondance du système en cas de crash. Eric
Peguiron souhaite ne subir aucun retard si le serveur d’application ou le NAS venait à être
défectueux. Nous nous focaliserons sur une solution une fois le travail de Bachelor effectué.
En attendant, Eric Peguiron souhaite commencer à utiliser l’application immédiatement en parallèle
de sa méthode actuelle. Cela permettra ainsi à ses collaborateurs de se familiariser au produit, sans
pour autant qu’ils perdent leurs repairs. L’agenda en papier et les post-it seront toujours présent afin
que le déroulement des activités ne soit pas bloqué en cas de difficulté.
Ceci permettra de procéder à une transition douce et d’éventuellement faire ressortir des fonctions
manquantes à l’application.
1. Réfléchir à un moyen d’installer un serveur redondant ou à créer un script qui permettrait de

récupérer automatiquement les données sauvegardées de la base de données.
2. Implémenter une fonction qui permet de lister les commandes propres à un client.

15 Informations du document
15.1 Historique des versions
Version Date Description / remarques Auteur
1.0 28.09.2018 Dossier d’implémentation Thierry Auberson
15.2 Définitions, acronymes et abréviations
Mot / Abréviation Signification
ERP Enterprise Resource Planning ou PGI pour Progiciel de Gestion Intégré (en
français). Programme informatique pour la gestion d’entreprise, tel que la
gestion de la production, des ressources, des stocks ou de l'administration.
GPAO Gestion de la Production assistée par Ordinateur
TGE Très grande entreprise
PME Petites et moyennes entreprises
TPE Très petite entreprise
NAS Network Access Storage ou stockage accessible par le réseau.
ORM Object Relationnal Mapping
DRY Don’t Repeat Yourself
OS Operating System
GPL General Public Licence

15.3 Vocabulaire métier
Termes Signification
Production Activités qui consistent à produire les morceaux nobles telles que l’abattage
de l’animal, le désossage, etc...
Fabrication Transformation des morceaux nobles en produits et sous-produits qui

seront utilisés pour la découpe et le mélange avec des épices.
Préparation Activité qui consiste à préparer les commandes des clients avec des
produits finis.
15.4 Vocabulaire technique
Termes Signification
Framework Ensemble cohérent de composants logiciels structurels qui sert de

fondations de l’ensemble ou d’une partie d’un logiciel.
Middleware Classes faisant partie du framework qui sont chargées d’effectuer des
traitements à l’arrivée d’une requête ou à son départ. Les middleware sont
une surcouche de l’application.
SSH Secure Shell est à la fois un programme informatique et un protocole de

communication sécurisé.
ORM Object Relational Mapping, outil qui permet d’effectuer des requêtes en
base de données via le programme applicatif et de s’affranchir du langage
SQL.
fork Nouveau logiciel créé à partir du code source d’un logiciel existant lorsque
les droits accordés par les auteurs le permettent.
design pattern Appelé patron de conception en français, est un arrangement

caractéristique de modules, reconnu comme bonne pratique en réponse à
un problème de conception d’un logiciel.
plug-in Module d’extension, module externe ou greffon qui apporte des

compléments à un logiciel.
DRY Concept de bonne pratique consistant à éviter la répétition de code : Don’t

Repeat Yourself pour Ne pas vous répéter.
package Fichier archive comprenant les fichiers, les informations et les procédures
nécessaires à l’installation d’un logiciel sur un système d’exploitation.

cron Programme qui permet d’exécuter automatiquement des scripts, des
commandes ou des logiciels, sur un système de type Unix. Son exécution
peut être à une date et une heure spécifiées à l’avance, ou selon un cycle
défini.
crontab Fichier contenant la table des tâches à effectuer par le logiciel cron.
cronjob Une tâche à effectuer par le logiciel cron. Correspond à une entrée dans le
fichier crontab et est défini avec les paramètres de date, heure et cycle
d’exécution.
Product Owner Le propriétaire d’un produit. Correspond au client ou au mandant d’un projet
qui en sera le bénéficiaire et l’utilisateur final.
Waterfall Technique de gestion de projet standard qui se déroule en une seule fois
avec livraison à la fin.
User Story Fonctionnalité métier correspondant à un besoin métier.

16 Exploitation des sources bibliographiques
16.1 Livres
Sujets Titres de l’ouvrage Auteurs
UML UML 2 par la pratique Pascal ROQUES

Études de cas et exercices corrigés
Laravel Découvrez le Framework PHP Laravel OpenClassrooms - Maurice

CHAVELLI
Laravel Laravel - Un framework efficace pour développer Raphaël HUCHET

vos applications PHP
Git Git - Maîtrisez la gestion de vos versions Samuel DAUZON

(concepts, utilisation et cas pratiques)
Bootstrap Prenez en main Bootstrap OpenClassrooms - Maurice

CHAVELLI
MySQL Administrez vos bases de données avec MySQL OpenClassrooms - Chantal

GRIBAUMONT
PHP Programmez en orienté objet en PHP OpenClassrooms - Victor

THUILLIER
PHP et Concevez votre SITE WEB avec PHP et MySQL OpenClassrooms - Mathieu
MySQL Le développement d’un site dynamique enfin à NEBRA
votre portée !

16.2 Sources en ligne
Sujet Source Lien
Petit guide de la découpe de Micarna https://www.micarna.ch/sites/micarna.ch/file

la viande de Porc s/Micarna_Fleischkunde_Schwein_FR.pdf
Ordonnance sur les denrées Confédération https://www.admin.ch/opc/fr/official-compilati

alimentaires Suisse on/2002/573.pdf
Ordonnance du DFI sur Confédération https://www.admin.ch/opc/fr/classified-compi

l’hygiène dans les activités Suisse lation/20143394/201805010000/817.024.1.p
liées aux denrées df
alimentaires
Liste des progiciels de Wikipedia https://fr.wikipedia.org/wiki/Liste_de_progici

gestion ingégrs els_de_gestion_int%C3%A9gr%C3%A9s
ERP ORACLE : La Wikipedia https://fr.wikiversity.org/wiki/ERP_ORACLE/

concurrence ORACLE La_concurrence_ORACLE
Top des 5 ERP gratuits et appvizer https://www.appvizer.fr/magazine/operations

Open Source /erp/top-5-erp-gratuit-open-source
11 Best PHP Frameworks Coders Eye https://coderseye.com/best-php-frameworks

for Modern Web Developers -for-web-developers/
in 2018
Méthode Agile Wikipedia https://fr.wikipedia.org/wiki/M%C3%A9thode

_agile
Scrum Wikipedia https://fr.wikipedia.org/wiki/Scrum_(d%C3%

A9veloppement)
Raspberry Raspberry https://www.raspberrypi.org/downloads/
Apache Wikipedia https://fr.wikipedia.org/wiki/Apache_HTTP_S

erver
PHP Wikipedia https://fr.wikipedia.org/wiki/PHP
Git CDSS Learn / Git http://learn.openwaterfoundation.org/cdss-le

arn-git/08a-lesson-workflow-concepts/lesson
-workflow-concepts/
design pattern Wikipedia https://fr.wikipedia.org/wiki/Patron_de_conc

eption
MariaDB Wikipedia https://fr.wikipedia.org/wiki/MariaDB
Bitbucket Wikipedia https://fr.wikipedia.org/wiki/Bitbucket
JavaScript Wikipedia https://fr.wikipedia.org/wiki/JavaScript
Laravel Wikipedia https://fr.wikipedia.org/wiki/Laravel

Laravel OpenClassrooms https://openclassrooms.com/fr/courses/3613
341-decouvrez-le-framework-php-laravel/
Bootstrap Wikipedia https://fr.wikipedia.org/wiki/Bootstrap_(frame

work)
Licence MIT Wikipedia https://fr.wikipedia.org/wiki/Licence_MIT
Bootstrap Bootstrap http://getbootstrap.com/
PHPUnit Wikipedia https://fr.wikipedia.org/wiki/PHPUnit
Atom Wikipedia https://fr.wikipedia.org/wiki/Atom_(%C3%A9

diteur_de_texte)
ORM Wikipedia https://fr.wikipedia.org/wiki/Mapping_objet-re

lationnel
Concours swiss-skills 2012 Union https://www.metzgerei.ch/fr/medias/mitteilun

Professionnelle gen/2012-11-06-mitteilung.php
Suisse de la Viande

16.3 Logiciels utilisés
Logiciel Documents réalisés
Google Docs Dossier de pré-étude
Visual Paradigm - Community Edition Diagrammes de séquences, de cas d’utilisations et

modélisation des données
LibreOffice Draw Organigrammes et maquettes des interfaces graphiques
ProjectLibre Planification du projet
GIMP Retouches d’images
Atom Développement de l’application Laravel
MySQL Workbench Manipulation de la base de données
iceScrum Gestion de projet avec la méthode Agile
Git Gestion des versions de développement
Apache Serveur Web HTTP
Laravel Framework PHP pour le développement de l’application
MariaDB Base de données de l’application
Bitbucket Plateforme web pour héberger le dépôt distant Git de

l’application

Annexe 01
Installation du server Raspberry Pi
Installation de l'OS
1. Télécharger l'image de l'OS sur le site de Rasberry

2. Installer l'application pour la création de la carte microSD:
$ sudo apt-get install gddrescue xz-utils
1. Aller dans le dossier de téléchargement de l'OS :
$ cd /home/share/Software_Linux
1. Décompresser l'image de l'OS :
$ nxz ubuntu-mate-16.04.2-desktop-armhf-raspberry-pi.img.xz
1. Ecrire la carte microSD du server (où /dev/mmcblk1 est le nom de la carte microSD):
$ sudo ddrescue -D --force ubuntu-mate-16.04.2-desktop-armhf-raspberry-pi.img

/dev/mmcblk1
Installation des applications sur le Raspberry
Un guide est disponible ici :
https://raspbian-france.fr/installer-serveur-web-raspberry-lamp/
Installation de Apache
Mise à jour du serveur
$ sudo apt update

$ sudo apt upgrade
$ sudo apt update
$ sudo apt install apache2
Installation de Apache
$ sudo apt install apache2
Modifier les droits d'accès pour accéder depuis le web

$ sudo chown -R peguiplan:www-data /var/www/html/
$ sudo chmod -R 770 /var/www/html/
Vérifier que Apache fonctionne
$ wget -O verif_apache.html http://127.0.0.1
Aide à la configuration de Apache ici :
1. Installer Apache et PHP 7.2
sudo add-apt-repository ppa:ondrej/php

sudo apt-get update
sudo apt-get install apache2 libapache2-mod-php7.2 php7.2 php7.2-xml php7.2-gd
php7.2-opcache php7.2-mbstring
1. Installer laravel
cd /tmp
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
1. Configurer apache
sudo chgrp -R www-data /var/www/html/your-project

sudo chmod -R 775 /var/www/html/your-project/storage
1. Configurer le fichier sites-available
cd /etc/apache2/sites-available
sudo nano laravel.conf
1. Ajouter le contenu suivant
<VirtualHost *:80>
ServerName yourdomain.tld
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/your-project/public
<Directory /var/www/html/your-project>
AllowOverride All
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
1. Exécuter les commandes :
sudo a2dissite 000-default.conf

sudo a2ensite laravel.conf
sudo a2enmod rewrite
sudo service apache2 restart
Références supplémentaires :
https://httpd.apache.org/docs/2.4/vhosts/name-based.html
Installation de PHP
Installer nano
$ sudo apt-get install nano
Ajouter un nouveau repository sources
$ sudo nano /etc/apt/sources.list
A la fin du fichier, ajouter les lignes suivantes :
deb http://repozytorium.mati75.eu/raspbian jessie-backports main contrib non-free

#deb-src http://repozytorium.mati75.eu/raspbian jessie-backports main contrib
non-free
Ajouter les certificats pour utiliser ces sources :
$ sudo gpg --keyserver pgpkeys.mit.edu --recv-key CCD91D6111A06851

$ sudo gpg --armor --export CCD91D6111A06851 | sudo apt-key add -
$ sudo apt-get update
Installer PHP 7.1
$ sudo apt install php7.1 php7.1-mbstring php7.1-xml
Configuration de php pour utiliser dompdf
https://tutoandco.colas-delmas.fr/developpement/installer-php7-1-php7-1-fpm-debian-
raspberry-raspbian/
Bug Fix pour PhpMyAdmin avec PHP7
Voici quelques liens pour fixer des bugs qu'il pourrait y avoir avec PhpMyAdmin et PHP7
https://devanswers.co/problem-php-7-2-phpmyadmin-warning-in-librariessql-count/
https://devanswers.co/manually-upgrade-phpmyadmin/
https://www.phpmyadmin.net/downloads/
Fix pour installation de PHP7.1 sur Raspberry
https://www.stewright.me/2016/03/turn-raspberry-pi-3-php-7-powered-web-server/
https://stackoverflow.com/questions/43408604/php7-install-ext-dom-issue
Configurer PHP sur le Raspberry :
https://tutoandco.colas-delmas.fr/developpement/installer-php7-1-php7-1-fpm-debian-
raspberry-raspbian/
Installation de MariaDB
Stopper MariaDB
/etc/init.d/mysql stop
Démarrer MariaDB en mode safe sans mot de passe et se connecter
mysqld_safe --skip-grant-tables &

...
mysql -u root
Modifier le mot de passe
use mysql;
update mysql.user set password=PASSWORD("mynewpassword") where user='root';
UPDATE mysql.user SET Grant_priv='Y', Super_priv='Y' WHERE user='root';
flush privileges;
quit
Stopper et redémarrer MariaDB
sudo /etc/init.d/mysql stop

...
sudo /etc/init.d/mysql start
Se connecter à MariaDB normalement avec
mysql -u root -p
Aide à la redéfinition des privilèges :
https://support.rackspace.com/how-to/mysql-resetting-a-lost-mysql-root-password/
https://korben.info/comment-changer-le-mot-de-passe-root-perdu-de-mysql.html
https://stackoverflow.com/questions/1709078/how-can-i-restore-the-mysql-root-user-s
-full-privileges
Aide à la gestion des utilisateurs
Un tuto exite ici :
https://www.howtogeek.com/50787/add-a-user-to-a-group-or-second-group-on-linux/
Installation de laravel
Installation de composer. Dans le terminal, aller dans le dossier du projet et coller le contenu
suivant :
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

php -r "if (hash_file('SHA384', 'composer-setup.php') ===
'669656bab3166a7aff8a7506b8cb2d1c292f042046c5a994c43155c0be6190fa0355160742ab2e1c88
d40d5be660b410') { echo 'Installer verified'; } else { echo 'Installer corrupt';
unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
Puis déplacer le fichier composer.phar dans le dossier suivant (pour pouvoir l'exécuter de
n'importe où)
$ sudo mv composer.phar /usr/local/bin/composer
Créer le projet avec composer
$ composer create-project --prefer-dist laravel/laravel ~/web/peguiplan
Pour lancer le serveur la première fois
cd ~/web/peguiplan
composer update
composer install
php artisan install
cp .env.example .env
php artisan key:generate
Aller faire la configuration dans le fichier .env
php artisan migrate

php artisan serve
Pour pouvoir utiliser le construteur de formulaires de laravel :
composer require "laravelcollective/html":"^5.4"
Changer des colonnes dans les tables de la DB avec les migrations requière Doctrine DBAL
composer require doctrine/dbal
Pour afficher les dates en différentes langues
composer require caouecs/laravel-lang:~3.0
Ensuite copier le dossier /vendor/caouecs/laravel-lang/src/fr dans le dossier /resources/lang
Créer un dossier pour stocker l'application Laravel et créer un raccourci depuis le dossier
/var/www/
mkdir -p ~/web/peguiplan/
$ sudo ln -s ~/web/peguiplan /var/www/
Exemple avec tuto :
http://valentinvannay.com/2016/01/21/installation-of-a-web-server-and-laravel-5-on-
a-raspberry-pi-2/
Installer Laravel avec Apache2 et PHP 7.2 :
https://www.howtoforge.com/tutorial/install-laravel-on-ubuntu-for-apache/
Annexe 02
Préparation du dépôt Git sur Bitbucket
1. Aller sur Bitbucket.org
2. Créer un repository
Mise en place de SSH pour Git sur Linux
https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html
Etape 1: Mise en place de l'identité par défaut
1. Créer l'identité par défaut :
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
1. Presser Enter pour accepter l'emplacement par défaut.

2. Entrer et ré-entrer un mot de passe quand demandé (passphrase '*******'):
Enter passphrase (empty for no passphrase):

Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:TjfWhN95zdwrxFwszMZdf4+oYIufEECu/BcS/JR/XqQ user@thi-tosh
The key\'s randomart image is:
+---[RSA 2048]----+
| . .|
| + . .+ o o|
| = o . o* +o|
| . . = . *+oo==|
| o . + S E =++ B|
| . . B B +. ..|
| . + o o . . |
| . o . . |
| o |
+----[SHA256]-----+
1. Lister le contenu de ~/.ssh :
$ ls ~/.ssh/
id_rsa id_rsa.pub
Etape 2: Ajouter la clé au ssh-agent
1. Pour démarrer l'agent, exécuter :
$ eval `ssh-agent`
Agent pid 10263
1. Entrer ssh-add suivi du chemin vers le private key file :
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
Etape 3 : Ne concerne que les dépôts de type Mercurial
Etape 4 : Ajouter la clé publique aux paramètres de Bitbucket
1. Dans Bitbucket, aller dans Bitbucket settings depuis l'avatar en bas à gauche. La page Account
settings s'ouvre
2. Cliquer sur SSH keys Si des clés ont déjà été ajoutées, elles seront visibles sur cette page.
3. Dans le terminal, copier le contenu du public key file :
$ cat ~/.ssh/id_rsa.pub
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQC+SdGZ6J7iFqvcVg1drRNh+22bxA2L7xODTY0W36jBGkTL9iGhMH9
dZkGAa/gfY6AlPEOAVHOpLOJdWQqUyfs+W7LUH9w1H4lfFhuAZWpYmEwbaiT3tOon5lTi9JhOmDaYiOxiN1
34TNnZz00eBVRydKF5AHbMOycU2pKOJT5nidSLKdcm7aJwroAiAOpyHQK1Kdc8L4rd+GNBmjlz8chHI8fPG
KMHaTCdrhkhUZqKamhMoCQo8mqrfAoF/uOBIXVBI/d6ACB7hByRcUQa5nO5mCdyad+R4UKWD9XgZTEJT+w7
2Wh36llZ0tfpDRXYwSHerYoPZg9ItBlmqc7HvLR/ user@thi-tosh
1. Selectionner et copier le texte affiché

2. Dans Bitbucket, cliquer sur Add key
3. Entrer un Label pour cette nouvelle clé
4. Coller le contenu de la clé publique dans la zone du champs SSH Key Nous devrions voir
l'adresse e-mail ou le nom du user sur la dernière ligne. Cela n'a pas d'importance si elle est
collée ou pas.
1. Cliquer sur Save Bitbucket devrait envoyer un email pour confirmer l'ajout de la nouvelle clé.
2. Retourner dans le terminal et vérifier la configuration de l'utilisateur en entrant la commande
suivante :
$ ssh -T git@bitbucket.org
1. Un message d'avertissement appararaît et la demande du mot de passe de la clé privée est

demandée pour valider l'accès permanent avec SSH :
The authenticity of host \'bitbucket.org (104.192.143.3)' can't be established.

RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added \'bitbucket.org,104.192.143.3\' (RSA) to the list of
known hosts.
logged in as tchery.
You can use git or hg to connect to Bitbucket. Shell access is disabled.
Préparation du poste de travail

Création du dossier de travail et création du lien symbolique pour Apache:
$ mkdir /home/share/Dev
$ sudo ln -s /home/share/Dev/ /var/www/Dev
Tester l'accès au dossier avec le Browser :
localhost
Cloner le dépôt Git en local :
1. Aller dans le dossier de Dev et clôner le dépôt distant sur la machine locale
$ cd /home/share/Dev/
user@thi-tosh:/home/share/Dev$ git clone git@bitbucket.org:tchery/peguiplan.git
Clonage dans 'peguiplan'...
Warning: Permanently added the RSA host key for IP address '104.192.143.2' to the
list of known hosts.
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Réception d\'objets: 100% (3/3), fait.
Ajouter les premiers fichiers dans le dépôt Git
1. Compléter le fichier README.md avec les dossiers et fichiers à souhait

2. Ajouter le tout au dépôt :
user@thi-tosh:/home/share/Dev/peguiplan$ git add -A

user@thi-tosh:/home/share/Dev/peguiplan$ git commit -m "Complete README.md"
[master 68b08b4] Complete README.md
1 file changed, 9 insertions(+)
user@thi-tosh:/home/share/Dev/peguiplan$ git push
Décompte des objets: 3, fait.
Delta compression using up to 2 threads.
Compression des objets: 100% (3/3), fait.
Écriture des objets: 100% (3/3), 487 bytes | 487.00 KiB/s, fait.
Total 3 (delta 1), reused 0 (delta 0)
To bitbucket.org:tchery/peguiplan.git
647df7e..68b08b4 master -> master
Annexe 03
Sur le NAS
Référence :
https://blog.whabash.com/posts/mounting_synology_nas_shared_folder_nfs_ubuntu_16_10
1 . Activer NFS sur le NAS Synology
Activer le service NFS (si pas activé)
2. Créer/Editer un Shared Folder et ajouter les permissions NFS
3. Installer nfs-common
sudo apt install nfs-common
4. Monter le share sur le serveur
Créer un dossier cible pour le point de montage et exécuter la commande suivante adaptée avec
l'adresse IP du serveur NFS et monter le point de montage
sudo mount 192.168.178.3:/volume1/peguiplan /mnt/NAS/peguiplan
5. Montage automatique lors du boot
Pour ajouter un point de montage persistant vers le share NFS, ajouter une entrer dans le fichier
/etc/fstab :
sudo nano /etc/fstab
et ajouter :
192.168.178.3:/volume1/peguiplan /mnt/NAS/peguiplan nfs

rsize=8192,wsize=8192,timeo=14,intr
Backup de la base de données

Référence:
https://www.kinamo.fr/fr/support/faq/mysql-backup-automatique-base-de-donnees
1. Créer un fichier script nommé mysql_backup.sh et entrer le script suivant :
#!/bin/bash
# Configuration de base: datestamp e.g. YYYYMMDD
DATE=$(date +"%Y%m%d")
# Dossier où sauvegarder les backups (créez le d'abord!)
BACKUP_DIR="/mnt/NAS/peguiplan/backup/mysql"
# Identifiants MySQL
MYSQL_USER="DBName"
MYSQL_PASSWORD="MyPasswordDB"
# Commandes MySQL (aucune raison de modifier ceci)
MYSQL=/usr/bin/mysql
MYSQLDUMP=/usr/bin/mysqldump
# Bases de données MySQL à ignorer
SKIPDATABASES="Database|information_schema|performance_schema|mysql"
# Nombre de jours à garder les dossiers (seront effacés après X jours)
RETENTION=14
# ---- NE RIEN MODIFIER SOUS CETTE LIGNE ------------------------------------------

#
# Create a new directory into backup directory location for this date
mkdir -p $BACKUP_DIR/$DATE
# Retrieve a list of all databases
databases=`$MYSQL -u$MYSQL_USER -p$MYSQL_PASSWORD -e "SHOW DATABASES;" | grep -Ev

"($SKIPDATABASES)"`
# Dumb the databases in seperate names and gzip the .sql file
for db in $databases; do
echo $db
$MYSQLDUMP --force --opt --user=$MYSQL_USER -p$MYSQL_PASSWORD --skip-lock-tables
--events --databases $db | gzip > "$BACKUP_DIR/$DATE/$db.sql.gz"
done
# Remove files older than X days
find $BACKUP_DIR/* -mtime +$RETENTION -delete
et copier ce script sous /usr/local/sbin/

sudo cp mysql_backup.sh /usr/local/sbin/
2. Changer les droits sur le script :
sudo chmod 755 /usr/local/sbin/mysql_backup.sh
3. Créer un cronjob
Modifier le crontab du serveur pour exécuter le script tous les jours à 1h :
sudo nano /etc/crontab
0 1 * * * root /usr/local/sbin/mysql_backup.sh
4. Relancer le daemon cron
Sauvegardez le fichier cron et redémarrer le service, ce qui se fait avec une des commandes
suivantes selon votre distribution Linux :
service cron restart

service crond restart
5. Forcer le crontab pour tester
Pour tester si le crontab fonctionne correctement et si les droits sur le NAS Synology sont
configurés correctement, le cronjob peut être forcé à s'exécuter de la manière suivante :
cd /etc/crontab/
sudo ./mysql_backup.sh
6. Ajouter un cronjob pour monter les dossiers de /etc/fstab après le redémarrage
Après un reboot, le Raspberry exécute directement la commande /etc/fstab Mais le Raspberry n'est
pas encore connecté au Wi-Fi et ne peut donc pas monter le dossier distant sur le NAS. C'est
pourquoi un cronjob, avec un délai de 60 secondes par exemple, peut être ajouté afin de monter le
dossier une fois le réseau connecté
https://askubuntu.com/questions/792973/how-can-i-force-a-mount-a-to-run-after-the-s
ystem-boots-up
Ouvrir le crontab
sudo nano /etc/crontab

Et ajouter la ligne suivante
@reboot root /bin/bash -c 'sleep 60 && /bin/mount -a'
mount NAS with NFS:
https://blog.whabash.com/posts/mounting_synology_nas_shared_folder_nfs_ubuntu_16_10
Tuto pour le backup automatique de la DB :
https://www.kinamo.fr/fr/support/faq/mysql-backup-automatique-base-de-donnees
Tuto pour la sauvegarde de la microSD du Raspberry :
https://domopi.eu/sauvegarde-de-la-carte-sd-du-raspberry-pi-sur-un-serveur-externe/
Annexe 04
Règles de validations custom pour les time and Database
Les règles de validations pour les formats de date et time n'existent pas par défaut dans Laravel. Il
faut les créer sois-même : Lien ici :
https://stackoverflow.com/questions/32006092/laravel-5-1-date-format-validation-all
ow-two-formats
Editer le fichier app/Providers/AppServiceProvider avec le code suivant :
<?php
namespace Peguiplan\Providers;
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Validator;
class AppServiceProvider extends ServiceProvider

{
/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
/**
* Custom validation rule
*
* @return boolval
*/
Validator::extend('date_multi_format', function($attribute, $value,
$formats){
// Iterate through all formats
foreach ($formats as $format) {
// parse time with current formats

$parsed = date_parse_from_format($format, $value);
// if value matches given format return true=validation succeeded

if ($parsed['error_count'] === 0 && $parsed['warning_count'] === 0)
{
return true;
}
}
// value did not match any of the provided formats, so return

false=validation failed
return false;
});
}
/**
* Register any application services.
*
* @return void
*/
public function register()
{
//
}
}
Et ensuite, dans la class de validation de requêtable app/Http/Requests/ModelCreateRequest

Utiliser la règle selon exemple suivant :
public function rules()

{
return [
'name' => 'required|max:50',
'unit_price' => 'required|between:0,99999.99',
'unit' => 'required|max:20',
'quantity_person' => 'between:0,99999.999',
'working_duration' => 'date_multi_format:"Y-m-d H:i:s.u","H:i:s"'
];
}
Cet exemple traîte d'une valeur de time :
'working_duration' => 'date_multi_format:"Y-m-d H:i:s.u","H:i:s"'
Pour une utilisation d'une date uniquement :
'working_duration' => 'date_multi_format:"Y-m-d H:i:s.u","Y-m-d"'
Ou Date et Time :
'working_duration' => 'date_multi_format:"Y-m-d H:i:s.u","Y-m-d H:i:s"'

Travail de Bachelor
Modèle d’authentification
Authentification
Le soussigné, Thierry Auberson, atteste par la présente avoir réalisé seul ce travail et n’avoir
utilisé aucune autre source que celles expressément mentionnées, si ce n’est les
connaissances acquises durant ses études et son expérience acquise dans une activité
professionnelle.
Yverdon, le 27 septembre 2018
Thierry Auberson

Auberson Thierry PDF

Transféré par

Droits d'auteur :

Formats disponibles

Auberson Thierry PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Auberson Thierry PDF

Transféré par

Droits d'auteur :

Formats disponibles

Conception d’une application

permettant la gestion des processus de production

PÉRIODE DE RÉALISATION DE MARS À OCTOBRE 2018

ORIENTATION SYSTÈMES DE GESTION

Boucherie-Charcuterie Eric Peguiron

Son contenu, sans préjuger de sa valeur, n'engage ni la responsabilité de

Aucune utilisation, même partielle, de ce travail ne peut être faite sans

Yverdon-les-Bains, novembre 2017

TRAVAIL DE BACHELOR 2017 - 2018

Conception d'une application permettant la gestion des processus de

Entreprise Boucherie -Charcuterie Eric Peguiron (Peguiron Eric)

L'entreprise Boucherie-Charcuterie Eric Peguiron est une entreprise individuelle située à

La boucherie compte aujourd’hui 4 collaborateurs, Eric Peguiron le propriétaire et ses 3

Ce projet, du nom de “Peguiplan”, a pour objectif d’implémenter un outil de gestion

Pour terminer, l’application implémentera la possibilité d’extraire des statistiques de production

Boucherie -Charcuterie Eric Peguiron

09.09.2018 - Travail de Bachelor de Auberson Thierry - Page 2 / 2

En premier lieu, je remercie Monsieur ​Eric ​Peguiron​, propriétaire de l’entreprise d’accueil

Je remercie Monsieur ​Nicolas ​Glassey​, enseignant en informatique au ​Centre ​professionnel ​du

Thierry Auberson 7 / 160

​4​ Table des matières ​9

​5​ Introduction ​17

​6​ Pré-requis de lecture ​19

​7​ Présentation de l’entreprise ​21

​7.1​ Historique de l’entreprise ​21

​7.2​ Succès de l’entreprise ​22

​7.3​ Organisation ​22

​7.4​ Activités ​23

​8​ Cahier des charges ​25

​8.1​ Rappel des spécifications fonctionnelles ​25

​8.2​ Rappel des spécifications techniques ​25

​8.2.1​ L’infrastructure matérielle ​26

​8.2.2​ La sauvegarde et la restauration du système ​27

​8.3​ Rappel des Technical Stories ​27

​8.3.1​ Mise en place du serveur ​27

​8.3.1.1​ Installer le serveur web ​27

​8.3.1.1.1​ Story ​27

​8.3.1.1.2​ Tests d’acceptation ​27

​8.3.1.2​ Installer l’application sur le serveur web ​28

​8.3.1.2.1​ Story ​28

​8.3.1.2.2​ Tests d’acceptation ​28

​8.3.2​ Mise en place de l’outil de gestion de versions ​28

​8.3.2.1​ Configurer l’outil de gestion de versions sur la machine de développement ​28

​8.3.2.1.1​ Story ​28

​8.3.2.1.2​ Tests d’acceptation ​28

Thierry Auberson 9 / 160

​8.3.2.2.1​ Story ​28

​8.3.2.2.2​ Tests d’acceptation ​28

​8.4​ Rappel des User Stories ​29

​8.4.1​ Gestion des produits ​29

​8.4.1.1​ Gérer les composants ​29

​8.4.1.1.1​ Story ​29

​8.4.1.1.2​ Tests d’acceptation ​29

​8.4.1.2​ Gérer les articles ​29

​8.4.1.2.1​ Story ​29

​8.4.1.2.2​ Tests d’acceptation ​29

​8.4.2​ Gestion des clients ​30

​8.4.2.1​ Gérer les comptes clients ​30

​8.4.2.1.1​ Story ​30

En premier lieu, je remercie Monsieur Eric Peguiron, propriétaire de l’entreprise d’accueil

Je remercie Monsieur Nicolas Glassey, enseignant en informatique au Centre professionnel du

4 Table des matières 9

5 Introduction 17

6 Pré-requis de lecture 19

7 Présentation de l’entreprise 21

7.1 Historique de l’entreprise 21

7.2 Succès de l’entreprise 22

7.3 Organisation 22

7.4 Activités 23

8 Cahier des charges 25

8.1 Rappel des spécifications fonctionnelles 25

8.2 Rappel des spécifications techniques 25

8.2.1 L’infrastructure matérielle 26

8.2.2 La sauvegarde et la restauration du système 27

8.3 Rappel des Technical Stories 27

8.3.1 Mise en place du serveur 27

8.3.1.1 Installer le serveur web 27

8.3.1.1.1 Story 27

8.3.1.1.2 Tests d’acceptation 27

8.3.1.2 Installer l’application sur le serveur web 28

8.3.1.2.1 Story 28

8.3.1.2.2 Tests d’acceptation 28

8.3.2 Mise en place de l’outil de gestion de versions 28

8.3.2.1 Configurer l’outil de gestion de versions sur la machine de développement 28

8.3.2.1.1 Story 28

8.3.2.1.2 Tests d’acceptation 28

8.3.2.2.1 Story 28

8.3.2.2.2 Tests d’acceptation 28

8.4 Rappel des User Stories 29

8.4.1 Gestion des produits 29

8.4.1.1 Gérer les composants 29

8.4.1.1.1 Story 29

8.4.1.1.2 Tests d’acceptation 29

8.4.1.2 Gérer les articles 29

8.4.1.2.1 Story 29

8.4.1.2.2 Tests d’acceptation 29

8.4.2 Gestion des clients 30

8.4.2.1 Gérer les comptes clients 30

8.4.2.1.1 Story 30

8.4.2.1.2 Tests d’acceptation 30

8.4.2.2 Gérer les contacts 30

8.4.2.2.1 Story 30

8.4.2.2.2 Tests d’acceptation 30

8.4.3 Gestion des commandes 31

8.4.3.1 Gérer les commandes clients 31

8.4.3.1.1 Story 31

8.4.3.1.2 Tests d’acceptation 31

8.4.3.2 Imprimer les commandes clients 31

8.4.3.2.1 Story 31

8.4.3.2.2 Tests d’acceptation 31

8.4.3.3 Gérer les commandes fournisseurs 32

8.4.3.3.1 Story 32

8.4.3.3.2 Tests d’acceptation 32

8.4.3.4 Historiser les commandes clients 32

8.4.3.4.1 Story 32

8.4.3.4.2 Tests d’acceptation 32

8.4.4.1 Sauvegarder les données de la base de données 32

8.4.4.1.1 Story 32

8.4.4.1.2 Tests d’acceptation 32

8.5 Nouvelle(s) User Story ajoutée(s) en cours d’implémentation 33

8.5.1 Gestion des commandes clients 33

8.5.1.1 Imprimer les commandes clients 33

8.5.1.1.1 Story 33

8.5.1.1.2 Tests d’acceptation 33

9 Démarche de projet 35

9.1 Méthode Agile 35

9.2 Le framework Scrum 35

9.3 La planification du projet 37

9.4 Différences par rapport à la planification 37

10 Les outils et technologies utilisés 39

10.1 Le serveur d’application RASPBERRY 39

10.2 Le système d’exploitation RASPBIAN 40

10.3 Le serveur HTTP Apache 2 40

10.4 Le langage de programmation PHP 41

10.5 Le langage de programmation JavaScript 41

10.6 La base de données MariaDB 41

10.7 Le schéma Apache-PHP-MariaDB 42

10.8 L’outil de gestion de versions Git 42

10.9 Le service Web d’hébergement de dépôt Bitbucket 44