Je tiens à exprimer tous mes remerciements à mon responsable du stage, Mme. Séverine PANHELLEUX, et mon tuteur, M. Romuald HATON, pour leur accueil, leur aide et conseils tout au long de mon stage.

Je tiens à remercier l’Université de Technologie de Compiègne avec mon suiveur d‘école, M. Arnaud DERATHE, et mon responsable de formation, M. Gilbert FARGES, qui m’ont enrichi de leur savoir en management de la qualité.

Je remercie aussi tous mes collègues du projet et la direction de l’Assurance Qualité des Projets Véhicules pour leur assistance de mon stage.

MERCI A TOUS DE VOTRE ACCOMPAGNEMENT ET VOS FAVEURS !

1.1. Qualité dans le secteur Automobile

Le secteur automobile constitue un modèle économique en transition : concurrence des marques low-cost ; exigences environnementales qui induisent de nouvelles orientations technologiques ; attentes nouvelles des consommateurs qui, tout en recherchant un haut niveau de sécurité, sont en attente de véhicules moins chers et plus économes en énergie ; montée en puissance des pays émergents qui remettent en cause une partie de la production en France ; programme d’un véhicule « décarboné » nécessitant de nouvelles ressources et de nouvelles compétences.

Il y a par conséquent, d’une part des enjeux autour du produit : en raison de l’évolution liée à des besoins d’usage nouvellement affirmés et d’autre part des enjeux autour du processus de production et du service de commercialisation pour demeurer compétitif. [3]

1.2. Contexte et enjeux du projet

1.2.1. Logique de développement des projets d’entreprise

Tout projet d’entreprise s’appuie sur une logique de développement structurée en phases, le passage d’une phase à une autre est marqué par un jalon projet.

Les principes généraux des bases de la logique et comme ci-dessous :

 

Figure 1 : Logique de développement des projets véhicules [1]

La logique de développement du projet a trois fonctions principales :
-    synchroniser tous les acteurs du projet
-    garantir en continu la tenue de la trajectoire de convergence du projet
-    autoriser l’engagement des étapes ultérieures

Le franchissement du jalon projet est prononcé sur la base de l’analyse de l’état d’avancement du projet par rapport aux résultats décisifs attendus. [1]

Les jalons projet font l’objet d’un avis ou d’un accord émanant du directeur de la qualité ou d’un niveau ayant délégation d’activité et/ou d’autorité. Les niveaux de délégation d’autorité sont définis en fonction des enjeux financiers et techniques.

1.2.2. Référentiels et Tableaux de Bord

Les principes d’AQP ont été déployés à certains types de projet avec des référentiels. Divers secteurs qualité font l’AQP et gèrent leurs propres référentiels. Un référentiel est l’ensemble des attendus du projet. L’évolution des référentiels est validée par le comité de pilotage chaque trimestre.

Dans mon stage, le périmètre est limité aux projets véhicules et transverses (modules, innovations etc.) avec plusieurs types des référentiels. Il y a aussi des référentiels d’autres types de projet comme projet mécanique et projet système qui sont pris en charges par d’autres personnes dans les autres secteurs.

Un Tableau de Bord (TdB) est généré par le référentiel par chaque jalon du projet. A ce jour dans le secteur AQP Véhicules, tous les référentiels sont dans une base Access et le TdB est sous forme d’Excel. Dans un TdB, il y a (Annexe 1) :

-    un onglet de la liste d’attendus. Les attendus consistent en leurs indicateurs, commentaires et responsables etc.
-    un onglet du radar par l’axe d’attendus.
-    plusieurs onglets pour évaluer chaque attendu. Les onglets sont formulés par  les cotations (vert, orange, rouge), les écarts, les plans d’action etc.

 

Figure 2 : Relation entre la base Access et les TdB  [2]

1.2.3. Processus Métier des projets véhicules

Les Ingénieurs Assurance Qualité (IAQ) prennent en charge de la qualité des projets véhicules. L’IAQ applique par chaque jalon projet un cycle des activités. Le processus simplifié est comme ci-dessous :

 

