Atlantis Montaza Rapport de Stage EMPI Groupe 12

Atlantis Montaza
Rapport de Stage EMPI Groupe 12
Tuteur entreprise : Sylvie Nicol
Tuteur Ecole : Benoit Martineaux
Samuel Picquenot / Corentin Néau / Marc N’Kaoua / Amaury Ollagnier

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
Sommaire
Contexte............................................................................................................. 2
1. Présentation de l´entreprise ........................................................................ 2
2. Cahier des charges ...................................................................................... 3
I. La gestion du projet ......................................................................................... 4
1. La mise au point .......................................................................................... 5
2. La réalisation ............................................................................................... 8
3. La vérification .............................................................................................. 9
II. Structure et organisation du logiciel ............................................................. 10
1. Structure des classes ................................................................................. 10
2. Structure de la Base de Données ............................................................... 10
3. Organisation du logiciel ............................................................................. 11
III. Aperçu du logiciel ........................................................................................ 12
1. Principales fonctionnalités ........................................................................ 12
2. Sauvegardes et Sécurité ............................................................................ 14
3. Divers scenarii possibles et méthodes utilisées pour la restauration ......... 17
V. Bilan Conclusion ........................................................................................... 19
1. Du point de vue du groupe ........................................................................ 19
2. Du point de vue de l´entreprise ................................................................. 22
ANNEXES .......................................................................................................... 24
Organigramme de l’entreprise ...................................................................... 24
1

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
1. Présentation de l´entreprise
Contexte
Atlantis Montaza est une entreprise de fabrication et de pose de tuyauterie industrielle.
Créée en 2005, cette PME opère principalement dans le secteur naval, mais également dans le
bâtiment, les constructions industrielles et la sécurité incendie.
Depuis sa création, l'entreprise connaît une
croissance importante et est dans une phase
d'expansion. Son chiffre d'affaires est passé
de 450.000 € à 1.390.000 € et l'effectif de 6 à
29 employés. Elle a construit un atelier de
fabrication en 2009 et a déménagé ses
bureaux début 2011 dans la zone industrielle
de Trignac aux alentours de Saint Naeaire. De plus Atlantis
Montaza est une entreprise de sous-traitance, milieu dans lequel la concurrence est très forte ;
c´est pourquoi pouvoir améliorer sa rapidité et sa compétitivité est crucial pour pouvoir être
pérenne dans son environnement.
Et dans cette optique de croissance, Atlantis Montaza a décidé d'automatiser une partie
des opérations administratives afin d'optimiser ses capacités de production et notre mission
entrait dans cette stratégie.
2

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
2. Cahier des charges
Lors de l'établissement d'un devis pour un chantier, l'entreprise doit évaluer le coût des
différentes pièces qu'elle aura à commander à ses fournisseurs. Établir le montant des
fournitures et comparer les prix sur chaque type de pièce demande la mobilisation de 40%
d'un temps plein et ralentit l'édition du devis, ce choix devant se faire par estimations sur
d'anciens devis ou demande des prix à chaque fournisseur.
Il nous a donc été demandé de créer une base de données permettant de modéliser ces
coûts et un logiciel utilisant cette base pour effectuer des comparatifs de prix. Ce logiciel doit
permettre à Atlantis Montaza de comparer les tarifs de ses fournisseurs, et ainsi d'établir plus
rapidement les montants de ses achats, ceux-ci devant être aussi avantageux que possible.
Un premier logiciel avait déjà été créé mais contenait trop de bugs et problèmes
d'implémentation qui le rendaient inutilisable. Nous avions le choix de reprendre ce logiciel
ou de créer le nôtre entièrement, et nous avons choisi la seconde option.
3

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
I. La gestion du projet
Avant le début du stage, nous avons pris connaissance du cahier des charges, et des
différentes tâches à effectuer. En vue du planning et du temps imparti pour la réalisation du
projet (10 jours, confer tableau ci-dessous), une bonne gestion du projet a été indispensable.
Nous allons donc vous présenter dans cette partie les différents outils que nous avons utilisés
et que nous avons créé pour la gestion du ce projet
La première étape, dès le lancement du projet, a été de lister toutes les tâches à
effectuer. Chacune de ces tâches s’intègre dans un processus continu de développement
articulé entre trois grandes parties : la mise au point, la réalisation, la vérification :
Réalisati
on
Mise au
point
Vérification
4

