1

Rapport de stage Bachelor 2ème année Rapport de stage de deuxième année. GODIER Victor 5 Janvier 2015 – 13 Février 2015

2

REMERCIEMENTS

Je tiens à remercier M. Jean-Yves GAYET, Président de l’AVF de m’avoir accueilli en stage de

deuxième année de BTS SIO durant 6 semaines et d’avoir été mon tuteur durant cette période de

stage.

M. Frédéric REINOLD & Mme Emmanuelle BORDAT pour leur soutien très précieux dans la

réalisation du projet réalisé durant ce stage.

Et enfin M. Dylan BLANCHARD, également stagiaire, qui a été mon co-équipier durant toute

cette période.

3

Sommaire Introduction ............................................................................................................................................. 5

I. Présentation de l’environnement et du Projet ............................................................................... 6

A. Mise en place du projet ............................................................................................................... 6

1. Données de l’AVF .................................................................................................................... 6

2. Système de fonctionnement ................................................................................................... 6

3. Cahier des charges ................................................................................................................... 6

B. Etudes préliminaires .................................................................................................................... 7

1. Etude de l’environnement ....................................................................................................... 7

2. Etude de solutions techniques ................................................................................................ 7

II. Rédaction des spécifications techniques ........................................................................................ 8

A. Identification des fonctionnalités du logiciel .............................................................................. 8

B. Cas d’utilisations .......................................................................................................................... 9

C. UML ........................................................................................................................................... 10

D. Interfaces Homme/Machine ..................................................................................................... 10

III. Mise en place de l’infrastructure .............................................................................................. 13

A. Adaptation de l’environnement informatique .......................................................................... 13

B. Installation du serveur ............................................................................................................... 13

1. Installation des composants logiciels .................................................................................... 13

2. Création de la Base De Données ........................................................................................... 13

3. Mise en place d’un script de sauvegarde .............................................................................. 13

C. Rédaction d’une documentation technique ............................................................................. 13

IV. Développement de l’application ............................................................................................... 14

A. Définition des priorités .............................................................................................................. 14

B. Développement du composant logiciel ..................................................................................... 14

C. Difficultés et retard sur le projet ............................................................................................... 14

4

D. Tests des fonctionnalités ........................................................................................................... 15

V. Déploiement de l’application ........................................................................................................ 15

A. Installation de l’application ....................................................................................................... 15

B. Rédaction d’une documentation d’utilisation ........................................................................... 15

C. Accompagnement dans la mise en place et l’utilisation du service .......................................... 15

Conclusion ............................................................................................................................................. 16

5

Introduction

L’Association Villes de France de Nantes est l’une des 300 associations bénévoles homonymes réparties dans toute la France. Son but est d’accueillir les nouveaux arrivants d’une ville et de leur proposer diverses activités pour se familiariser avec leur nouvel environnement et rencontrer d’autres Nantais.

Afin de moderniser son fonctionnement, notamment dans la gestion de ses adhérents et des activités qu’elle propose, l’AVF de Nantes a décidé d’informatiser toute son administration.

Mon travail dans ce stage, avec l’aide de Mr Dylan BLANCHARD, était de mettre en place une application répondant au cahier des charges préalablement préparé par un membre de l’association.

Sur ce projet, bien que nous ayons travaillé sur les mêmes tâches, Mr Dylan BLANCHARD avait la charge du réseau et de son infrastructure, alors que j’avais la charge du développement.

6

I. Présentation de l’environnement et du Projet

Le rôle principal d’un système d’information est de permettre la transmission d’informations

et l’accès aux données de façon efficiente. L’association ayant reçu de nouveaux équipements

informatiques quelques mois avant le début de notre stage, notre objectif était de mettre en place

une application permettant de gérer les informations de l’AVF et pouvant fonctionner sur plusieurs

ordinateurs en même temps.

A. Mise en place du projet

1. Données de l’AVF

L’AVF de Nantes existe depuis 1966, et détient donc des archives très conséquentes sur ses

adhérents (350 adhérents inscrits, et environ 800 personnes au total se sont inscrit à l’AVF Nantes) :