Figure 3 : Processus Métier IAQ [2]

Pendant la préparation du Jalon projet, l’IAQ récupère le TdB du jalon correspondant dans le référentiel officiel et prend en main cette liste d’attendus. Il diffuse les attendus aux acteurs et les évalue par les retours des acteurs. Une présentation est ensuite faite à partir du radar du jalon et de la synthèse des plans d’action. Enfin, une note d’avis ou d’accord officialise la position de la qualité (donnée d’entrée pour décider de prononcer le jalon ou pas).

1.3. Cahier des charges

1.3.1. Outil du système d’information et son historique

Au tout début, chaque secteur qualité faisait l’AQP avec ses outils internes et spécifiques à périmètre. L’entreprise a souhaité converger sur un outil informatique pour les secteurs qualité.

Cet outil du système d’information est une application manipulable en navigateur Web [4] et accessible par l’intranet de l’entreprise. Cette application est mise à la disposition des acteurs dans l’optique de gérer l’intégralité des TdB de chaque référentiel. (Annexe 2)

Avant 2015, l’application gérait des checklists simples avec une seule façon d’estimer l’attendu. Dans le secteur AQP Véhicules, les fiches et les TdB des référentiels n’étaient pas gérés dans l’outil, mais dans une base Access et des Macros Excel.

En 2015, une première version d’Expression des Besoins Fonctionnels (EBF) a été validée et développée mais n’a pas été complètement testée faute de ressources côté métier.

1.3.2. Nouveau besoin du secteur

En  2017, plusieurs secteurs qualité commencent à travailler ensemble sur l’évolution de l’application. La couverture de l’application est devenue plus large aujourd’hui.

Le secteur AQP Véhicules souhaite finaliser l’implémentation de cet outil du SI pour son Processus Métier. Pendant ce projet, mon rôle représente les IAQ Véhicules avec tous leurs besoins, les activités principales sont par conséquent :

-    formaliser la nouvelle EBF 2017 avec la base de l’existant en 2015
-    spécifier le besoin en discutant avec les parties prenantes (l’informatique et les autres secteurs qualité)
-    effectuer les recettes de l’application
-    formaliser une guide pour aider les IAQ (manuels utilisateur et administrateur)

Enfin, une décision de Go / No Go de la phase pilote sera prise en compte par la direction.

 
1.4. Problématique (QQOQCP)

Une méthode QQOQCP a été élaborée afin de bien cadrer la problématique à partir du cahier des charges du projet de stage :

Tableau 1 : Table QQOQCP [2]

Donnée d’entrée :	Processus Métier IAQ
Qui ?	Directs Emetteurs : Métier de l’Assurance Qualité de Projets Véhicules Récepteurs : IAQ Véhicules	Indirects Emetteurs : Autres secteurs assurance qualité Récepteurs : utilisateurs des autres secteurs
Quoi ?	Développer l’outil du système d’information et l’implémenter dans le Processus Métier
Où ?	Dans le secteur AQP Véhicules
Quand ?	Tous au long du Processus Métier des IAQ Véhicules
Comment ?	- Identifier le CdC pour l’évolution de l’application - Effectuer la recette et valider les fonctionnalités - Formaliser les utilisateurs avec le manuel
Pourquoi ?	- Réduire les risques potentiels de l’utilisation des outils actuels - Pérenniser les activités des IAQ Véhicules en utilisant un outil officiel d’entreprise
Donnée de sortie :	Quelles sont les critères pour que les IAQ puissent appliquer leurs Processus Métier à l’outil du système d’information ?

 

1.5. Analyse SWOT

Pris en compte la complexité du projet, une analyse SWOT a été fait afin de faire savoir la situation du projet et de prévenir les risques éventuels :

Figure 4 : Analyse SWOT du projet [2]

2.1. Cycle en V de la conception

Un modèle du cycle en V est utilisé fréquemment pour une conception du projet informatique. Ce diagramme est à vous exposer les étapes principales du projet :

Figure 5 : Cycle en V de la concpetion [2]

Tout au long de mon projet, des questions ont été posées afin d’identifier l’état du projet et de bien dérouler le projet :

