Dédicaces

Dédicaces
A nos chers parents,

A ceux qui n’ont jamais cessé de nous encourager,
Et de nous conseiller.
A ceux qui n’ont jamais été avares ni de leur temps
ni de leurs connaissances pour satisfaire nos
interrogations.
A ces éducateurs bien veillant, nous dédions le fruit
de notre carrière estudiantine.
A nos frères et à nos sœurs.
En témoignages de l’amour et de l’affectation qui
nous lient.
A tous nos amis.
Rapport du Projet – Etude et amélioration du SI qualité GRET/PSFV
Remerciements
On tient à exprimer notre gratitude à Mr.ASMODI Hassan, notre tuteur, pour nous avoir
intégré rapidement au sein de l’entreprise et nous avoir accordé toute sa confiance ; pour le temps
qu’il nous a consacré tout au long de cette période, s’efforçant à répondre à toutes nos
interrogations, sans oublier sa participation au cheminement de ce rapport.
On tient également à remercier Pr.EZZIYANI Mostafa, notre encadrant et enseignant à la

FST de Tanger, ainsi que le reste du corps professoral du département de génie informatique pour
leur support pertinent et fort précieux.
On tient à remercier tout particulièrement et à témoigner toute notre reconnaissance aux

personnes suivantes, pour l’expérience enrichissante et pleine d’intérêt qu’elles nous ont fait vivre
durant ces quatre mois au sein de l’usine Renault Tanger :
- M.LAATIRIS Abou-ennasr & M.ET-TAKI Abdelhak, administrateurs GRET, pour la qualité de
leur suivi incessant, pour leur accueil et pour la confiance qu’ils nous ont accordés.
- M.FOLENS Patrick ESIL de l’usine Renault Douai, pour l’aide précieuse qu’il nous a accordé tout
au long de ce projet.
Nos remerciements vont aussi à toute l’équipe du département des systèmes d’information
de Renault Tanger que nous avons côtoyé au quotidien dans une bonne ambiance. Ce projet a pu
être mené à son terme grâce à la contribution de nombreuses personnes qu’il serait difficile de les
citer tous, on tient à les remercier ici.
RENAULT – Usine Tanger DSI Service Manufacturing Page 3/98

Résumé :
Le présent rapport décrit le travail réalisé dans le cadre de notre projet de fin d'études en
ingénierie informatique effectué à Renault Tanger Exploitation. Le projet consiste en l’étude et
l’amélioration du système d’information qualité de Renault (nommé GRET).
Durant notre projet, nous avons eu pour mission dans une première étape d’étudier le
système de pilotage et de suivi des flux véhicules (PSFV). Dans la deuxième étape, nous avons
réalisé une étude détaillée du système d’information qualité actuel de Renault, pour en cerner les
limites, ainsi que la faisabilité, les gains et les contraintes d’une éventuelle amélioration.
La troisième étape a été celle de l’amélioration du système en étendant ses fonctionnalités

de base. Finalement la dernière étape a été la formation des utilisateurs à la manipulation et
l’exploitation du nouveau système.

Abstract :
In the framework of our graduation project in computer science engineering at Renault

Tangier Exploitation (RTE). The project involves the study and improvement of Renault's quality
information system (GRET).
The GRET application is an important block in Renault vehicles flow, control and
monitoring (PSFV). The project was conducted through the following phases:
- Phase 1: discovery and understanding of vehicle flow lifecycle, main features and
functionalities of PSFV that are interfaced with the target system GRET.
- Phase 2: focus on GRET functions, limitations and user requests.
- Phase 3: extending basic functionalities (enabling reporting, online requests and
cartography…)
- Phase 4: end-user training on the new release features.

Table des Matières :

