La Business Intelligence au sein du système … · I had an opportunity to discover Airbus and Sopra methodologies, to observe a project piloting in a difficult condition. This internship

Master 2 MIAGE

2012-2013

PHAN Ngoc-Thang

Mémoire soutenu à l’Université le 27 Mai 2013

Encadrant : GOMEZ Anne Tuteur : PUJOLLE Geneviève

La Business Intelligence au

sein du système

d’informatique financier

d’Airbus MÉMOIRE DE STAGE DE FIN D’ETUDES

La Business Intelligence au sein du système d’informatique financier d’Airbus PHAN Ngoc-Thang

Page 2


Page 3

Remerciements

Avant de commencer ce rapport marquant la fin de mes études, je tiens à remercier toutes

les personnes qui tout au long de mon stage m’ont orientées dans la mission qui m’a été confiée.

Je tiens à remercier tout d'abord Eric d’Arco, qui m'a donné l'opportunité de réaliser mon

projet de fin d'étude dans le bundle FBI au sein de Sopra group Midi-Pyrénées.

Mes remerciements s'adressent aussi à Anne Gomez, ma tutrice de stage, qui s'est montrée

disponible tout au long du stage pour m’aider et me donner les conseils nécessaires.

Je tiens à remercier Myriam Serrano, ma chef de projet, et toute l’équipe One Report,

Vincent Lesiourd, Pablo Aguilar, Myriam Serres et Daheyna Paleatchy pour m’avoir aidé à bien

m’intégrer au projet et m’accompagner dans mes tâches. Merci pour leurs réponses à toutes mes

questions.

Je remercie également tous les membres du domaine FI BI pour leurs aides et leur accueil

sympathique. Merci pour l’ambiance plein d’humour et d’amitié que tout le monde a créé à chaque

jour de mon stage.

J’exprime mes remerciements à Madame Geneviève Pujolle, ma tutrice universitaire et

l’équipe enseignante de la formation MIAGE.

Enfin, tous mes remerciements à mes parents et mes amis, qui m’ont écouté, soutenu tout

au long de mon stage et de mes études. Merci d’être à côté de moi et de me donner les conseils

quand j’en ai besoin.


Page 4


Page 5

Résumé

Dans le cadre de ma dernière année d’étude de la formation MIAGE, j’ai effectué un stage de

6 mois (de décembre 2012 à mai 2013) au sein de Sopra Group Midi-Pyrénées. Ce stage s’est déroulé

dans le bundle FBI de l’agence 101 Aérospatiale, et s’inscrit dans le cadre de l’évolution d’une partie

du système d’information financière d’Airbus.

Au cours de mon stage, j’ai pu aborder la mise en œuvre d’un projet dans un contexte

industriel. J’ai participé avec l’équipe de projet à toutes les phases : l’analyse du besoin utilisateur, la

conception d’une solution en rapport avec les exigences utilisateurs, l’implémentation de la solution,

les tests de l’application et la mise à disposition de l’application aux utilisateurs.

Cette expérience m’a donné l’opportunité de travailler sur différents aspects du système

d’information complexe d’Airbus, avec le progiciel SAP R/3 et SAP BW. J’ai eu l’occasion de découvrir

des méthodologies de travail d’Airbus et Sopra, d’observer le pilotage d’un projet dans un contexte

difficile. Ce stage m’a permis d’avoir des premiers pas dans ma carrière professionnelle.

Abstract

For my final year in MIAGE, I did an internship for 6 months (December 2012-May 2013) in

the bundle FBI of Sopra Group Midi-Pyrenees. My task was to realize a reporting application in the

financial information system of Airbus.

During my internship, I was able to get into a project in an industrial context. I participated

with the project team in all phases: Business requirement analysis, solution design in relation to user

requirements, implementation of the solution, tests and delivery of the application to users.

This experience gave me a chance to work on different aspects of complex information

system with the SAP R/3 and SAP BW technologies. I had an opportunity to discover Airbus and Sopra

methodologies, to observe a project piloting in a difficult condition. This internship allowed me to

have a first step in my professional career.


Page 6


Page 7

Sommaires Remerciements .................................................................................................................................. 3

Résumé ....................................................................................................................................... 5

Abstract ...................................................................................................................................... 5

Sommaires .................................................................................................................................. 7

1. L’environnement de stage ................................................................................................... 9

1.1. Sopra Group ................................................................................................................ 9

1.1.1. Historique .............................................................................................................. 9

1.1.2. Activités et marchés .............................................................................................. 9

1.1.3. Chiffres clés ......................................................................................................... 10

1.1.4. Implantation France et International .................................................................. 10

1.2. Division Midi Pyrénées .............................................................................................. 11

1.3. Le Bundle FBI ............................................................................................................. 11

2. Synthèse des travaux ......................................................................................................... 13

2.1. L’informatique décisionnelle dans le domaine financier d’Airbus ............................ 13

2.2. Projet One Report...................................................................................................... 13

2.2.1. Présentation du projet ........................................................................................ 13

2.2.1.1. Le projet ARP ................................................................................................ 13

2.2.1.2. One Report, le projet reporting financier d’ARP .......................................... 14

2.2.1.3. L’organisation du projet ............................................................................... 15

2.2.2. Les méthodes de gestion de projet : GPP et e-Media ......................................... 16

2.2.2.1. Airbus GPP Toolkits ...................................................................................... 17

2.2.2.2. Sopra e-Media .............................................................................................. 18

2.2.3. L’environnement technique ................................................................................ 19

2.2.3.1. Le système d’information décisionnelle d’Airbus ........................................ 19

2.2.3.2. La solution BI de SAP .................................................................................... 20

2.2.3.3. La validation de l’application avec HPQC ..................................................... 22

2.2.4. Les travaux réalisés .............................................................................................. 22

2.2.4.1. Validation...................................................................................................... 22

2.2.4.1.1. Test d’intégration .................................................................................. 22

2.2.4.1.2. Gestion des anomalies .......................................................................... 24

2.2.4.2. Spécification ................................................................................................. 26

2.2.4.2.1. Spécification générale ........................................................................... 26

2.2.4.2.2. Spécification détaillée ........................................................................... 28

2.2.4.3. Développement ............................................................................................ 33

2.2.4.4. Livrables ........................................................................................................ 35

3. Sujet de réflexion : L’offshoring d’un projet informatique ............................................... 37

3.1.1. Introduction ........................................................................................................... 37

3.1.2. Choix du sujet ...................................................................................................... 37

3.1.3. Définition ............................................................................................................. 37

3.1.4. Le marché offshore international ........................................................................ 39

3.1.4.1. Les pays de services offshore ....................................................................... 39


Page 8

3.1.4.2. Les géants des sociétés offshore .................................................................. 40

3.2. Les enjeux .................................................................................................................. 41

3.2.1. Les bénéfices ....................................................................................................... 41

3.2.2. Les points critiques .............................................................................................. 44

3.3. L’offshoring : stratégie incontournable de Sopra ...................................................... 45

3.3.1. Offshore à SopraGroup........................................................................................ 45

3.3.1.1. SopraGroup India – Madrid – Casablanca .................................................... 46

3.3.1.2. Modèle « Soprasien » : Xshore ..................................................................... 47

3.3.1.3. L’approche basée sur l’évaluation des risques ............................................. 47

3.3.2. L’offshore dans le contexte du projet One Report .............................................. 50

3.3.2.1. Organisation des équipes FO-BO .................................................................. 50

3.3.2.2. Les premiers retours d’expériences ............................................................. 50

3.4. Une solution pour l’offshore : les méthodes agiles ................................................... 51

3.4.1. Amélioration du plan de communication ............................................................ 52

3.4.1.1. Mobiliser des ressources humaines ............................................................. 52

3.4.1.2. Gérer les problèmes interculturels............................................................... 53

3.4.1.3. Utiliser des bonnes méthodes de communication ....................................... 54

3.4.2. Amélioration du plan qualité ............................................................................... 55

3.4.2.1. Réduire les risques d’incompréhension ....................................................... 55

3.4.2.2. Faire valider régulièrement le travail ........................................................... 56

3.4.2.3. Répartir les équipes selon en fonction des modules développés ................ 57

3.4.2.4. Produire efficacement des documents ........................................................ 57

3.4.3. Conclusion ........................................................................................................... 58

4. Bilan ................................................................................................................................... 59

4.1. Bilan de compétences ............................................................................................... 59

4.1.1. Compétences techniques .................................................................................... 59

4.1.2. Compétences fonctionnelles du métier .............................................................. 60

4.1.3. Compétences de management ........................................................................... 61

4.2. Bilan professionnel .................................................................................................... 61

4.3. Bilan personnel .......................................................................................................... 62

4.4. Difficultés ................................................................................................................... 63

4.5. Conclusion ................................................................................................................. 64

Glossaires .................................................................................................................................. 65

Bibliographies ........................................................................................................................... 67

Annexes .................................................................................................................................... 71

Planning de stage...................................................................................................................... 78


Page 9

1. L’environnement de stage

1.1. Sopra Group

1.1.1. Historique

Sopra Group a été créé en janvier 1968 à Annecy, par ses fondateurs Pierre Pasquier,

François Odin et Léo Gantelet. Cette société, une des plus anciennes SSII européennes et top 10 des

sociétés européennes de Conseil et de Services informatiques, s’est rapidement imposée

nationalement et internationalement à partir de la création de sa première filiale internationale à

Genève en 1985.

Grâce à la réussite et à la croissance considérables, Sopra Group est entrée à la Bourse de

Paris avec succès en 1990.

Aujourd’hui, l’acquisition des différentes sociétés (SG2 Ingénierie, Orga Consultant, Infosud

ingénierie de Crédit Agricole, Valoris et HR Access…) permet au groupe de renforcer et d’élargir ses

services proposés (conseil et services informatiques, solutions bancaires et business intelligence…).

1.1.2. Activités et marchés

L’activité principale de Sopra est d’accompagner ses clients dans l’évolution de leur

organisation et de leurs systèmes d’information. Elle se compose de :

- Consulting (12% chiffre d’affaires)

- Intégration de Systèmes&Outsourcing applicatif (60% chiffre d’affaires)

- Solutions applicatives (13% chiffre d’affaires)

- Filiale Axway, leader mondial dans le domaine des Collaborative Business Solutions (15%

chiffre d’affaires)

La répartition de ces activités sur les marchés principaux (services financiers, services

transport et utilities, industrie, secteur public, télécoms & médias, distribution) selon leur chiffre

d’affaires est stable (voir schéma ci-dessous).

Fig – 1 La répartition de ces activités de Sopra Group


Page 10

1.1.3. Chiffres clés

Fig 2 - Les résultats financiers de Sopra des années 2010-2012

En 2012, le chiffre d’affaire réalisé par le groupe a été 1,217 milliards d’euros avec une

croissance organique de 2%. Il compte jusqu’aujourd’hui un effectif supérieur à 15 000

collaborateurs (1er trimestre 2013).

Malgré une situation difficile de l’économie européenne et mondiale, Sopra conserve encore

sa position et sa progression, ses résultats nets restent encore optimistes.

1.1.4. Implantation France et International

Fig 3 – L’implantation internationale de Sopra

Pour son implantation nationale, Sopra a construit une large couverture avec 25 sites en

France. Le groupe a aussi des implantations en Europe (Espagne, Royaume-Uni, Italie, Benelux,


Page 11

Suisse…). Au niveau international, Sopra a développé des centres de services dans les positions

stratégiques comme Inde, Maroc pour profiter les avantages de ces pays.

1.2. Division Midi Pyrénées

La division Midi-Pyrénées de Sopra a été créée en 1994. Aujourd’hui, la division compte plus

de 1000 collaborateurs travaillant sur 5 agences selon les projets sur différents secteurs :

l’aérospatiale, l’industrie / public / tertiaire, STIE (Scientifique Technique Industriel Embarqué) et le

business consulting.

Fig 4 – L’organisation de la division Sopra Midi Pyrénées

1.3. Le Bundle FBI

Le bundle FBI est un pôle de l’agence Aerospace 1, se situe au site Sopra Colomiers 1.

Le terme « Bundle » est utilisé par Airbus pour désigner un ensemble de projets d’un même

domaine. En réalité, les activités du Bundle FBI (Finance et Business Intelligence) ont été démarrées

en Avril 2011. Ce bundle fournit des services d’application aux projets du domaine Finance et BI

d’Airbus, pour un contrat de 3 ans et un budget de 5 millions d’euros.

Fig 5 – L’organisation du bundle FBI


Page 12

Le bundle est organisé en 4 domaines. Deux domaines opérationnels BI et BI-Finance

contiennent des équipes travaillant directement sur les projets d’Airbus. L’équipe du domaine d’AS

(Application Services) reçoit les projets finalisés par les domaines BI, BI-FI et s’occupe du support et

de la maintenance des applications. Enfin, une équipe du centre de compétences s’occupe des tâches

transversales : la validation des livrables avant de les transférer aux clients, l’étude sur la stratégie du

bundle, la sélection des benchmarks, des outils et le support du business dans la phase d’expression

des besoins (facilitateur).

Du côté opérationnel, le bundle contient des chefs de projets (PM), des facilitateurs (ISPL),

des seniors analystes (architectes), des juniors analystes (designers), des développeurs et des

testeurs.

Le projet où je travaille pendant mon stage est un projet du domaine BI-Finance. Ce projet

consiste à développer une application de reporting dans le système d’information financier d’Airbus.


Page 13

2. Synthèse des travaux

2.1. L’informatique décisionnelle dans le domaine financier d’Airbus

L’informatique décisionnelle (aussi connue par le terme Business Intelligence) est un

ensemble de méthodes, d’architectures, de technologies et d’applications qui consistent à récupérer

et transformer des données sources, les organiser en informations utiles afin de les présenter

clairement pour aider à la prise de décision. Autrement dit, l’informatique décisionnelle fournit à

l’entreprise des solutions de gestion des données volumineuses, variées, difficiles à gérer, sur

lesquelles l’entreprise peut déduire des décisions stratégiques efficaces. La BI permet aussi d’avoir

une vision globale sur les activités passées, actuelles et à venir ; elle aide aussi au processus d’analyse

des activités, de recherche de données… Ce domaine devient aujourd’hui source de la compétitivité

de l’entreprise.

La fonction finance est un des principaux enjeux de la compétitivité et la transformation de

l’entreprise. Aujourd’hui, en période de crise, la finance n’est plus qu’une fonction support mais un

élément majeur dans le pilotage et la stratégie de l’entreprise, comme disait le Baromètre Decideo,

«la Finance est le domaine le plus consommateur en applications décisionnelles» (Les tendances du

décisionnel en 2010). Bien évidemment, un système de comptabilité, de gestion de trésorerie

performante permet à l’entreprise d’augmenter sa capacité financière et de mieux déployer sa

stratégie choisie.

Ces raisons montrent que pour un grand business (leader de construction des avions) comme

Airbus le système d’information décisionnel financier est primordial pour répondre aux questions de

budgets, de coûts et de planifications financières. Le système BI permet à toute société de mieux

gérer son compte de résultats, faciliter la comptabilité en s’accordant aux exigences légales imposées

par les instances de régulation. Il permet aussi de mesurer la performance de l’entreprise, l’efficacité

de ses activités, la rentabilité de ses projets et préparer des actions en regardant des opportunités du

marché. Enfin, à partir de ces informations, il aide les décideurs d’Airbus à prendre des décisions

financières (investissement, endettement…) pour lesquelles on doit être très prudent dans cette

période de crise.

2.2. Projet One Report

2.2.1. Présentation du projet

2.2.1.1. Le projet ARP

Airbus, leader du monde de constructeur aéronautique, a un système d’information énorme

et très compliqué à gérer. Au début, chaque implantation principale de la société (France, Allemagne,

Royaume-Uni, Espagne) dispose son système ERP pour gérer tous ses processus d’achat, de

production, de ressources humaines, de relation clients… En conséquence, ces processus et des

règles de gestion de chaque système ne sont pas toujours communs et causent des difficultés dans

leurs interactions. C’est pourquoi le projet ARP (Airbus Ressources Planning) a été lancé dans le but


Page 14

d’harmoniser tous les différents systèmes SAP d’Airbus. Grâce à ce projet, tous les processus métiers

clés d’Airbus deviennent uniformes et les activités sont désormais gérées de façon unique et globale.

En 2006, les processus d’assemblage de l’A380 ont été les premiers harmonisés grâce à ARP.

En 2008, les deux sites de Toulouse et de Hambourg ont réussi à fonctionner ensemble et à livrer le

premier avion dont l’assemblage utilisait le seul système d’information ARP. Aujourd’hui, les autres

processus d’Airbus ont aussi migré au fur et à mesure vers ce système ARP.

Bien évidemment, le domaine de la finance est une partie importante de ce projet important.

Pour la migration des systèmes d’information financiers des quatre pays, Airbus a fait appel aux

différents SSII, où la partie BI de la finance a été confiée à Sopra, plus précisément au Bundle FBI.

C’est dans ce contexte que One Report a été mis en place.

2.2.1.2. One Report, le projet reporting financier d’ARP

One Report est un élément majeur dans l’ensemble du projet du domaine financier d’ARP, il

consiste à réaliser une application de reporting dans le système d’information financier d’ARP. Le

but de One Report, comme toutes les autres applications BI, est de fournir les informations

financières sur les stocks utiles sous forme des reportings aux décideurs. Les fonctions principales de

cette application sont séparées en 3 BSD où chacune est considérée comme une itération de

développement.

Le BSD1 « Gross Value & provisioning » se focalise sur le calcul de la dépréciation des

matériels.

Le BSD2 « Material stock per location » se focalise sur l’inventaire des stocks au niveau

des emplacements de stockage Airbus.

Le BSD3 « Material flow » se focalise sur les flux des matériels (l’analyse de la quantité, la

valeur et la raison des entrées-sorties de stock).

Fig 6 - Le processus de reporting One Report.


Page 15

Au premier jour ouvré de chaque mois, les données financières des systèmes SAP Finance et