-    1ière étape Processus Métier : Au tout début de projet, une connaissance de Processus Métier actuel des IAQ est incontournable. Est-ce que le processus est bien écrit et formalisé ? Comment les IAQ respectent le processus à leurs travaux réels ? Est-ce que les outils en cours sont efficaces et le système d’information actuel est fiable ?
-    2ième étape Expression des Besoins : L’EBF est une liste des besoins des fonctions de l’application contractualisée côté métier. La consolidation de l’EBF est un amont du développement. Est-ce que l’EBF est conforme aux besoins client et tous couvre ?
-    3ième étape Cahier des charges : Un CdC décrit les fonctionnalités concrètes et les défauts ou anomalies à corriger pour l’informatique. Comment communiquer avec l’informatique et prendre un accord sur le développement ?
-    4ième étape Développement : Quelles sont les priorités des besoins à développer ?
-    5ième étape Recette des fonctionnalités : Pendant la recette de l’application, est-ce que les fonctionnalités bien répondent les besoins ? Est-ce qu’elles sont fiables et ergonomiques ?
-    6ième étape Validation et opération : Est-ce que les fonctions réalisées sont suffisantes pour l’implémentation de l’application ? Est-ce qu’il y a encore des écarts et quels sont les plans d’action ?

Toutes ses questions synthétiseraient et se diviseraient par trois grands thèmes de questions qui seront exprimée dans ce chapitre:

-    Comment adapter le besoin client au produit et le vendre ?
-    Comment développer l’application et assurer son déroulement ?
-    Comment déployer une phase recette Key User et quelle est son attente ?

2.2. Comment adapter les besoins client au produit et le vendre ?

Le processus de l’assurance qualité du Métier actuel se déroule bien, donc les intérêts de l’application à implémentée sont devenus une question importante du projet.
Pour répondre cette question, trois choses ont été effectuées :

-    Une liste de l’EBF pour cadrer le périmètre et le développement de l’application
-    Une analyse de la conduite du changement sur les activités des IAQ
-    Une guide préparée évidemment pour formaliser les IAQ

2.2.1. EBF utilisation et administration client

L’EBF est des descriptions des besoins sur les fonctions de l’application au point de vue du client. Il est classifié par certains critères :

-    Sujet : Les besoins peuvent être une fonction technique ou une description d’affichage, donc les besoins divisent par le sujet qui permet de les retrouver rapidement. Par exemple : TdB, Radar et IHM (Interface Hors Machine) etc.
-    Use cases : trois types de fonction ont été par ailleurs définis comme utilisation, administration ou les deux.
-    Importance : Tous les besoins sont classifiés par Must Have et Nice to Have qui signifient la priorité des fonctions.
-    Statut : Un statut pour chaque besoin permet de suivre l’avancement du développement de l’application. Par exemple : réalisé, non-réalisé et fonction à terminer etc.

Le classement, surtout l’importance des besoins, permet d’aider à planifier et suivre le développement des fonctions.

Prise en considération des contraintes techniques, financières ou du délai, l’EBF a été aussi modifiée en cours de développement afin d’adapter le cas réel. Par exemple pour une fonction très spécifique et complexe, l’informatique avait proposé une autre façon du comportement. Après l’échange, le secteur l’a considéré comme une fonction dégradée mais elle a été acceptée. A ce moment-là, le besoin Must Have peut être reclassé comme Nice to Have ou reformulé avec le nouveau comportement.

2.2.2. Conduite du changement

L’implémentation de l’application prévue ne doit pas changer le Processus Métier mais seulement les outils. L’analyse des difficultés liées à l’évolution de l’application permet de prévoir la conduite du changement appropriée.

Figure 6 : Conduite du changement [2]

1)    Gestion du référentiel :
Pour le processus actuel, le gestionnaire du référentiel met à jour son référentiel dans la base Access après chaque évolution des référentiels. La base Access conserve les nouvelles versions des référentiels autant que les versions passées. Le gestionnaire lance la macro Excel pour générer les TdB vides (liste des attendus) par jalon à partir de la base.
Avec l’application, les référentiels peuvent être mis à jour directement dans l’application. L’application gère chaque référentiel avec une version officiel (non-modifiable) et une version en draft pour mettre à jour les données. La liste des attendus du TdB est alimentée par l’application automatiquement.

