Cohérence des données

Dès la mise en production, nous avons été confrontés à un problème que nous n’avons pas rencontré lors de la préproduction et des tests de l’application.

PLE reçoit des informations référentielles concernant les COFOR en provenance de BFP

d’une part et de RFR d’autre part. Les règles que nous appliquons pour intégrer ces données référentielles sont les suivantes :

• Passage du traitement d’intégration des données de BFP et mise à jour de la base de

données avec ces informations.

• Passage du traitement d’intégration des données de RFR, recherche des informations à

enrichir (COFOR hybrides) et mise à jour de ces données.

Il s’avère que pour des raisons fonctionnelles, certaines données issues de BFP ont étés mises en cohérence avec des données d’autres systèmes, pour assurer une justesse des informations de bout en bout.

PLE rediffuse des informations à de multiples systèmes avals. L’intégration des données

référentielles de RFR dans PLE a engendré le cas suivant :

• Des données de COFOR Expéditeur sont transmises en direction de l’application RFX

(Référentiel des FluX logistiques). RFX va router des informations à destination de systèmes avals. Lors de ce transfert de données vers l’application GLOBE (Gestion de la Logistique des Ordres et de la flexiBilité des Eléments détachés) notamment, RFX va vérifier la cohérence des données reçues de PLE avec celles qu’il reçoit du système

PEGASE, émet une alerte en cas d’incohérence et place alors le flux concerné en

Dominique ALTHUSER 19/08/2010 Page 54 sur 103

Figure 31 : Cheminement inter-applications du COFOR Expéditeur

Et c’est ce qui s’est passé lors du premier passage de ces traitements en production : des anomalies concernant environ quatre-vingt COFOR Expéditeur ont été remontées par RFX. Nous nous trouvions donc dans une situation quelque peu inédite : l’intégration dans PLE de données référentielles créait des effets de bord sur des applications avals, comme dans

GLOBE depuis RFX. Une cellule de crise réunissant l’ensemble des parties prenantes des

applications concernées a été constituée immédiatement pour décider de la manière de traiter les écarts constatés. Ces écarts, d’origines multiples, ont été traités au cas par cas. L’analyse de chaque écart a eu lieu, une action correctrice a été entreprise dans chacun des systèmes concernés pour aligner les données et ainsi d’assurer leur cohérence de bout en bout.

Du côté de PLE, nous avons mis en place un traitement supplémentaire aux deux traitements pour l’intégration des données des COFOR. Ce traitement est ainsi chargé, tout le temps que durera l’action de mise en cohérence des données sur tous les systèmes, de forcer le COFOR Expéditeur à sa « mauvaise » valeur, c'est-à-dire de lui attribuer la valeur nécessaire pour qu’il ne soit plus en erreur lors des différents passages dans les systèmes, notamment dans RFX. Ce traitement complémentaire a été retiré de la production début avril 2010, date à laquelle tous les écarts initialement constatés ont été résolus.

Le problème d’incohérences de données initialement survenu a finalement donné lieu à une démarche de convergence des référentiels, préalable au bon déploiement de CORAIL.

Ce problème a également montré toute la complexité du suivi des données au travers des systèmes. Il ne suffit pas de faire des tests, si poussés soient-ils, au sein d’une application et de ses applications adjacentes. Il est absolument nécessaire de tester les données depuis leur intégration dans les systèmes jusqu’à chacun des points qui les utilisent. L’exercice n’est toutefois pas simple à mettre en œuvre. Pour arriver à tester ces données de bout en bout, il faut que l’ensemble des environnements de préproduction des applications concernées soient disponibles et en cohérence avec les données à tester. C’est quelque chose qui est difficile à obtenir parce que chacune de ces applications est utilisée avec des données potentiellement différentes, au gré des évolutions et versions en cours de développement sur ces applications. Il faudra néanmoins à l’avenir partager un jeu de données entre toutes les applications concernées, afin de garantir cette cohérence nécessaire pour éviter que ce problème ne survienne à nouveau.

Dominique ALTHUSER 19/08/2010 Page 55 sur 103

Cela m’a permis d’enrichir le dossier de tests avec une rubrique spécifique pour mener des tests sur des données depuis l’intégration de ces données dans les systèmes jusqu’à chacun des points d’utilisation de ces données. C’est également de cette manière qu’il faudra procéder lorsque nous testerons l’échange de données entre CORAIL et PLE.

Nous venons de voir au cours de ce chapitre et de celui qui le précédait la conduite d’une étude préalable et d’un projet de réalisation, du point de vue du CPI qui anime et conduit son équipe vers la mise en production de l’application.

Ce n’est cependant pas le seul rôle du CPI, il doit également piloter son projet et son application du point de vue du suivi, du reporting et de la qualité. Ce pilotage et ce suivi contribuent aussi à préparer l’accostage entre PLE et CORAIL. C’est ce que je vais démontrer dans le chapitre suivant.

Dominique ALTHUSER 19/08/2010 Page 56 sur 103

4 Pilotage du projet

Nous avons suivi la conduite d’une nouvelle version d’une application au travers des phases d’étude préalable et de projet de réalisation.

Si le CPI du projet conduit effectivement les travaux à réaliser (gestion des ressources, du planning, …), il ne le fait pas sans aide, ce serait bien trop fastidieux et risqué.

Il existe toute une panoplie d’outils qui sont mis à sa disposition pour l’épauler dans cette tâche de pilotage de projet, afin qu’il puisse y voir clair et qu’il sache à tout moment où en est son projet.

C’est l’objet de ce chapitre qui va en premier lieu expliquer la démarche projet du Groupe

PSA, puis montrer les livrables qui sont produits et qui servent au pilotage du projet. Il sera

indiqué ensuite comment est gérée l’application PLE en vie courante, hors phase projet.

4.1 La démarche projet PSA