Logistiques doivent être chargées dans le au système BI. A partir de ces données brutes, One Report

identifie la variance comptabilité (l’écart entre les valeurs finances FI et logistiques-finances MM-FI)

et calcule la provision de ces articles selon les différentes valeurs fiscales. Ce calcul doit être terminé

au plus tard le D+4 (4e jour ouvré du mois).

Ces données sont ensuite utilisées avec les valeurs venant des systèmes logistiques (SAP

MM) pour calculer la variance logistique (entre MM et MM-FI) des matériels et un report

d’inventaire de stock doit être produit au plus tard à 12h du D+4. Enfin, un report sur les flux des

articles permettent aux contrôleurs de gestion, des comptables une analyse détaillée sur les

mouvements de stock.

Fig 7 - Les différents systèmes SAP d’Airbus

Les données financières sont extraites depuis les systèmes SAP R/3 des pays (PDA pour

l’Allemagne, PGI pour la France, SPA pour l’Espagne, APD pour le Royaume-Uni et PEA pour le

système harmonisé ARP) vers le système SAP BW unique d’ARP PBA. Le planning a été défini de telle

manière à développer un premier lot qui ne gère que les données allemande. Ceci permettra de

valider la solution et d’ensuite la généraliser aux autres pays (system back end)... La migration sera

continuée avec ARP dans un second temps et terminera avec les 3 autres pays (PGI, SPA, APD).

2.2.1.3. L’organisation du projet

L’équipe de projet est composée par 2 sous-équipes : une équipe de front office en France de

4-5 personnes (donc 1 ou 2 architectes généraux, 2 consultants confirmés et moi-même) et une

équipe de back office en Inde (donc un responsable, 2 développeurs BW et 2 développeurs ABAP).

Une équipe testing indienne de 2 personnes intervient à la phase de test.

Le chef de projet Sopra gère et anime les deux équipes. Sur la partie MOA, des besoins

fonctionnels sont exprimés par le chef de produit. Un responsable de projet côté Airbus avec plus de

connaissances techniques s’occupe ensuite l’alignement des exigences sur les techniques de SAP BW


Page 16

et la validation des livrables. Entre l’équipe MOA et l’équipe MOE du projet, un facilitateur d’une

autre société (Akka) intervient pour l’explication des besoins et des règles fonctionnelles.

L’ISPL joue le rôle d’interface entre Airbus et l’équipe de projet, il participe à la phase

d’expression des besoins, assure le suivi de l’avancement du projet et reporte les problèmes au

responsable de projet. En général, pour garder une visibilité totale sur l’état du projet, l’ISPL et

l’équipe de projet ne doivent pas être de la même société.

Les activités de supports sont assurées par les équipes AS et FBICC de Sopra. L’AS intervient à

la phase de maintenance de l’application et le centre de compétence FBI participe à la validation des

livrables avant de les fournir aux clients.

L’organigramme de One Report est présenté sous forme du schéma ci-dessous.

Fig 8 - L’organigramme du projet One Report

2.2.2. Les méthodes de gestion de projet : GPP et e-Media

One Report, comme les autres projets du Bundle, est soumis à deux méthodes différentes de

pilotage de projet, une du client Airbus et une de Sopra.


Page 17

2.2.2.1. Airbus GPP Toolkits

Fig 9 – Le processus de GPP Toolkits

Airbus, pour le pilotage de ces projets, utilise GPP Toolkits. C’est un modèle générique,

adapté en fonction des caractéristiques spécifiques de chaque domaine, technologie, programme ou

projet. L’instruction de GPP introduit le cycle de vie, l’organisation et les règles s’appliquant aux

projets du système information.

Le cycle de vie de GPP a une forme qui se ressemble au cycle de vie en V, il se compose de

phases, de jalons et de portes de qualité.

Phase : 7 phases : chacune peut être divisée en sous-phases. Chaque phase doit

être accomplie dans l'ordre chronologique afin de s'assurer que ses principaux objectifs sont

atteints avant de passer à la suivante. Les 7 phases principales de GPP dans l’ordre

chronologique sont : Étude de l’opportunité (M1-M3), Conception (M3-M5), Définition de la

solution (M5-M7), Développement de la solution (M7-M9), Test d’acceptation (M9-M11),

Déploiement (M11-M13), Utilisation opérationnelle (M14). Sopra intervient au projet One

Report à partir de la phase M5-M7 jusqu’à la fin du cycle, où l’équipe de projet s’occupe de la

spécification, du développement, du test et de la mise en production. L’équipe AS

(Application Service) de Sopra s’occupe éventuellement de la phase de maintenance.

Jalons (Milestones) : 14 jalons pour marquer les points de contrôle importants : les jalons en

rouge (M3, M5, M11, M12) sont des étapes de GO / NO GO qui impliquent une décision du

comité de pilotage. Chaque jalon permet de faire une estimation sur l’état actuel du projet,

d’assurer que les décisions-clés relatives à l’avancement du projet sont effectuées, d’évaluer

si le projet est prêt à avancer à la prochaine phase, le non atteint des objectifs peut conduire

à retravailler sur la phase actuelle ou même à abandonner du projet. Il y a 11 jalons

principaux dont 4 GO / NO GO.

Étapes qualité (Quality Gates) : pour l'évaluation des livrables-clés. Ce processus est réalisé

en 2 étapes. La première étape est la mise en place de l’accord du processus pour

déterminer les fonctions des acteurs et les livrables impliqués, les critères d’acceptation et le

chemin restant. La 2e étape est l’évaluation des livrables en se basant sur les critères

d’acceptation. One Report débute par la réception de la BSD (Business Specification Dossier)


Page 18

d’Airbus contenant toutes les exigences et les règles fonctionnelles de l’application. Ensuite,

les documents de spécification et de test devront être livrés par l’équipe de projet Sopra. Ces

livrables font partie de mes travaux durant le stage.

Durant le stage en licence 3 chez Airbus, je travaillais dans le service de définition des

applications liées au système d’information. Cette occasion m’a permis de me familiariser avec cette

méthodologie. C’est pourquoi, au début, des notions et des termes utilisés par GPP Toolkits ne m’ont

pas posé des problèmes d’incompréhension durant les discussions et les réunions.

2.2.2.2. Sopra e-Media

Si les jalons et les phases principales du projet sont imposés par Airbus, Sopra applique aussi

sa propre méthode de pilotage de projet e-Media.

A la phase M5-M7, dès la réception du BSD d’Airbus, une phase d’initialisation est lancée au

côté de Sopra, où les acteurs de pilotage font un plan sur les tâches principales, l’équipe et le budget

du projet. Une équipe de projet Sopra est construite en composant d’un chef de projet, des

architectes générales, des designers, des développeurs et des testeurs. Ensuite, des documents

d’initialisation doivent être produits (plan de management et plan de développement). Sopra doit

fournir aussi le chiffrage et la planification du projet au client. Une fois tous ces documents validés

par le client, la réalisation du projet est lancée.

E-Media définit aussi 4 niveaux de réunions : la V1, V2, V3 et V4 (V pour visibilité). La V1 est

une réunion hebdomadaire faite au sein de l’équipe de projet pour communiquer l’avancement des

tâches. La V2, au niveau supérieur, est planifiée chaque mois entre les chefs de projets et le manager

du domaine pour avoir une vision globale sur l’état de l’ensemble des projets. Les réunions de type

V3 et V4 interviennent rarement au déroulement d’un projet. Les V3 sont les réunions annuelles ou

biannuelles pour la planification financière et les V4 identifient la stratégie globale à long terme

(plusieurs années).

Le chef de projet doit organiser et animer les V1, il rédige aussi un compte-rendu de la

réunion et le fait diffuser à l’équipe. Pour One Report, chaque semaine, la V1 de l’équipe front office

est planifiée mardi après-midi. Une réunion de ce type est aussi faite avec l’équipe indienne par

conférence téléphonique. Dans la période où One Report recevait des alertes de retard, la V1 avec

les développeurs offshore a été passée en mode journalier pour augmenter un niveau de suivi.

A côté des réunions officielles, les petites réunions et discussions informelles sont souvent

faites entre les membres de l’équipe pour clarifier un problème ou faire un point sur les tâches à

faire.


Page 19

2.2.3. L’environnement technique

2.2.3.1. Le système d’information décisionnelle d’Airbus

Le rôle principal du décisionnel est de mettre à la disposition des utilisateurs des données

bien structurées afin de faciliter la prise de décision. Un système BI se distingue des systèmes

opérationnels (comme dans le cas d‘ARP, on distingue le système BW PBA et le système R/3 PEA). Le

décisionnel se base sur un moteur OLAP (analytique) plutôt qu’un moteur OLTP (transactionnel). Il

permet de transformer les données brutes en informations utiles. Un flux de données décisionnelles

est :

- L’extraction des données opérationnelles des systèmes de production.

- Le stockage des données transactionnelles dans l’entrepôt de données (dans le système

BW Airbus, cette couche est appelée Integrated Layer). Ces données sont ensuite

transformées en tenant compte des règles de gestions métiers et transportées aux

magasins de données (Datamart layer).

- La restitution des données décisionnelles des magasins de données et la présentation de

ces informations sous forme des requêtes de reporting. Ces reports vont servir à

l’analyse et la prise de décision des utilisateurs finaux.

Fig 10 - Le processus de l’informatique décisionnelle

Pour mieux gérer son système BI, Airbus impose ses propres règles d’administration rédigées

dans le document « Norm&Method ». Les objets de la couche X (Integrated Layer) sont utilisés par

l’ensemble des projets. Les données dans cette couche sont extraites directement à partir des

systèmes opérationnels, sans aucune transformation spécifique. Ces données sont gérées par