coordonnées, intérêt pour certaines activités, historique des activités auxquelles ils ont participé,

etc…

2. Système de fonctionnement

Les informations de ces membres sont réparties sur plusieurs supports :

Les informations personnelles, comme les coordonnées et les activités auxquelles un

adhérent souhaiterait participer, sont inscrites sur sa fiche d’inscription.

Les historiques de participation aux activités sont répartis sur différentes fiches de présences,

et il est souvent difficile de retrouver ces informations.

Pour finir, les paiements des activités sont écrits sur un cahier, puis reportés sur un logiciel de

comptabilité.

3. Cahier des charges

Un des adhérents de l’association a écrit un cahier des charges pour l’AVF regroupant tous les besoins de celle-ci, et ce qu’elle souhaite comme type d’application. Afin d’optimiser au mieux notre travail nous avons dû revoir ce cahier des charges avec les dirigeants de l’association. En effet, nous nous sommes aperçus que certains besoins n’avaient pas été recensés alors qu’ils constituaient un objectif principal. Ce qui a considérablement alourdi le projet.

7

B. Etudes préliminaires

1. Etude de l’environnement

L’informatisation de l’association étant très récente, le réseau de l’association était très peu

développé : 3 ordinateurs sous Windows 8, 2 imprimantes, 1 routeur du fournisseur d’accès à internet

de l’association, 1 commutateur relié au routeur et à tous les pc via des prises murales.

Nous étions donc relativement libres pour modifier le réseau. Parmi les besoins du cahier des

charges, il était spécifié que les utilisateurs du logiciel devaient pouvoir travailler de plusieurs

ordinateurs différents et en même temps, ce qui nous a amené à rédiger une étude des différentes

solutions techniques que nous pouvions mettre en place.

2. Etude de solutions techniques

Au vu du cahier des charges et afin de répondre au mieux aux besoins de l’association, j’ai

décidé, avec la consultation de mon co-équipier, que nous développerions une application web en

PHP.

Pour cela, nous allions avoir besoin d’une base de données et d’un serveur apache. Après

diverses recherches sur internet et après consultation de l’informaticien de l’association, Mr

BLANCHARD a rédigé un tableau regroupant les avantages et inconvénients des différentes solutions

d’infrastructures possibles, ainsi que leurs coûts financiers pour l’association.

Les solutions potentielles étaient :

8

Après réunion avec les dirigeants de l’association et leur informaticien, nous avons décidé

d’opter pour la solution du serveur Debian.

II. Rédaction des spécifications techniques

A. Identification des fonctionnalités du logiciel

Nous avons identifié quatre grandes parties dans l’application :

- La gestion des Adhérents : Gérer les informations des adhérents et leur adhésion par années.

- La gestion des Activités : Gérer les informations des activités et les inscriptions des

adhérents.

- La gestion de la comptabilité : Répertorier les achats de tickets et les forfaits qui permettent

l’accès aux activités, ainsi que les cotisations de début d’année permettant d’adhérer à

l’association.

- La gestion des comptes utilisateurs : Gérer les comptes utilisateurs, c’est-à-dire le personnel

et leur accès aux différentes parties du site.

9

B. Cas d’utilisations

A partir de ces constats, nous avons pu établir les cas d’utilisations liés à l’application.

10

C. UML

Nous avons ensuite rédigé le diagramme de classe UML en prenant soin de laisser la

possibilité d’améliorer le logiciel simplement dans le futur.

D. Interfaces Homme/Machine

Page d’accueil

Le menu en gris permet de naviguer dans les différentes parties du site. La page d’accueil

permet aux administrateurs de l’application de faire passer un message aux utilisateurs.

11

Page d’accueil de la partie Adhérent

La page d’accueil des Adhérents permet d’avoir la liste de toutes les personnes inscrites à

l’association. Un sous menu apparait alors (un menu similaire est disponible dans chacune des autres

parties du site), permettant l’accès à d’autres fonctionnalités comme la gestion des groupes ou

l’accès aux archives des membres qui sont ou ont été adhérents à l’association.

A partir de cette page, il est possible de créer un nouveau membre grâce au menu, pour la