2)    Evolution et propagation du référentiel :
Puisque un projet véhicule peut durer plusieurs années et l’évolution des référentiels se déroule par trimestre. Selon la stratégie d’évolution des référentiels, le TdB actuel est figé par la version du référentiel en cours après le cadrage de son jalon.
Dans l’application, le TdB contient tous les jalons du projet. Afin d’adapter le comportement de la MAJ des données des TdB techniquement, une fonction de la propagation des référentiels a été développée :

Figure 7 : Evolution des référentiels et propagation des TdB [2]

3)    Initialisation et documentation du TdB :
Comparé aux outils actuels, pour retrouver ses TdB du jalon l’IAQ n’a pas besoin d’entrer à l’arborescence dans le disque en réseau de l’entreprise. Les TdB sont listés dans l’application Web et peuvent être filtrés par certains paramètres pour que l’IAQ puisse trouver son TdB facilement.

4)    Présentation et officialisation du jalon :
L’application n’intervient pas à la présentation et la note d’avis / d’accord, mais elle permet d’exporter une synthèse des attendus en PDF ou Excel et de copier le radar directement dans l’outil ailleurs (PPT).

2.2.3. Guide de l’utilisation et l’administration

La guide de l’application est définie comme un des livrables du projet. Deux manuels sur l’utilisation et l’administration ont été rédigés :

Le manuel de l’utilisation décrit :

-    Autorisation d’accès à l’application
-    Procédures de créer le TdB et le documenter
-    Export de la synthèse et du radar

Le manuel de l’administration décrit :

-    Administration des droits utilisateur
-    Gestion des référentiels et propagation

Lors que l’application est toujours en cours du développement, les manuels sont provisoires.

Par ailleurs, un carnet de l’utilisation qui synthétise les fonctions de l’application est prévu et en cours de préparer. Comparé aux manuels, il est plus simple mais facile de parcourir dans la main qui permet les IAQ de se souvenir. Le sommaire sera divisé par le nouveau Processus Métier mais pas fonction par fonction, donc il est plus habitué aux activités de l’AQP par les IAQ.

2.3. Comment développer l’application et assurer son déroulement ?

Comme les autres applications Web, il y a plusieurs éditions pour son développement et sa maintenance :

-    Une édition pour les développeurs de l’informatique
-    Une édition « RE7 » pour effectuer la recette par les testeurs MOA et MOE
-    Une édition « OPER » où les utilisateurs mettent en opération avec leur vrai travail

Pour le secteur AQP Véhicules, l’application est en cours d’étudier, cependant, dans le secteur système, plusieurs activités sont déjà mises en place dans l’OPER. Pour éviter les risques de bloquer l’application, toutes les fonctions sont testées dans « RE7 » et implémentées dans « OPER » après validation par toutes les parties prenantes.

2.3.1. Méthode du développement informatique

En 2015, l’application a été développée par lotissement. Un lotissement est une méthode du développement divisé par lot de l’application. Pendant chaque lot, les MOA fournissent à l’informatique un CdC qui contractualise plein de fonctions à développer. L’informatique réalise toutes les fonctions d’un seul coup. Enfin les MOA effectuent le test et les fonctions sont déployées après la validation de tous.

En 2017, une méthode agile du développement informatique est utilisée. Les MOA prennent en contact avec l’informatique tout le temps en méthode agile. Les demandes de nouvelles fonctions ou les observations des anomalies et bugs ont été partagées avec l’informatique par réunion hebdomadaire. L’informatique est contactée immédiatement si un problème grave ou urgent est rencontré. Les opinions du développement sont échangées fréquemment entre l’informatique et les MOA.

Les fonctions sont développées et testées par sprint. Un sprint est plus léger qu’un lot. Pendant chaque sprint, moins de fonctions sont à développer. L’informatique réalise les fonctions et les diffuse par un cahier de recette aux MOA dans quelques semaines.

