master 1 miage bordeaux romain arnoux université … · master 1 miage bordeaux université...
TRANSCRIPT
Master 1 MIAGE Bordeaux Université Bordeaux 1
Romain Arnoux
Tuteur : M. Dussaux
Mémoire de stage de Master 1 MIAGE Stage réalisé à SIMOREP MICHELIN, Bassens Sous la direction de M. Sanchez et M. Labreize
Promotion 2007-2008
Master 1 MIAGE Bordeaux Université Bordeaux 1
Romain Arnoux
Tuteur : M. Dussaux
Mémoire de stage de Master 1 MIAGE Stage réalisé à SIMOREP MICHELIN Rue Edouard Michelin 33530 Bassens
Promotion 2007-2008
Remerciements
Je tiens à remercier :
• Monsieur Miguel Sanchez, Responsable N/TE et Responsable de mon stage, pour
m’avoir accordé sa confiance pour la réalisation de cet intéressant projet, mis à ma
disposition les moyens techniques nécessaires pour le réaliser et pour sa sympathie.
• Monsieur Jean-Pascal Labreize, mon maître de stage, pour les nombreux conseils qu’il
a pu me donner et tout ce qu’il a pu m’apprendre autant en gestion de projet qu’en
relations humaines ou sur le domaine de l’entreprise.
• Madame Nicole Guilhem, Messieurs Guy Gennaro et Laurent Castagnetti pour leur
disponibilité. Le temps passé à répondre à mes questions ou pour m’aider à résoudre
des problèmes.
• Tout le personnel Michelin que je n’ai pas cité grâce à qui j’ai pu m’intégrer
facilement et avec qui j’ai pu discuter à propos de nombreux sujets durant ces quatre
mois. Un clin d’œil particulier aux courageux béta-testeurs !!
• Monsieur Valère Dussaux, mon tuteur, pour ces conseils, encouragements et sa
disponibilité.
• Toute l'équipe administrative de la MIAGE pour leur aide, les informations sur les
stages et les offres.
Sommaire
GIDABE, RENOVATION D’UN OUTIL MICHELIN ............. .......................................................2
1) LE CONTEXTE ...............................................................................................................................3
1.1) PRESENTATION DE L’ENTREPRISE................................................................................................3
1.1.1) Michelin ...............................................................................................................................3
1.1.2) Bassens.................................................................................................................................5
1.1.3) Le bureau d’études...............................................................................................................6
1.2) PRESENTATION DU PROJET..........................................................................................................7
1.2.1) Analyse de l’existant ............................................................................................................7
1.2.2) Description du besoin ..........................................................................................................8
2) ETUDE DE LA SOLUTION .........................................................................................................10
2.1) METHODES AGILES..................................................................................................................10
2.2) MODELES DE DONNEES..............................................................................................................11
2.2.1) Les acteurs .........................................................................................................................12
2.2.2) Les documents....................................................................................................................12
2.2.3) Les traitements...................................................................................................................13
2.3) MAQUETTE ................................................................................................................................14
3) REALISATION ..............................................................................................................................16
3.1) PLANNING ..................................................................................................................................16
3.2) DEVELOPPEMENT.......................................................................................................................17
3.2.1) Module de recherche..........................................................................................................17
3.2.2) Module de création ............................................................................................................18
3.2.3) Module de réservation .......................................................................................................18
3.2.4) Module de réintégration ....................................................................................................19
3.3) TRANSFERT DE LA BASE DE DONNEES.......................................................................................20
3.4) FORMATION UTILISATEUR .........................................................................................................22
CONCLUSION ...................................................................................................................................23
BIBLIOGRAPHIE..............................................................................................................................24
GLOSSAIRE .......................................................................................................................................25
ANNEXES ...........................................................................................................................................27
2
Gidabe, rénovation d’un outil Michelin
La 1ere année de Master MIAGE étant le cœur de la formation, le stage de fin d’année
se doit d’apporter des éléments professionnalisant pour aborder sereinement le Master 2 et
l’entrée sur le marché du travail. Du sérieux et de la rigueur, imposée par la mission que
l’entreprise nous confie, sont nécessaires. Cette mission devra alors être réalisée avec une
certaine conscience professionnelle tout en étant méthodique de manière à la mener à terme.
L’enjeu de ce stage est important puisque l’expérience acquise sera l’un des éléments
déterminant qui pourra donner une idée des capacités de l’étudiant aux futurs employeurs.
Après plusieurs démarches, j’ai intégré le bureau d’études de l’usine MICHELIN de
Bassens. Ce stage s’est déroulé dans la période du 5 mai au 29 Août 2008, sous la direction
de M. Miguel Sanchez, chef du service N/TE et encadré par M. Jean-Pascal Labreize,
informaticien industriel.
Le sujet de ces quatre mois de stage est la refonte d’un système d’information, appelé
GIDABE, qui a pour fonction d’assurer la gestion des documents techniques*1 du bureau
d’études et de certains autres services de l’usine.
Nous pouvons nous demander comment réaliser un nouveau logiciel reprenant le
principe d’une application existante tout en l’adaptant aux nouvelles technologies et en
améliorant ses capacités et fonctions.
Ce mémoire va tenter de répondre à cette problématique en exposant mes démarches
et en essayant le plus possible d'avoir une progression logique dans la suite des différentes
étapes de traitement. La première partie présentera le fonctionnement du bureau d’études à
travers une analyse de l'existant, l'étude des besoins et la description du projet. La seconde
partie sera consacrée à la présentation de la méthode utilisée, la schématisation des données
et de l’application. Enfin, la troisième partie abordera la réalisation du projet en lui-même
avec le développement, l’intégration et la formation utilisateur.
1 Les mots ou abréviations notés par une étoile sont expliqués dans le glossaire page 25.
3
1) Le contexte
1.1) Présentation de l’entreprise
1.1.1) Michelin
L’entreprise MICHELIN2 est née du génie industriel de deux frères dont la créativité
et l’intelligence ont permis au groupe de connaître un grand développement et de devenir l’un
des leaders dans le domaine des pneumatiques.
Le développement de l’entreprise peut se résumer en quelques grandes dates
charnières montrant toutes les étapes franchies pour arriver au statut de groupe multinational :
1832: En Auvergne, le grand-père maternel des fondateurs de l'entreprise, Aristide
BARBIER, s'associe avec son cousin et ami Edouard DAUBREE pour fonder une fabrique
de machines agricoles. L'épouse d'Edouard DAUBREE est la nièce du savant écossais Mac
INTOSH qui découvrit la solubilité du caoutchouc. BARBIER rêve aux applications
possibles du caoutchouc. Il écrit que l'on pourrait en faire "des garnitures de roue pour
voitures légères". La manufacture découvre alors les usages du caoutchouc.
1833 : Edouard et André lient le nom de MICHELIN à l'application du
pneumatique à l'automobile.
1896 : Création de l’entreprise MICHELIN et CIE à Clermont-Ferrand (268
personnes).
1900 : André créé le "guide MICHELIN", puis la série des cartes routières qu'il établit
pour la France ainsi que certains pays étrangers.
1951 : Plus de 80 000 personnes déjà réparties sur les cinq continents.
2 Les informations concernant les sources sont dans la bibliographie page 24.
4
2001 : 120 000 personnes avec 80 sites de production répartis sur 19 pays.
Présence commerciale dans 170 pays (15 000 produits commerciaux).
L'entreprise est un véritable groupe multinational qui a perçu très tôt l'importance d'une
implantation géographique dans un maximum de pays. Ainsi, aujourd'hui, le groupe est
présent sur quatre continents à travers ces 80 usines:
- 45 en Europe dont 25 en France
- 21 en Amérique du Nord
- 4 en Amérique du Sud
- 2 en Afrique
- 7 en Asie
MICHELIN dispose aussi de 6 centres d'étude et de recherche ainsi que de 6
plantations d'hévéas pour la production de latex qui fournit le caoutchouc naturel. En effet,
une enveloppe est fabriquée à partir de 60% de gomme synthétique et de 40% de gomme
naturelle.
Toutes les usines sont regroupées dans les régions du centre de la France pour des
raisons logistiques (transport de marchandises) et climatiques. A noter que ces régions sont
industrialisées depuis le début du siècle ce qui explique la main d’œuvre compétente.
En France, 60% de la production vendue est exportée.
Les principales productions du groupe se repartissent ainsi (production journalière):
- 830 000 pneus
- 76 000 chambres à air
- 88 000 roues
- 4 millions de kilomètres de câbles d'acier
- 70 000 cartes et guides
Sur le plan humain, le groupe compte actuellement environ 120 000 employés. Il
affiche un chiffre d'affaires de 15.4 milliards d'euros en 2000 (101 milliards de francs) et un
bénéfice de 438 millions d'euros (2.87 milliards de francs). Enfin avec une part de marché de
5
19.4% en 2000, MICHELIN occupe la deuxième place à égalité avec BRIDGESTONE et
juste derrière GOOD YEAR (21.5%).
1.1.2) Bassens
Le nom légal de l'usine (inscrit au registre du commerce) est SIMOREP &Cie mais
elle fait bel et bien partie du groupe MICHELIN.
La ville de Bassens a été choisie en 1963 pour l’installation d’un grand site de
production de caoutchouc synthétique (proximité d'un port, bonne desserte routière et
ferroviaire).
Le site de BASSENS produit, sur la base de dérivés du pétrole, styrène et butadiène
surtout, des caoutchoucs synthétiques de différentes textures et qualités. Ceux-ci sont destinés
à l'usage exclusif des usines du groupe fabriquant l'enveloppe elle-même.
L'usine, située sur la presqu'île du bec d'Ambès, occupe une superficie de 63 hectares.
Toutes les installations sont à l'air libre. L'importance du site peut se résumer par plusieurs
points et chiffres significatifs (Voir Annexe 1):
Une production continue
900 kilomètres de tuyauteries
20 000 mètres cube de stockage
163 000 tonnes par an de gomme produite à une cadence d’environ 600 tonnes/jour, exportée
à 73%
35% des besoins MICHELIN en gomme synthétique
L'usine de BASSENS, c'est aussi un effectif d'environ 380 personnes pour un chiffre d'affaire
de 147 millions d'euros (964 millions de francs) en 2000.
6
1.1.3) Le bureau d’études
C’est le Service N/TE (Technique Etudes) que j’ai intégré durant mon stage. Il
emploie 11 personnes dont le chef de service est M. Miguel Sanchez, mon responsable de
stage.
Chaque personne qui travaille dans ce service a un rôle bien défini. Chacun a sa
spécialité : mécanique, électrique, génie chimique, instrumentation, automatique ou
informatique.
Ce service prend en compte toutes les demandes d’évolution des installations et pilote
les affaires. Il est chargé d’étudier toutes les modifications à apporter aux différentes unités.
Il travaille donc en étroite collaboration avec les autres services. Les clients du bureau
d’études sont, en fait, les services de l’usine elle-même.
Image 1 : Organigramme N/TE. Source : CSM Bassens
7
1.2) Présentation du projet
1.2.1) Analyse de l’existant
Le rôle du bureau d’études est donc de créer les plans des nouvelles installations
répondant aux commandes ou de procéder à la modification des plans pour les mettre en
conformité avec les installations réellement en place.
Le nombre de plans ou de documents techniques est très important. La plupart des
documents récents sont informatisés. Certains plans plus anciens sont archivés dans un fond
documentaire papier. Pouvoir retrouver un plan rapidement est l'une des priorités de la
documentaliste, Mme. Nicole Guilhem, chargé de la gestion des documents. Pour cela, elle
utilise un logiciel nommé « GIDABE ».
Cette application a été développée en 1991 en Clips* et repose sur une base de
données Visual dBase*. L'interface de type DOS ne permet pas d'utiliser la souris et le
manque de mémoire de l'époque a obligé à restreindre le nombre de caractères dans les
champs de définition des documents. L'autre principal inconvénient réside dans le fait que
l'application est mono utilisateur. C'est-à-dire qu'une seule personne à la fois peut entrer des
documents dans la base de données ou retirer le document qui l’intéresse. Si une personne
souhaite obtenir le document soit elle passe par la documentaliste, soit elle va directement sur
le disque de stockage pour prendre le plan. La réintégration se fait sans vérification et
l'écrasement d'une version intermédiaire est courant.
Dans ces conditions, la sécurité des documents ne peut pas être assurée. C'est
pourquoi le bureau d'études m'a chargé de réaliser un nouveau logiciel pour le remplacer en y
apportant des améliorations.
8
1.2.2) Description du besoin
Le besoin du bureau d'études s'exprime autour de plusieurs points.
Contraintes techniques :
� Utilisation d'Access pour créer la base de données.
� Développement modulaire et évolutif avec Visual Basic* ou Windev*.
� Intégration de l'application sur le serveur usine.
� Respect de la charte Michelin.
� Alléger les procédures humaines : réservation, création, ajout, sortie,...
Fonctionnalités :
� Produire une application multi-utilisateurs.
� Gérer les différents types d'utilisateurs et leurs droits.
o Accès en écriture ou en lecture.
o Accès aux données des autres services.
o Accès à certaines natures de documents.
� Sécuriser les documents.
o Verrou « lecture seule » lorsque le document est en modification.
o Interdire l'accès aux documents situés sur le disque.
o Mettre en place des protocoles de contrôle après création ou modification d'un
document.
o Tracer chaque mouvement des documents.
o Conserver chaque version d'un document.
� Rechercher les documents.
o Permettre une recherche sur de nombreux filtres.
o Recherche intuitive avec peu de critères ou des informations incomplètes.
� Gestion des documents.
o Optimiser les formulaires d’ajout de documents pour une utilisation rapide.
o Possibilité de rajouter un grand nombre de documents.
o Possibilité de réserver des numéros de document pour une création ultérieure.
� Modularité.
o Possibilité d'ajouter de nouvelles fonctions rapidement.
9
Données :
� Récupérer la totalité de la base de données existante.
� Assouplir les restrictions de taille des champs.
� Optimiser la base de données en indexant les champs importants.
� Optimiser les requêtes pour améliorer les performances.
� Prendre en compte le grand nombre de documents et de données.
Interface Homme - Machine :
� Produire une interface conviviale, ergonomique et simple.
� Produire une application légère.
Documentation et utilisateurs :
� Produire une documentation utilisateur complète.
� Déployer l'application dans plusieurs services n'ayant pas accès à GIDABE
auparavant.
� Former le personnel à l'utilisation de la nouvelle application.
10
2) Etude de la solution
La difficulté dans la conduite des projets informatiques tient, outre la complexité
technologique, au nombre et à la variété des personnes impliquées. Tous projet informatique
comporte une part d’innovation, mais aussi d'adaptation à l'évolution de l'entreprise, qu'il
convient d'apprendre à jauger et à maîtriser, en s'appuyant sur des méthodologies efficaces.
C'est pourquoi nous avons utilisé les méthodes AGIILES* en nous inspirant du Extreme
Programming.
2.1) Méthodes AGILES
Le but de ses méthodes est de raccourcir les cycles de développement. Il s'agit de
mieux intégrer le client pour organiser l'expression des besoins et rendre le travail de
développement plus facile. Ce ne sont pas des méthodes universelles, elles s'appliquent
uniquement sur des projets simples en environnement non critique. Il y a une forte
responsabilisation de la maîtrise d'ouvrage qui est très impliqué. L'objectif étant la
satisfaction immédiate du client.
Nous privilégions l’application et l'interaction à la contractualisation des
spécifications. Il faut préférer la livraison de fonctionnalités réelles, à la production d’une
documentation pléthorique. Il faut favoriser l'acceptation du changement et la modification
des priorités, au respect d'une planification figée.
La conduite du projet s'est donc déroulée en plusieurs étapes. Tout d'abord une
analyse de l'existant et du besoin du client. Une spécification des flux et des types de
données. La réalisation d'une maquette graphique complète permettant aux clients de
visualiser directement l'aspect final de l'application et de recadrer certains points qui auraient
été mal interprétés. Vient ensuite la phase de développement en parallèle aux tests pour
pouvoir effectuer des bilans réguliers sur l'avancement des différentes fonctions. La phase
finale concerne l'intégration de l'application avec la récupération des données et le
déploiement sur le bureau d'études. Après validation, le déploiement sur l'ensemble des
11
services. Enfin, formation du personnel et rédaction de la documentation. À chaque étape, des
réunions de validation avec les différents acteurs ont été nécessaires.
2.2) Modèles de données
Les 3 premières semaines du stage ont été consacrées à la réalisation d'un modèle
conceptuel de données réalisé à partir de la méthode MERISE*. Pour cela, le contact avec le
client devait être précis et bref pour obtenir le maximum d'informations sans les gêner.
L'observation attentive du travail quotidien de chacun permet aussi de trouver des solutions
ou de mettre l'accent sur certains problèmes.
L'application sera vitale pour le service. Elle devra répondre à toutes leurs attentes,
avoir une structure suffisamment rigide pour qu'il n'y ait pas d'erreur malgré toutes les
possibilités d’utilisation. La structure devra être aussi suffisamment adaptable pour pouvoir
ajouter les fonctionnalités rapidement. Cette phase d'analyse a donc été très importante dans
la réalisation du projet.
Le relationnel est très sollicité durant cette partie car il faut poser beaucoup de
questions qui paraissent souvent évidentes aux employés mais qui peuvent avoir de grandes
répercussions sur la structure de l'application. Nous avons fait trois réunions pour pouvoir
valider les évolutions de l’analyse en nous appuyant sur des modèles des flux (Voir Annexe
2) et des modèles conceptuels de données (Voir Annexe 3). Le fait que la documentaliste
connaisse parfaitement le fonctionnement de l'ancienne application a grandement facilité
l'analyse. La disponibilité et la patience du personnel m'ont permis d'arriver rapidement à
trouver une structure satisfaisante pour les modules principaux.
Le modèle conceptuel de données peut être divisé en trois parties que nous allons
étudier plus en détails:
� La partie acteurs, regroupant les utilisateurs internes et les entreprises externes.
� La partie document avec les différents identifiants et liaisons.
� La partie traitement avec le statut du document, les réservations, et les verrous.
12
2.2.1) Les acteurs
Il y a deux types d'acteurs qui peuvent agir sur les documents. Les utilisateurs
internes, qui sont déclarés dans la base de données et qui font partie du personnel Michelin
Bassens. Les entreprises externes, à qui les utilisateurs internes sous-traitent la modification
des plans. Ces entreprises sont stockées dans une table précise et n'ont aucun droit sur
l'application.
Les utilisateurs internes sont divisés en quatre catégories représentées par un « niveau
». Les administrateurs qui ont tous les droits et peuvent modifier la base de données. Les
gestionnaires, qui sont des utilisateurs connaissant parfaitement l'application GIDABE et
ayant des responsabilités au niveau du fonds documentaire. Ils ont des droits d'écriture sur les
documents plus évolués que les deux derniers niveaux d'utilisateurs. Les
créateurs/modificateurs, qui sont les utilisateurs qui vont créer des plans et les modifier. Ces
utilisateurs sont soumis aux verrous de vérifications après modification ou aux verrous de
lecture seule lorsqu'un document est en modification. Le dernier niveau d'utilisateurs sert
uniquement à consulter les documents, c'est-à-dire qu'ils n'ont aucun droit en écriture.
2.2.2) Les documents
Les documents sont au centre de l'application et sont identifiés par de nombreux
paramètres. L’identifiant principal est le nom du document qui est unique et généré à partir
du préfixe de la nature suivi d'un numéro qui s’incrémente à chaque nouveau document.
Pour certaines natures, on peut ajouter une sous nature qui spécifiera le type de
documents. Chaque document réfère à du matériel situé sur l'usine. Le document est donc
inclus dans une unité de l'usine et placé dans une sous partie : la zone. Le document est
ensuite lié à des repères qui sont les identifiants du matériel qu'il décrit.
Nous précisons aussi le support sur lequel est inscrit le document. S'il s'agit d'un
document informatique alors les utilisateurs peuvent le consulter directement dans GIDABE.
13
En revanche s'il s'agit d'un document papier ou d'un document archivé sur CD-ROM, il faut
alors demander un gestionnaire pour pouvoir le consulter.
La totalité des documents est stockée sur un disque dur accessible à tous les
utilisateurs en lecture. Pour pouvoir assurer la sécurité des documents, nous avons décidé de
renommée de façon anonyme chaque document. Une extension propre à l'application est
appliquée et la table tDocument contient la correspondance entre le nom réel et le nom visible
sur le disque. À aucun moment, un utilisateur (autre qu’administrateur) ne peut connaître le
nom du fichier inscrit sur le disque. Cette sécurité nous permet donc d'assurer que le
document présent dans GIDABE est bien la dernière version.
2.2.3) Les traitements
Le principal traitement que subira un document est sa modification. Une table
répertorie donc la totalité des modifications, les dates d'entrée et de sortie du document, la
personne qui l’a sorti et la personne ou entreprise qui effectue la modification. Lorsqu'un
document est en cours de modification ou en cours de création, les utilisateurs peuvent
consulter la dernière version, en revanche, ils ne peuvent en aucun cas procéder à une
modification. Seule la personne qui a sorti le document peut entrer le document modifié. En
cas de soucis, les gestionnaires sont les seules personnes qui peuvent écraser un document.
La création d'une nouvelle unité de production prend plusieurs mois et génère de
nombreux plans dont le créateur doit connaître le nom avant même le début de la conception,
pour pouvoir faire les liaisons entre les différentes structures. Dans ces conditions, il est
obligatoire de pouvoir réserver des numéros à l'avance. Ces numéros sont identifiés par un
numéro d'affaire. Lorsque celle-ci est terminée, le responsable de l'affaire peut intégrer tous
les documents dans GIDABE via un formulaire optimisé pour l'ajout de nombreux
documents. Bien souvent, plus de numéros ont été réservés qu'il en était réellement
nécessaire. L'utilisateur qui les a réservé peut donc choisir de les libérer et ils seront réutilisés
pour nommer les prochains documents.
Les verrous sont un point capital de l'application, nous en avons déjà vu certains
concernant l'accès des utilisateurs en fonction de son niveau ou du statut du document. Il
14
existe deux autres types de verrous : le premier concerne les natures des documents l'autre
concerne le service dont fait partie l’utilisateur. Certains créateurs sont qualifiés uniquement
sur certaines natures de documents il leur est donc impossible de créer des documents de
natures pour lesquelles ils n'ont pas l'autorisation. Ainsi un électricien ne pourra pas créer ou
modifier un plan de bâtiment par exemple.
Un facteur peut aussi spécifier le service qui aura accès à ce document. Souvent utilisé dans
les phases de conception ce verrou empêchera toute personne étrangère au service de
modifier ou de consulter le document. Par défaut, le document est accessible à tous.
2.3) Maquette
À partir de la troisième semaine, j'ai commencé à réaliser les maquettes pour apporter
aux clients une vision beaucoup plus concrète de ce à quoi ressemblera l'application finale en
fonction des informations que j'ai pu enregistrer durant la première partie du stage.
Dès les premiers jours, nous avons discuté pour déterminer dans quel environnement
nous allions développer l'application et l'interface. Nous avions le choix entre Windev et
VBA, mais finalement les délais, l'importance de l'aboutissement du projet et mon expérience
en Visual Basic nous ont poussé à choisir Access pour réaliser l'ensemble de l'application.
Le premier objectif de la maquette était de présenter un environnement de travail
agréable et pratique. Objectif plutôt simple à réaliser puisque l'ancienne application consistait
en un écran 16 couleurs sans aucun bouton, aucune police stylisée et aucun curseur.
Venait ensuite l’ergonomie des boutons et l'enchaînement des opérations. Puis la
correspondance entre les fonctions présentées et les souhaits des clients.
Développer la maquette en présentant des exemples virtuels a été un véritable atout pour la
suite du développement. L'ensemble des clients n'étant pas forcément initié aux modèles
conceptuels de données, ces exemples concrets leur ont permis de modifier certains points
mal interprétés.
15
Une dernière réunion de validation a eu lieu lors de la première semaine de juin. J'ai
pu faire une première présentation à l'ensemble des utilisateurs des différents services pour
obtenir les derniers avis et pouvoir commencer le développement concret de l'application.
Image 2 : Menu Principal de GIDABE
16
3) Réalisation
3.1) Planning
Je présente ici le planning du projet tel qu'il était la veille de rendre le rapport. Bien
évidemment chaque phase ne s'est pas terminée aussi strictement que sur le diagramme, les
réunions de validation ou la découverte d'un bogue pouvaient amener à revenir sur le
développement d'une fonctionnalité théoriquement terminée.
Image 3 : Diagramme de Gantt, projet GIDABE
Chaque ligne correspond à une tâche effectuée par une ou plusieurs personnes. Le
trait noir correspond à l'avancement de la tâche. Les ruptures représentent les week-ends.
Lorsque le trait noir atteint la fin de la case bleue, c'est que la tâche terminée.
Vous trouverez sur l'adresse Internet suivante une présentation détaillée du planning
du projet, la description et les ressources attribuées à chaque tâche.
http://ro.arnoux.free.fr/download/GIDABE
17
3.2) Développement
L'un des principaux objectifs de l’Extreme Programming est de livrer rapidement aux
clients une application fonctionnelle. Nous avons déterminé des priorités pour permettre au
client d’utiliser l'application bien que la totalité des modules ne soit pas disponible. Nous
avons donc débuté par le coeur de l'application : les documents. Nous voulions que les
utilisateurs puissent ajouter, modifier un document le plus tôt possible. Ensuite, venait le
module de recherche. Se succèdent plus tard le développement parallèle du module de
réservation et du menu des gestionnaires. Durant la deuxième partie du développement, nous
avons traité tous les verrous et gestion des droits accès. À ce stade, l'application a pu être
livrée dans certains services pendant que je développais certains modules moins prioritaires
comme l'ajout en masse de documents. Une fois l’application complètement terminée et
déboguée, nous avons procédé à son déploiement sur l’ensemble des services.
3.2.1) Module de recherche
(Voir Annexes 4 et 5)
Ce module est le premier disponible dans le menu principal. Il permet de rechercher
un ou plusieurs documents à partir de différentes informations. L'utilisateur coche des check-
box pour sélectionner les critères qu'il souhaite renseigner. Un champ de texte ou un menu
déroulant apparaît pour entrer l'information. J'ai donc créé un algorithme exécutant une
requête dynamique sur la base de données. Chaque nouveau critère sélectionné ajoute une
nouvelle condition et parfois une nouvelle clause « FROM ». Pour les champs de texte
comme le libellé du document, que l'utilisateur ne connaît pas forcément par coeur, j'ai utilisé
l'opérateur « LIKE » pour pouvoir faire des recherches sur une partie du champ.
Le résultat de la requête est envoyé dans un autre formulaire et est affiché dans une
liste déroulante. En sélectionnant l'une des lignes de la liste, le descriptif complet du
document apparaît en dessous. L'utilisateur a ensuite plusieurs choix : il peut consulter le
document, télécharger le document pour le modifier, ou encore modifier la fiche au cas où
des informations seraient erronées.
18
Ce formulaire contient énormément de tests pour savoir à quelles informations
utilisateur peut accéder et quelles actions il peut déclencher. Par exemple, un simple
utilisateur ne pourra pas modifier la fiche ni le document, ces deux boutons sont donc
invisibles et il ne peut pas les utiliser. Les verrous concernant les natures des documents ou
les propriétaires se font aussi sur ce formulaire.
3.2.2) Module de création
(Voir Annexes 6)
Ce formulaire permet de créer une nouvelle fiche de document. Le document en lui-
même peut ne pas être déjà créé et lié à la fiche, car le créateur a besoin de connaître le nom
de son document avant de travailler dessus. Pour cela, il doit sélectionner la nature du
document qui va générer automatiquement le nom. Il est constitué du préfixe de la nature
suivi d'un numéro qui s'incrémente à chaque nouvelle création. Lorsqu'une fiche est créée
sans être liée à un fichier informatique, le document a le statut « en création ». Ainsi, aucun
utilisateur ne peut visualiser ni modifier le document. Seul le créateur de la fiche ou un
gestionnaire pourra lier le fichier informatique à sa fiche.
Toute modification de la fiche ou du document doit se faire par le formulaire de
résultat de recherche.
3.2.3) Module de réservation
(Voir Annexes 7)
Vous savez donc maintenant qu'il est possible de réserver des numéros de documents
pour des entreprises extérieures. Pour cela, il faut passer par le menu de réservation située
dans le menu principal. Un formulaire permet de saisir des informations communes à tous les
documents comme le numéro de l'affaire, l'unité et la zone dans lesquelles se situeront les
nouveaux appareils. L'utilisateur a la possibilité de saisir l'auteur des documents, le
propriétaire, préciser la sous nature des documents. Tous ces renseignements seront déjà pré
19
remplis lors de la réintégration des documents. L'utilisateur doit bien évidemment préciser le
nombre de numéros qu'il souhaite réserver. Ces numéros sont toujours consécutifs.
Lors du développement de ce module en local, la procédure d'enregistrement des
données dans les tables s'effectuait rapidement. Lors des tests sur le réseau, la procédure
devenait beaucoup plus longue et la réservation de 100 numéros prennait environ 30
secondes. Ce délai nous a beaucoup posé problème car si deux personnes réservent des
numéros en même temps, leurs numéros se chevaucheront et ne seront donc plus consécutifs.
Nous avons donc dû trouver un moyen pour verrouiller l'ensemble des numéros en cours de
réservation par la première personne pour n'autoriser que les numéros suivants aux autres
utilisateurs. Nous avons utilisé une table temporaire qui contient le premier et le dernier
numéro en cours de réservation, si un autre utilisateur réserve des numéros, on vérifie que les
numéros sélectionnés par l'algorithme ne sont pas dans cette table. De plus, compte tenu du
temps d'attente pour la réservation, les utilisateurs avaient tendance à penser que l'application
avait planté et quittaient Access. J’ai donc mis en place un système de barre défilante pour
indiquer l'avancement de la procédure.
3.2.4) Module de réintégration
(Voir Annexes 8)
Pour pouvoir sauvegarder un fichier informatique dans GIDABE, que ce soit un
document en cours de création, ou en cours de modification, il faut passer par le menu de
sauvegarde situé dans le menu principal. Un simple bouton ouvre une fenêtre de dialogue
permettant à l'utilisateur de sélectionner le fichier qui souhaite intégrer. Le système vérifie si
l'utilisateur en question est en droit de réintégrer le document sélectionné à partir de son
identifiant et du nom du fichier. Si l'utilisateur n’est pas inscrit dans la base de données
comme modificateur ou créateur du document sélectionné, l'application indique un message
d'erreur. Si l'utilisateur a sélectionné un fichier qui ne correspond à aucune fiche en cours de
création ou en cours de modification, alors l'application indique que le nom du fichier
sélectionné ne correspond à aucun document.
Une fois le document réintégré dans la base de données, le statut « non contrôlé » est
automatiquement appliqué. La liste des documents non contrôlés apparaît sur l'écran d'accueil
20
de chaque gestionnaire. Celui-ci peut donc procéder aux vérifications nécessaires. Une fois
les informations de la fiche et la correspondance avec le fichier informatique vérifiées, le
gestionnaire passe le document en statut « contrôlé ».
Lorsqu'une personne prend un document pour le modifier, celui-ci n'est plus
accessible en écriture. Si jamais cette personne n'effectue finalement pas de modification, il
peut choisir de « libérer » le document pour que celui-ci conserve son ancien statut et que les
gestionnaires n'aient pas à contrôlé un document qui n'a pas subi de modification. Cette
option de libération est disponible sur le même formulaire que la réintégration.
3.3) Transfert de la base de données
Une fois les fonctions principales développées et déboguées, nous pouvions
commencer à réintégrer les données de l'ancienne base vers la nouvelle. Les informations les
plus anciennes contenues dans cette base datent de 1991 et contient plus de 44 000 fiches de
document. Chaque ligne a son importance et devait être conservée sous peine de perdre des
informations vitales concernant les structures de l'usine. La phase de transfert fut donc le
point le plus critique de l'ensemble du projet.
Compte tenu des restrictions imposées par l'ancienne application, les utilisateurs
étaient obligés de placer des informations dans des champs qui ne leur étaient pas à l'origine
destinés. Par exemple, on retrouvait des informations concernant le format du document dans
le champ de l'auteur. Plus grave, des champs identifiants comme le nom du document étaient
parfois redondants. Les unités et les zones étaient parfois mal orthographiées. Certains plans
référaient à du matériel qui avait été supprimé. Pour les distinguer, la documentaliste n'avait
pas d'autre moyen que d'inscrire dans le libellé du document le mot «ANNULE ».
Évidemment comme il ne s'agissait pas d'une opération automatisée, l'orthographe était
hasardeuse. On se retrouvait avec des «ANNNULE », « ANNUULE »,.... Il y a donc fallu
une longue phase de vérification de la base de données pour corriger les erreurs flagrantes. Le
personnel du bureau d'études a donc énormément travaillé pour me faciliter cette tâche
pendant que je développais l'algorithme de récupération des données.
21
Les fichiers, sur le disque, étaient stockés dans un sous dossier correspondant à la
zone lui-même contenu dans un dossier correspondant à l'unité de la zone. Tous ces dossiers
contenaient une multitude de fichiers n'ayant rien à voir avec des documents techniques ou
encore de véritables plans qui n'étaient pas présents dans la base de données de GIDABE. La
totalité des fichiers à vérifier pesait 6.4 Go.
La procédure de transfert a été affectueusement appelée « La Moulinette » en raison
de l'importance des traitements effectués sur les données et des changements irréversibles
qu'elle produirait. L'algorithme procédait de la façon suivante (Voir Annexe 9):
- Pour chaque ligne de la base de données de l'ancien GIDABE
- Vérifier la pertinence des informations, insérer ces informations dans la nouvelle base
de données.
- Déterminer en fonction du nom et des informations du document le support : papier,
CD-ROM, informatique.
- Lier le document aux affaires et aux repères correspondants.
- Chercher le fichier informatique, si il y en a un, dans le dossier de zone spécifiée.
- Renommer ce fichier pour le rendre anonyme.
- Couper le fichier vers l’espace disque final.
À chaque procédure, on écrit dans un fichier texte le résultat de l'opération pour savoir
exactement, pour chaque document, si tout s’est bien effectuée ou si il y a eu un problème.
Toutes ces informations sont écrites dans un fichier de « log »*.
À la fin de la procédure, tous les documents présents dans l'ancienne base de données
ont été transférés et les fichiers informatiques traités. Tous les fichiers restant dans
l'arborescence de l'ancienne application sont considérés comme des anomalies. Soit ils
correspondent à des fichiers qui ne rien à voir avec GIDABE, soit se sont des documents qui
n'ont jamais été intégrés dans la base de données, soit se sont des documents présents dans la
base mais mal placés ou mal nommés sur le disque.
J'ai d'abord procédé à une moulinette de tests en local sur mon poste uniquement pour
pouvoir tester le comportement de l'algorithme. Une fois certain que le résultat correspondait
à notre volonté, nous avons lancé la procédure sur les données réelles. Le transfert des
22
données et le déplacement des fichiers ont pris 29 heures et 52 minutes. Au final, 43 387
lignes ont été traitées et environ 5Go de fichiers ont été copiés.
3.4) Formation utilisateur
Une fois la base de données transférée, nous avons déployé l'application sur les postes
du bureau d'études, soit environ vingt personnes. La majorité des futurs utilisateurs de
GIDABE avaient déjà vu, lors de la présentation de la maquette, à quoi ressemblerait
visuellement le logiciel. Le principe de fonctionnement de l'application reste proche de
l'ancienne application, seuls les processus et certaines fonctions étaient à revoir.
La majeure partie de la formation principale s'est faite lors de réunions générales où
chaque utilisateur a pu voir la démonstration des différentes fonctions de l'application.
Évidemment, cela restait théorique et seule la pratique leur a permis de vraiment entrer dans
les détails. J'ai donc passé plusieurs jours à accompagner les utilisateurs dans leur découverte
de la nouvelle application et à leur expliquer les fonctionnalités qui n'étaient pas encore
claires. Certains processus comme le contrôle des documents ou la notion de propriétaire
posaient parfois problème, ces notions étant totalement nouvelles.
L'application fut bien accueillie par le service qui par la même occasion servait de
béta-test en vue du déploiement sur l'ensemble de l'usine. Nous avons donc demandé aux
utilisateurs de faire remonter les bogues, les problèmes d'optimisation ou d'ergonomie pour
pouvoir les modifier rapidement. Cette phase de béta-test a duré environ deux semaines puis
nous avons pu ouvrir l'application à deux nouveaux services.
Venaient ensuite les deux dernières parties du projet : le développement des derniers
modules non prioritaires et la rédaction de la documentation utilisateur que vous trouverez
jointe à ce rapport.
23
Conclusion
Ce stage s'est révélé aussi important pour moi que pour l’usine. L'analyse de leur
entreprise, de leurs besoins a été plus que rigoureuse de façon à développer une application
sérieuse sur laquelle les employés pourraient en partie se reposer. La mission qu'on m'a
proposée était donc un projet complet avec une importante analyse de l'existant et du besoin,
le développement complet d'une application, son intégration chez les clients et enfin la
formation des utilisateurs. Pour pouvoir réaliser ces objectifs en quatre mois, la gestion des
délais impliquait l'utilisation d'un planning et une détermination des priorités rigoureuses.
Découvrir le fonctionnement d’une usine est une très bonne expérience. La mission qui m’a
été confié portait sur des outils que j’avais parfois utilisés mais sur lesquels j'ai beaucoup
approfondi mes connaissances, ce qui m'a apporté une véritable formation en plus de celle de
la MIAGE. Les méthodes de développement AGILES sont vraiment très utiles concernant
des petits projets où on peut facilement entrer en contact avec les clients.
Pour réaliser mes objectifs, j'ai dû analyser la demande et comprendre le fonctionnement de
l'entreprise. J'ai donc beaucoup appris concernant la conduite de projets, avec ses difficultés
et les façons de réussir. Les relations humaines et la communication ont une part
prépondérante dans un projet. C'est grâce à ça que les parties peuvent s'entendre sur le
fonctionnement d'un outil et ainsi gagner en efficacité. Prendre en compte le point de vue de
l'utilisateur est un aspect très peu enseigné dans les formations scolaires, pourtant cela forme
la base du travail d'analyste programmeur et de chef de projet. J'ai appris à prendre du recul
par rapport mon travail et voir des défauts de conception important. Enfin, j'y ai appris que la
qualité du travail et la motivation sont des éléments essentiels à la réussite.
24
Bibliographie
� VBA pour les nuls, Steve Cummings, SYBEX, ISBN : 2-7361-3437-0.
� VBA Access 2007, Henri Laugié, ENI.
� Michelin, Histoire et chiffres, Document interne, 2007.
Webographie :
� Programmer efficacement avec Excel en VBA, J-M Rabilloud :
ftp://ftp2.developpez.be/developps/vb/VB-excel2.pdf
� Développez.com : http://access.developpez.com/
� Michelin : http://www.michelin.fr
� Wikipédia : http://fr.wikipedia.org
� GanttProject : http://ganttproject.sourceforge.net/fr
25
Glossaire
SGDT :
Un système de gestion de données
techniques est un ensemble d'outils
informatiques pour la gestion des
données techniques liées à un projet de
conception.
Clips :
C Language Integrated Production
System est un environnement et un
langage de programmation créés en 1985,
faisant partie du paradigme des langages
déclaratifs et logiques. Il s'agit avant tout
d'un outil de construction de systèmes
experts à base de règles et d'objets.
dBASE :
C’est un SGBD destiné à faire partager
des fichiers de données par plusieurs
utilisateurs. Cette version amène surtout
la possibilité de travailler en multiposte
sur les réseaux locaux supportant
l'interface logicielle MS.NET, tels que
PC NETWORK ou GOUPIL.NET.
D'autres types de réseaux comme Novell
sont acceptés.
VBA :
Visual Basic for Applications est une
implémentation de Microsoft Visual Basic
qui est intégrée dans toutes les
applications de Microsoft Office. C’est un
langage de programmation évènementiel
de troisième génération ainsi qu'un
environnement de développement intégré,
créé par Microsoft pour son modèle de
programmation COM. Visual Basic est
directement dérivé du BASIC et permet le
développement rapide d'applications, la
création d'interfaces graphiques, l'accès
aux bases de données en utilisant les
technologies DAO, ADO et RDO.
26
AGILES :
La notion de méthode agile se limite
actuellement aux méthodes ciblant le
développement d'une application
informatique. Ces méthodes Agiles
permettent de concevoir des logiciels en
impliquant au maximum le demandeur
(client), ce qui permet une grande
réactivité à ses demandes. L’Extreme
Programming fait partie de ces méthodes.
MERISE :
C’est une méthode d'analyse, de
conception et de gestion de projet
complètement intégrée, ce qui en
constitue le principal atout. Elle fourni un
cadre méthodologique et un langage
commun à beaucoup d’informaticiens.
Cela permet de pouvoir expliquer
rapidement des fonctionnements
complexes ou abstraits.
WinDev :
WinDev est un atelier de génie logiciel
édité par la société française PC SOFT et
conçu pour développer rapidement des
applications, principalement orientées
données.
Log :
En informatique, le concept d'historique
des événements ou de logging désigne
l'enregistrement séquentiel dans un fichier
ou une base de données de tous les
événements affectant un processus
particulier (application, activité d'un
réseau informatique...).
27
Annexes
Annexe 1 Vue aérienne de l’usine SIMOREP & Cie, Michelin
Annexe 2 Modèle des flux de GIDABE
Annexe 3 Modèle conceptuel de données de GIDABE
Annexe 4 Module de recherche
Annexe 5 Formulaire de résultat de recherche
Annexe 6 Module de création
Annexe 7 Module de réservation
Annexe 8 Module de réintégration
Annexe 9 Algorithme de « La Moulinette »