modification ou la suppression (en réalité c’est plutôt une clôture de l’adhésion d’un membre

puisque toute personne étant passée par l’association doit être gardée en archive) il faut cliquer sur

la ligne de l’adhérent.

12

Page d’affichage d’un adhérent

Dans cette partie du site, nous sommes à ce qu’on peut appeler le niveau 3, c’est-à-dire une

fonctionnalité dans une partie de l’application. Pour remonter dans les « niveaux », il suffit de cliquer

sur le logo de l’AVF en haut à gauche, ce qui ramène à la page d’accueil de l’application, ou

revenir/changer de niveau 2 grâce au menu principal.

Puisque nous sommes toujours dans la partie Adhérent, le sous menu de celle-ci est donc

toujours visible.

(Vous trouverez le document complet de modélisation dans les annexes)

13

III. Mise en place de l’infrastructure

A. Adaptation de l’environnement informatique

Dans le but de simplifier le réseau, nous avons décidé de configurer les ordinateurs fixes en

IP statique. N’ayant pas de routeurs à disposition, c’était la manière la plus simple pour que les

utilisateurs de la future application puissent accéder au serveur apache.

B. Installation du serveur

Une fois le serveur reçu, nous y avons ajouté un autre disque dur qui servira à stocker les sauvegardes de la base de données. Puis nous nous sommes attachés à son installation.

1. Installation des composants logiciels

Il fallait faire de ce serveur le serveur Web ainsi que le serveur de Base De Données. Pour cela

nous avons installé apache 2.4.12, ainsi que MariaD 10.0.

2. Création de la Base De Données

Pour la base de données, nous avons créé une nouvelle base au nom de l’association (avfbd),

ainsi qu’un utilisateur (avfuser).

Nous avons ensuite créé toutes les tables selon le schéma UML du dossier de spécification.

3. Mise en place d’un script de sauvegarde

Pour prévenir d’un problème de disque dur principal qui ferait perdre toute les données à

l’association, nous avons installé un second disque dur. Puis grâce à un script en .bash, Mr

BLANCHARD a programmé des sauvegardes récurrentes de la base de données.

Il y a dorénavant une sauvegarde tous les jours de la semaine, puis une sauvegarde

hebdomadaire le samedi et enfin une mensuelle, qui garde le premier samedi du mois.

C. Rédaction d’une documentation technique

Une fois le serveur installé et prêt à être utilisé, nous avons rédigé une documentation technique regroupant les caractéristiques du serveur, les modifications matérielles apportées, les logiciels installés et les identifiants correspondants.

(voir annexe pour le détail de la documentation technique)

14

IV. Développement de l’application

A. Définition des priorités

Constatant que la modélisation avait pris plus de temps que prévu à cause du cahier des

charges initial incomplet, nous avons décidé de diviser le développement en plusieurs étapes :

Etape 1 : Connexion à l’application et gestion des adhérents.

Etape 2 : Gestion des comptes pour l’application.

Etape 3 : Gestion des Activités.

Etape 4 : Gestion de la comptabilité.

B. Développement du composant logiciel

Afin de pouvoir travailler en toute sécurité et chacun de notre côté, nous avons monté une

réplique de la base de données MariaDB sur notre ordinateur portable respectif avec PHPMyAdmin.

Ceci nous a ainsi permis de travailler en local et de ne pas risquer de corrompre la base de données,

ou de la polluer avec des tests d’intégration.

Pour développer ce logiciel, nous avons utilisé les langages HTML5/CSS3 pour l’interface, le

PHP pour le langage procédural et le langage SQL pour les requêtes sur la base de données. Nous

avons développé avec l’IDE Netbeans 8.0.2.

Nous avons beaucoup utilisé les sites web :

http://www.sql.sh/

http://www.php.net/

http://www.openclassrooms.com/ Ces sites nous ont été très utiles lorsque nous avions besoin de compléments de formation sur les langages que nous avons utilisés.

C. Difficultés et retard sur le projet

Le temps passé sur la modélisation et les difficultés que nous avons rencontrées pour coder l’application nous ont fait prendre beaucoup de retard.