Une gravité des fonctions manquantes ou des défauts constatés est définie comme :

-    K1 : bloquant (interdit l’utilisation)
-    K2 : Gênant mais pas bloquant (on peut avoir un mode de l’utilisation)
-    K3 : Peu gênant (confort)

L’informatique réalise les fonctions et corriger les défauts par l’ordre de priorité en considérant leur complexité et gravité. Cette méthode permet de gagner du temps surtout pour reboucler les fonctions insatisfaisantes.

2.3.2. Comité d’évolution

Le comité d’évolution regroupe toutes les MOA des différents secteurs et l’informatique. Pendant le comité, les participants présentent les évolutions importantes, décident leur prise en compte et l’informatique présente le planning des évolutions pour les prochains sprints. Une fiche de suivi des évolutions et anomalies converge tous ceux qui sont présentés en comité. Un pilote du comité d’évolution assure le déroulement de la réunion organisé une fois ou deux fois par mois.

Le comité d’évolution permet de faire l’accord et la cohérence du développement de l’application par exemple la gestion des profils utilisateur et administrateur et le règle du calcul cotations des attendus etc. Quelques besoins spécifiques ont été harmonisés pendant les réunions, donc le comité profite au coût du développement. Par ailleurs, l’informatique gaspille moins de temps sur présenter le planning du développement ou les informations importantes aux différents MOA (sans/moins répétition).

2.4. Comment déployer la recette et l’évaluation de Key User et quelle est son attente ?

Après la SWOT de l’application, l’état du déploiement et le planning des étapes suivantes ont été présentés en comité de direction, le secteur AQP Véhicules a décidé d’engager les ressources à la recette et l’évaluation de l’application. Le Key User va tester l’application en simulant partiellement le vrai travail de l’AQP.

La phase pilote sera prononcée après la synthèse d’évaluation de Key User. Concernant le développement de l’application est en méthode agile et toujours en cours, quelques fonctions ne seront pas réalisées. Cependant pour prononcer le Go pour la phase pilote, les besoins non-conformes devraient :

-    Aucune fonction K1
-    Toutes fonctions K2 avec les plans d’action cohérents et acceptés par Key User

2.4.1. Prérequis de la recette

La checklist des prérequis de la recette est indispensable pour assurer un bon déploiement de la recette et évaluation :

-    Comme déjà mentionné, la guide utilisation et administration est prête pour formaliser les évaluateurs.
-   Tous les référentiels à tester sont concernés dans l’application. Une fonction spécifique de la migration des référentiels pour les projets véhicules a été développée qui permet d’exporter une fiche par la base Access et de l’importer dans l’application.
-    Le questionnaire de l’évaluation de l’application a été préparé. Le questionnaire est divisé par les différentes étapes de nouveau processus avec plusieurs sujets détaillés. Le score est classé par bloquant, gênant et satisfaisant avec 6 niveaux. (Annexe 3)

2.4.2. Déploiement de la recette et évaluation des IAQ

Le Key User de la recette a été défini et nommé comme un IAQ par gamme du projet véhicule. Les évaluateurs IAQ sont localisés en différents pays mondiaux pour que l’application puisse être testée par l’interface en français et anglais et sur la compatibilité des dispositifs des différents sièges d’entreprise dans le monde. Les évaluateurs seront aussi les pilotes de la phase pilote d’après.

La recette a été effectuée en mi-juin 2017. En première étape, plusieurs créneaux de réunion ont été effectués par MOA (mon tuteur et moi), MOE (développeurs de l’application) et clients (évaluateurs IAQ). Une méthode « I do, We do, You do » a été appliquée :

    I do : Je démontre et explique l’utilisation de l’application.
    We do : On fait ensemble (Q&R face à face).
    You do : Les évaluateurs font la recette tout seul.

Après la formation, les questionnaires ont été diffusés aux évaluateurs avec les manuels en support. Une synthèse des évaluations est en cours de construire.

3.1. Résultats obtenus du projet

3.1.1. Bilan de l’EBF en 2017