l’équipe de centre de compétences BW (BICC. Par contre, dans la couche H (Datamart Layer), sachant

que les vues métiers sont différentes suivant les domaines chaque projet dispose de ses propres


Page 20

objets et ne peut utiliser que les siens. Cette règle permet d’éviter les problèmes d’inter-blocage

entre les différents projets en utilisant les mêmes objets

Les données décisionnelles utilisées dans la BI sont classifiées en 2 types : des données de

bases et des données transactionnelles. Les données de base, appelées par les Master Data, sont les

informations stables et inchangées pendant une longue durée (le code de fournisseur, de matériel…)

et elles sont utilisées par tous les processus. Les données transactionnelles sont spécifiques au

processus, elles permettent de relier les données de base (par exemple une commande est

composée d’un fournisseur et d’un matériel).

2.2.3.2. La solution BI de SAP

SAP propose un ensemble de solution permettant de construire un système BI. Un flux de

données de BW contient tous les étapes de l’extraction des données brutes jusqu’à la présentation

des informations dans les reports.

Les objets stockage de BW sont de 2 types : des info-objects et des info-providers. Les info-

objects sont les plus petites unités d’information de BW, ils peuvent être des caractéristiques, des

ratios, des unités, des caractéristiques de temps ou des caractéristiques techniques. Ces info-objects

sont contenus dans différents types d’info-provider selon leur utilisation : DSO (Data Store Object)

pour stocker les données transactionnelles, Master Data pour les dimensions d’analyse données de

base, InfoCube pour les données transactionnelles dans les reports.

Fig 11 - Les flux de données SAP BW


Page 21

Les données des systèmes de production R/3 ou des fichiers plats sont extraites vers les data

sources du système BW par des infopackages ou des modules fonctionnels (développé en ABAP).

Dans le système BW, ces données sont stockées dans les DSO (pour les données

transactionnelles) et des Master Data (pour les données de base). L’alimentation des données entre

les objets est assurée par les transformations et les DTP (Data Transport Package). Les cubes de

données sont créés dans la couche de Datamart sous forme des InfoCubes. En général, toutes les

règles de gestion sont déjà intégrées au niveau des cubes, car c’est principalement les informations

dans les InfoCubes qui sont utilisées dans les reports.

Enfin, SAP BW dispose des outils de développement des reports : Query Designer pour les

reports Excel, Report Designer pour les reports en PDF et Web Application Designer pour les reports

en Web Template.

One Report, comme tous les autres projets BI Airbus, travaille sur 4 environnements

différents selon les différentes phases. Le transport des objets entre les environnements est assuré

par les Ordres de transport (OT) de SAP.

Fig 12 - Les environnements d’ARP BW

L’environnement de développement (EBA) : destiné à la phase de développement. C’est le

seul environnement où les créations, modifications et suppressions manuelles des objets

BW (DSO, Cube, Master Data…) sont autorisées. Les objets dans cet environnement ne

contiennent pas forcément des données. Une fois finis, les objets sont passés les

environnements d’intégration.

L’environnement de test d’intégration (TBA) : destiné aux tests d’intégration de l’équipe de

projet. Dans TBA, il est important que cet environnement contienne des données

significatives afin de pouvoir effectuer tous les cas de test.

L’environnement de qualification (QBA) : destiné aux recettes (test d’utilisateurs). Les

données de test en QBA doivent être une copie des données de production. A la fin de la

phase de validation, les objets sont transportés en PBA pour la mise en production.

L’environnement de production (PBA) : destiné au déploiement de l’application. Déjà

développés et testés, l’application y est utilisée par les utilisateurs finaux.


Page 22

2.2.3.3. La validation de l’application avec HPQC

HP Quality Center (HPQC) est le leader logiciel dans la gestion de qualité informatique. Dans

One Report, HPQC est utilisé sous forme d’un SaaS (software as a service – c’est-à-dire une

application client légère déployée via un navigateur d’Internet) dans la phase de test pour rédiger

des scénarios, des cas de test et gérer les anomalies de l’application testée.

Ce logiciel permet aussi de vérifier la traçabilité entre les exigences de l’application et les cas

de test afin d’assurer une couverture totale des cas de test sur l’ensemble des cas d’utilisation. Avec

l’historisation des résultats de test, les testeurs peuvent suivre tout le cycle de vie d’une anomalie

détectée durant ces tests afin de décider des actions correctives nécessaires. Enfin, travaillant sur un

système de qualification unique, l’équipe de projet peut avoir une vision commune sur l’état des

tests et mieux communiquer des problèmes.

La participation à la phase de vérification et de validation des applications dans le cadre de

mon dernier stage chez Airbus m’a été utile et a faciliter l’utilisation de ce logiciel sur les activités de

test de One Report.

2.2.4. Les travaux réalisés

Durant le stage, j’ai eu l’occasion de participer à toutes les phases du projet dans le contexte

industriel, depuis la réception du cahier des charges (le BSD) jusqu’au test utilisateurs. Pourtant, mon

intervention n’a pas suivi l’ordre classique des phases d’un projet. Au moment où je suis arrivé au

projet (Décembre 2012), la phase de spécification de l’itération 1 a été finalisée et le développement

était en train d’être réalisé par l’équipe indienne. C’est pourquoi mes premières tâches étaient des

tests de validation des objets livrées par les équipes offshore en Inde. En réalité, suite aux différentes

difficultés, cette phase a dû prendre plus de temps que prévu. Elle m’a permis de monter en

compétences sur les techniques de SAP BW et ABAP. Dans un second temps, dès le lancement de la

deuxième itération, j’ai travaillé sur la spécification et le développement des objets BW. Ce travail a

consistée à spécifier les objets BW, les règles de calcul et à développer des chaines de processus des

données (process chain).

Mes travaux réalisés sont détaillés dans les parties suivantes.

2.2.4.1. Validation

2.2.4.1.1. Test d’intégration

La phase de test d’intégration a été lancée après le développement. En réalité, pour mieux

comprendre les règles spécifiées de One Report, j’ai commencé par la rédaction des scénarios de

test. Les scénario sont écrits en se basant sur la matrice de compliance élément capital du projet qui

permet de valider que tous les besoins sont couverts et tester. Les cas de test d’intégration sont

basés sur les objets BW (un cas de test par DSO, Cube ou Report créé) et la couverture des objets BW

sur l’ensemble des exigences est précisée dans la matrice de compliance produite par les analystes

durant la spécification.


Page 23

J’ai commencé par le test de certain objet de la fonctionnalité dépréciation de One Report

(cf. figure 6), notamment le DSO HFIAX801 (cf. Annexe Architecture technique détaillée) contenant

les données sur les valeurs brutes et les quantités MM-FI des matériels agrégées par centre de profit

et par évaluation harmonisée. C’est un des 3 DSO de base de One Report (HFIAX801, HFIAX802 et

HFIAX803) contenant plus de 30 règles de calcul, d’extraction et de transformation. Puisque tous les

reports et les autres objets de la couche Datamart de l’itération 1 doivent se baser sur son contenu,

le test de HFIAX801 est important et primordial.

Les cas de test sont rédigés dans le test plan de HPQC. Un cas de test est composé de

plusieurs étapes. Pour chaque étape, j’ai défini la description des actions de test et le résultat

attendu. Dans le cas de HFIAX801, il s’agit de saisir les données en entrée et de vérifier si les données

existent dans ce DSO et correspondent bien aux règles de calcul. Le calcul de ces résultats attendus

doit être fait par moi-même à partir des données sources. Cette tâche a nécessité que je travaille

avec les analystes du projet de manière à ce qu’ils m’expliquent les règles fonctionnelles. Ce travail

préliminaire est absolument nécessaire pour assurer une qualité des cas de tests.

Fig 13 - Un scénario de test rédigé sur HPQC

Les tests sont ensuite réalisés sur le test lab de HPQC. Pour chaque cas de test, le réalisateur

doit suivre la description de chaque étape et vérifie la cohérence entre les résultats attendus et les

résultats réels. Dans le cas de problèmes, des anomalies sont créées avec une description attachée.

Dans One Report, des copies d’écran de test sont obligatoires afin d’assurer la traçabilité vis à vis du

client, des tests réalisés mais aussi pour permettre au développeur de mieux comprendre l’anomalie.


Page 24

Fig 14 - La réalisation d’un test sur HPQC

Durant le test, la difficulté majeure que j’ai rencontrée était le manque des données de test

parce que tous les objets n’ont pas été chargés et les données n’ont pas été fournies par le business.

De ce fait je n’ai pas pu réaliser l’intégralité du périmètre de mes tests. Plusieurs solutions sont

possibles dans le cas de manque de données :

1 – Création manuelle de données. Ceci n’est pas possible dans l’environnement de test à ma

disposition du fait de la définition des droits dans cet environnement.

2- Vérification partielle en faisant une relecture de code. Bien évidemment, cette façon de

tester ne peut pas assurer une qualité du développement mais elle permet de réduire les risques.

2.2.4.1.2. Gestion des anomalies

Lors de mon retour à l’entreprise, suite aux 2 semaines de cours à l’université, presque tous

les tests avaient été réalisés. J’ai alors été chargé de la gestion des anomalies.

Une anomalie est créée durant le test lorsque le résultat ne correspond pas au scénario

prévu. Pour une anomalie, il faut définir son type (défaut, amélioration, observation, question), sa

classification (fonctionnelle ou technique), son niveau d’impact (bloquant, majeur, mineur), sa

reproductibilité, sa description et communiquer ensuite l’anomalie au correcteur correspondant (par

mail et par fichier de communication). Une fois créée, l’anomalie est enregistrée dans le centre des

défauts de HPQC avec un statut « New ».

La réception de l’anomalie est confirmée par le passage en état « Open » par le Chef de

projet qui valide toutes les anomalies. Les actions analytiques et correctives sont ensuite mises en

place pour détecter la cause du problème et sa solution (soit la modification de la spécification, soit

la correction du code, soit la remise en question les règles fonctionnelles). Après avoir résolu le


Page 25

problème, le correcteur passe l’anomalie en statut « Fixed ». Cette anomalie doit être re-testée et

clôturée par le détecteur.

Fig 15 – Le suivi d’une anomalie sur HPQC

Quand je suis rentré de l’université, dans HPQC, le nombre d’anomalies était plus de 70 et la

plupart entre elles n’ont pas été clôturées. Dans un premier temps, j’ai pris le temps pour analyser

tout l’ensemble de ces anomalies et définir la priorité de chacune selon la sévérité, la date de

création… J’ai commencé par les problèmes bloquants, puis les majeurs et les mineurs. Pour une

anomalie technique, il me fallait vérifier si elle était bien corrigée sur l’environnement de

développement (EBA) et transportée à l’environnement de test (TBA). Ensuite je devais relancer le

cas de test correspondant sur TBA et vérifier si le problème se reproduisait ou non. Il fallait aussi que

je m’assure de la correcte modification des spécifications dans le cas d’un bug fonctionnel. Cette

modification doit ensuite être développée par les équipes offshore. Je devais alors valider que le

développement était correcte. Si le problème a été bien réglé, je le clôturais et communiquais au

correcteur. Bien évidemment il y avait certains défauts que je n’étais pas capable de re-tester et

clôturer à cause du manque de connaissances (surtout des défauts remontés par le BICC). Dans ce

cas, il m’a fallu adresser au détecteur de l’anomalie pour demander son avis. Enfin, la gestion de ces

anomalies m’a permis d’avoir une vision globale sur les objets One Report, de mieux appréhender les

normes et les exigences de développement d’une application.


Page 26

2.2.4.2. Spécification

2.2.4.2.1. Spécification générale

Fig 16 - Le schéma étoile général One Report

Une fois la phase de test terminée, la deuxième itération a commencée par une phase de

spécification. Cette phase est basée sur le BSD (Business solution dossier) qui nous sert de cahier des

charges. Ce document contient l’explication des fonctionnalités de l’application One Report, des

règles de gestion du domaine financier d’Airbus, un dictionnaire des données utilisées et une liste

des exigences obligatoires et optionnelles précisées par le client. Airbus a aussi fourni à l’équipe

Sopra un schéma étoile des données afin de préciser les données principales à remonter.

Une première version de l’architecture de l’application décrite dans un ARD (Application

Architecte Overview) a été aussi étudiée par l’ISPL chez Akka (SSII concurrent de Sopra). Il s’agit d’un

document décrivant l’architecture générale de tous les flux de données (depuis les datasources

jusqu’aux infocubes) développés dans l’application. A partir du cahier des charges et l’ARD initiale,

dans un premier temps, l’équipe front office One Report travaillait sur l’architecture générale de

l’application, afin de compléter cet ARD. (cf. annexe)

Une liste des objets (Master Data, DSO, Cube…) utilisant cet ARD devait être définie, ces

objets peuvent être existants (fournis par le BICC) ou nouveaux (créés par l’équipe). En général,

chaque dimension du cube dans le schéma de l’étoile est associée à un DSO ou un Master Data. Les

données sources sont extraites depuis les systèmes SAP R/3 par les datasources et sont stockées

dans l’entrepôt de données (couche X). Ces données sont quasiment brutes car il y a rarement des


Page 27

transformations au cours de l’extraction. Elles sont ensuite montées au magasin de données (couche

H) où les règles de calcul et de transformation sont mises en place.

Selon la norme d’Airbus, tous les objets de la couche H doivent être propres au projet One

Report et créés par nous-mêmes. Pour les objets de la couche, toutes les modifications ou créations

doivent être validées par le centre de compétences BI Airbus. Une fois mise à la disposition à une

équipe de projet, l’objet de la couche X ne peut pas être travaillé par un autre projet tout au long du

projet affecté.

Ensuite, nous devions aussi préciser dans l’ARD le mode de chargement (full, delta), la

fréquence (mensuel, journalier ou à demande) et l’ordre de chargement des objets. Ces informations

serviront à la spécification des chaines de processus de données (process chains).

Je me suis occupé de compléter l’ARD de tous les pays. En se basant sur les flux de données

de l’Allemagne spécifiés dans la première itération, j’ai ajouté d’autres flux similaires de la France, de

l’Espagne et du Royaume-Uni en tenant compte des règles spécifiques de chaque pays.

Fig 17 – Les flux de données One Report Provision d’Allemagne (à gauche) et des autres pays(à droite)

(Extrait de l’ARD One Report)

Cette phase s’est terminée par la définition des règles de spécification générale. Pour ce

faire, un AGD (Application General Dossier) a été créé. Ce document est une version détaillée de

l’ARD en précisant toutes les règles de spécification correspondant à chaque flux de données (les

champs à remonter, les filtres, les transformations générales…). Nous devions aussi défini dans l’AGD

les environnements du système (les systèmes sources et cibles de l’application), tous les objets

utilisés par l’application, une description détaillée des flux de données, des variables globales, des

impacts sur les autres projets interdépendants…


Page 28

Fig 18 - Le schéma étoile mis dans l’AGD

Une matrice de couverture a été étudiée en parallèle pour assurer la cohérence entre ces

règles et les exigences du client. Chaque objet BW (DSO, module fonction, programme, report ou

chaine de chargement) créé doit répondre à au moins une exigence et toutes les exigences de type

obligatoire présentées dans le cahier des charges doivent être associées à une règle de spécification.

Les derniers documents à produire durant cette phase sont des SD (spécification dossier).

C’est une version officielle de la matrice de couverture. Je me suis chargé de mettre à jour cette

matrice en ajoutant les règles de spécifications de l’itération 2 et rédiger les SD correspondants. Pour

cette tâche, j’ai dû analyser le BSD et l’AGD pour comprendre des exigences et des règles de

spécification. Finalement, avec l’aide de l’ISPL et de l’équipe One Report, j’ai pu compléter la matrice

et livrer les SD aux clients.

La spécification générale permet d’avoir une vision globale sur l’application. Elle nous a aussi

permis d’identifier les points d’incompréhension et de les discuter au cours des workshops organisés

avec le business et le responsable de projet. A la fin de cette phase, un prototype de la solution finale

a été montré et validé par le client afin d’éviter des changements de spécification majeurs dans les

phases suivantes.

2.2.4.2.2. Spécification détaillée

Après avoir défini une solution générale, la spécification détaillée est commencée et elle sera

destinée aux développeurs. C’est pourquoi, dans cette phase, les règles sont spécifiées de façon plus

détaillées et les aspects techniques SAP BW sont ajoutés.


Page 29

L’extraction et la restitution des données

La partie importante de la BI est l’extraction et la restitution des données en tenant compte

les règles de gestion pour obtenir des informations décisionnelles utiles. Le document spécifique à

cette partie est le Dataflow. Selon mon observation, le Dataflow est le document central du projet,

qui contient presque toutes les spécifications principales d’un objet de l’application. C’est aussi la

partie de la spécification où l’équipe de projet devait passer plus de temps.

Fig 19 - Le dataflow du DSO HFIAX801

Chaque objet BW (DSO, Master Data, Cube) est associé à un seul Dataflow. Ce dossier

spécifie tous les flux de données alimentant l’objet en sujet. Pour chaque flux, nous identifiions les

champs sources à remonter et les champs correspondants dans l’objet cible ainsi que l’objet source,

le système source et le format du champ (chaine de caractères, unité, nombre entier, date…). Il nous

a été demandé aussi d’intégrer la partie de l’ARD concernant cet objet dans ce document.

Entre les données sources et les données cibles, les règles de transformation devaient aussi

être définies. Les règles sont catégorisées en différents types soit une jointure, un module fonction,

une extraction, une transformation ou une routine (l’ensemble de règles consécutives). Une règle

doit être expliquée fonctionnellement, c’est-à-dire qu’il nous fallait éviter d’utiliser directement le

code afin de faciliter la validation du client.

L’exemple d’une règle que je peux citer est la restitution de la quantité du stock dans une

location à partir du DSO « Mouvement de stock ». Ce champ est contenu dans le DSO HFIAX802 qui

servira à faire l’inventaire de stock.

Pour chaque mouvement de stock, il faut déterminer s’il s’agit d'une entrée ou d'une

sortie en se basant sur la clé spécifiée par SAP BW.

o Si la clé est 100, 101, 104, 105, 106, 110 et le composant est ‘MM’ (module SAP

matériel management) alors il s’agit d’une sortie de stock.

o Sinon si la compagnie est Airbus France, la clé est 412, le type du matériel est ‘CMSE’

alors il s’agit d’une sortie de stock (cette règle est spécifiée pour le système France).


Page 30

o Sinon si la clé est 000, 001, 004, 005, 006, 010 et le composant est ‘MM’ (module SAP

matériel management) alors il s’agit d'une entrée de stock.

S'il s’agit d’une entrée de stock, alors stock actuel = stock actuel + quantité entrée. Dans

l’autre cas, stock actuel = stock actuel – quantité sortie.

Pour les règles plus compliquées, nous spécifiions dans une SAP Analysis à part et

mentionnée dans le Dataflow correspondant. Elle sert à spécifier toutes les règles ou les fonctions

complexes qui ne peuvent pas être détaillées dans le Dataflow sous forme d’un algorithme de

langage pseudo-code. La SAP Analysis, contrairement aux autres livrables, n’est pas imposée par un

template particulier. C’est pourquoi pour certains projets, un seul SAP Analysis a été produit. Dans

One Report, nous avons décidé de produire un SAP Analysis pour chaque objet ou chaque module

fonction.

Voici l’extrait de la SAP Analysis de la fonction ZFI_GET_LOCAL_UNIT écrite par moi-même. Il

s’agit d’une fonction restituant l’unité de mesure d’un matériel du système source local étant donné

l’unité harmonisée dans le système ARP, le numéro identifiant du matériel, le système source et le

pays du système local.

L’algorithme de cette fonction :

Les paramètres d’entrée :

- Le système source (ARP, Allemagne, France, Royaume-Uni, Espagne)

- L’unité harmonisée (utilisée dans le système ARP)

- Le numéro du matériel

- Le pays local. (France, Royaume-Uni, Allemagne, Espagne)

Le paramètre de sortie :

- L’unité locale (utilisée dans le système local).

1. Chercher dans le DSO XPPT0061 (contenant des unités de mesure) pour récupérer les

systèmes source, les unités locales et les harmonisées correspondantes.

2. Calculer l’unité du système local :

Regarder si les unités locales correspondent à l’unité harmonisée en entrée.

o Si une seule unité locale correspond à l’unité harmonisée, le résultat est cette unité

locale.

o Si plusieurs unités locales correspondent à l’unité harmonisée, il faut regarder dans

la Master Data XMATERIAL et vérifier le système source en entrée.

Si ce système source n’est pas ARP (donc FR, GE, UK, ES), il est suffisant de

récupérer l’unité locale correspondante au système source et au numéro

matériel en entrée. Cette unité est le résultat du calcul.


Page 31

Si ce système source est ARP, il faut récupérer l’unité locale ayant le système

source local correspondant au pays entré. Cette unité est le résultat du

calcul.

L’extrait de la SAP Analysis de cette fonction.

Description :

Input

Source system: I_XSOURSYST TYPE: XSOURSYST

Unit of measurement ARP I_XUNTRF TYPE: XBASE_UOM

Material number I_XMATERIAL TYPE: XMATERIAL

Country INPUT I_HCOUNTRY TYPE: HCOUNTRY

Output

Local unit measure O_BASE_UOM TYPE: XBASE_UOM

Treatment :

Read XPPT0061 in order to retrieve XSOURSYST, XBASE_UOM, XUNTRF.

Data will be put into the internal table T01.

/*Management of duplicate rows

Move all of duplicate rows to another internal table (T02, those rows are deleted

from T01.

/*Calcul of Local unit of measure*/

Read the table T02

With key Source system = I_XSOURSYST

Base unit of measure ARP = I_XUNTRF

If found

/*Input unit of measure ARP corresponds to many local unit of measure

Check I_XSOURSYST:

If I_XSOURSYST = ‘XEA’,

/*Input material is harmonized

Check the I_HCOUNTRY:

If I_HCOUNTRY = ‘FR’ then LW_SOURSYST = ‘XGI’

If I_HCOUNTRY = ‘DE’ then LW_SOURSYST = ‘XDA’

If I_HCOUNTRY = ‘GB’ then LW_SOURSYST = ‘APD’

If I_HCOUNTRY = ‘ES’ then LW_SOURSYST = ‘SPA’

Look up into XMATERIAL in order to get Base unit of measure

(BASE_UOM), selection fields:

XHM_NB = I_XSOURSYST

XSOURSYST = LW_SOURSYST

O_BASE_UOM = BASE_UOM

Else

/*Input material is local

Look up into XMATERIAL in order to get Base unit of measure

(BASE_UOM), selection fields: XMATERIAL = I_XMATERIAL

XSOURSYST = I_XSOURSYST

O_BASE_UOM = BASE_UOM

End if.

If no data found then raise exception NO_DATA_FOUND

Else

/*Input unit of measure ARP corresponds to only 1 local unit of measure

Read the table T01 (which contains no duplicate rows from XPPT0061) in

order to retrieve base unit of measurement Natco (XBASE_UOM),

With key

XSOURSYST = I_XSOURSYST


Page 32

XUNTRF = I_XUNTRF

O_BASE_UOM = XBASE_UOM

End if.

Le chargement des données

Une fois la structure des objets avec toutes les règles de calcul et de restitution bien

spécifiées, il reste à définir des process chains qui permettront le lancement de l’application en

production suivant une schedule précis... Selon les exigences exprimées par le client, au premier jour

de chaque mois, les données financières et logistiques des systèmes de production doivent être

remontées dans le système décisionnel. Au 4e jour du mois, toutes les données doivent être

calculées et chargées dans tous les objets et l’utilisateur peut lancer les requêtes de reporting sur ces

informations. Pour ce faire, SAP BW met en place des chaines de processus automatisées. Il s’agit

d’une suite d’opérations « simples » (chargement ou déchargement d’un objet, l’activation des

données, lancement d’un programme, appel d’une fonction…) liées les unes aux autres par les liens

logiques (si succès, si échec, ET, OU…) ou les étapes de décision. Elle est généralement utilisée pour

les actions sans intervention humaine (chargements nocturnes…) ou de sauvegarder mes actions

exécutées manuellement souvent répétées.

Tous les process chains sont spécifiés dans un document DLS unique (Data Loading

Sequency). Pour chaque process chain, nous avons défini la condition de démarrage, l’objet chargé

ou éventuellement les sous-chaînes. Il est interdit de lancer deux chargements sur un même objet.

De plus, les chargements sont interdépendants entre eux (par exemple, pour charger un champ de

l’objet A, il faut aller consulter les données dans les objets B et C, donc il est obligatoire que ces

objets aient été chargés). Pour ces raisons, il nous fallait définir des événements afin de faire

communiquer les process chains. Une process chain, avant de charger un objet ou d’aller consulter

un autre objet, doit vérifier dans la liste des événements pour savoir si le chargement de l’objet en

question a été fini ou non. Si oui, cette process chain est interrompue jusqu’à ce qu’elle reçoive un

événement marquant la fin du chargement bloquant.

Fig 20 – Le Data Loading Sequency One Report


Page 33

La présentation des données sous forme des reports

Lorsque toutes les données sont transformées en informations décisionnelles dans le

système BI, nous avons décrit la présentation des données sous forme des reports.

SAP BW fournit trois formats pour les reports : Excel, PDF et en Web. Dans ce cadre de One

Report, seuls les reports en Excel sont demandés. Le contenu des reports (les données représentées)

est précisé dans le BRD. La spécification d’un report est réalisée à l’aide du Data Access. Dans ce Data

Access, nous devions indiquer les caractéristiques et leurs types (fixés ou libres – les attributs non

affichés par défaut mais peuvent être ajoutés dans le tableau reporting par la fonction drill-down),

les ratios, les autorisations (par exemple des comptables françaises ne peuvent que consulter les

données du système d’Airbus France) et les critères de sélection des données. Au niveau des Data

Access, les règles de restitution sont rarement définies. En fait, nous n’avons précisé que les petits

calculs des ratios ainsi que des règles spécifiques de présentation (couleur, graphique…). Un exemple

du report doit être joint à la fin du Data Access pour assurer une bonne compréhension des

développeurs.

2.2.4.3. Développement

Les tâches de développement sont généralement réalisées par l’équipe Sopra India.

Pourtant, dans le but de participer à tous les phases du projet, le développement des process chains

m’a été confié.

Le développement des process chains sur SAP BW utilise une interface graphique simple et

efficace. Je me suis chargé de développer les process chains de chargement des objets de couche X

et quelques objets de la couche H. Dans la couche X les objets utilisés par One Report peuvent être

existants ou créés par l’équipe de projet. Pour cela, il m’a fallu créer des process chains de

chargement des nouveaux objets et modifier les process chains existants.

Voici un exemple sur un process chaine typique que j’ai développé : le chargement du Cube

HFIAX80C7.

Les étapes de cette process chaine sont :

1. Démarrer de la chaine.

2. Attendre des événements XFI_E067 (fin de chargement de XFICTRL1), HFI_E020 (fin

de chargement de HFIAX801), XFIMBEW1_DE (fin de chargement de XFIMBEW1)

3. Étape de décision :

a. Si la date du jour est le 3e jour du mois, continuer la process chain

b. Sinon, si l’heure actuelle est >23h50 ou <14h, continuer la process chain

c. Sinon, attendre jusqu’à 23h50 pour continuer la process chain (dans ce cas,

j’ai développé un programme bloquant la chaine jusqu’à 23h50).

4. Supprimer les indexes du cube HFIAX80C7

5. Lancer le DTP de chargement du cube HFIAX80C7

6. Recréer l’index du cube HFIAX80C7


Page 34

7. Calculer les statistiques de données du cube (pour les raisons de performance).

Cette chaine a été développée et testée unitairement sur EBA par moi-même. Elle est ensuite

transportée et testée sur TBA par l’équipe testing.

Fig 21 - La process chain de chargement du cube HFIAX80C7


Page 35

2.2.4.4. Livrables

En plus des documents techniques, Airbus impose aussi la livraison d’autres documents. Ces

documents ne sont pas destinés aux développeurs, ils contiennent des informations nécessaires pour

préparer la mise en production de l’application.

Le RAD (Roles&Authorizations Dosser) définit des rôles pour les développeurs, les testeurs et

les utilisateurs de l’application. Pour chaque acteur, une liste des activités autorisées est définie

(manager les objets, lancer les requêtes…). Dans One Report, 4 groupes d’utilisateurs sont définis :

Data admin : autorisation de toutes les actions sur les objets de données BW (DSO, Cube…).

Query designer : autorisation de toutes les actions sur tous les reports One Report.

Delegated admin : autorisation de l’attribution des rôles aux utilisateurs One Report.

End user : autorisation de lancement des reports.

Ce document est destiné aux SAP Rights (le service de gestion des rôles des systèmes SAP

Airbus). En effet ce n’est pas le projet qui crée directement les rôles associé. Toute la gestion des

rôles est centralisée selon les exigences d’Airbus).

Le Data Sizing est un document contenant toutes les informations techniques de tous les

objets de l’application. Ce document est nécessaire pour mesurer le volume des données et la

performance de One Report. Dans le Data Sizing, l’équipe de projet doit préciser pour chaque objet

le nombre de données chargées, la fréquence de chargement de données, la taille et le

partitionnement des objets. Grâce à ce document, nous pouvons estimer le volume de données du

projet et assurer une bonne intégration dans le plan de production.

Le MIV/MIP (mise en validation et mise en production) est un document contenant la

description et le détail de tous les ordres de transport de l’application sur le système SAP R/3 et SAP

BW. Comme l’application sera transportée vers l’environnement de production PBA durant la phase

de déploiement, ce document doit définir le planning et le scénario des processus de transport ainsi

que les codes de retours et les ordres de corrections.

Ces documents sont uniques pour toutes les itérations et ne seront livrés qu’à la dernière

itération pour la mise en production de One Report. Comme One Report n’est pas encore passé à la

production, ils ne sont pas finalisés pour le moment.

Les seuls livrables non produits pas l’équipe front-office sont les dossiers de test. Bien

évidemment, ils sont rédigés par l’équipe testing.

Voici un bilan sur les livrables du projet One Report selon chaque phase :

Spécification (M5-M7) :

ARD : Validé par ISPL, BICC (couche X), IMSB (responsable de production Airbus)

AGD : Validé par ISPL, BICC (couche X)


Page 36

Dataflows : Validé par ISPL

Data Sizing (init) : Validé par ISPL, IMSI (administrateur système Airbus)

Data Access : Validé par ISPL, IMSB

RAD (init) : Validé par ISPL, SAP Rights

Développement (M7-M9) :

Dataflows (mise à jour) : Validé par ISPL, BICC (couche X)

MIV : Validé par IMSI (couche X)

DLS (init) : Validé par IMSB

Intégration (M9-M10)

DLS : Validé par ISPL, IMSB

Dataflows (mise à jour) : Validé par BICC (couche X)

RAD : Validé par SAP Rights

Validation (M10-M11)

MIV : Validé par IMSI

MIP : Validé par IMSI

Data Sizing (finalisé) : Validé par IMSI

Test dossier : Validé par IMSB

DLS (finalisé) : Validé par IMSB

Production (M11-M15)

Tous les documents : Validés par ISPL

Back up procedure : Validé par IMSB

Incident report : Validé par IMSB

Knowledge transfer : Validé par IMSB


Page 37

3. Sujet de réflexion : L’offshoring d’un projet informatique

3.1.1. Introduction

3.1.2. Choix du sujet

L’offshoring, le nearshoring, l’onshoring… Nous entendons parler de ces termes chaque jour

comme une des stratégies incontournables des SSII françaises et internationales. Chaque année, des

centres de services sont ouverts aux quatre coins du monde : Malaisie, Vietnam, République

Tchèque, Maroc… Ces tendances de délocalisation des ressources sont aussi la source de nombreux

débats, sur leurs bénéfices et leurs impacts sur le plan macroéconomique. Malgré tout, cette

stratégie ne semble jamais démodée pour les entreprises voulant trouver une solution pour

augmenter l’efficacité de leur production. Même si ce n’est pas toujours le cas…

Durant mon stage, j’ai eu l’occasion de participer à un projet offshoring, One Report, qui est

composé de 2 équipes, une équipe front office en France, une back office en Inde. Étant à la fois

observateur et acteur de ce projet, j’ai décidé de choisir l’offshoring comme sujet de réflexion. Dans

un premier temps, je vais vous parler de l’offshoring, sa définition, ses enjeux et la situation actuelle

des entreprises dans ce phénomène... Ensuite, je vais présenter le point de vue de Sopra Group, un

des acteurs majeurs déployant cette stratégie, sa méthode de mise en œuvre ainsi que les

expériences que j’ai pu retenir du projet offshore One Report. Je terminerai par une analyse globale

de l’application des méthodes agiles dans un contexte d’offshoring, une des solutions récentes pour

réduire les risques autour de la délocalisation des projets informatiques.

3.1.3. Définition

L’offshoring désigne la délocalisation des activités de service ou de production de certaines

entreprises vers des pays à bas salaire. Il se compose de 2 catégories différentes : l’offshoring

informatique, et l’offshoring des business process (les processus métiers). Le premier, présent dans

les activités des SSII (IBM, Accenture, Capgemini, HP-EDS, Sopra Group…), consiste dans la plupart

des cas à externaliser une partie des activités de l’entreprise, le développement, le test et la

maintenance d’un système d’information. Mais pour d’autres sociétés, dans les domaines comme

l’aéronautique – Airbus ou Boeing - ou les grands groupes technologiques comme Samsung, LG, HTC,

Apple, l’offshoring consiste à ouvrir des sites de fabrication dans différents pays pour pouvoir

profiter de la variété des ressources ou élargir leurs marchés. Le BPO (business process offshoring)

concerne la délocalisation des autres services de l’entreprise comme les activités financières, de

ressources humaines et de marketing… Dans le cadre de ce sujet, je vais analyser le cas d’offshoring

des projets informatiques.

Les bénéfices connus de l’offshoring sont une réduction des coûts, une meilleure disponibilité

du personnel qualifié et un travail plus efficace. Mais ce service est aussi critiqué à cause du transfert

de l’emploi vers les autres pays ainsi que des risques géopolitiques, de la communication inefficace

et des conflits culturels.

Il faut bien distinguer l’offshoring de l’outsourcing. Nous pouvons trouver dans certains

documents l’utilisation de l’offshoring et de l’outsourcing pour désigner la même chose. En fait, ces


Page 38

deux termes ne sont pas tout à fait synonymes. L’outsourcing est un contrat passé entre 2

entreprises. L’externalisation dans ce cas revient à confier à la société tierce tout ou partie d’une

fonction de l’entreprise, la relation est de type client et prestataire de services externe. Ce contrat

est utilisé habituellement pour bénéficier des compétences spécialisées, des économies de coût et

de main d’œuvre. Contrairement à l’offshoring, l’outsourcing fait courir le risque à l’entreprise

cliente d’une dépendance au prestataire à cause du manque de connaissances et de ressources

internes. Nous pouvons dire aussi que l’offshoring est un cas particulier d’outsourcing, où le client et

le prestataire travaillent pour une même entreprise, mais implanté dans différents pays.

Fig 22 – Le business modèle des services outsourcing et offshoring

1

Le schéma ci-dessus résume la relation entre ces 2 concepts clés d’externalisation.

L’offshoring est basé plutôt sur la notion de la localisation géographique (soit au pays domicile soit à

l’étranger) tandis que l’outsourcing est défini selon l’utilisation des ressources internes ou externes.

Le marché global définit 5 catégories de services en se basant sur ces deux dimensions. Nous pouvons

trouver les différents scénarios. L’entreprise décide d’« outsourcer » (utiliser les ressources externes)

ses services à un prestataire local (cas 1). C’est le cas des projets dans le domaine aéronautique dans

la région Midi-Pyrénées, où EADS, ou sa composante Airbus, décide de sous-traiter ses projets à

plusieurs prestataires de services (Labinal, Safran, les SSII Sopra, Sogeti, AKKA, Cap Gemini…). Elle

peut aussi choisir des prestataires étrangers (cas 2 et 3). L’entreprise peut aussi décider d’ouvrir elle-

même son centre de services à l’étranger, déléguer la partie développement (cas 4) ou les activités

pilotage du projet (cas 5). Ce dernier cas se produit souvent entre une filiale de l’entreprise à

l’étranger et un fournisseur tiers.

De nos jours, l’offshore des services informatiques est une pratique de plus en plus

dominante dans le business global. Le chiffre d’affaires de ce type était de 250 millions de dollars à la

fin des années 1990. Aujourd’hui on annonce, selon les recherches de Dubaï Outsource Zone, que le

1 Sako, Mari. (2005). "Outsourcing and Offshoring: Key Trends and Issues". Livre présenté au Forum des

marchés émergents. Oxford, Royaume-Uni.


Page 39

marché mondial de l’offshoring pourrait atteindre les 479 milliards de dollars en 20162. Cette

croissance des services offshoring informatiques est liée à la disponibilité de grandes quantités

d’infrastructure de communication qui se sont développées grâce aux technologies d’Internet et de

télécommunications.

Il existe aussi le terme de nearshoring, l’implantation d’une activité dans un pays

proche de l’entreprise (pour une société française, ce sont les pays d’Europe ou du Maghreb), et

l’inshoring le fait d’utiliser une filiale à l’intérieur de son groupe afin de réaliser une prestation

informatique.

3.1.4. Le marché offshore international

Fig 23 - Le nombre des centres offshore dans les pays du monde

L’offshoring est actuellement une des stratégies principales des SSII internationales et

françaises, qui leur permet d’augmenter la productivité et la rentabilité3. Chaque année, malgré la

crise économique, ces entreprises investissent de plus en plus dans la construction de leurs centres

offshore. Aujourd’hui, les pays les plus attractifs du monde offshoring, en dehors de l’Inde, sont la

Chine, le Vietnam, les Philippines, la Roumanie, la République Tchèque et les pays d'Amérique

Latine…

3.1.4.1. Les pays de services offshore

Selon une analyse de Gartner Group, en 2011, les 30 pays les plus dynamiques et

intéressants pour la délocalisation de services informatiques sont 4 :

Amériques: Argentine, Brésil, Chili, Colombie, Costa Rica, Mexique, Panama et Pérou.

2 Michael Byrne. “Global outsourcing market to touch USD 479 billion by 2016”. Industry Watch, News. Publié le 7 juin 2011. 3 Dominique Filipponne. « Dix SSII reines de l'offshore ». Article sur JournalDuNet. Publié le 24 Octobre 2008.

4 Gartner Group. “Eight New Countries Moved into the Top 30”. Egham, UK, December 20, 2010.

http://www.smeadvisor.com/author/mikeb/

http://www.smeadvisor.com/category/industry-watch/

http://www.smeadvisor.com/category/news/


Page 40

Asie / Pacifique: Bangladesh, Chine, Inde, Indonésie, Malaisie, Philippines, Sri Lanka,

Thaïlande et Vietnam.

L'Europe, le Moyen-Orient et Afrique: Bulgarie, République Tchèque, Égypte, Hongrie,

Maroc, Ile Maurice, Pologne, Roumanie, Russie, Slovaquie, Afrique du Sud, Turquie et

Ukraine.

Avec de nombreux effectifs travaillant dans le domaine de l’informatique (25% des travaux

professionnels en Inde sont liés à l’informatique) et 500.000 nouveaux ingénieurs sortant des

universités chaque année, l’Inde est considérée comme un pays offshore incontournable. Les

grandes SSII indiennes aujourd’hui ont un chiffre d’affaires annuel de 28,7 milliards dollars.

Les autres pays « low-cost » européens ou d’Afrique du Nord ont aussi compris les avantages

qu’ils peuvent en tirer. Selon le directeur international d’Akka Technologies, qui a implanté un centre

offshore en Roumanie, Stéphane Descos, les Pays les plus proches de la France géographiquement et

culturellement parlant, comme la Roumanie et le Maroc, demandent moins d'encadrement, et

dégagent souvent une meilleure productivité.

En Asie, malgré une différence de culture forte et souvent difficile à franchir, les chiffres du

marché offshore ont sans cesse atteint des plafonds. A côté du géant indien, les entreprises

occidentales passent aujourd’hui aux pays du Pacifique. Capgemini est un pionnier sur ce chemin,

en ouvrant des filiales en Chine (1037 personnes), aux Philippines (182 personnes) et au Vietnam

(139 personnes). La Chine, avec des caractéristiques similaires à son voisin indien, est considérée

aujourd’hui comme étant une nouvelle destination offshore majeure.

3.1.4.2. Les géants des sociétés offshore

IBM est actuellement le leader mondial dans le domaine de l’informatique, et dans

l’offshoring, cette géante « Big Blue » (telle qu’on appelle cette entreprise) est aussi la pionnière. Sa

première délocalisation est commencée en 2004 par l’achat de l’indien Daksh e-Services, spécialisé

dans les centres d’appels. A la fin de 2009, le nombre d’effectifs global d’IBM s’élève à 400.000

collaborateurs avec seulement 25% localisés aux États-Unis contre 33% en Inde ! 5

Accenture, un autre acteur majeur du monde informatique, est connu par son réseau de

centre offshore. En septembre 2012, Accenture comptait 257.000 employés dans plus de 120 pays

dont 80.000 en Inde. Une forte stratégie de délocalisation permet à cette société de fournir une

grande variété de services. Aujourd’hui, la liste des clients d’Accenture est à plus de 75% de Fortune

Global 500 (les 500 entreprises mondiales classées selon l'importance de leur chiffre d'affaires) et

94% du top 100 de cette liste.

Le leader des SSII français dans le domaine offshore est Capgemini qui a commencé par

acheter la SSII indienne Kanbay pour 1,25 milliards de dollars en 2006. Elle comptait 40.000 employés

5 Working America & AFL-CIO. “Sending jobs overseas: The cost to America’s economy and working families.”

Washington, DC. 2010


Page 41

offshore en 2010 sur un total d'effectifs de119.000, dont 35.000 en Inde. En 2012, Capgemini a

recruté encore 10.000 ingénieurs en Inde et presque 3000 dans les autres locations offshores. La

stratégie de cette société est de devenir un acteur majeur mondial du monde informatique comme

IBM et Accenture et d’élargir encore sa base clientèle avec un nombre de 80.000 salariés offshore

prévu (soit le double de celui en 2010).

Les SSII indiens TCS (Tata Consultancy Services), Infosys technologies et Wipro technologies

apparaissent aussi dans le top 11 des meilleurs fournisseurs des services offshore mondial. Le leader

TCS de services informatiques indiens aujourd’hui compte investir dans la politique de

développement vers l’extérieur avec l’acquisition de la société française Alti pour 75 millions €.

Aujourd’hui, la société réalise un chiffre d’affaires de 100 millions € grâce aux gros contrats signés

avec SFR et Michelin. Infosys, présent en France depuis 2001, a obtenu en 2009 un résultat de 45

millions € en chiffre d’affaires selon une estimation du cabinet Pierre Audoin Consultants (PAC). Le

dernier SSII indien présenté dans le top, Wipro, après une dizaine d’années en France, compte 300

employés avec un chiffre d’affaires annuel de 300 millions € en 2011, soit 10 fois plus élevés qu’en

2005. Aujourd’hui, ces sociétés indiennes continuent de consolider leurs images et leurs positions sur

le marché international, d'augmenter la confiance des clients et de renforcer leur niveau de

compétitivité.

3.2. Les enjeux

3.2.1. Les bénéfices

Le phénomène offshoring semble évident. Mais pourquoi les entreprises le considèrent

comme incontournable ? Pourquoi presque toutes les grandes sociétés dans le monde des services

informatiques ont déployé cette stratégie ? Quels sont les bénéfices ?

Un premier avantage qu’apporte l’offshoring est sur le plan financier. La délocalisation,

permet à l’entreprise, avant tout, de réduire ses coûts de production. Cette réduction est le résultat

de plusieurs facteurs, notamment la réduction du coût des ressources …

Pour en avoir une vision précise, voici la table de comparaison de charges des salariés

américain et indien dans le secteur informatique :

États-Unis Inde

Salaire brut annuel 42,927 USD 6,179 USD

Coût G&A 8,571 USD 1,000 USD

Télécom 1,500 USD 2,328 USD

Dépréciation 3,000 USD 1,500 USD

Montant total 58,598 USD 11,854 USD

Ce tableau montre la différence de charge que l’entreprise doit supporter pour un

informaticien américain et un informaticien indien (plus de 46.000 USD par personne par an). Cette

différence est due à l’écart du salaire à temps plein, des coûts généraux et administratifs (coût de

déplacement, des charges sociales…), etc. L’entreprise peut encore bénéficier cet écart de charges


Page 42

dans d'autres pays comme la Chine (3000 USD), la Thaïlande (4500 USD), le Vietnam (2500 USD)6…

Bien sur, dans ces pays, les coûts administratifs sont beaucoup moins élevés. Nous pouvons constater

que la délocalisation en Inde, par exemple, permet à l’entreprise de réduire jusqu’à 80% son coût du

personnel (!), et que la charge d’un informaticien américain est équivalente à celle de 5

informaticiens indiens ! C’est surtout cette raison qui motive les entreprises d’entrer dans le monde

offshore.

A côté des avantages de charges du personnel, la délocalisation dans les pays « low-cost »

permet aussi de bénéficier des avantages fiscaux. Chaque pays, selon leur politique, adopte des

droits d’imposition différents. Dans certains états, les impôts sur le revenu et les impôts sur les

bénéfices des sociétés sont plutôt faibles voire inexistants, il peut ne pas y avoir d’impôt sur le

revenu du capital. Comme pour les impôts, les différentes taxes, en particulier la TVA, sont

généralement moins élevées ou supprimées. La délocalisation des grands entreprises doit tenir

compte ces informations avant de choisir la location d’implantation de leur centre de services

offshore ou nearshore. Aux États-Unis, le taux le plus élevé d’impôt marginal fédéral sur les sociétés

ayant des revenus supérieurs à 18,3 millions USD est de 40 %. En France, depuis 1993, l’impôt sur les

sociétés est à un taux de 33,33%, auquel se rajoute la contribution sociale sur la société 3,3%, donc le

taux global est de 34,43%. Au Royaume-Uni, le principal impôt sur les sociétés est de 28%. Tandis

qu’en Irlande, le taux de l’impôt est de seulement 12,5%. Ce taux est légèrement plus bas qu’en

Lituanie (15%), qu’en Roumanie (16%) et qu’en République Tchèque (19%). 7 8 Les pays offshore dans

les continents plus lointains ont aussi des fiscalités intéressantes : 15% au Hong Kong, 17% au

Singapour… Cela peut montrer que, avec les centres de services nearshore ou offshore implantés

dans les « paradis fiscaux », l’entreprise bénéfice d'un taux de 2 à 3 fois moindre qu’au pays onshore,

comme indiquait Lord Upsohn (Chambre des Lords, 1976) : « Aucun homme d’affaires en possession

de ses facultés intellectuelles n’entreprendra des relations d’affaires sur une base autre quelle celle

consistant à payer la plus petite imposition possible ».

En plus, aujourd’hui, dans les pays en développement, pour attirer les investissements

étrangers, le gouvernement décide d’offrir aux investisseurs des avantages fiscaux. Au Vietnam, le

gouvernement a décidé d’abolir les impôts sur le rapatriement des bénéfices pour les investisseurs

étrangers. Les investisseurs sont aussi autorisés de remettre leurs profits annuels à la fin de l’année

financière. Le ministre des finances du Vietnam annonce pour l’année 2013 des réductions de

charges fiscales pour les entreprises à capitaux étrangers qui s’engagent dans des projets

6 Worldsalaries.org. Programmer Salaries - International Comparison.

Site : http://www.worldsalaries.org/computerprogrammer.shtml Consulté en avril 2013. 7 Fresh Air. How offshore tax heaven save companies billions. Talk show. NPR. 2011.

Site : http://www.npr.org/2011/03/17/134619750/how-offshore-tax-havens-save-companies-billions. Consulté en avril 2013. 8 Wikipédia. Fiscalité en Europe.

Site : http://fr.wikipedia.org/wiki/Fiscalit%C3%A9_en_Europe. Consulté le 13 avril 2013.


Page 43

d'expansion pour les investissements existants9. Cette nouvelle politique motive les grandes

entreprises dans leur délocalisation vers ce pays. En effet, Cap Gemini y a déjà créé un centre de

développement. L’année 2013 sera l’entrée d'autres sociétés françaises comme Renault, Peugeot…

A côté des gains d’impôts sur le revenu, l’offshore permet aussi aux entreprises d’économiser

les autres coûts liés aux activités fiscaux onshore comme les coûts de comptabilité, des activités

d’audit, les coûts liés à la maintenance des données fiscales… Grâce à la combinaison de ces

réductions, la marge d’un projet offshore est espérée atteindre jusqu’à 40% de son budget total.

Pourtant, l’offshore n’a pas comme seul intérêt un bénéfice financier à court terme. Sur le

plan des stratégies à long terme, la délocalisation est aussi considérée comme un investissement

pour les entreprises. Grâce à l’ouverture des centres de services, l’entreprise peut ensuite entrer

dans le marché des pays, qui sont souvent en dessous du niveau de leur potentiel. La globalisation

permet à l’entreprise d’élargir leur part de marché, de consolider leur position sur le marché

international. Car en profitant de la variété des ressources et des compétences, l’entreprise peut très

bien augmenter la compétitivité de prix et de qualité, donc être plus dynamique face aux

concurrents.

Sur le plan macroéconomique, la délocalisation présente aussi un avantage non seulement

pour l’industrie des pays onshore mais aussi des pays offshore. Ces pays bénéficient du transfert des

connaissances et des compétences de l’entreprise mère aux filiales offshore. L’apparition des

entreprises internationales augmente la concurrence du domaine, oblige des entreprises locales à se

développer pour éviter d’être exclues du marché. Ces centres de services aident aussi ces pays à

créer des emplois, réduire le taux de chômage et former des ressources qualifiées. Le tableau ci-

dessous montre les chiffres liés à l’offshoring des Philippines, un des pays les plus dynamiques dans

ce domaine.

2004 2005 2006 2007 2008 2009

Croissance annuelle du PIB 6.10% 5.10% 5.40% 7.10% 3.80% 0.90%

Chiffre d’affaires de l’industrie des services offshore (Milliards USD)

1.5 2.2 3.3 4.9 6.1 7.2

Taux de croissance du CA des services offshore

47% 50% 48% 24% 18%

Nombre d’emplois du domaine offshore

101,00 163,000 236,000 300,000 372,000 442,000

Taux de croissance d’emplois du domaine offshore

61% 45% 27% 24% 19%

Table 1 - Philippines IT – BPO Industry, 2004-2009

Source: National Statistical Coordination Board; Business Processing Association of the Philippines

9 Vietnam Briefing. Vietnam Set to Lower Corporate Income Tax. Magazine. Publié le 20 décembre 2012.


Page 44

Nous pouvons constater sur ce tableau que, même si l’économie du pays est dans une

situation difficile, où le taux de croissance du PIB a baissé en 2007 de 7,1% à 3,8% et a chuté jusqu’à

0,9% en 2008, la croissance du domaine offshore est plutôt stable (avec une augmentation de 20%-

50% durant cette période), malgré une baisse de taux de croissance vers la fin 2009 en raison de

l’apparition des nouveaux concurrents offshore dans la région.

Un autre exemple est le cas de l’Inde, le champion des pays d’accueil de l’offshore, et aussi le

pays qui a le plus bénéficié de ce phénomène. Ayant été considéré comme la meilleure destination

pour l’ouverture des centres offshores, l’Inde profite bien des fruits du transfert de connaissances et

des autres effets. Les grands SSII indiens comme TCS, Wipro, Infosys, HCL Technologies… ont

aujourd’hui des collaborateurs de bon niveau et des méthodes de travail certifiées. Ayant leur centre

de services en Europe et aux États-Unis pour approcher leurs clients grandes comptes, ces grandes

entreprises indiennes ne sont plus juste des sous-traitants de services informatiques, elles sont

aujourd’hui en concurrence directe avec les SSII étrangers et sur leurs territoires.

3.2.2. Les points critiques

Malgré les avantages présentés, le phénomène offshore reste encore un sujet critique de

nombreux débats. La délocalisation est considérée comme un bénéfice pour le pays offshore, mais

elle présente des risques pour l’économie des pays onshore, notamment l’augmentation du taux de

chômage. Les États-Unis, pionnier des activités offshoring, ont passé une période difficile due à cette

stratégie. En Iowa, entre les années 2000 et 2003, 45.000 postes ont été supprimés. Et ce chiffre est

estimé à 3,3 millions sur l’ensemble des états dans les 10 prochaines années. C'est la raison pour

laquelle les américains considèrent l'offshore comme la cause de la disparition des postes. Selon une

étude de ‘Program on International Policy Attitudes, 72% des personnes enquêtées constatent que

l’offshore est une mauvaise tendance car cela fait perdre du travail aux employés américains. Les

salariés américains, étant en concurrence plus ou moins directe avec leurs collègues dans les pays

low-cost, pensent que la délocalisation amènera à réduire leur salaire.

La suppression des postes n’est pas le seul mauvais impact de l’offshore. Les américains

considèrent que les bénéfices de l’offshore ne profitent qu'aux patrons des entreprises, et que

l’argent gagné par les SSII est lié aux diminutions du nombre de salariés. 64% des américains, dans la

même enquête, considèrent que l’offshore élargit la distance entre les riches et les pauvres du pays.

Sur le plan macroéconomique du pays, l’offshore présente aussi des risques de crise économique.

Comme le revenu des salariés est réduit, ces derniers sont forcés de réduire leur niveau de vie en

réduisant leur consommation, ce qui est dangereux pour la santé économique du pays.

La délocalisation permet à l’entreprise de bénéficier des « paradis fiscaux », inversement, elle

fait perdre au pays un montant lié à l’impôt que l’entreprise aurait dû payer si elle s’y implante.

Accenture, lors de sa délocalisation, localise son siège social à Dublin, Irlande, depuis 2009 pour

profiter de meilleurs taux fiscaux. Selon une étude d’US PIRG, chaque année, les États-Unis comptent

une perte de 150 milliards dollars d’impôts à cause de ce phénomène 10 alors que ce montant aurait

10

U.S. PRIG (Education Fund). What America Could Do with $150 Billion Lost to Offshore Tax Heavens?


Page 45

dû être investi dans l’éducation, la santé, l’économie, les transports et autres projets.

Une étude d’Unilog et IDC, réalisée en 2004 auprès de 200 entreprises en France, en

Allemagne et au Royaume-Uni, montre que 36% des entreprises enquêtées ont mal évalué les

économies réalisées dans la délocalisation des services. Les calculs montrent que dans certains

projets, les gains ne sont pas aussi importants que ce qui était estimé au début. Les entreprises

espéraient pouvoir gagner jusqu’à 40% du coût total du projet, mais en réalité, ils sont souvent

autour de 10-15%.

Il faut aussi noter que le projet offshore présente plein de risques pour l’entreprise adoptant

cette stratégie. La collabora on à distance nécessite des connexions de qualité, une documentation

bien soignée. Il faut aussi avoir des normes et des standards de sécurisation des données. La

protection, la confidentialité des données et la gestion des licences d’utilisation des logiciels dans le

contexte offshore deviennent compliquées. Concernant les ressources offshores, même si

l’entreprise bénéficie de la variété et des gains sur le coût de ces ressources, elle peut aussi avoir des

risques. L’offshore permet aux employés d’augmenter leurs compétences, et en conséquence, leur

permet d’avoir des droits de demander un salaire plus élevé, ce qui augmente le coût de ces

ressources pour l’entreprise. Dans le domaine de l’informatique, le taux de turnover est déjà élevé,

et l’offshore a tendance à l’accroître encore.

3.3. L’offshoring : stratégie incontournable de Sopra

3.3.1. Offshore à SopraGroup

Fig 24 – Les centres de service nearshore-offshore de Sopra

Site http://www.uspirg.org/sites/pirg/files/reports/USPIRG_Tax_Havens_Fact_Sheet_0.pdf (consulté en avril 2013)

http://www.uspirg.org/sites/pirg/files/reports/USPIRG_Tax_Havens_Fact_Sheet_0.pdf


Page 46

Aujourd’hui, l’offshoring à SopraGroup est considéré comme un élément important dans ses

stratégies commerciales pour plusieurs raisons : les freins à l’offshoring ont quasiment disparu sur

son marché qui est celui de l’accompagnement de ses clients dans l’évolution de leur système

d’information. Ce choix de stratégie est influencé par des clients (l’approche « sourcing » de la

plupart des grands clients de SopraGroup inclut l’offshoring) et aussi par des concurrents (comme

indiqué dans la partie 3.1.5 « Situation des SSII en France et à l'international », presque toutes les

grandes SSII sont déjà entrées dans le monde d’offshoring).

En 2012, selon le rapport financier du groupe, 32% du chiffre d’affaires est réalisé par les

centres de services hors de France, soit un montant de 389,44 millions € avec un effectif de 4760

(juin 2012), soit 33.5% de l'effectif total du groupe.

3.3.1.1. SopraGroup India – Madrid – Casablanca

Sopra Group India est considéré comme le centre de Services offshore. Cette filiale 100%

Sopra Group est localisé à New Delhi et comprend plus de 1000 ingénieurs impliqués dans des

projets de développement au forfait, des TMA ou des activités de Global Testing, ainsi que la R&D

(recherche & développement) et le support technique. Comme tous les autres centres d’offshore en

Inde, ce centre de services couvre un large éventail technique comme ERP (SAP, Oracle, eBusiness…),

Web/Portail (Java, .NET…), IMB mainframe, iSeries, EAI (Axway, WM…), BI (Datastage, Informatica,

Microsoft, Cognos, BIW…) et des processus de Développement industriels sont certifiés SEI CMMI

niveau 5 et ISO 9001:2000. Pour ces raisons, Sopra Group India devient le cœur de la stratégie et des

offres du groupe, ce qui permet d’atteindre le meilleur ratio Qualité – Réactivité – Coût…

Fig 25 - Sopra India

Pour le côté Nearshore, Sopra a choisi en 2003 Madrid comme site nearshore afin de servir

ses clients français et européens. Ensuite, une extension à Casablanca (Maroc) a été mise en place

début 2008. Ces sites bénéficient à la fois des avantages du nearshore : même fuseau horaire, une

proximité culturelle et géographique (la langue de travail n’est pas obligatoirement l’anglais, le

français est aussi utilisé) et des avantages en local : connaissance du marché local et capacité de

recrutement rapide. Aujourd’hui, avec 1200 ingénieurs formés aux technologies actuelles, ces

centres nearshore permettent d’assurer un niveau de production efficace et de services de qualité.


Page 47

3.3.1.2. Modèle « Soprasien » : Xshore

Alors, comment s’organise Sopra Group pour réussir cette stratégie ?

Dans la stratégie de Sopra, un projet « XShore » est composé de 2 sous- projets, un projet

« onshore » proche du client et un projet « offshore » ou « nearshore » développé dans un Centre de

Services. L’onshore peut être localisé sur 2 sites, soit sur le site du client (onsite), soit sur le site Sopra

(offsite), soit réparti sur les 2. Le projet One Report auquel j’ai participé est un projet de type

Onshore-Offshore, avec une équipe onshore à Sopra Group Midi Pyrénées qui travaille directement

avec le client (Airbus) et une équipe offshore à Sopra Group India (localisé à Noida, New Delhi). La

répartition des responsabilités et des activités des équipes sera détaillée dans la partie suivante.

Fig 26 – L’oganisation d’un projet offshore de Sopra

Ce modèle présente différents niveaux de répartition des activités entre l’onshore et

l’offshore. En général, il existe 4 niveaux de répartition des activités. Si un projet est au niveau 1,

l'offshore n’est qu’un centre de développement. Par contre, si un projet est au niveau 4, l’offshore

gère la totalité du projet. L’onshore dans ce cas assure le suivi commercial et le pilotage global du

projet. Le choix d’appliquer un niveau sur un projet doit tenir compte du type de projet, du moment

du projet et des risques… One Report est un projet de niveau 1.

Un projet informatique en général est souvent au niveau 1 ou 2, c’est-à-dire que l’équipe

onshore s’occupe de la partie fonctionnelle et du design et l’équipe offshore réalise le

développement, car un projet nécessite souvent des ressources onshore afin d’assurer la

communication directe avec le client. Les niveaux 3 et 4 sont souvent conseillés pour les TMA (Tierce

Maintenance Applicative - la maintenance appliquée à un logiciel) qui ne demande pas forcément

une communication permanente et directe avec le client.

3.3.1.3. L’approche basée sur l’évaluation des risques

L’application de l’offshoring à un projet informatique n’est pas tout à fait automatique.

Comme indiqué précédemment, même si l’offshore rapporte à l’entreprise des avantages

indéniables, il présente des risques, surtout dans la communication, la qualité de la livraison et

l’efficacité de la production… Ces risques, venant d’une gestion de projet insuffisante ou du fait de ne


Page 48

pas avoir effectué une étude d’opportunité préalable, peuvent conduire le projet à l’échec et donc

l’entreprise à des pertes importantes sur le plan financier et sur son image. C’est pourquoi,

l’application de l’offshoring doit être implémentée suivant une démarche prudente.

Pour ces raisons, Sopra Group a décidé d’implémenter une stratégie d’évaluation

d’opportunité des projets offshore basée sur une méthodologie d’étude rigoureuse et soignée. Pour

les livraisons de ses projets informatiques, Sopra Group, depuis 1998, adopte le modèle de livraison

globale (Global Delivery Model). Ce modèle permet de déterminer les projets ou les phases d’un

projet qui conviennent le mieux à l'offshoring et des stratégies de gestion des risques spécifiques

sont déployées afin d’assurer une livraison efficace. Ce modèle s’applique aux projets de

développement d’applications, des programmes de gestion d’applications et des services de test…

Fig 26 – Le processus d’évaluation des risques

La détermination de l’applicabilité de l’offshore sur un projet est basée sur une méthodologie

d’évaluation. L’étude de cette méthodologie se compose de 4 étapes : développement des critères,

des facteurs et des benchmarks utilisés ; évaluation du projet ou du service en question suivant les

facteurs précédents ; développement de la migration des stratégies du projet afin d’atteindre les

objectifs, amélioration du processus selon les retours d’expériences du projet. Ces étapes forment un

cycle de développement continu, afin d’optimiser l’efficacité de la méthodologie ainsi que son

domaine d’application.

La première étape d’évaluation d’opportunité de l’offshore est de développer des critères et

des facteurs afin d'identifier les risques de chaque projet et leurs impacts. Ces critères peuvent

couvrir des besoins d’utilisateurs, des plateformes, des interfaces, des parties intéressées, de

l’architecte du projet… Les facteurs d’évaluation sont aussi liés à l’organisation du client : la maturité

du client doit être suffisante pour appréhender les activités multi-géographiques, les licences

spécifiques et les considérations juridiques peuvent avoir un impact sur la capacité d’offshoring.

Une fois les critères bien définis, une matrice d’évaluation des risques est construite. Dans

cette matrice, pour chaque risque, un niveau d’impact est défini et des valeurs de probabilité du

risque sont déterminées à chaque phase du projet. Enfin, une valeur de risque global est calculée en


Page 49

prenant la somme des produits entre le niveau de l’impact et sa valeur. Cette valeur finale permet de

choisir une bonne stratégie de gestion qui devra être adoptée par le pilotage afin d’assurer le bon

déroulement du projet. Selon ce choix, les actions nécessaires seront mises en place (choix du niveau

de modèle onshore-offshore, définition des responsabilités des acteurs, le transfert de

connaissances…)

Fig 27 – La matrice d’évaluation de risques

Les résultats de l’étude initiale des risques peuvent conduire à modifier ou supprimer des

projets à valeur importante de risques. Le processus d’amélioration peut varier selon les besoins du

client et les risques à réduire. Les stratégies déployées peuvent être :

L’utilisation d’un spécialiste de validation des besoins clients en termes de faisabilité

technique qui s’assurera de l’alignement des exigences techniques avec la capacité du

système. Cette action permet de réduire des problèmes venant des besoins instables durant

la phase de développement du projet.

Le développement d’une stratégie de transfert de connaissances fonctionnelles avec le client

dans les projets onsite. Ce workshop doit permettre à l’équipe offshore d’avoir des

connaissances métiers et une communication efficace car souvent la distance géographique

provoque une barrière dans la communication, particulièrement dans l’expression des

besoins fonctionnels. Des outils et des règles de communication doivent être appliqués afin

d’avoir une meilleure transparence entre l’équipe business, l’équipe onshore et l’équipe

offshore.

L’application des méthodes de développement agile où les phases de projet sont organisées

en itérations. Les méthodes de développement agile, souvent utilisées pour travailler plus

rapidement et plus efficacement, sont tout à fait applicables aux projets offshore. Le fait de

dispatcher le projet en plusieurs cycles permet à l’équipe offshore d’avoir la visibilité

fonctionnelle très tôt. Toutefois, la prise de décision sur la méthode doit avoir la validation

côté client. Dans certain cas, le schéma directeur informatique du client impose la méthode

de travail (Airbus, pour les projets de niveau d’importance élevé, impose la méthode du cycle

en V). Les détails de l’utilisation seront présentés dans la prochaine partie.


Page 50

Après la mise en place des actions nécessaires pour réduire les risques du projet, les retours

d’expériences sont pris en compte dans les pratiques standard dans le but d’améliorer l’évaluation

des projets suivants.

3.3.2. L’offshore dans le contexte du projet One Report

3.3.2.1. Organisation des équipes FO-BO

One Report, comme la plupart des projets du pôle FBI, est réalisé dans le contexte offshore,

donc avec une équipe front-office en France et une équipe back-office en Inde. La répartition des

tâches du projet est 50-50 et le mode de fonctionnement est plutôt classique. L’équipe front office,

composé de 2 senior architectes, 2 analystes et un chef de projet s’occupe de la spécification

(l’architecture générale et le design détaillé) tandis que l’équipe back-office composée de 3

développeurs BW et 2 développeurs ABAP, réalise le développement. Il y a aussi une équipe de

testing offshore de 2 testeurs indépendants de l’équipe de projet, qui intervient dans le projet durant

les phases de test.

3.3.2.2. Les premiers retours d’expériences

Par ciper à ce projet durant mon stage m’a permis de vivre des expériences dans le contexte

offshore. La gestion dans ce contexte est plus difficile parce qu’il faut prendre en compte la distance

géographique et culturelle importante entre les deux sites offshore. Voici les premiers retours

d’expériences que j’ai pu retenir dans le contexte de One Report.

La communication est une des activités principales du management d’un projet et le

contexte offshore la rend plus compliquée à gérer. Pour remplacer la communication physique face à

face, différents outils de télécommunication ont été mis en place. Chaque jour, une conférence

téléphonique est planifiée entre le chef de projet front-office et le responsable de l’équipe back-

office pour discuter de l’avancement des tâches de la journée. Les autres échanges peuvent être

réalisés via les mails ou l’outil de messagerie instantanée entre tous les membres des équipes ainsi

que des fichiers communication sur le réseau interne pour assurer la transparence et la pérennité de

l’information.

Malgré le temps que l’équipe a consacré à la communication, il subsiste des problèmes

d’incompréhension. En effet, comme One Report est un projet de type classique, la conception est

faite uniquement onshore et le développement à l’offshore. Cette distinction amène inévitablement

à des difficultés de compréhension par les développeurs indiens des spécifications fonctionnelles

établies par les analystes français. Ces difficultés ont causé un nombre important de défauts du

développement livré par les développeurs et la correction de ces défauts a pris beaucoup de temps

pendant la phase de qualification. C’est pourquoi, des actions de validation ont été mises en place

dès réception du développement, avant la phase de qualification, pour éviter ce problème.

Un autre problème lié à la communication est la gestion des versions des documents,

notamment la synchronisation des documents de spécifications. Dans certains cas l’équipe offshore

ne développe pas la dernière version de la spécification ou ne prend pas en compte une évolution de


Page 51

la spécification. Pour résoudre ce problème, un fichier de communication a été mis en place où toutes

les évolutions sont communiquées à l’ensemble de l’équipe.

Une autre difficulté de One Report est la volatilité du marché de services informatiques en

Inde. Comme précisé précédemment dans la partie des points critiques de l’offshore, l’évolution du

marché offshore en Inde fait augmenter le phénomène de turnover où les développeurs, ayant acquis

un certain niveau d’expérience, ont tendance à aller chercher un autre poste avec plus de

responsabilité et de rémunération. Cette situation n’est pas favorable pour un projet de longue durée

comme One Report qui demande une stabilisation de l’équipe.

Un impact de la différence culturelle dans One Report est la distance hiérarchique. En Inde,

où cette distance est importante, les employés ont tendance à attendre de leurs supérieurs les tâches

à faire. Par contre, les Français n’ont pas cette distance dans leur culture de travail: l'organisation du

travail se fait de manière conviviale et non autoritaire entre employés et managers. Cette différence

présente des difficultés dans la communication, dans la mesure où les développeurs offshore ne

remettent pas en question les tâches qui leur ont été confiées et suivent passivement les ordres.

Pour conclure, les vrais challenges de One Report est d’optimiser la communication et la

validation du développement. Pour le plan de la communication, différents outils, fichiers de

communication, de recapitalisation ont été mis en place. Pour faciliter la validation par les analystes,

les développeurs sont requis de réaliser eux-mêmes les tests unitaires avant de livrer leur travail

3.4. Une solution pour l’offshore : les méthodes agiles Je profite du contexte du sujet de réflexion pour ouvrir une parenthèse sur la relation entre

ce sujet et les méthodes de gestion de projet. Il existe à nos jours, plusieurs méthodes de gestion de

projet informatique où chacune a ses avantages particuliers propres. Quelle serait la méthode de

gestion de projet la plus favorable pour les projets offshoring où existent de nombreux risques

notamment sur la communication et la compréhension des besoins fonctionnels du client ?

Aujourd’hui, les méthodes agiles font partie des méthodes les plus adéquates. En se basant sur les

retours d’expériences et mes connaissances, je vais montrer une petite analyse de l’application des

méthodes agiles dans le contexte offshore et comment ces méthodes pourraient en réduire les

risques.

Les méthodes agiles sont apparues pour la première fois en 2001 en tant que méthodes de

développement informatique. Elles divisent le projet en plusieurs petites itérations, avec l’évolution

des besoins et des solutions durant la réalisation du projet avec une équipe souple et flexible. Ces

méthodes sont utilisées dans le cas où le projet nécessite des travaux rapides tout en garantissant la

qualité. Les 3 méthodes les plus connues et utilisées sont XP (eXtreming Programing), RAD (Rapid

Application Development) et Scrum.

Un des points fondamentaux des méthodes agiles est la communication. Les échanges entre

les acteurs (le client, le chef de projet, les membres de l’équipe) jouent un des rôles les plus

importants dans le succès du projet. Ensuite, un autre risque de l’offshoring est le manque

d’information et de connaissance des spécifications fonctionnelles de l’équipe offshore. Les


Page 52

méthodes agiles, souvent appliquées dans le cas de manque d’expression des besoins clients,

permettent de résoudre ce problème.

Mais l’application des méthodes agiles dans les projets offshoring n’est pas toujours facile.

Premièrement, la communication dans les méthodes agiles doit être plus « proche » possible, c’est-à-

dire jusqu’au niveau des échanges physiques. Dans la méthode XP, les membres de l’équipe doivent

travailler en binôme, l’un à côté de l’autre. Dans la méthode RAD, chaque jour, une petite réunion

entre tous les membres de l’équipe doit être planifiée au début de la journée de travail, au cours de

laquelle chacun communique son travail. Ces actions sont particulièrement difficiles à mettre en

œuvre dans l’offshoring à cause de la distance géographique. Ensuite, certaines entreprises

préfèrent la démarche classique, où les besoins et les spécifications doivent être complètement

exprimés avant d’être envoyés au développement dans les centres de services dans les pays

étrangers. Cette démarche n’est pas compatible avec les méthodes agiles, où les changements des

besoins du client sont acceptés et le retour à l’étape précédent ne pose pas de problème au

déroulement du projet.

C’est pourquoi la question posée pour cette partie est: comment adapter les méthodes agiles

aux projets offshoring pour bénéficier de leurs avantages ?

3.4.1. Amélioration du plan de communication

Comme précisé précédemment, l’une des difficultés de l’offshore est la communication.

Comment une communication à distance peut garantir la qualité des échanges physiques ?

3.4.1.1. Mobiliser des ressources humaines

Une première solution proposée est la présence d’une personne sur le site onshore. Si

l’équipe offshore ne peut pas être « en colocation » avec l’équipe onshore, le fait d’envoyer une

personne sur le site onshore peut aider beaucoup à faciliter la communication. Cette solution permet

d’assurer la communication physique, ce qui est idéal pour tous les projets. La communication au

sein de l’équipe de projet ne se limite pas aux réunions hebdomadaires, les discussions informelles

sont aussi intéressantes et importantes. Les méthodes agiles privilégient ces genres de discussions,

car elles permettent d’avoir un maximum d’information sans y passer beaucoup de temps, d’assurer

la transparence de l’information au sein de l’équipe, de détecter et de faire monter les problèmes le

plus tôt possible.

Le choix de la personne pour la mission est aussi important. Cette personne doit être

l’intermédiaire entre 2 équipes, c’est-à-dire elle doit avoir les connaissances de base des 2 équipes

(notamment des connaissances métiers et techniques), ainsi que des compétences de

communication pour relier des personnes de différentes cultures, gérer les conflits, les risques

d’incompréhension, etc. C’est pourquoi dans la plupart des cas, les personnes choisies sont des

personnes d'expérience ayant une certaine responsabilité. Pourtant il faut aussi prendre en compte

les besoins et les préférences individuels de la personne en question. Travailler à des milliers de

kilomètres loin de sa famille pour une durée de plusieurs mois n’est pas toujours facile. Dans la

plupart des cas, les personnes sont envoyées onshore seulement dans les phases estimées

importantes du projet (souvent les phases initiales pour participer au travail avec le client) et qui


Page 53

durent quelques semaines ou quelques mois au plus. Même si cette solution a beaucoup

d’avantages, elle n’est pas utilisée pour tous les projets pour des raisons de coût d'envoi de la

personne. Dans One Report, cette solution n’est pas appliquée mais dans certains projets, il y avait

des déplacements d'une personne de Sopra Group India en France pour participer à certaines

phases.

L’envoi de la personne à l’onshore n’est pas la seule solution possible. Dans certains cas,

selon le contexte du projet, c’est la partie onshore qui envoie ses personnes à l’offshore, par exemple

le client et le manager onshore peuvent être envoyés à l’offshore pour produire le plan de

production initial du projet. L’envoi des ressources à l’autre équipe est aussi une solution pour

équilibrer les compétences et les connaissances entre les équipes. Nous pouvons trouver un analyste

offshore sur le site onshore dans les sessions initiales de spécifications pour mieux comprendre les

règles de gestion. Ou un développeur onshore sur le site offshore dans le développement de la

première itération pour participer à l’initialisation du code de base. L’importance de cette action

n’est pas d'exécuter des tâches du projet (même si cela est intéressant), mais de construire une

relation réelle, basée sur l’échange direct face à face. Cette relation facilite la communication à

distance dans les phases suivantes du projet. Et cette action, pour pouvoir profiter de ses avantages,

doit être toujours réalisée dans les phases initiales du projet.

3.4.1.2. Gérer les problèmes interculturels

Un problème pouvant empêcher la mise en place des méthodes agiles dans le contexte

offshore est la différence culturelle entre les équipes. Les centres de service offshore sont souvent

localisés dans des pays situés à grande distance géographique et culturelle, ce qui entraîne des

difficultés dans l’application des méthodes agiles des entreprises. Le principe des méthodes agiles est

le travail autonome avec des décisions prises de façon collective, sans aucun effet venant de la

hiérarchie.

Pourtant, dans certains pays comme l’Inde, la Chine, le Vietnam… la distance hiérarchique est

considérée comme indispensable dans la culture d’entreprise. La prise de décision dépend forcément

des supérieurs et les personnes de niveau hiérarchique plus bas ont l'habitude d’attendre des ordres

ou des tâches de leurs chefs. Pour ces pays, le management est défini comme « l’art du contrôle».

Cette notion de hiérarchie peut nuire à la communication dans l’équipe, ce qui devient mono-sens :

des seniors aux juniors. Ce phénomène est moins évident dans les pays onshore (des pays de

l’Ouest). Il existe des cas où l’équipe offshore accepte passivement des informations venant de

l’onshore sans discussion, pourtant rien ne peut garantir que les spécifications dans ces cas soient

bien exprimées et prises en compte par l’équipe offshore.

Dans One Report, la différence des distances hiérarchiques pose aussi des problèmes.

L’équipe indienne, influencée par le mode de travail patron-employé, a des difficultés dans la prise

de décision de certaines tâches. Un exemple que j’ai pu observer est le développement des chaines

de chargement où les développeurs attendaient toujours d’avoir les spécifications détaillées et

développent (sans aucune remise en question) la conception livrée par les analystes, tandis que les

analystes voulaient fournir des spécifications générales et laisser aux développeurs le choix de


Page 54

décider plus librement au niveau d’architecture plus détaillé. Le changement de culture est difficile et

faire que les personnes habituées à un style de contrôle expriment leurs opinions et prennent

l’initiative va prendre beaucoup de temps et peut ne pas se faire en un seul projet. Mais cette action

très importante ne doit pas être sous-estimée pour assurer une bonne communication et donc le

succès du projet, car une fois que les équipes offshore ont pris l’habitude de prendre des décisions

avec une meilleure responsabilité, les membres seront plus motivés et autonomes.

3.4.1.3. Utiliser des bonnes méthodes de communication

Une autre solution qui peut réduire les risques de manque d’information est de construire un

centre de documentation interne. J’ai pu observer ce cas dans le cadre de mon stage. Sopra Group a

mis en place un portail de connaissances du groupe sur l’intranet contenant tous les retours

d’expériences, des études et des analyses faites et partagées par tous les collaborateurs dans

différents domaines. Ensuite, au niveau du pôle FBI, il existe aussi un serveur commun où tout le

monde peut trouver des guides d’utilisation, des tutoriels BW, des normes et méthodes de

développement… Chaque employé dispose ensuite d'un répertoire sur le serveur de chaque division

pour partager les documents. Au niveau de chaque équipe de projet, les documents contenant des

informations communes (les dossiers de spécification, de test, le planning…) sont synchronisés et

gérés par l’outil SVN. Ces outils de partage de connaissances et d’information doivent être simples à

installer et déployer. La base des documents doit être bien structurée et gérée avec des droits

d’accès précis et des contrôles réguliers, afin de permettre un transfert de l’information efficace. Ces

« bibliothèques électroniques » sont pour moi une pratique intéressante.

Au niveau des réunions, les méthodes agiles privilégient des meetings informels et efficaces

(les scrums dans Scrum ou les stand-up meetings dans XP). Dans les projets offshore, il n’est pas

toujours facile de faire des réunions à distance avec toute l’équipe de projet à cause du décalage

horaire (4h30’ d’écart entre la France et l'Inde, mais pour les entreprises américaines, l’écart est de

11h30). Une solution à ce problème est de réduire le nombre de conférences, seules les réunions

vraiment nécessaires sont mises en place et entre seulement des personnes concernées, souvent des

personnes s’occupant de la communication au sein de l’équipe, notamment des managers. Les autres

discussions informelles sont assurées par l’outil de messagerie instantanée.

Dans One Report et les autres projets offshore de Sopra, une réunion par semaine suffit, à

condition que d'autres actions aient été mises en place (l’envoi des ressources à l’autre équipe ou la

mise en place du wiki…) et que le projet soit en bon état. Seulement dans la période où le projet est

en situation de crise, les réunions sont passées en mode journalier pour assurer le suivi et pilotage. A

côté des problèmes de décalage horaire, il faut aussi prendre en compte les écarts entre les jours de

congés et les jours fériés des différents pays dans la planification du projet. Il ne faut pas forcer les

Français dans leur Toussaint et les Indiens pendant leurs jours de fêtes hindoues. A Sopra, les

informations concernant des jours fériés de tous les pays où est implanté le Groupe sont accessibles

sur le site intranet et la planification doit toujours prendre en compte ces calendriers.

La communication à distance, pour moi, est un peu « fragile ». Comme les problèmes

techniques sont hasardeux et variés, rien ne peut nous assurer une communication permanente tout


Page 55

au long du projet. C’est pourquoi il est nécessaire d’avoir plusieurs moyens de communication afin

d’éviter le risque que le projet soit bloqué à cause de problèmes majeurs pouvant survenir à ces

moyens. De plus, les différents modes de télécommunication doivent être utilisés pour des besoins

leur correspondant bien, c’est-à-dire au bon moment et pour résoudre le bon problème.

En réalité, dans One Report, les équipes de projet disposent d'un wiki interne, d'un outil

« instant messaging », d'emails, de documents de communications et de connections téléphoniques.

L’outil de messagerie instantané développé par Sopra (appelé Spark) est favorable aux messages

courts, mais permet aussi de savoir si la personne est à son bureau ou si elle est disponible pour

répondre à des questions. Si la résolution du problème dépasse la limite des quelques messages,

l’échange par téléphone devra être utilisé pour économiser du temps et réduire les risques

d’incompréhension… Enfin, il faut penser à concevoir un plan d’action dans le cas de problème des

outils de communication et aussi une maintenance régulière afin d’éviter tous les risques possibles.

3.4.2. Amélioration du plan qualité

Le succès du projet dépend certainement de l’efficacité de la communication au sein de

l’équipe. Pourtant, cette solution n’est pas suffisante pour assurer la qualité de la production.

L’échange des informations internes est nécessaire, mais une bonne méthode de travail est aussi

importante pour produire rapidement, avec de la bonne qualité et avec moins de coût.

3.4.2.1. Réduire les risques d’incompréhension

Une première solution pour réduire les risques d’incompréhension est de raccourcir les

itérations. Dans les méthodes agiles, les itérations durent souvent de 6 à 8 semaines. Mais rien

n’empêche de construire des itérations encore plus courtes, contenant un niveau plus simple de

règles de gestion. La spécification devient plus facile à comprendre. Certains projets appliquent des

itérations de 2 semaines. La réduction de taille de chaque itération permet de détecter les problèmes

au plus tôt possible et de les corriger avant qu’ils ne se compliquent. Ces problèmes peuvent venir de

la compréhension des règles fonctionnelles ou du niveau des stratégies déployées (plan de

production trop serré, manque de ressources, communication inefficace et même taille de chaque

itération…).

Pourtant, le découpage du projet en plusieurs parties dépend du contexte de chaque projet.

Dans One Report, il est difficile d’avoir des itérations courtes à cause des contraintes liées au

mécanisme de SAP BW (une itération de One Report dure 3-4 mois). Puisque les flux d’information

décisionnelle doivent être travaillés de façon complète des systèmes sources aux outils de reporting

et que l’utilisateur ne teste que les reports finaux, il est compliqué de développer un flux

d’information en plusieurs itérations. Une itération longue implique un décalage entre la conception

et le test de One Report. En réalité, il y a des difficultés dans la phase de test à cause de nombreux

défauts détectés.

Dans les projets offshores, l’incompréhension des besoins clients du côté offshore est

souvent un problème difficile à gérer. Effectivement, les méthodes agiles, comme XP, sont

particulièrement utilisées pour les projets où les besoins utilisateurs sont incomplètement définis.

Dans ce cas, les cas d’utilisation (users stories) dans XP sont utilisés et ils doivent être rédigés par les


Page 56

analystes et les utilisateurs eux-mêmes dans la phase d’expression des besoins. Ces users stories sont

les petites descriptions des besoins et de leurs scénarios de test d’utilisateurs. Elles sont transférées

ensuite à l’équipe offshore en même temps que la spécification et permettent aux développeurs

d’avoir une vision concrète de ce qu'ils doivent faire. Cette façon va faciliter le travail de toute

l’équipe de projet : les analystes doivent forcément comprendre les règles fonctionnelles pour

pouvoir rédiger les cas de tests et remonter leurs questions au plus tôt possible aux clients, les

développeurs peuvent aussi lancer des tests de leur côté, prévoir les problèmes et les questions

éventuels sur les cas de test.

Un problème qui peut apparaitre dans cette solution est l’engagement du client, plutôt dans

la rédaction des cas de tests utilisateur. C’est le cas de One Report. Au moment où Sopra commence

à intervenir dans le projet (au début de la phase de spécification), toutes les règles de gestion ne sont

pas encore précisées par le client. Ce problème cause beaucoup de difficultés à l’équipe de projet car

les architectes et les développeurs n’ont pas une vision claire de l’ensemble des règles

fonctionnelles. C’est pourquoi, les méthodes agiles soulignent l’implication du client dans le projet

comme un principe de base.

3.4.2.2. Faire valider régulièrement le travail

Dans les méthodes agiles, pour assurer la qualité de la livraison du produit, il faut faire

valider le travail par le client au plus tôt et le plus fréquemment possible. Dans Scrum, les prototypes

sont souvent utilisés pour montrer plus rapidement la solution proposée au client par l’équipe projet.

Le contexte offshore ne permet pas de faire régulièrement la démonstration de la solution

directement au client. Mais nous pouvons procéder différemment, par exemple faire valider le

développement par les analystes qui connaissent déjà les règles fonctionnelles.

Dans One Report, l’équipe front-office et back-office travaillent sur les mêmes

environnements de développement, de test, d’intégration et de production. Ces environnements

permettent aux analystes et clients d’avoir une meilleure vision sur le produit développé par l’équipe

offshore. Les mécanismes de ces systèmes sont bien adaptés pour cette façon de travailler. Les

développements de l’équipe offshore une fois finalisés doivent être validés par les analystes du côté

français avant d'être transférés dans les environnements de test. Cela permet de faire une première

revue sur le produit développé, afin d’éviter les problèmes d’incompréhension entre les équipes.

Un problème éventuel pour cette solution que j’ai pu observer dans mon projet est un de

définition des tâches de chaque équipe. Les développeurs indiens ont un peu négligé les tests

unitaires avant de livrer le code aux analystes, en pensant que leur travail sera en tout cas vérifié. Il

est nécessaire que les développeurs aient conscience que leurs tests permettent de réduire le temps

de validation par les analystes, donc d’assurer l’efficacité du travail collectif. Quant à la spécification,

comme les utilisateurs finaux d’Airbus n’interviennent qu’à la phase de recette, les documents

d’architecture générale doivent toujours être validés par les acteurs intermédiaires (l’ISPL – le

facilitateur de projet entre Airbus et Sopra, le centre de compétence BI Sopra et Airbus) avant de

passer au niveau de design plus détaillé.


Page 57

3.4.2.3. Répartir les équipes selon en fonction des modules développés

Une autre habitude que nous pouvons trouver dans les projets offshore est la répartition des

équipes selon leurs activités. Souvent dans ces projets, l’équipe onshore s’occupe de la spécification

des besoins grâce au contact plus proche avec le client tandis que l’équipe offshore réalise le

développement. Cette méthode est proche du modèle en cascade, qui consiste à réaliser le projet

successivement par étapes, où le passage à l’étape suivante est fait qu’à condition que l’étape

courante soit complètement terminée.

Par contre, travailler en méthodes agiles avec les itérations ne favorise pas ce mode de

séparation. Il serait intéressant de ne pas limiter l’équipe offshore au développement, cette équipe

peut aussi s’occuper d'activités liées à l’analyse et la conception du produit, sous réserve que ces

activités soient en provenance de l’onshore. Nous pouvons découper le projet en plusieurs modules

et construire des équipes en fonction du domaine de fonctionnalités, pour que chaque équipe puisse

prendre en charge quelques modules. Dans ce type d’organisation du travail, le côté offshore peut

avoir des connaissances fonctionnelles du projet. Et l’existence des analystes offshore permet aussi

de gagner du temps en diminuant la charge sur la communication. Les développeurs offshore n’ont

pas besoin d’attendre toujours les réponses de côté onshore, ce qui pourrait les bloquer pendant un

certain temps, du fait qu'ils peuvent recevoir des réponses des analystes locaux.

Ce cas de blocage est apparu dans One Report, où l’équipe offshore ne prend en charge que

la partie de développement et n’a pas été capable de remettre en question les erreurs dans les

spécifications fournies par les analystes. Pour cette raison, la montée en compétence fonctionnelle

des analystes offshore est importante et cette action peut nécessiter l’envoi de ces ressources à

l’onshore dans les phases initiales communes.

3.4.2.4. Produire efficacement des documents

Les documents font certainement partie de la qualité du projet, mais dans l’application des

méthodes agiles dans l’offshoring, ce point provoque un dilemme. Selon les méthodes agiles, les

documents ne sont produits qu’en cas de nécessité, et des prototypes jetables, des courtes

discussions… sont plus favorables. Par contre, le contexte offshore nécessite de la documentation,

cette activité est inévitable et non négligeable pour remplacer la communication face à face. Le

temps que l’équipe consacre à cette activité aide à réduire les risques de mauvaise compréhension,

de maintenance…

La question qui reste est comment pouvons-nous optimiser la documentation, jusqu’à quel

niveau produit-on les documents ? La documentation est incontournable, mais il est aussi déconseillé

de passer trop de temps à rédiger les documents inutiles. Un wiki avec les documents de support

réutilisable (des bilans des anciens projets, des retours d’expériences, des guides…) serait

intéressant, ainsi que d'autres outils de tracking... Certes, il faut produire « juste suffisamment » de

documents, mais ce niveau de « suffisamment » dépend vraiment du projet et du contexte réel. Le

fait de travailler en plusieurs itérations permet à l’équipe de projet d’acquérir l’expérience et de

définir au fur et à mesure le niveau de documentation nécessaire.


Page 58

Dans le projet One Report, la structure des documents a changé au cours des itérations, avec

l’arrivée de l’expérience. Au début, les documents sont répertoriés en fonction des itérations, mais

dans un deuxième temps, ils sont placés selon l’architecture du projet puisque les itérations utilisent

des objets communs. Par contre, la plupart des documents produits sont imposés par Airbus. Pour

les autres documents, l’équipe ne produit que les fichiers internes nécessaires : tableau de bord des

travaux, fiches de question, fichier de communication, rapport d’activité individuel (pour le pilotage

du projet)…

3.4.3. Conclusion

L’offshore est actuellement une tendance des SSII mais les problématiques de gestion des

projets dans ce contexte restent encore le sujet de nombreux débats car les causes d’échec viennent

principalement des problèmes de management. Les méthodes agiles, considérées comme récentes,

flexibles et certainement évolutives dans le futur, sont adaptables à ce challenge offshore. Ce qui

précède fournit une première analyse de l’application de ces méthodes à l’offshoring. Certes, il en

existe d'autres plus adaptées, en fonction de chaque projet. Le point principal à prendre en compte

est que les méthodes de gestion de projet ne sont qu’une boîte de bonnes pratiques. Il n’y a pas de

normes et de standards dans la gestion de projet, ni de méthode meilleure ou plus mauvaise. La

gestion de projet nécessite un esprit flexible et proactif où dans tous les cas, il ne faut pas être

attaché à une seule méthode. Le gestionnaire de projet doit savoir réagir et prendre des décisions au

plus vite possible, selon ses connaissances de ces bonnes pratiques, pour assurer le bon déroulement

du projet et donc l’efficacité et la qualité du travail de son équipe.


Page 59

4. Bilan

Le but du stage est d’apporter à l’étudiant des expériences dans le contexte professionnel.

C’est la deuxième fois que j’effectue un stage durant mes études. Lors du dernier stage en Licence 3,

je travaillais avec l’équipe des chefs de produits d’Airbus (des Maîtrises d’Ouvrage) et j’avais participé

à la phase d’étude de l’opportunité, de définition des besoins et de validation de l’application livrée

par le prestataire de service. Cette fois, j’ai été intégré à l’équipe de projet du client Airbus mais du

côté Maîtrise d’œuvre, pour réaliser les phases de définition de la solution finale, de développement

de cette solution et de test d’intégration. Finalement, ces deux stages m’ont permis de participer à

tout le cycle de réalisation d’un produit informatique, d’observer et d’exercer des activités des deux

côtés MOA et MOE. Ces expériences ont été pour moi très enrichissantes et intéressantes.

Pour cette dernière partie du mémoire, je vais présenter dans un premier temps mes bilans

sur les compétences que j’ai pu acquérir pendant mon stage, qu’elles soient techniques,

professionnelles ou fonctionnelles. Ensuite, j’aborderai les apports du stage sur le plan professionnel

et personnel. Je terminerai par un bilan des difficultés rencontrées durant le stage sur mes tâches

confiées et comment j’ai résolu ces problèmes.

4.1. Bilan de compétences

Tout d’abord, je vais présenter les apports du stage à mes domaines de compétences. Le

stage m’a permis d’un côté de consolider mes connaissances existantes, c’est-à-dire d’appliquer et

prendre du recul par rapport à ce que j’ai pu acquérir de la formation MIAGE et de mes anciennes

expériences ; et de l’autre côté d’enrichir mon portefeuille de compétences pour pouvoir évoluer

dans ma carrière professionnelle. Ces compétences ne sont pas seulement de nouveaux langages de

développement, mais aussi des méthodes de travail, la gestion de projet et l’ensemble des savoir-

faire.

4.1.1. Compétences techniques

Premièrement, je veux insister sur mon entrée dans le domaine de SAP BW, le système

Business Intelligence de SAP.

Les cours à l’université m’ont donné une première idée du système ERP et SAP, un des sujets

émergents de l’informatique de gestion, mais cela restait encore une vision abstraite. C’est la raison

pour laquelle mon choix de stage était orienté vers les postes permettant d’obtenir une première

expérience sur ce domaine. Finalement, j’ai eu l’occasion d’atteindre cet objectif en étant retenu

pour ce stage, proposé par le pôle FBI de Sopra Group. Deux formations (SAP BW et langage ABAP)

données par l’équipe de Sopra Academy et 6 mois de travail sur un projet important de reporting

financier m’ont permis d’avoir une perception du système ERP et son progiciel dominant sur le

marché SAP.


Page 60

Ensuite, mon entrée dans le domaine de l’informatique décisionnelle a eu lieu de deux

façons : la formation de Sopra Academy dans un premier temps, et les cours donnés par les

enseignants de la MIAGE durant la période de retour à l’université. Effectivement, ces deux façons ne

sont pas totalement similaires.

La formation dans l’environnement professionnel s’oriente vers les notions et pratiques de

SAP BW. Elle est plus précise mais aussi un peu limitée car son objectif est d’acquérir un savoir-faire

du système SAP BW tout en respectant des méthodes de développement Sopra et des normes

imposées par le client Airbus. De l’autre côté, le but des cours de l’entrepôt de données à la MIAGE

est de faire une présentation globale sur la Business Intelligence grâce aux définitions théoriques et

générales, et ses différents outils sur le marché… Cette approche particulière m’a permis de voir la

relation entre des connaissances acquises académiquement et celles requises par le contexte

professionnel et comment appliquer les acquis universitaires à la vie professionnelle et inversement.

Pour toutes ces raisons, mon objectif d’acquisition d’une bonne première expérience sur SAP

a été atteint.

Ce stage m’a aussi permis d’appliquer les savoir-faire obtenus lors de mes anciens projets

professionnels. Dans le cadre du stage en Licence 3, j’avais pu participer à la phase de vérification et

de validation d’une application avec des chefs de produit informatique d’Airbus. Ces expériences

m’ont familiarisé avec le logiciel de test HPQC et les activités de validation (rédaction des cas de test,

suivi des anomalies…) que j’ai appliqué dans ce stage. Ce cas m’a montré l’apport des projets de

professionnalisation sur les connaissances des progiciels et des processus d’entreprise. Ces

connaissances ne sont pas forcément obtenues dans le cadre des enseignements universitaires mais

elles sont aussi très utiles pour ma carrière professionnelle.

4.1.2. Compétences fonctionnelles du métier

Travaillant dans un projet lié au système d’information financier d’Airbus, j’ai pu également

avoir l’occasion de découvrir le monde de la finance. En vérité, les notions financières utilisées dans

One Report n’ont pas beaucoup de relation avec les cours de gestion financière à la MIAGE. Ce fait

me parait naturel vu que la MIAGE n’est pas une formation orientée vers les compétences du

domaine de la finance. Néanmoins, mon travail de spécification demande des connaissances des

règles de gestion financière d’Airbus, donc il m’a fallu acquérir ces notions.

Mon entrée dans ce nouveau domaine n’a pas été tout à fait facile comme dans celui de la BI.

Au début, le manque de connaissance m’a posé des difficultés dans la lecture du cahier des charges

et à l’analyse des règles de gestion, notamment à la compréhension des vocabulaires du métier (des

types de comptes financiers, de prix du matériel, des niveaux d’agrégation des données…).

Effectivement, des sessions de transfert de connaissances, des réunions d’expression des besoins du

client Airbus, des discussions avec mes collègues (souvent des personnes diplômées de l’IAE finance

à Toulouse) m’ont aidé à monter en compétences et à comprendre la partie fonctionnelle de

l’application One Report.


Page 61

En tout cas, ces expériences ont été intéressantes. Avec des connaissances dans un domaine

autre que l’informatique de gestion (dans ce cas ce sont les connaissances de la finance, même si

cela est limité dans le cadre de One Report), je pourrais avoir plus de piste pour mon projet

professionnel.

4.1.3. Compétences de management

L’objectif de la MIAGE est de former le futur chef de projet informatique. Ce métier nécessite

trois branches de compétences : les compétences technique, les compétences métier et enfin les

compétences management.

Bien que le sujet de mon stage ne soit pas directement attaché à la gestion de projet, j’ai

aussi acquis les expériences dans ce domaine, en observant les activités de pilotage sur One Report

et en appliquant mes savoir-faire d’organisation ou de planification dans mon projet de stage.

Participant à One Report, chaque jour, je pouvais observer les actions de ma chef de projet et des

responsables du domaine FBI quand le projet s’est situé dans le contexte de crise. One Report a

connu les difficultés au cours de son déroulement pour différentes raisons. Rapidement, l’équipe de

pilotage FBI a mis en place un plan d’action pour identifier et analyser la source du problème

(renforcer la communication et le suivi de l’équipe de projet, affecter des ressources manquantes…).

Ce cas particulier a été pour moi très intéressant car il m’a donné des idées sur les actions à mettre

en œuvre dans le cas où le projet ne se déroulerait pas dans de bonnes conditions.

J’ai pu aussi dans le cadre de mon stage découvrir deux méthodes de gestion de projet

différentes : eMedia de Sopra et GPP Toolkits de Airbus, de voir comment deux sociétés peuvent

collaborer et harmoniser leurs différents modes de travail (cette analyse a été présentée dans la

partie 2.2.2 de ce mémoire de stage).

4.2. Bilan professionnel

L’apport du stage n’est pas seulement des acquis de compétences, c’est aussi une occasion

pour l’étudiant de « se plonger » dans le contexte industriel, de développer des aptitudes

d'adaptabilité ainsi qu'un véritable sens du service permettant d'évoluer dans un environnement

professionnel.

Concernant mon projet de stage, comme tous les autres projets, j’ai défini les grands

objectifs à atteindre et ai créé un planning prévisionnel. Au cours du stage, ma gestion du temps a

globalement tenu la route, même si le planning réel n’a pas suivi exactement ce qui était prévu en

raison d’une forte dépendance du planning One Report, le projet où je travaillais. Il m’est arrivé des

périodes non prévues de baisse ou de surcharge d’activités et je ne me suis pas bien organisé pour

me débrouiller pendant ces périodes. C’est pourquoi vers la fin de mon stage, je me suis trouvé dans

un planning légèrement serré à cause du retard de la rédaction de ce mémoire de stage. Ces

expériences m’ont montré qu’une bonne gestion de temps nécessite vraiment une flexibilité de la

réalisation des tâches, il faut aussi bien définir la priorité des tâches et prévoir tous les problèmes

possibles.


Page 62

Durant mon stage, j’ai participé aux différentes réunions : des réunions hebdomadaires de

l’équipe où j’ai dû communiquer l’avancement de mon travail, des conférences avec l’équipe

offshore en Inde pour échanger des informations… J’ai eu aussi l’occasion de joindre des sessions de

transfert de connaissance : des workshops internes de l’équipe ou du bundle FBI ou avec le client

Airbus. Au cours de ces réunions, mis à part l’acquisition des connaissances du métier et de la

technique, j’ai pu pratiquer mes capacités d’analyse, de synthèse et d’écoute active afin de maintenir

une communication efficace.

Étant naturellement timide et fermé, la communication était une difficulté pour moi. En plus,

le contexte offshore de One Report nécessite une bonne maîtrise de l’Anglais. C’est une qualité

indispensable au métier de chef de projet. Au cours de mon stage, j’ai essayé d’appliquer les notions

vues en cours de communication à la MIAGE (écoute active, construction d’argument,

communication multiculturelle…). Finalement, j’ai réussi à être à l’aise dans la communication avec

mes collègues français et indiens, même s’il me reste beaucoup de choses à améliorer notamment

sur l’esprit d’ouverture aux autres et l’expression de mes idées.

Enfin, je veux ouvrir une parenthèse sur mon observation de mon métier préféré : chef de

projet. Dans un projet en situation de crise comme One Report, le chef de projet devait assurer la

communication, augmenter le suivi et le pilotage de l’équipe indienne et aussi supporter les

membres de l’équipe sur leurs tâches… Ensuite, être un chef de projet nécessite une capacité

d’analyse et de résolution du problème. Comme le planning de One Report a été serré, il a fallu

réagir le plus rapidement possible pour ne pas perdre trop de temps sur un incident. Enfin, la

communication est un vrai challenge pour le chef de projet. Il doit toujours avoir une vision optimiste

et être le plus motivé afin de pouvoir animer et motiver son équipe. Avec une grosse charge de

travail et aussi des pressions, le métier de chef de projet demande vraiment une passion et un goût

de travailler en équipe avec des contacts humains. Le succès d’un projet dépend vraiment de la

qualité de son manager.

4.3. Bilan personnel

Durant cette deuxième expérience de stage, j’ai aussi amélioré mes capacités d’adaptation et

d’intégration. Au début du stage, le manque de connaissances m’a fait douter de mes capacités à

effectuer les travaux demandés. Le fait d’être nouveau dans un milieu inconnu m'a aussi rendu un

peu timide. En plus, le statut difficile de One Report nécessite des qualités d’expertise et le manque

de compétences m’a fait hésiter à participer aux tâches que je jugeais « critiques ». Pourtant, grâce

au soutien de mes collègues, j’ai pu de temps en temps acquérir l’autonomie dans mon travail.

Durant le stage, j’ai participé à la réunion annuelle d’agence où j’ai reçu des informations de

Sopra groupe. Cette participation m’a donné le sentiment d’être un vrai collaborateur du groupe. Je

suis aussi invité au petit déjeuner d’accueil des nouveaux stagiaires avec des responsables de la

division qui m’ont donné des conseils intéressants sur l’orientation de ma vie professionnelle.


Page 63

Durant le stage, j’ai aussi participé à un « workshop » des jeux de société créés par les

salariés de Sopra. Chaque jeudi midi, j’ai eu l’occasion de découvrir les nouveaux jeux dans une

ambiance conviviale avec le groupe des soprasiens passionnés par « Gynkopolis », « Sevenwonder »,

« Smallworld, « GalaxyRace »… Ces sessions de jeux m’ont apporté de bons souvenirs. Ils m’ont

montré que la vie professionnelle n’est pas constituée uniquement de travail mais aussi de relations

humaines et de découvertes intéressantes.

Sur mon projet professionnel, ce stage m’a permis d’entrer dans un nouveau domaine, la BI.

Intéressé par les technologies liées à la base de données, je suis arrivé rapidement à trouver le plaisir

de découvrir ce domaine, surtout le système SAP BW. Après le stage, je souhaite continuer sur un

poste lié à SAP pour progresser et évoluer dans ce domaine.

4.4. Difficultés

Durant ce stage, j'ai dû faire face à plusieurs difficultés, qu'elles soient organisationnelles ou

techniques.

Le premier challenge que j’ai rencontré est l’adaptation au contexte de production d’Airbus.

Comme One Report fait partie de l’ensemble des projets d’ARP, sa réalisation doit s’effectuer dans

les mêmes environnements que les autres projets (l’environnement SAP BW d’ARP). Airbus, pour

administrer les activités sur ces environnements, a mis en place des normes et des méthodes de

nommage, de développement, d’autorisations... Parfois, les procédures de demande de droit

d’autorisation ou de création des vues pour l’extraction des données des systèmes R/3 au SAP Rights

et au BICC (centre de compétences d’Airbus) m’ont pris du temps et m’ont bloqué dans certaines

tâches. En réalité, comme je ne maîtrisais pas ces normes et ces méthodes, la validation des

documents par le BICC m’a pris du temps et m’a obligé de retravailler plusieurs fois sur les livrables.

Ensuite, les travaux de One Report ont été réalisés sur des environnements interdépendants

qui n’étaient pas toujours stables. Quelquefois, j’ai reçu des anomalies dans l’extraction des données

venues du système SAP R/3. Il y avait aussi des périodes de blocage des environnements dû aux

actions de maintenance ou aux incidents de surcharge du système. Ces problèmes, qui n’étaient pas

sous la responsabilité de One Report, m’ont parfois bloqué dans l’avancement des tâches, il me

fallait m’adapter à ce contexte et trouver rapidement des solutions pour les régler (basculer à une

autre tâche ou demander l’aide d’une personne concernée).

Enfin, une autre difficulté est le manque de connaissances du métier dans le domaine de la

finance et un planning serré dans la rédaction du mémoire de stage que j’ai précisé dans les parties

précédentes.

Malgré les diverses difficultés rencontrées, mon stage s’est déroulé dans d’excellentes

conditions. Mon équipe, ma chef de projet et ma tutrice professionnelle m’ont suivi dans

l’avancement des tâches, ont répondu à toutes mes questions et m’ont donnée des bons conseils

afin de me permettre de surmonter ces difficultés et d’accomplir mes tâches dans les délais qui

m’étaient impartis.


Page 64

4.5. Conclusion

Mon sujet de stage est intéressant, il m’a permis de découvrir la BI qui devrait devenir

ensuite mon domaine préféré. A côté des apports techniques et organisationnels, le stage m’a aussi

permis de mettre en application des acquis théoriques. De plus, j’ai pu développer des aptitudes

d'adaptabilité ainsi qu'un véritable sens du service me permettant d'évoluer dans un environnement

professionnel. Enfin, le stage m’a aidé à avoir une vision plus claire sur ma future carrière

professionnelle.


Page 65

Glossaires ARD Architecture Dossier

AGD Application general design

BI Business Intelligence

BICC Business Intelligence Competence Center

BRD Business Requirement Dossier

BSD Business Specification Dossier

CP Chef de projet

DSO Data Store Object

ETL Extract, Transform, Load

FBI Finance Business Intellingence

GPP Generic Project Process

IMSB Responsable de production Airbus (assurer la MIP)

IMSI Administrateur système Airbus (infrastructures)

ISPL Information System Project Leader

KPI Key Performance Indicator

MD Master data

MIV/MIP Mise en validation, mise en production

NatCos National Companies

PSA Persistent Staging Area

RAD Roles & Authorizations Dosser

SD Specification Dossier

SI Système d’Information

TD Test Dossier


Page 66


Page 67

Bibliographies

Documents consultés pour la partie « présentation d’entreprise » et « synthèse des travaux »

SOPRA GROUP. Livret d’accueil. Document interne.

SOPRA GROUP. Livret d’accueil Bundle FBI. Document interne.

SOPRA GROUP. Livret de formation SAP BW. Document interne.

RAVAT F. et TESTE O., Cours de Datawarehouse, MIAGE 2012-2013.

ZURFLUH G. et PUJOLLE G., Cours de gestion de projet, MIAGE. 2012-2013.

Documents consultés pour le sujet de réflexion :

MARTINS CAMBAO Carlos, MALIK Douma, et al. (2002), LES SOLUTIONS ERP. Brique E-Mage, Mars

2002.

CB RICHARD ELLIS, “Outsourcing and the Rise of India”. Journal en ligne. Q1, 2004.

AGN INTERNATIONAL ASIA PACIFIC, “Tax card 2011, General Guide to Asia Pacific Countries Tax

Fact”, Août 2011.

KPMG International Cooperative, “Asia Pacific Taxation, Singapore, 2012 Edition”. Mars 2012.

ENDRES Dieter, FUEST Clemens, SPENGE Christoph, “Company Taxation in the Asia-pacific Region,

India, and Russia”. ISPN 3642122175, 9783642122170. Springer, 2010.

BOIRON Pascal, « Services informatiques : pourquoi l’offshore ne prend pas en France ». Magazine ITPartners. Publié le 3 Novembre 2011.

CHINA BRIEFING. “China, India and Emerging Asia Tax Rates Compared”. Asia Briefing Bookstore. 9

Décembre, 2011

SEXTANT EXPRETISE, « LE MARCHÉ INFORMATIQUE : SERVICES, LOGICIELS ET MATÉRIEL ».

Publication sur le site www.sextant-expertise.fr. Septembre 2012.

GOASDUFF Laurence (Gartner Group). « Many Outsourcers Will Disappear, but Which Ones and How

Fast?” Article publié par Gartner Group. Egham UK, February 25, 2013.

FILIPPONE Dominique, « OFFSHORE IT : LE TERRAIN DE JEU MONDIAL DES SSII FRANÇAISES ». Article

sur JournalDuNet. 08 Juillet 2011.

VANDER WEERDT Gwyn, « Analyzing the Debate over Offshore Oursourcing in the Service Industry : Is

there a Reason for Concern ? ». Major Themes in Economics, Spring 2006.

http://www.china-briefing.com/news/author/china-briefing

http://www.china-briefing.com/news/2011/12/09/china-india-and-emerging-asia-tax-rates-compared.html


Page 68

WORKING AMERICA & AFL-CIO. “Sending jobs overseas: The cost to America’s economy and working

families.” Washington, DC. 2010

SOPRA GROUP. « Projets en Xshore. Les clés de la réussite ». Document interne Sopra. Juin 2008.

SOPRA GROUP. « Risk Based Approach to Offshore Delivery ». Livre blanc.

GEREFFI Gary, FERNADEZ-STARK Karina. “The Offshore Services Value Chain. Developing Countries

and the Crisis”. Center on Globalization, Governance & Competitiveness Duke University. Avril 2010.

AUNDHE M.D., MATHEW S.K.., “Risks in offshore IT outsourcing: A service provider perspective”,

European Management Journal (2009), doi:10.1016/j.emj.2009.01.004.

ROUHIER Stéphane, « EXEMPLES D’OFFSHORING : Retours d’expérience et leçons apprises au sein de

grandes entreprises », CIGREF. 2007.

HUGON Jean-Christophe, LOUPY Hugon Fabien. « Les sociétés françaises et l’externalisation offshore ». Mémoire de thèse. Mai 2007.

LE GO Patrick, « Agile & offshore : retour d’expérience en milieu bancaire ». Valtech. Octobre 2007.

ANDERSEN Per. “IT Trends For The Future”. IDC Nordic. 29 Novembre, 2005.

SAKO Mari. (2005). "Outsourcing and Offshoring: Key Trends and Issues". Livre présenté au Forum

des marchés émergents. Oxford, Royaume-Uni.

BYRNE Michael. “Global outsourcing market to touch USD 479 billion by 2016”. Industry

Watch, News. Publié le 7 juin 2011.

FILIPPONE Dominique. « Dix SSII reines de l'offshore ». Article sur JournalDuNet. Publié le 24 Octobre

2008.

GARTNER Group. “Eight New Countries Moved into the Top 30”. Egham, UK, December 20, 2010.

WORLDSALARIES. Programmer Salaries - International Comparison.

http://www.worldsalaries.org/computerprogrammer.shtml Consulté en avril 2013.

Fresh Air. How offshore tax heaven save companies billions. Talk show. NPR. 2011.

http://www.npr.org/2011/03/17/134619750/how-offshore-tax-havens-save-companies-billions.

Consulté en avril 2013.

Wikipédia. Fiscalité en Europe. http://fr.wikipedia.org/wiki/Fiscalit%C3%A9_en_Europe. Consulté le

13 avril 2013.

VIETNAM BRIEFING. Vietnam Set to Lower Corporate Income Tax. Magazine. Publié le 20 décembre

2012.

http://www.smeadvisor.com/author/mikeb/



http://www.smeadvisor.com/category/news/


Page 69

U.S. PRIG (Education Fund). What America Could Do with $150 Billion Lost to Offshore Tax Havens.

http://www.uspirg.org/sites/pirg/files/reports/USPIRG_Tax_Havens_Fact_Sheet_0.pdf (consulté en

avril 2013).


Page 70


Page 71

Annexes

L’architecture générale détaillée One Report

Afin de mieux présenter l’application One Report et donner une meilleure vision sur

l’ensemble des objets stockage de données du projet, dans cette partie, j’intègre l’architecture

générale One Report, pour les flux de données transactionnelles venant du système allemand, dans

le cadre des deux premières itérations (la spécification de la 3e itération n’est pas encore finalisée).

Pour la première itération : One Report Gross Value & Provision

Les données fonctionnelles du module FI sont remontées dans le DSO XFIPEIG1 de la couche X qui

alimente le DSO HFIAX801 (le DSO de base de la première itération).


Page 72

HFIAX801 va ensuite alimenter le DSO HFIAX80H pour historiser les données et le DSO HFIAX804

pour calculer la réconciliation entre les données FI et les données MMFI.

Ces données sont ensuite utilisées pour alimenter les cubes et les multi-cubes :

Le multi-cube HFIAX80M1 est utilisé pour les reports de provisions.

Le multi-cube HFIAX80M3 est utilisé pour les reports des montants fiscaux et la dépréciation.


Page 73

Pour la deuxième itération : One Report Material Stock by Location

Les données MM sont remontées du système R/3 et stockées dans le DSO XPPH3202. Ce flux est déjà

existé et utilisé par les autres projets.

One Report prend ces données et stocké dans le DSO HFIAX802 (pour 1 mois) et le DSO HFIAX803 (la

consommation détaillée des 12 derniers mois).


Page 74

HFIAX802 alimente le DSO HFIAX80K pour réconcilier des écarts entre les données MM et MMFI

(venant du HFIAX801) et le cube HFIAX80C5.

Le multi-cube HFIAX80M4 est une vue des données de différents cube (le niveau de stock dans

HFIAX80C5, la provision dans HFIAX80C4 et les cibles d’inventaire dans HPPH320CG, un cube

existant).


Page 75

Le cube HFIAX80C6 va prendre les données d’inventaire de HFIAX80M4 en convertissant les

montants en devise locale.

Le report d’inventaire de stock est basé sur le multi-cube HFIAX80M5 qui est une vue de HFIAX80C6.


Page 76

Le report des prix MAP et standard est basé sur le multi-cube HFIAX80M7 alimenté par HFIAX801.


Page 77

Le report des stocks VMI est basé sur le multi-cube HFIAX80C8 alimenté par HFIAX802.


Page 78

Planning de stage Liste des tâches


Page 79

Diagramme de GANTT