A la fin de la période de stage, nous n’avions toujours pas fini la première étape du développement. Nous avons donc décidé de revenir certains soirs de la semaine pour permettre de livrer une première partie fonctionnelle de l’application.

15

D. Tests des fonctionnalités

Les fonctionnalités de l’HTML5 nous ont beaucoup facilité la tâche. En effet, il est possible

d’ajouter beaucoup de contraintes aux formulaires, permettant ainsi d’éviter beaucoup d’erreurs par

la suite (exemple : rentrer un type string dans un champ de date).

Afin d’être sûr que le programme fonctionnait correctement, il fallait tester tous les champs

de saisie. Et une fois en place, il fallait essayer de rentrer des caractères spéciaux. Nous avons eu

beaucoup de problèmes à cause de l’apostrophe que nous avions oubliée lors des tests. En effet,

notre code étant mal organisé à certains endroits, les apostrophes empêchaient de faire fonctionner

nos requêtes SQL.

V. Déploiement de l’application

A. Installation de l’application

Une fois le développement de la première partie terminé, nous avons installé l’application

sur le serveur. Afin que la page de connexion soit index.php et non index.html, nous avons dû

modifier le fichier .htaccess d’apache en mettant la priorité de lecture sur index.php avant

index.html.

Puisqu’il n’y a pas de serveur DNS à l’AVF, il fallait rentrer l’adresse IP du serveur dans un

navigateur web afin d’accéder à l’application. Nous avons donc mis un raccourci sur le bureau de

chaque ordinateur, plus simple pour les utilisateurs de l’application.

B. Rédaction d’une documentation d’utilisation

Une fois le développement de l’application achevé, au moins pour la première partie, nous

avons rédigé une documentation d’utilisation.

A l’aide de captures d’écran, la documentation technique comporte des illustrations pour

toutes les fonctionnalités de l’application. Les utilisateurs du logiciel pouvant avoir des niveaux

techniques très différents, il fallait une documentation très complète et très précise, à la portée de

n’importe quel utilisateur.

C. Accompagnement dans la mise en place et l’utilisation du

service

Bien que les documentations d’utilisations aient été rédigées, il est toujours positif

d’organiser une session de formation pour les utilisateurs. Nous avons donc organisé un rendez-vous

avec le président et la vice-présidente de l’association pour être sûr que les utilisateurs n’auraient

pas de problème pour la prise en main du logiciel.

Cette session de formation a été très bénéfique, notamment pour relever certain bug du

logiciel. C’est en effet au cours de cet entretien que nous avons par exemple détecté l’oubli de la

gestion des apostrophes pour les requêtes SQL. J’ai donc dû par la suite corriger rapidement ce bug

avant que les utilisateurs du logiciel ne commencent à s’en servir.

16

Conclusion L’achat très rapide du serveur par l’association a été très bénéfique. Nous avons ainsi pu

mettre celui-ci en place et le suivre tout au long de notre stage mais également lors de nos retours à

l’association. Cela nous a permis entre autre de vérifier le bon fonctionnement du script de

sauvegarde de la base de données, élément essentiel du serveur.

Une fois le stage terminé, nous nous sommes rendu compte lors de nos cours de PHP

Symfony que l’application aurait été bien mieux structurée si nous avions utilisé ce Framework. Bien

que les fonctionnalités à implémenter soient assez différentes, certaines fonctions sont réutilisées à

plusieurs endroits et nous n’avons pas assez mis en application le principe de DRY (« Don’t Repeat

Yourself », en français : Ne vous répétez pas).

Le projet de ce stage n’étant pas terminé, des étudiants de première année reprendront le

projet que nous avons commencé. L’intérêt des documentations techniques et du dossier de

modélisation devient alors très important, tout comme des pages de code commentées.

Ce stage m’a été très bénéfique autant sur le fond que sur la forme. Le stage se déroulant

dans une association sans aide d’une équipe de professionnels (hormis nos professeurs que je

remercie encore), nous avons dû apprendre à surmonter les difficultés ensemble mon co-équipier et

moi-même. Nous étions alors dans la situation d’un prestataire externe à l’entreprise et c’est une

expérience qui aura sans aucun doute des répercussions dans ma vie professionnelle future.