Figure 8 : Evolution EBF 2015/2017 pour projets véhicules  [1]

En raison de l’ajout, du reclassement et de l’abandon des besoins, la nouvelle EBF est moins qu’en 2015, mais il y a plus de Must Have définis. Ça signifie une exigence augmentée du client sur l’application depuis 2015. Il y a quelques nouveaux besoins qui apporteraient « Quick-Win » à l’application, donc ils sont aussi classés comme Must Have.

Figure 9 : Taux de réalisation de l’EBF  [1]

Depuis juin 2017, 85% de Must Have a été réalisé. Il y a moins de Nice to Have réalisés en considérant la priorité, mais environ 80% [1] des Nice to Have a été consolidé et planifié.

3.1.2. Synthèse des évaluations des Key User

Dès à présent, la recette et l’évaluation des Key User est encore en cours. La synthèse des évaluations est en construction. Elle est prévue avec la fréquence et l’importance des remarques (bonnes et mauvaises).


3.2. Valeur ajoutée pour le secteur AQP Véhicules

La valeur ajoutée de l’application pour le secteur AQP Véhicules présente deux aspects :

L’application permet de réduire les risques potentiels de l’utilisation. Par exemple, en utilisant les outils actuels, l’IAQ pourrait récupérer le TdB de la mauvaise version ou avec les mauvaises données. Avec l’application, la gestion des données et l’AQP sont effectuées dans un seul système d’information.

L’application permet de pérenniser les activités des IAQ. Prise en compte de l’augmentation de la base de données, peut-être un jour il arrivera un problème de la défaillance pour la gestion des données dans MS Access. La Macro pour générer le TdB n’est pas maintenue par les techniciens aujourd’hui, donc il existe aussi un risque. Cependant, il existe contractuellement une équipe informatique pour développer et maintenir l’application.

[1] « Document interne d’entreprise ».

[2] Z. Yueqi, « Adapter un Système d’Information à la gestion de Tableaux de Bord qualité », Université de Technologie de Compiègne, Master Qualité et Performance dans les Organisations (QPO), Mémoire d’intelligence Méthodologique du stage professionnel de fin d’études, www.utc.fr/master-qualite, puis "Travaux" "Qualité-Management", réf n°412, juin 2017.

[3] « La qualité dans le secteur automobile ». [En ligne]. Disponible sur : http://www.qualiteperformance.org/comprendre-la-qualite/la-qualite-par-secteurs-d-activite/la-qualite-dans-le-secteur-automobile/ . [Consulté le : 02-Mai-2017].

[4] « Application web ». [En ligne]. Disponible sur Wikipédia. [Consulté le : 21-Juin-2017].

[5] De Courcy R., Les systèmes d'information en réadaptation, Québec, Réseau international CIDIH et facteurs environnementaux, 1992, no 5 vol. 1-2 p. 7-10

Assurance Qualité des Projets Véhicules :
C’est un contrôle et une maîtrise des risques potentiels par apport aux enjeux financiers et techniques du projet. C’est aussi une conformité des produits et des services aux besoins client et un renforcement des compétences pour adapter l’évolution du marché.

Key User :
Le Key User est un IAQ utilisateur de l’application qui participe à l’évaluation et la phase pilote.

Phase pilote :
Une phase pilote est une mise en œuvre d’activité AQP en conditions réelles les pilotes IAQ (Key User).

Recette :
La recette a pour l’objectif de vérifier et valider le développement d’un outil informatique. Un cahier de recette est diffusé après chaque phase du développement (sprint) par l’informatique. Les fonctions à tester et leurs étapes sont précisées dans un cahier de recette. En fonction des résultats, soit en applique (recette OK), soit en continue (recette KO).

Système d’information :
Le système d'information (SI) est un ensemble organisé de ressources qui permet de collecter, stocker, traiter et distribuer de l'information. [5]
Dans l’application, le SI comprend :

-    Les données (référentiels)
-    Les TdB des utilisateurs
-    Les liens vers EdP (justificatif)

Il ne comprend pas :

-    Les Notes d’avis / accord
-    Les documents EdP