Mise au
point
Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
1. La mise au point
1°) Durant la phase de mise au point du projet, nous avons rencontré nos
clients, à savoir l’entreprise Atlantis Montaza, 20 jours avant le début du
projet, pour nous préciser le cahier des charges. Cette réunion nous a été
très bénéfique pour orienter notre travail dans la bonne direction.
À la fin de cet entretien, nous avions toutes les cartes en main pour débuter la conception du
logiciel demandé.
2°) Nous avons donc décidé de séparer le projet en trois parties distinctes.
Chacun des membres du groupe a été affecté à une de ces parties pour la totalité du stage :
Corentin Néau s’est occupé de la gestion de la base de données.
Amaury Ollagnier a développé le modèle, interprète entre l’interface et la base de
données.
Marc N’Kaoua ainsi que Samuel Picquenot se sont occupés eux plutôt de l’interface
du logiciel.
5

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
3°) Des recherches étaient aussi nécessaires pour faire communiquer les différentes
parties du programme entre elles. En effet le langage pour gérer la base de données, le SQL,
est un langage très différent de celui pour la réalisation du modèle ainsi que pour l’interface.
4°) En parallèle, nous avons réfléchi tous ensemble à différentes caractéristiques du
logiciel. Tout d’abord pour l’architecture globale de notre code à travers un diagramme de
modélisation UML (Unified Modeling Language) disponible en annexe. Nous avons ensuite
réalisé des plans de l'apparence désirée de l’interface du logiciel afin d’améliorer l’ergonomie
du notre logiciel.
5°) Par ailleurs, il nous fallait capitaliser sur le projet réalisé par nos prédécesseurs.
Nous avons donc étudié leur travail pour en cibler les principaux points forts et faibles et ainsi
concevoir un logiciel disposant des mêmes avantages mais comblant ses inconvénients.
6°) Nous avons réalisé aussi dès le premier jour un planning de prévision pour chacun
des membres du groupe :
6

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
7

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
2. La réalisation
Réalisation
parler.
Une fois la phase de mise au point terminée, nous savions que
des détails d’ordre technique ou organisationnel seraient de toute
façon à revoir au cours de notre avancée. Cependant, nous avions
assez de données pour commencer le développement à proprement
Les trois parties du programme ont pu être développées presque simultanément. Une des
principales difficultés de cette phase de développement résidait dans la nécessité de les
articuler au mieux.
C’est pourquoi nous avons mis en place un serveur SVN, système de gestion de
versions qui nous a permis de travailler en synchronisation permanente au sein du groupe.
Chaque membre du groupe profitait en permanence des dernières avancées du code des autres
les différentes couches logicielles.
membres, même si nous travaillions
tous sur des ordinateurs différents.
Grâce à cet outil, nous avons gagné
du temps dans le développement des interactions entre
Nous avons donc grâce à cet outil réalisé les trois différentes parties du programme. Il
a fallu de plus gérer toutes les interactions entre ces différentes parties une des tâche qui nous
a pris le plus de ressources niveau temps.
Pour donner un ordre d’idée, notre code fait aux alentours de 10 000 lignes de code.
Enfin la dernière partie concernant la partie optimisation du programme avec
l'affichage des meilleurs prix, l’affichage de l’évolution des prix pour chacun des fournisseurs.
8