Introduction générale...............................................................................................................................11
Chapitre I :ontexte général du projet.......................................................................................................12
1. Présentation de l’organisme d’accueil..................................................................................................13
1.1 Historique Renault Maroc.................................................................................................................13
1.2 Renault Tanger Exploitation.............................................................................................................14
1.2.1 Partenariat Renault Tanger........................................................................................................14
1.2.2 Processus de fabrication............................................................................................................16
1.2.3 Organigramme...........................................................................................................................18
1.3 Département système d’information.................................................................................................19
1.3.1 Présentation DSI Manufacturing :.............................................................................................19
1.3.2 Organigramme DSI Manufacturing...........................................................................................20
2. Contexte générale du projet :................................................................................................................21
Introduction................................................................................................................................................21
2.1 Objectif.............................................................................................................................................22
2.2 La méthodologie adoptée..................................................................................................................23
2.2.1 Les méthodes agiles...................................................................................................................23
2.2.2 Un comparatif des méthodes agiles...........................................................................................23
2.2.3 Le choix de la méthodologie Scrum..........................................................................................24
2.2.4 La méthodologie Scrum............................................................................................................25
2.3 Planification......................................................................................................................................26
Chapitre II :Etat de l’art...........................................................................................................................28
1. Les systèmes d’informations de fabrication GRET/PSFV.............................................................28
1.1Fonctionnement du système PSFV.....................................................................................................28
1.1.1 Généralités PSFV......................................................................................................................28
1.1.2 Périmètre et responsabilité.........................................................................................................29
1.1.3 Fonctionnalités..........................................................................................................................30
1.1.4 Fonctions de pilotage de la production......................................................................................31
1.2 Fonctionnement du système GRET...................................................................................................34
1.2.1 Généralités GRET.....................................................................................................................34
1.2.2 Notions sur le captage et les retouches......................................................................................35
1.2.3 Glossaire des termes utilisés dans GRET...................................................................................36
1.2.4 Application GRET (Captage des défauts liés aux véhicules).....................................................37
1.3 Fonctionnement globale de NGRET et PSFV...................................................................................39
1.4 Problématique...................................................................................................................................40
1.5 Conclusion........................................................................................................................................40
2. Business intelligence & BO...............................................................................................................41
2.1 Introduction.....................................................................................................................................41
2.2 Présentation de la B.I........................................................................................................................42
2.2.1 Architecture BI..........................................................................................................................42
2.2.2 Le datawarehouse......................................................................................................................43
2.2.3 L’ETL........................................................................................................................................44
2.2.4 L’application Business Object XI..............................................................................................44
2.2.5 Reporting (génération d'états)....................................................................................................45
2.2.6 Modèle de l’univers exploitable.................................................................................................46
2.3 Indicateurs standard d'animations Qualité.........................................................................................51
2.3.1 les principaux indicateurs d’animations qualité de RTE............................................................51
2.4 Problématique...................................................................................................................................54
2.5 Conclusion.........................................................................................................................................54
3. Flux de Travail..................................................................................................................................55
3.1 Introduction :....................................................................................................................................55
3.2 Procédures actuelles..........................................................................................................................55
3.3 Problématique...................................................................................................................................55

3.4 Conclusion........................................................................................................................................56
4. Architecture Intranet Renault.............................................................................................................56
4.1 Architecture Intranet Renault............................................................................................................56
4.2 Declic................................................................................................................................................56
4.3 Espaces métiers.................................................................................................................................57
Chapitre III :Modèle proposé...................................................................................................................59
1. Modèle proposé.....................................................................................................................................60
1.1 Introduction......................................................................................................................................60
1.2 Récapitulatif......................................................................................................................................60
1.3 Solutions proposées..........................................................................................................................60
1.3.1 Avantages & Inconvénients :.....................................................................................................62
1.3.2 Choix de la solution...................................................................................................................63
1.4 Modèle fonctionnel...........................................................................................................................63
1.4.1 Documents Business Objects :...................................................................................................65
1.4.2 Demandes de flux de travail :....................................................................................................66
1.4.3 Cartographie GRET/PSFV:........................................................................................................66
Chapitre IV :Réalisation & Mise en oeuvre.............................................................................................67
1. Implémentation du modèle fonctionnelle............................................................................................68
1.1 Introduction......................................................................................................................................68
1.2 Déroulement par rapport à Sprint :....................................................................................................68
1.3 Elaboration des documents BO.........................................................................................................72
1.4 Réalisation des eProcess...................................................................................................................74
1.4.1 Définition : eProcess Local (e-sign)...........................................................................................74
1.5 Réalisation de la cartographie...........................................................................................................78
1.6 Paramétrage de l’espace métier sous Tridion....................................................................................80
1.6.1 Paramétrage de l’espace Métiers sous Tridion...........................................................................80
Chapitre V :Synthèse du projet & Conclusion........................................................................................85
Synthèse du projet...................................................................................................................................86
1. Planning réel de ce qui a été fait.........................................................................................................86
2. Les objectifs ont été atteints................................................................................................................86
3. Les perspectives d’évolution...............................................................................................................87
Conclusion générale................................................................................................................................88
Annexes................................................................................................................................................89
Références.................................................................................................................................................101

Liste des figures :

Figure 1.1 : Organigramme Renault................................................................................................18
Figure 1.2: Organigramme DSI Manufacturing...............................................................................20
Figure 1.3 : cycle de développement d’un projet SCRUM..............................................................25
Figure 1.4 : Diagramme de Gantt (planning de réalisation)............................................................27
Figure 2.1 : PSFV dans le contexte usine de fabrication.................................................................29
Figure 2.2: Couverture macroscopique............................................................................................30
Figure 2.3 : Responsabilité de PSFV dans l’usine...........................................................................30
Figure 2.4 : Règles du captage défaut..............................................................................................35
Figure 2.6 : Ecran de Captage manuelle GRET Poste SPIN...........................................................39
Figure 2.5 : Ecran de Captage GRET Poste Tactile déployé au département peinture...................39
Figure 2.7 : Référentiel GRET.........................................................................................................40
Figure 2.8 : Solution BI....................................................................................................................43
Figure 2.9 : Datawarehouse et Datamart..........................................................................................43
Figure 2.10 : Principe de l'ETL........................................................................................................44
Figure 2.11 : Synthèse des concepts liés à l’univers........................................................................47
Figure 2.12 : Assistant de sélection de l’univers.............................................................................48
Figure 2.13 : Schéma de l’univers UCM_GRET Histo...................................................................49
Figure 2.14 : Schéma de l’univers UCM_GRET FdE.....................................................................49
Figure 2.15 : Portail DECLIC..........................................................................................................56
Figure 2.16 : L’espace Métiers DECLIC.........................................................................................57
Figure 4.1 : burndown chart du 3éme Sprint (3 - 20 Avril).............................................................69
Figure 4.2 : Backlog du 3éme Sprint (3 - 20 Avril).........................................................................70
Figure 4.6 : Cycle de vie d'une demande workflow.........................................................................74
Figure 4.7 : Liste des formulaires en –ligne crées...........................................................................75
Figure 4.9 : Demande de création/modification d'un document BO................................................76
Figure 4.10 : Message de notification au valideur...........................................................................76
Figure 4.11 : Message de notification de demandeur......................................................................77
Figure 4.12 : Page de la visualisation de la demande......................................................................77
Figure 4.15 : Périmètre maitrise de la qualité..................................................................................81
Figure 4.16 : Détail de périmètre exemple (Activités ponctuelles).................................................82
Figure 4.9 : Périmètre animation UET.............................................................................................82
Figure 4.17 : Périmètre professionnalisme......................................................................................83
Figure 4.18 : Authentification pour accéder à l’espace métiers.......................................................83
Figure 4.19 : Espace Métiers crées dédié à l’usine de Tanger.........................................................84
Figure 4.20 : les périmètres crées dans Espace Métiers...................................................................84
Figure 4.21 : Consultation d’un document BO................................................................................84
Figure 5.1 : Diagramme de Gantt (planning finale de réalisation)..................................................86

Liste des abréviations :

Afin de faciliter la compréhension du document qui suit, ce glossaire reprend et donne la
signification des abréviations et des sigles utilisés.
PSFV : Pilotage et suivie de flux de véhicule
GRET : Gestion des retouches sur les véhicules
PJI : Programme jour identifiant.
SipTK : Système information pilotage TriStock.
Siptol : Système information pilotage tôlerie.
UET : Unité de travail.
TK ou TriStock : Espace concerné de régler et corrigé l’ordre de véhicule.
CLE : Centre livreur.
PDC : prise à distribution centrale.
MADU : Mise à disposition usine.
MADC : Mise à disposition client.
OL : Ordre de livraison.
STRATUS : Système de traçabilité de véhicule.
BVU : Base véhicule usine.
BCV : Base centrale véhicule.
TCT : Tombé chaine tôlerie.
TCM : Tombé chaine mécanique.
TCP : Tombé chaine peinture.
TCU : Tombé chaine usine, Zone orientation véhicule vers le flux normale ou hors flux.
BCC : Bon, Complet, Confort (signé en blanc).
PPUM : Dossier de véhicule, leur famille et pièces et autre….
CARNET : Système permettant d’émettre un ordre de fabrication.
N° Luge : Identifiant de véhicule sur le film de fabrication.
SAO : Système anti-oubli.
PEV : Pilotage électronique de véhicule (Statique et dynamique).
STR : Straight through ratio.
PAD : Pourcentage d’acceptation direct (#STR).
Zipage : Scanner étiquette.
PASA : Lien dans l’intranet de l’usine
Kitting-picking : Zone de préparation ou d’alimentation de véhicule.

Check -man : Contrôleur de défauts.

AVES : Alliance véhicule évaluation standard.
MUSES : Catalogue centrale de défaillances.
FIL DE L’EAU : En temps réel.
MQ : Protocole d’envoie et de communication entre les serveurs.
CBC : Captage bord de la chaine.
DivD : Département d’ingénierie des véhicules décentralisé.
Cartographie : Découpage de l’espace physique de production.
TRAVES : Identification des rangées de véhicules en parc de retouche.
QCD : Qualité coûts délai.

Introduction générale
Ce document, a pour but, de présenter les réflexions, les travaux effectués et les résultats
obtenus au cours de la mission qui nous a été confiée pour ce stage.
Il est composé de quatre parties :
Première partie :
Elle est consacrée à la présentation de l'entreprise, définition du contexte et des objectifs du
projet réalisé. Dans un deuxième temps, nous présentons le planning de réalisation et la
méthodologie adoptée.
Seconde partie :
C'est une présentation générale de « l’état de l’art » qui est organisée en 4 axes :
 GRET : définition et étude des systèmes GRET et PSFV, cette partie est conclue par
l’identification de la problématique et les limitations que présentent les systèmes.
 Flux de travail : description des procédures de travail actuelles, identification des
problèmes.
 Reporting : description de l’architecture BI (business intelligence) utilisée par
Renault, identification des problèmes et des limitations.
 Architecture Intranet Renault : description de l’architecture Intranet Renault (Déclic).
Troisième partie :
Cette partie décrit le « Modèle proposé », elle définit la solution retenue pour l’amélioration
des systèmes GRET/PSFV.
Quatrième partie :
Cette partie est consacrée à la « réalisation et la mise en œuvre » du projet au sein de
l’entreprise Renault, on y décrit les étapes d’implémentation et de déploiements du modèle
fonctionnel proposé. Enfin, on présente une synthèse des résultats obtenus suivie d’une conclusion.

Chapitre I
Contexte général du
projet
Le présent chapitre décrit le contexte général du projet,

il présente l’entité d’accueil et l’équipe de travail à
travers son personnel et ses axes de travail.
Après cela, nous donnons un descriptif général du
système faisant l’objet de notre étude, nous
commençons par une brève présentation du projet, en
précisant le cadre général, l’objectif du projet, Enfin,
nous décrivons la méthodologie adoptée et le planning
mis en place pour la réalisation du projet.
1. Présentation de l’organisme d’accueil

1.1 Historique Renault Maroc

L’histoire de Renault au Maroc démarre il y a 80 ans, lorsque louis Renault eut l’intuition que
le développement hors France était l’un des gages nécessaire pour installer son entreprise dans une
perspective durable.
La naissance official de la marque au losange est ainsi actée par la création de l’Agence
Marocaine des Automobiles Renault (AMAR) le 2 février 1928. Cette société existe au Maroc
depuis sa création sans qu’aucune rupture ne soit intervenue dans son existence. Elle changera de
dénomination en 1933, devant la Société Marocaine des Automobiles Renault (SOMAR), puis à
nouveau en 1967 pour reprendre son appellation actuelle : Renault MAROC.
En 80 ans de présence, Renault Maroc a évolué au gré des événements politiques, industriels et
commerciaux qui ont marqué le pays, construisant son succès en marquant de son empreinte la
mémoire des Marocains par des dizaines de milliers de véhicules vendus, des millions des
kilométrages de parcours.
Aujourd’hui leader du marché automobile marocain, Renault Maroc représente plus qu’un
simple constructeur automobile, c’est avant tout un partenaire fidèle du développement industriel
humain du Royaume. Dans cette lignée, la marque a adapté sa production aux habitudes de
consommation des Marocains et lance au milieu des années 90 le projet de « voiture économique »
qui donnera à SOMACA, dont Renault est l’actionnaire principal, un second souffle dans sa
longue existence. C’est aussi que le groupe a introduit avec succès la marque DACIA en
s’appuyant sur les modèles Logan et Logan MCV, modèles les plus vendus du pays.
Renault confirme également sa confiance et son attachement au Maroc en y bâtissant une vaste
unité industrielle à la région Nord. Bâtie sur une superficie de 314 Ha et mobilisant un
investissement de 1,1 milliard d’euros, cette usine produira à terme 400 000 véhicules,
majoritairement destinés à l’exportation. Fruit d’un étroit partenariat entre Royaume Maroc et le
Renault Maroc, la construction de cette nouvelle usine participera au développement de la région
Nord dans son ensemble.
Ce succès, Renault le doit en grande partie à son réseau de distribution commercial qui l’a
fidèlement accompagné tout au long de ses 80 ans de présence au Maroc, faisant de Renault,
aujourd’hui unique constructeur automobile au pays, l’une des marques préférées des Marocains.
1.2 Renault Tanger Exploitation

1.2.1 Partenariat Renault Tanger

La vision stratégique du gouvernement marocain est d’intégrer le Royaume dans un plan de

développement ouvert sur l’Europe, la Turquie et ses voisins du Maghreb. Compte tenu de sa
position géographique, véritable carrefour entre l’Europe et l’Afrique, le Maroc offre de grandes
opportunités de développement, et l’automobile s’est imposée comme un domaine naturel pour
parvenir à cet objectif.
C’est dans ce cadre que le Premier Ministre marocain de l’époque et Carlos Ghosn, PDG de
Renault Nissan, ont signé le 1er septembre 2007 un protocole d’intention pour la construction
d’un complexe industriel à Tanger sur la zone de Meloussa. Une usine sans précédent au Maroc en
termes d’investissements et d’ambitions, destinée à l’Alliance Renault - Nissan. Le contrat cadre a
été signé le 18 janvier 2008 et c’est le 30 octobre 2009 qu’est officiellement posée de la première
pierre de l’Usine Renault Tanger Méditerranée.
FIPAR Holding, filiale marocaine de la CDG (Caisse de Dépôt et de Gestion), est actionnaire
de Renault Tanger d’exploitation à hauteur de 47,6 %.
Un projet économique, industriel et humain d’envergure
 Inauguration du site industriel de Renault-Nissan de Tanger (Maroc)
La nouvelle usine de l’Alliance située à Tanger a été inaugurée en présence de Carlos Ghosn,
Président de Renault et de Nissan, et de Sa Majesté le Roi du Maroc Mohamed VI.
Ce fut l’occasion pour chacun de redécouvrir le chemin parcouru, depuis la signature des accords
définitifs le 18 janvier 2008 jusqu’au premier accord de fabrication de l’usine, celui du monospace
Dacia Lodgy obtenu le 27 janvier 2012.
Après l’usine de Chennai pilotée par Nissan en Inde, l’usine de Tanger, pilotée, elle, par Renault,
est la deuxième usine commune de l’Alliance. Dédié à la production de deux véhicules de la

gamme M0, le monospace Lodgy et un petit utilitaire (également décliné en version VP), le site
industriel marocain aura, à terme, une capacité maximale de production de 400 000 véhicules/an.
 Un site industriel international
Le site Renault Tanger Méditerranée sera une usine d’assemblage complète réalisant
l’emboutissage, la tôlerie, la peinture et le montage. Avec un accès direct à la plateforme portuaire
du port de Tanger Med, les véhicules qui sortiront des ateliers seront à 90 % destinés au marché
international.
Cette usine viendra compléter le dispositif industriel de Renault pour les véhicules
économiques dérivés de la plateforme Logan et démarrera avec 2 modèles nouveaux dans la
gamme.
Avec une capacité de production atteignant à terme 400 000 véhicules par an, un effort
d’investissement de 1,1 milliard d’euros, la création de plus de 6 000 emplois directs et 30.000
emplois indirects et une superficie de 300 hectares, l’usine de Tanger représentera l’un des
complexes automobile industriels les plus importants du bassin méditerranéen. Ce sera également
un vecteur de développement économique important pour le Nord grâce au renforcement du tissu
industriel marocain de fournisseurs, sous-traitants et équipementiers, et au développement de
nouvelles compétences que l’usine va susciter. A ce titre, un centre de formation est créé au sein
du complexe industriel. Le 30 octobre 2008, Renault signait avec le gouvernement marocain une
Convention pour la réalisation de cet Institut de Formation aux Métiers de l’Industrie Automobile
 Tanger Méditerranée (IFMIA/TM) pour un investissement global de 7,5 millions d’euros.
L’objectif : former d’ici 2012 dans un premier temps 4 000 personnes via 750 000 heures de
formation, dont les deux tiers se dérouleront dans les locaux du centre, le tiers restant étant assuré
à l’étranger dans les autres usines du Groupe. Spécialement dédié au développement des
compétences des futurs salariés de l’usine et à ceux de certains fournisseurs, le Centre s’étalera sur
une superficie de 1,5 hectare et comptera 22 écoles de dextérité, 8 ateliers de formation en
maintenance ainsi que de nombreux locaux pour la formation tertiaire. Le CFMATM accueillera
250 stagiaires à la fois, pour leur assurer une formation à l’embauche et des formations continues
à différents niveaux : opérateurs, techniciens, cadres.
1.2.2 Processus de fabrication

Le processus de fabrication d’un véhicule peut se découper en quatre grandes étapes :

 Emboutissage
Atelier d’emboutissage
L’emboutissage consiste en la fabrication des éléments de carrosserie à l’aide de presses. Les

rouleaux de tôle arrivent par trains ou poids lourds et sont découpés puis compressés pour leur
donner la forme voulue. Les pièces obtenues sont alors transférées dans des containers à la tôlerie.
 Tôlerie
La tôlerie se décompose en plusieurs étapes. Premièrement, les éléments de base arrivant de
l’emboutissage sont assemblés en blocs élémentaires composant la carrosserie : les unités.
Atelier Tôlerie
 Peinture
La peinture comprend le passage des caisses en cataphorèse, qui est un traitement anticorrosion
par électrodéposition. S’en suivent les différentes étapes de peinture : masticage, application des
laques, cuisson. Enfin, de la cire est injecté dans les corps creux pour compléter le traitement
antirouille.
Atelier Peinture
 Tri-stock
Remettre dans l’ordre pour le montage selon la commande des clients

Atelier Tri stock
 Montage
Le montage regroupe tout l’habillage des véhicules. Ceux-ci sont tous d’abord débarrassés de
leurs portes qui sont équipées en parallèle puis reçoivent les premiers équipements (garnitures et
planche de bord). Le groupe motopropulseur (moteur, boîte de vitesse, train roulant avant et
équipements) est monté, ainsi que le train arrière. Les portes sont ensuite remontées et les derniers
éléments sont ajoutés (pare-brise, sièges, etc.) Différents tests et contrôles sont effectués. La
voiture est terminée et prête à être livrée.
Atelier montage
 Le bout d’usine.
Banc de tests dynamiques (à rouleaux) : Parallélisme, Test électrique véhicule, Phares
Le bout d’usine

Synthèse :
1. La tôlerie fabrique une « caisse »
2. La peinture peint la caisse
3. Le tri-stock trie les véhicules avant le montage
4. Le montage habille la caisse (moteur/boite, tableau de bord, intérieurs, roues,
électronique...)
5. Le bout d’usine contrôle le véhicule, la retouche si nécessaire
1.2.3 Organigramme
Figure 1.1 : Organigramme Renault
1.3 Département système d’information

1.3.1 Présentation DSI Manufacturing :
Un système d’information est l'organisation et les outils qui permettent aux acteurs d'une
entreprise de communiquer, de traiter et de stocker des informations. Il représente l’ensemble des
éléments participant à la gestion, au stockage, au traitement, au transport et à la diffusion de
l’information au sein d’une organisation ou entreprise.
- Dans un système d'information d'une grande entreprise, on trouve :
 Un ERP - Enterprise Resource Planning (en français : PGI pour progiciel de gestion
intégré) - qui intègre tous les systèmes informatisés permettant de soutenir le
fonctionnement de l'entreprise ;

 Des systèmes appelés « spécifiques » (ou encore : non standards, de conception

« maison », développés sur mesure, que l'on ne trouve pas sur le marché, ...), où l'on
rencontrera davantage d'applications dans les domaines du calcul de coûts, de la
facturation, de l'aide à la production, ou de fonctions annexes.
La proportion entre ERP et systèmes spécifiques est très variable d'une entreprise à l'autre.
L'urbanisation traite de la cartographie des systèmes de l'entreprise et donc de son système
d'information.
Dans les ERP, on trouve des modules couvrant différents domaines d'activité (comme la gestion
de la production, la gestion de la relation commerciale avec la clientèle, la gestion des ressources
humaines, la comptabilité, ...) autour d'une base de données commune.
Il est fréquent qu'une entreprise soit équipée de plusieurs progiciels différents selon ses domaines
d'activité. Dans ce cas, les progiciels ne sont pas totalement intégrés comme dans un PGI, mais
interfacés entre eux ainsi qu'avec des applications spécifiques.
Le département système d’information de fabrication de la société Renault utilise des systèmes
d’information spécifique. Ces deniers permettent de piloter et contrôler les flux de fabrication,
piloter les indicateurs qualité de la fabrication, assurer la maintenance et la fiabilité industrielle, et
gérer les ordres de fabrication. Ceci en utilisant les systèmes d’information suivants :
- SIPTOL : Pilotage et suivi du flux véhicules en Tôlerie. Ensemble de fonctions permettant
la fabrication de caisses « en blanc » à destination de la peinture et la fabrication
d'ensembles destinés à être expédiés dans d'autres usines.
- SIPTK : Application permettant le suivi et le pilotage de l'ensemble des véhicules
transitant par un tri-stock. Elle a pour objectif de réordonnancer les véhicules en sortie de
peinture, selon le film ferme de montage, tout en respectant les contraintes de fabrication et
les demandes d'approvisionnement de l'usine.
- PSFV : PSFV assure, sur les différentes étapes de fabrication (Tôlerie, Peinture, Montage,
Bout d'usine), le pilotage du flux de fabrication, le suivi de la production, le recueil des
informations issues du processus ainsi que la diffusion de la diversité opératoire.
- GRET : Gérer les défauts et les retouches, ce système d’information permet la déclaration
des défauts sur les produits en cours de fabrication, le suivi des retouches réalisées, le
stockage et l’archivage de ces informations, le calcul d'indicateurs de qualité sur les
défauts.
SI Performance : Assure la maintenance et la performance industrielle, il permet de :

 Gérer la maintenance industrielle programmée des moyens de production

 Préparer la maintenance
 Organiser la maintenance
 Maintenir les installations
 Suivre les Moyens
 Suivre en temps réel les performances des moyens
 Animer le processus d’Analyse des Pertes
1.3.2 Organigramme DSI Manufacturing
Figure 1.2: Organigramme DSI Manufacturing
2. Contexte générale du projet :
Avec une capacité de production atteignant à terme 400 000 véhicules par an, un effort
d’investissement de 1,1 milliard d’euros, la création de plus de 6 000 emplois directs et 30.000
emplois indirects et une superficie de 300 hectares, l’usine de Tanger représente l’un des
complexes automobile industriels les plus importants du bassin méditerranéen.

Dans sa politique, Renault laisse paraître une forte motivation pour l’amélioration de la qualité de
ses produits finis. Dans ce sens, Renault s’efforce de travailler ce point à tous les niveaux de la
fabrication des véhicules.
Actuellement l’usine produit environ 80 véhicules par jour, l’application des standards de Renault
ainsi que l’amélioration continue de l’entreprise sont quelques-uns des enjeux majeurs visés,
une grande partie des améliorations possibles passent par l’optimisation du système
d’informations dont dispose Renault, c’est dans ce cadre que s’inscrit notre projet de fin d’études
« Etude & amélioration du SI GRET/PSFV ».
Introduction
"The most profound technologies are those that disappear. They weave themselves into
the fabric of everyday life until they are indistinguishable from it”
Mark Weiser
Dans un environnement compétitif comme celui de l’industrie automobile : efficacité, qualité et

amélioration en continu sont les leviers du succès, l’information devient un élément critique pour
la réussite de l’entreprise, entre outre la possibilité d’avoir un accès facile et centralisé à
l’information présente un gain considérable.
Les systèmes d’information de Fabrication visent à répondre à des objectifs spécifiques :
 Réduction des coûts.

 Diminution des délais.
 Augmentation de la qualité.
Ils permettent ainsi aux fabricants et à leurs managers d’augmenter leur réactivité, optimiser leur
gestion de la production ainsi qu’améliorer et accroître leur rentabilité. D’une manière générale,
les systèmes d’information de fabrication visent à :
 Piloter et contrôler les flux de fabrication.

 Piloter les indicateurs qualité de la fabrication.
 Assurer la maintenance et la fiabilité industrielle.

 Gérer les ordres de fabrication.
Plus particulièrement, la fonction de pilotage des flux de fabrication a pour objectif d’assurer
d’une part, aux opérateurs les instructions qui leur permettent de piloter leurs équipements de
production et de suivre les pièces à fabriquer et d’autre part, aux managers, des tableaux de bord
pour le suivi de production, des alertes sur la disponibilité des moyens qui aident à faire le
monitoring des processus de fabrication et le maintien de l’amélioration continue.
Dans cette optique, PSFV et GRET ont été développés par les équipes informatiques de la société
Renault afin d’assurer le pilotage et le suivi des flux des véhicules et la détection des retouches
tout au long de la chaine de production.
Ce sont deux systèmes à la fois critiques et transverses qui sont déployés sur tous les ateliers de
fabrication de l’usine : la tôlerie, la peinture, les sous-ensembles ainsi que le montage.
Notre projet a pour objectif l’étude des SI Qualité « GRET/PSFV » et l’amélioration de ces
systèmes pour répondre aux besoins de Renault Tanger dans la vie série de production.
2.1 Objectif
L'objectif de ce projet est d’une part de faire l’étude sur les SI Qualité notamment les systèmes
majeurs de gestion de flux de la production tel que GRET & PSFV, et d’autres part, améliorer et
étendre les fonctionnalités de bases de ces systèmes. En complément on cherche à standardiser les
procédures de communication et de diffusion des flux d’information relatifs à GRET/PSFV entre
les différentes entités du site appartenant au périmètre « Qualité » (fabrication/qualité/SI).
Pour la réalisation de ces objectifs la solution choisie est la mise en place d’un système
complémentaire qui puisse répondre à ces besoins. Ce système s’adresse à 3 niveaux
d’utilisateurs :
 Chefs d’UET.
 Chefs d’atelier.
 Chefs de département.
En pratique ce système doit satisfaire les requis suivants :
 Permettre le suivi de l’actualité coté qualité.
 Permettre le suivi des détails de productions à travers des rapports.

 Permettre le suivi des statistiques de productions (fonction tableau de bord) en implémentant

le calcul de plusieurs indicateurs qualité.
 La standardisation des flux de travail à l’intérieur du périmètre « qualité » en implémentant
plusieurs workflow.
 La réalisation d’une cartographie pour les systèmes GRET & PSFV.
 une documentation GRET/PSFV.
 Autres fonctionnalités...
2.2 La méthodologie adoptée

2.2.1 Les méthodes agiles
Les méthodes agiles, peuvent être définies comme «des procédures de conception de logiciels qui
se veulent plus pragmatiques que les méthodes traditionnelles. En impliquant au maximum le
demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la
satisfaction réelle du besoin du client, et non des termes du contrat de développement ».
Les principes qui régissent les méthodes agiles, ainsi que les différences fondamentales qu’ils ont
par rapport aux méthodes dites classiques sont les suivants :
 Mettre en œuvre des individualités et des interactions,
 Produire un logiciel entièrement testé et qui fonctionne,
 Collaborer avec le client,
 Répondre aux modifications
- Cela réclame des outils de suivi et une attitude constante de coopération avec le client.
2.2.2 Un comparatif des méthodes agiles
- Dans cette partie on va réaliser un comparatif entre les méthodes agiles les plus connues, le
résultat est présenté sous forme d’un tableau.
Méthodes comparées :
Méthode Points clés Inconvénients
Développement guidé par les Focalisation sur l’aspect individuel du
besoins du client. développement, au détriment d’une vue
Extreme • Equipes réduites, centrées globale
Programmin sur les développeurs par binomes. et des pratiques de management ou
g (XP) • Builds journaliers, amélioration, de formalisation. Risque de manquer de
constante, adaptativité aux contrôle et de structuration en laissant les
modifications.. développeurs trop libres de dériver par
rapport aux fonctions de l’application.

Rational Processus complet assisté par Lourd, largement étendu, il peut être difficile
Unified des outils. à mettre en oeuvre de façon spécifique.
Process • Rôles bien définis. Convient pour les gros projets qui génèrent
(RUP) beaucoup de documentation.
Petites équipes, itérations de 30 La mise en œuvre du développement n’est
(Scrum) jours, réunions journalières. pas précisée, seule compte la gestion des
ressources humaines.
2.2.3 Le choix de la méthodologie Scrum

- D’avantage qu’une méthode formelle, Scrum, illustré par la figure 1.3(cycle de développement
d’un projet SCRUM), peut être vu comme un framework méthodologique dont l’implémentation
doit être ajustée en fonction des caractéristiques techniques, organisationnelles et culturelles des
projets qui souhaitent la mettre en œuvre (Scrum, au demeurant, ne limite pas son champ
d’application aux seuls projets informatiques : ses principes sont applicables pour toute activité
visant à produire un résultat).
- Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies et d’artefacts qui
permettent de relever les défis principaux du développement incrémental : la planification, la
gestion du temps et la gestion des obstacles. Scrum est entièrement piloté par la Valeur Métier.
La gestion des risques, en particulier, est réalisée au travers de ce prisme.
Figure 1.3 : cycle de développement d’un projet SCRUM

2.2.4 La méthodologie Scrum

 Introduction à la méthodologie Scrum
Le terme Scrum (qui signifie «mêlée »en rugby) se rapproche plus d’une gestion de ressources
humaines plutôt que d’une réelle méthode de développement. Il s’agit ici de ne pas oublier le côté
humain du développement.
Les principales caractéristiques de Scrum sont :
 Identifier les changements très tôt.
 Donner toute confiance aux développeurs et les laisser faire leur travail.
 Faire des itérations variantes (généralement de 30 jours), appelés aussi «sprints »pour
laisser le temps de coder. Chaque itération a un objectif bien précis ou «backlog »et fournit
une nouvelle fonctionnalité testée (une démonstration est faite à la fin de chaque sprint).
 Faire des réunions tous les jours (daily meeting) et chaque semaine (weekly meeting) pour
encadrer les équipes et recaler les objectifs.
 Évènements SCRUM
Le Sprint : Le Sprint est une période d'un mois Réunion de Planification de Sprint : Tout le monde est présent
maximum, au bout de laquelle l'équipe délivre un à cette réunion, la réunion de planification (Sprint Planning
incrément du produit, potentiellement livrable. Meeting) se passe en deux temps. Dans la première partie,
l'équipe de développement cherche à prévoir ce qui sera
1.1.1 développé durant le prochain Sprint.
Dans un second temps l'équipe se focalise sur la manière dont ils
Scrum Quotidien : Au quotidien, une réunion, le atteindront le but du sprint.
Scrum quotidien (Daily Scrum), permet aux
1.1.2
Développeurs de faire un point de coordination sur
Revue de sprint : À la fin du sprint, tout le monde se réunit pour
les tâches en cours, et sur les difficultés rencontrées.
effectuer la revue de sprint, qui dure au maximum 4 heures.
Cette réunion dure 15 minutes maximum.
L'objectif de la revue de sprint est de valider le logiciel qui a été
1.1.3 produit pendant le sprint.
Rétrospective du sprint : La rétrospective du sprint est faite en interne à l'équipe (incluant le ScrumMaster). Elle dure 3 heures
pour un sprint d'un mois, et réduit selon la durée du sprint.
- L'objectif est de comprendre ce qui n'a pas bien marché dans le sprint, les erreurs commises et de prendre des décisions pour
s'améliorer.
 Les rôles de SCRUM
 Scrum identifie trois acteurs :

 Le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle et est à
même de réaliser les arbitrages nécessaires à la priorisation des développements. Son rôle

est absolument essentiel, et son respect des règles du jeu est la pierre angulaire du succès
d’un projet agile.
 Le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser la
capacité de production de l’Equipe en l’aidant à travailler de façon autonome et à
s’améliorer constamment. Il est également le garant de la bonne implémentation de Scrum.
 L’Equipe, dont la taille doit être réduite, et qui prend en charge le développement du
produit (planification, conception, codage, tests, documentation) Après avoir fait le choix
de la méthodologie, qui est une étape primordiale dans le cycle de développement d’un
produit informatique, nous exposerons dans le paragraphe suivant la problématique auquel
nous sommes amenés à développer une solution.
2.3 Planification
Afin d’aboutir dans l’exécution de notre travail, nous avons adopté le planning prévisionnel
suivant :
 Diagramme de Gantt :

Figure 1.4 : Diagramme de Gantt (planning de réalisation)
Chapitre II
Etat de l’art
Nous consacrons ce chapitre à l’étude de l’état de l’art.

Nous avons choisi d’étaler cette étude sur 4 parties : tout
d’abord nous commençons par une présentation des
systèmes d’informations dont il est question, la partie
suivante est consacrée à l’architecture BI (Business
Intelligence) utilisé par Renault, la 3éme partie décrit les
procédures de travails au sein du périmètre
DSI/Qualité/Fabrication, finalement la 4éme partie est
dédiée à l’architecture Intranet utilisée par Renault.

1. Les systèmes d’informations de fabrication GRET/PSFV
1.1 Fonctionnement du système PSFV

1.1.1 Généralités PSFV
 Notions sur PSFV (pilotage et suivi du flux de véhicule).
On appelle Flux de véhicules, l’ensemble des véhicules, de leur position (zone courante) et de
leurs déplacements (changements de zone), exprimés dans le temps modélisé en tranches horaires
(Calendrier de production).
On appelle Suivi, l’ensemble des opérations et des systèmes de mesure du Flux de véhicules :
En termes quantitatifs : Quand ces véhicules sont-ils passés par ici ?
En termes qualitatifs : Combien de véhicules sont-ils sortis bons d’ici ?
On appelle Pilotage, l’ensemble des opérations et des systèmes qui conditionnent et modifient le Flux
de véhicules :
 Bloquer les véhicules dans une «zone».
 Orienter les véhicules à une «Pré-signature».
1.1.2 Périmètre et responsabilité
 Périmètre
PSFV couvre le périmètre du processus de fabrication, de l'enchaînement administratif jusqu'à la

"Mise à Disposition par l’Usine" (MADU) du véhicule à la Distribution Aval (Centre Livraison-
Expédition "CLE").

 Couverture :
Demandes commerciales
Affectation
PSFà –l’usine
Véhicules connait les véhicules pendant leur fabrication
Figure 2.1 : PSFV dans le contexte usine de fabrication
Ordonnancement en « journées » Fabrication Distribution
Figure 2.2: Couverture macroscopique

 Responsabilité :
Responsabilité usine
CLE
Carnet Tôlerie Peinture TK Montage Finition
Couverture PSF-véhicule
PSF-véhicule connait les véhicules depuis leur « accrochage administratif » jusqu’à MADU + 1 jour
MADU
Figure 2.3 : Responsabilité de PSFV dans l’usine

1.1.3 Fonctionnalités
- PSFV assure, pendant les différentes étapes de la fabrication (Tôlerie, Peinture, Montage, Bout
d'usine), le pilotage du flux de la fabrication, le suivi de la production, le recueil des informations
issues du processus ainsi que la diffusion de la diversité opératoire.

Il s'agit donc de:
 Lancer les films de fabrication, prendre en compte les contraintes processus et optimiser le
flux en conséquence.
 Veiller au respect de l'ordre et du délai de fabrication (vieillissement).

 Aider les opérationnels sur le pilotage du flux en cas d'aléas de la fabrication.
 Communiquer la diversité opératoire aux différents moyens de production des chaînes
principales et de préparation, y compris pour les fournisseurs dits « synchrones » et les
systèmes de pilotage d'atelier si nécessaire.
 Pilotage du flux véhicule (blocage, orientation, contrôles qualité).
 Un module de PSFV, EVE, pilote l'exécution du Processus Electronique Véhicule
(chargement des calculateurs et contrôle du fonctionnement des fonctions électriques et
électroniques du véhicule).
 Editer les différents documents légaux devant accompagner le véhicule fabriqué.
 Recueillir du processus de fabrication, les informations sur le produit (traçabilité, qualité).
 Suivre et restituer en temps réel, l'avancement de la fabrication par rapport aux objectifs
quantitatifs et qualitatifs fixés.
- Alors le système PSFV gère en temps réel les flux de véhicules, de la Tôlerie jusqu’au bout d'usine.
1.1.4 Fonctions de pilotage de la production
Comme vu précédemment l’une des fonctions essentielles de PSFV est le pilotage du flux
véhicule, dans ce qui suit on va découvrir en détails les notions de blocage, orientation, contrôles
qualité qui sont en rapport directe avec l’étude réalisée.
a. Remontée des informations de passage :
Deux types de points : points PSFV (de passage, ou de captage), points de dialogue (automate),
chaque point de dialogue (automate avec PSFV) peut être défini comme un point de remontée
d’informations de passage. Au niveau de ces points de passage l’identifiant primaire ou secondaire
du véhicule est transmis à PSFV qui change le véhicule de zone courante pour des besoins de suivi
des encours ou de suivi de production.
 On distingue 2 types de points PSFV :
Point de passage : il permet d’orienter un véhicule vers une zone parmi plusieurs.
Point de captage : c’est un point de saisie des défauts (Module GRET).
b. Orientation des véhicules :

Le flux de véhicules n’est pas direct et de nombreuses bifurcations sont possibles pour des raisons
liées au processus, aux retouches ou encore aux contrôles (suivant le type de processus, un
véhicule peut suivre plusieurs orientations). Pour orienter un véhicule, l’API en charge du point
d’orientation a deux possibilités : choisir l’orientation en se basant sur des données stockées dans
sa mémoire (gestion API) ou la choisir en se basant sur des données stockées dans le système de
pilotage (saisies sur GRET gérées par PSFV).
Solution API Solution PSFV
Pas besoin de liaison avec PSFV à Données d’orientation stockées par un
Avantages chaque point de saisie d’orientation ou à système robuste et fiable et disponible
chaque point d’orientation du véhicule. dans tout l’atelier
Risque de perte des données en cas
Nécessité d’un dialogue PSFV à chaque
d’erreur API
Inconvénients point de saisie et à chaque point
Risque de décyclage de la pile API lors
d’orientation
de la transmission d’un API à l’autre
 Particularités de la gestion PSFV

Sous PSFV, pour gérer l’orientation d’un véhicule, il existe deux notions sensiblement différentes :
l’orientation et la pré-orientation.
 Orientation PSFV
A un point de saisie d’orientation PSFV, l’API ou l’opérateur (via une console PSFV) peut
remonter à PSFV une orientation pour le véhicule présent.
L’orientation consiste pour PSFV à modifier la zone courante du véhicule : le véhicule passe donc
informatiquement dans la zone destination sans avoir pour autant changé physiquement de place à
ce moment précis.
Remarque : A un point de saisie d’orientation, PSFV peut faire des propositions d’orientations
mais le choix est toujours réalisé par un API ou par un opérateur
 Pré-orientation PSFV
La saisie de pré-orientation consiste à remonter à PSFV, l’orientation souhaitée pour le véhicule
mais sans changer sa zone courante. Cette information est stockée par PSFV pour être utilisée
ultérieurement au niveau des choix de parcours du véhicule. Cette information sera alors
descendue à un API qui pourra au choix :
 La recevoir sans l’appliquer
 La recevoir et l’appliquer (prise en compte comme orientation)
 La recevoir et appliquer une orientation différente, s’il le juge nécessaire (cas
d’une zone saturée …)

 Orientation vers zones de retouches

Au bout de la zone de finition, compte-tenu des retouches détectées, l’opérateur choisit sur la console
PSFV l’orientation voulue pour le véhicule. En fonction du mode de fonctionnement choisi, cette
information peut être, soit remontée en tant qu’orientation, soit en tant que pré-orientation.
Remarque : Cette orientation est indépendante de la saisie des défauts réalisée sous GRET.
Suite à la retouche, il est possible de saisir une nouvelle orientation sur la console PSFV :
 Nouveau passage sur le même type de retouche.
 Envoi vers un nouveau type de retouche.
 Recirculation sur la chaîne principale.
 Suite du processus normal.
Aux divers points d’orientation entre la zone de finition et la zone de retouche, lorsque l’API a
besoin de connaître la destination d’un véhicule, il remonte l’identifiant (primaire ou secondaire)
du véhicule concerné à PSFV qui lui renvoie l’orientation ou la pré-orientation de ce dernier.
Cette information est donc utile :
 Au niveau du processus de fabrication pour orienter le véhicule vers la zone de
retouche.
 En entrée de la zone de retouche pour orienter le véhicule vers les stocks dédiés à
chaque type de retouche.
 Au niveau des postes de retouche pour orienter le véhicule selon le type de retouche
choisi en finition.
 En sortie de la zone de retouche pour orienter le véhicule vers le flux principal, vers
une nouvelle retouche ou vers un second tour.
 Orientation vers les zones de contrôles

Les sorties de véhicules pour contrôle (Qualité, AVES, …) peuvent être gérées :
 En local : le prélèvement est géré par l’intermédiaire d’un appui-bouton en bord de chaîne.
 Par PSFV : par le biais d’une famille PPUM spécifique
Une fois le véhicule contrôlé, il peut être réintroduit dans le flux principal.

1.2 Fonctionnement du système GRET

1.2.1 Généralités GRET
 GRET signifie la gestion de retouche c’est un module de PSFV qui répond aux besoins
suivants :
 Captage des données véhicules.
 Aider au management QCD de la production.
La gestion des retouches est une nécessité, malgré une maîtrise de la conformité en progrès
constant, la retouche reste indispensable :
 Elle permet de livrer au client un véhicule conforme aux normes qualité
 Elle fait face aux problèmes non maîtrisés par le processus de fabrication
Mais retoucher les véhicules, c'est prendre un risque
 de qualité (risque de dégradation d’une autre prestation du véhicule)
 de coût supplémentaire
 de délai, en retardant la livraison au client
En principe l’objectif d'entreprise est mené à un objectif de qualité qui se traduit que chacun fasse
"bon du premier coup", seul moyen pour avoir une qualité performante, et aussi se traduit dans le
plan de surveillance global qui permet de maîtriser la conformité du produit et du processus et
d’évaluer son efficacité au travers des critères du processus et des audits produits.
 GRET s'inscrit dans le cadre du plan de surveillance et permet une gestion active des retouches
dans le but d'en réduire le nombre et les impacts.
Les apports de GRET Fonctionnalités de GRET
 GRET permet essentiellement : 1. Captage :
 D'enregistrer les défauts constatés en ligne  Saisie des défauts (Ecran VT, Poste SPIN, Poste
ou en plateau. d’aspect tactile)
 D'orienter les véhicules vers les zones de  Remontée automatique des défauts, SAO
retouches appropriées. (système anti-oubli) vissage,
 De saisir les retouches effectuées, en ligne  Remplissage, Fonctions électriques.
ou en plateau.  Saisie des retouches et requalification des
 D'informer les UET en amont des défauts
défauts qu’elles génèrent (alertes). 2. Pilotage :
 D’enregistrer les audits réalisés et leurs  Analyse des défauts de l’encours de fabrication

résultats.  Alertes vers l’UET imputée en cas de répétition

 De calculer les indicateurs de résultats 3. Reporting :
(STR*, PAD*, Entrabilité…).  Analyse des défauts (historique des 16 derniers
 D‘alimenter l'animation des actions de mois)
réduction des retouches.  Parétos
 Indicateurs Qualité
1.2.2 Notions sur le captage et les retouches
a. Captage défaut
Le captage de défaut peut être effectué tout au long du périmètre de l’usine, il permet de remonter
au système les défauts constatés sur un véhicule, cette information est essentiellement utile pour la
retouche, plus le défaut est décrit avec détails plus la retouche sera rapide et efficace.
Les informations relatives au captage des défauts sont exploitables par les fabricants qui peuvent
en tout moment vérifier l’efficacité de leur périmètre de travail (UET, Atelier, Département).
 L’efficacité de ce système est basée sur les règles suivantes :
Captage des défauts dans chaque UET Utilisation du Reporting de GRET pour l’animation
 Un poste de captage mini par UET  À tous les niveaux : UET, atelier, département
 Saisie de tous les défauts
GRET (captage) Utilisation des fonctions de suivi des

Saisie des retouches avec
défauts de l’encours et des alertes
requalification des défauts
pour une réactivité maximum, grâce
à la fonction « Fil de l’Eau »
Captage des défauts au bout du
montage
Utilisation des captages
Surveillance de la bonne documentation pour l’orientation vers les
 Pas de défaut générique retouché sans requalification plateaux de retouches, la
 Documentation correcte des UET imputées signature en blanc
 Audits sur l’exhaustivité et la qualité de la documentation
Figure 2.4 : Règles du captage défaut
b. Captage dans le cadre de l’autocontrôle
rois types de d

ar l’opérateur
 le défaut signalé, retouché ou non
 si le défaut est imputable à l’UET, le poste qui a appelé  NR
 si le défaut n’est pas imputable à l’UET, pas de poste  NNS
 Par le checkman, qui contrôle selon sa gamme
 les défauts constatés, retouchés ou non, non déclarés précédemment par
l’opérateur senior
 Par l’auditeur externe, qui contrôle selon sa gamme
 les défauts constatés, non déclarés précédemment :
 Défauts actifs : véhicule KO  NQ
 Défauts retouchés : véhicule OK
 si tous les défauts éventuels ont déjà été déclarés, véhicule OK
c. Retouche ou reprise de défaut

Reprise des défauts détectés sur les véhicules en ligne de finition. L’atelier de retouche est
habituellement constitué de postes dédiés au différents types de retouches à réaliser ;
 Postes fixes permettant des petites retouches (maximum de la taille d’une feuille A4)
appelé raccords noyés.
 (Préparation + Application + Cuisson) permettant des retouches plus importantes et
sur plusieurs parties du véhicules.
 Grosse retouche au niveau de laquelle on peut réaliser des échanges d’ouvrants et un
ponçage complet ou partiel du véhicule avant de le renvoyer sur chaîne principale
pour une nouvelle application
En amont de la retouche, les véhicules à reprendre sont habituellement orientés dans
des stocks dédiés à chaque type de retouche en attendant d’être appelés sur un
poste d’application par un opérateur.
1.2.3 Glossaire des termes utilisés dans GRET
 Élément : partie ou pièce du véhicule (ex: capot).
 Incident : nature du problème (ex: rayure).
 Défaillance : description d’un défaut potentiel par l’association d’un élément et
d’un incident.

 Défaut : incident constaté sur un élément d’un véhicule,

occurrence d’une défaillance.
 Populations concernées par GRET :
En usine (local) En central

1- L’administrateur GRET local 1- L’administrateur central GRET
2- Pour le captage : 2- L’ingénierie pour le Reporting
 Les opérateurs senior, les auditeurs  Coordination/pilotage des DIVd : ex DIESE
autocontrôle, les checkmens.  Analyse des défauts des fonctions gérées ex :
 Les auditeurs PESD, les contrôleurs CSC Remplissage, vissage
S/D.
 Les retoucheurs
3- Pour le reporting :
 Les chefs d’UET, chefs d’atelier, chefs
de département
 Les auditeurs et analystes du service
Qualité
 L’ingénierie DIVd
1.2.4 Application GRET (Captage des défauts liés aux véhicules)

- Il s’agit de l'ensemble des processus à mettre en œuvre pour capter des données véhicules en
provenance du processus « fabriquer les véhicules ».
Déclarer et reprendre des défauts Capter manuellement:
Se fait par l'intermédiaire du module GRET, intégré à PSFV, qui
permet de:
 déclarer les défauts :
 Saisir le défaut (élément + incident)
 Contrôler l'existence du défaut dans FPSFV_DEFAUT
 Contrôler l’état du défaut (actif/non actif)
 Saisir la zone de constatation du défaut
 Contrôler la zone de constatation
 Contrôler la technique du défaut
 reprendre les défauts :
 Saisir la zone de reprise
 Contrôler la zone de reprise

Captage automatique :
 Se fait par interfaçage de GRET aux modules de captage
automatique via API ou PEV
Capter les manque-pièces Captage manuel :
(manuel, automatique, sur encours)  Déclarer les manques pièces :
 Saisir le manque pièce
 Contrôler l'existence du manque pièce dans
FPSFV_MQ_PIECE
 Contrôler l'état du manque pièce
 Contrôler que le manque pièce n'est pas actif sur le véhicule
 Saisir la zone de constatation du manque pièce
 Contrôler la zone de constatation
 Reprendre les manques pièces :
 Saisir la zone de reprise
 Contrôler la zone de reprise
Captage automatique :
(Défaut électronique, défaut décodé et remonté par l’API)
Capter la traçabilité unitaire  Saisir l'information de traçabilité, contrôler le format de
pièces saisie.
 Contrôler la conformité sur l'élément
Capter la traçabilité électronique  Captage de l'information de traçabilité transmise par les
Moyens PEV
Aider au management QCD de la  Il s’agit de respecter le volume, la séquence et
production l’horaire programmés, les délais de livraison et la
cohérence entre le flux véhicule et le flux pièce.
Fonctions remarquables de l’application GRET:
nimer la qualit
 Suivre les compteurs de production (tableaux) : Consulter les encours des flux entrants et sortants
d'une zone en regard des objectifs, visualiser les écarts entre réalisés et objectifs,…, PAD, taux de
signature

uivre les encou
igner un véhic
L’évènement physique BCC (Bon, Complet, Conforme) signifie que la qualité du véhicule est validée,
par un certain nombre de contrôles : il ne présente aucun défaut, aucun manque pièce, absence de
blocage, aucune information de traçabilité manquante, présence du N° de châssis, du numéro de
fabrication, absence de réalignement, pas de consigne particulière, blocage, statut qualité…etc.
 Livrer un véhicule (MADU) : Imprimer la fiche d’équipement volatile (FEV), Imprimer l’ordre de
livraison (OL), Capter la Mise à Disposition Usine (MADU) du véhicule pour la livraison aval
Figure 2.5 : Ecran de Captage GRET Poste Tactile déployé au département peinture
Figure 2.6 : Ecran de Captage manuelle GRET Poste SPIN

1.3 Fonctionnement globale de NGRET et PSFV

NGRET PSFV
 Gestion des catalogues  Captage des défauts et des retouches
 Reporting  Pilotage
Figure 2.7 : Référentiel GRET
Ce schéma décrit le fonctionnement global de NGRET (nouveau GRET) et PSFV :

 Utilisation d’un catalogue central :
- Éléments et incidents codifiés en cohérence avec MUSES par l’administration centrale.
 Utilisation d’un catalogue de défaillances par l’administrateur local :

- Association des éléments et des incidents, Documentation des UET d’imputation.
 Documentation de regroupements pour aide à la saisie, restitutions, …
 Paramétrage des postes de travail, des points de saisie, des zones :
- Pour simplifier le captage.
- Pour le calcul des indicateurs, les restitutions.
1.4 Problématique

- Le nombre élevé de postes PSFV et GRET rend leurs gestion de plus en plus difficile (48 postes
GRET, 190 postes PSFV dont 180 imprimantes) :
 traquer les déplacements (localisations).
 suivre les pannes.
 changements de paramétrages (adresse IP, nom de machine, responsables, contextes
d’utilisateurs…)
1.5 Conclusion
- PSFV et GRET assurent le pilotage, le suivi des flux de véhicules ainsi que la détection des
retouches tout au long de la chaine de production.
Ce sont deux systèmes à la fois critiques et transverses qui sont déployés sur tous les ateliers de
fabrication à l’usine : la tôlerie, la peinture, les sous-ensembles ainsi que le montage.
Nous avons pu découvrir dans cette partie les fonctionnalités de chaque système, dans la partie
suivante, on va découvrir d’avantage la partie Reporting de GRET.

2. Business intelligence & BO
2.1 Introduction
Dans la partie précédente on a introduit le système GRET qui permet entre autres :
 la saisie des défauts (Ecran VT, Poste SPIN, Poste d’aspect tactile)
 la remontée automatique des défauts, SAO (système anti-oubli) vissage,
remplissage, Fonctions électriques.
 La saisie des retouches et requalification des défauts
L’objectif de la qualité est d’exploiter ces informations afin de pouvoir mener des analyses sur la
production, ces analyses peuvent être avec plusieurs finalités :
 Analyse des défauts (détails des défauts de fabrication).
 Calcul des indicateurs qualité.
Pour pouvoir mener ces analyses une nouvelle couche (décisionnelle) doit venir s’ajouter à GRET,
c’est la partie GRET Reporting.
Dans cette partie on va découvrir GRET Reporting avec l’architecture sous-jacente. Pour cela un
rappel sur la BI (Business Intelligence) est nécessaire.
2.2 Présentation de la B.I.

« L’informatique décisionnelle (ou BI pour Business Intelligence) désigne les moyens, les outils et
les méthodes qui permettent de collecter, consolider, modéliser et restituer les données, matérielles
ou immatérielles, d'une entreprise en vue d'offrir une aide à la décision et de permettre aux
responsables de la stratégie d'entreprise d’avoir une vue d’ensemble de l’activité traitée. »
- Une entreprise est généralement composée de plusieurs services tels que les ressources
humaines, les services comptabilité, marketing, commercial, technique… Tous conservent des
informations propres à leurs fonctions : listes des clients, des employés, chiffres, emplois du
temps… L’accumulation de ces données nécessite donc leur sauvegarde dans le but d’une future

exploitation. On constate ainsi régulièrement que chaque service possède son tableau de bord, ce
qui lui permet de mesurer les indicateurs de performance de l’entreprise (chiffre d’affaire, calculs
de bénéfices à l’année…). Cependant, chaque service a bien souvent sa façon de stocker ses
informations (par exemple dans un fichier Excel, une base de données MySQL…), et sa manière
de calculer les indicateurs, avec sa vérité et ses critères. Ainsi, si l’on veut considérer les données
de l’entreprise dans son ensemble, la tâche s’avère rude voire parfois impossible. Pourtant, cela
constituerait une utilité évidente et un réel apport à la société. En effet, une mise en relation et une
analyse de toutes les données permettraient de réaliser des études et des prévisions sur le
comportement et la « santé » de l’entreprise.
2.2.1 Architecture BI
Ensemble de solutions informatiques permettant l’analyse des données de l’entreprise, afin de
pouvoir dégager les informations qualitatives nouvelles qui vont fonder des décisions, qu’elles
soient tactiques ou stratégiques.
Figure 2.8 : Solution BI
Le but de la BI est d’apporter une vision globale des données de l’entreprise, afin de répondre aux
problématiques de celle-ci, ou tout simplement, afin de l’évaluer. Pour y arriver, le Business
Object met donc à disposition une plateforme qui illustre ce cheminement. Avant d’évoquer les
bases de celles-ci, il est essentiel de connaitre le concept du datawarehouse.
2.2.2 Le datawarehouse
Comme expliqué précédemment, la première étape d’un projet BI est de créer un entrepôt central
pour avoir une vision globale des données de chaque service. Cet entrepôt porte le nom de
datawarehouse. On peut également parler de datamart, si seulement une catégorie de services ou
métiers est concernée. Par définition, un datamart peut être contenu dans un datawarehouse, ou il
peut être seulement issu de celui-ci.

Figure 2.9 : Datawarehouse et Datamart
Un datawarehouse représente en fait une base de données, celles-ci étant intégrées (elles auront
subi une sorte de nettoyage qui les normalisera), non volatiles (c'est-à-dire qu’une fois les données
rentrées dans l’entrepôt, elles y restent pour de bon), et historisées (ou datées). C’est là la
différence avec des sources de données transactionnelles (systèmes OLTP). Grâce à la plateforme
business Object, cet entrepôt central sera rempli. Mais avant, il est indispensable de définir sa
structure.
2.2.3 L’ETL
Une fois la structure du datawarehouse définie, les données doivent être insérées. L’outil qui va
permettre le remplissage de notre base est l’ETL (Extract-Transform-Loading). Comme son nom
l’indique, il commence par extraire les données provenant de différentes sources (Excel,
MySQL…), les transforme si besoin est, puis les charge dans le datawarehouse.
Figure 2.10 : Principe de l'ETL
Ce processus se déroule donc en trois étapes :

 Extraction des données à partir d’une ou plusieurs sources de données telles que fichier
plat, fichier brut, OLE DB (source relationnelles telles que SQL Server, Access…),
Excel… ;
 Transformation des données agrégées ;
 Chargement des données dans la banque de données de destination (datawarehouse).
La phase d’ETL est ici incontournable car elle conditionne et influence la qualité du projet par la
suite.
2.2.4 L’application Business Object XI

Business Object : une plate-forme globale d'entreprise permettant de

rompre les barrières traditionnelles des déploiements de Business
Intelligence en fournissant à tous les acteurs décisionnels un accès
transparent aux informations essentielles.
 Généralités sur BO :
- C’est un outil décisionnel qui propose une gamme complète de fonctionnalités (reporting,
requêtage, analyses, tableaux de bord, visualisations, etc.) pour garantir que chaque personne
impliquée dans un processus décisionnel dispose de l'interface et du niveau d'interactivité adapté à
sa mission, il offre un accès sécurisé aux informations stockées dans les bases de données et les
progiciels, aussi il permettra à une interrogation des systèmes, et finalement le plus essentielle est
la génération d'états « reporting».
- Alors pour obtenir des informations plus détaillées, il est nécessaire d'utiliser Business Objects,
plus généralement le requêteur BO va permettre à tout utilisateur d'extraire des données et de les
mettre en forme dans des rapports. Ces requêtes ainsi crées peuvent ensuite être mises à
disposition des utilisateurs pour l'exploiter sur son poste.
 Utilisation de Business Object : Pour utiliser GRET reporting, il est nécessaire :
– D’être abonné à BO.
– D’être autorisé à accéder aux tables GRET UCM (FdE, Histo).
Chaque utilisateur sera habilité à voir les données de son site dans la langue de son pays.
 Les fonctionnalités de Business Object : Business Object (Desktop intelligence) permet :
La sélection des données (requête) Sélection, condition, tri et filtrage sur des objets
métier.
La mise en forme des données 1- Construction de tableaux et graphiques sur des
données sélectionnées
• Tableaux simples, croisés…
• Graphiques en histogramme, courbes,
nuages de points...
2- Utilisation de formules
• Fonctions d’agrégation, mathématiques,
chaines de caractères...
3- Mise en page
• Création de ruptures suivant une ou
plusieurs dimensions
• Ajout de libellés et commentaires
La publication : Exports Excel, Html

L’impression de rapports
 Un rapport Business Object : C’est un document avec une extension .rep, qui fournit la
possibilité de (renommer, déplacer, modifier, sauvegarder), il contient des données mises en
forme, il est nécessaire de rafraîchir les informations à l’ouverture du document grâce à une
demande de rafraîchissement fait apparaître dans une invite.
2.2.5 Reporting (génération d'états)

Un compte rendu souvent appelé en anglais reporting est l'opération consistant, pour
une entreprise, à faire rapport de son activité.
C'est la présentation périodique de rapports et bilans analytiques sur les
activités et résultats d'une organisation, d'une unité de travail où du
responsable d'une fonction, destinée à en informer ceux chargés de les
superviser en interne où en externe, ou tout simplement concernés par ces
activités ou résultats.
 Définition : Le terme "Reporting" désigne une famille d'outils de Business intelligence
destinés à assurer la réalisation, la publication et la diffusion de rapports d'activité selon un format
prédéterminé. Ils sont essentiellement destinés à faciliter la communication de résultats chiffrés ou
d'un suivi d'avancement.
 Principe : L'outil de reporting assure l'interrogation des bases de données selon les requêtes
SQL préparées lors de l'élaboration du modèle. Le rapport d'activité peut ensuite être publié sur
l'Intranet, périodiquement en automatique ou
ponctuellement à la demande. L'outil offre bien entendu des
fonctions spécifiques pour l'élaboration du modèle du
rapport, des modules de calcul et de présentation
(graphiques) afin de concevoir des comptes rendus
particulièrement seyants et pertinents.
2.2.6 Modèle de l’univers exploitable
Lorsqu'on fait un schéma de BD pour un système d'information classique, on parle en termes de
tables et de relations, une table étant une représentation d'une entité et une relation une technique
pour lier ces entités. Et bien en BI, on parle en termes de Dimension et de Faits. C'est une autre
approche des données, on entend par dimensions les axes sur lesquels on veut faire l'analyse.
- Une dimension est tout ce qu'on utilisera pour faire nos analyses (exp:PJI passage,
famille,..).

- Un fait est tout ce qu'on voudra analyser (Exp : Description véhicule, défaut véhicule,
….).
Un Univers est une représentation métier de données (à partir du datawherhouse) permettant aux
utilisateurs d'interroger une base et d’analyser les données, l’univers regroupe donc :
 Les données accessibles du système d’information que l'utilisateur pourra manipuler en
fonction de son métier ou de sa fonction.
 Liste de mots clés mise à la disposition de l'utilisateur en fonction de ses besoins.
 Composé des classes : classes que l'utilisateur actionne pour utiliser ces objets.
 Composé d'objets : objets que l'utilisateur manipule pour formuler une requête, ces objets
correspondent à des champs de la base de données ou à des variables calculées à partir de
champs de la base de données.
Figure 2.11 : Synthèse des concepts liés à l’univers
L’univers UCM_GRET existant est modélisé selon le schéma en flocon (voir l’annexe C), le
principe étant qu'il peut exister des hiérarchies de dimensions et qu'elles sont reliées aux faits.
 Les objets BO :
Les objets BO peuvent se présenter sous forme de :
•Dimension : donnée servant de base à l'analyse.

•Information : associée à une dimension, apporte des détails, on ne peut pas faire d’analyses sur
les informations.
•Indicateur : qui est une donnée numérique, généralement résultat d'un calcul sur les données de la
base.
 Localisation des données

Sur les poste clients. Sur les serveurs
- Exécutable BO.  Sources de données du data Warehouse.
- Données locales(Macro) Référentiel par domaine :
- Définition locales des Univers. - Définition centralisée des Univers.
- Données de sécurité.
 Les classes de l’univers :
Le reporting GRET est basée sur 2 univers, l’un pour les requêtes de type « HISTO », et l’autre
pour les requêtes de type « FIL DE L’EAU », ces univers ont pour but de fournir des données
centralisées de la production.
Les univers UCM_GRET sont l'ensemble des classes issues des bases de données qui servent de
bases pour les rapports générés à l’aide de Business Objects.
Ces classes sont organisées en univers qui regroupent les objets de même nature :
 UCM GRET Encours (fil de l’eau) : contient les données en temps réels sur les véhicules
produits.
 UCM GRET Histo : contient les données historiques sur les véhicules produits (données
des 16 derniers mois jusqu’à la veille).

Figure 2.12 : Assistant de sélection de l’univers
 Univers UCM GRET Histo
Figure 2.13 : Schéma de l’univers UCM_GRET Histo
 Univers UCM GRET FdE

Figure 2.14 : Schéma de l’univers UCM_GRET FdE
 Ce tableau décrit la compatibilité entre les classes des deux univers.

Tableau de compatibilité des classes de l’univers GRET
 Requêtes
Pour préciser ce qui se passe lors de la définition d'une requête, détaillons les différentes phases :
1. Les Univers sont définis par les administrateurs et sont référencés en un seul endroit sur un
serveur.
2. Un utilisateur BO, autorisé à exploiter cet Univers, bénéficiera des éventuelles mises à jour.
3. La requête est ensuite construite sur le poste utilisateur BO.
4. BO va générer le SQL de la commande correspondant aux spécifications de la requête.
5. Cette commande va être adressée au serveur qui contient les données.
6. La commande est alors exécutée sur le serveur, qui renvoie ensuite les données correspondant à
la demande.
7. Ces données sont maintenant présentes physiquement sur le poste BO qui en a fait la demande.
2.3 Indicateurs standard d'animations Qualité

Ces indicateurs sont la base de l’activité, ils offrent des résultats donnant une vision globale sur la
productivité de l’entreprise, C’est en fonction des observations de ces résultats
qu'il faut déclencher des analyses ciblées afin de remédier aux éventuels
problèmes par des plans d'action.
2.3.1 les principaux indicateurs d’animations qualité de RTE
Parmi les principaux indicateurs qui décrivent le niveau de la performance où
de la perturbation dans l’usine on trouve :
a. Défauts STR : Straight = Direct ; Through = A travers ; Ratio = Ratio (pourcentage)
Le STR a été défini comme un indicateur clé de la performance, qui correspond au nombre de
véhicules non sortis du flux pour retouche entre la TCM et la MADU*(signature en blanc).
Cet indicateur mesure la qualité produite au poste de travail. En effet, la meilleure qualité pour le
client est celle qui est obtenue directement au poste de travail, grâce à une opération standardisée.
 Le STR est le ratio entre : Les véhicules bons du premier coup ET les véhicules passés à la
signature en blanc.
- Un véhicule n’est pas bon s’il est sorti du flux entre la TCM et la MADC.
Formule :
Le STR, en %, est calculé par caisse, et son

pourcentage est calculé sur une période donnée.
b. Défauts non STR :
Le Non STR concerne les défauts retouchés entre la TCM et MADU, c’est un indicateur qui
mesure la perturbation.
 Le non STR signifie tous

les défauts dont la retouche est enregistrée sur un point de captage identifié Hors flux entre TCM
et la MADU :
Parmi les causes de non STR on trouve :
 Défaut déclaré.
 Retouches aspects (carrosserie, sellerie…).

 Manque pièce (ou blocage)

 Blocage ou code qualité
 Blocage pour un problème de process (équilibrage des roues…..)
c. Défauts PAD : Pourcentage ; Acceptation ; Directe
Le PAD est le Pourcentage d’Acceptation Directe calculé sur une période donnée, il est calculé
sur chaque flux de fabrication en prenant 2 points de référence : un point par flux de fabrication.
Formule :
- Un véhicule est hors flux à une date donnée si :

Il est passé par un des deux points de référence à cette date, ET, est rentré dans une des zones hors
flux (liste à renseigner par l’utilisateur),ET, possède au moins un défaut retouché dans l’un des
lieux de retouche hors flux (à renseigner par l’utilisateur),ET, possède au moins un défaut dont le
code retouche figure parmi la liste spécifique des codes retouches hors flux.
 Un véhicule est considéré hors flux uniquement s’il satisfait obligatoirement chacune de
ces 4 conditions.
d. Défauts Non PAD :
- Un véhicule est comptabilisé dans le non PAD pour un département s’il satisfait les conditions
précédentes à cause d’un défaut imputé à ce département.
e. Pareto activité :
- Le Pareto activité reflète le détail des défauts déclarés sur tous les véhicules sur une période
donnée, il retourne un Top des défauts dont la date de déclaration correspond à cette période,
prenant en compte que le Top est calculé par le couple Elément/incident.
f. Pareto flux :
- Le Pareto flux reflète le détail des défauts présents, retouchés ou non sur tous les véhicules
passés par un ou plusieurs points sur une période donnée, il retourne un Top des défauts dont la
date de passage correspond à cette période.
g. Le Pareto Évolution :
- Le Pareto évolution restitue sur une période donnée, sur tous les véhicules passés par un point
de référence dans cette période, et il reflète l’évolution horaire du nombre de défauts.
h. Les Résultats d’audit :
- Les résultats de l’audit représentent tous les défauts déclarés dans un contexte d’audit
(Auditeur) sur une période donnée.

i. La consultation véhicule :
Exprime tous les défauts enregistrés pour un véhicule sélectionné.
j. Les indicateurs autocontrôles :
« Il est difficile à une personne de trouver une aiguille dans une botte de foin quand elle ne sait
même pas s’il y en a une ni où elle peut être. »(CONTROLE)
« Il est plus simple de demander à celle qui l’a laissée tomber ou qui l’a vue d’indiquer où elle se
trouve. »(AUTOCONTROLE)
 L’autocontrôle est un contrôle par l’opérateur lui-même, du travail qu’il a accompli, suivant des
règles spécifiées.
L‘autocontrôle s’inscrit pleinement dans les principes d’obtention de la Qualité au poste de travail:
• Ne pas accepter de défaut.
• Ne pas produire de défaut.
• Ne pas transmettre de défaut.
Cependant et chaque fois que cela est nécessaire, le geste d’autocontrôle est intégré dans
l’opération standard, l’autocontrôle est donc partie intégrante de la standardisation du poste de
travail, et parmi les indicateurs autocontrôle existés on trouve :
 Défauts NQ :
Le NQ est un indicateur pour mesurer le niveau de qualité d’une UET c'est-à-dire le nombre de
défauts déclarés dans un contexte Audit et imputés à cette UET.
 Défauts NR :
Le NR est un indicateur pour mesurer le niveau de retouche c'est-à-dire le nombre de défauts
déclarés et générés dans la même UET sur les véhicules passés à une date donnée par un point de
référence.
 Défauts NNS :
Les défauts NNS représentent tous les défauts sur les véhicules, imputés à une UET donnée et
déclarés par une AUTRE UET
Remarque :
Le TD (Taux de Défaillances) = Nombre de véhicules avec au moins un défaut / Nombre de
véhicules passés par le point de référence.
Le K/1000 = La somme des quantités de tous les défauts / Nombre de véhicules passés par le
point de référence.

2.4 Problématique
- Les indicateurs vu précédemment sont d’une grande importance pour les chefs UET, chefs
d’ateliers et chefs de département…, toutefois actuellement seules les requêtes STR et PAD ont
été réalisées, pour le reste l’utilisation d’Excel ou le calcul manuel (avec les erreurs que ça
implique) sont les moyens utilisés.
Un des problèmes majeurs dont souffre la production c’est la difficulté d’avoir un aperçu global et
clair des défauts/retouches, ainsi il est actuellement difficile par exemple d’avoir un classement
des UET qui génèrent le plus de défauts… d’où l’intérêt d’implémenter ces indicateurs.
2.5 Conclusion
- Dans cette partie on a pu découvrir l’architecture BI de Renault, ainsi que les principaux
indicateurs qualité qui n’ont pas été en grande partie implémentés.

3. Flux de Travail
3.1 Introduction :
Un workflow (flux de travaux) est la représentation d'une suite de tâches ou opérations effectuées
par une personne, un groupe de personnes, un organisme, etc. Le terme flow renvoie au passage
du produit, du document, de l'information, etc., d'une étape à l'autre.
De façon pratique, le workflow sert à décrire le circuit de validation, les tâches à répartir entre les
différents acteurs d'un processus, les délais, les modes de validation, et à fournir à chacun des
acteurs les informations nécessaires à l'exécution de sa tâche. Le workflow permet généralement
un suivi et identifie les acteurs en précisant leur rôle et la manière de le remplir au mieux. Pour un
processus de publication en ligne par exemple, il s'agit de la modélisation des tâches de l'ensemble
de la chaîne éditoriale.
3.2 Procédures actuelles
 Plusieurs manipulations sont courantes sur GRET :
 Ajout d’une défaillance dans le catalogue.
 Correction d’une saisie erronée.
 Modification d’une UET catalogue.
 …
Ces manipulations sont réalisables par les administrateurs GRET du site, GRET étant un système
critique, plusieurs acteurs interviennent dans son utilisation (48 que pour la saisie), naturellement
plusieurs erreurs de manipulation peuvent avoir lieu, dans ce cas la procédure standard est de
contacter les administrateurs GRET pour résoudre le problème, la procédure se fait généralement
par téléphone/e-mail/face à face.
3.3 Problématique
 Cette démarche présente plusieurs problèmes & limitations :
 Perte de temps.
 Manque de traçabilité sur les changements.
 Problèmes de coordination.
 Manque d’efficacité dans le traitement d’une demande (manque d’information…).
Dans certains cas le problème peut subvenir au niveau de l’expression des besoins, tous
simplement parce que la personne concernée (demandeur) ne sais pas à qui adresser sa demande.
Le nombre croissant des demandes chaque jour aggrave la situation actuelle (actuellement environ
50 demandes/jour en attendant le démarrage de Tanger 2 (la 2éme ligne de production)).

3.4 Conclusion
Il est clair que la méthode actuelle en plus d’être inefficace, n’est pas standard est ne prend pas
bénéfice des possibilités du système d’information dont dispose Renault.
4. Architecture Intranet Renault
4.1 Architecture Intranet Renault

L’architecture Intranet de Renault s’appuie sur la SPT (Standardisation du poste de travail) qui est
basée sur les principes suivants :
 Standardisation : Homogénéisation du hardware & du software.
 Informatique ubiquitaire : l’utilisateur peut récupérer l’information à partir de tous les
périphériques connectés à l’intranet de Renault.
 Stabilité : stabilité technique de la station de travail et maitrise de son contenu.
 Paiement à l'utilisation : abonnement mensuel aux services Desktop.
 Concrètement :
 Un poste de travail sous Windows XP.
 Un portail pour les employés : DECLIC
 Un système d’abonnement aux catalogues des services et des outils.
4.2 Declic
Figure 2.15 : Portail DECLIC

 DECLIC est un Portail générique :

 Déclic est un Portail intranet générique pour tous les employés de l’entreprise
“Un portail pour tous “.
 C’est le point d’accès unique aux différents “Espaces Métiers” (e-WorkPlace)
 Le projet Déclic est accompagné d’une solution plus rapide et plus simple pour la
gestion des contenus des sites intranet.
 Caractéristiques:
 Restrictions d’accès synchronisées quotidiennement avec IS SAP Ressources humaine (BPU).
 Personnalisable.
 Accès à l’Intranet / Internet IS et aux outils génériques.
 Accès à IS.
 Intégration de Web mail, MS Office, serveurs de fichiers.
 Affichage de messages et d’alertes profilés à partir d’IS.
 Capacité d’abonnement aux medias internes.
4.3 Espaces métiers
Figure 2.16 : L’espace Métiers DECLIC
 Définition :
 Affichage des liens et d’informations dédiées à une communauté d’utilisateurs avec des
activités professionnelles communes.

 Unique point d’accés aux informations, liens et outils dont les utilisateurs ont besoin pour
accomplir leurs taches de travail, processus et missions.
 Un espace métier contient :
 Liens statiques :
 Exp : lien vers la page du planning.
 Exp : lien vers un fichier sur un disque partagé.
 Liens dynamiques (URL calculée, selon l’utilisateur et ses préférences)
 Exp : liens vers des pages basenotes générées (selon l’ID de l’équipe).
 Données dynamiques transmises par IS au Portails pour être affichées.
 Exp : des indicateurs qualité dans le text des liens, reliés à
une liste détaillée.
 Des rapports et graphiques générés dynamiquement.
 Exp: des graphiques représentant l’évolution d’un indicateur qualité générés
dynamiquement.
 Les liens catégorisés par processus.

ChapitreIII
Modèle proposé
Nous consacrons ce chapitre dans un premier temps au

choix d’un modèle qui puisse répondre aux besoins
définis dans le chapitre précédent, ensuite une étude
détaillée de ce modèle sera réalisée afin de décrire les
fonctionnalités et le comportement voulus.

1. Modèle proposé
1.1 Introduction
L’objectif de ce chapitre est de :
- Proposer un ensemble de solutions (3).
- Faire un comparatif entre les solutions proposées.
- Choisir la solution la plus adaptée.
- Réalisation d’un modèle fonctionnel décrivant le comportement attendu de la solution retenue.
1.2 Récapitulatif
Dans le chapitre précédent on a fait une étude sur l’état des arts, voici en bref les problématiques
rencontrées :
- L’absence d’outils permettant le calcul des indicateurs qualités.
- utilisation des e-mails & du téléphone comme procédures standards de travail dans le périmètre
SI/Qualité/Fabrication.
- Absence d’une cartographie pour les systèmes GRET/PSFV, utilisation de fichiers Excel pour
modéliser la distribution des postes, d’où plusieurs problèmes :
 Existence de fichiers non mis à jour.
 Informations non accessibles à tous les utilisateurs.
 Informations non centralisées.
1.3 Solutions proposées

A partir des problèmes ci-dessus plusieurs solutions ont été proposées, dans cette partie on va
détailler chacune de ces solutions :
 Solution 1 : Application WEB destinée aux personnes suivantes :
1 - Fabrication : chefs d’ateliers, chefs de départements.
2 – Qualité : Administrateurs GRET.
3 – DSI : SI Qualité
 Cette application doit assurer les fonctionnalités suivantes :
- « Calcul des indicateurs », avec représentation par tableaux, graphiques…
- « Cartographie GRET et GRET/PSFV », avec possibilité de modification des points…

- « Workflows », application de l’approche BPM (Business Process Management) consistant

à modéliser informatiquement les processus métiers de l'entreprise, aussi bien dans leur
aspect applicatif qu'humain. Où l’on peut soumettre des demandes concernant GRET :
 Modification d’une UET d’imputation GRET.
 Correction d’une erreur d’imputation d’un défaut de saisie GRET.
 Ajout d’une nouvelle défaillance dans le catalogue.
 Demander la création d’un menu PSFV
 Demander la création d’une nouvelle requête BO.
BPM (Business Process Management « Gestion des Processus Métiers »)
On appelle « BPM » (Business Process Management, traduisez littéralement "gestion des
processus métiers ») l'approche consistant à modéliser informatiquement les processus
métiers de l'entreprise, aussi bien dans leur aspect applicatif qu'humain.
Solutions proposés Avantages Inconvénients
Solution 1 -Possibilité de personnalisation - Développement à zéro.
du rendu des indicateurs. - Maintenabilité de l’application
- La cartographie serait (plusieurs modifications
consultable à partir d’une nécessiteraient l’altération du
interface web (donc consultable code).
par les Téléphones de service… - Nécessité de faire plusieurs
sans plugin…) formations au personnel sur
l’utilisation de l’application.
Solution 2 - L’application serait intégrée - L’information n’est

dans l’intranet qualité. accessible qu’aux
administrateurs GRET (pour
les autres il faut passer par cet
intermédiaire).
- Pour la partie Workflow une
autre solution est à trouver
(seul le personnel du
département qualité a le droit
d’accéder à l’intranet Qualité).
Solution 3 - Solution intégrée dans Déclic - cartographie sous Excel
(Intranet de Renault utilisé par présente toujours des
l’ensemble du personnel) limitations :
- Développement plus efficace 1 – bien que l’ensemble des
et orienté fonctionnalités informations seraient dans un
(contrôle d’accès… déjà seul fichier, ce dernier serait

implémenté) téléchargeable, des versions

- Solution facilement non mises à jours pourraient
maintenable (utilisation de être utilisées.
TRIDION sans avoir à modifier 2 – consultable uniquement à
le code) partir de périphériques où
- Internationalisation. Excel est déjà installé.
- Contrôle d’accès centralisé et

gestion des utilisateurs sécurisé.
- Personnalisation des services
offerts par le SI qualité, par
groupe...
1.3.2 Choix de la solution

- Après analyse des solutions proposées ci-dessus et consultation avec l’ESIL de l’usine de Tanger
le choix retenue est une combinaison entre les solutions 1 et 3.
La solution 3 présente plusieurs avantages, et son seul inconvénient est l’utilisation d’Excel pour
la réalisation de la cartographie, comme solution alternative on a proposé la mise en place de la
cartographie GRET/PSFV sous une interface web.
- La cartographie serait utilisée par l’ESIL ainsi que par les administrateurs GRET (3 utilisateurs
dont 1 est un administrateur qui peut modifier la cartographie), avec un nombre d’utilisateurs aussi
restreint la contrainte concernant la formation d’un nombre élevé d’utilisateurs n’est plus valable.
Concernant la maintenabilité de l’application, on a prévu l’utilisation d’un modèle paramétrable
par l’ESIL.
1.4 Modèle fonctionnel

La solution proposée est transverse (concerne l’ensemble des départements participants au
processus de fabrication), pour cette raison on a choisi de diviser la solution en 4 parties :
 Qualité Tôlerie.
 Qualité Peinture.
 Qualité Sous-ensemble.
 Qualité Montage.
Chacune de ces parties offre une interface permettant l’accès aux informations/actions propres à
ce département :

- Consultation des documents Business Objects présentant les indicateurs qualité (chaque
requête est accompagné d’un descriptif est d’un mode d’utilisation modifiable par l’ESIL).
- Soumission des différentes demandes concernant GRET, ces demandes sont ensuite
transmises de façon hiérarchique aux acteurs/validateurs concernés (le demandeur est
notifié par e-mail de chacune des étapes de validation).
Consultation de la cartographie GRET/PSFV (l’ESIL de l’usine de Tanger en est
l’administrateur).
 Cette solution catégorise les utilisateurs en 3 catégories avec les droits/rôles suivants :
a. Administrateurs GRET :
Coté requête BO Coté Documentation Coté Workflow
• Création/Mise à jour des • Création des documents. • Valider les demandes
rapports BO. • Diffusion aux utilisateurs
• Diffusion aux utilisateurs concernés.
concernés.
En plus des droits d’un utilisateur ordinaire (CUET, CA, CD).
b. ESIL usine de Tanger :
• Création/Mise à jour des • Création des documents. • Administration des
rapports BO. • Diffusion aux utilisateurs workflow.
• Diffusion aux utilisateurs concernés. • Validation des demandes.
concernés. • Publication
• Publication des nouveaux
rapports.
En plus des droits d’un utilisateur ordinaire (CUET, CA, CD).
c. Utilisateur (Chef UET, chef Atelier, chef de département) :
• Consultation des rapports • Consultation de la • Validation des demandes.
BO. documentation. • Soumettre des demandes de
workflow
- Dans la suite de ce chapitre on va détailler le comportement souhaité de la solution.

1.4.1 Documents Business Objects :

 Voici une maquette de documents business Objects à réaliser :
Chaque document est basé sur une ou plusieurs requêtes, lors de l’exécution d’une requête
l’utilisateur doit entrer des valeurs comme paramètres des requêtes.
L’idée est d’utiliser un document BO pour visualiser un ensemble d’informations, limitant ainsi le
besoin constant de création de nouveaux documents, à condition de préserver la simplicité
d’utilisation.
- Les documents standards peuvent être mis à jour dans l’intranet de l’entreprise (Déclic) et
par la suite :
 Les ESIL et les chefs (ateliers, département, UET) pourraient alors être prévenus par
mail de la disponibilité d’une nouvelle version.

1.4.2 Demandes de flux de travail :

 Maquette d’une demande de correction d’une saisie GRET :
1.4.3 Cartographie GRET/PSFV:

 Maquettes de la cartographie GRET/PSFV du département de montage :
Représentation physique des emplacements des postes GRET/PSFV dans l’ensemble de l’usine.
Lors du clic sur un point :

ChapitreIV
Réalisation & Mise en
œuvre
Ce chapitre sera consacré aux étapes d’implémentation

de la solution décrite dans le chapitre précédent,
l’organisation du travail selon la méthode Scrum y est
décrite, chaque étape de réalisation sera précédée d’une
présentation des outils employés, finalement l’étape de
formations des utilisateurs sera décrite brièvement.
1. Implémentation du modèle fonctionnelle
1.1 Introduction

Ce chapitre aborde l’aspect implantation informatique du modèle générique proposé

conformément à la méthodologie SCRUM. Nous y présentons les étapes de réalisation qui nous
ont permis de mettre en place le système. Nous détaillons la phase de création des documents
BO, des e-Process et de la cartographie GRET/PSFV. Nous abordons en fin de chapitre la phase
des tests et la formation des utilisateurs.
1.2 Déroulement par rapport à Sprint :

 Régles :
Pendant le déroulement de notre projet les rôles SCRUM ont été répartis de la façon suivante :
- Product owner : Administrateurs GRET (ET-TAKI Abdelhak, LAATRIS Abou-ennassr) +
en partie l’ESIL de l’usine de Tanger (ASMODI Hassan).
- Scrum master : ESIL de l’usine de Tanger(Hassan Asmodi).
- L’équipe : Stagiaires : Achraf & Youssef.
On a décidé qu’un sprint sera d’une durée de 2 semaines.
 Backlog Produit :
Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs.
L'objectif est d'établir une liste de fonctionnalités à réaliser, que l'on appelle backlog de produit.
À chaque item de backlog sont associés entre autres les attributs suivants :
- Priorité
- Catégorie.
- Durée.
- Pourcentage de complétion.
- Optionnellement un item peut nécessiter un prédécesseur et des ressources.
Plusieurs de ces attributs sont définis par le Product Owner. Ce dernier définit dans quel ordre
devront être réalisés ces items. Il peut changer cet ordre en cours de projet et même ajouter,
modifier ou supprimer des items dans le backlog.
La somme des pourcentages de complétion des items du backlog de produit constitue le reste à
faire total du projet. Cela permet de produire un release burndown chart, qui montre les points
restant à réaliser au fur et à mesure des sprints.
(Backlog produit : voir annexe).
 Backlog de Sprint

Lorsqu'on démarre un sprint, on choisit quels items du backlog de produit seront réalisés dans ce
sprint. L'équipe décompose ensuite chaque item en liste de tâches élémentaires (techniques ou
non), chaque tâche étant estimée en heures et ne devant pas durer plus de 2 jours. On constitue
ainsi le backlog de sprint.
Pendant le déroulement du sprint, chaque équipier s'affecte des tâches du backlog de sprint et les
réalise. Il met à jour régulièrement dans le backlog du sprint le reste à faire de chaque tâche. Les
tâches ne sont pas réparties initialement entre tous les équipiers, elles sont prises au fur et à
mesure que les précédentes sont terminées.
La somme des heures des items du backlog de sprint constitue le reste à faire total du sprint. Cela
permet de produire un sprint burndown chart qui montre les heures restantes à réaliser au fur et
à mesure du sprint.
Exemple de sprint burndown chart :
Figure 4.1 : burndown chart du 3éme Sprint (3 - 20 Avril)

- Le graphique suivant correspond au 3éme Sprint (du 3Avril au 20 avril) dont le Backlog est le
suivant :
Figure 4.2 : Backlog du 3éme Sprint (3 - 20 Avril)
Le décalage entre les 2 courbes (la courbe en rouge représentant le travail restant, tandis que celle
en noir la courbe idéale) est dû à un retard dans la tâche de réalisation des documents BO (Histo
montage), ainsi que la tâche « validation des documents avec les administrateurs GRET » qui ont
demandé plus de temps que prévu.
 Mise en œuvre de Scrum :
3 semaines après le début du projet on a été informés par un GLS(CUET de DOUAI présent à l’usine de
Tanger qu’un projet pareil avait été déployé auparavant à l’usine Renault de DOUAI, ainsi avec l’accord
de notre encadrant (ESIL) nous avons pris contact avec l’ESIL de l’usine de DOUAI Mr.Folens Patrick
qui a accepté de nous fournir l’aide nécessaire et de prendre part (par Live meeting) aux réunions de
planification de Sprints.
Réunions de planification de Sprint :

 Participants :
ESIL usine de Tanger, Stagaires : Achraf & Youssef, Administrateurs GRET, ESIL usine de
DOUAI.

 La réunion se passe en 2 temps :

Partie Objectifs
1ére partie (participation de tout le monde) - Enoncer les buts du sprint (le produit du
sprint).
- Proposer des estimations temporelles en
nombre de jours.
2éme partie (participation des ESIL de l’usine - Etablir les étapes nécessaires pour atteindre le
de Tanger et celui de Douai, stagiaires : Achraf but du Sprint.
& Youssef)
Réunions de revue de Sprint :
À la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au
maximum 2 heures. L'objectif de la revue de sprint est de valider le travail qui a été réalisé
pendant le sprint.
- Valider la réalisation à la fin du sprint en effectuant une démonstration du travail
réalisé.
- Modifier éventuellement certains objectifs définis au départ en fonction de nouvelles
requêtes.
Réunion quotidienne :
Scrum préconise la tenue d'une réunion quotidienne pendant laquelle l'équipe décrit ce qui a été
fait la veille, ce qui va être fait dans la journée, et les points bloquants. C'est le moment où on met
à jour la liste de tâche du Sprint et où on révise le burndown de sprint.
Ces réunions étaient réalisées avec la participation de l’équipe étendue :
- Équipe : Stagiaires (Achraf & Youssef) + Scrum master (ESIL de l’usine de Tanger
« Asmodi Hassan »).

1.3 Elaboration des documents BO

- Les objectifs des documents BO crées sont multiples. Nous pouvons les regrouper en trois
catégories :
 Consultation des défauts, manques pièces…
 Indicateurs qualité.
 Mesure de la réactivité aux problèmes.
Ces documents sont mis à disposition des gens de métiers de la fabrication (CUET, CA, CD)
organisés par départements (Qualité Tôlerie, Qualité Peinture, Qualité Sous-ensemble, Qualité
Montage), ces documents sont catégorisés en :
- Documents dédiés aux activités journalières.
- Documents dédiés aux activités ponctuelles.
Au niveau interne quelques-uns de ces documents se basent sur des requêtes interrogeant l’univers
UCM_GRET_HISTO (données historiques à partir du serveur centrale) tandis que d’autres
ciblent l’univers UCM_GRET_FDE (données en fil de l’eau à partir du serveur local).
Remarque : Pour exploitation de ces requêtes et les documentations d’une manière aisé et
accessible, nous avons opté à la création d’un espace de données sur le serveur DSI_qualité pour
le projet (20GO comme espace mémoire).
 Exemple "documents Montage”:
Dans cette partie on va décrire les documents BO réalisés, cette description sera complétée par
quelques captures d’écran.
Maitrise Qualité
Activités journalières
> Consulter le catalogue de défaillance Elément/Incident de l'usine par Famille/Type et par UET
> Consulter les Pertes Qualité TCM J92, K67, F67 de l'UET
> Consulter les indicateurs STR usine HISTO
> Consulter les indicateurs STR usine FIL DE L'EAU
> Consulter les Indicateurs Auto Contrôle (NR, NNS, NQ)
> Consulter les Indicateurs Tps réel (NR, NQ)
………………….
Activités ponctuelles
> Analyser ma non Qualité (Pareto Activité)
> Analyser ma non Qualité (Pareto Flux)
> Analyser ma non Qualité (Pareto Evolution)
> Consulter la non qualité d'un véhicule
> Consulter les Pertes Qualité TCM de l'UET
> Consulter le TOP 20 des défauts (Pareto Flux)
…………….

Les documents BO sont consultables via l’espace métiers créé sur le portail DECLIC, il suffit de
rafraîchir ces documents et d’introduire les paramètres nécessaires dans l’invite pour avoir les
résultats.
 Captures d’écran des rapports BO dédie pour le département du Montage :
Figure 4.3 : Pareto activité
Figure 4.4 : STR

Figure 4.5 : Les indicateurs autocontrôle

Ces captures d'écran apportent une vision beaucoup plus large sur le contenu des rapports réalisés
pour le suivi de la qualité de la fabrication, d’autres documents spécifiques à chaque département
(Montage, Tôlerie, Peinture, Sous-ensemble) ont été réalisés.
1.4 Réalisation des eProcess

1.4.1 Définition : eProcess Local (e-sign)
- eProcess local est un outil web tout en un qui permet, à la demande des Métiers responsables des
processus, de concevoir, publier et administrer des processus de validation dématérialisés,
appelés workflows.
L'ensemble des workflows créés repose sur des

formulaires prédéfinis regroupés au sein d'espaces
Métiers nommés instances.
Ils permettent à des utilisateurs d'émettre des demandes avec un nombre d'étapes de validation
donné défini par leur responsable. Le circuit de validation emprunté par le workflow est ensuite
déterminé par chaque Valideur pour l’étape suivante, en suivant les instructions définies dans le
workflow.
 voici un logigramme qui décrit le cycle de vie d’une demande (cas simple sans conditions
sur les champs) :

Figure 4.6 : Cycle de vie d'une demande workflow
- Chaque demande doit passer par ce circuit de validation. Selon le workflow utilisé, les étapes de
validation peuvent changer, notons que ce logigramme peut se voir modifier si des conditions sont
posées sur les champs de la demandes, on peut ainsi selon la valeur d’un champ cheminer le
demande vers un valideur donné.
 Voici les différentes demandes workflow mises à disposition des utilisateurs de GRET :
> Demandé la correction d’une erreur d'imputation d’un défaut sous GRET
> Demandé la modification d'une UET d'imputation sous GRET
> Demandé la création d’une nouvelle défaillance sous GRET
> Demandé la création ou la modification d'une requête BO
> Demandé la création d'un menu PSFV.
Formulaire en ligne pour la

gestion des eProcess sous e-
Sign
Figure 4.7 : Liste des formulaires en –ligne crées
 Formulaire en ligne réalisé pour la demande de création d’une nouvelle défaillance :

Figure 4.8 : Demande de création d'une nouvelle défaillance
 Formulaire en ligne réalisé pour la demande de création/modification d’un document BO.
Figure 4.9 : Demande de création/modification d'un document BO
 Ce message est un exemple d’une notification envoyée au valideur qui fait partie du
circuit de validation d’une demande en –ligne.
Figure 4.10 : Message de notification au valideur

 Cet e-mail représente le message de notification envoyé au demandeur, contenant la

réponse sur la demande.
Figure 4.11 : Message de notification de demandeur
 Cette page web décrit le détail de la demande après le traitement par le valideur.
Figure 4.12 : Page de la visualisation de la demande

1.5 Réalisation de la cartographie

La cartographie GRET/PSFV englobe les informations suivantes :
- la répartition physique des postes GRET/PSFV sur l’usine.
- Le rôle de chaque poste dans le processus de fabrication.
- Informations propres à chaque poste (adresse IP, nom machine, responsable…).
En cours


1.6 Paramétrage de l’espace métier sous Tridion
- L’outil informatique Tridion est:un CMS (Content Management System), un logiciel destinés à

la conception et à la mise à jour dynamique de sites Web.
 Concrètement, TRIDION est :
 Un outil d’édition de pages Web et de publication.
 L’outil officiel Renault de gestion de sites intranet, retenu notamment pour :
– Sa facilité d’utilisation.
 Séparation contenu / contenant => l’utilisateur se concentre sur le texte
– Son homogénéité d’affichage.
– Ses délais de publication très courts (5 à 30mn)
 Utilisé pour Declic et la plupart des bases Groupe.
1.6.1 Paramétrage de l’espace Métiers sous Tridion

Voici la démarche à suivre pour la création et le paramétrage de l’espace métier :
Les étapes de paramétrages ont été réalisées en coopération avec la responsable de la gouvernance de
Déclic Mme.Caron Héléne.
 Les étapes de paramétrage :
 Acteur : Stagiaire
- Formation à TRIDION « Créer/Modifier une Page Contenu Déclic »
 Acteur : Centrale Renault.
- Confirmer l’accord sur la structure proposé.
 Acteur : Stagiaire
- Préparation des sous-onglets
- Préparation des 3 boites à l’intérieur de chaque sous-onglet
- Préparation des liens dans les boites
- Préparation des Pages intermédiaires qui hébergeront les liens
- Préparation complète d’une Page intermédiaire
 Acteur : Centrale Renault - Stagiaire
- 1ère Recette de la structure.

- Saisie des autres pages intermédiaires

 Acteur : Centrale Renault.
- Recette.
- Corrections éventuelles.
 Mise en ligne de l’espace métier.
- Pour pouvoir bénéficier de cet espace métier il suffit d’ajouter au profil de l’utilisateur de Déclic
l’entité du site de Tanger :
- L’espace métier est organisé en 3 périmètres :

 Périmètre maitrise de la qualité :
Ce périmètre est le plus important, il permet d’accéder au différents rapport BO, ainsi qu’aux
formulaires métiers des demandes.
Les détails de ce périmètre sont présentés dans les captures d’écran suivantes :

Figure 4.15 : Périmètre maitrise de la qualité
Figure 4.16 : Détail de périmètre exemple (Activités ponctuelles)
 Périmètre animation UET:
Figure 4.9 : Périmètre animation UET
La deuxième catégorie intègre les documents utiles pour l’animation d’UET :

 Suivre le planning de présence de l'UET
 Suivre le tableau de bord de l'effectif
 Piloter mon déploiement du dossier de l'UET
 Consulter l'organigramme du département
 Tableau de présence
 Fiche challenge / défi UET
 ...

 Périmètre professionnalisme :
Figure 4.17 : Périmètre professionnalisme
- La dernière catégorie intègre les documents utiles pour l’amélioration en continue :

 Construire le plan de formation.
 Accéder aux tableaux de planification et de résultats dextérité.
 Guide d'animation formation au poste
 Guide d'évaluation formation au poste
 Supports d'évaluation de blocs et niveaux de compétences
 Tableau des exigences opératoires
 Relevé de présence formation
 ...
 Captures d’écran de l’espace métier élaboré pour l’usine Tanger :

Figure 4.18 : Authentification pour accéder à l’espace métiers
Figure 4.19 : Espace Métiers crées dédié à l’usine de Tanger
 Par la suite il suffit de sélectionner le département et l’activité à consulter :
Figure 4.20 : les périmètres crées dans Espace Métiers

Figure 4.21 : Consultation d’un document BO
Chapitre V
Synthèse du projet &
Conclusion
Dans ce chapitre on va présenter une synthèse globale

de notre projet ainsi que ses perspectives d’évolution,
pour finir avec une conclusion générale.

Synthèse du projet
1. Planning réel de ce qui a été fait
Figure 5.1 : Diagramme de Gantt (planning finale de réalisation)
Le décalage entre le planning prévisionnel et le planning réel au 4éme mois est dû à

l’indisponibilité du coordinateur au niveau de central (congé puis formation).
Cependant face à cet imprévu plusieurs réarrangements dans le planning ont été faits avec
l’ESIL de l’usine de Tanger afin de donner la priorité à d’autres tâches pour que finalement le
délai global ait été respecté.
2. Les objectifs ont été atteints

Actuellement le projet a été validé par la centrale Renault et mis en production. Des
formations sur l’utilisation du système ont été dispensées au personnel concerné. Généralement les
objectifs escomptés du projet ont été atteints.
Finalement pour faciliter la maintenance et l’utilisation de ce système nous y avons associé
une documentation ainsi qu’un support de formation détaillant son utilisation.

3. Les perspectives d’évolution

Ce projet traite les problématiques du côté qualité, mais est généralisable aux autres
départements de l’usine, les étapes de réalisation sont globalement les mêmes, ainsi que les gains
qui en résultent :
 Regrouper dans un seul espace métier tous les documents dont a besoin chaque
département.
 Réduire le temps de recherche/collecte d’informations.
 Fournir des indicateurs de performances.
 Standardiser les procédures d’entreprise.

Conclusion générale
Ainsi se termine notre rapport, dans lequel nous avons d’abord commencé par introduire
notre projet dans son contexte général, fait une étude de l’état de l’art, pour ensuite proposer
quelques solutions possibles, finalement la solution retenue a été décrite depuis la phase de
conception jusqu’à la phase de déploiement.
Nous estimons avoir satisfait les objectifs initialement fixés tout en faisant faces aux diverses
contraintes qui sont apparues durant ce stage. Nous sommes d’autant plus confiants dans notre
jugement que les tests intensifs qui ont été faits par de nombreux membres de notre équipe ont été
réussis et que ces derniers ont exprimés leur satisfaction des résultats atteints.
Ce stage a été une expérience enrichissante en enseignements, outre l’aspect technique nous
avons pu découvrir de prêt le fonctionnement d’une entreprise multinationale qui exerce dans
l’industrie automobile.
Au plan humain on a eu l’occasion de côtoyer de grands professionnels et de travailler en

collaboration avec des personnes de différentes cultures, on estime que ce stage de fin d’étude a
été une transition réussie pour notre future insertion professionnelle.
Achraf & Youssef

Annexes
Annexe A

Paramétrage e-sign
Concepteurs et Administrateurs de workflows
1. Créer et paramétrer un workflow dans une instance
1.1 Créer ou modifier un workflow

Lorsqu’un utilisateur est Concepteur pour une instance, alors il dispose du menu « Administrer » et du
sous-menu « Gérer Workflow » lorsqu’il se connecte à l’application.
En cliquant sur le menu « Gérer Workflow », la liste des workflows de l’instance s’affiche.
Le concepteur peut alors créer un nouveau workflow ou modifier un workflow existant. La démarche est
décrite dans les paragraphes ci-dessous.
1.2 Créer un nouveau workflow vierge

Lorsqu’un concepteur souhaite paramétrer un tout nouveau workflow, il l’initialise avec un paramétrage
vierge, c'est-à-dire sans Etape et sans Donnée pré-définies.
Le mode opératoire est : depuis la liste des workflows de l’instance, cliquez sur le bouton « Créer
workflow ».
L’écran de paramétrage du workflow s’ouvre : voir ensuite le paragraphe (Paramétrer un workflow).
1.3 Modifier un workflow existant

Pour modifier un workflow existant, le publier ou le retirer de la publication, cliquer sur le nom du
workflow depuis la liste des workflows de l’instance :

L’écran de synthèse du paramétrage du workflow s’affiche :
Pour modifier des paramètres, cliquer sur le bouton « Modifier ». L’écran de paramétrage du workflow
s’ouvre : voir ensuite le paragraphe (Paramétrer un workflow).
1.4 Paramétrer un workflow
1.4.1 Description des principes de paramétrage d’un workflow

Lors de la création ou la modification d’un workflow, l’écran de paramétrage s’ouvre. Il comprend 6 zones
principales qui définissent complètement le workflow :
 Caractéristiques générales (zone intitulée « Nouveau workflow »)
 Administrateurs
 Etapes
 Groupes de Champs
 Champs (données)
 Fichier d’aide (taille limitée à 2 Mo).
1.4.2 Paramétrer les Caractéristiques générales du workflow

Cette zone intitulée « Nouveau Workflow » (même dans le cas de modification d’un workflow existant)
comprend des informations générales sur le workflow.
Zone de paramétrage des caractéristiques générales d’un workflow.
1.4.3 Paramétrer les Administrateurs du workflow

Les administrateurs du workflow sont modifiables après publication du workflow et lorsque des demandes
sont en cours.
Pour ajouter un administrateur, cliquer sur le bouton , puis rechercher la personne à ajouter dans
l’annuaire.
Pour retirer le rôle d’administrateur pour une personne, cliquer sur l’icône correspondante :
Zone de paramétrage des Administrateurs d’un workflow.

1.4.4 Paramétrer les Etapes du workflow

Les étapes d’un workflow sont modifiables si aucune demande n’existe pour ce workflow (aucune
demande créée ou toutes les demandes ont été supprimées).
 Paramétrer une étape du workflow

Pour ajouter une étape à la suite des étapes définies dans le workflow, cliquer sur bouton ;
Pour modifier une étape existante, cliquer sur son numéro (couleur de numéro bleu foncé sur fond bleu)
à gauche du titre du valideur de l’étape :
Zone de paramétrage des étapes d’un workflow.
Dans les deux cas, la fenêtre d’édition de l’étape s’affiche :
1.4.5 Paramétrer les Groupes et Champs de données du workflow
 Principe des formulaires

L’illustration ci-dessous montre la définition d’un formulaire dans l’écran d’administration du workflow, et
le résultat obtenu dans l’écran de rédaction d’une demande pour un utilisateur :
Définition d’un formulaire avec 2 groupes de données et 4 champs de données
Affichage du formulaire avec 2 groupes de données et 4 champs de données
 Paramétrage d’un Groupe de données

Pour ajouter un Groupe, cliquer sur les boutons ;
Pour modifier le nom, cliquer sur son numéro (couleur de numéro bleu foncé sur fond bleu) à gauche du
nom ;

Lorsque le concepteur ajoute ou modifie un groupe, la fenêtre suivante s’affiche :
 Paramétrage d’un Champ de données

Pour ajouter un Champ, cliquer sur les boutons ;
Pour modifier les paramètres d’un champ, cliquer sur son numéro (couleur de numéro bleu foncé sur
fond bleu) à gauche du nom ;
Zone de paramétrage des champs de données d’un workflow.
Lorsque le concepteur ajoute ou modifie un champ, la fenêtre suivante s’affiche :
1.5 Publier un workflow
1.5.1 Rendre le workflow visible pour les utilisateurs dans eProcess Local
La publication d’un workflow dans eProcess Local se déclenche dans son écran de paramétrage :
Zone de paramétrage des caractéristiques générales d’un workflow.

1.5.2 Adresse d’accès direct au workflow

Lorsqu’un workflow est publié dans eProcess Local, il est possible de fournir aux utilisateurs une adresse
(URL) pour accéder directement à la rédaction d’une demande dans ce workflow. Cela permet d’éviter de
sélectionner une instance puis un workflow avant de commencer à rédiger sa demande.
L’adresse a le format suivant :
http://h01.intra.renault.fr/h01/index.php?action=creerDmnd&IdWf=XXXX
où XXXX est à remplacer par l'identifiant du workflow
Annexe B
Paramétrage Tridion
1. Modifier les paramètres de votre Site : modifier le composant « Paramétrage du
site »
Paramétrer un Site consiste, dans le répertoire Paramétrage du Site, à mettre à jour le Composant
Paramétrage du Site.
Remarque :
Le composant « Paramétrage du site » contrôle notamment :
 Le choix de la charte graphique

 Le choix de la langue d’affichage par défaut du site

 Le choix du mode de publication pour le multilinguisme (publication automatique ou non)
 L’option publication directe à la fin du workflow
 L’option pour notifier ou non via e-mail pour le workflow d’approbation
2. Modifier les fonctions transverses : modifier les répertoires du Menu du Haut
Modifier les répertories du menu haut consiste, dans le répertoire Menu Haut, à créer, supprimer ou
renommer les sous répertoires souhaités. Cela aura pour effet de modifier les libellés affichés dans le
menu haut du site.
Pour modifier les répertoires, utilisez exclusivement l’assistant « Gestion des Répertoires » :
3. Modifier les domaines : modifier les répertoires de type domaine
Modifier les Domaines du Site consiste, sous le répertoire Accueil, à créer, supprimer, renommer des
répertoires de type Domaine.
Composant MAJ Menu Haut

Domaines
4. Pour chaque domaine, modifier les rubriques
Modifier les rubriques et/ou sous rubriques d’un domaine consiste à créer, supprimer, ou renommer les
sous répertoires du domaine concerné
Pour modifier les répertoires, utilisez exclusivement l’assistant de « Gestion des Répertoires ».
5. Modifier les pages d’accueil du répertoire Accueil et de chaque domaine :
Les pages d’accueil (composant de type Home) ne peuvent être remplies que par 3 types de boîtes :
 Les boîtes de type « Boîte message prioritaire »
 Les boîtes de type « Boîte manuelle » ou « Boîte à contenu éditorial »
 Les boîtes de type « Boîtes automatique » (plusieurs types de boîtes automatiques existent)

Champs pour insérer des boîtes manuelles

ou
automatiques
Champs pour créer une boîte message prioritaire
6. Mettre en place les Workflows dans Tridion
Dans Tridion, pour initier un circuit d’approbation (un workflow de validation), vous devez :
 Faire un clic droit sur le répertoire dont les contenus seront soumis à validation par un groupe ARCA
(généralement le groupe « Approbateur »)
 Sélectionner « Propriétés »
 Dans l’onglet Général, cliquer sur « Groupe Workflow » et une fenêtre apparaîtra en pop-up
 Sélectionner le groupe qui fera l’approbation et valider.
Remarque : pour désactiver le workflow, sélectionner « Aucun » dans la liste des groupes.
7. Republier
La republication est à réaliser après toute modification de répertoires (création, suppression, renommage,
état cliquable ou non cliquable).
Dans tous les cas, vous devez republier le plan du site (Contenus/Paramétrage du site/Menu haut/Plan du
site) car il reflète l’arborescence du site entier

 S’il y a une modification sur les répertories du menu haut : republier MAJ Menu Haut
 S’il y a une modification sur les répertories la barre d’onglet (les domaines): republier la page
d’accueil (Home) de site.
 S’il y a une modification sur les répertories du menu gauche de navigation (les rubriques et/ou
sous rubriques d’un domaine): republier la page d’accueil (Home) du domaine correspondant
 S’il y a une modification sur le nom d’un répertoire, cela provoque un changement de l’affichage
du chemin des composants contenus dans ce répertoire (le chemin est affiché sous la barre
d’onglet): il faut republier un composant pour mettre à jour son chemin.
Annexe C
Univers UCM GRET

Annexe D
BackLog prduit

Références
Bibliographie
URLographie
http://search.intra.renualt.fr/search
http://www.intra.renault.fr
http://fr.wikipedia/wiki/Wiki
http://www.codes-sources.com
http://fr.wikipedia/wiki/Wiki
http://www.bussines-object-creative.com
http://www.developpez.com
http://wiki.intra.renault.fr:8080/wiki/dosearchsite.action
http://fofab.lha.renault.fr/FR/Espace_accueil/Espace_accueil.php
http://cartographie.renault.fr/cartographie/ref_carto_fr/standard/sl
ide0002.htm
http://www.reporting-source.com

Dédicaces

Transféré par

Droits d'auteur :

Formats disponibles

Dédicaces

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dédicaces

Transféré par

Droits d'auteur :

Formats disponibles

Dédicaces

A nos chers parents,

On tient également à remercier Pr.EZZIYANI Mostafa, notre encadrant et enseignant à la

On tient à remercier tout particulièrement et à témoigner toute notre reconnaissance aux

RENAULT – Usine Tanger DSI Service Manufacturing Page 3/98

La troisième étape a été celle de l’amélioration du système en étendant ses fonctionnalités

RENAULT – Usine Tanger DSI Service Manufacturing Page 4/98

In the framework of our graduation project in computer science engineering at Renault

RENAULT – Usine Tanger DSI Service Manufacturing Page 5/98

Table des Matières :

RENAULT – Usine Tanger DSI Service Manufacturing Page 6/98

RENAULT – Usine Tanger DSI Service Manufacturing Page 7/98

Liste des figures :

RENAULT – Usine Tanger DSI Service Manufacturing Page 8/98

Liste des abréviations :

RENAULT – Usine Tanger DSI Service Manufacturing Page 9/98

Check -man : Contrôleur de défauts.

RENAULT – Usine Tanger DSI Service Manufacturing Page 10/98

RENAULT – Usine Tanger DSI Service Manufacturing Page 11/98

Le présent chapitre décrit le contexte général du projet,

1. Présentation de l’organisme d’accueil

RENAULT – Usine Tanger DSI Service Manufacturing Page 12/98

1.1 Historique Renault Maroc

1.2 Renault Tanger Exploitation

RENAULT – Usine Tanger DSI Service Manufacturing Page 13/98

La vision stratégique du gouvernement marocain est d’intégrer le Royaume dans un plan de

Un projet économique, industriel et humain d’envergure

 Inauguration du site industriel de Renault-Nissan de Tanger (Maroc)

RENAULT – Usine Tanger DSI Service Manufacturing Page 14/98

1.2.2 Processus de fabrication

RENAULT – Usine Tanger DSI Service Manufacturing Page 15/98

L’emboutissage consiste en la fabrication des éléments de carrosserie à l’aide de presses. Les

RENAULT – Usine Tanger DSI Service Manufacturing Page 16/98

Atelier Tri stock

RENAULT – Usine Tanger DSI Service Manufacturing Page 17/98

Figure 1.1 : Organigramme Renault

1.3 Département système d’information

RENAULT – Usine Tanger DSI Service Manufacturing Page 18/98

 Des systèmes appelés « spécifiques » (ou encore : non standards, de conception

RENAULT – Usine Tanger DSI Service Manufacturing Page 19/98

 Gérer la maintenance industrielle programmée des moyens de production

1.3.2 Organigramme DSI Manufacturing

Figure 1.2: Organigramme DSI Manufacturing

2. Contexte générale du projet :

RENAULT – Usine Tanger DSI Service Manufacturing Page 20/98

Dans un environnement compétitif comme celui de l’industrie automobile : efficacité, qualité et

Les systèmes d’information de Fabrication visent à répondre à des objectifs spécifiques :

 Réduction des coûts.

 Piloter et contrôler les flux de fabrication.

RENAULT – Usine Tanger DSI Service Manufacturing Page 21/98

 Gérer les ordres de fabrication.

RENAULT – Usine Tanger DSI Service Manufacturing Page 22/98

 Permettre le suivi des statistiques de productions (fonction tableau de bord) en implémentant

2.2 La méthodologie adoptée

RENAULT – Usine Tanger DSI Service Manufacturing Page 23/98

2.2.3 Le choix de la méthodologie Scrum

Figure 1.3 : cycle de développement d’un projet SCRUM

RENAULT – Usine Tanger DSI Service Manufacturing Page 24/98

2.2.4 La méthodologie Scrum