Vérification
Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
3. La vérification
Enfin la dernière partie du planning lié à la vérification de la
fonctionnalité de notre programme.
Nous avons dans un premier temps du mettre en place un système
de sauvegarde sur le réseau, plus détaillé dans la suite du rapport
Nous avons eu aussi la chance de pouvoir discuter au cours du stage des
possibilités d’amélioration de développements complémentaires sur le
programme pour il soit le plus possible en adéquation avec les attentes de l’entreprise.
Enfin une vérification plus technique pour vérifier que toutes les fonctionnalités du logiciel
sont bien opérationnelles. Pour cela nous avons procédé à de nombreuses séries de test de
crash et déverminage du programme: grandeur nature, avec les utilisateurs finaux (clients).
9

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
II. Structure et organisation du
1. Structure des classes
logiciel
Pour que le programme soit plus simple à développer et accessible à des développeurs
tiers par la suite, nous l'avons structuré dès le début du projet. Nous avons pour cela utilisé
une représentation sous forme de diagramme UML (Unified Modeling Language), qui permet
de visualiser les liens entre les classes, c'est-à-dire entre les différents fichiers texte dans
lesquels nous écrivons pour réaliser le programme, et entre les objets qu'ils représentent
(clients, fournisseurs, pièces, etc...).
Ce diagramme est présent dans l'annexe.
2. Structure de la Base de Données
La base de données, socle du programme, devait elle aussi être lisible facilement pour
permettre à tous les membres du groupe de comprendre facilement comment sont articulées
les différentes tables et les liens présents entre elles.
Pour ceci, nous avons mis au point le diagramme suivant :
10

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
3. Organisation du logiciel
Nous avons donc choisi de développer notre logiciel sur un modèle en trois couches, décrites
sur le schéma ci-dessous
- La première couche permet de manipuler la base de données, de type MySQL, à partir du
langage Java dans lequel est développé le reste du logiciel. Ainsi, un pilote permet d’exécuter
des requêtes sur la base de données à partir de Java ;
- Une partie intermédiaire est celle du modèle, qui fait le lien entre les requêtes sur la base de
données et les objets Java qui sont manipulés par le logiciel à partir de ces requêtes ;
-Enfin, la dernière couche est la seule visible par l’utilisateur final, c’est l’Interface Homme-
Machine, qui produit les éléments graphiques tels que des fenêtres, onglets, boutons et autres
dialogues dont l’utilisateur se sert pour créer, supprimer ou modifier des objets du modèle.
11

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
III. Aperçu du logiciel
1. Principales fonctionnalités
Nous avons décidé de séparer le logiciel en trois grandes catégories, organisées sous
formes d'onglets. Cette organisation permet de passer aisément d'une catégorie à l'autre sans
risquer de perdre son travail, et de ne pas se perdre dans les fonctionnalités ainsi que tous les
types de données à entrer.
Ces catégories sont elles-mêmes divisées en onglets ; la catégorie « édition », qui
permet de consulter et d'éditer les données de la base, est donc répartie en quatre onglets :
Fournisseur, Pièce, Client et Chantier.
Il est possible pour chacun d'ajouter ou supprimer des éléments et de modifier les
données. Il existe des relations de dépendance entre ces catégories, et le logiciel permet de les
mettre en évidence :
les fournisseurs proposent chacun une liste de pièce, à un prix fixé ;
les chantiers sur lesquels l'entreprise opère sont liés à des clients ;
les commandes passées sont faites à un fournisseur donné, pour un chantier précis.
Exemple d'onglet : l'onglet Clients
12

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
La catégorie "étude" permet de manipuler les données entrées pour apporter une aide
non négligeable dans l'exercice de la comptabilité.
Le premier onglet permet d'établir la liste des commandes passées. Ces commandes
référencent le fournisseur, le chantier pour lequel elles sont passées et le détail des pièces
commandées. Il est possible de filtrer ces commandes pour affiner les recherches.
Le second onglet permet de comparer les différents prix pour une même pièce. Il suffit
d'entrer un nombre de pièces à commander et de choisir la pièce pour que tous les
fournisseurs la proposant s'affichent, permettant ainsi de comparer les prix de chacun. Cet
onglet est très important, car établir des devis nécessitait auparavant d'appeler les fournisseurs
afin de trouver la commande la moins coûteuse, ce qui prenait beaucoup de temps. Cet onglet
permet au contraire de trouver le fournisseur le plus avantageux bien plus rapidement et
d'établir un devis plus vite.
Le dernier onglet, quant à lui, permet de générer un graphe montrant l'évolution des
prix suivant les fournisseurs, à compter de juin 2011. Cela permettrait, en cas de hausse des
prix de matières premières, de justifier au client une hausse des prix.
La dernière catégorie est consacrée à la sauvegarde des données; on peut y effectuer
des sauvegardes manuelles de la base de données ou importer des données en cas de
problème.
L'organisation en onglets permet d'implémenter un grand nombre de types de données
et de fonctionnalités tout en gardant un logiciel clair et structuré. Il peut permet de plus un
développement facile de modules complémentaires ultérieurs, qui pourront se greffer
directement sur le logiciel existant.
Le logiciel et l'édition de données sont clairs et intuitifs et ont été très bien accueillis
par le personnel de l'entreprise. La seule étape qui ait posé des difficultés techniques a été
l'installation du programme sur les ordinateurs d'Atlantis Montaza, mais nous étions présents
et avons pu les assister. La démarche est de plus détaillée dans le manuel d'utilisation (en
annexe).
13

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
2. Sauvegardes et Sécurité
1.1/ La base de donnée :
Dans le cadre de notre réalisation, nous avions à choisir un système de base de
données. SQL a été retenu de par ses nombreux apports. En effet, le langage de base de
données SQL est très rependu et reconnu dans le stockage de données.
De plus, pendant notre parcours d’étudiant ingénieur à l’Ecole des Mines de Nantes,
nous avons étudié ce langage. Ensuite, nous avons choisi le serveur MySQL fourni dans le
pack EasyPHP car il est livré avec des outils de gestion, comme PhpMyAdmin, qui sont très
pratiques lors de la réalisation de notre programme.
La base de données est organisée par des relations entre les différentes tables
comportant les données. Ce système de liaisons est une nécessité dans notre programme. Avec
la gestion des utilisateurs par un système de droits, ainsi que des sauvegardes facilement
réalisables, le support de cette base de données est complet. La facilité d’installation et
d’utilisation du pack nous a aussi encouragés à l’utiliser.
1.2/ Le format de sauvegarde :
De par le serveur SQL, les fichiers de sauvegarde sont des fichiers au format .sql.
Ceux-ci sont au format texte codé en ASCII et sont très flexibles et facilement modifiables.
De plus, le langage utilisé à l’intérieur est le même que celui du serveur, soit le SQL. Ainsi, il
n’y a pas de fichier binaire ou crypté qui peuvent présenter des difficultés d’import ou
d’autres standards nécessitants des logiciels tiers.
Les fichiers .sql sauvegardent la base de données en listant toutes les commandes SQL
nécessaires à la reconstruction de la base de données complète. Lors d’un export, un utilitaire
de MySQL nous fournit le fichier complet de sauvegarde comportant toutes les informations
de la base qu’elles représentent la structure des tables ou les données. En outre, lors d’un
import, le serveur MySQL va exécuter l’ensemble des requêtes SQL présente dans le fichier
de sauvegarde pour restaurer totalement une version de la base.
14

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
1.3/ Les détails des sauvegardes :
A ce moment, nous avons décidé d’utiliser ce type de sauvegarde (intégralité de la
base dans un fichier unique) pour avoir une gestion plus flexible de nos fichiers .sql. Nous
utiliserons la date et l’heure de sauvegarde comme nom de fichier afin de connaître quelle
sauvegarde est la plus récente. En effet, un seul fichier suffit à restaurer la totalité des données.
Même s’il comporte l’intégralité de la base, ce fichier reste relativement léger, il devrait faire
moins de 20 Mo. Il suffit donc de ne garder que le fichier le plus récent comme sauvegarde.
Cependant, si l’on garde en mémoire la totalité des mises à jour, les nombreuses sauvegardes
encombreraient les espaces de stockage dédiés.
C’est pour cela que nous avons décidé de garder un nombre fixe de mises à jour fixé à
10 pour, dans un premier temps avoir plusieurs sauvegardes en cas d’erreur de saisie, et, dans
un deuxième temps, de ne pas être submergé par ses nombreuses sauvegardes.
Nous devions aussi nous accorder sur la fréquence des sauvegardes, et, au vu du choix ci-
dessus d’un nombre limité de fichiers de sauvegarde, nous avons choisi de faire une
sauvegarde à chaque modification des données. Cette décision a été prise pour conserver un
maximum de mise à jour et de n’avoir que très peu de manipulations à refaire lors d’un
problème.
De plus, une fonctionnalité de sauvegarde manuelle a été mise en place dans le
programme. Elle permet d’exporter la base de données dans un répertoire spécifié pour une
utilisation extérieure ou simplement une sauvegarde complémentaire. L’utilisateur a le choix
du moment de la sauvegarde ainsi que du dossier de destination du fichier .sql.
La restauration d’un fichier de sauvegarde est tout aussi simple. Un fichier initialisation.sql
compte l’installation de base des tables. Les données sont importables via le programme en
utilisant le bouton « importer ». Le programme va donc exécuter les différentes lignes du
fichier de sauvegarde afin de réinitialiser la base.
15

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
2/ Placement physique des sauvegardes :
2.1/ Le poste principal (poste de Cynthia) :
Le poste principal est le poste d’utilisation du programme, il compte la base de
données via le serveur MySQL ainsi qu’un serveur de sauvegarde détaillé plus loin.
L’utilisation d’un seul poste pour la base de données ainsi que les nombreux utilitaires permet
d’éviter d’encombrer les autres postes avec un surplus de programmes. La base de données
étant en local, l’accès aux données est plus rapide et plus sécurisé.
Ce poste comporte deux supports de sauvegarde. Le premier est la base de donnée
MySQL qui compote en permanence la dernière version des données du programme. Un
support de sauvegarde externe est aussi utilisé afin de conserver la base de données même lors
d’un plantage ou d’une détérioration de l’ordinateur. Cet espace de sauvegarde est une clé usb
16

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
branché sur ce PC sur laquelle sont sauvegardées toutes les mises à jour de la base de données
en temps réel.
2.2/ Les autres postes du réseau :
De plus, chacun des autres postes du réseau peuvent servir d’utilitaire de sauvegarde
via le réseau. En effet, grâce aux connexions LAN et à un utilitaire de sauvegarde lancé sur
ces autres postes, le programme principal envoie les mises à jour à travers le réseau à tous les
postes lançant l’utilitaire. Ainsi, les fichiers de sauvegarde sont copiés localement dans le
disque dur de chacun des postes annexes.
Le programme utilitaire fonctionne en arrière-plan afin de ne pas interférer avec
l’utilisation première de ces postes. Cette sauvegarde supplémentaire peut être très utile si la
clé du poste principal n’est pas branchée et que le disque dur de ce même poste meurt. Ainsi,
il suffit d’une des deux méthodes de sauvegarde pour éviter de perdre l’intégralité des
données.
3. Divers scenarii possibles et méthodes utilisées pour la
restauration
3.1/ Utilisation normale du programme :
L’utilisateur peut spécifier le dossier de sauvegarde sur clé usb au démarrage du
programme. Le programme de gestion du réseau va être lancé afin de gérer les postes annexes
et leur transmettre les différentes mises à jour.
Ces deux dispositifs vont sauvegarder les données dans des fichiers .sql avec la date
en nom de fichier. Lors de l’utilisation « normale » et fonctionnelle du programme, la base de
donnée est sauvegardée à chaque mise à jour d’informations. On peut aussi sauvegarder les
données manuellement dans le répertoire désiré.
17

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
3.2/ Si le programme plante :
La base de données étant indépendante du programme, celle-ci n’a pas planté et est
accessible lors d’un redémarrage simple du programme. La dernière version de la base sera
celle avant la dernière mise à jour faite. Il y aura donc qu’une opération à réitérer. Si le
problème persiste, il faut réinstaller le programme et importer les données d’une date
souhaitée grâce au manuel d’utilisation.
3.3/ Si le disque dur du poste principal meurt :
Il faut réinstaller le programme sur le nouveau poste principal ou le nouveau disque
dur du poste principal en suivant les instructions du manuel d’utilisation. En important un
fichier de sauvegarde d’une certaine date, les données relatives seront restaurées (choisir
notamment une des sauvegarde de la clé usb ou dans les autres postes du réseau).
3.4/ Si la clé usb meurt ou si tout autre poste a un problème :
Dans cette situation, il n’y a aucune répercussion sur notre logiciel du poste principal.
Il faut cependant s’assurer qu’un ou plusieurs systèmes de sauvegarde est toujours présent
comme une nouvelle clé usb branchée ou d’autres postes faisant fonctionner l’utilitaire de
sauvegarde en arrière-plan, facilement installable depuis la clé d’installation.
3.5/ S’il y a une erreur de saisie majeure :
Une ancienne version de la base de donnée peut facilement être retrouvable et mise en
place grâce à un import d’un fichier .sql avec la fonctionnalité du programme. La version
relative à ce fichier de sauvegarde va être réinitialisée.
18

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
1. Du point de vue du groupe
V. Bilan Conclusion
Ce stage a été très enrichissant pour nous et nous a offert une expérience très différente de
celle du stage opérateur. Là où le stage opérateur nous permettait de découvrir le
fonctionnement de l'entreprise, les conditions de travail de la production et nous offrait un
contact avec les salariés, ce stage EMPI nous a placés au niveau décisionnel, où nous avons
dû effectuer une tâche susceptible d'orienter les choix stratégiques de l'entreprise.
Parmi les apports que la mission nous a apportés nous avons pu identifier quatre
grandes catégories: compétences techniques, travail de groupe, gestion de projet et exigences
du travail en entreprise.
Compétences techniques
Tout d'abord, ce projet nous a apporté de solides connaissances et compétences
techniques concernant :
-la gestion et la manipulation des bases de données : nous avions étudié le langage
SQL, qui permet cela, mais n'avions pas encore eu l'opportunité de mettre en œuvre ces
connaissances au sein d'un projet de cette ampleur. Nous avons ici pu aborder notamment la
gestion des utilisateurs et des droits sur une base de données ;
-la communication entre une base de données MySQL et un programme développé en
langage Java. Ce point nous était totalement inconnu au début du projet. Après quelques
heures de recherches, nous avons trouvé un outil intégré au langage Java pour communiquer
avec des bases de données, et nous le sommes approprié.
-la création d'une architecture PAC (Présentation-Abstraction-Contrôle) permettant de
générer une interface graphique complète et évolutive pour notre logiciel. Nous avions abordé
ce point lors de nos cours, mais de façon moins poussée et sur des projets à plus petite échelle.
19

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
Pour les besoins de création de cette interface, nous nous sommes fait un devoir de réfléchir
tous ensemble. En effet, il était capital de se mettre à la place de l'utilisateur final et de
récolter autant d'idées que possible pour concevoir un logiciel intuitif, facile à prendre en
main et à utiliser au quotidien même pour quelqu'un n'ayant pas de connaissances
particulières en informatique.
Cette démarche de prise de recul nous a permis de mieux répondre aux attentes non exprimées
de l'entreprise en lui présentant un logiciel utilisable dès son installation.
Nous avons pu voir que cette réflexion de notre part avait réussi. En effet, une employée
d'Atlantis Montaza a commencé à saisir avec aisance des clients et des chantiers dans le
logiciel alors qu'il était à peine installé et qu'elle n'en avait pas lu la notice.
-le développement d'un logiciel en équipe, rendu plus simple par l'utilisation de l'outil
SVN qui nous permettait de synchroniser le code entre les différents membres du groupe.
Travail en groupe
Outre la prise en main de cet outil très utilisé lors du développement de projets
informatiques à grande échelle, nous avons développé nos capacités de travail en équipe tout
au long de cette mission.
En effet, il n'aurait nullement été possible de mener ce projet à bien sans une bonne
communication et un soutien mutuel important au sein du groupe :
– chacun des membres avisait en permanence les autres des avancées réalisées dans son
domaine : base de données, modèle ou interface homme-machine. Grâce à cela, chacun savait
immédiatement lorsqu'une nouvelle fonctionnalité du programme en développement ou d'une
de ses composantes logicielles étaient disponibles. De fait, de nombreux tests pouvaient être
réalisés au fur et à mesure du développement pour en améliorer la fiabilité et la robustesse.
– lorsqu'un membre du groupe rencontrait des difficultés, les autres étaient toujours
présents pour lui apporter leur soutien moral et/ou leur savoir-faire pour surmonter les
obstacles. Il régnait ainsi une très bonne cohésion au sein du groupe.
20

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
Gestion de projet
Notre progression a en outre été facilitée par une très bonne gestion de projet.
Le planning prévisionnel a permis d'avoir une visibilité optimale sur l'ensemble des procédés
de conception, développement et vérification du logiciel, et ce dès le lancement de la mission.
Par ailleurs, nous avons pu nous organiser sur la base d'un planning de présence dans
les locaux de l'entreprise, et ainsi déterminer les tâches prioritaires à réaliser et discernant
celles qui étaient réalisables à l'école de celles qui nécessitaient notre présence à Trignac.
Ensuite, grâce à la répartition des différentes parties du développement entre les membres de
l'équipe, chacun de nous a pu se concentrer sur un aspect particulier du logiciel pour ainsi en
maîtriser au mieux les caractéristiques.
Enfin, nous avons déterminé l'architecture du logiciel en la représentant sous forme
schématique, pour détecter au plus vite d'éventuels problèmes ou incohérences et donner à
chacun des équipiers la possibilité de repérer un fichier de travail dans la structure du
programme. De cette manière, la visibilité nécessaire à un développement efficace arrivait
rapidement.
Exigences du travail en entreprise
Ce travail demandé diffère d'un projet de l'école dans le sens où un résultat répondant
à de réels besoins était attendu. Lors d'un projet d'école, des résultats sont bien sûr demandés
mais ils reflètent uniquement notre investissement dans le projet et nos compétences
techniques acquises au cours de la formation.
Durant ce stage, le projet que nous avons mené à bien répondait d'un réel besoin de la
part de l'entreprise. Il doit servir de base de travail et d'outil décisionnel important au sein
d'Atlantis Montaza, et lui apporter un atout face à ses concurrents. Il peut aussi
éventuellement être complété de nouvelles fonctionnalités dans le futur pour répondre à de
nouveaux besoins qui seraient formulés.
Ce facteur est très motivant par rapport à un projet de l'école et nous a poussés à
travailler bien au-delà des horaires impartis afin de le mener à bien. Il nous a également donné
une pression supplémentaire quant à la nécessité de finir le logiciel. De plus nous avons été
très contents de nous même lorsque nous l'avons vu fonctionner.
21

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
Cela n'était pourtant pas évident: dans les projets informatiques que nous avons
effectué plus tôt dans nos études, un petit dysfonctionnement ne remettait pas en cause notre
compréhension du programme et pouvait être toléré. Ici, la moindre erreur, d'entrées de
données par exemple, empêche l'écriture de données dans la base et rend caduc la quasi-
totalité du logiciel. Nous avons donc dû faire très attention à ce que le logiciel soit
opérationnel et ne contienne pas de problèmes de ce genre.
Un point important des besoins de l'entreprise, qui peut paraître évident aux yeux des
personnes travaillant en milieu professionnel mais qui ne saute pas à nos yeux d'ingénieur, est
la sécurité que nécessite un tel logiciel. En effet, il est indispensable que l'entreprise soit sûre
que ses données ne soient pas perdues, et suite aux recommandations de notre tuteur école
nous avons fait en sorte de réduire ce risque au minimum. Les données entrées sont de plus
confidentielles et ne doivent pas être récupérées par une personne extérieure à la société, c'est
pourquoi nous avons fait fonctionner le logiciel sur réseau local.
Il nous a fallu de plus communiquer avec le personnel afin de connaître au mieux leurs
besoins; nous avons ainsi modifié le projet plusieurs fois, de manière à répondre à leurs
besoins; ainsi, l'onglet "évolution des prix" n'était pas présent dans notre projet initial, mais
nous l'avons ajouté quand il nous a été demandé de le faire.
2. Du point de vue de l´entreprise
Grâce au logiciel, l'entreprise a estimé que le temps d'établissement d'un devis pourrait
passer de 0,4 temps plein à 0,1 temps plein. En se basant sur le coût annuel d'un SMIC et en
incluant les charges patronales, le gain de 0,3 temps plein en termes de salaire ferait donc
économiser un peu plus de 7000€ par an à l'entreprise; ce temps pourra être investi dans
d'autres tâches à accomplir étant donné le faible nombre d'employés administratifs (2
personnes).
De plus, comme le logiciel est intuitif et permet une prise en main rapide, la maîtrise
du logiciel pourra être rapide et permettra d'optimiser le temps d'utilisation.
22

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
Cependant, le principal atout du logiciel est de faire gagner un temps considérable
dans l'établissement des devis, ce qui procure à l'entreprise un atout considérable par rapport à
ses concurrents. La rapidité de réponse peut en effet constituer un facteur important dans le
choix d'un client pour son fournisseur et cela pourra peser dans la balance en faveur d'Atlantis
Montaza, ce qui lui permettra d'obtenir plus de chantiers par rapport à ses concurrents
qu'auparavant.
Ce logiciel entre également dans la politique d'automatisation des commandes de
l'entreprise, ce qui lui permet d'être globalement plus performante. Dans la même veine, il
nous a été demandé en complément d'améliorer un logiciel de répartition des tâches de
production. Il fallait auparavant, en fonction des capacités de production journalières, entrer
manuellement la répartition des tâches à effectuer en production. Nous avons automatisé cette
tâche, qui a donc réparti la production en fonction des dates de début et de fin de chaque
commande et du temps qu'elle demandait, ce qui répartit les commandes de manière
automatique et évite de passer un temps considérable à établir les plannings.
23

Ollagnier Amaury / N’Kaoua Marc / Picquenot Samuel / Néau Corentin
Organigramme de l’entreprise
ANNEXES
24