Eyrolles conduite-de-projets-informatiques-offshore

Eric O’Neill, diplôméde l’Institut NationaldesTélécommunications,débute sa carrière àNew-York, où ildécouvre à la fin desannées 1980 lesprojets informatiquesoffshore. Il revient enFrance en 1994 pourprendre la tête deséquipes de R&D de XRTCerg Finance. Il dirigedes projets offshoreimportants, dépassantla centaine d’années-homme, mettant enpratique desméthodologies telles queRUP (Rational UnifiedProcess) d’IBM, surlesquelles son expérienceest désormais reconnue.Après plus de 15 ans depratique du développement delogiciels, il crée OutsourcingAdvantage qui met sonexpérience et son réseau deprestataires à portée des sociétésqui désirent démarrer ou optimiserleurs projets informatiques offshore.

www.outsourcing-adv.com

Au sommaire

Un guide pratique pour réussir vos projets offshoreUn guide pratique pour réussir vos projets offshoreCet ouvrage répond aux questions que se posent toutes les entreprises qui envisagentde sous-traiter en offshore certains de leurs projets informatiques. Quels projets exter-naliser ? Comment choisir un prestataire, dans quel pays ? Comment évaluer lesrisques et le retour sur investissement ?

Emaillé de conseils pratiques et de check-lists, l’ouvrage propose des solutionsconcrètes et opérationnelles pour réussir chaque phase du projet : étapes prépara-toires, choix du prestataire et du mode d’outsourcing (forfait, régie…), aspects contrac-tuels, organisation des équipes, méthodologie de suivi de projet, tests et recettes,déploiement, supervision et sécurité.

Au sommaireLes principes de l’outsourcing. Pourquoi sous-traiter des développe-ments en offshore ? • Les spécificités de l’offshore : éloignement deséquipes, langue de travail, différences de mentalité, etc. • Les paysde l’offshore et les prestataires offshore • Les collaborateurs locaux etles collaborateurs en offshore • Les modes de fonctionnement de l’off-shore : montage des équipes, modes de gestion (forfait, régie…) •Choisir le projet à externaliser • Les risques de l’offshore : protectionde la propriété intellectuelle, confidentialité des informations, maîtrisedes coûts et retards de paiement, risques politiques et sociaux.Préparation des projets offshore. Evaluer son projet pour l’offshore •Choisir le prestataire et les équipes offshore • Le contrat avec le pres-tataire offshore : propriété intellectuelle, définition de services, gestiondes équipes, méthodologie et suivi du projet. Gestion des projets enoffshore. Les points clés de la gestion de projet offshore • Gestiondes ressources humaines • Méthodologie et processus de dévelop-pement itératif • Gestion des tests et de la qualité • Intégration etdéploiement • Suivi de l’équipe offshore : indicateurs de mesure,documents de suivi et rapports d’activité, sécurité, etc. Annexe.Modèles de documents et exemples (évaluation du projet, rapport defacturation, points clés d’un contrat en mode régie, suivi des risques,gestion des exigences, iteration assessment, planning détaillé d’uneitération, feuille de recette, mesure des économies réalisées).

Code

édite

ur :

G115

60 •

ISBN

: 2-

212-

1156

0-1

45 E

Eric O’Neill

Solutions d’entreprise

● Quels projets sous-traiter en offshore ?

● Choix du pays et duprestataire

● Évaluation des risques

● La relation contractuelleavec le prestataire

● Méthodologie de suivi de projet

● Tests, recette et déploiement

● Modèles de documents prêts à l’emploi

Cond

uite

de

proj

ets o

ffsh

ore

Cond

uite

de

proj

ets o

ffsh

ore

E. O

’Nei

llE.

O’N

eill

sol entr-o'neill ok 1/03/05 10:50

Conduite de projets informatiques offshore

CHEZ LE MÊME ÉDITEUR

F. VALLÉE. – UML pour les décideurs.N°11621, 2005, 300 pages (collection Architecte logiciel).

P. ROQUES, F. VALLÉE. – UML 2 en action. De lʼanalyse des besoins à la conception J2EE.N°11462, 3e édition, 2004, 380 pages + poster (collection Architecte logiciel).

P.-A. MULLER, N. GAERTNER. – Modélisation objet avec UML. N°11397, 2e édition 2000, 520 pages (format semi-poche).

G. BOOCH, J. RUMBAUGH, I. JACOBSON. – Le guide de lʼutilisateur UML. Collection Technologies objet/Référence. N°9103, 2000, 552 pages.

P. ROQUES. – UML : modéliser un site e-commerce.N°11070, 2002, 168 pages (collection Cahiers du programmeur).

J.-L. BÉNARD, L. BOSSAVIT , R. MÉDINA , D. WILLIAMS. – Gestion de projet Extreme Programming.N°11561, 2002, 300 pages (collection Architecte logiciel).

A. COCKBURN. – Rédiger des cas dʼutilisation efficaces. N°9288, 2001, 320 pages.

I. JACOBSON, G. BOOCH, J.RUMBAUGH. – Le Processus unifié de développement logiciel. N°9142, 2000, 487 pages.

R. KIMBALL, L. REEVES, M. ROSS,W. THORNTHWAITE. – Concevoir et déployer un data warehouse. Guide de conduite de projet.N°11600, 2000, 594 pages.

R. LEFÉBURE, G. VENTURI. – Gestion de la relation client.N°11331, 2e édition, 2004, 464 pages.

P. DEVOITINE. – Mettre en place et exploiter un centre dʼappels.N°11122, 2003, 402 pages.


Eric O’Neill

Avec la contribution de Olivier Salvatori

ÉDITIONS EYROLLES61, bd Saint-Germain75240 Paris Cedex 05

www.editions-eyrolles.com

Le code de la propriété intellectuelle du 1er juillet 1992 interdit en effet expressément er juillet 1992 interdit en effet expressément er

la photocopie à usage collectif sans autorisation des ayants droit. Or, cette pratique sʼest généralisée notamment dans les établissements dʼenseignement, provoquant une baisse brutale des achats de livres, au point que la possibilité même pour les auteurs de créer des œuvres nouvelles et de les faire éditer correctement est aujourdʼhui menacée.En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou

partiellement le présent ouvrage, sur quelque support que ce soit, sans autorisation de lʼéditeur ou du Centre Français dʼExploitation du Droit de Copie, 20, rue des Grands-Augustins, 75006 Paris.© Groupe Eyrolles, 2005, ISBN : 2-212-11560-1

http://www.editions-eyrolles.com

Pour Alexandra

Livre Offshore.book Page V Lundi, 21. février 2005 7:44 19

Livre Offshore.book Page VI Lundi, 21. février 2005 7:44 19

VII

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Objectifs de l’ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Organisation de l’ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

À qui s’adresse l’ouvrage ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Première partie – Les principes de l’outsourcing

Chapitre 1 – La mondialisation des tâches informatiques . . . . . . . . . . . . . . . . . . . . . . . . 7

Délocalisation informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

La recherche de la compétitivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Offshore, outsourcing, délocalisation et développements distribués . . . . . . . . . . . . . . . . . 11

L’offshore sans perte d’emploi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Gestion des équipes offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Les avantages de l’outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Les coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

La gestion des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

La qualité des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Les processus structurés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Les tests et la qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Attribution de rôles aux personnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapitre 2 – Les chemins de l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Les développements onsite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Le personnel en régie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Les développements offsite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Les développements offshore et nearshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Éloignement des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Table des matières

Livre Offshore.book Page VII Lundi, 21. février 2005 7:44 19


VIII

La langue de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Les différences culturelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Comprendre les mentalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Gérer les projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Le syndrome du poulet bien gras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Les pays de l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Des salaires faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Inde, Europe de l’Est, Asie et Maghreb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Niveaux de coûts et seuils limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Universités et marques d’éducation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

La stabilité politique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Les prestataires offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Les géants de l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Les multinationales de l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Les leaders en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Les petits prestataires offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Les prestataires dédiés à un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Évolution des pays de l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Les collaborateurs des prestataires offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Les développements informatiques dans les pays de l’offshore . . . . . . . . . . . . . . . . . . . . . 52

Les informaticiens et l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

La mesure des coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapitre 3 – Les collaborateurs locaux et en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Les informaticiens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Centre de coûts ou d’investissement ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Remplacer l’irremplaçable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Transmettre le savoir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Documenter les projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Ajuster les salaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Spécialiser les rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Présentation de l’externalisation auprès des équipes locales . . . . . . . . . . . . . . . . . . . . . . 64

Le travail en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Les motivations des informaticiens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Livre Offshore.book Page VIII Lundi, 21. février 2005 7:44 19

IX

Table des matières

Le salaire des informaticiens en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Le statut des collaborateurs en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Les conditions de travail chez le prestataire offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Inviter des collaborateurs à travailler chez le client . . . . . . . . . . . . . . . . . . . . . . . 77

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Chapitre 4 – Les modes de fonctionnement de l’offshore . . . . . . . . . . . . . . . . . . . . . . . . 79

Le montage des équipes en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Le prestataire au forfait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

La filiale en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Le prestataire offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Le joint-venture en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Comparaison des différents partenariats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Les modes de gestion des équipes outsourcées . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Importance de la localisation du prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Le projet au forfait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

La régie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

La régie forfaitée et plafonnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Choisir le bon mode de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapitre 5 – Choisir le projet à externaliser en offshore . . . . . . . . . . . . . . . . . . . . . . . . . 97

Les éléments structurants des projets en offshore . . . . . . . . . . . . . . . . . . . . . . . . 97

La documentation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Indépendance du projet à l’égard des influences externes . . . . . . . . . . . . . . . . . . . . . . . 101

Compréhension fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

La complexité technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Validation par le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Le premier projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Un petit projet de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Un module périphérique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Un projet ambitieux comme premier projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Typologie des projets pour l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Projet de reverse-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Grand projet correctement spécifié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Projet lié à des développements chez le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Livre Offshore.book Page IX Lundi, 21. février 2005 7:44 19


X

Petit projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Projet de fondations techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Tour d’horizon des types de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Chapitre 6 – Les risques de l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Le partenaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Les litiges en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Protection de la propriété intellectuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Propriété du code source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Rétention des sources en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Arrêt des prestations en situation de conflit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Utilisation de bibliothèques de programmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Fractionnement du code source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Confidentialité des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Les informations confidentielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Isolement des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Les fuites chez des concurrents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Protection de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Augmentation brutale des coûts des prestations . . . . . . . . . . . . . . . . . . . . . . . . 127

Monter deux équipes en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Les paiements du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Les retards de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Les risques politiques locaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Les licences des outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Les licences apportées par le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Retrait des protections des logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Les risques sociaux chez le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Partie 2 – Préparation des projets en offshore

Chapitre 7 – Évaluer son projet pour l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

La position du responsable R&D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Les objectifs du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Définition des budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Livre Offshore.book Page X Lundi, 21. février 2005 7:44 19

XI

Table des matières

Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Le projet de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Choix du projet de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Démarrer avec un vrai projet important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Définir les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Choix des managers de l’offshore chez le client . . . . . . . . . . . . . . . . . . . . . . . . . 145

Placer un représentant du client chez le prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Se faire accompagner pour démarrer l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Méthodologie et procédures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Formation et conseil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Outils de suivi de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Chapitre 8 – Choisir le prestataire et les équipes offshore . . . . . . . . . . . . . . . . . . . . . . 153

Critères de choix du prestataire en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Localisation du prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Décalage horaire et distance géographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

La culture du pays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Le système éducatif en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

L’offshore dans la durée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Deux prestataires en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Choisir le prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

La demande d’informations au prestataire offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Les principaux éléments de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Les références du prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Le contrat de partenariat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Relations avec le partenaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Constitution des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

L’embauche des collaborateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Les formations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Chapitre 9 – Le contrat avec le prestataire offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Considérations générales sur le contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Validation du contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Livre Offshore.book Page XI Lundi, 21. février 2005 7:44 19


XII

Le préambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Utilisation ultérieure du contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

La propriété intellectuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Réutilisation d’éléments appartenant au prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Protection d’éléments appartenant au client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Introduction d’éléments appartenant à des tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Réutilisation de code personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Protection contre la concurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Non-respect des règles de confidentialité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Les services du prestataire offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

La langue de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Prestations de base et services complémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Devise de facturation et risque de change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

L’unité de facturation des prestations de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Les sous-projets au forfait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Facturation des collaborateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Les services complémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Gestion des factures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Les termes de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Paiement sans délai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Paiements partiels des factures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Pénalité de retard de paiement du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Rétention de paiement et suspension de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Les augmentations de tarif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Gestion des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Précautions quant au statut des collaborateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Le statut d’employé du prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Constitution des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Flexibilité des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Isolement des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Le montant des salaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Promotions et réorganisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Les employés à temps partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Les doubles emplois des collaborateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Livre Offshore.book Page XII Lundi, 21. février 2005 7:44 19

XIII

Table des matières

Mise en place et suivi de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Imposer ses procédures au prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Les rapports de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Le suivi de projet au forfait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Communication et références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

La rupture du contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Protéger la propriété intellectuelle au-delà du partenariat . . . . . . . . . . . . . . . . . . . . . . 207

Arbitrage et médiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Partie 3 – Gestion des projets en offshore

Chapitre 10 – Les points clés de la gestion de projet en offshore . . . . . . . . . . . . . . . . 211

La satisfaction du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Garder une vision claire des objectifs de management . . . . . . . . . . . . . . . . . . . 213

Transparence de la communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Gestion des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Recherche de la qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Procédures utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

La méthode itérative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

De petites équipes couvrant tous les domaines . . . . . . . . . . . . . . . . . . . . . . . . . 224

Responsabiliser l’offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Gestion des tâches clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Chapitre 11 – Gestion des ressources humaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Identification des profils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Distribution des responsabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Petites équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Rôles des collaborateurs d’une équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Partager la responsabilité et rendre compte de son rôle . . . . . . . . . . . . . . . . . . . . . . . . 232

Donner le pouvoir de décision aux collaborateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Favoriser les initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Mentors et rôles centraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Livre Offshore.book Page XIII Lundi, 21. février 2005 7:44 19


XIV

Communication avec le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Communications défectueuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Questions d’ordre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Chef de projet et petits projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Les primes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Primes démotivantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Primes collectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Primes pour travail exceptionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Les malus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Chapitre 12 – Processus et méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

La méthodologie et les hommes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Choix de la méthodologie et des outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

La méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Le référentiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Gestion du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Gestion des flux (workflow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Gestion des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Gestion de la documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Mise en place de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Le planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Gestion des corrections et des nouveaux développements . . . . . . . . . . . . . . . . . . . . . . . 256

Release, Service Pack, patch et Hot Fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Le release plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Plan de développement et charge des itérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Le planning détaillé de l’itération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Analyse de l’itération terminée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Valider la réalité des réalisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Intégration continue et périodique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Les tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Automatisation des rapports de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Livre Offshore.book Page XIV Lundi, 21. février 2005 7:44 19

XV

Table des matières

Chapitre 13 – Gestion des tests et de la qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Les tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Les tests fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Les tests minimaux, ou MAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Juger de l’état de qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Les tests fonctionnels transversaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Les tests intuitifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Enrichissement des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Les tests techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Couverture des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Les tests de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Tests et mesure du risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Chapitre 14 – Intégration et déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Gestion des plates-formes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Fondations techniques et procédures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Le déploiement chez le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Les tests chez le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Supervision des plates-formes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Préparation des livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Chapitre 15 – Suivi de l’équipe offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Rappels sur le suivi de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Les mesures univoques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Les visites au prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Les documents de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Définition des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

L’itération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Les plannings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

La qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Le rapport d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Les documents organisationnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Les documents administratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Livre Offshore.book Page XV Lundi, 21. février 2005 7:44 19


XVI

Mesure des économies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Automatisation des documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

La sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Partie 4 – Annexe

Modèles et exemples

Évaluation du projet offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Rapport de facturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Points à considérer dans un contrat en mode régie . . . . . . . . . . . . . . . . . . . . . . 314

Suivi des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Suivi des décisions en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Iteration assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Planning détaillé d’une itération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

La feuille de recette (Acceptance Sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Mesure des économies réalisées en offshore . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Livre Offshore.book Page XVI Lundi, 21. février 2005 7:44 19

1

Avant-propos

Depuis que l’informatique sert le monde des entreprises, la réalisation de projets infor -matiques a toujours été une discipline complexe et coûteuse. La construction d’un logi-ciel consomme une quantité importante de main-d’œuvre très qualifi ée, comptant biensouvent des ingénieurs provenant d’écoles prestigieuses exigeant des rémunérationsélevées. Les projets de développement de logiciels dépassent la dizaine d’années/homme,voire la centaine, et représentent des investissements considérables.

Lorsqu’un projet informatique est poursuivi, on découvre que les utilisateurs ont d’autresbesoins, changent d’avis ou qu’il est nécessaire de prendre en compte de nouvelles évolutionstechnologiques, avant même que le projet soit livré en première version. Ces évolutionssont parfois si importantes qu’elles s’apparentent à un nouveau départ du projet. D’autresprojets consistent à saisir une occasion de marché, souvent liée à la réponse à un appeld’offres dont le livrable est attendu à une date pour le moins optimiste. Quelles quesoient ses motivations, le responsable de projet a intérêt à livrer dans le laps de temps leplus court.

Pour réaliser un tel projet, il faut disposer des ressources convenables, ce qui est rare-ment le cas. L’embauche de nouveaux collaborateurs engage l’entreprise à long terme,alors même qu’elle n’a pas suffisamment de visibilité pour être certaine d’avoir besoin deces ressources une fois le projet terminé. Quant à l’emploi local de personnel en régie, ilest extrêmement coûteux. Ce sont pourtant les solutions auxquelles on a traditionnelle-ment recours.

La réalisation de projets en offshore apporte une dimension nouvelle à la gestion desprojets informatiques. Avec ce mode de travail, le responsable du projet peut réduiresignificativement les coûts de réalisation et mettre à la disposition du projet des informa-ticiens qualifiés, tout en bénéficiant d’une grande flexibilité de la taille de l’équipe, tantpour l’accroître que pour la réduire.

Un tel résultat n’est toutefois pas facile à atteindre, et les pièges sont légion. Nombre desociétés s’y essayent, mais rares sont celles qui en retirent tous les avantages, certaineséchouant purement et simplement. Celles qui parviennent à travailler avec un prestataireen offshore constatent une productivité si faible qu’elles n’en tirent pratiquement aucuneéconomie. Certaines sociétés ne parviennent pas à obtenir une production distante fiableet font continuellement face à des problèmes de qualité ou de retard, qu’elles ne parviennentpas à surmonter.

Pour bénéficier pleinement des avantages de l’offshore, il faut apprendre à travailler avecun partenaire issu d’une autre culture et oublier partiellement l’expérience acquise avecdes partenaires occidentaux. Il faut en outre se montrer capable d’apporter une rigueur

Livre Offshore.book Page 1 Lundi, 21. février 2005 7:44 19


2

nouvelle dans les réalisations afin de structurer les procédures et les échanges. Un modede travail satisfaisant avec des informaticiens internes est rarement transposable à desréalisations réparties.

La réalisation de projets en offshore est pourtant une évolution naturelle de l’informa-tique. Les avantages que l’on en retire sont stratégiques pour la plupart des entreprises.Ils peuvent changer la dynamique des sociétés et révéler une nouvelle compétitivitépermettant de saisir des occasions jusque-là inatteignables. Des projets auparavant jugéstrop coûteux ou trop risqués deviennent envisageables et peuvent être lancés. À l’opposé,les sociétés qui ne parviennent pas à maîtriser les développements en offshore travaillentsur une échelle de coûts sans commune mesure et subissent la rigidité de leursressources.

Le travail avec une équipe en offshore bénéficie à tous, y compris aux informaticiens dudonneur d’ordres, contrairement aux idées reçues. La nature de leur travail peut certess’en trouver modifiée, ne serait-ce que pour s’adapter aux processus industriels. Lestâches de supervision, de management et d’architecture, par exemple, y prennent plusd’importance.

Lorsque les réalisations en offshore sont bien gérées, la société dégage davantage demoyens financiers, qui apportent un certain confort aux développements locaux.

Objectifs de l’ouvrage

Cet ouvrage a pour objectif d’aider les sociétés à réussir leurs projets en offshore. Ilrassemble l’expérience de plus de douze années de réalisations en offshore dans denombreux pays et avec de multiples prestataires.

L’ouvrage commence par présenter la culture du développement en offshore et insiste surla distance qui sépare le travail en local et celui en offshore. Ces différences culturellesnécessitent une grande rigueur de la part du client de l’offshore pour suivre et piloter lesréalisations à distance.

La perception qu’ont les collaborateurs du donneur d’ordres du travail de leur sociétéavec un prestataire offshore est une autre difficulté à affronter. Pour réussir l’outsourcingdes développements en offshore, il est essentiel de comprendre les raisons de leursinquiétudes. Ces dernières vont bien au-delà d’une simple peur de perdre leur emploi auprofit d’un informaticien distant moins coûteux.

Une fois les fondations de l’offshore posées, l’ouvrage accompagne le donneur d’ordrestout au long des nombreux choix qu’il doit faire, depuis la sélection d’un prestatairejusqu’à la mise en place de l’organisation qui lui permettra de travailler effi cacement aveclui, à commencer par le contrat.

Vient ensuite la gestion proprement dite des projets en offshore. Certaines pratiquespréconisées dans l’ouvrage ne sont pas propres à l’offshore et font la preuve de leur effi -cacité dans les projets répartis ou locaux. Leur mise en œuvre devient toutefois pratique-ment incontournable lorsqu’on travaille avec des équipes distantes.


Avant-propos

3

Organisation de l’ouvrage

L’ouvrage est structuré en quatre parties :

Partie I. Les principes de l’outsourcingCette partie présente les grands principes qui président à l’externalisation des dévelop-pements informatiques en offshore. Elle met en lumière les différences culturelles, tropsouvent ignorées, entre les pays de l’offshore et ceux du donneur d’ordres.

• Chapitre 1. Introduit la mondialisation des tâches informatiques, qui prend souventle nom de développements offshore, et son impact sur les métiers du logiciel.

• Chapitre 2. Présente et compare les différentes approches qu’une société peut envi-sager pour externaliser ses projets informatiques.

• Chapitre 3. S’intéresse au facteur humain des projets offshore, tant chez le donneurd’ordres, où l’on s’inquiète toujours de l’externalisation, que chez le prestataire.

• Chapitre 4. Étudie les modes de fonctionnement des projets réalisés en offshore,notamment les réalisations au forfait ou en mode régie, et leurs effets sur le suivi deprojet.

• Chapitre 5. Dresse une typologie des projets qui sont confiés en offshore et soulignel’importance du premier projet pour prendre la mesure des difficultés que l’onrencontre.

• Chapitre 6. Traite des risques réels ou supposés pris par le donneur d’ordres enconfiant des projets en offshore et insiste sur les effets négatifs des préjugés et d’uneinquiétude exagérée sur leur succès.

Partie II. Préparation des projets en offshoreCette partie traite des choix que le donneur d’ordres doit effectuer pour sélectionner leprestataire en se donnant les meilleures chances de succès et pour organiser le travailavec celui-ci.

• Chapitre 7. Présente les différents types de projets que l’on peut confier à un presta-taire offshore et montre toute l’importance du premier projet pour que le prestataire etle client apprennent à se connaître.

• Chapitre 8. Aborde les critères de choix du prestataire offshore susceptibles derépondre aux ambitions du client.

• Chapitre 9. Introduit les fondations du contrat qui lie le donneur d’ordres au presta-taire offshore et montre comment formaliser un cadre strict permettant de travailleravec efficacité.

Partie III. Gestion des projets en offshoreCette partie traite des principes clés de la gestion de projet en offshore et propose unesérie de recommandations pour garantir la transparence et le suivi effi cace des dévelop-pements distants.

• Chapitre 10. Détaille les fondamentaux de la gestion de projet en offshore et proposeplusieurs façons de les mettre en œuvre.

• Chapitre 11. Traite de la façon de gérer les ressources humaines, facteur clé de la réus-site des projets offshore, afin de garantir des échanges fluides et de créer un climat deconfiance réciproque entre le client et le prestataire.



4

• Chapitre 12. Présente la méthode et les procédures à mettre en place pour tout à lafois structurer le travail avec le prestataire, assurer la productivité des équipes etfournir les principales sources d’un suivi rigoureux.

• Chapitre 13. Introduit la gestion de la qualité permettant de disposer non seulementd’une qualité contrôlée, mais aussi d’une visibilité de l’état de finition du projet.

• Chapitre 14. Aborde les sujets trop souvent délaissés de l’intégration et du déploieme nt,qui conditionnent la fluidité des livraisons de l’offshore et l’efficacité des supervisionsà distance.

• Chapitre 15. Traite du suivi du travail de l’équipe distante en utilisant les indicateurset les éléments fournis par la méthodologie mise en place.

Partie IV. Annexe

• Cette partie rassemble des listes de points permettant de synthétiser les recomman-dations faites tout au long de l’ouvrage afin que le lecteur puisse s’en servir commeaides à la décision. Elle propose en outre des modèles de documents illustrant lesthèmes abordés dans l’ouvrage.

À qui s’adresse l’ouvrage ?

Cet ouvrage s’adresse à toutes les personnes concernées par les projets offshore ou quis’intéressent à ce sujet. Les lecteurs qui n’ont pas encore d’expérience de travail avec unprestataire en offshore y trouveront des recommandations leur permettant de s’y préparerefficacement et d’augmenter les chances de réussir leurs projets. Ceux qui travaillent déjàavec un prestataire offshore pourront identifier des optimisations et les sources decertains dysfonctionnements.

Les dirigeants d’entreprise trouveront les informations leur permettant de comprendreles mécanismes de l’offshore et ses risques et de mesurer les avantages que leur sociétépeut en retirer. Les informations fournies leur permettront de définir l’organisation àmettre en place en tenant le plus grand compte de la distance qui sépare leur mode defonctionnement courant de celui qui est nécessaire en offshore.

Les managers d’équipes informatiques pourront appréhender l’organisation de leurscollaborateurs pour obtenir un fonctionnement fluide et efficace avec un prestatairedistant. Ils pourront également identifier les sources des dysfonctionnements et la façond’y remédier.

Les informaticiens, qu’il s’agisse de chefs de projet, de développeurs, de testeurs, d’archi-tectes, d’analystes ou d’intégrateurs, pourront identifier la place que tient leur rôle dansle contexte de l’offshore et les postes à fort potentiel. S’ils travaillent déjà sur des projetsoffshore, ils en tireront bénéfice pour améliorer la productivité et la fluidité des opéra-tions. Les informations fournies dans l’ouvrage leur permettront d’être plus rapidementefficaces et d’éviter certains pièges.


PARTIE 11Les principes

de l’outsourcingPour le client de l’offshore, les choses se présentent on ne peut plus simplement.Il cherche des ressources compétentes et flexibles afin de pouvoir adapter lataille de ses équipes à ses besoins tout en bénéficiant d’une économie impor-tante. Cette économie doit lui permettre de saisir des occasions, dont il nepourrait profiter autrement.

Lorsqu’on commence à travailler avec une équipe en offshore, on aborde unmode de fonctionnement différent de ce dont on a l’habitude, et ce, pour deuxraisons essentielles. La première est que la culture comme les lois etl’économie de ces pays sont très éloignées de ce que l’on pratique localement.La seconde raison est que le travail à distance crée des difficultés qui deman-dent davantage de rigueur et de contrôle sur les réalisations. L’expérience quele client peut avoir dans son pays ne lui est que de peu d’utilité pour réussir sesprojets en offshore.

Cette première partie traite principalement des différences culturelles que l’onconstate entre les pays de l’offshore et leurs clients des pays occidentaux dansle domaine des réalisations informatiques. Ces différences doivent être biencomprises si l’on veut profiter des avantages de l’outsourcing sans risquer desombrer sous les difficultés.

Les pays occidentaux sont habitués à une économie stable économiquement,socialement, légalement et fiscalement, qui découle d’ajustements répétés aulong des années et d’une recherche de la justice. Les pays de l’offshore, quioffrent des niveaux de coûts des prestations humaines beaucoup plus faibles,n’ont jamais connu une telle stabilité. On y observe des revirements violentsdans les domaines politiques et sociaux, qui font parfois la une des journaux.

Ces pays sont différents des nôtres. Ils sont en formation, et leurs modèleséconomiques se cherchent. Leurs entrepreneurs suivent le plus souvent la voiela plus facile et tirent parti des lois inexistantes, généralement inadaptées, et



6

surtout des pratiques, qui évitent les fiscalités contraignantes. La complexité de certainesde ces économies, notamment en relation avec l’informatique et Internet, ne se traduitpas toujours par les lois qui conviennent. De toute façon, nombre de lois ne sont pasappliquées.

Les différents régimes politiques en place ont en commun d’avoir délaissé le droit dutravail et la protection de la propriété intellectuelle. Dans certains pays, l’économie paral-lèle dépasse de loin en ampleur le marché officiel.

Pour toutes ces raisons, les occasions à saisir en offshore sont immenses. Les droitsd’entrée sur de nombreux marchés sont très faibles. Dans les pays qui profitent d’un bonniveau d’éducation scientifique, la fourniture de prestations informatiques en offshore enfait partie. On y observe cependant tous les défauts d’un marché en formation. La dispa-rité des fournisseurs de services est immense, depuis les vrais professionnels jusqu’àceux qui saisissent leur chance sans disposer d’aucune expérience.

Si l’Inde a atteint une grande maturité dans la prestation de services informatiques, avecdes prestataires qui emploient jusqu’à dix mille personnes, la majorité des pays de l’offshorese cherchent encore. Ils ne savent pas très bien comment organiser le travail pour queleurs excellentes ressources répondent à la pression de la demande étrangère.

Dans cette partie, nous essayons de montrer ce qu’est réellement le travail en offshore.Nous insistons sur les préjugés des clients comme sur les différences culturelles quipeuvent mettre en péril ses réalisations distantes. En matière d’outsourcing, tous les projetsne sont pas équivalents, tant s'en faut. Savoir choisir ses projets et anticiper les problèmesest la clé du succès.

La deuxième partie de l’ouvrage traite de la préparation des projets en offshore, en insis-tant sur le contrat qui lie le prestataire et le client. La troisième partie est consacrée autravail avec le prestataire en offshore.


7

Chapitre 1

La mondialisation des tâches informatiques

Quel que soit le domaine que l’on observe, les économies engendrées par l’outsourcing,aussi appelé offshore ou délocalisation, sont considérables. Les différences de prix sontimmédiatement visibles lorsque des produits locaux sont en concurrence avec desproductions délocalisées. Quel que soit le domaine, confection, automobile, fabrication,assemblage, etc., la délocalisation bouleverse en profondeur la façon dont fonctionnentces industries.

Longtemps, la pratique de la délocalisation a été considérée comme une marque dequalité inférieure. Ce qui était fabriqué en Chine, à Taïwan, par exemple, était considérécomme moins solide, plus fragile, moins bien fini et donc moins durable. Lorsqu’on recher-chait la qualité, on regardait la mention Made in China comme une marque de fragilité etles mentions Made in USA, Made in Germany ou Made in France comme des marques de qualité.La mention Made in France suggérait en outre que l’on aidait l’économie nationale en ache-tant un produit fabriqué en France et utilisant une main-d’œuvre française. Certains étaientprêts à acheter plus cher un produit a priori identique parce qu’il portait cette mention.

Ces temps sont révolus. L’image de qualité des labels de fabrication « exotiques » a changé .Dans de nombreux domaines, on considère désormais que certains produits fabriquésdans ces pays sont moins chers tout en offrant une qualité acceptable.

Ce chapitre donne un aperçu global de l’offshore et des principaux avantages qui s’atta-chent à ces réalisations distribuées. Certains sujets abordés sont détaillés dans la suitede l’ouvrage, comme les motivations de l’offshore, les façons de travailler avec des équipesen offshore, les pays de l’offshore ou les prestataires que l’on trouve dans ces pays.

Délocalisation informatique

La mondialisation touche aujourd’hui l’ensemble des domaines de l’informatique. Lesraisons à cela ne sont guère différentes de celles qui poussent les autres secteurs de laproduction à délocaliser : produire plus à budget constant, voire à budget réduit, produireplus rapidement pour arriver les premiers ou au meilleur moment sur les marchés les plusprofitables, saisir les occasions sur des marchés toujours plus éphémères.

Ces critères valent particulièrement pour la production du matériel informatique, des ordi-nateurs, des cartes informatiques et plus généralement de tous les matériels électroniques.



8

Plus personne aujourd’hui ne considère que cette production délocalisée est de qualitéinférieure. Les plus grandes marques, jouissant de la meilleure réputation de fiabilité etde qualité, fabriquent en grande partie leurs matériels dans les pays où la main-d’œuvreest moins chère. Dans ce domaine du matériel informatique, la concurrence est telle queles marges font l’objet d’une attention extrême à toutes les phases de fabrication, dutransport et de la distribution. L’objectif est de conserver à toutes les étapes un niveau deprofitabilité tel que les revendeurs finals, les fabricants et les concepteurs disposent d’unproduit compétitif et d’une marge suffisante.

Personne ne s’attend à trouver la mention Made in France sur un ordinateur, un modemou une carte informatique. Tout au plus, trouve-t-on les mentions Assemblé en France surcertains matériels. On aurait même plutôt tendance à considérer qu’une fabrication localeserait de qualité inférieure, car on ne pourrait y trouver les économies d’échelle et larigueur des procédures qui sont appliquées dans les pays qui se sont spécialisés dans cesfabrications.

La fabrication de matériel informatique égratigne au passage une idée reçue voulant que lamondialisation ne touche que des domaines à faible qualification. L’informatique néces-site en effet une main-d’œuvre qualifiée dans des domaines de pointe, où l’évolution techno-logique est extrêmement rapide et la qualité un critère essentiel. Ceux qui pensent queles ressources offshore ne peuvent rivaliser en connaissances, compétences et créativitéavec les ressources des États-Unis ou des pays de l’Europe de l’Ouest ont clairement tort.

Dans l’industrie du logiciel, la créativité ou même la simple présence d’une offre fonction-nelle a longtemps prévalu sur la comparaison des prix. Parfois, on considérait que tellogiciel de comptabilité était le meilleur pour un type d’activité donné, et l’on achetait leproduit choisi. Cette situation change, et le monde du logiciel arrive lentement à matu-rité. Les fonctionnalités dont les utilisateurs ont besoin se stabilisent et sont souventoffertes de façon similaire dans tous les produits. Les éditeurs de logiciels ont eu le tempsde comparer leurs produits à ceux de la concurrence et d’en adopter les meilleures idées.

Critères de comparaison

La capacité à comparer directement des produits de plus en plus semblables, notammentdans le domaine du logiciel, rend le facteur prix déterminant. L’outsourcing devient dès lorsle moyen d’atteindre une production aux meilleurs coûts.Des produits très différents étant difficiles à comparer, on s’attache parfois à des critèressubjectifs, tels que l’esthétique. La comparaison purement financière est en ce cas peusignificative. Par exemple, le caractère très particulier des automobiles Morgan fabriquéesau Royaume-Uni interdit de comparer leur prix à celui des voitures de grande série.D’une façon comparable, l’appréciation d’un bijou se fonde davantage sur une évaluationartistique que sur la comparaison des prix, même si ceux-ci ont une grande importance.L’attachement est ici avant tout émotionnel.Lorsque les produits se standardisent, que les sujets d’évaluation sont comparables pointà point et qu’on peut mesurer une distance entre les produits, leur coût devient l’un des critè-res essentiels d’achat. On trouve dans cette catégorie les ordinateurs portables, les cartesgraphiques ou les cartes-mémoires. Les différences techniques et fonctionnelles sontnaturellement estimées comme justifiant la différence de coûts ce produit ne fait pas ceciet cela mais est moins cher de tant , mais l’acheteur porte la plus grande attention aux coûts.


Chapitre 1 – La mondialisation des tâches informatiques

9

La créativité fonctionnelle des produits est de moins en moins laissée aux équipes infor -matiques et est prise en charge par des responsables fonctionnels (chefs de produit,représentants des utilisateurs, etc.). Ces derniers savent analyser et mesurer les besoinsdes utilisateurs afin d’identifier ce qui fait vendre un produit. Les informaticiens restentencore créatifs, mais le plus souvent à un niveau technique, concernant, par exemple, lesarchitectures logicielles, certaines procédures ou les moyens de parvenir à une meilleurequalité. Même les sujets réputés très techniques relatifs aux frameworks de dévelop-pement ont tendance à se standardiser et laissent moins de place à l’inventivité des infor-maticiens.

Comme cela s’est produit il y a quelques années pour le matériel informatique, on assisteà une concurrence acharnée entre les logiciels. Les logiciels de gestion des notes de frais,de la trésorerie ou des immobilisations ou les serveurs EJB devenant directement compa-rables entre eux, les coûts et la réactivité constituent des éléments de comparaisonessentiels dans les décisions d’achat. On peut imaginer qu’il y aura un gagnant à cesconfrontations. Celui-ci pourrait par la suite devenir un standard du marché, commeMicrosoft avec ses suites Office ou Adobe avec Photoshop.

Les développements informatiques réalisés par les sociétés de services sont soumis auxmêmes tendances. On considère que les réalisations d’un prestataire ou d’un autre sontassez comparables, la différence résidant surtout dans la capacité du prestataire àaccepter et garantir les conditions contractuelles (délais et qualité). Dans ce cas aussi,l’on s’attache à comparer les coûts, et l’on recherche une justification mesurable aux diffé-rences de prix.

La plupart des produits développés aujourd’hui ne sont que de nouvelles versions deproduits préexistants. Ils ne comportent le plus souvent que des évolutions techno-logiques — on souhaite les mêmes fonctionnalités, dont on est content, mais utiliséesavec des technologies plus modernes — ou n’implémentent que des ajouts fonctionnelsmineurs et des corrections d’anomalies (maintenance applicative) d’une application donton est globalement satisfait et qui est utilisée tous les jours. Dans la plupart des cas,l’objectif est bien défini, et le coût de la réalisation de cet objectif est un élément capitalde décision.

Terminologie employée dans cet ouvrage

Dans le cours de cet ouvrage, les termes offshore, développements distribués ou distants,externalisation et outsourcing sont considérés comme synonymes. Compte tenu du sujetmême de l’ouvrage, l’offshore désigne la sous-traitance d’un développement informatiquedans un pays éloigné. Nous soulignons explicitement les cas où le terme prend une autresignification, par exemple en cas d’externalisation locale dans le pays du donneurd’ordres.Le terme local est relatif au lieu du donneur d’ordres, que ce soit son pays ou les locaux desa société, tandis que les termes distant, délocalisé et offshore sont employés en référenceau pays du prestataire en offshore ou à ses locaux.Les termes client ou donneur d’ordres désignent la société qui fait appel aux services duprestataire en offshore. Le terme prestataire désigne la société en offshore qui fournit desservices informatiques en offshore aux sociétés généralement situées dans les pays d’Europede l’Ouest ou aux États-Unis. Dans quelques cas rares, nous employons le terme client pourdésigner les clients du donneur d’ordres d’une façon qui sera sans équivoque pour le lecteur.



10

La recherche de la compétitivitéLes éditeurs de logiciels, comme les sociétés de services, sont entrés dans une ère où lacompétitivité de leurs services et produits est le moteur essentiel du profit. Les dévelop-pements informatiques requièrent des ressources souvent importantes et emploient unemain-d’œuvre qualifiée et recherchée, au coût élevé.

Un projet informatique se chiffre en année/homme (une année d’un homme). Il n’est pasrare que certains projets dépassent la cinquantaine d’années/homme lorsqu’on intègreles tâches en amont du développement (élaboration de la vision, spécifications et prépa-ration du projet) et les tâches en aval (test, déploiement, performance et maintenancecorrective et évolutive).

Si l’on considère en première estimation qu’une année/homme de développement enFrance revient, tout compris, à 75 000-100 000 euros par an, un projet de dix années/homme coûte entre 750 000 et 1 000 000 euros. Si l’on peut réduire ces coûts de 40 % ce qui correspond au taux de réduction moyen du coût d’un projet réalisé en offshoreconstaté aux États-Unis , on peut espérer 300 000 à 400 000 euros d’économie.

Une société de services peut trouver dans cette réduction des coûts un nouveau soufflepour remporter des marchés, parfois même en augmentant sa marge propre. L’économieréalisée par une société qui fait appel à l’offshore peut ne pas être totalement répercutéesur le coût des prestations facturées à son client. Elle peut, par exemple, être partagéeentre une réduction du coût de la prestation pour se positionner de façon plus agressiveet une augmentation de la marge.

EN RÉSUMÉL’offshore, compétitivité et réactivité

Les sociétés qui développent des logiciels peuvent trouver un nouveau souffle en faisant appel auxressources de l’offshore pour réaliser leurs projets. Le différentiel de coûts est tel que ces sociétéspeuvent y puiser une nouvelle dynamique les rendant tout à la fois plus compétitives et plusréactives.

Terminologie employée dans cet ouvrage (suite)

Le terme régie s’oppose à forfait. La régie désigne une sous-traitance, le plus souventaccompagnée d’une facturation du temps passé et d’une refacturation des dépensesengagées (time and materials). La responsabilité du projet revient essentiellement au client,qui délègue les tâches de la façon qui lui convient et impose ses méthodes et son organi-sation. Le terme forfait suppose que le prestataire s’engage sur une réalisation à un tarifdéfini à l’avance, sur la base d’un document formalisé qui définit les engagements du pres-tataire de services. Une régie forfaitée désigne une coopération sur un mode régie. À l’inté-rieur de cette coopération en mode régie, certains sous-projets sont gérés au forfait.On conserve cependant le fonctionnement en mode régie, le client pouvant intervenir dansle cours du projet, y compris sur les parties au forfait.On appellera salaire chargé le salaire brut d’une personne augmenté de toutes les charges etdépenses directement liées au salaire pour l’employeur. On trouve ainsi le salaire brut, les char-ges sociales, les cotisations patronales diverses et le plus souvent les cotisations à la mutuelle.



11

Un éditeur de logiciel consacre habituellement entre 14 et 25 % de son chiffre d’affairesaux développements de nouveaux produits. Si, par exemple, il réalise un chiffre d’affairesde 15 millions d’euros, il consacre donc entre 2 100 000 et 3 750 000 euros à ses dévelop-pements. L’éditeur est le plus souvent en concurrence avec d’autres, qui visent la mêmecible et rivalisent de créativité et de réactivité. Celui qui délocalise ses développementsen offshore en réalisant 40 % d’économie voit ses capacités pratiquement doubler. Sacapacité à réaliser davantage de produits, plus rapidement et de meilleure qualité, caravec plus de tests, lui permet de mieux se positionner sur son marché et, dans le meilleurdes cas, d’y prendre des parts décisives.

Ce même éditeur qui réalise 15 000 000 euros de chiffre d’affaires peut donc investir, grâceà l’offshore, un budget de développement qui aurait représenté, s’il avait été réalisé enlocal, 3 500 000 à 6 250 000 euros. Sa puissance de production se situe entre 23 et 41 % deson chiffre d’affaires, alors que son investissement n’est que de 14 à 25 % de ce mêmechiffre d’affaires. Ces valeurs et pourcentages, évidemment considérables pour un éditeurde logiciel, montrent clairement le dynamisme de celui qui a su passer en offshore et enretirer tous les fruits.

Offshore, outsourcing, délocalisation et développements distribuésLa délocalisation des projets informatiques s’est tout d’abord appelée offshore par analogieavec les plates-formes pétrolières, qui sont situées loin de la rive, par opposition auxdéveloppements simplement externalisés, dits offsite. Le terme offsite désigne une exter-nalisation locale mettant à disposition des équipes de développement en régie ou auforfait. Le terme offshore situe clairement ces équipes dans un lieu lointain.

La figure 1.1 illustre le sens des termes onsite, offsite et offshore.

En révélant la distance qui sépare les équipes de production du donneur d’ordres, leterme offshore laisse supposer que le lieu où l’on choisit d’utiliser les ressources informa-tiques offre des avantages importants. Du fait des délocalisations massives, qui touchentdepuis quelques années certaines industries en s’accompagnant de milliers de pertesd’emplois, le terme offshore a acquis une connotation négative, associée à l’imaged’informaticiens licenciés au profit d’équipes distantes très peu coûteuses.

Figure 1.1. Onsite, offsite et offshore



12

Contaminé par de telles images, l’offshore a été trop vite associé à des manœuvres patro-nales visant le seul profit des actionnaires au détriment des employés qui, d’un coup, seretrouvaient hors jeu. Nous verrons que de telles attitudes, lorsqu’elles existent, sontsurtout répandues dans le monde de la fabrication et qu’elles concernent peu les projetsinformatiques. Nous verrons en outre comment, dans certains cas, l’offshore peut aucontraire être source de création d’emplois.

L’ampleur des développements confiés à l’offshore a retenu l’attention des grandes entre-prises de marketing qui vendent des études de marché. Constatant la montée en puissancede la délocalisation des projets informatiques, ces dernières ont non seulement mesurél’évolution des volumes des projets informatiques confiés à l’offshore mais également estiméles emplois perdus dans les années à venir au profit de l’offshore.

Certaines de ces études donnent des chiffres alarmants, avec 10 à 20 % du nombre totald’informaticiens européens, canadiens ou américains qui seraient perdus au profit despays de l’offshore. Le Canada, qui est souvent considéré comme un pays d’offshore pourles États-Unis, y apparaît comme doublement perdant : en tant que client d’offshoremoins compétitif que d’autres pays et en tant que donneur d’ordres, un certain nombred’entreprises canadiennes sous-traitant vers des pays moins coûteux.

Les politiques n’ont pas manqué de monter aux créneaux, notamment aux États-Unis etau Canada, pour jeter l’anathème sur une pratique jugée « antipatriotique » et d’exercertoutes sortes de pressions pour maintenir les développements localement. À l’opposé, leCSPP (Computer Systems Policy Project), un groupe de pression et de communicationaméricain réunissant les CEO (Chief Executive Officer) de HP, IBM, Intel, NCR, Unisys,Applied Materials, EMC et Motorola, défend l’usage des ressources en offshore. AlanGreenspan lui-même, directeur de la Réserve fédérale américaine, présente ouvertementl’outsourcing et la délocalisation comme des atouts pour l’économie américaine.

Selon le CSPP, l’offshore est l’unique solution pour être réellement réactif face auxbesoins du marché et fournir au plus vite le produit demandé par les utilisateurs (voirhttp://www.cspp.org/reports/ChooseToCompete.pdf). De plus, sans l’offshore, certains fleuronsde l’industrie américaine seraient moins compétitifs et risqueraient de perdre leur positiondominante.

Les aspects positifs de l’offshore ne sauraient certes faire oublier certaines dérives, consta-tées notamment dans la fabrication des vêtements et des chaussures. Dans de nombreuxcas, la pratique des ressources en offshore s’apparente davantage à l’esclavagisme qu’à ladélocalisation, et il n’est pas rare que de jeunes enfants travaillent dans des usinesoffshore.

L’initiative pro-offshore

Le Computer Systems Policy Project se fait l’avocat de l’utilisation de l’outsourcing afin depermettre à l’industrie américaine de rester compétitive, réactive et concurrentielle. Ildéfend l’idée que l’offshore permettra à terme de conserver et de créer plus d’emplois auxÉtats-Unis et que l’interdiction de l’offshore conduirait à une protection artificielle desemplois qui serait suivie de pertes d’emplois après que les entreprises auront perdu leurposition concurrentielle.


http://www.cspp.org/reports/ChooseToCompete.pdf


13

L’image d’une exploitation honteuse des ressources humaines s’est hélas peu à peu atta-chée au concept même d’offshore, alors même que, dans le cas de l’informatique, cesressources offshore sont mieux considérées, mieux rémunérées et mieux gérées quelorsqu’elles travaillent pour des entreprises du pays. En dépit de la réalité, l’offshoredemeure associé à des pratiques abusives dans l’esprit de bien des informaticiens.

Il convient d’ajouter que les échecs en offshore ont été nombreux et que l’on parletoujours plus des échecs que des succès. Les opérations en offshore qui n’ont pas échoué,mais dont les résultats ont été médiocres ou simplement décevants en comparaison desattentes, contribuent elles aussi à donner une impression globale négative de complexité,de médiocre qualité et de faible fiabilité.

Quant au grand public, il associe généralement l’offshore au montage de sociétés offshoreou à l’offshore banking, c’est-à-dire à l’utilisation de sociétés ou de banques dans des paysà la fiscalité différente permettant de mettre en place des optimisations financières auxlimites de la légalité. Ce double sens entache évidemment la perception du développe-ment offshore en lui associant la connotation de fiscalité laxiste, voire de blanchimentd’argent, même si les développements offshore n’ont aucun rapport avec ces pratiques.

EN RÉSUMÉL’offshore, meilleurs postes et meilleurs salaires

Dans les pays de l’offshore, les informaticiens considèrent que les meilleurs postes sont proposéspar les prestataires offshore. Ces derniers offrent les meilleures expériences professionnelles, lesmeilleurs salaires, les meilleures conditions de travail, et ces expériences sont celles qui sont le plusmises en avant dans les curriculum vitae des candidats aux recrutements.

Curieusement, le terme offshore n’est pas toujours mieux perçu dans les pays del’offshore. Dans ces pays, qui sont souvent émergents, et dont la fiscalité est mal définieet souvent contournée, ce mot peut avoir une connotation encore plus négative qu’enFrance. En effet, de nombreuses entreprises de ces pays travaillant avec l’étranger montentdes sociétés dans des pays encore plus favorables fiscalement pour y capter des fonds etne reversent à leur pays d’origine que les sommes dues aux employés, maintenant ainsiune optimisation fiscale des flux financiers. On se retrouve alors dans une situation où lesdeux sens du terme offshore (fiscal et pour les développements informatiques) sontmêlés, ajoutant encore à la confusion des termes.

Les autorités des pays de l’offshore tentent le plus souvent d’instaurer des conditionsfiscales plus favorables aux entreprises, afin que les revenus de l’offshore soient effective-ment captés par les pays où les prestations sont assurées, mais n’y parviennent que très mal.

Un vocabulaire mal défini

Pour toutes ces raisons, le terme offshore est souvent utilisé avec précaution, que ce soiten France ou dans les pays d’offshore, de peur de choquer ceux qui pourraient lui associerdes pratiques globalement négatives ou, pire encore, le confondre avec les pratiquesfiscales offshore.

De nombreuses sociétés préfèrent employer des expressions telles que développementsgéographiquement distribués ou outsourcing. L’ennui avec ces termes de rechange est que leconcept d’éloignement disparaît. On parle aussi parfois de délocalisation. Tous ces termesse rapportent en fait au même sujet et le plus souvent au même concept d’offshore.



14

L’outsourcing, le terme le plus employé, désigne le fait de trouver des ressources à l’exté-rieur, sous-entendu de l’entreprise. La nature des ressources « outsourcées » n’est pasprécisée. Dans l’esprit de beaucoup d’informaticiens, outsourcing est devenu synonymed’offshore, la connotation sulfureuse en moins.

Neutre et très générale, l’expression « développements géographiquement distribués »sous-entend que la distribution des développements peut être aussi bien internequ’externe, avec des sites de développement répartis à travers le monde. Elle est souventemployée par les éditeurs de logiciel, qui souhaitent rester le plus générique possible.Certains d’entre eux l’utilisent cependant pour désigner spécifiquement les développementsoffshore.

Enfin, le terme « délocalisation » est utilisé pour signifier une volonté d’externaliser desdéveloppements locaux.

Quels que soient les termes utilisés, ils renvoient le plus souvent au concept de dévelop-pement offshore.

L’offshore sans perte d’emploiC’est un fait que certaines sociétés déplacent massivement leurs ressources informa-tiques pour créer des équipes dans des pays d’offshore. Il est évident qu’en ce cas desemplois sont perdus dans le pays d’origine de ces sociétés au profit des pays d’accueil. Laplupart du temps, cependant, il s’agit moins de rechercher une délocalisation massiveque de bénéficier des avantages de l’offshore sans pour autant déstabiliser les équipesinformatiques locales, lesquelles fournissent des services sur lesquels on souhaite continuerde s’appuyer.

Le plus souvent, les sociétés françaises recourent à l’offshore, encore assez timidementfaut-il le préciser, soit pour valoriser leurs réponses aux appels d’offres, soit pour réaliserdes coups, comme sortir un nouveau module rapidement, ou minimiser des dévelop-pements périphériques, comme la création de rapports. Sur les marchés plus mûrs,comme le jeu ou certains utilitaires de grande diffusion, où la concurrence est forte et lesproduits assez semblables ou d’un coût plafonné, les éditeurs qui ont besoin d’optimiserleurs marges font plus volontiers appel à l’offshore.

Leur démarche, généralement progressive et prudente, est la suivante :

1. Une société apprend qu’un de ses concurrents commence à travailler efficacement avecl’offshore et en retire des avantages.

2. Elle constate que ce dernier emporte des contrats en réponse à des appels d’offres enparvenant à se positionner de façon suffisamment compétitive.

3. Elle réalise les occasions qu’elle a ratées du fait que ses effectifs étaient trop figés ettrop accaparés par les tâches courantes.

4. Elle parvient à la conclusion qu’il lui faut à son tour se tourner vers l’offshore, seulcapable de lui apporter l’oxygène nécessaire pour insuffler un nouveau dynamismedans l’entreprise.

Les sociétés qui adoptent cette démarche commencent par des développements offshoreau coup par coup, embauchent en France un chef de projet pour suivre le développementet parfois une équipe de recette. Les chefs de produit voient aussi parfois leur nombreaugmenter pour gérer les volumes accrus de spécifications des produits à réaliser en



15

offshore. Dans de nombreux cas, il n’est pas envisagé de réaliser ces développements eninterne ni en embauchant de nouvelles ressources.

Les réponses à certains appels d’offres sous-tendent donc dès le départ le recours àl’offshore. À l’inverse, le fait d’emporter un marché peut se traduire par un accroissementdes ressources locales de l’entreprise, laquelle pourra s’engager dans une stratégie plusagressive, dans le meilleur des cas accompagnée d’emplois supplémentaires.

Si l’offshore n’a pas pour vocation de supplanter les équipes locales, il s’accompagnesouvent d’une redistribution des tâches, surtout pour les projets importants. Par exemple,la maintenance d’applications est transférée à des équipes distantes, tandis que lesnouveaux projets sont conservés localement, afin d’assurer une meilleure réactivité faceaux demandes des clients par une plus grande proximité avec ces derniers.

Gestion des équipes offshoreLes prestations offshore peuvent prendre de nombreux visages. La plupart des entre-prises qui traitent en offshore travaillent avec un prestataire situé dans un pays favorableau montage d’équipes informatiques. Dans d’autres cas, l’entreprise s’établit elle-mêmedans un pays d’offshore pour y monter sa propre équipe. On rencontre enfin des sociétés,souvent très importantes, qui établissent une filiale dans un pays d’offshore pour enutiliser directement les ressources. Nous n’adressons pas dans cet ouvrage la problé-matique des multinationales qui créent une filiale importante en offshore, à l’image deMicrosoft, qui s’établit en Chine avec des milliers d’employés.

L’utilisation d’un prestataire offshore est le cas le plus commun et, à mon sens, le plussouhaitable. C’est assurément celui qui laisse le plus de liberté et de flexibilité à l’entre-prise cliente tout en entretenant une réelle relation de client à fournisseur. Il arrive quedes sociétés créent des joint-ventures avec des partenaires offshore, à l’exemple d’IBM auBelarus, qui traite avec des sociétés dans lesquelles elle a pris des participations signifi-catives. Ces sociétés créées en joint-venture traitent également avec d’autres clients pourproposer leurs services de développement.

Lorsqu’une entreprise crée sa propre filiale ou un joint-venture dans un pays offshore, ellecherche avant tout, outre de faibles coûts de prestation, à réduire au minimum la margedu partenaire. Ce choix peut aussi être motivé par la protection d’informations confiden-tielles ou relevant de la propriété intellectuelle ou encore par des motifs personnels dumanager qui gère le projet.

Les avantages de l’outsourcing

Les sociétés qui engagent des développements en offshore sont à la recherche d’arrange-ments qui soient à leur entier avantage. Dans certains cas, l’entreprise souhaite profitertout à la fois de compétences hors du commun, de coûts très faibles, d’une flexibilitétotale des équipes et d’une sécurité parfaite quant au succès du ou des projets.

S’il est possible d’atteindre de tels objectifs, encore faut-il trouver le bon prestataireoffshore, l’organisation qui lui convient le mieux, ainsi que les collaborateurs adéquats.Il faut en outre mettre en œuvre une gestion de projet telle que la progression du dévelop-pement soit transparente. Tout cela est loin d’être facile.



16

Les coûtsLes économies résultant de développements offshore sont réelles, mais, de l’avis dessociétés qui y recourent, c’est presque un avantage secondaire, comme nous le verronspar la suite.

La plupart des entreprises qui souhaitent se lancer dans l’offshore sans en avoir compristous les mécanismes s’arrêtent à ces considérations. On entend très souvent parler desalaires d’informaticiens dans les pays de l’offshore qui se situeraient aux alentours de120 à 300 euros par mois. Ces salaires semblent dérisoires en comparaison de ceux desinformaticiens français, supérieurs d’au moins un facteur 15. Un tel calcul est cependantfaux.

Dans la réalité, on s’aperçoit que les prestations informatiques offshore descendent rare-ment en deçà de 80 dollars par jour, soit 1 680 dollars par mois, et que les tarifs les pluscourants varient selon les prestataires et les pays entre 100 et 300 dollars par jour, soitentre 2 100 et 6 300 dollars par mois, parfois plus dans certains cas rares. Les prestationsoffshore sont en tout cas rarement tarifées à moins de 100 dollars/jour.

Le tableau 1.1 dresse une comparaison des ordres de grandeur des salaires locaux enFrance, des tarifs en régie des prestataires français et de ceux des prestations réalisées enoffshore.

Ce tableau est toutefois trompeur car il ne compare pas des services équivalents. Enoffshore, la tarification comprend le plus souvent le collaborateur, son espace de travailet son équipement (ordinateur, accès à Internet, administration des serveurs). Les tarifsde régie locaux et à l’offshore s’entendent par journée effectivement travaillée etn’incluent pas, à la différence du salaire d’un collaborateur français, les périodes devacances, qui augmentent le coût réel de la journée travaillée. Pour être comparé sur desbases équivalentes, le salaire français devrait donc être augmenté pour tenir compte descongés, des 35 heures, des absences pour maladie, ainsi que des autres coûts relatifs àl’employé dans l’entreprise, comme la mise à disposition de locaux, de services généraux,du nettoyage, etc.

Nous détaillons plus finement au chapitre 2 tous les éléments à considérer pour mesurervalablement les coûts.

Tableau 1.1. Comparaison des prestations journalières (en euro)

FonctionSalaire français

(chargé)Régie chez

un prestataire françaisPrestation offshore

(tout inclus)

Chef d’équipe 200-500 500-800 100-250

Chef de projet 180-400 400-700 100-250

Développeur confirmé 180-400 400-700 100-250

Intégrateur 150-250 350-500 80-200

Développeur débutant 150-200 350-500 80-150

Testeur fonctionnel 130-200 350-500 80-150



17

La comparaison des coûts d’un développement en offshore avec un développementnational est toujours complexe, car l’une des mesures est obligatoirement une estima-tion, tant que l’on ne mène pas effectivement deux développements identiques de front,l’un en France et l’autre en offshore. Cette comparaison est cependant recherchée par ladirection des entreprises.

Le plus simple pour mesurer le plus justement le coût des prestations offshore parrapport aux mêmes réalisations locales consiste à partir du coût homme « tout compris »de la R&D locale. Cela inclut, outre le salaire, les locaux, les avantages, les congés, lesservices centraux redistribués sur les employés, etc. On estime ensuite la durée/hommedu projet s’il avait été réalisé localement et, de façon à ne pas favoriser ce calcul pourl’offshore, on fait l’hypothèse qu’aucune difficulté ne serait venue alourdir le poids dudéveloppement en local, comme l’impossibilité de recruter à temps, par exemple. Oncompare alors le résultat obtenu aux coûts de l’offshore tout compris, incluant voyages,déplacements, chef de projet et équipes de recette locales, plus tous les frais de l’offshoretels qu’ils sont facturés, y compris les frais de location de bande passante Internet ou detéléphone.

On parvient généralement au résultat qu’un projet correctement géré en offshore génèreentre 20 et 80 % d’économies par rapport au même projet géré nationalement, avec uneespérance de gain moyenne de l’ordre de 40 %.

La gestion des équipesEn dépit des gains financiers importants évoqués à la section précédente, la flexibilité deséquipes offshore est sans doute l’un des bénéfices premiers de l’outsourcing.

Par le biais d’un prestataire en offshore, une société locale peut facilement constituer deséquipes importantes puis, selon les accords contractuels qu’elle a passés avec le presta-taire, les réduire à volonté. La rapidité de constitution de l’équipe dépend de l’importancedu prestataire offshore. Les prestataires suffisamment implantés en offshore n’ontaucune difficulté à prélever sur leurs propres personnels une équipe de base constituantenviron 20 % de l’équipe finale. Les prestataires bien exposés et qui maintiennent unebonne image dans leur pays peuvent facilement trouver des candidats de qualité pour les80 % restants. Une équipe d’une cinquantaine de personnes peut ainsi être montée enquatre à six semaines par un bon prestataire offshore, même si cette équipe comportecertains profils hors norme.

Le tableau 1.2 compare les différents moyens de créer et de gérer une équipe selon diffé-rents modes de travail, entre une embauche simple, un CDD et une régie avec un prestatairelocal ou en offshore.

Tableau 1.2. Flexibilité des équipes

Critère CoûtRapidité de constitution

Capacité à réduire l’équipe

CompétenceCapacité d’accueil

Embauche de l’équipe en CDI (local)

Normal (salaire en CDI)

Difficile Très difficile Normale à bonne Difficile si l’on ne dispose pas des locaux et de l’infra-structure pour re-cevoir le personnel.



18

Sans recourir à l’offshore, une société doit bien évaluer ses objectifs et les moyens dontelle dispose. Elle a le choix entre embaucher en contrat à durée déterminée, prendre dupersonnel en régie, décider d’externaliser le projet au forfait auprès d’un prestataire localou gérer le développement avec un prestataire offshore. Aucune de ces solutions ne secompare favorablement à l’offshore en terme de flexibilité et de coûts.

L’embauche de personnel est un engagement sur le futur. Or, le plus souvent, la sociéténe peut être certaine de l’évolution de ses besoins ni de ses moyens et opte pour laprudence. La réduction des effectifs est toujours délicate et pénible, surtout si cespersonnes ont été embauchées quelques mois plus tôt et que la société affiche du profit.

EN RÉSUMÉL’offshore, réactivité et dynamisme

En utilisant des ressources offshore, une société peut saisir des occasions de marché avec un dyna-misme et une réactivité impossibles à atteindre au moyen de ressources distantes.

Critère CoûtRapidité de constitution

Capacité à réduire l’équipe

CompétenceCapacité d’accueil

Embauche de l’équipe en CDD (local)

Pratiquement impossible, seul un salaire élevé pouvant motiver les candidats

Pratiquement impossible

Prévue par le CDD Très faibles chan-ces d’attirer les profils désirés

Embauche en CDI et complément en régie (local)

Normal à élevé selon l’utilisa-tion de la régie

Assez difficile Aisée pour les collaborateurs en régie

Normale à bonne

Régie (local) Très élevé Normal Aisée, après une période minimale prévue contrac-tuellement

Normale à bonne

Forfait (local) Élevé Aisé Naturelle en fin de contrat

Le prestataire tra-vaillant au forfait prend contractuel-lement tous les ris-ques, y compris ceux liés à la mise à disposition des compétences recherchées.

Très aisée

Offshore Très faible Très facile Très facile, prévue par le contrat

Normale à excellente

Très aisée

Tableau 1.2. Flexibilité des équipes(suite)



19

Même dans le cas où l’on penserait avoir besoin de ces ressources dans la durée et où l’ondéciderait de créer une équipe, la constitution d’une équipe d’une cinquantaine depersonnes est difficile et prend du temps. La recherche des candidats passe souvent parla publication d’une annonce dans les médias (presse, Internet, etc.). En cas d’urgence, ilfaut faire appel à un recruteur. On ne peut s’attendre à trouver de premiers collaborateursavant plusieurs mois. Une équipe de 50 personnes peut être constituée au bout de cinq àsix mois dans le meilleur des cas. Les coûts correspondants sont importants, surtoutlorsqu’un recruteur est impliqué.

Pendant la période de constitution de l’équipe, le projet progresse lentement. Les postesse remplissent non pas au fur et à mesure de leur utilité mais au hasard des candidatures,les postes les plus courants étant assurés le plus rapidement, et les plus rares, et donc lesplus importants pour le projet, pouvant rester vacants.

Un candidat en recherche d’emploi qui a postulé à d’autres postes proposés par d’autresentreprises peut de surcroît se désister au tout dernier moment. Ces désistementspeuvent être d’autant plus importants que la société est petite, affiche de mauvais résul-tats, a peu de notoriété, est située en un lieu difficile d’accès ou offre des risques d’insta-bilité.

La régie vient naturellement compléter les embauches. Certaines entreprises misententièrement sur elle pour réaliser leurs projets. La régie présente des avantages évidents,comme la capacité de disposer du personnel rapidement surtout si l’on choisitplusieurs sociétés pour fournir le personnel demandé , et offre une flexibilité trèsimportante pour la gestion des effectifs. Les coûts sont en revanche significativementplus élevés que ceux de l’embauche directe de personnel. L’engagement contractueldétermine le plus souvent une période minimale où l’on doit conserver le personnel enrégie et s’accompagne de clauses de remplacement au cas où une personne ne convien-drait pas. Avec la régie, on paye, parfois cher, la disponibilité rapide des ressources ainsique la flexibilité de leur gestion.

Aucune solution n’offre une flexibilité, une qualité et une réactivité comparables à cellesde l’offshore. Pour un prix inférieur, on peut constituer l’équipe dont on a besoin très rapi-dement, avec les profils les plus compétents ou les plus rares, et réduire les équipes àvolonté une fois le projet terminé.

La flexibilité de l’offshore

L’offshore peut apporter un niveau de flexibilité inégalé pour la gestion des ressourceshumaines. Les engagements du client de l’offshore se limitent aux accords contractuelspassés avec le prestataire offshore. Les clients de l’offshore peuvent ainsi bénéficier del’avantage cumulé de ressources dédiées et d’une grande liberté quant aux ajustementsde ces ressources.

Les sociétés impliquées dans les développements souhaitent naviguer au plus près deleurs besoins, en maintenant une gestion rigoureuse de leurs engagements et de leursdépenses. Elles veulent pouvoir conserver toute latitude d’action afin de réagir à dessituations nouvelles, telles que changement de climat économique, annulation ou réductionde contrats.

Les licenciements sont des actions toujours délicates, tant par les coûts qui les accompa-gnent que par les conséquences sociales et humaines. Les coûts peuvent être très impor-tants, surtout s’ils ne découlent pas d’un motif économique ou s’ils donnent lieu à des



20

conflits sociaux ou à une mauvaise ambiance persistante dans l’entreprise. Ces coûts vontbien au-delà des indemnités légales. Bien souvent, le préavis n’est pas effectué, les condi-tions de départ sont négociées, et les revendications des employés licenciés donnent lieuà des procédures aux prud’hommes. Les coûts cachés doivent aussi être pris en compte,comme la démotivation de certains employés, qui commencent à chercher un nouvelemploi.

La flexibilité ne concerne pas que la gestion des ressources humaines. Savoir gérer deschangements importants peut devenir une question de survie pour certaines sociétés deservices ou des éditeurs de logiciels. Par exemple, une société de services peut voir un deses projets abandonné par un client ou considérablement réduit. Même si le contratdéfinit des clauses de dédommagement en cas de dédit, ces derniers sont souvent loin decouvrir les dépenses d’arrêt du projet. Si la société ne dispose pas d’un autre contrat poury faire suite, elle se retrouve avec des collaborateurs en intercontrat, qu’elle doit prendreà sa charge sans les facturer à des clients.

EN RÉSUMÉL’offshore, ajuster les équipes aux besoins

L’offshore permet d’ajuster les ressources aux besoins de la société cliente que ce soit en augmen-tation ou en réduction.

Un éditeur est lui aussi soumis à des nécessités de réaction rapide. Il lui arrive de modifiersa stratégie en cours d’année pour l’adapter aux nouvelles conditions du marché. Il sepeut que les résultats ne soient pas aussi bons qu’espérés et que des projets soient aban-donnés. Il se peut aussi que des développements liés à des engagements pour un clientspécifique ne soient plus nécessaires du fait que le client s’est désengagé et ne souhaiteplus acheter le produit de l’éditeur.

Dans tous ces cas, seule une grande flexibilité des équipes permet de s’adapter aux condi-tions nouvelles et aux changements de l’environnement afin d’adapter la stratégie et dene pas manquer les occasions qui se présentent.

La qualité des ressourcesLes bons prestataires des pays de l’offshore peuvent attirer les meilleures ressourceslocales. On y trouve souvent des profils remarquables, équivalents à ceux des bonnesécoles d’ingénieurs françaises. Les prestataires de l’offshore offrent d’ailleurs à ces profilsdes salaires et des conditions de travail bien meilleurs que n’importe quel autre typed’entreprise locale.

La qualité du prestataire offshore importe ici beaucoup. Les plus petits, qui n’ont pas deréputation locale, peuvent avoir du mal à trouver les candidats recherchés. Les très grosprestataires adoptent quant à eux souvent un mode « optimisé » de gestion de leursressources et ne les dédient pas toujours à un seul projet. C’est surtout le cas en Inde, oùles bons chefs de projet capables de dialoguer avec le client sont rares. Ces chefs deprojets « tournent » sur plusieurs projets. Le client de l’offshore ne dispose alors pas d’unexcellent profil dédié à son projet, qu’il peut former et habituer à sa façon de travailler,puisque, chaque mois, il trouve un autre chef de projet en face de lui. Les prestatairesayant établi une excellente réputation locale deviennent assez vite des références, quiattirent les meilleurs profils du pays.



21

Certaines universités locales, comme le Belarusian State University, au Belarus, oul’Institut Polytechnique de Bucarest, en Roumanie, sont fort réputées et rayonnent danstoute l’ex-URSS et dans les pays de l’Est. Leur image est comparable à celle d’une grandeécole de premier rang en France, comme l’école des Mines ou Centrale Paris. À l’imagedes grandes écoles françaises, cette réputation ne traverse toutefois pas bien les fron-tières, et ces universités de l’offshore nous sont généralement inconnues. Il est amusantde constater qu’aux États-Unis comme dans les pays de l’Est, la Sorbonne est considéréecomme la meilleure université française, y compris dans les domaines techniques.

EN RÉSUMÉL’offshore, des informaticiens de premier rang

L’offshore attirant les meilleures ressources informatiques, les entreprises qui y recourent peuventdisposer d’excellentes équipes et d’informaticiens de tout premier rang.

En choisissant correctement son prestataire offshore, il n’est pas difficile d’attirer les meilleursprofils sur un projet. Aucun profil technique n’est inaccessible. Les compé tences enmatière de technologie récente sont courantes, et l’on constate une réelle expériencedans ces domaines.

Les seules ressources difficiles à trouver en offshore sont les bons managers de niveaumiddle management et les équipes de test, mais n’est-ce pas non plus très souvent le casen France ?

Les processus structurésPour travailler efficacement avec une équipe distante, il est nécessaire de mettre en placeune structuration stricte des procédures, notamment de recette, ainsi que des flux detravail, ou workflows, bien définis.

Certains prestataires offshore souhaiteront appliquer leurs méthodes , mais d’autressauront parfaitement se plier à des procédures standards, telles que le RUP (RationalUnified Process) ou XP (eXtreme Programming).

Un processus bien mené offre une excellente vision de la progression du projet en mêmetemps qu’une garantie de succès. Les enseignements tirés de tels processus pour lagestion de projet ont parfois une portée qui dépasse le projet géré en offshore. Un retourd’expérience peut dans de tels cas bénéficier aux développements internes de l’entreprisecliente de l’offshore ou à d’autres projets distribués.

Les tests et la qualitéLes projets distribués posent toujours des problèmes de qualité. Pour les résoudre, il estessentiel de mettre en place des procédures de recette bien cadrées afin de travailler effi-cacement avec les équipes distantes et d’apprécier fidèlement le niveau de qualité desdéveloppements qu’elles produisent.

La réduction des coûts de développement offshore permet d’effectuer des tests de qualitéavant livraison de l’exécutable. De telles démarches sont toutefois difficiles à mettre enœuvre avec des équipes locales, où les tests qualité sont souvent déportés sur les bêta-tests. Les premiers clients utilisateurs du produit jouent alors un rôle important pourdéboguer et recetter le produit, voire assurer la totalité de cette recette. Les tests peuvent



22

cependant être automatisés au moyen de robots afin d’assurer un meilleur niveau dequalité et de détection des régressions.

EN RÉSUMÉL’offshore, automatisation des tests

En offshore, la nécessité de mesurer la qualité du produit livré oblige à mettre en place des procé-dures de test de qualité. L’automatisation des tests est un atout important, qui accompagne lafiabilité des livrables.

Si les équipes de test sont souvent difficiles à constituer dans les pays clients, et notam-ment en France, c’est parce que ces postes sont peu attrayants et que les tâches corres-pondantes sont souvent répétitives, tout en exigeant un bon niveau technique. De même,l’automatisation des tests est rarement réalisée en France alors qu’elle est devenue enoffshore un outil répandu pour garantir le niveau de qualité des livrables.

Les tests offshore atteignent parfois un niveau de qualité et de structuration que l’onrencontre rarement dans les pays des clients, que ce soit en raison de leur coût ou de ladifficulté à trouver les ressources adéquates.

Attribution de rôles aux personnesGrâce à l’offshore, on peut envisager d’attribuer des rôles à des personnes, comme leconseil technique, afin de s’assurer de la bonne utilisation du framework technique. Onpeut même se permettre de dédier la totalité du temps d’une personne à ces rôles afinqu’elles y consacrent toute l’attention nécessaire, ce qu’il est difficile d’imaginer en local.Comme la personne n’a que ces tâches à réaliser, on est certain qu’elle ne les délaisserapas au profit d’autres responsabilités.

Ces rôles correspondent souvent à des tâches habituellement réparties sur plusieursmembres des équipes locales. Par exemple, le respect des guidelines, c’est-à-dire desrègles de création d’artefacts, comme les règles de codage, de modélisation ou d’écriturede cas d’utilisation, et celui des procédures sont souvent de la responsabilité de chaquecréateur des documents ou artefacts, alors que ces derniers doivent assurer ce rôle enplus de leur responsabilité principale.

Le respect des guidelines et des procédures est le plus souvent perçu comme d’un niveaude priorité faible par rapport à la production des artefacts eux-mêmes, même si l’onrépète bien souvent que ces procédures et guidelines doivent impérativement êtrerespectés. Le fait de dédier une personne à ce rôle permet d’obtenir davantage d’unitédans l’application des procédures et assure qu’elles seront correctement respectées partous. Cet exemple vaut pour d’autres domaines, comme la méthodologie des tests,l’usage des frameworks technologiques, les règles de sécurité, etc.

En local, même si l’on sait qu’il serait bon de disposer d’un architecte fonctionnel, d’unarchitecte technique, d’un intégrateur, de testeurs, de développeurs de programmes detests, etc., on fait bien peu souvent l’effort financier de créer des postes dédiés à ces rôles.Avec l’offshore, il en va tout autrement, d’une part, parce que certaines de ces positionssont indispensables pour sécuriser les réalisations et, d’autre part, parce c’est abordablefinancièrement. Le fait d’assigner un poste à temps plein à la bonne application desméthodes et procédures et à leur mise à jour en continu garantit un travail structuré,transparent et contrôlable.



23

L’un des premiers rôles généralement désignés est le responsable procédures, qui a pourmission d’assurer que les procédures sont effectivement en place, suffisamment préciseset correctement appliquées. Une de ses missions est d’analyser dans la durée les besoinsd’évolution des procédures ou les redondances du reporting.

Le rôle d’architecte fonctionnel est souvent absent des projets réalisés en local, cetteresponsabilité se trouvant répartie entre plusieurs chefs de projet. Il apporte pourtant ungrand confort dans le traitement de tout nouveau développement ou changement. Ilrepère en outre les relations avec les composants existants et sait identifier les designpatterns, assurant de la sorte une excellente gestion de l’évolution des produits.

Le rôle d’architecte technique est essentiel pour isoler les développements fonctionnelsdes développements techniques et fournir aux développeurs fonctionnels ce dont ils ontbesoin pour travailler efficacement. Il peut aussi travailler avec les équipes de test pourréaliser des tests de performance ou de charge significatifs. Toute évolution des couchestechniques peut être immédiatement traitée par l’architecte technique, qui est à mêmed’en mesurer l’impact sur le reste du produit.

Selon la nature du projet, il peut être nécessaire de créer d’autres rôles. Cette approche,consistant à dédier un poste à certaines tâches que l’on considère importantes, engarantit la bonne application.

Conclusion

Les motivations incitant à travailler avec un prestataire offshore peuvent grandementvarier selon les projets et les sociétés. Les sociétés qui pratiquent les développements enoffshore depuis un certain temps, et tout particulièrement celles qui ont de grandeséquipes de développement, donnent plus d’importance à la flexibilité et aux compétencesdes ressources que l’on trouve dans ces pays. Les plus petites se préoccupent davantagedes coûts. Toutes recherchent la qualité des livraisons.

Quel que soit le poids respectif que l’on accorde à chacun des avantages de l’offshore, onrecherche toujours un mélange de ceux-ci. On veut réaliser plus, plus rapidement, avecplus de qualité, un meilleur contrôle, une meilleure visibilité pour le même prix ou mêmepour moins cher.

Pour ambitieux qu’ils soient, de tels objectifs peuvent être atteints, à condition detravailler efficacement avec l’offshore. Le but de cet ouvrage est de montrer comment yparvenir.


25

Chapitre 2

Les chemins de l’offshore

Pour réaliser un projet informatique, nous avons toujours le choix du type de ressource àutiliser. Du plus proche au plus lointain, nous disposons des quatre approches généralessuivantes :

• Onsite. Sur place, au sein de la société, avec des ressources propres ou externes enrégie.

• Offsite. En dehors de la société. Il s’agit le plus souvent d’une sous-traitance au forfait.

• Nearshore. Faibles coûts des ressources et relative proximité.

• Offshore. Ressources à faible coût

Le tableau 2.1 détaille les principaux éléments qui différencient ces approches.

Tableau 2.1. Comparaison du choix des ressources

OnsiteOnsite (avec ressources en régie)

Offsite (projet externalisé au forfait)

Nearshore (Offshore dans un pays proche)

Offshore (dans un

pays éloigné)

Coût du projet ++ +++ +++ – –

Compétences en gestion de projet

++ ++ – + +

Facilité à travailler en équipe

++ ++ + + –

Capacité à agir en période de crise

++ + – + –

Limitation des sujets à risque sur le projet

++ ++ + + –

Capacité à constituer rapide-ment une équipe

– + + ++ ++

Capacité à réduire les effectifs

– + + ++ ++



26

Nous supposons dans ce tableau que le prestataire offshore ou nearshore agit en moderégie. Les compétences nécessaires à la réussite d’un projet en offshore dépendent dumode de fonctionnement retenu. Dans le cas de projets en offshore au forfait, les compé-tences chez le client sont peu utiles. À l’inverse, si la société cliente de l’offshore prend lecontrôle total du projet et des ressources en offshore, les compétences en gestion deprojet deviennent primordiales pour réussir le projet. Le client de l’offshore pourra toutde même s’appuyer sur les compétences en gestion de projet mises en place chez l eprestataire offshore.

Nous montrons dans ce chapitre comment la société qui confie ses projets en offshorepeut atteindre ses objectifs de flexibilité, de coûts et de garantie de succès. Nous étudionspour cela les divers chemins qu’elle peut emprunter et montrons que nous disposons dela possibilité de travailler en nearshore, ce qui permet d’atteindre pratiquement tous lesobjectifs simultanément.

Si la récompense est de taille, les chemins qui y mènent ne sont pas sans embûches.L’expérience que l’on a des projets, même multisites, dans les pays occidentaux n’est quepartiellement utile pour éviter les nombreux pièges que l’on rencontre en travaillant avecles pays de l’offshore. Les difficultés abordées succinctement dans ce chapitre sont pourla plupart reprises dans les chapitres suivants afin d’en détailler les remèdes possibles. Ilimporte de les avoir à l’esprit afin de ne pas se laisser surprendre.

Les différences culturelles et les problèmes de communication dépendent du pays aveclequel on décide de travailler. Le choix du pays de l’offshore définit donc en grande partiela nature des difficultés rencontrées. Un pays proche et sûr permet de se rendre périodi-quement chez le prestataire et de réduire, par ces contacts réguliers, la distance culturelleentre les équipes.

Les développements onsite

Une société qui souhaite réaliser des développements se dote des équipes qui permet-tent de les réaliser. C’est le plus simple et le plus naturel. Ses besoins en ressourcescomplémentaires peuvent être plus ou moins importants, mais il est généralementpossible d’anticiper une certaine quantité de développements afin d’assurer la mainte-nance corrective et évolutive à tout moment une fois le projet terminé. La maintenancedes produits existants est en effet assez facile à prévoir, si nous faisons abstraction desévolutions majeures. Le seul fait d’assurer cette maintenance mène à un plancher assezprécis du volume de développement nécessaire et permet d’estimer le nombre minimalde ressources.

Comme nous l’avons vu au chapitre précédent, les ressources onsite recrutées posent desdifficultés importantes si nous souhaitons conserver une grande liberté, que ce soit pourréduire les investissements en R&D ou pour les faire croître très rapidement. Lesressources embauchées agissent comme un filtre « passe-bas ». Elles ne laissent passerque les mouvements de basse fréquence. Autrement dit, les décisions vives, par lesquellesnous souhaitons constituer des équipes rapidement pour, peut-être, les réduire avec lamême rapidité plus tard, sont impossibles à réaliser avec des équipes recrutées.


Chapitre 2 – Les chemins de l’offshore

27

Certaines sociétés considèrent que la valeur de leur entreprise se situe en partie dans lesressources dont elles disposent pour réaliser leurs projets, notamment pour les sujets quisont au cœur de leur activité. Les développements qui sont considérés comme primor-diaux (mission critical) sont souvent conservés en interne en vue d’une meilleure chance desuccès et d’une meilleure confidentialité des réalisations.

Avec les développements sur site, toute la responsabilité de la réussite ou de l’échec d’undéveloppement se situe au sein de l’entreprise. Si le projet réussit, l’équipe de R&D ausens large, incluant les tâches amont et aval du pur développement, s’attribue le succès,même s’il ne provient pas toujours d’une démarche concertée et construite. En réalité, lesuccès est le résultat complexe d’un ajustement continu dans le temps, où des rôles poly-morphes se sont créés de fait et garantissent une certaine qualité des réalisations.

Par exemple, il est courant que certains chefs de projet, travaillant depuis longtemps surle domaine fonctionnel concerné, parviennent à jouer un rôle mixte de chef de produit, dechef de projet, de responsable des tests et même de décisionnaire final, assurant lesuccès du développement demandé. Personne n’a souhaité organiser les choses ainsi,mais elles ont évolué naturellement de cette façon. De telles personnes clés au sein deséquipes de développement assurent de facto le succès des réalisations, souvent sans entirer de reconnaissance.

L’équipe R&D est également responsable des échecs des projets. Certains collaborateurssont difficiles à remplacer lorsqu’ils s’en vont. Des collaborateurs jouant un rôle essentiel,tel celui décrit ci-dessus, partent parfois en emmenant les compétences et la part organi-sationnelle qui garantissaient le succès. Ces responsabilités, parfois imprécises, qui serévèlent surtout par le vide soudainement créé, rendent les remplacements encore plusdélicats. Pour pallier cette dépendance aux circonstances, il est nécessaire d’apporterdavantage de rigueur aux procédures et de s’assurer que le fonctionnement s’appuie nonpas sur le hasard ni la bonne volonté mais sur une réelle organisation.

La réduction des équipes ne s’appuie pas toujours sur des critères objectifs. Le manage-ment s’attache parfois à certains informaticiens parce qu’ils sont de bons compagnons etqu’ils créent un sain esprit d’équipe. Il y a aussi ceux qui sont là depuis toujours, qui ontparticipé aux premières heures de la société et dont on se souvient parce qu’ils avaienttrès bien réagi dans des périodes de crise. La façon de gérer le personnel embauché estle résultat d’un processus complexe, où le non-dit tient une place importante. Sur le papier ,il est facile de décider de réduire les effectifs. Lorsqu’il s’agit de nommer les personnes,les choses deviennent plus difficiles, car toutes sortes de justifications émotionnellesconduisent à souhaiter conserver la majeure partie des effectifs.

Pour toutes ces raisons, la flexibilité des équipes sur site est difficile à assurer, que ce soitpour réduire les équipes ou pour les faire croître.

EN RÉSUMÉLa gestion complexe des équipes locales

Les équipes locales sont souvent perçues comme participant à la valeur de la société. Certainespersonnes jouent parfois des rôles multiples et incontournables et contribuent directement ausuccès des développements. Les processus de décision concernant ces équipes impliquent unepart émotionnelle importante, qui l’emporte souvent sur les raisonnements financiers.



28

Le personnel en régieL’utilisation de personnel en régie permet de compléter l’équipe sur site. Cette dernière,dont la valeur critique pour la société est la plus élevée, est destinée à centraliser lesrôles. Dans certains cas, il est possible de faire massivement appel au personnel en régie,y compris pour la maîtrise du projet, voire pour assurer la gestion des aspects fonction-nels du projet. La régie permet d’atteindre l’objectif de flexibilité des équipes, qui est sicher aux sociétés dynamiques.

La flexibilité obtenue par le recours à du personnel en régie se paye cher, à la fois ensurcoût de salaire, en formation et en intégration. Les équipes internes risquent desurcroît de se trouver déstabilisées lorsque les collaborateurs en régie s’en vont. Parfois,ces personnes jouent des rôles clés dans l’organisation et manquent cruellement aprèsleur départ, tout particulièrement lorsque la société s’appuie sur leurs compétences fonc-tionnelles ou de gestion de projet. Il est rare que ces mêmes personnes soient disponiblespour une mission future.

Dans la majorité des cas, le management du projet reste dans la société cliente. Même siun chef de projet provient de l’extérieur en régie pour une durée limitée, il est le plussouvent prévu que la gestion du projet est transférée à un collaborateur local, de façonque la compétence tant technique que fonctionnelle reste à l’intérieur de la société. Lasociété cliente maintient de la sorte toute sa propriété intellectuelle à l’intérieur de seslocaux.

EN RÉSUMÉLa régie, ou la flexibilité au prix fort

L’utilisation de personnel en régie assure la flexibilité des ressources informatiques, mais elle sepaye cher. Le personnel en régie doit être accueilli dans les locaux de l’entreprise comme le personnelembauché.

Coût de la régie

Le personnel en régie engendre un surcoût d’environ 50 %. Les tarifs d’un développeur sesituent rarement en deçà de 300 euros par jour et atteignent parfois 800 euros par jour pourles profils les plus expérimentés. Au finale, non seulement les développements reviennentplus cher, mais il faut aussi fournir les ordinateurs et l’espace de travail pour le personnelen régie. Ce dernier est plus ou moins géré comme le personnel embauché. Généralement,la société qui accueille des personnes en régie s’engage à les conserver au moins six mois,parfois moins, selon les accords passés avec le fournisseur de personnel. Il arrive souventqu’après plusieurs mois la société qui utilise des ressources en régie oublie ses objectifsde flexibilité ou les difficultés rencontrées pour embaucher et qui lui avaient fait choisir larégie. Les surcoûts du personnel en régie deviennent lourds par rapport au coût du person-nel embauché, et la pertinence d’utiliser de la régie est régulièrement contestée. Souvent,la société demande à son fournisseur de personnel en régie d’embaucher les ressourcesen régie ou de revoir le contrat en baissant les coûts des collaborateurs en régie, qui, pourtant,paraissaient corrects au moment de la signature du contrat de régie.



29

Les développements offsite

Les développements offsite reviennent à sous-traiter le projet, le plus souvent au forfait,auprès d’une société de services. Nous supposons ici que les développements sonteffectués en totalité dans le pays du client et non en offshore.

Un chef de projet chez le client suit la progression du projet, mais la maîtrise quotidienneest transférée au prestataire offsite. La société cliente atteint parfaitement ses objectifsde flexibilité et n’a pas besoin de fortes compétences en interne pour gérer le projet, unefois les spécifications détaillées fournies à la société de services.

Le coût est assurément élevé, car le prestataire travaillant au forfait embauche le plussouvent ses ressources ou utilise des compléments de ressources en régie. Il impute desurcroît une marge additionnelle sur sa facturation afin de se protéger des aléas du projet.

L’utilisation de projets au forfait est souvent perçue comme une garantie de réussite pourun prix fixé d’avance. Comme expliqué précédemment, la gestion au forfait ne s’appliquepas à tous les projets, et la garantie de satisfaction des utilisateurs finals du produit déve-loppé est loin d’être garantie. La flexibilité est en revanche naturellement assurée, puisque,une fois le produit livré, le contrat se termine en même temps que les engagementsenvers la société de services.

Le chapitre 4 détaille les avantages et inconvénients comparés du forfait et de la régie,ainsi que les conséquences de ces modes de travail, notamment avec un prestataire enoffshore.

Les développements offshore et nearshore

Les développements offshore et nearshore sont similaires, la seule différence résidantdans la distance entre la société cliente et le prestataire de services en offshore. Le near-shore recourt à une équipe de développement assez proche géographiquement, dépassantrarement trois heures d’avion, avec une ou deux heures de décalage horaire.

Nous considérons dans ce chapitre l’offshore et le nearshore en mode régie, même s’iln’est pas rare d’injecter une part de forfait afin de donner à certaines réalisations un cadre

Projets offsite et forfait

Tous les projets ne s’adaptent pas bien au forfait. Plus le projet est long et complexe, etplus il est difficile à définir au moment de la signature du contrat avec le prestataire. Lesprojets au forfait conviennent assez bien aux petits projets bien définis et aux projetsstables par nature, comme ceux consistant en l’implémentation de principes mathémati-ques ou les convertisseurs de formats de fichiers. Le forfait est peu efficace pour les projetslongs et complexes, dont le contenu doit être révisé au cours de la réalisation. Selon lafaçon dont le projet est géré par la société de services, des effets néfastes peuvent nuireau projet, au client et à la société de services, voire, dans certains cas, mener à l’arrêt duprojet.



30

à la fois pour le contenu et le prix des réalisations, même si ce cadrage est partiel, puisquele reste du projet est réalisé en régie. Dans le forfait pur avec une équipe en offshore, ladistance importe peu, car le projet est entièrement défini au moment de la signature ducontrat. Les échanges sont par conséquent moins fréquents et moins intenses que dansle mode régie. Le mode forfait est privilégié par les sociétés américaines qui recourent àl’offshore car il favorise le travail des équipes locales et offshore sans recouvrementhoraire. En France, la possibilité de travailler en régie avec le nearshore est tellementefficace que le forfait ne se rencontre pratiquement jamais.

Pour peu que l’on prenne soin de bien choisir son prestataire, le nearshore en régiepermet d’atteindre tous les objectifs mentionnés précédemment (flexibilité des équipes,compétences, faibles coûts et contrôle fin et continu de l’avancée du projet). Dans tousles cas, le choix d’un partenaire incompétent ne peut mener qu’à l’échec.

Il est possible de négocier la dose de forfait souhaitée avec le prestataire offshore, tout enconservant un contrôle précis des actions de l’équipe distante. L’accord contractueldéfinit avec précision la façon de travailler ensemble, ainsi que la part de responsabilitédonnée à chaque équipe, les méthodes et le management que l’on souhaite appliquer.

Que ce soit en offshore ou en nearshore, les difficultés sont très nombreuses et difficilesà résoudre. Celui qui sait anticiper ces difficultés peut se préparer, les éviter, voire, danscertains cas, les retourner à son avantage. Il est donc très important de bien les comprendre.Les sections qui suivent font un tour d’horizon de ces problèmes, dont la résolution estessentielle au succès ses projets en offshore.

Éloignement des équipesLa distance modifie fortement les façons de travailler. Que les équipes de développementsoient éloignées de quelques kilomètres seulement ou de 5 000 kilomètres, un grandnombre de problèmes doivent être résolus pour travailler efficacement.

Les problèmes qui proviennent de l’éloignement sont essentiellement résolus par lesprocédures mises en place et la formalisation des documents échangés. Cela paraîtsimple. Pourtant, la mise en place de procédures formalisées fait le plus souvent appa-raître des défauts dans l’organisation interne de la société cliente, avec des rôles pas clai-rement définis, des documents pas toujours disponibles et des informations diffuses.Même les centres de décision peuvent apparaître flous, si bien qu’on se demande parfoisqui décide, notamment lorsque les procédures concernent deux équipes distinctes de lasociété, qui sont gérées par deux directeurs, par exemple, la direction marketing, qui gèreles aspects fonctionnels, et la direction R&D, qui gère les développements.

Pour travailler efficacement à distance avec le prestataire en offshore, il faut mettre enplace des procédures adaptées. Ces dernières doivent prendre en compte la culture del’entreprise cliente et celle du prestataire, ainsi que la taille du projet et le personnel enplace. Dans le mode au forfait, le client de l’offshore n’a pas vraiment de contrôle sur lesprocédures mises en place, lesquelles sont sous l’entière responsabilité du prestataire deservices en offshore. Le mode en régie est de loin préférable si l’on souhaite contraindrele prestataire à appliquer les procédures que l’on utilise localement.

Les procédures que l’on met en place au sein d’une équipe locale sont souvent déployéesavec prudence, afin de ne pas créer de ruptures, susceptibles de freiner le développement,et de ne pas froisser certaines personnes clés, qui verraient d’un mauvais œil les limita-tions apportées à leurs responsabilités. La mise en place de procédures avec une équipe



31

en offshore est beaucoup plus difficile qu’avec une équipe locale (voir la troisième partie de cetouvrage). Pour y parvenir, il ne faut mettre en place que les procédures, outils et documentsréellement utiles et qui doivent être utilisés immédiatement. Toutes les erreurs sur lesmises en place de ces artefacts (procédures mal conçues, contradictions, lourdeur exagéréede certaines procédures) conduisent immédiatement à des dysfonctionnements .

Il est fortement recommandé de s’appuyer sur des méthodes qui ont fait leurs preuves etqui sont pleinement documentées, comme le RUP (Rational Unified Process) ou XP(eXtreme Programming). Ces méthodes sont toutefois lourdes et difficiles à mettre enplace. Pour ne pas ralentir la progression du projet par l’installation d’un cadre méthodo-logique, on pourra ne mettre en place que ce dont on a besoin au fur et à mesure del’apparition de l’utilité de ces procédures, ce qui demande une bonne maîtrise et unebonne compréhension de la gestion du développement de logiciels. En revanche, il estnécessaire de mettre en place sans délai les outils qui permettront de suivre la mise enœuvre des procédures, voire d’en forcer l’application.

Certains prestataires en offshore mettent en avant leurs propres procédures, auxquellesils ont parfois donné un nom. Ils considèrent que ces procédures leur apportent un avan-tage concurrentiel. Cela peut être vrai pour les développements au forfait, mais c’estassurément un frein pour les développements en régie, où l’on souhaite fondre dévelop-pements distribués et internes. La maîtrise des méthodes standards du marché par unprestataire offshore peut être considérée comme un atout par rapport à des prestatairesqui n’ont jamais utilisé de méthode formelle.

L’éloignement accroît la difficulté à synchroniser efficacement les développements locauxet distants. Il se trouve assez souvent que la société locale conserve en interne les partiescentrales du développement et ne confie à l’offshore que les parties complémentaires oupériphériques. Les développements doivent en ce cas s’intégrer correctement, alorsmême que les différentes parties du programme évoluent indépendamment. Lesproblèmes éventuels se résolvent par la mise en place de procédures strictes. Pour êtreefficaces, elles doivent être correctement appliquées à la fois chez les équipes françaiseset en offshore. Les appliquer uniquement aux équipes en offshore ne serait qu’une demi-mesure. Il faut le plus souvent partager les outils et procédures les plus importants entreles équipes.

EN RÉSUMÉL’éloignement modifie la gestion de projetQuand le prestataire de services est distant et travaille en mode régie, la gestion de projet et lesprocédures doivent être rigoureuses et réellement applicables pour réussir les projets. Il faut enoutre que les rôles soient clairement définis et que l’organisation soit comprise et efficace.

La langue de travailSi certaines équipes en offshore utilisent le français comme langue de travail, notammentdans le Maghreb, en Roumanie, au Vietnam et à l’Île Maurice, la quasi-totalité des pays quioffrent des prestations offshore utilisent l’anglais. La majeure partie des prestations en off-shore commandées par la France n’utilise d’ailleurs pas le français comme langue de travail.

Il ne faut pas se cacher que le fait de travailler dans une langue qui n’est pas sa languenatale est une difficulté. Il ne faut pas croire pour autant que les anglophones travaillentmieux avec les équipes offshore, car ils rencontrent un autre problème, aux effets beau-coup plus pervers. Américains et Anglais utilisent un vocabulaire plus complexe que les



32

étrangers, avec des tournures idiomatiques, des postpositions qui changent le sens desmots, des accents locaux, un rythme souvent plus rapide, etc. De plus, ils ont tendance àmoins vérifier que ce qui est dit est compris. De son côté, l’interlocuteur en offshore nedemande pas toujours de répéter, espérant rattraper le sens qui lui a échappé dans lasuite de la conversation. Au téléphone, c’est évidemment encore plus difficile. C’est là unedifficulté bien connue des Américains qui travaillent avec l’Inde, par exemple. On larencontre aussi parfois lorsqu’un Français monte une équipe francophone en Roumanie,au Vietnam ou à l’Île Maurice.

Les équipes françaises parlent parfois très mal l’anglais ou, plus étonnant, n’osent pasparler anglais, bien qu’elles en soient capables. L’anglais nécessaire et suffisant pourtravailler en offshore est pourtant rudimentaire. Il faut être capable de se faire biencomprendre par écrit et assez bien à l’oral. Un interlocuteur en offshore qui ne comprendpas l’anglais d’un Français ne va pas hésiter à dire qu’il n’a pas compris. Il sait que c’estdifficile aussi pour son interlocuteur, et le fait de demander de répéter n’est pas considérécomme un aveu de faiblesse.

Lorsque les deux interlocuteurs utilisent un anglais appris, le vocabulaire et les phrasesemployées de part et d’autre sont d’un niveau plus simple. Les tournures idiomatiques etles faux amis, même parmi les plus courants, sont naturellement évités, puisqu’on n’estpas certain de ne pas se tromper. La diction est en outre plus lente, et on vérifie le plussouvent du regard que ce que l’on dit est compris.

EN RÉSUMÉL’anglais deuxième langue facilite la communication

Le fait que l’anglais soit la deuxième langue à la fois du prestataire et de la société cliente facilite lacommunication. Le vocabulaire est simple, les tournures de phrase légères et le sens des échangesunivoque.

La communication écrite se trouve souvent facilitée par les très nombreux outils detraduction disponibles en ligne ou sur PC. Il est de la sorte possible de rechercher dessynonymes, de vérifier le sens d’un terme ou d’en choisir un meilleur ou de corriger untexte à l’aide des correcteurs orthographiques et grammaticaux de traitements de textetels que Microsoft Word. En règle générale, les personnes parlant mal anglais parviennentà communiquer efficacement par écrit dans le cadre d’un projet informatique. On estparfois étonné de rencontrer un chef de projet en offshore qui a envoyé de nombreuxmessages en anglais, longs et précis, et de constater qu’il ne parle pas anglais.

La communication orale n’a pas vraiment cours lors d’un projet en offshore. Les conver-sations téléphoniques ne laissant pas de traces, on leur préfère les messageries instan-tanées, telles que Windows Messenger, MSN Messenger ou ICQ, qui sont très efficacespour régler en temps réel les problèmes ou transférer certains messages vers d’autrespersonnes concernées. Avec ces messageries instantanées, tous les utilitaires permettantde traduire, rechercher des synonymes ou détecter les fautes d’orthographe peuvent êtreactivés.

La langue de travail du projet doit être l’unique langue d’échange d’information sur leprojet. Il est fortement recommandé d’interdire la langue locale dans toutes les conversa-tions relatives à la gestion du projet, que cela concerne les notes entre équipes, les chats(conversations instantanées) ou toute autre communication écrite. Cela vaut pour leséquipes en offshore comme pour les équipes locales. Pour une équipe locale en France,



33

par exemple, les messages et notes relatives à la gestion du projet devraient toutes êtrerédigées exclusivement en anglais, même si les destinataires sont français.

Ce n’est que lors des déplacements sur place que l’on doit communiquer par oral dans lalangue de travail du projet ou lorsqu’un collaborateur de l’offshore se rend chez le clientlocal.

Le plus gros problème de langue que l’on constate est le refus de certains membresd’équipes locales au rôle incontournable dans les opérations en offshore de parleranglais. On peut découvrir derrière cette attitude des blocages psychologiques, voire unefaçon détournée de refuser l’offshore.

Du côté des équipes offshore, on rencontre des niveaux d’anglais très disparates. Certainespersonnes écrivent bien en anglais mais le parlent très mal. D’autres ont un accent incom-préhensible ou un débit ultrarapide. Il est possible d’exiger du presta taire en offshore unniveau minimal d’anglais au sein de l’équipe qu’il met en place. Des cours d’anglaispeuvent être organisés, assortis de tests de niveau, comme le propose sur In ternet Brain-Bench (www.brainbench.com), qui délivre en outre des certificats d’aptitude. Le contrat liantle prestataire en offshore et son client peut prévoir un niveau défini par le nombre depoints obtenus aux tests de BrainBench.

Nous ne parlons ici que de la langue de travail pour la gestion du projet et non des corpusde documents produits, tels les spécifications ou les manuels utilisateur. Même si lalangue de travail est l’anglais, il est possible de fournir au prestataire en offshore desspécifications en français, un programme à réécrire dont tous les commentaires sont enfrançais, des documents méthodologiques ou des manuels utilisateur en français. Leprestataire en offshore sera presque toujours en mesure d’embaucher des personnesparlant français afin d’exploiter sans difficulté ces documents. En revanche, il ne faut pasespérer le voir produire des documents en français avec un niveau de qualité suffisant. Cepeut être alors le bon moment pour la société française d’opter pour l’anglais commelangue de travail afin de s’assurer un meilleur potentiel de croissance externe à l’inter-national ou de croissance géographique.

EN RÉSUMÉFormations en anglais chez le prestataire

Le prestataire offshore peut organiser des cours d’anglais permettant aux membres des équipesembauchées de se perfectionner afin de communiquer efficacement.

Les différences culturellesLes difficultés culturelles sont d’un tout autre ordre et posent de sérieux problèmes dansle temps, car elles sont souvent ignorées ou cachées. Les problèmes culturels sont sournoiset peuvent créer des conflits inextricables si on ne les prend pas en compte.

L’un des premiers problèmes culturels que l’on rencontre est le complexe d’infériorité (duprestataire en offshore) ou de supériorité (du client ou du prestataire). Dans les deux cas,le problème naît de l’énorme différence de niveau de vie qui existe entre le pays du clientet celui de l’offshore. Dans certains cas, des collaborateurs en offshore affichent une atti-tude obséquieuse, ne voulant contredire en rien ce que le client demande. Dans d’autrescas, c’est l’inverse. Il n’est pas rare de rencontrer des collaborateurs en offshore qui, aunom d’un vif sentiment patriotique en réponse à une attitude jugée méprisante de certainsclients, développent une posture d’opposition systématique à l’égard de ces clients.


http://www.brainbench.com


34

Il est vrai que le client fait parfois montre d’un sentiment de supériorité injustifiable etagit comme si les équipes offshore étaient « inférieures », ne comprenant rien et devantse contenter d’exécuter à la lettre les directives. Lorsqu’une telle attitude est partagée parles collaborateurs en offshore, on se doute que les relations sont vite tendues avant de sedégrader totalement.

Les réactions à adopter face à un prestataire offshore doivent être très différentes decelles que l’on peut avoir avec une société de services locale. En offshore, si des erreurssont commises et qu’on en fait le reproche au prestataire, cela peut générer une réactionde défi. Certaines personnes vont placer un point d’honneur à démontrer que ce n’est pasentièrement de leur faute ou que c’est facilement explicable. J’ai personnellementrencontré un manager d’une équipe offshore d’un pays dont je tairai le nom qui avaitarrêté de travailler pour démontrer qu’il avait raison et que la faute incombait à son client,qui n’avait pas donné les bonnes directives ou qui n’avait pas été assez clair.

Dans certaines cultures, on peut être surpris que les managers considèrent comme unefaiblesse, voire comme une faute, le fait de dire qu’ils n’ont pas compris ou de demanderdes informations complémentaires. En Asie, une attitude largement répandue consiste àne jamais dire non, ce qui oblige l’interlocuteur à une gymnastique particulière pourposer les questions dans le bon sens. Par exemple, la réponse à la question « avez-voustout ce qu’il vous faut pour travailler efficacement ? » est toujours « oui ». Il suffit souventde formuler la question autrement, par exemple « avez-vous besoin de plus d’informa-tions pour travailler efficacement ? », pour engager la discussion et se rendre compte duvaste champ d’interrogations en suspens.

Dans certains pays, les problèmes culturels et religieux peuvent être insurmontables. Parexemple, monter une équipe au Liban en employant des musulmans et des israélites estl’assurance de conflits plus ou moins ouverts et de tensions régulières. J’ai moi-mêmegéré à Beyrouth une petite équipe composée de chrétiens, de musulmans et de juifs, qui,après plusieurs semaines, s’est clairement divisée en trois clans qui ne se parlaient pas.

Certains pays ont connu peu de mélange de races dans leur histoire, comme la Chine oule Belarus, ce dont ils tirent parfois fierté, voire un sentiment de supériorité. De plus,certaines de ces régions sont rarement fréquentées par les voyageurs, le tourisme y étantpeu développé et les occasions commerciales attirant essentiellement des hommesd’affaires occidentaux. Lorsque de telles conditions sont réunies dans un pays d’offshore,il peut être difficile à un chef de projet de peau noire ou de type arabe recruté par le clientfrançais de se faire reconnaître comme un manager ou technicien compétent. Même si lescollaborateurs offshore sont parmi les plus éduqués et les moins xénophobes du pays, ilsferont montre de méfiance à l’égard des capacités et de la compétence de ces personnestypées. L’équipe offshore fera toutefois de son mieux pour travailler efficacement avec untel chef de projet et dépasser ces préjugés.

Les événements politiques internationaux ont parfois une résonance forte dans les paysde l’offshore, et la politique internationale de pays comme la France ou les États-unis

Les résultats inattendus des différences culturelles

Plus l’éloignement culturel est important et plus les surprises qui en découlent peuvent êtregraves. Il est essentiel de conserver un esprit ouvert pour traiter ces surprises culturelles.



35

peut y créer de fortes réactions d’adhésion ou de rejet. Précisons toutefois que les effets deces réactions auprès de l’équipe de développement sont assez faibles. Il n’en va pas de mêmede la vie quotidienne des représentants du client dans ces pays, qui peut devenir difficile.

Comprendre les mentalitésIl est important de comprendre comment les collaborateurs avec lesquels on travaillepensent et quels sont leurs objectifs. Contrairement à une idée répandue, rares sont lesdéveloppeurs de l’offshore à désirer émigrer vers les États-unis ou l’Europe de l’Ouest. Lamajorité d’entre eux aiment vivre entourés de leurs proches et n’aspirent pas à quitter leurfamille. Ils souhaitent se marier et avoir des enfants qui grandiront près de leurs grands-parents, tout en leur apportant un niveau de vie agréable.

Les États-unis ont à plusieurs reprises ouvert leurs frontières aux immigrants qualifiésdans le domaine de l’informatique, sans que cela crée de fl ux massifs d’immigration.De même, à une époque où l’Allemagne a constaté un manque d’informaticiens qualifiés,elle a offert un grand nombre de visas mais n’a reçu que peu de candidats.

L’idée que les personnels qualifiés de l’offshore souhaitent absolument quitter leur paysest globalement fausse. Ce que recherche avant tout la majorité d’entre eux c’est la stabi-lité de l’emploi, la régularité des paiements et un salaire leur permettant d’envisager unemprunt pour acheter un logement. Dans ces pays, les postes d’informaticiens sontpresque toujours précaires. Lorsqu’un projet se termine, le prestataire se sépare le plussouvent immédiatement de ses collaborateurs. La stabilité est donc un facteur essentielde satisfaction pour les collaborateurs en offshore. Le sujet des motivations humaines esttraité plus en profondeur au chapitre 3.

Gérer les projetsComme expliqué au chapitre 1, les collaborateurs en offshore ont rarement de fortescompétences en matière de gestion de projet. On trouve certes des personnes qui ontdéjà managé des projets avec des sociétés occidentales, mais, le plus souvent, les prin-cipes mêmes de la gestion de projet sont peu maîtrisés. Ceux qui ont parfois accompli destâches précises de suivi des équipes ou d’avancement des projets ont rarement acquisune vision d’ensemble du projet et n’ont pas eu à prendre de décisions pour corriger lesdysfonctionnements éventuels. Face à un nouveau projet, leur capacité à le gérer et à cré erles procédures adéquates est donc généralement faible.

Les compétences en matière de management des ressources humaines sont égalementfaibles. Il n’est pas rare de trouver des managers en offshore qui pensent innover ensuggérant de mettre en place des techniques de management abandonnées depuis long-temps en Europe de l’Ouest ou aux États-unis et considérées comme des erreurs notoires.

D’une manière générale, les compétences en management sont extrêmement rares, quelsqu’en soient les domaines. Même lorsqu’on se trouve en face d’une personne qui a acquisune certaine expérience, il convient de demeurer vigilant, car elle peut atteindre rapide-ment ses limites. Tout peut alors arriver. Mon expérience m’a convaincu, à quelques raresexceptions près, qu’il était préférable que le client de l’offshore prenne en charge la tota-lité du management d’un projet. Une fois que ce client sera en mesure d’apprécier à sajuste valeur les compétences du management local, il pourra décider de déléguer certainsdomaines de management, non sans accompagner ces responsabilités du reporting ad hoc.



36

EN RÉSUMÉManagement et gestion de projet

Les collaborateurs en offshore qui savent manager des équipes et gérer des projets sont générale-ment très rares. Mieux vaut s’entourer des compétences de ses propres collaborateurs si l’on veutgarantir le succès de ses projets en offshore.

Le syndrome du poulet bien grasL’attitude du management de la société cliente de l’offshore est déterminante pour laréussite d’un projet. Il n’est pas rare de voir un membre du comité de direction qui n’estpas impliqué dans le développement s’inquiéter des marges que réalise le prestataireoffshore. Cette personne, qui peut être le directeur général de la société, le directeurfinancier ou un responsable de business unit, considère volontiers que les responsablesn’ont pas négocié le contrat à un prix raisonnable ou que les coûts ne sont pas contrôlés.Se développe alors le syndrome du gros poulet bien gras qui se fait plumer par le prestataireen offshore, lequel réalise, on en est certain, des marges abusives.

Ce sentiment peut provenir de plusieurs sources. Des managers parlent de l’offshore avecdes amis qui gèrent aussi des activités en offshore et échangent chiffres et opinions sur

ÉTUDE DE CAS

Un manager faisant illusion

Une société française, éditrice de logiciels, dispose d’une équipe de développement d’une quin-zaine de personnes. Les procédures n’existent pas vraiment, mais la motivation des informaticiens,leurs compétences fonctionnelles et leur bonne volonté donnent des résultats très satisfaisants.Sans documentation fonctionnelle ni technique, la transparence des développements est quasimentnulle, et l’arrivée de nouveaux collaborateurs demande de longues sessions de formation.Cette société décide de travailler avec un prestataire en offshore. Elle en trouve un de qualité, quilui présente un chef de projet expérimenté. Dès les premiers contacts avec ce dernier, la société estimpressionnée par son professionnalisme. Le chef de projet leur déclare qu’il ne peut travailler sansformalisation et qu’il souhaite apporter plus de rigueur dans les procédures. Il leur expliquecomment procéder, quels documents créer et comment les rédiger. L’éditeur français suit ces recom-mandations et fait l’effort de créer tant bien que mal les documents demandés, avec descriptiondes architectures, guides de codage, etc.Les questions du chef de projet sont d’abord des plus pertinentes, par exemple : « Comment allez-vous valider nos livraisons et avec quels délais ? » Mais les choses ne tardent pas à se gâter. Leslivraisons sont en retard, les sujets mal compris s’étendent, et l’incompréhension s’installe entre laFrance et le prestataire en offshore. Au bout d’un certain temps, l’éditeur de logiciels se rendcompte que le chef de projet ne prend pas même la peine de lire les documents sur les spécifica-tions du produit à développer, les priorités et les guides. Les règles de codage ne sont pas respectées.Le produit est finalement livré, mais dans une cacophonie non maîtrisée, avec plus de 200 % deretard. Pour l’éditeur de logiciel, le développement en offshore est considéré comme un échec.Le chef de projet a clairement atteint ses limites de compétences. Il a répété ce qu’il a vu faire en débutde projet mais n’a pas su s’adapter pour gérer son équipe, ni exploiter les documents qu’il a lui-mêmedemandés. Un management direct de l’équipe par le client aurait certainement immédiatementdétecté cet état de fait et aurait probablement été en mesure de prendre les décisions opportunes.



37

les prestations. Par exemple, l’un dit qu’il paye ses collaborateurs en offshore entre 400et 600 dollars par mois, ce qui semble très peu à l’autre, dont la société débourse2 000 dollars par mois pour chaque collaborateur. Nous verrons au chapitre 3 que cesdifférences s’expliquent très bien et que nous ne faisons là que comparer des servicesincomparables. L’impression de se faire avoir est parfois si bien ancrée que le managerfrançais refuse d’écouter les explications et exige une renégociation du contrat.

D’autres managers ont simplement eu vent de certains échecs de sociétés françaises ouaméricaines qui ont été tout bonnement flouées par un prestataire indélicat. Ceux-là onttendance à mettre en place un suivi draconien au détriment de la productivité. D’autresencore partent du principe que la différence de niveau de vie entre les pays de l’offshoreet le leur est tel que le prestataire en offshore ne peut que chercher par tous les moyensà extirper le maximum d’argent de son client. Il considère dès lors presque maladivementque toute action du prestataire a un objectif caché.

Quelles que soient les raisons, le sentiment irrationnel de se faire rouler peut l’emporter surla qualité observée du partenariat et sur le respect constaté des engagements contractuels.Tout ce que peut dire le partenaire est révoqué en doute, à commencer par le coût des pres-tations. On oublie alors que le prix pratiqué est certainement comparable à celui des autresprestataires offshore et en tout cas très inférieur à celui des salaires ou de la régie en France .

Parfois, l’attitude des managers, notamment français, vire carrément à la paranoïa. Certainsd’entre eux s’imaginent que des développeurs fantômes sont facturés, par exemp le.Pour se rassurer, ils commandent des missions d’audit ou effectuent des visites surprises.D’autres supposent que les développeurs ne touchent pas réellement les salairesfacturés. Si les vérifications entreprises par ces managers ne donnent rien, ils demeurentpersuadés que le prestataire est encore plus malin qu’ils ne l’imaginent.

Que certains audits soient réalisés est une chose normale, mais qu’un climat de méfianceexacerbé soit entretenu artificiellement entre le prestataire offshore et son client ne peutque nuire à leurs relations. Une fois la suspicion installée, elle ne disparaît pas aisément,et toute tentative pour établir la qualité du partenariat est qualifiée de naïve.

Ce type de comportement est hélas largement répandu. Sur une centaine de sociétés fran-çaises et américaines qui ont travaillé avec l’offshore, on estime que la moitié l’a adoptéà des degrés divers. Pour 20 % d’entre elles, la méfiance vis-à-vis de l’offshore est consi-dérée comme ayant nui au bon fonctionnement des opérations.

EN RÉSUMÉLa suspicion nuit au partenariat

Un climat de suspicion entre la société cliente et le prestataire offshore peut nuire si fortement à lacollaboration que les managers de part et d’autre peuvent en venir à préférer que le projet s’arrête.

Les pays de l’offshore

Cette section présente succinctement les pays de l’offshore et les raisons pour lesquellesces pays peuvent fournir des prestations de services informatiques de qualité. Nous yrevenons beaucoup plus en détail dans la deuxième partie de l’ouvrage afin de guider lelecteur dans les critères de choix d’un prestataire offshore.



38

Des salaires faiblesTous les pays qui offrent aux informaticiens des salaires faibles en comparaison de ceuxdu pays du client sont potentiellement candidats à la fourniture de prestations informati-ques en offshore. Dans certains pays, les salaires mensuels bruts des informaticiens lesmoins bien payés sont de l’ordre de 100 dollars par mois. Les salaires élevés se limitentgénéralement à 1 000 dollars par mois, voire 1 300 dollars pour un manager de haut niveau.

Il existe cependant de grandes disparités de salaires entre ces pays. Dans certains d’entreeux, on trouve un très large spectre de salaires dans une même équipe, avec des déve-loppeurs débutants payés 100 dollars et d’autres qui atteignent 1 500 dollars, voiredavantage. C’est le cas de la plupart des pays de l’Est. Dans d’autres pays, notammenten Asie, on constate un resserrement entre 300 et 600 dollars au maximum. Même despays où les salaires ne sont qu’un petit peu plus faibles que ceux du pays du clientconstituent un attrait pour ce dernier. Le Canada, par exemple, où les salaires sont géné-ralement de 20 % inférieurs à ceux des États-unis, joue le rôle de pays de l’offshore pourles Américains. Dans la plupart des pays de l’offshore, les salaires sont très inférieurs àceux pratiqués en France.

Le salaire que reçoit le collaborateur en offshore importe finalement assez peu, sauf dansle cas où l’on souhaiterait créer sa propre société en offshore pour y gérer directement sonéquipe. Ce qui importe, c’est la tarification du prestataire offshore et les conditions quis’y attachent. Ce sujet est abordé en détail au chapitre 8. On peut raisonnablementestimer que les prestations en offshore sont facturées en moyenne entre 80 et 300 dollarspar jour et par personne.

Inde, Europe de l’Est, Asie et MaghrebLe premier pays de l’offshore est sans conteste l’Inde. Les Indiens ont été les premiers àproposer des prestations de services informatiques à grande échelle et à faibles coûts auxsociétés américaines.

L’environnement de l’Inde est très favorable. Les universités sont réputées et formentdes scientifiques de haut niveau, qui travaillent depuis longtemps aux États-Unis. Denombreux postes de management importants sont tenus aux États-Unis et en Grande-Bretagne par des personnes d’origine indienne. Certains de ces managers indiens ont suprendre très tôt la responsabilité de travailler avec des équipes distantes en Inde.

Aujourd’hui, environ 80 % des prestations en offshore sont réalisées en Inde, le reste dumonde se partageant les 20 % restants. Il est tout aussi intéressant de constater que plusde 80 % des clients de l’offshore sont aux États-Unis et au Royaume-Uni, pays culturellementproches de l’Inde.

L’Europe de l’Est peut être considérée comme un immense réservoir de ressourcesfutures pour l’offshore. Les cinq grands centres universitaires de l’ex-URSS (Moscou,Saint-Pétersbourg et Novossibirsk en Russie, Kiev en Ukraine et Minsk au Belarus) restentdes pépinières très dynamiques, qui produisent en quantité des informaticiens dequalité. D’autres pays d’Europe de l’Est proposent également des ressources de qualité,notamment la Roumanie, la Bulgarie, la République tchèque, la Serbie, la Slovaquie, laPologne et les États baltes. Souvent, seule la capitale attire les meilleures ressources.



39

En Asie, la Chine est un nouvel entrant très agressif. Dotée de quantité de ressources trèscapables, elle pourrait fournir à l’avenir bien plus de ressources que l’Inde. L’Indonésie,les Philippines et le Vietnam offrent aussi nombre de prestataires offshore.

Au Moyen-Orient, Israël et le Liban proposent des prestations offshore, mais leurs tarifsne sont plus vraiment compétitifs.

Les pays du Maghreb proposent assez naturellement à la France des prestations offshore,avec pour atout principal leur proximité historique et culturelle. Il en va de même de l’ÎleMaurice, très active pour proposer ses prestations offshore en France. De même, laRoumanie met en avant sa capacité à créer des équipes de langue française.

La figure 2.1 présente les positions géographiques des principaux pays de l’offshore pourl’Europe. On peut se rendre compte de l’éloignement de certains de ces pays et des payslimitrophes. On repérera notamment l’éloignement de pays tels que l’Inde, la Chine etl’Île Maurice, par rapport aux pays de nearshore, qui sont proches et faciles d’accès. Letableau 2.2 récapitule pour chacun de ces pays les niveaux de coûts estimés en trois caté-gories, faibles (1), moyens (2) et élevés (3). Dans chacun de ces pays, on trouve des contre-exemples de sociétés prêtes à travailler pour moins cher ou d’autres demandant des tarifstrès élevés.

Figure 2.1. Les pays de l’offshore



40

D’autres pays proposent des prestations offshore, surtout pour les États-Unis, mais ilssont peu attractifs pour l’Europe. On trouve dans cette catégorie les pays d’Amérique duSud, comme le Brésil, la Colombie, l’Argentine, le Chili, les pays d’Amérique centrale,essentiellement le Mexique, et même, comme expliqué précédemment, le Canada. Tousles pays du continent américain ont un décalage horaire comparable à celui des États-Unis, qui compte quatre fuseaux horaires.

Tableau 2.2. Particularités et niveaux de coûts des pays de l’offshore

ParticularitéNiveau de coût

Inde Premier pays de l’offshore. Très grande pratique des projets au forfait. Proximité culturelle anglo-saxonne. Risque de saturation par les États-Unis

2-3

Russie Nearshore. Pays sous-exploité par les États-Unis, avec d’énormes réser-ves en informaticiens. Très fortes compétences sur les sujets techniques

1-2

Belarus, Ukraine Nearshore. Pays presque totalement ignorés par les États-Unis. Réserves en informaticiens très importantes. Coûts significativement plus faibles qu’en Russie

1-2

Roumanie Nearshore. Fort potentiel pour créer des équipes en langue française 2-3

Île Maurice Fort potentiel pour créer des équipes en langue française. Mélange d’Inde et de francophonie. Attrait touristique

2-3

Chine Énorme potentiel pour l’offshore, qui en est au stade du commencement. Les différences culturelles en font un pays difficile à aborder.

1

Tunisie, Maroc, Algérie

Nearshore. Fort potentiel pour créer des équipes en langue française 2-3

Pologne, États baltes, République tchèque, Slovaquie

Nearshore. Pays d’offshore pour quelques années encore. L’intégration dans l’Europe crée une dynamique qui éloigne ces pays de l’offshore.

2-3

Liban Fort potentiel pour créer des équipes en langue française. Région très tourmentée

2-3

Israël Prix très élevés. Région tourmentée 3

Philippines Très actif, surtout vers les États-Unis où la proximité culturelle est importante.

1-2

Vietnam Très actif vers les États-Unis. A tenté de se positionner comme un pays proposant des prestations en langue française mais sans grand succès.

1-2

Canada, Amérique du Sud

Pays d’offshore pour les États-Unis, sans grand intérêt pour les sociétés européennes

2-3



41

Niveaux de coûts et seuils limitesDans chaque pays de l’offshore, les prestataires proposent des coûts très variables. Onpeut toujours rechercher les coûts les plus faibles, mais, en deçà d’une certaine valeur,l’économie réalisée se paie en perte de productivité.

À l’inverse, au-delà de certains niveaux de coûts, le produit fourni par le prestataire n’estpas meilleur ou même dans certains cas est inférieur, les collaborateurs du prestataireoffshore pouvant avoir du mal à gérer des prestations d’une qualité supérieure. Ce sujetest abordé en détail au chapitre 3.

La figure 2.2 montre qu’au-delà d’un certain seuil, la recherche de l’économie avec uneéquipe donnée n’apporte plus de gain de productivité. Les causes à cela peuvent êtrenombreuses mais sont faciles à comprendre : le prestataire choisira des collaborateursacceptant des salaires plus faibles, il ne fera pas d’efforts pour fournir un environnementde travail agréable, les bons profils seront rapidement placés sur d’autres affaires plusprofitables, et les services complémentaires seront limités au strict minimum. On observemême parfois un phénomène plus étonnant : lorsqu’on paye le prestataire beaucoup plusqu’il ne pense nécessaire, il arrive que la productivité diminue rapidement. Cela peuts’expliquer par l’interprétation qu’en fait le prestataire. Il imagine que son client ne s’inté-resse pas au coût de la production et néglige la recherche de la productivité en offshore.

Pro

duc

tivité

Coût par personne

Les coûts des prestations sont liés

à la productivité.

L’augmentation des coûts des prestations n’accroît plus la

productivité.

Les coûts bas nuisent à la productivité.

Dans certains cas, les coûts élevés nuisent

à la productivité.

Figure 2.2. Coûts des prestations et productivité



42

De plus, certaines personnes, payées beaucoup plus qu’elles ne valent sur le marché,commencent à s’arroger des rôles bien au-delà de leurs responsabilités et parfois de leurscapacités, tout en négligeant leurs responsabilités directes.

La figure 2.3 illustre l’existence d’une valeur optimale à verser au prestataire en offshorepour obtenir la meilleure productivité. Un versement plus important n’apporte plus deproductivité, et tout niveau de prix inférieur entraîne une perte de productivité plusimportante que l’économie réalisée, rendant ainsi l’efficacité des opérations plus faible.On peut aussi comparer l’efficacité des équipes en offshore avec celle des équipes locales,qui est représentée par une ligne horizontale. On voit ainsi que les équipes en offshore nesont pas toujours financièrement plus efficaces que les équipes locales et qu’il faut porterune attention soutenue à la recherche du point optimal.

Universités et marques d’éducationTous les pays où l’on trouve une main-d’œuvre à faible coût ne sont pas pour autant de bonspays de l’offshore. L’Afrique noire, par exemple, n’est généralement pas réputée pour abriterdes pays d’offshore. Il est essentiel que les pays de l’offshore aient de bonnes ressourcesinformatiques et donc des universités reconnues dans le monde de l’informatique.

Certains pays réputés pour leurs ressources informatiques n’offrent le niveau d’éducationsouhaité que dans la capitale ou dans certaines grandes villes. Dès que l’on quitte cescentres universitaires, la qualité des ressources s’en ressent. Les bons éléments préfèrentaller vivre dans la capitale, où ils trouvent des offres d’emploi au niveau de leurs attentes.

Pro

duct

ivité

par

dol

lar

Coût des prestations

Productivité aux mêmes coûts qu’en

France

La productivité augmente plus rapidement que les coûts.

La productivité n’augmente plus aussi

rapidement que les coûts.

Point de productivité optimal

Figure 2.3 Productivité par dollar dépensé en offshore en fonction de l’économie réalisée



43

Dans certains pays, comme l’Inde, des régions se sont spécialisées dans les prestationsoffshore et attirent les meilleurs profils. C’est le cas du Bangalore , qui est une vraie SiliconValley de l’offshore en Inde, rassemblant l’essentiel des sociétés de haute technologie dupays dans la même région et, par là même, attirant les meilleures ressources qui cher-chent à y faire carrière. S’il reste possible de constituer de bonnes équipes dans lesprovinces, c’est plus difficile. Les équipes importantes sont en revanche beaucoup plusdifficiles à monter.

EN RÉSUMÉLes capitales, fiefs de l’offshore

Les capitales ou, en Inde, certaines provinces, comme le Bangalore, sont les lieux privilégiés pourcréer rapidement les meilleures équipes.

Entre la capitale et les villes de province, on constate dans la grande majorité des cas desdifférences de salaires très importantes. Les villes de province sont souvent délaisséespar les bons informaticiens, car les emplois gratifiants et bien rémunérés y sont rares.On y rencontre cependant parfois un prestataire offshore de qualité, capable d’attirer lesbons profils de la région. Les salaires pratiqués dans sa région étant inférieurs à ceux dela capitale, il peut proposer des tarifs très attractifs. De leur côté, les informaticiens de larégion ne veulent pas risquer de perdre un bon poste dans une ville où les offres d’emploiintéressantes sont rares. Précisons que ces profils sont le plus souvent moins qualifiésque ceux de la capitale.

Dans un certain nombre de pays de l’offshore, on trouve une pratique presque inconnueen France, consistant à organiser des challenges. Il existe deux types de challenges, ceuxdes entités gouvernementales du pays et ceux des grandes sociétés internationales. Parexemple, HP organise le HP Global Business Challenge (www.jaintl.org/hpgbc/) et IBM l’Interna-tional Collegiate Programming Contest (http://icpc.baylor.edu/icpc/) et les International MathematicsCompetition for University Students (http://www.imc-math.org/).

Les gouvernements de certains pays d’offshore proposent des olympiades, comme leBelarusian Economics Olympiads, qui opposent le plus souvent des équipes. Les personnesles mieux placées dans les équipes bénéficient de conditions plus avantageuses pourcontinuer leurs études.

Chaque année, les personnes ayant réussi à bien se positionner dans ces concours sevoient offrir des postes dans les meilleures sociétés locales et parfois même les meilleuresentreprises aux États-Unis. Les pays se plaisent à se classer entre eux selon les résultatsobtenus à ces concours, qui font autorité.

Une autre marque de qualité de l’éducation est incarnée par les certificats délivrés par dessites Internet, à l’image de BrainBench (www.brainbench.com). Comme pour les certificationsdes grands éditeurs, par exemple, Microsoft, une série de questions délicates sont poséessur Internet pendant une durée limitée. Le candidat s’engage sur l’honneur à ne pas sefaire aider. Selon son succès ou son échec, il reçoit ou non la certification, accompagnéed’une note. Les domaines de certifications vont du français ou de l’anglais à la program-mation Java en passant par l’administration Windows XP, Linux, etc. Les candidats àl’embauche des pays de l’offshore placent souvent dans leurs CV de tels certifi cats on-line.

Dans tous les cas, une localisation offshore de qualité est un lieu où l’on trouve de bonnesuniversités. La plupart du temps, une ou deux villes seulement correspondent à cescritères.


http://www.jaintl.org/hpgbc/

http://icpc.baylor.edu/icpc/

http://www.imc-math.org/



44

La stabilité politiqueLa stabilité politique du pays est un facteur important pour déterminer avec quels pays ilest possible de travailler. Les apparences sont toutefois trompeuses. Des événementsmajeurs, comme la chute de Ceausescu en Roumanie, ont eu peu d’influence sur les pres-tations des équipes offshore. Les employés se sont présentés presque normalement et letravail a avancé comme les autres jours. De même, les tragédies politiques contempo-raines en Israël et au Liban ont certes ralenti les prestations offshore mais ne les ont pasarrêtées.

En règle générale, lorsqu’il y a des difficultés dans un pays, le fait de travailler pour desprojets en offshore apporte une sécurité et une assurance face à la tourmente du pays. Lespaiements proviennent de pays étrangers, qui ne connaissent pas les mêmes troubles, etdont la capacité à payer n’est pas affectée. La monnaie utilisée est le plus souvent ledollar ou l’euro, qui sont assez bien protégés contre les taux d’inflation galopants que l’onconstate dans les pays en difficulté. Les employés peuvent penser, à juste titre, que lespaiements de leurs salaires sont pratiquement garantis pour peu que le travail continuenormalement.

Même si le travail peut continuer localement, on doit se demander si les chefs de projetde la société cliente de l’offshore accepteront de se rendre sur place. Les déplacementsen Algérie avaient été refusés par de nombreux chefs de projet dans la période où ce quel’on a appelé la montée de l’intégrisme s’accompagnait d’assassinats en masse. Demême, les déplacements en Israël ne sont pas bien ressentis lorsque les attentats s’inten-sifient. Même l’Inde a commencé à poser problème lorsque les tensions avec le Pakistanse sont intensifiées et que de nombreux chefs de projet ont refusé de se rendre sur place.

EN RÉSUMÉLe risque politique

Il faut un désordre très important pour que l’équipe en offshore s’arrête de travailler. Dès lespremiers troubles, il est toutefois possible que les chefs de projet du client de l’offshore refusent dese rendre sur place.

Les prestataires offshore

À la manière des sociétés de services en France, les prestataires offshore vont de la toutepetite société, parfois constituée d’une personne unique jusqu’aux géants, qui emploientplus de dix mille collaborateurs, comme en Inde.

Les prestataires offshore commencent le plus souvent à travailler dans le domaine de lafourniture de services à des sociétés européennes ou américaines, souvent grâce à un amiqui est allé dans un de ces pays et qui, dans le cadre de son travail, a fait naturellementla promotion de l’opportunité d’utiliser les ressources de son pays.

On trouve souvent dans les pays de l’offshore des concepts de sociétés étonnants. Parexemple, dans les anciens pays communistes, lorsque la libre entreprise a commencé àexister, on trouvait des sociétés qui, en plus du développement informatique, se consa-craient à la pêcherie ou à l’exploitation forestière. La plupart de ces sociétés se sont



45

finalement spécialisées et concentrées sur l’informatique, mais on en rencontre encoreaux activités disparates.

On peut classer les prestataires offshore en plusieurs catégories, mais il est parfoisimpossible d’attribuer une catégorie unique à un prestataire offshore. On trouve desgéants, comme en Inde, des multinationales, des leaders locaux, des petits prestataireset des sociétés dédiées à un client.

Les géants de l’offshoreLes géants de l’offshore ne se rencontrent pratiquement qu’en Inde. Ils ont souvent desfiliales importantes dans de nombreux pays, comme les États-Unis, la Grande-Bretagneet parfois même la France et l’Allemagne.

Ces sociétés peuvent s’adapter aux gros projets comme aux petits, mais ne s’intéressentguère aux projets de moins d’une douzaine de personnes, ce seuil pouvant évoluer selonles périodes.

L’Inde recevant la très grande majorité des prestations de conseil en offshore, cesdernières constatent une insuffisance des ressources de qualité susceptibles de gérer effi-cacement les projets et de communiquer avec les clients. Les profils plus communs sonten revanche toujours assez faciles à recruter, quitte à aller les chercher dans d’autres villesou à les débaucher d’entreprises locales.

Les chefs de projet expérimentés et les profils techniques plus pointus sont devenus desperles rares. La plupart de ces géants ont beaucoup de mal à les attribuer de façon stableà un projet et préfèrent une gestion dynamique de ces ressources, en les plaçant sur leprojet où elles seront les plus utiles de leur point de vue.

Les géants indiens se sont engagé dans le rachat de prestataires offshore dans denombreux pays, notamment en Russie et dans d’autres pays de l’ex-URSS, étendant ainsileur couverture géographique et leur capacité à embaucher de nouvelles ressources.

On peut se demander comment ces sociétés vont évoluer dans le temps alors que lesanalystes prévoient une pénurie de main-d’œuvre informatique et le triplement dessalaires locaux en Inde. Une telle augmentation des salaires entraînerait inévitablementune hausse significative des tarifs pratiqués par les prestataires offshore. Dans quellemesure l’immense attraction dont l’Inde bénéficie aujourd’hui persistera-t-elle ? L’évolu-tion probable de ces géants indiens consistera à proposer des prestations à partir d’autrespays de façon à maintenir des prix attractifs.

Les multinationales de l’offshoreCertains prestataires offshore ont une présence multinationale, la maison mère étantsituée le plus souvent aux États-Unis et les centres de développement dans plusieurspays d’offshore, souvent dans une même région. Par exemple, il arrive que l’on trouve descentres de développement en Russie (Moscou et Saint-Pétersbourg), au Belarus (Minsk)et en Ukraine (Kiev). Le nombre d’employés de ces sociétés peut dépasser mille collabo-rateurs, répartis très inégalement entre les centres de développement.

La maison mère agit le plus souvent elle-même comme une société de services locale, parexemple, aux États-Unis, mais en s’appuyant sur des prestations réalisées en offshore.Elle dispose localement d’équipes importantes, qui peuvent représenter le tiers du totaldes personnes impliquées dans un projet.



46

On commence à trouver de telles sociétés en France, bien que leur développement soitencore timide.

Ces sociétés fonctionnent selon des règles strictes. Elles ont mis en place des procéduresrigides, assez peu adaptables aux désirs des clients. Les procédures ont fait leurs preuves,et, pour ces prestataires, tout changement est un risque qu’il peut être difficile d’assumer.Les procédures sont surtout conçues pour des développements au forfait, dans lesquelsles prestataires organisent la bonne marche du projet. Elles ont même souvent mis enplace leur propre méthodologie, élaborée dans le temps et fonctionnant de façon satis-faisante.

Cette méthodologie fait elle-même partie de ce qui est considéré comme un élémentimportant de la valeur de l’entreprise. Les nouveaux membres y sont formés dès leurarrivée et signent des engagements de confidentialité, qui visent à en prévenir l’expor-tation vers d’autres équipes. On y trouve donc souvent une sensibilité extrême à la protec-tion des informations et des méthodes. Même les relations entre les membres deséquipes sont parfois contrôlées avec beaucoup de rigueur. Par exemple, telle société vapartitionner profondément les tâches qui sont confiées à chaque développeur, de façonque personne ne sache sur quoi travaillent les autres. Selon leur rôle, les membres deséquipes portent des tee-shirts d’une couleur différente. Les chefs de projet, tous revêtusd’un tee-shirt de même couleur, n’ont pas le droit de se parler entre eux, ni mêmed’essayer de lier connaissance.

Ces sociétés acceptent rarement des prestations autrement qu’au forfait. De ce fait, ellesont peu de clients parmi les sociétés de services, qui sont plutôt leurs concurrentes, oules éditeurs de logiciels.

Le centre névralgique de ces sociétés est la maison mère, généralement située aux États-Unis. Elles adaptent leurs centres de développements selon l’évolution des marchés enessayant de maintenir une proximité géographique avec tous les sites offshore qu’ellescréent.

Les leaders en offshoreLes leaders locaux représentent sans doute le potentiel le plus important pour les déve-loppements offshore. Ce sont des sociétés qui ont choisi d’assurer des développementspour des sociétés essentiellement européennes et américaines. Elles comptent souventplus de 100 collaborateurs et travaillent avec de nombreux clients selon des modes enrégie ou au forfait. Parfois, les prestations démarrent et se poursuivent à la satisfaction dechacune des parties sans même qu’un contrat ait été signé. Ces sociétés essaient toujoursde conserver une grande adhérence aux souhaits de chaque client afin de le satisfaire àtout prix.

Certaines d’entre elles disposent d’un représentant dans un pays occidental afi n d’effec-tuer une prospection commerciale. Ce dernier est rémunéré uniquement au succès. Ilarrive que plusieurs représentants d’un même leader local travaillent de cette façon. Dansquelques cas rares, une société officiellement constituée représente localement la sociétéoffshore et agit comme une antenne commerciale. C’est toutefois rarement une filiale duprestataire offshore.

Les développements représentent généralement des contrats de 6 à 30 collaborateurs.Certaines affaires plus rares peuvent mettre en jeu une équipe d’une centaine de collabo-rateurs, mais ces cas correspondent généralement à la montée en charge progressive d’un



47

projet. La moyenne des contrats se situe le plus souvent autour de la quinzaine de colla-borateurs, incluant les équipes de test.

Ces sociétés particulièrement flexibles sont capables de s’adapter aux méthodes detravail de chaque client. Vous pouvez, si vous le souhaitez, créer une équipe dédiée quevous contrôlez pleinement ou, au contraire, maintenir une équipe dynamique essentiel-lement gérée par les managers offshore ou même déléguer des projets au forfait.

Leur volonté de réussir est telle que ces sociétés se montrent très accommodantes pourabsorber vos changements de stratégie ou pallier votre manque de personnel.

Dans les pays de l’offshore, les leaders locaux sont bien connus des meilleures univer-sités. Ils souhaitent attirer les meilleurs profils, notamment ceux qui ont obtenu lesmeilleures notes dans les universités ou aux olympiades et font tout leur possible pourapparaître comme une opportunité de choix pour les nouveaux diplômés. Les argumentsqu’ils mettent en avant sont les conditions de travail, la nature des projets à réaliser, lestechnologies employées et, bien sûr, les salaires. La durée et la stabilité des contrats quisont confiés au prestataire sont également des atouts majeurs.

EN RÉSUMÉLes leaders locaux, partenaires privilégiés

Les leaders locaux offrent les meilleures garanties de flexibilité et d’adaptabilité aux projets etméthodes de gestion de projet offshore. Ce sont les partenaires à privilégier en offshore.

Les managers de ces sociétés maintiennent des relations étroites avec les universités. Il n’estpas rare de trouver un manager qui y donne des cours ou y tient un rôle honorifique assezimportant. Les étudiants en fin d’études trouvent par ailleurs dans ces sociétés des occasionsde stage.

Une fois que ces sociétés ont réussi à se présenter comme un des meilleurs choix,les talents se présentent régulièrement, et il n’est pas difficile de monter des équipesimportantes très rapidement.

Certaines d’entre elles proposent des cursus payants complémentaires à l’université afinde mieux préparer les nouveaux diplômés au monde du travail, notamment à la gestionde projet en offshore.

À la fin de leurs études, les étudiants de certains pays, par exemple, de l’ex-URSS, doiventà l’État un certain nombre d’années de service, le plus souvent dans des organismesnationaux mais aussi dans des sociétés accréditées. Les leaders de l’offshore sont géné-ralement accrédités pour recevoir ces étudiants, offrant à ces derniers l’occasion à la foisd’échapper aux organismes d’État, qui offrent des salaires très faibles, et d’acquérir immé-diatement une expérience professionnelle.

Avec le temps, les sociétés qui jouissent d’une solide réputation dans leur pays voientleur marché s’ouvrir et les contrats avec les entreprises nationales devenir de plus en plusnombreux et rentables.

Les managers de ces sociétés sont parfois déroutants. Certains d’entre eux peuvent semontrer extrêmement sérieux et précis dans leurs communications et afficher soudaine-ment de graves lacunes. D’autres sont plus fantasques encore et ne répondent aux ques-tions posées que selon leur humeur. Pour travailler correctement avec eux, il faut prendresoi-même la communication en main et la gérer de bout en bout. Il ne faut pas hésiter à



48

relancer les e-mails sans réponse, réexpliquer constamment ce que l’on attend du parte-naire et ne pas se décourager lorsque les échanges semblent déroutants.

Les leaders de l’offshore sont certainement les plus dynamiques et les plus flexibles pourtravailler efficacement. S’ils offrent toutes les garanties de succès et de sérieux, ils ne sontpas toujours aisément discernables des autres prestataires offshore, plus petits.

Cet ouvrage est principalement consacré à la conduite de projet avec ces leaders del’offshore.

Les petits prestataires offshoreEn dehors des leaders de l’offshore, beaucoup de petites sociétés se démènent pourtrouver des contrats. Parfois, elles ne sont pas même officiellement constituées etopèrent sans existence juridique. Cela représente évidemment un risque pour le client,qui peut voir son équipe disparaître du jour au lendemain suite à une procédure judi-ciaire. Le client peut lui-même se voir inquiéter pour avoir réglé des factures à une sociétésans existence légale.

On ne peut se rendre compte de ce que sont ces sociétés qu’en se rendant sur place.Certaines d’entre elles sont de vraies sociétés qui prennent leur essor, tandis que d’autrestravaillent depuis un appartement sommairement organisé, en exploitant chaque mètrecarré disponible et en recourant à une installation informatique plus que précaire.

Dans tous les cas, leur site Internet est magnifique, souvent meilleur que ceux desleaders ou des géants de l’offshore. Ces sites sont évidemment leurs meilleurs atoutscommerciaux.

Certaines de ces sociétés ont connu des déboires sur leur marché national et cherchent àse diversifier au moyen de prestations offshore. Le problème est qu’elles ignorent toutdes pratiques des clients de l’offshore ou même simplement de ce qu’est un client ou laproductivité. J’en ai connu qui exigeaient de toucher des royalties (droits de licence) avecun pourcentage très élevé en plus d’une rémunération au forfait.

Il est toujours possible de prendre le risque de travailler avec de telles sociétés, àcondition de faire le bon choix et de les accompagner sur la voie du succès. Avec un peude chance et de talent, quelques-uns de ces prestataires deviendront des leaders del’offshore.

EN RÉSUMÉLes petits prestataires offshore

Malgré des tarifs souvent très avantageux et des sites Internet remarquables, les petits prestatairesn’ont souvent pas d’existence légale. Il n’est pas rare de les voir disparaître en cours de projet.

Les prestataires dédiés à un clientIl arrive que des sociétés européennes ou américaines choisissent de créer leur proprestructure dans le pays de leur choix, parfois en partenariat (joint-venture) avec unepersonne de confiance ou une société dans le pays. Les raisons de ces démarches sontvraisemblablement une recherche d’optimisation des tarifs payés pour les dévelop-pements distribués ou une préoccupation accrue de confidentialité des informations quel’on souhaite contrôler en tous points.



49

On retrouve ici un cas proche des multinationales, à la différence près que la société quiutilise l’offshore n’est pas nécessairement une société qui revend des prestations deservices. On peut trouver un éditeur de logiciel ou un consommateur de développementsinformatiques, qui, à l’origine, a créé cette société pour ses besoins propres.

Il est vrai que les tarifs payés à son prestataire par le client de l’offshore sont de l’ordre de100 à 200 dollars par personne/jour alors que le salaire de cette même personne est de 15 à40 euros. Comme expliqué précédemment dans ce chapitre, certains clients se demandentsi les prestataires offshore ne s’octroient pas des marges exagérées, une part importantede ces clients sombrant même parfois dans la paranoïa.

En réalité, le montant de ces marges de 10 à 40 % est justifié par les charges sociales, lesloyers à payer pour les locaux, les périodes d’intercontrat, les efforts de management pourgérer les équipes, les commissions versées aux commerciaux ou apporteurs d’affaires, lesbonus qui sont souvent payés aux collaborateurs et qui constituent une part de leur moti-vation, les commissions de vente et enfin les non-paiements de certains clients, quivoient le prestataire payer tout de même une partie du salaire aux collaborateurs.Certains clients suspicieux exigent le détail des coûts internes et se rendent finalementcompte qu’ils paient un prix assez juste. Ce sujet est abordé plus en détail au chapitre 4.

Hormis la confidentialité des informations, la création d’une structure dans un pays del’offshore n’apporte aucun avantage franc, si ce n’est une maîtrise plus fine des coûtsde développement. Ces sociétés sont moins expertes dans la gestion de l’exploitationd’une structure dans le pays de l’offshore, et leur gestion est souvent moins efficace etplus coûteuse. Dans les cas les plus favorables, on peut espérer réduire le coût des pres-tations de développement de l’ordre de 10 à 20 %, rarement plus. Parfois, les inconvé-nients de ce type d’approche, comme la difficulté à attirer les meilleurs profils, les tauximportants de renouvellement du personnel ou l’obscurité de la fiscalité locale, l’empor-tent sur les avantages, et l’on se retrouve à assurer des prestations de faible qualité ou d’unprix supérieur à ce que l’on trouve chez un prestataire offshore.

Ces sociétés, souvent assez petites, rencontrent plusieurs types de problèmes qu’ellesdoivent surmonter alors que ces derniers sont transparents lorsqu’on travaille avec unprestataire. Elles doivent en outre savoir travailler avec les lois et usages locaux, qui sontparfois opaques et contradictoires. Cela nécessite de savoir faire jouer ses relations pourrégler les problèmes. Les comptes de ces sociétés en offshore feront partie des comptesde la maison mère et devront être tenus avec la rigueur des comptabilités françaises, cequi n’est pas toujours facile dans ces pays.

La taille et l’activité de telles sociétés n’en font pas pour autant des leaders de l’offshore,et elles restent le plus souvent inconnues des étudiants et des informaticiens en offshore.La création d’équipes compétentes n’est donc pas chose aisée, et l’on ne trouve pastoujours rapidement les ressources souhaitées. Ce sujet est détaillé au chapitre 4.

Il arrive que les managers de ces sociétés souhaitent ouvrir leurs activités à d’autressociétés, par exemple, à la suite d’une réduction d’effectifs, qui laisse des ingénieurs dequalité sans travail, ou parce qu’ils souhaitent diversifier leur activité. Si l’on envisage dedevenir le client d’un tel prestataire offshore, il faut porter une attention particulière auniveau de priorité que l’on peut avoir par rapport au client privilégié qu’est la maisonmère.



50

Évolution des pays de l’offshoreCe qui fait la vertu d’un pays de l’offshore peut s’évanouir avec le temps. Les salairesofferts ne resteront pas toujours aussi faibles, par exemple. En Pologne, notamment, ilsont augmenté de façon importante depuis l’ouverture aux marchés occidentaux. Il en vade même des pays qui ont pu et su se rapprocher de la Communauté européenne et quiont vu ou verront leur niveau économique se rapprocher de la moyenne de la CEE.

Beaucoup de ces pays, en particulier les anciens pays de l’Est, ne sont pas naturellementpauvres. Ils disposent de ressources naturelles importantes, d’une infrastructure indus-trielle certes vieillissante, mais avec des sites isolés montrant des capacités à exploiteravec succès les technologies les plus récentes. Bien souvent, ces pays ont d’excellentesuniversités, qui forment des diplômés ambitieux souhaitant réussir dans leur pays.

La pauvreté actuelle de ces pays provient surtout d’événements bien identifiés qui les ontdéstabilisés, et ils retrouveront productivité et richesse plus ou moins rapidement. Despays comme la Russie, l’Ukraine, la Roumanie, la Pologne ou les Pays baltes atteindrontcertainement un niveau de vie comparable au reste de l’Europe, peut-être plus rapidementque le Belarus ou la Moldavie.

Les prestataires offshore travaillent parfois avec des sociétés nationales mais pas auxmêmes tarifs que ceux pratiqués en tant que prestataire offshore. Cela concerne souventdes réalisations de prestige pour la société, parfois réalisées à perte.

Dans les pays de l’Est, on peut imaginer que les marchés des prestations informatiquesnationaux continueront de se développer jusqu’au moment où les marges réalisées en tantque prestataire offshore et sur les marchés nationaux seront proches. Les prestations natio-nales s’effectueront à des niveaux tarifaires plus élevés. Au fur et à mesure que les salaireslocaux s’élèveront, ces pays deviendront de moins en moins intéressants pour l’offshore. Lessociétés qui y proposaient des services en offshore deviendront des sociétés de servicesnationales et pratiqueront une tarification similaire, que le client soit national ou occidental.

Cette tendance peut être constatée dès aujourd’hui à Moscou, où certains prestatairesembauchent des développeurs à des salaires mensuels situés entre 1 000 et 2 500 dollars.D’autres pays, comme la Roumanie, ont constaté par moments une pénurie de certainsprofils du fait d’une forte demande sur le marché national, laquelle a rapidement faitmonter les salaires de 300 dollars mensuels à quatre ou cinq fois plus.

La figure 2.4 illustre l’évolution du coût de la prestation facturée en tant que prestataireoffshore et prestataire national. Du fait de l’évolution du marché national, de l’augmen-tation des salaires locaux et du rapprochement des tarifications offshore et nationales, leprestataire se tourne naturellement vers son marché national et devient moins intéressantcomme prestataire offshore.

Depuis la prophétie apocryphe de Napoléon en 1816, on se demande « quand la Chines’éveillera », tant son potentiel est énorme. On peut raisonnablement imaginer que cenouveau venu dans l’offshore restera une destination de choix pendant encore long-temps.

L’Inde risque de saturer rapidement ses ressources informatiques si les prévisions seréalisent. On parle de triplement des salaires locaux dans les années à venir, ce qui rendraimmanquablement les prestations indiennes moins intéressantes. Il n’est pas impossibleque les nouveaux contrats de développement, notamment ceux des États-Unis, se recentrentsur l’Europe de l’Est, la Chine et l’Asie.



51

Les pays de l’offshore présentent un paradoxe, qui tient à l’écart entre la qualité de leursuniversités informatiques et leur niveau économique. Dans de nombreux pays, on peuttoutefois penser que les conditions économiques vont plus ou moins rapidementatteindre un niveau comparable à celui que l’on observe dans les pays plus riches.

Les prestataires offshore, qui assurent tous un volume de contrats souvent faible avec lessociétés de leur pays, se développeront de plus en plus sur leur marché national et serontde moins en moins attirants pour les sociétés des pays plus riches. Les tarifs s’équilibrant,ces pays perdront tout intérêt pour l’offshore.

Les collaborateurs des prestataires offshore

Une opinion courante considère que l’offshore soustrait les ressources humaines qui fontla richesse d’un pays au seul bénéfice des sociétés occidentales, qui exploitent à vil prixune main-d’œuvre de qualité. Il est vrai que l’image de sociétés riches qui utilisentd’excellentes ressources à un prix très faible peut être choquante.

La réalité est cependant différente. Le plus souvent, le marché local de l’informatique està peine existant dans les pays de l’offshore. Bien sûr, des banques, des organismes offi-ciels et de grandes sociétés ont besoin de développements, mais ces organismes payent

Prestataire offshore Marché national

Coû

t des

pre

stat

ions

Temps

Evolution du coût des prestations pour le marché national

Evolution du coût des prestations pour les clients de l’offshore

Figure 2.4. Évolution du coût des prestations pour les clients de l’offshore et pour le marché national



52

pour cela beaucoup moins cher que les clients de l’offshore. Pour certains organismesgouvernementaux, les sommes payées pour des développements informatiques sontproches du symbole mais s’associent à d’autres arrangements, pas toujours clairementexplicités. Des sociétés réalisent même certaines commandes gratuitement, dans l’espoirque des personnes influentes leur soient redevables.

Bien souvent, les pays de l’offshore revendent massivement les produits progiciels desplus grands éditeurs à des prix extrêmement faibles, équivalents au coût de gravure dusupport, CD ou DVD. On peut ainsi acheter les suites Microsoft Office, Oracle, etc., pourquelques dollars, dans des magasins ayant pignon sur rue, au vu et au su de tous. Si de tellespratiques sont clairement illégales au regard du droit international, il convient de préciserque nombre de ces pays n’ont pas ratifié la reconnaissance du droit d’auteur ou l’ont fait depure forme. La culture qui consiste à payer pour des logiciels le prix catalogue est absentedans la plupart des pays de l’offshore. Il n’existe d’ailleurs pratiquement pas d’éditeur delogiciel dans ces pays, et le marché local du développement de logiciel est inexistant.

Une telle situation tue évidemment dans l’œuf le marché du développement logiciel, tantétranger que national, puisque les entreprises peuvent accéder à la quasi-totalité desproduits de large distribution que l’on trouve sur les marchés américain et européen àdes prix dérisoires.

Les développements informatiques dans les pays de l’offshoreLe marché du développement national n’est pas totalement au point mort dans les paysde l’offshore. De grandes sociétés, tout particulièrement les banques nationales, les orga-nismes gouvernementaux, les sociétés de téléphonie, etc., font appel à des sociétés deservices pour développer des produits ou constituent leurs propres équipes dans ce but.

Lorsqu’on a une expérience occidentale de ces domaines, où l’on recherche avant toutproductivité et qualité, on est stupéfait de découvrir le fonctionnement de ces sociétés.On commence par remarquer sur certains CV que des personnes cumulent plusieurspostes simultanément, par exemple, dans une grande banque et dans une petite sociétéde services qui développe des sites Internet. On apprend qu’après la fin d’un projet, labanque conserve les personnels correspondants et leur confie des missions sporadiquesqui ne prennent que quelques heures par semaine. Les développeurs cherchent donc untravail supplémentaire, au su de l’employeur, qui trouve cela normal. Il est vrai que lessalaires de ces développeurs, qui ne dépassent guère 50 ou 75 dollars par mois, sontinsuffisants pour faire vivre leur famille. Si les budgets de ces grandes entreprises ont étémal gérés ou si l’État n’a plus assez d’argent, les salaires ne sont pas payés ou ne le sontque partiellement, sans aucune garantie que le salaire non versé le soit un jour.

Même si le poste est à temps complet, il est courant de voir un développeur travailler pourune seconde société, après ou avant ses heures de travail ou pendant les week-ends. Lessalaires versés par les entreprises d’État ne sont jamais suffisants pour assurer ne serait-ce que les besoins d’un jeune couple. Souvent, le second emploi est moins sûr et peuts’arrêter du jour au lendemain. Il est en revanche mieux rémunéré, parfois au pourcen-tage. Le développeur conserve donc son emploi stable, où l’on est peu exigeant, et serattrape sur un autre emploi donnant des résultats à court terme.

On rencontre parfois au cours des entretiens d’embauche des informaticiens qui viennentdu marché national et cherchent à entrer dans une société d’offshore. S’ils ont travailléune dizaine ou une quinzaine d’années pour des organismes d’État, les notions de



53

management, de productivité, de travail en groupe, de rigueur et de qualité leur sontparfaitement étrangères, même lorsque les domaines fonctionnels dont ils ont l’expériencesont intéressants.

Il n’est pas rare non plus de rencontrer des personnes qui ont travaillé plusieurs annéessur un projet et ne connaissent que la couche technique qu’ils ont développée. Ils n’ontaucune idée du sujet fonctionnel traité par le produit développé. Cet état de fait est davan-tage représentatif de la mentalité qui règne dans ces équipes que de celle du développeur .

On comprend qu’un étudiant capable, qui a intégré une université prestigieuse de sonpays, où la concurrence est vive, et d’où il sort bien placé n’ait pas envie de rejoindre cessociétés nationales qui étouffent l’esprit d’initiative et jusqu’au simple élan.

Les informaticiens et l’offshoreLes prestataires de l’offshore constituent un monde à part. Les salaires y sont deux à cinqfois supérieurs à ceux en vigueur dans les organismes d’État. Les compétences et lestalents y sont mieux reconnus, et l’expérience acquise est valorisée dans un CV.

Les méthodes de travail sont en outre plus rationnelles. Les montants en jeu correspon-dent mieux à une logique de rentabilité, et le succès de chaque projet doit être aussi bienassuré que possible. Un informaticien qui rejoint une des équipes de développement d’unprestataire offshore est immédiatement sur un chemin ambitieux, profitable et valorisant.

Les sociétés offshore se livrent une compétition féroce. Lorsqu’un gros projet est signédans l’une d’elles, il est toujours à craindre qu’elle cherche à débaucher les meilleurscollaborateurs de ses concurrents pour mieux garantir le succès de son projet. Lessalaires s’adaptent donc assez rapidement à ce que chaque société est prête à débourserpour acquérir ou conserver ces profils. Certaines sociétés font directement participer leurscollaborateurs clés aux bénéfices du projet.

En plus de tout cela, l’informaticien peut avoir l’occasion de voyager à l’étranger et dedécouvrir une autre culture, ce qui l’enrichit intellectuellement et lui permet de mieux com-prendre ses clients et leurs attentes. Son salaire beaucoup plus élevé lui procure le plussouvent un niveau de vie agréable, et il est vite considéré comme une personne qui réussit.

Il pourra ensuite postuler à d’autres postes chez d’autres prestataires offshore ou mêmetenter de s’expatrier en valorisant son expérience et, très probablement, son excellentepratique professionnelle de l’anglais.

EN RÉSUMÉLes postes les plus prisés sont chez les prestataires offshore

Pour les informaticiens en offshore, les postes les plus désirables sont ceux que proposent les pres-tataires offshore. Les salaires y sont plus élevés et les projets plus intéressants tout en apportantune valeur ajoutée au curriculum vitae.

La mesure des coûts

Ceux qui sont responsables du choix d’utiliser des ressources en offshore souhaitenttoujours, à un moment ou un autre, justifier les coûts des développements réalisés enoffshore. Parfois, on veut simplement savoir quel est le montant des économies réalisées.



54

On peut comprendre que la direction financière ou la direction générale veuille disposerde plus d’informations sur ces opérations, qui ne sont pas toujours transparentes.

Les développements offshore apparaissent sur une ligne unique du budget de l’entre-prise, avec un montant important, de plusieurs centaines de milliers à plus d’un milliond’euros. Les autres lignes du budget font apparaître des détails, comme les salaires dechaque personne, les dépenses marketing, qui sont souvent détaillées par poste et quetous voient et comprennent. La ligne « développement offshore » est cependant la plusimportante. Pour peu que le mot « offshore » soit mentionné au lieu d’« outsourcing »,cette ligne donne vite l’impression d’investissements sulfureux et suscite des demandesd’explications.

ASTUCECommuniquer la rentabilité de l’offshore

Il est indispensable de construire une mesure régulière et objective des économies que l’on réaliseen travaillant avec une équipe en offshore, afin d’en prouver la rentabilité au management de façontrimestrielle ou semestrielle.

On peut toujours donner un détail précis de la façon dont les sommes sont dépensées. Ilest plus important de souligner les économies réalisées. De cette façon, les initiateurs dela décision de recourir à l’offshore apparaissent comme les responsables d’économiesmesurables. Pour peu qu’une comptabilité analytique adéquate soit mise en place dansla société, une profitabilité par produit peut être dégagée.

Comme expliqué au chapitre 1, les coûts de l’offshore doivent être mesurés à l’aune descoûts hypothétiques de la même réalisation en local. Cet exercice est difficile car oncompare une réalisation réelle avec une réalisation hypothétique. Il faut donc chercher àne pas valoriser outre mesure l’outsourcing, en choisissant des valeurs « lourdes »pour l’outsourcing et « légères » pour les réalisations locales. Des méthodes de calculprécises sont proposées au chapitre 3.

Conclusion

Rares sont aujourd’hui les sociétés qui développent des applications, qu’elles soientéditrices de logiciels ou sociétés de services, qui ne considèrent pas de confier une partiede leurs réalisations en offshore. Si les enjeux économiques sont de taille, les difficultésne le sont pas moins. Pour mener au succès les projets outsourcés, il faut prendre encompte de nombreux sujets, à commencer par la gestion des ressources humaines et lamise en place d’une méthodologie rigoureuse, ce qui n’est pas si courant dans les projetsgérés localement.

Pour peu que l’on mette de côté ses préjugés sur l’offshore et que l’on choisisse son parte-naire avec soin, on peut bénéficier à plein des avantages de l’offshore. Lorsqu’on travailleen bonne intelligence avec le partenaire en offshore, on peut allier intérêt professionnelet personnel. La découverte d’autres cultures et d’autres façons de vivre ne peut manquerd’enrichir ceux qui s’y prêtent.


55

Chapitre 3

Les collaborateurs locaux et en offshore

Ce chapitre aborde la gestion des collaborateurs du partenaire et du client. Le succès desprojets en offshore dépend fortement des hommes et de la bonne compréhension deleurs attentes et motivations.

Le travail avec l’offshore demande le plus souvent des modifications substantielles de lafaçon de travailler, tant pour l’organisation des équipes que pour les procédures. Certainscollaborateurs locaux du client de l’offshore ne manqueront pas d’adopter une réactionde défense, à la fois naturelle et émotionnelle, à l’égard de l’externalisation de ressources.Il faudra donc apprendre à communiquer avec les équipes afin de les faire adhérer auprojet d’entreprise sur l’utilisation de l’outsourcing.

Il importe surtout de bien comprendre ce qu’est le travail en offshore. Ce monde est sidifférent du nôtre que l’on perd vite ses repères les plus sûrs.

Les informaticiens

Cette section aborde le comportement des collaborateurs travaillant pour la sociétécliente de l’offshore et leur attitude vis-à-vis de l’offshore. Les informaticiens forment unepopulation souvent difficile à gérer dans la société. À la fois créatifs et hautement quali-fiés, ils perçoivent des salaires élevés, qui ne les satisfont pourtant pas, et protègent leurspostes en rendant volontiers leur domaine opaque.

Cette section se penche sur les motivations de ces équipes locales et sur les moyensd’intégrer leur travail à celui des équipes distantes.

Centre de coûts ou d’investissement ?Les directions des entreprises cherchent à réaliser toujours plus de projets à un coût aussifaible que possible. L’éditeur de logiciels cherche le plus souvent à travailler à budget fixeet à réaliser autant de produits ou d’évolutions que possible tandis que la société de servicescherche à réduire le coût de sa production afin d’être plus compétitive et d’augmenter samarge.

Dans tous les cas, le salaire des informaticiens est au cœur des débats, avec une logiquede coûts que la société de services cherche à réduire, ou avec une logique d’investissementpour les éditeurs de logiciels.



56

Informaticien dans une société de servicesOn a longtemps considéré que le travail de consultant pour une société de services étaitun poste de transition et non une carrière. Tout au plus estimait-on que c’était une bonneécole pour apprendre diverses technologies et méthodes afin de mieux choisir plus tard.Les sociétés qui constituaient leurs propres équipes pour réaliser leurs projets se tour-nent désormais plus volontiers vers l’outsourcing, et donc vers les sociétés de services,afin d’externaliser leurs équipes de production de logiciels. Ces sociétés de servicesproposant des postes intéressants pour des missions à long terme, il est aujourd’huipossible d’y faire carrière.

Dans un environnement de plus en plus compétitif, les clients des sociétés de servicescherchent toujours plus de qualité et d’engagement de leurs fournisseurs, pour unesomme aussi réduite que possible. Pour réaliser leurs commandes, les dirigeants dessociétés de services recherchent, d’une part, des chefs de projet de confiance, qui saurontparler au client et mener à bien les projets, et, d’autre part, des coûts de production aussifaibles que possible afin de soumettre des offres compétitives.

La compétitivité de l’offre est aujourd’hui essentielle pour remporter des affaires. Lessociétés qui veulent faire réaliser un projet comprennent que la grande disparité desmontants des propositions de services informatiques ne va pas toujours de pair avec laqualité des réalisations, et ils ne veulent plus payer plus que nécessaire les programmesdont ils ont besoin. Certaines d’entre elles commencent à exiger dans leurs appelsd’offres que les développements soient réalisés en offshore, à un prix plus faible et àqualité égale. Ils réclament en outre un engagement fort du prestataire de services pourapporter toutes les garanties qu’il offre habituellement à ses réalisations.

La société de services considère l’essentiel des collaborateurs qui travaillent à la réalisa-tion de ses projets comme formant un coût, lequel servira de base au calcul de ses offresde services. Le salaire des informaticiens est ainsi maintenu aussi bas que possible afinde rester compétitif, à l’exception de certains profils rares, qui personnalisent les capa-cités du prestataire et en font la valeur. Les augmentations de salaire sont accordées avecparcimonie, puisqu’elles s’accompagnent toujours d’une perte de compétitivité et deprofitabilité.

EN RÉSUMÉSalaires des informaticiens et compétitivité

Les sociétés de services veulent réduire leurs coûts de production pour pouvoir présenter des offresde prix agressives tout en conservant une marge importante. L’utilisation de ressources en offshoreà faible prix est dès lors incontournable.

Informaticien chez un éditeur de logicielsDe leur côté, les éditeurs de logiciels utilisent leurs ressources de développement avecune logique d’investissement. Ils attribuent le plus souvent un pourcentage fixe de leurchiffre d’affaires à leurs développements, qui varie entre 14 et 25 %. Pour peu que l’éditeursoit coté en Bourse ou qu’il ait l’intention de l’être, il a les yeux rivés sur les résultatstrimestriels, semestriels et annuels et sait qu’un investissement coûteux risque de peserlourd sur les résultats publiés.

Le directeur des développements doit réaliser le plus de projets possible avec un pour-centage bien défini du chiffre d’affaires. Dans ces conditions, démarrer un nouveau projet


Chapitre 3 – Les collaborateurs locaux et en offshore

57

majeur, qu’il soit fonctionnel ou qu’il relève d’une migration technique, présente degrandes difficultés organisationnelles puisque l’essentiel des ressources est occupé à lamaintenance et aux évolutions des produits existants. Comme on sait par ailleurs que l’onsouhaite avant tout couvrir un pic de développement, l’embauche ne convient pas.

Il est tout sauf évident pour les éditeurs de logiciels de décider de recourir à desressources en offshore. Les équipes locales sont habituellement performantes, tant fonc-tionnellement que techniquement, et restent toujours plus efficaces, au moins dans lespremiers temps, que les équipes en offshore, qu’il faudra former. De plus, travailler enoffshore demande que l’on communique son savoir, ce qui pose parfois des problèmes àcertains informaticiens, qui se plaisent à le protéger.

L’éditeur se retrouve devant des choix cornéliens, du type : faut-il confier les nouveauxprojets aux équipes en offshore, au risque de vexer les informaticiens locaux, lesquelsresteront sur leurs « vieux » projets, aux technologies vieillissantes, ou aux équipes enplace, en déléguant la maintenance évolutive à l’offshore, avec tous les problèmes detransmission des connaissances que l’on peut imaginer ?

EN RÉSUMÉLes informaticiens comme poste d’investissement

En utilisant des ressources en offshore, l’éditeur de logiciels peut optimiser ses réalisations et déve-lopper beaucoup plus pour un budget donné, sans se soucier des fluctuations du nombre d’informa-ticiens dont il aura besoin.

Remplacer l’irremplaçableLes employés des sociétés disent souvent que la valeur d’une entreprise réside danschacune des personnes qui la constituent. S’il est vrai que les employés participent effec-tivement à la production de la société, il n’est pas moins vrai que seules quelques rarespersonnes, à tous les échelons de la hiérarchie, apportent une valeur exceptionnelle.

Le nombre de collaborateurs d’une société est considéré un peu rapidement comme unindicateur de sa taille et de sa puissance. En cas d’estimation de cette société par unacheteur ou un financier, le nombre des employés n’est pas considéré comme une donnéeimportante. On ne prend en compte que les données financières, à commencer par lechiffre d’affaires, la rentabilité et les revenus récurrents et sûrs, comme la maintenancedes applications. Le compte du nombre de collaborateurs est presque considéré commeune donnée négative, car un nombre élevé est synonyme de dépenses récurrentesélevées. Du point de vue financier, il vaut toujours mieux arriver aux mêmes résultats avecmoins d’employés.

La reconnaissance des employés clés est aussi un sujet délicat. Certains collaborateurs,qu’ils soient technico-commerciaux, chefs de projet ou responsables fonctionnels, saventcomprendre les clients et trouver des solutions adaptées à leurs attentes. Ces qualitésleur permettent d’emporter des affaires, d’en garantir le succès ou de concevoir demeilleurs produits, qui seront des succès sur les marchés logiciels. Si certaines personnespossèdent ces qualités rares, force est d’admettre qu’elles ne sont pas légion. La plupartdes cadres techniques ne se voient pas moins eux-mêmes comme des personnes



58

exceptionnelles et se plaignent de n’être pas mieux reconnus. Leurs salaires sont évidem-ment considérés comme sous-évalués. Ce sentiment est encore renforcé dans lesdomaines techniques, où intervient une certaine part de création.

Quelle que soit l’équipe en place, à condition qu’elle soit de qualité, les questions tech-niques trouvent la plupart du temps des solutions acceptables et utilisables. À moinsd’une réelle innovation, ce qui est très rare, il est probable que n’importe quelle équipede qualité pourrait faire une proposition acceptable. L’équipe qui attend une reconnais-sance de son employeur n’en reçoit que rarement, car la position de créateur n’est géné-ralement pas reconnue par le management. Cette équipe est tout simplement considéréecomme remplaçable.

De fait, la majeure partie des collaborateurs est remplaçable. Leur travail est certes néces-saire au bon fonctionnement de l’entreprise, mais que l’on ait affaire à ces collaborateursou à d’autres, on obtient toujours de bonnes solutions. Le management a donc intérêt àutiliser les ressources les plus favorables, les moins chères et dont il peut maîtriser sanstrop de contraintes les fluctuations.

La décision d’utiliser des ressources en offshore est l’aboutissement de la réflexion dumanagement, qui est généralement incomprise des informaticiens. La réalité est que l’ontrouve assez facilement d’excellents profils dans les pays de l’offshore et que la plupartdes équipes techniques peuvent être efficacement délocalisées. Les réalisations peuventêtre équivalentes ou supérieures, avec des compétences de grande qualité, des coûts plusfaibles et, en prime, la flexibilité des équipes que recherche tant le management.

On comprend que la valeur de l’entreprise ne soit pas vraiment affectée si les réalisationstechniques sont faites en dehors de la société. Il est même possible qu’une bonne utili-sation de l’offshore accroisse la valeur de la société en démontrant sa capacité à être plusperformante en réduisant les coûts récurrents.

EN RÉSUMÉAdaptabilité des équipes techniques

En dépit du fait que les équipes techniques s’estiment souvent indispensables, il est possible de lesremplacer ou d’externaliser les réalisations sans perdre en productivité ni en qualité. En exter-nalisant une partie de leurs réalisations techniques dans les pays de l’offshore, les décideursgagnent en coûts et en flexibilité. La possibilité de rejet de l’offshore par les équipes locales doitcependant être traitée avec toute l’attention requise, faute de voir la gestion humaine des projetsdevenir fort complexe.

Une reconnaissance qui n’arrive pas

Il existe un fossé entre la perception qu’ont les collaborateurs techniques de leur travail,qu’ils considèrent comme une création intellectuelle essentielle au succès de leuremployeur, et celle des dirigeants de la société. Ces derniers reconnaissent certes lesqualités de ces collaborateurs mais les considèrent comme plus ou moins interchangea-bles. Du coup, les collaborateurs sont d’éternels insatisfaits, qui espèrent toujours plus dereconnaissance de la part de leur employeur, tandis que ce dernier s’agace de l’importanceexagérée qu’ils s’attribuent.



59

Transmettre le savoirLes informaticiens les plus compétents techniquement mesurent parfois avec beaucoupde précautions les informations qu’ils rendent disponibles à la société. Certains poussentcette attitude jusqu’à refuser de montrer leur code source ou de formaliser leur savoir.Cette opacité des connaissances disparaît complètement lorsqu’on travaille avec uneéquipe distante, surtout si elle est située en offshore, puisque la documentation estessentielle au bon fonctionnement des équipes distantes. Les procédures qui sont misesen place avec le prestataire offshore règlent d’ailleurs souvent en premier lieu la qualitéde la documentation qui est échangée entre les parties.

Pour le prestataire offshore, il est important de s’assurer que la totalité de la propriétéintellectuelle est transmise au client. Cela ne peut être réalisé qu’avec une transmissioncomplète de toute la documentation de la production de l’offshore. Cette transmissions’effectue non seulement lorsque le projet arrive à son terme, mais aussi au fur et à mesurede l’avancée du projet. Les informations transférées aux chefs de projet permettent à cesderniers d’évaluer la qualité et la complétude des informations transmises.

EN RÉSUMÉLa rétention d’information

Certains informaticiens, souvent de grande qualité, maintiennent une opacité volontaire sur lesdomaines dont ils sont responsables, espérant de la sorte protéger le caractère incontournable deleur poste. En refusant de s’inscrire dans les procédures en place, ils entretiennent en réalité unmalaise au sein du management. Avec des ressources en offshore, de telles situations ne se rencontrentjamais, la documentation de toutes les réalisations étant l’une des règles élémentaires du travailavec un prestataire distant.

Documenter les projetsTrop souvent, les informaticiens, managers, responsables fonctionnels ou chefs de projetconsidèrent la documentation comme une perte de temps. J’ai même souvent entendudes chefs de projet affirmer que les spécifications représentaient un travail peu utile etqu’ils préféraient la communication directe entre le responsable fonctionnel et le chef deprojet, la jugeant plus réactive et efficace.

Il n’y a aucun doute que travailler sans formalisation est plus agréable pour les déve-loppeurs. Les informaticiens se sentent plus libres et expriment plus facilement leur créa-tivité. Lorsque le responsable fonctionnel est aussi le développeur, on arrive à créer unedynamique positive, qui atteint le plus haut niveau de productivité. Il est en revanchedifficile d’impliquer d’autres informaticiens dans de tels projets, si ce n’est pour réaliserdes tâches annexes, énoncées oralement par le chef de projet, ou savoir à l’avance ce quesera le produit en cours de développement.

Si cette approche sans papier est assurément la plus efficace pour les développements detrès petites équipes, elle ne convient plus pour les projets importants. La visibilité sur cequi doit être fait, la distribution sur plusieurs équipes, les dépendances entre les équipeset, plus important encore, la nécessité de tester les applications, et donc d’assurer unerecette objective, ne peuvent être assurées que si la documentation est saine, à jour etcomplète.

Avec les développements en offshore, la mise à disposition de la documentation estune nécessité. Sans cette documentation, il y a peu de chance de travailler efficacement.



60

Les développeurs en offshore n’apprécient guère plus le travail de documentation que lesdéveloppeurs des autres pays, mais ils en comprennent mieux l’utilité et savent qu’il estimpossible de s’en passer.

EN RÉSUMÉUne documentation complète et à jourLa documentation est le socle de la communication avec l’équipe en offshore. Elle doit être à toutmoment disponible, complète et à jour, tout particulièrement pour les spécifications et les documentsrelatifs aux tests et à la recette.

Ajuster les salairesLa gestion des salaires des informaticiens a toujours été un casse-tête. Rares sont ceuxqui s’estiment satisfaits de leur employeur et qui considèrent leur salaire comme juste.

On a longtemps estimé que si l’on avait des besoins informatiques, il fallait nécessaire-ment embaucher des ressources. Les informaticiens embauchés lors des périodes fastesont bénéficié de salaires élevés, qu’ils ont conservés après le ralentissement du marchéde l’informatique. Cela explique certaines différences de salaire, que ne comprennent pastoujours les informaticiens, qui ne se fondent pas sur des critères de compétence, maissur les conditions d’attribution du salaire à l’embauche.

Dans les sociétés informatiques, les augmentations de salaire sont couramment del’ordre de 1 à 3 % de la masse salariale des équipes de développement. Cela est de peud’effet sur les salaires anormalement bas. À chaque discussion budgétaire, les frustrationscréent des situations tendues, certains se décourageant, d’autres se mettant en colère.

Les primes de motivation sont généralement mal vues des informaticiens. Leurs condi-tions d’attribution sont difficiles à comprendre. Il arrive que les objectifs ne soient pasatteints pour des raisons indépendantes de la qualité du travail et de l’implication desinformaticiens, par exemple. Une prime attribuée en ignorant les changements de prioritéou les retards extérieurs aux développements devient une prime de démotivation.

Pour toutes ces raisons, la gestion des ressources humaines des équipes techniquesconsomme du temps et de l’énergie. Du fait de son externalisation, la gestion deressources en offshore résout ces problèmes. La flexibilité des salaires que l’on rencontredans la plupart des pays de l’offshore permet au prestataire de réduire ou d’augmenter lamasse salariale comme il le souhaite et d’atteindre un bon équilibre.

EN RÉSUMÉGérer les injustices des salairesLe manager des équipes d’informaticiens en France doit constamment gérer une situation où lessalaires ne reflètent pas la qualité ni la productivité des individus. Les sommes allouées pour les augmen-tations suffisent à peine à corriger les injustices patentes. La gestion des ressources en offshorepermet de s’affranchir de ce problème. De plus, les salaires en offshore peuvent être revus aisémentà la baisse ou à la hausse afin d’atteindre une saine adéquation entre salaire et productivité.

Spécialiser les rôlesPour réussir un projet en offshore, l’entreprise doit faire preuve de rigueur et recourir àune meilleure spécialisation des rôles. L’expérience montre que lorsqu’une personnea plusieurs rôles, ce qui est très souvent le cas, elle se concentre le plus souvent sur ceuxqui lui plaisent le plus ou qui sont les plus gratifiants. Il n’est donc pas évident de garantir



61

que tous les rôles soient correctement assurés. Pour qu’un rôle un tant soit peu difficilesoit pleinement assuré, il faut y dédier une personne.

Le chef de projet offshore

Le chef d’un projet offshore travaille localement, c’est-à-dire dans le pays du client, pourgérer le projet confié au prestataire offshore. Il porte le projet, et son travail contribuefortement au succès ou à l’échec du projet. Il est responsable de toute l’équipe, si cettedernière est assez petite (moins de 20 personnes). Sinon, le travail est partagé entreplusieurs chefs de projet, l’un d’eux jouant le rôle de directeur de projet.

Les tâches du chef de projet offshore sont les suivantes :

• Gérer l’équipe offshore sur tous les aspects de management.

• Mettre en place et adapter les procédures en offshore pour suivre efficacement leprojet.

• Mettre en place le reporting, qui permet de suivre la progression du projet, le travail dechacun et la qualité des livrables.

• Suivre effectivement la progression du projet et demander des explications sur lesretards ou autres dysfonctionnements.

• Répondre aux questions des équipes en offshore, tant sur des points bloquants, quidemandent une réponse fonctionnelle ou technique, que sur des questions organisa-tionnelles.

• Informer le chef de produit de la progression du projet et prendre avec lui les décisionsvisant à rattraper les retards ou changer le contenu de certains livrables.

• Se rendre sur place pour mieux suivre les équipes distantes et communiquer sur la viede l’entreprise et du projet.

• Vérifier l’application des clauses contractuelles que doit respecter le prestataire.

Si ces tâches sont semblables à celles de tout chef de projet, la spécificité du travail duchef de projet offshore est qu’il n’a pas de responsabilité fonctionnelle et qu’il ne définitpas le produit à réaliser. Plus important, il gère son équipe non pas sur place, mais àdistance et ne la voit que rarement.

Perception du travail du chef de projet en offshore

Les chefs de projet ont pour tâche de gérer des équipes délocalisées, situées à plusieursmilliers de kilomètres. Leur poste est souvent mal compris, et la perception même de leurtravail s’en trouve affectée.

Il est d’usage de considérer que l’importance d’un poste peut être mesurée au nombre depersonnes managées. Le chef de projet qui gère des équipes invisibles en offshore estperçu comme ayant moins d’importance et d’influence que celui qui gère une équipe pluspetite, mais visible de tous à l’intérieur de la société.

Ainsi, le chef de projet qui gère une équipe distante de 50 personnes peut être considérécomme oisif ou sous-utilisé et se voir reprocher de ne pas beaucoup travailler. Sonsalaire, probablement égal ou supérieur à celui des autres chefs de projet gérant deséquipes locales, semble presque exagéré pour une personne si manifestement seule.



62

La gestion d’une équipe en offshore ne s’effectue pas de la même façon qu’en local.Délesté de la gestion des hommes, le chef de projet conduit froidement le projet à partirdes indicateurs de progression et utilise la messagerie pour communiquer.

Il ne ressent les gratifications du management que lorsqu’il se rend sur place, en offshore.Cette expérience est toutefois de courte durée et presque intime, puisque ses collèguesne la voient pas. À son retour, il se retrouve toujours aussi seul et incompris.

Pour ces raisons, le poste de chef de projet offshore ne convient pas à une personne quiapprécie avant tout le management humain. Il m’est souvent arrivé de rencontrer descandidats qui refusent des postes de management d’équipe en offshore pour ces raisons,qu’ils ont su clairement exprimer.

EN RÉSUMÉChef de projet offshore, un poste difficile à assumer

Le chef de projet offshore est souvent moins bien reconnu que celui qui gère des équipes locales. Eninterne, on ne se rend pas toujours compte de la complexité de la gestion d’une équipe distante.On s’interroge même parfois sur le travail du chef de projet offshore. Ce dernier peut lui-mêmeêtre insatisfait de son poste, qui ne lui offre pas pleinement les aspects humains de la gestiond’équipe.

La responsabilité du chef de projet offshore

On constate souvent que le chef de projet offshore dans la société cliente n’est pas réel-lement considéré comme responsable du succès des projets qu’il gère. Lorsqu’un projetéchoue, par exemple, il se trouve exempté de la pleine responsabilité de l’échec, alorsqu’un échec semblable rencontré sur un projet local entraîne des sanctions à l’encontredu chef de projet fautif.

Le chef de projet offshore apparaît aux yeux du management comme un acteur presquepassif, et la responsabilité de l’échec est reportée sur l’équipe distante. Je n’ai personnel-lement rencontré aucun exemple où le chef de projet offshore était considéré commeresponsable des crises et problèmes d’un projet.

De telles situations ne sont ni saines ni productives. Il est important de responsabiliserpleinement le chef de projet offshore en lui donnant les moyens d’assurer sa mission.Il doit être comptable du succès comme de l’échec des réalisations qu’il gère.

EN RÉSUMÉDes chefs de projet à responsabilité limitée

Dans la plupart des sociétés, les chefs de projet locaux gérant les projets réalisés en offshore setrouvent étonnamment déchargés de la pleine responsabilité des échecs et des problèmes rencontrésdans leurs équipes en offshore.

Pour obtenir des résultats optimaux, il est essentiel que le chef de projet soit pleinement respon-sable de l’équipe qu’il gère, tant pour ses succès que pour ses échecs.

Les responsables fonctionnels

Les responsables fonctionnels, aussi appelés chefs de produit, ou program managers,jouent un rôle à la fois essentiel et difficile. Ils sont responsables de la définition duproduit et de son adéquation aux attentes des utilisateurs.



63

Les responsabilités du chef de produit sont les suivantes :

• Gestion des spécifications fonctionnelles, de leur complétude et de leur qualité.

• Réception régulière des informations des chefs de projet sur la progression du déve-loppement et décisions avec les personnes concernées en cas de retard, notammentpour alléger le produit de certaines fonctionnalités.

• Fourniture et vérification des scénarios de tests ainsi que des jeux de données quidoivent être utilisés pour vérifier la qualité du développement.

• Gestion de la recette (mais non des tests) des livraisons, avec, si nécessaire, uneéquipe de recette pour vérifier le fonctionnement du produit.

Le responsable fonctionnel prend la décision de libérer le produit pour qu’il soit utiliséen production. Il ne gère pas directement les équipes en offshore, mais est tenu informéen permanence de l’évolution du projet. Dans les petites équipes, ce poste est souventcumulé avec celui de chef de projet. C’est là un mélange des genres regrettable carles aspects fonctionnels et la gestion de projet prennent généralement le dessus au détrimentdu management de projet.

Les équipes de recette

Il est souhaitable que les tests soient réalisés et automatisés en offshore avec des robotsde test. Il faut tout de même recetter le produit livré chez le client pour en vérifier laqualité. Le responsable fonctionnel pilote ces opérations et y participe lui-même directe-ment. Ce poste se rencontre toutefois rarement. On trouve bien des testeurs, mais il s’agitd’un poste différent, même si la recette consiste pour l’essentiel à tester le livrable.

Les fonctions de l’équipe de recette sont les suivantes :

• Vérification par échantillonnage sur les livrables que les scénarios de test ont étéexécutés en offshore et que les résultats annoncés concordent avec ceux que l’onobserve.

• Vérification que les messages et autres communications modifiant le contenu fonc-tionnel du produit ont été répercutés sur les spécifications (use cases, ou cas d’utili-sation).

• Vérification que les scénarios de test sont à jour par rapport aux spécifications (casd’utilisation).

• Test manuel du produit sur des fonctions complexes ou qui ont présenté une instabi-lité notoire.

Intégration et déploiement

Si les déploiements sont multitiers, comme le permettent les technologies récentes, leurgestion en local chez le client est une tâche difficile. Lorsque le livrable est envoyé,comment organise-t-on le déploiement de celui-ci sur la plate-forme de recette ?

L’équipe d’intégration et de déploiement (ID) a pour rôle de gérer, le plus souvent direc-tement à partir du code source, la constitution du build qui sera déployé sur la plate-forme cible.

Les fonctions de l’équipe d’intégration et de déploiement sont les suivantes :

• constitution du build à partir du code source ;



64

• déploiement du build sur la plate-forme ;

• définition des scripts de création des builds développés en offshore ;

• configuration des systèmes d’exploitation et des middlewares pour obtenir la sécuritéet les performances attendues ;

• synchronisation du travail d’intégration et de déploiement avec les équipes en offshorepour assurer les niveaux de service attendus (SLA).

Il est toujours difficile d’assurer un certain niveau de service avec une équipe restreinte.Par exemple, un service vingt-quatre heures sur vingt-quatre et sept jours sur septdemande au minimum cinq personnes. Le recours à des ressources en offshore apporteassurément un confort et une rigueur industrielle à toutes ces tâches.

Présentation de l’externalisation auprès des équipes localesMême si tous les collaborateurs locaux peuvent comprendre les motivations objectivesqui poussent le management à prendre la décision de faire appel à des ressources enoffshore, cette décision est génératrice de malaise.

Apparaît en premier lieu la crainte d’être licencié et remplacé par une ressource moinscoûteuse en offshore. On trouve ensuite de nombreuses peurs, souvent très personnelles,ayant trait à la nature du travail que l’on assure quotidiennement. On craint, par exemple, quece travail perde de son attrait s’il doit être industrialisé, comme l’exige le développementen offshore.

Les développeurs locaux et l’offshore

La première crainte du collaborateur local est de perdre son poste ou de voir certains deses collègues perdre le leur. De grands groupes américains ont froidement décidé d’exter-naliser un tiers de leurs ressources informatiques. Cela s’est traduit par des licenciementsmassifs dans les entreprises concernées.

Dans les plus petites sociétés de services ou chez les éditeurs de logiciels, on cherchemoins à réduire les effectifs qu’à saisir des opportunités de marché. Les équipes restenten place, et l’on y ajoute une équipe en offshore. Les investissements sont en ce cas viterentabilisés par les réalisations.

Le travail peut en outre être significativement modifié par l’industrialisation des procé-dures, qui vise à mieux documenter et contrôler la progression d’un projet. La documen-tation, en plus d’être extrêmement rébarbative à créer pour les informaticiens, expose etfixe tout le savoir détenu et le rend transmissible à un tiers. Si un climat d’inquiétude sedéveloppe, la rumeur colporte vite que l’industrialisation des processus est le premier pasd’un plan caché visant à remplacer les informaticiens locaux.

L’industrialisation peut aboutir à la spécialisation des métiers et interdire les rôles multi-ples, notamment ceux qui partagent des responsabilités fonctionnelles et techniques,qu’apprécient tant d’informaticiens. Ces derniers se voient contraints de choisir entre latechnique et le fonctionnel, au risque de devoir renoncer à une partie intéressante de leurposte.

Il va de soi que l’industrialisation des développements de logiciels peut être mise enplace indépendamment de l’offshore. Elle peut viser, par exemple, à obtenir plus de prévi-sibilité dans les livraisons ou à s’assurer de disposer de toutes les informations relatives



65

à un projet. Le mécontentement qui en résulte n’est pas moins fort, si ce n’est que lacrainte d’être remplacé par un collaborateur distant est absente.

À rebours de ces frustrations, les enthousiastes de l’offshore y voient des possibilitésd’ouverture. Ils apprécient principalement la possibilité d’être en contact avec denouvelles mentalités et d’autres cultures. Si l’informaticien atteint l’âge où l’oncommence à ne plus souhaiter développer soi-même pour préférer la gestion de projet, ily voit une occasion d’accéder à des fonctions de management.

Quant aux amateurs de procédures, qui critiquent régulièrement le laisser-aller qui règnedans les équipes de développement, ils se félicitent de la mise en place de processusd’industrialisation grâce à l’utilisation de ressources en offshore.

Comme on le voit, les réactions sont bipolaires, opposants farouches d’un côté et enthou-siastes inconditionnels de l’autre. Dans tous les cas, la direction doit bien communiquersur la réalisation de projets en offshore afin d’expliquer les décisions telles qu’elles sontet de contrôler la rumeur qui pourrait prendre le pas sur la perception objective de laréalité.

Il lui revient d’identifier les personnes favorables, qui pourront participer aux premièresréalisations distantes. Celles-ci sont suffisamment difficiles à gérer pour ne pas ajouter àla difficulté en choisissant sciemment des réfractaires à l’offshore ou à l’industrialisationdes développements.

Communication sur les projets offshore

Il est souvent nécessaire de rassurer les équipes locales en leur expliquant clairementcomment l’offshore sera utilisé. Il est important d’expliquer que la société n’a nullementl’intention de licencier massivement ses équipes pour en constituer de semblables enoffshore.

Le tableau 3.1 récapitule les principales questions soulevées lorsqu’on communique surla mise en place d’une équipe en offshore. L’agressivité des questions dépend bien sûrdes relations du management avec ses équipes.

Tableau 3.1. Communication aux collaborateurs sur les réalisations en offshore

Inquiétude Proposition de réponse

Les ressources locales seront-elles rapidement remplacées par d’autres en offshore ?

Aucun licenciement n’est envisagé. Les développements en offshore permettent de saisir des chances de marché uniques. Ces projets exigent aussi des ressources en France. Globalement, les ressources augmentent en France et en offshore et rendent la société plus compé-titive et plus pérenne.

Les augmentations de salaire seront-elles affectées par l’offshore ?

Non. Les augmentations de salaire seront gérées comme précédem-ment, en prenant garde de ne pas pénaliser la compétitivité par des salaires exagérément importants par rapport à la concurrence. Nous ne comparons pas les salaires français et en offshore pour accorder les augmentations de salaire. De plus, certains postes tournés vers l’offshore seront créés. Ils demanderont une évolution de profil.



66

EN RÉSUMÉAdhésion à l’utilisation de l’offshore

Il est important d’assurer une communication positive sur la stratégie offshore. Les personnes impli-quées sur les premiers projets seront choisies parmi les plus enthousiastes pour démontrer la réalitéet l’utilité de l’offshore. On présentera régulièrement l’intérêt qu’y ont trouvé ceux qui ont travaillélocalement sur ces projets afin de créer un climat plus favorable et justifier et étendre au besoinl’utilisation de l’offshore.

Il est vain d’essayer d’obtenir à tout prix l’adhésion de l’ensemble des collaborateurs, caril y aura toujours des opposants résolus. On se bornera donc à convaincre des bonnesintentions du management les ténors des équipes de développement, qui sont écoutésde tous.

La communication est une des clés de la réussite des projets distants. Si l’on doit réaliserun projet en offshore dans un climat d’opposition ouverte, on a de fortes chances d’échouer .

Inquiétude Proposition de réponse

Si le premier projet se passe bien, pourquoi le management ne voudrait-il pas faire basculer l’essentiel des projets en offshore, notamment les maintenances appli-catives tierces ?

Il est impensable que la société de services ne réalise que des projets en offshore. Des équipes locales sont toujours indispensables. Certains clients exigent que les réalisations soient effectuées en France. Il ne s’agit pas de réduire les effectifs de la société, mais de saisir des chan-ces de marché. Certaines personnes pourront évoluer vers des postes de responsabilité pour travailler avec les équipes en offshore.

Quelles mesures seront prises pour permettre aux équipes locales de travailler plus efficacement avec l’offshore ?

Les équipes locales n’auront pas nécessairement à travailler avec des ressources en offshore. Ceux qui souhaiteront évoluer vers des respon-sabilités de contrôle ou de pilotage en offshore pourront le faire et seront formés pour cela. Les formations envisagées concernent le management de projet en offshore et la mise à niveau de l’anglais.

La communication de toutes les informations dont je dispose n’annonce-t-elle pas mon licen-ciement prochain ?

Non (à moins que cela n’ait été communiqué officiellement). Certaines personnes vont gérer le projet en offshore depuis la France. D’autres travailleront sur d’autres projets, qui seront considérés comme vitaux pour l’entreprise et qui ne seront pas traités en offshore.

Y a-t-il une concurrence entre les projets français et les projets en offshore ?

Non. Bien sûr on essaiera de mesurer la productivité des équipes en offshore et on comparera certainement celle-ci aux réalisations locales, mais le but n’est pas de juger qui est le plus compétitif. Le mode de fonctionnement étant très différent pour des développements locaux et en offshore, les problèmes rencontrés ne sont pas aisément compara-bles.

Les nouveaux projets avec les technologies les plus intéressantes seront-ils confiés à l’offshore, ne laissant aux équipes locales que les projets aux technologies plus anciennes ?

Non. Il n’y a pas de volonté dans ce sens ni dans le sens contraire. On trouvera des projets nouveaux s’appuyant sur de nouvelles techno-logies en local comme en offshore, au hasard des affaires qui seront remportées ou selon l’organisation qui conviendra le mieux à chaque projet en particulier.

Tableau 3.1. Communication aux collaborateurs sur les réalisations en offshore



67

Le travail en offshore

Cette section traite des spécificités du travail avec les pays de l’offshore. Selon les pays etles prestataires retenus, les approches et motivations seront plus ou moins différentes.

L’important est de se faire une idée générale de l’environnement de travail et des façonsde penser et d’agir des informaticiens en offshore.

Les motivations des informaticiensLes motivations des informaticiens en offshore sont très différentes de celles des infor-maticiens locaux. Comme expliqué au cours des chapitres précédents, la vie dans un paysd’offshore est souvent difficile et précaire. En règle générale, on y recherche une stabilitéfinancière. Le salaire doit être suffisant pour vivre, mais pas nécessairement le plus élevé.

Un collaborateur porte une grande attention à la façon dont le président du prestataireoffshore se comporte. Certains dirigeants utilisent pleinement la faible protection socialeque l’on rencontre dans ces pays pour se séparer immédiatement de toute personne devenuemoins utile. Par exemple, si un projet s’arrête, certaines sociétés licencient immédiatementtout le personnel ou ne le paie plus, avec un préavis d’au plus une semaine.

L’informaticien qui choisit un nouveau poste donne la priorité aux sociétés qui essaientde conserver leurs employés et de leur offrir dans les périodes d’intercontrat un salairecorrespondant au minimum vital. Cette considération est à prendre en compte lors duchoix d’un partenaire en offshore si l’on souhaite bénéficier des meilleurs profils.

Il ne faut pas s’imaginer que les informaticiens en offshore sont prêts à accepter n’importequel poste. Ces derniers accordent une grande importance aux technologies proposées.Si Java et .Net sont généralement appréciés et les équipes qui les maîtrisent faciles àmonter, les postes utilisant des technologies plus anciennes, comme la maintenanced’applications Cobol, sont plus difficiles à pourvoir. On y parvient cependant plus aisémentque localement.

Une fois les objectifs de stabilité des revenus et d’intérêt technologique du poste atteints,viennent les motivations habituelles, comme obtenir un salaire plus élevé, monter engrade, acheter une maison et une voiture et se préparer à avoir des enfants, si l’on n’en a déjà.

Le partenaire offshore peut jouer un rôle important dans la réalisation de ces objectifs,par exemple en se portant garant pour l’achat d’une maison ou d’un appartement. Dansnombre de ces pays, l’on ne dispose pas toujours d’un compte bancaire, et les salaires nesont pas forcément considérés comme une garantie de revenus. Dans ces conditions,l’obtention d’un prêt est parfois difficile, et l’employeur peut être d’un grand secours pourfaciliter les démarches financières. Certaines sociétés offrent une telle assistance ets’assurent ainsi de la fidélité de leurs salariés durant la période de remboursement du prêt.

EN RÉSUMÉMotivation des informaticiens en offshoreLes premières motivations des informaticiens en offshore sont la stabilité de l’emploi et des revenusainsi que l’intérêt technologique du poste offert. Jugé moins important, le montant du salaire doitêtre d’un niveau suffisant pour vivre correctement.

Le prestataire qui offre la meilleure stabilité financière, traite de projets technologiquement intéressantset est prêt à aider ses employés attire les meilleurs candidats.



68

Le salaire des informaticiens en offshoreDans la plupart des pays de l’offshore, la gestion des salaires des employés n’a rien decomparable avec ce que nous connaissons.

Il est important de comprendre comment est rémunéré un collaborateur en offshore pourmieux anticiper ses motivations et ses réactions vis-à-vis de son employeur.

Salaires officiels et salaires réels

Les salaires qu’ont obtenus les collaborateurs en offshore suivent grosso modo les mêmesrègles que localement. On trouve des personnes qui se sont bien présentées et ontobtenu un niveau salarial supérieur à ce qu’elles valent, des personnes qui sont arrivéesau bon moment, etc.

Le plus souvent, les lois sociales de ces pays sont très particulières. Comme nous lesavons, il est impossible en France de réduire le salaire d’un employé sans son consen-tement. Dans les pays de l’offshore, les lois sont souvent beaucoup plus flexibles. Lesréductions de salaire, sans être toujours permises, sont souvent pratiquées.

Les réalités salariales diffèrent grandement d’un pays à un autre, mais quelques pointscommuns peuvent être observés dans tous les pays d’offshore. Les salaires faibles sontpeu taxés par le gouvernement. Dès que l’on dépasse environ 150 dollars par mois, ceseuil pouvant varier selon le pays, la part qui revient au gouvernement devient plusimportante.

Afin de limiter les taxes et les retenues sur les salaires à verser au gouvernement, certainsprestataires déclarent un salaire, dit officiel, de l’ordre de 50 dollars et versent le reste ausalarié sans le déclarer. Le collaborateur est ainsi officiellement un employé du presta-taire sur la base d’un salaire inférieur à son salaire réel.

Dans certains pays, cette pratique est commune dans la grande majorité des sociétésprivées, tandis que les sociétés publiques ne pratiquent que des salaires officiels, auxmontants beaucoup plus faibles. Les gouvernements tentent sans grand succès decombattre ces pratiques, qui entretiennent une économie grise.

Certains prestataires choisissent de déclarer la totalité des salaires afin d’être en confor-mité parfaite avec la loi et d’éviter de jongler avec des sommes circulant sur un circuitcaché. Comme les informaticiens en offshore raisonnent en salaire net, c’est-à-dire, aprèsdéduction de tous les prélèvements, ces prestataires augmentent le salaire brut de façonà offrir un salaire net équivalent, ce coût supplémentaire étant généralement répercutésur la tarification aux clients.

On trouve aussi des prestataires qui demandent ouvertement à leurs employés de choisirentre un salaire déclaré entièrement ou partiellement, le salaire net étant alors réduit desprélèvements légaux.

Le contrat de travail est souvent oral. Lorsqu’il est écrit, il inclut surtout les contraintesde sécurité que l’employé doit respecter, mais le salaire lui-même n’est pas toujoursprécisé.

Il n’est pas rare que les prestataires ne payent que les jours où ils ont besoin de leurscollaborateurs au salaire plein, les autres jours étant rémunérés sur la base du salaire offi-ciel, beaucoup plus faible. Les collaborateurs qui ne travaillent pas sur un projet à plein-temps ne savent jamais en ce cas combien ils gagneront le mois suivant.



69

EN RÉSUMÉVariété des modes de rémunération

On trouve en offshore une très grande variété de modes de rémunération. L’immense flexibilité dessalaires dont usent les prestataires en offshore contribue à la précarité que ressentent leurs collabo-rateurs.

Des salaires variablesLes prestataires se permettent beaucoup de libertés quant à la façon de payer leursemployés. De nombreux managers motivent leurs équipes par le biais de bonus. Ontrouve des cas où le salaire versé est de 50 dollars, le reste étant versé sur appréciationdes managers. Les salaires effectivement payés varient alors dans des proportions impor-tantes d’un mois à l’autre.

Les collaborateurs ne sont pas tous opposés à cette flexibilité des salaires, car cela leurpermet d’espérer gagner plus en travaillant plus. Les managers sont les premiers àvanter ce mode de rémunération variable, source, selon eux, d’une meilleure motiva-tion de leurs collaborateurs. Il est vrai que ce système de primes ou de bonus leurpermet de faire travailler leurs collaborateurs tard dans la nuit et durant des week-endsentiers.

Ce système n’est toutefois pas sans faille, et les injustices sont nombreuses. Dès quel’équipe devient importante, les managers ne peuvent plus apprécier le travail effective-ment réalisé par chacun. De plus, lorsque des développeurs font des journées de quatorzeheures, les dernières heures travaillées sont peu productives.

Les absences pour maladie ou pour raisons personnelles sont souvent sanctionnées. Leprestataire offshore décide parfois arbitrairement de réduire les salaires pour fairepartager par les salariés une réduction consentie à un client.

Comme on le voit, la flexibilité sur les salaires va bien au-delà de la simple possibilitéd’ajuster en offshore le salaire lorsqu’on en a besoin. Il n’est pas rare qu’un collaborateurne puisse répondre lorsqu’on lui demande combien il gagne. Il peut citer ses dernierssalaires, parfois fort disparates, mais ne sait pas ce qu’il gagnera dans les mois à venir.

De telles situations ne sont pas souhaitables. Offrir des bonus est certes une bonnechose, mais jouer sur la flexibilité des salaires au point que les employés ne savent pascombien ils gagnent est clairement un abus qui ne peut être à l’avantage du client.

Idéalement, la flexibilité des salaires doit permettre d’ajuster ces derniers à la producti-vité et à la valeur réelle de chaque collaborateur. On peut ainsi construire une grille derémunération dans laquelle le salaire de chaque collaborateur est en harmonie avec ceuxde ses collègues.

Être « trop payé »Comme on l’a dit, les salaires moyens des informaticiens dans les pays de l’offshore tour-nent autour de 100 à 400 dollars par mois. Certains talents, que l’on veut fidéliser,peuvent se voir proposer des salaires dépassant 1 000 dollars par mois.

Lorsqu’une personne voit son salaire tripler ou quadrupler du jour au lendemain, il seproduit parfois un effet inattendu. Le collaborateur devient immédiatement moinsproductif et change d’attitude vis-à-vis de son travail. Il se sent d’un coup très importantet se mêle de sujets habituellement gérés par sa hiérarchie, comme si son augmentationlui donnait le droit d’agir à la place de ses supérieurs. Son poste, auquel on souhaitait le



70

fidéliser, ne l’intéresse déjà plus, et il devient très difficile, voire impossible, de l’y faireretourner. Bien souvent, il ne peut que quitter la société après une série de heurts avec sahiérarchie.

J’ai pu observer ce type d’attitude au moins une fois chez chaque prestataire avec lequelj’ai travaillé. Il faut donc être conscient qu’une action visant à fidéliser un collaborateurpar une augmentation de salaire peut avoir l’effet directement inverse.

ÉTUDE DE CAS

Un manager trop payé

Ce cas vécu illustre parmi d’autres une situation de salaire excessif qui a entraîné un comportementdestructeur.Après de nombreux tâtonnements pour trouver un chef d’équipe compétent, on a choisi de promou-voir un chef de projet, nommé Valery. Après plusieurs mois d’observation, le client est satisfait. Il aenfin trouvé l’homme de la situation. L’équipe comptant environ soixante personnes, Valery sefélicite de sa promotion. À la fin de la période d’observation, il reçoit son nouveau salaire, et sarémunération passe de 400 à 1 200 dollars.Il commence alors à se mettre sous pression et s’attribue de son propre chef de nouvelles respon-sabilités. Sur certains sujets, il reste compétent et fournit un travail de grande qualité, mais ilcommence à s’immiscer dans les affaires de sa hiérarchie. Il veut gérer tous les aspects du manage-ment de son équipe, comme l’agencement des locaux, la gestion de la trésorerie du prestataire, lerythme où les salaires sont payés, etc.Le client a des difficultés financières à ce même moment et est en retard sur ses paiements, ce quientraîne mécaniquement un retard dans le versement des salaires des collaborateurs, le prestatairene disposant pas de réserve financière importante. Valery commence à s’inquiéter de la façon dontest gérée la trésorerie et se persuade que les affaires sont mal tenues. Il véhicule l’idée que les salairespourraient être facilement payés si l’on constituait une réserve de trésorerie équivalant à plusieursmois de salaires.Il en parle au manager de la société, qui lui explique que la marge est plus faible qu’il ne l’imagineet que la création d’une réserve de trésorerie, certes théoriquement souhaitable, est peu réaliste,car elle demanderait un temps considérable pour être constituée. De plus, la faible marge dégagéesur le client est nécessaire pour financer d’autres activités du prestataire. Valery n’en croit pas unmot et s’imagine que la marge est immense et doit permettre de constituer cette réserve rapide-ment. Il s’entête et en parle aux autres membres de l’équipe, qui ne peuvent évidemmentqu’acquiescer. Il finit par en parler au client lui-même, lequel convient que le fonctionnementserait plus fluide si ses retards de paiement n’impactaient pas les versements des salaires de sonéquipe.Fort de ce qu’il pense être un soutien de l’équipe et du client, il s’en fait une cause et délaisse lagestion de l’équipe en offshore. Les tensions avec la hiérarchie le minent, et il n’hésite pas à criti-quer de front tous les sujets. Il perd de plus en plus contact avec les tâches que réalise son équipe,ne sait plus où en sont les réalisations et est critiqué par sa hiérarchie et par le client. Sa causeprogresse cependant, et il commence à travailler à la sécession de l’équipe pour quitter la sociétéet recevoir directement le paiement des salaires du client. Il ouvre un compte en banque pour rece-voir les paiements du client, met certaines personnes dans la confidence et affirme être soutenupar le client, alors qu’il n’en est rien.



71

Le salaire conditionnel du collaborateur

Comme on vient de le voir, l’absence de paiement du client entraîne bien souvent lasuspension du versement des salaires. Dans la plupart des cas, le prestataire paie lessalaires si le retard ne dépasse pas un mois. Après deux mois de retard, cela devient plusrare. Les collaborateurs en offshore reçoivent donc leur salaire sous condition.

Cela explique pourquoi les collaborateurs choisissent, autant qu’ils le peuvent, lesprojets sur lesquels ils veulent travailler. Un client mauvais payeur entraîne des revenuserratiques. Un client bon payeur assure des revenus réguliers.

Les termes de paiement consentis par le prestataire à son client sont le plus souventrépercutés sur les collaborateurs. Si l’accord de paiement de la facture du prestataire estprévu à soixante jours fin de mois, payable au 10 du mois suivant, on constate un délai del’ordre de quatre-vingt-dix jours entre l’émission de la facture et son paiement. Pendantles trois premiers mois, il y a donc de fortes chances que les collaborateurs en offshore nesoient pas rémunérés ou seulement de façon minimale.

Pour s’assurer des meilleures équipes, il est recommandé de payer dans les temps sonprestataire en offshore. C’est l’un des critères de qualité et de sérieux les plus importantspour les collaborateurs comme pour le prestataire.

EN RÉSUMÉPaiement du client et versement des salaires

Dans la plupart des cas, la réception du paiement du client conditionne le versement des salairesdes collaborateurs en offshore. Sans réserve importante de trésorerie, le prestataire ne peut assurerplus d’un mois de salaires. Les collaborateurs en offshore, tout comme le prestataire, apprécientdonc les paiements des factures dans les délais. Les collaborateurs qui ont la possibilité de choisirleurs projets en font un critère de sélection.

Les clients qui ne sont pas au courant de ce fonctionnement utilisent parfois le blocagedes paiements pour exercer une pression sur le prestataire. La réalité est qu’ils exercenten fait cette pression sur l’équipe qui travaille pour eux, au risque de la démotiver.

Les retards de paiement des factures par le client exercent avant tout une pression sur lui-même, car ils nuisent à la productivité de l’équipe. L’un des effets inattendus de ce modede fonctionnement est que les prestataires sont parfois moins agressifs pour recouvrerleur dû, puisque leurs dépenses propres sont plus réduites.

Lors de la visite périodique du client en offshore, Valery n’est plus le même homme. Il est fatiguéet las de se faire critiquer en permanence. Il demande au client de le ramener à un rôle de déve-loppeur, en affirmant que ce serait mieux ainsi. Son action n’en continue pas moins. Soutenu parun groupe de collaborateurs qui s’imagine que le client valide ses actions, Valery envoie unmessage au client pour l’informer que les salaires n’étant pas payés, l’équipe allait se dissoudre.Il propose de créer une autre société qui recevrait directement les paiements du client et constitueraitune réserve de trésorerie pour couvrir les retards de paiement.Le management du prestataire mis en copie de ce message est furieux. Le client n’y comprend rienet pense renoncer à ce prestataire qui ne contrôle plus rien. Le président du prestataire démet alorsValery de ses fonctions, qui quitte la société quelques semaines plus tard.



72

EN RÉSUMÉPaiement des factures et service fourni

Lorsque le client décide de ne pas payer dans les temps son prestataire en offshore, il suspend dumême coup le paiement des salaires de son équipe, entraînant perte de motivation et ressentiment.Les meilleures ressources peuvent en venir à refuser de travailler pour ce client, lui préférant unclient qui honore ses factures dans les temps.

Travailler sans être rémunéré

Lors des entretiens d’embauche des collaborateurs, certains informaticiens expliquentqu’ils ont travaillé sans être payés pendant de nombreux mois et qu’ils ont décidé dequitter leur poste. Plusieurs raisons peuvent expliquer de telles situations.

Lorsque le prestataire arrête de payer ses collaborateurs parce qu’il n’est pas lui-mêmepayé par son client, le chef de projet du client, qui n’est pas dans le circuit du paiementdes factures, continue de demander des corrections et de nouveaux développements àson équipe distante. Les deux premiers mois sans paiement, l’équipe travaille norma-lement mais commence à s’inquiéter de l’absence de paiements au commencement dutroisième.

Le client paye parfois sporadiquement seulement une faible partie des sommes dues,donnant un espoir au prestataire et à son équipe. Il a bien souvent la volonté de continuerle projet mais ne dispose plus des fonds pour le financer. Le plus souvent, le projet meurtlentement, sans vraiment qu’on y mette fin. Faute d’un message fort du client, les colla-borateurs rejoignent d’autres projets du prestataire, voire d’autres sociétés.

Dans le cas des projets au forfait, les clients ne paient pas toujours le dernier versement.Cela se rencontre fréquemment lorsque le projet au forfait est petit et que le client est lui-même une petite entreprise. Il verse, par exemple, 30 % à la commande et 20 % en coursde projet. Les 50 % restants, prévus à la livraison du produit final, ne sont jamais payés.Le client justifie sa décision par la mauvaise qualité de la livraison, les faibles perfor-mances ou l’existence de bogues inacceptables.

Une fois le produit reçu et installé, le client disparaît parfois purement et simplement enne répondant plus aux messages ni au téléphone. La mauvaise volonté est en ce casévidente puisque le client ne donne aucune chance à son prestataire offshore de corrigerla qualité de la dernière livraison.

Certains prestataires organisent des stages non rémunérés sur plusieurs mois. Le stagiaireteste des applications réelles et réalise un travail pour le prestataire offshore qu’il factureà son client. Après cette période, le prestataire offshore propose aux meilleurs, souventpeu nombreux, de rejoindre sa société. Les autres sont remerciés et peuvent parfois continuerà travailler gratuitement. On trouve ainsi des personnes qui ont travaillé volontairementgratuitement plusieurs mois pour se constituer une expérience.

D’autres prestataires, ou les mêmes, demandent que leurs collaborateurs réalisent gratui-tement un premier projet test d’un client en leur proposant de n’être payés que si le clientest satisfait. La plupart des collaborateurs en offshore ont fait l’expérience de travaux deplusieurs mois sans rémunération. C’est une expérience pénible, qu’ils souhaitent éviterdans le futur.



73

L’émigration vers les pays occidentaux

Les collaborateurs en offshore connaissent les salaires des informaticiens occidentaux etrêvent parfois d’atteindre de telles rémunérations. Ceux qui ont émigré se rendentcompte que ces montants, qui leur semblaient colossaux au départ, sont loin d’offrir lepouvoir d’achat qu’ils anticipaient.

Les développeurs envisagent d’émigrer vers l’Ouest à deux moments clés de leur carrière.À la sortie de l’université, ils imaginent qu’ils vont émigrer et réussir dans un pays del’Ouest avec un salaire immédiatement supérieur à celui auquel ils pourraient prétendredans leur pays. Viennent ensuite les personnes qui ont travaillé dans leur pays et ont eudes enfants qui atteignent l’âge de 6 à 12 ans. Ils ont appris la langue de leur paysd’accueil et s’expatrient en disposant d’une certaine somme d’argent, qui leur permet dedémarrer, souvent avec une offre d’emploi leur offrant une certaine sécurité. Leur objectifest de donner un meilleur potentiel et un meilleur cadre de vie à leurs enfants.

Lorsqu’une personne s’en va et se plaît dans son pays d’accueil, il est probable qu’elletrace un chemin pour ses amis et collègues. Elle parle de ses conditions d’intégration etdes astuces légales à sa disposition. Souvent, ceux qui ont émigré se sentent seuls et fontleur possible pour que des personnes de leur pays, qu’ils connaissent bien, viennent lesrejoindre.

EN RÉSUMÉSalaires en offshore et salaires occidentaux

Les salaires des informaticiens des pays occidentaux font rêver les pays de l’offshore. Ceux quichoisissent d’émigrer découvrent rapidement que la différence entre les salaires n’est pas si impor-tante dès lors qu’on prend en compte la fiscalité et le coût de la vie. Après plusieurs années àl’étranger, nombre d’informaticiens préfèrent retourner vivre dans leur pays.

ÉTUDE DE CAS

Un chef de projet qui émigre

Pour illustrer ce que découvre le collaborateur en offshore en émigrant, prenons le cas d’un chef deprojet confirmé, qui touche 800 dollars en offshore et qui se voit offrir un poste à Paris pour unsalaire brut de 4 000 dollars. Son premier calcul est de se dire qu’il a quintuplé son salaire.En réalité, les 800 dollars qu’il perçoit dans son pays sont entièrement à son usage, tandis que ses4 000 dollars de salaire brut deviennent 3 200 dollars nets après prélèvements des charges. Il paieaussi des impôts sur le revenu. L’appartement, qui lui coûtait entre 100 et 150 dollars dans sonpays, passe à 1 000 à 1 800 dollars, par exemple à Paris. S’il envisage de s’éloigner de Paris, il doitacheter une voiture. L’assurance-automobile, de 30 dollars par an dans son pays, lui coûte1 000 dollars. Si l’on ajoute la nourriture, la différence de revenu réel est beaucoup moins importantequ’il ne l’imagine.Lorsque des difficultés d’intégration s’ajoutent à cette faible augmentation du niveau de vie, lesémigrants choisissent souvent de retourner travailler dans leur pays, forts d’une expérience dequelques années à l’étranger.



74

Le statut des collaborateurs en offshoreUne des réalités de l’offshore est qu’on ne connaît jamais très bien le prestataire aveclequel on décide de travailler, même si l’on a pu étudier son site Internet ou s’il a étérecommandé par une personne de confiance.

Il n’est pas rare de voir des opérateurs offshore, souvent assez petits, proposer desressources sans même être constitués officiellement en société. Leurs collaborateurs sont ence cas payés au noir et travaillent le plus souvent dans un appartement loué par le manager.

Il est très difficile de détecter ces sociétés fantômes, d’autant qu’elles peuvent disposerde solides références, lesquelles n’ont probablement jamais décelé leur statut légal. Lescollaborateurs de tels prestataires se trouvent dans une situation doublement précaire :ils ne sont pas officiellement salariés et, pour peu que le gouvernement découvre leuractivité, la société se verra démantelée et son manager poursuivi, voire les collaborateurseux-mêmes. Le client perd alors son équipe, avec peu d’espoir de la reconstituer un jour.Il risque en outre de se voir inquiété pour avoir réglé des factures à une société fictive.

Si la société existe effectivement, le statut d’employé n’est pas pour autant toujours d’unegrande clarté. De nombreuses sociétés font travailler leurs collaborateurs sans contrat detravail. Leur poste n’est pas décrit, leur salaire est vague, et les obligations respectives nesont pas claires.

Cette situation est gênante pour le salarié, qui ignore s’il a droit à des vacances ou àdes congés maladie, s’il dispose d’une couverture sociale, d’un préavis en cas d elicenciement, etc. L’employeur décide de tout et peut accorder des droits réglementairesà ses employés ou changer à son gré les règles du jeu.

EN RÉSUMÉLe statut incertain de salarié

Il n’existe pas toujours de contrat de travail entre le salarié en offshore et son employeur. Le collabo-rateur est souvent payé au noir. Quand elles existent, les obligations légales ne sont pas toujoursclaires, notamment sur les salaires, les congés ou l’assurance-maladie. Le salarié est de bout enbout dans une situation précaire.

Dans certains pays, comme le Belarus, on trouve encore la notion d’enregistrement dansune commune pour avoir le droit d’y travailler. Cette pratique tend toutefois à disparaîtredans les pays de l’ex-URSS, comme en Ukraine, où l’enregistrement (registration) n’existe plus.

La pratique de l’enregistrement vise à contrôler les migrations de populations afind’éviter la désertification de régions défavorisées. Les lois n’interdisent pas que l’on sedélace d’une ville à une autre, mais, pour s’enregistrer dans une ville et pouvoir ytravailler, il faut disposer d’un appartement ou d’un certificat d’hébergement. Sans cetenregistrement, une société ne peut embaucher. Elle peut toutefois assister un employépour obtenir un enregistrement. Les employés non enregistrés n’ont de choix que detravailler de façon non déclarée.

Certains prestataires font travailler leurs collaborateurs dans le cadre d’un contrat detravail dûment signé par les deux parties et d’un salaire totalement déclaré. Le surcoûtpar rapport aux prestataires qui paient une partie des salaires au noir est généralementrépercuté sur le tarif des prestations, dans une fourchette de 20 à 30 %. Si le client exigede son prestataire offshore de n’employer que des collaborateurs dûment déclarés etrémunérés, il doit s’attendre à une tarification plus élevée.



75

Même si ces pratiques en marge de la légalité sont très courantes et que la grande majo-rité des prestataires et autres sociétés privées y recourent dans les pays de l’offshore, ellesne vont pas sans risque pour le client.

Les conditions de travail chez le prestataire offshoreLes conditions de travail offertes par le prestataire offshore contribuent grandement à attirerles meilleures ressources, à motiver les équipes et à créer une saine ambiance productive.

Ces conditions varient du tout au tout d’un prestataire à un autre. Trop souvent, lesdépenses relatives aux conditions de travail sont considérées comme superflues. Debonnes conditions de travail permettent pourtant non seulement de tirer le meilleur partide l’équipe en offshore mais aussi d’avoir plaisir à se rendre au travail.

Le cadre de travail

Les sociétés offshore offrent un cadre de travail extrêmement variable. L’espace de travailde chaque collaborateur est le plus souvent restreint, de façon à placer le plus depersonnes dans une même surface. On trouve de grandes salles, avec de petits bureauxalignés, à peine plus grands que des tables d’écolier, où le silence n’est troublé que parle cliquetis des claviers et le ronronnement des ventilateurs.

S’il est souvent relativement neuf, le mobilier est clairement bon marché et se détériorerapidement. Les salles de travail sont peu agréables. On rencontre fréquemment dessalles aveugles, dans lesquelles une dizaine de développeurs travaillent sous un éclairageau néon fatigant.

Dans les pays où il fait chaud l’été, l’air conditionné, lorsqu’il fonctionne, ne couvre querarement toutes les pièces. Les premières pièces servies sont les salles serveur et lesbureaux des managers les plus importants. Les salles où la majeure partie des déve-loppeurs travaille sont les dernières servies. L’été, la productivité y baisse sensiblement,et une tension continuelle rend le personnel moins prompt à s’engager dans les tâchesdélicates ou ennuyeuses.

Les parties communes des immeubles sont généralement délaissées. Leur réfection estla dernière priorité, d’autant plus que les locaux du prestataire offshore ne détonnent pasvraiment par rapport à ceux des autres sociétés du pays. Les toilettes, par exemple, sontgénéralement vétustes, sales et malodorantes. Le papier hygiénique est rarement présent,et le fonctionnement de la chasse d’eau souvent défectueux.

L’installation électrique du hall d’entrée pend au plafond avec de nombreux fils inquié-tants. Les escaliers empestent de grands bacs débordant de milliers de mégots de cigarettesfumées les mois passés. Des gravats de travaux anciens restent sur place, et personne nesonge à les enlever.

Cette sombre description est loin d’être exagérée, même si tous ces travers ne se retrou-vent pas systématiquement chez tous les prestataires. Il ne fait aucun doute qu’un mauvaiscadre de travail nuit à la productivité et au désir des collaborateurs de rester au travail.Quelques prestataires se rendent d’ailleurs compte que le cadre de travail et l’hygiène sontessentiels pour obtenir le meilleur de leurs collaborateurs. Force est de constater que cesderniers font exception et que leurs efforts mêmes manquent de constance.



76

Il est possible de prévoir contractuellement un cadre de travail agréable et propre, afin defournir à l’équipe un environnement dans lequel on aurait soi-même plaisir à travailler.Des conditions minimales peuvent être exprimées dans le contrat. Pour éviter que cetengagement soit ignoré, on peut prévoir une pénalité, par exemple en pourcentage dumontant facturé pour les collaborateurs, si le cadre de travail ne satisfait pas auxexigences du contrat.

EN RÉSUMÉLe cadre de travail en offshore

Chez de nombreux prestataires offshore, le cadre de travail est déplorable. Un cadre de travailagréable est pourtant un facteur important de qualité du travail et de motivation des équipes en offshore.Il est recommandé de définir contractuellement un niveau minimal de propreté et de confort que leprestataire aura obligation de respecter.

Les horaires de travailGénéralement, les horaires de travail en offshore sont assez peu différents de ce que l’onpratique en Occident. La journée commence vers 9 ou 10 heures et s’achève vers19 heures, parfois plus tard.

Certains prestataires font travailler des développeurs en second emploi. Ces derniers seprésentent vers la fin de la journée de travail normale et restent entre six et huit heuresdans les locaux, par exemple de 18 heures à minuit ou 2 heures du matin.

D’autres prestataires ont des équipes qui travaillent au rythme de leur client américain.S’il est situé sur la côte Ouest des États-Unis et que le prestataire soit à Kiev, on observedix heures de décalage horaire. Les équipes arrivent donc entre 18 et 20 heures, ce quirisque de privilégier les seconds emplois.

J’ai rencontré des équipes dont le client voulait économiser sur les stations de travail. Lesdéveloppeurs faisaient donc les trois-huit sur ces machines, chaque poste de travail étantpartagé par trois utilisateurs. Ce type d’organisation devient vite un casse-tête et n’est pasrecommandé. Par exemple, il est impossible d’organiser une réunion avec tous les chefsde projet.

Les vacancesLa gestion des vacances est un sujet particulièrement épineux pour le client de l’offshore.Pour ce dernier, les vacances des collaborateurs en offshore pèsent sur la disponibilité dupersonnel tout en représentant un potentiel de réduction des dépenses sur l’année,puisque le client ne paye naturellement que les jours effectivement travaillés.

Selon que les collaborateurs en offshore travaillent 200, 260 ou 300 jours par an, le coûtdes prestations par personne sur l’année est très différent, de même que la quantité detravail. L’impact sur le budget annuel des opérations en offshore peut devenir très impor-tant si l’on travaille en régie avec une équipe fixe. Au forfait, les vacances ne sont qu’unecontrainte, qui peut tout au plus retarder une livraison ou ralentir un développement.

Si les congés payés sont une obligation légale dans nombre de pays de l’offshore, lespersonnels prennent rarement un mois de vacances dans l’année. Lorsque le prestataireétablit une différence entre salaire officiel et salaire réel, le collaborateur ne perçoit decongés payés que sur son salaire officiel. Lorsque le prestataire agit ainsi, les collabo-rateurs en offshore perçoivent un salaire très inférieur durant leurs congés et préfèrentsouvent ne pas partir en vacances.



77

Le client a besoin de connaître le nombre de jours de vacances de ses collaborateurs afind’établir un budget tenant compte des jours de travail disponibles en offshore. Le contratdoit donc spécifier le nombre de jours de vacances maximal et minimal par employé, afinde ne pas avoir la surprise de voir son budget augmenter de 20 % parce que les informa-ticiens n’ont pas pris de vacances.

La sécurité des locaux

Il est surprenant de constater que le niveau de sécurité des locaux de l’offshore est parfoistrès largement supérieur à ce que l’on rencontre localement. En plus des alarmes diversesplacées ici et là, il n’est pas rare de trouver un ou plusieurs gardes qui veillent toute la nuitsur les locaux.

Ce niveau de sécurité extrêmement élevé assure une excellente protection des informa-tions et du matériel chez le prestataire. Généralement, les droits d’accès des collaborateurssont clairement définis, empêchant, par exemple, un collaborateur de venir travailler endehors des heures normales s’il n’est pas accrédité pour cela. De même, la sortie du matérielest très contrôlée.

Inviter des collaborateurs à travailler chez le client

Un grand nombre de sociétés clientes invitent certains de leurs collaborateurs de l’off-shore à venir travailler localement de façon permanente. Il n’y a pas de gain financier àespérer d’une telle approche, les services d’immigration vérifiant presque systématique-ment que le salaire offert est en accord avec le marché.

La véritable raison de ces invitations est de trouver une recrue de qualité que l’on a apprisà connaître pendant la période où l’on a travaillé ensemble et qui est immédiatementopérationnelle.

Certains clients invitent localement des salariés de leur prestataire à des fins de forma-tion. La formation est ici considérée au sens large. Apprendre à un collaborateur àtravailler avec son client n’est toutefois pas facile à formaliser. On peut aussi invitertemporairement un collaborateur lors des livraisons importantes, afin qu’il accompagnele déploiement et forme les équipes d’intégration locale.

Quand on invite un collaborateur en France pour une période courte, le client doit prendreen charge les dépenses indiquées au tableau 3.2.

Tableau 3.2. Coût d’un collaborateur de l’offshore invité en France

Sujet Estimation du coût

Voyage La société paye le billet d’avion, souvent en tarif économie.

Frais de vie Entre 50 et 75 euros par jour dans la plupart des cas. Certains demandent des indemnités supérieures.

Logement On place souvent le personnel offshore dans des résidences hôtelières. Le coût varie selon la ville et la qualité de la résidence de 50 à 120 euros par jour.



78

On arrive assez rapidement à des montants comparables à ceux d’une personne embauchéelocalement.

Ces invitations sont cependant très appréciées. Elles permettent de récompenser uncollaborateur que l’on apprécie. Ce dernier s’enrichit de la culture et des pratiques d’unautre pays, ce qui le rend à même de mieux comprendre le fonctionnement de la sociétécliente. Il peut en outre rencontrer les intervenants du projet qui ne se rendent jamaischez le prestataire en offshore.

Conclusion

Les sociétés comprennent rapidement que pour être compétitives et réactives, il leurfaut réduire les coûts humains des réalisations informatiques. Pour ce faire, l’utilisationde ressources en offshore demande beaucoup de précautions afin de ne pas risquer dedéstabiliser les équipes.

En offshore, la situation est pour le moins exotique. Les protections sociales sont faibles,rendant possibles de nombreux excès de la part des prestataires. Les plus sérieux parmices derniers, qui parviennent à monter les meilleures équipes, proposent à leurs collabo-rateurs un environnement de travail sain très apprécié.

La gestion des ressources humaines comporte toujours une part de défi, consistant àréaliser plus, plus rapidement et avec une meilleure qualité. Ce sont les hommes qui assu-rent le succès ou l’échec des projets. Un bon management ne peut être qu’un gage de succès.

Ce chapitre a cherché à appréhender les différences majeures que l’on constate entre lesprojets locaux et en offshore. Le client qui souhaite exploiter tous les excès que permet-tent les lois des pays de l’offshore comprend vite que ce comportement ne conduit querarement au succès. À l’inverse, si ces différences sont bien comprises, il est possible demotiver les équipes distantes, de maintenir une équité en leur sein et d’atteindre desrésultats contrôlés et fiables.

Sujet Estimation du coût

Déplacements Le plus souvent, on paie les trajets en taxi depuis et vers l’aéroport et une carte Orange sur les zones concernées en région parisienne.

Retour vers le pays

Lorsque la personne reste plus de six semaines, elle demande généralement soit de se faire accompagner de son épouse durant une semaine, soit de retourner dans son pays égale-ment une semaine. Il faut compter une semaine dans le pays de l’offshore toutes les six semaines. La société paye alors tous les frais d’avion et de taxi.

Tableau 3.2. Coût d’un collaborateur de l’offshore invité en France(suite)


79

Chapitre 4

Les modes de fonctionnement

de l’offshoreCe chapitre expose les différents modes de fonctionnement que l’on peut envisager avecson partenaire ou sa filiale en offshore. Chaque mode couvre certains objectifs et présentedes avantages et des inconvénients. Lorsqu’on n’a pas encore travaillé avec une équipeen offshore, on éprouve certaines difficultés à choisir entre les différentes options dispo-nibles.

La crainte que le partenaire ou les collaborateurs en offshore agissent pour détourner leproduit, le revendre ou le réutiliser dans d’autres développements est un préjugé tenace.La direction de la société cliente ne se gêne pas pour exprimer ses craintes. Elle considèresouvent la personne en charge de mettre en place l’outsourcing comme responsable dela sécurité. Pour légitime qu’il soit, en local comme en offshore, ce type de préoccupationne doit pas pour autant guider tous les choix en retenant systématiquement l’option laplus sécurisée. On arriverait alors à un montage dont les coûts et les contraintesrendraient toute externalisation des développements impossible.

Le besoin de limiter les risques pousse naturellement vers des réalisations au forfait. Sicette approche prend tout son sens lorsqu’on travaille avec de grands cabinets de conseilou de grands intégrateurs, elle perd beaucoup de son intérêt pour une collaboration avecun prestataire en offshore, surtout sur des projets de taille importante. La réalité montreque l’approche au forfait est source de problèmes, qui l’emportent bien souvent sur lesavantages attendus.

Ce chapitre expose les avantages et inconvénients de chaque approche afin de rendre leschoix les plus objectifs possible.

Le montage des équipes en offshore

Le choix de montage d’une équipe en offshore dépend avant tout de la taille du projet etde ses exigences en matière de sécurité.

Les principales options disponibles sont les suivantes :

• Si le projet est très petit ou bien défini, il peut être réalisé au forfait, accompagné d’uncontrat prévoyant les défections du prestataire.



80

• Si l’on souhaite confier des projets importants de façon récurrente et que l’on fasse dela sécurité et du contrôle des opérations une priorité par rapport aux coûts et à la flexi-bilité, on peut choisir de monter une filiale en offshore.

• Dans tous les autres cas, il est préférable de travailler avec un prestataire en offshore.

Les sections qui suivent détaillent chacune de ces approches.

Le prestataire au forfaitLes sociétés qui ont de petits projets ou des projets qu’il est facile de définir dans leurtotalité attachent peu d’importance au prestataire qui les réalisera. Elles veulentdisposer de leur produit au coût le plus bas, en conservant une part importante dupaiement à l’acceptation du produit livré, de façon à garder un moyen de pression sur leprestataire.

Le projet est généralement facile à définir, soit par nature, soit au moyen d’une maquettecommentée. La charge de travail de ces petits projets se situe aux alentours de six moisà deux ou trois années/homme.

Pour réaliser ces projets, ces sociétés créent un document décrivant le projet à réaliser etl’envoient à quelques prestataires. Ce document est accompagné des conditions contrac-tuelles les plus importantes, notamment le paiement d’au moins 50 % de la facture à vali-dation de la livraison finale. Elles demandent aux prestataires pressentis de leur envoyerleur meilleure proposition. Le projet peut aussi être placé sur un site d’attribution deprojets sur offres sur Internet, comme le propose www.elance.com.

Sur ces sites, la société qui propose un projet fournit tous les éléments relatifs à sonaffaire afin de le décrire aussi complètement que possible. Sans connaître les offres desconcurrents, les prestataires candidats envoient leur proposition en annonçant à quelprix le projet peut être réalisé. À la fin d’une période donnée, le client retient la meilleureoffre.

EN RÉSUMÉLes petits projets au forfait

Les petits projets au forfait, par nature stables, totalement définis et de taille modeste, peuvent êtreconfiés à des prestataires choisis sur appel d’offres sur Internet. Cette solution donne généralementsatisfaction pourvu que le projet s’y prête. C’est toutefois une solution risquée, tant pour le client, quipeut ne jamais disposer d’un produit satisfaisant, que pour le prestataire, qui peut ne jamais recevoirson dernier paiement.

Ce sont souvent des indépendants dans les pays de l’offshore qui remportent ce type demarché. Certains informaticiens indépendants répondent aussi à ces appels d’offres, àdes niveaux de prix sans concurrence. On peut trouver des propositions à partir de400 dollars par mois. Le niveau de compétence peut être très variable, allant de l’étudiantsans expérience au développeur très expérimenté, momentanément sans emploi.Certains développeurs prennent ce type de projet en complément de leur travail et enassurent le développement, à plusieurs, après les heures de travail. Même si ce sont detels indépendants qui gèrent le projet, leur réponse à l’appel d’offres est souvent dissi-mulée sous une structure fantôme à des fins de crédibilité. On ne peut donc jamais vrai-ment savoir comment le projet est géré. Le plus souvent c’est sans importance, car le


http://www.elance.com

Chapitre 4 – Les modes de fonctionnement de l’offshore

81

succès est au rendez-vous. Ce mode de fonctionnement n’offre toutefois pas de garantiessuffisantes pour de grands projets ou des projets qui revêtent une importance stratégiquepour le client.

Dans tous les cas, l’engagement du prestataire sur la réussite du projet est faible. Si unautre travail plus profitable se présente, il bascule vers ce dernier et, dans le meilleur descas, transfère le projet à des connaissances et relations.

Vue du côté des informaticiens en offshore, la situation n’est guère plus rassurante.Comment être certain d’être payé en fin de projet, surtout si tout le paiement est effectuéà l’acceptation de la livraison ? Le fait est que de nombreux prestataires ne sont paspayés, ce qui entretient un climat de forte défiance.

Comme dans tous les partenariats, on trouve aussi des sociétés qui ont utilisé cetteapproche avec une grande ouverture d’esprit. Si le client est prêt à accepter des retards etque le projet ne soit pas critique, la gestion de projet est aussi simple qu’efficace.

La filiale en offshoreLes sociétés qui souhaitent assurer en offshore un volume important et régulier de réali-sations ont souvent envie de créer une filiale en offshore. Si, dans certains cas, il s’agit dela meilleure solution, il n’en reste pas moins qu’il s’agit d’une décision lourde, complexe,coûteuse et finalement assez risquée.

Limiter les risques

Cette approche a pour principales motivations d’éviter tous les risques et de ne pasdépendre d’un tiers pour ses réalisations en gardant une maîtrise totale des opérations.Si l’objectif est d’obtenir les meilleures conditions de sécurité et de protection de lapropriété intellectuelle, la création d’une filiale dans un pays de l’offshore se justifie.

Bien des sociétés supposent que la création d’une filiale en offshore apporte unemeilleure rentabilité et une gestion plus fine. L’expérience montre qu’il est possibled’atteindre des coûts comparables avec un prestataire tout en disposant d’un totalcontrôle administratif sur les équipes et les opérations.

EN RÉSUMÉFiliale en offshore et limitation des risques

On pense parfois résoudre l’essentiel des risques en offshore en créant sa propre structure. Saufdans de rares cas, il est démontré que l’on peut se prémunir des risques aux mêmes coûts avec unprestataire en offshore.

En choisissant de créer une filiale, la société assume tous les risques de ses choix, tant àl’égard du pays d’accueil que de l’administration de la société. De plus, elle ne bénéficiepas des économies d’échelle apportées par un partenaire sur l’administration générale outechnique, la flexibilité des équipes, etc.

Les chefs d’entreprise des prestataires locaux sont généralement rompus aux lois de leurpays et savent exactement comment faire fonctionner leur société dans les meilleuresconditions. À l’inverse, une société étrangère opère le plus souvent « selon les livres »sans toujours saisir les trucs et astuces bien connus des managers locaux.



82

Filiale ou prestataire en offshore

Pour créer une société dans un pays de l’offshore, le gérant doit être de préférence unepersonne appartenant au pays, même si le capital est détenu par des étrangers. Lesdémarches administratives peuvent être inextricables ou à tout le moins fortementconsommatrices de temps. Des appuis auprès des administrations compétentes pourfaciliter les démarches sont indispensables.

Les grandes sociétés rencontrent moins de difficulté, car elles ont accès à des avocatsspécialisés dans le droit de ces pays. Les coûts induits peuvent être cachés par descontrats à l’année avec des cabinets. Les sociétés plus petites qui s’y essayent rencontrentdavantage d’aléas et à des coûts souvent très importants. Dans certains pays, l’effort n’envaut pas la chandelle.

Les pays qui sont en train de rejoindre la Communauté européenne offrent certainementplus de facilités pour créer une société à capital essentiellement occidental. Ces pays ontcependant plus de chances de rattraper rapidement leur retard économique et de devenirmoins intéressants à long terme pour les réalisations en offshore.

EN RÉSUMÉCréation d’une société en offshore

La création d’une filiale en offshore demande des démarches lourdes et coûteuses. Leur gestionadministrative peut de surcroît se révéler complexe. C’est pourquoi la création d’une filiale n’estjustifiée que pour assurer la mise en place de règles de sécurité et de protection de la propriété intel-lectuelle strictes.

Avant de conclure hâtivement que l’on peut réaliser des économies importantes en créantune filiale, il convient de calculer le montant de ces économies supposées.

De prime abord, la comparaison du salaire mensuel que reçoit un collaborateur en off-shore avec la somme facturée par un prestataire est telle que l’on se dispense de calculerplus loin. Le coût réel total du personnel dans la filiale en offshore, tenant compte de toutesles dépenses annexes de personnel, de locaux, d’administration et d’investissement, estcependant beaucoup plus important.

Le tableau 4.1 récapitule les principaux postes à prendre en compte dans le calcul descoûts d’une filiale offshore comparés à ceux d’un prestataire.

Tableau 4.1. Avantages comparés d’une filiale et d’un prestataire offshore

Poste Filiale offshore Prestataire offshore

Salaires des informaticiens

Les salaires semblent faibles et sources d’économies potentiellement importantes par rapport à la somme facturée par un prestataire.

Les prestations semblent au premier abord anormalement élevées, et l’on imagine une marge exagérée du prestataire.

Environnement de travail

Les locaux, l’électricité, les charges doivent être payés.

Ces charges sont incluses dans le coût des prestations.

Communications Le téléphone et l’Internet sont des frais supplémentaires.

Ces sommes sont parfois facturées séparément au client selon le contrat avec le prestataire.



83

Poste Filiale offshore Prestataire offshore

Charges et taxes sur les salaires

Toutes les charges et taxes sont intégrale-ment payées par la filiale, ce qui, dans certains pays, peut représenter un pour-centage approchant du montant du salaire brut de l’informaticien.

Les charges salariales et taxes sont entiè-rement gérées par le prestataire.

Vacances, naissances et maladies

Toutes ces périodes sont le plus souvent payées par l’employeur et s’ajoutent au coût de chaque personne.

Seules les journées travaillées sont factu-rées. Le prestataire offshore gère lui-même ces surcoûts.

Logiciels Tous les logiciels doivent être acquis par la société, qui doit également contrôler l’utili-sation légale des licences.

Certains logiciels sont fournis avec les prestations. Par accord contractuel, on donne la responsabilité au prestataire de s’assurer de la légalité des licences mises à disposition.

Management Le management peut être un poste impor-tant s’il s’agit d’un expatrié qui est payé comme tel.

Le management, généralement très compétent, est entièrement pris en charge dans le cadre des prestations.

Tâches centrales

Les tâches de gestion des ressources humaines, d’administration de la société, de comptabilité et relatives à l’informatique interne doivent être assurées en plus des prestations de développement.

Ces tâches sont généralement intégrées dans le service fourni par le prestataire. Dans certains cas, l’informatique interne n’est pas assurée en offshore, surtout dans le cas de prestations de grande ampleur, qui nécessitent des ressources IT dédiées.

Capacité à embaucher

La capacité à embaucher est généralement assez faible, sauf si la société jouit déjà d’une bonne réputation dans le pays.

La capacité à embaucher est généralement excellente, et les meilleurs profils souhai-tent rejoindre le prestataire, pour peu que ce dernier soit bien choisi.

Efficacité fiscale Faible, car les tâches sont réalisées selon les livres.

Les managers connaissent la meilleure façon d’opérer sans enfreindre la légalité.

Intercontrats et flexibilité

Les intercontrats sont payés par la société. La flexibilité des ressources, qui est le premier avantage de l’utilisation de l’offs-hore, s’en trouve presque perdue.

La flexibilité des ressources est pleinement prise en charge par le prestataire offshore.

Risque social de réintégration dans la maison mère

Certains employés peuvent essayer de faire prévaloir le fait qu’ils sont, en réalité, embauchés par la société mère, qui est donneuse d’ordres. Les contrats doivent être bien conçus pour éviter ces risques.

Aucun risque de réintégration chez le donneur d’ordres, mais cela doit être prévu dans le contrat des prestations offshore.

Tableau 4.1. Avantages comparés d’une filiale et d’un prestataire offshore(suite)



84

Le montant facturé par le prestataire correspond à une marge normale, d’environ 10 à30 %. Seules son expérience du marché, les économies d’échelle qu’il réalise sur lesservices généraux et la flexibilité naturelle de ses équipes, liée à ses activités avecplusieurs clients, lui permettent de tenir de telles marges. En créant une filiale, on nedispose souvent pas de l’expérience de ces managers, si bien que les coûts finaux parpersonne sont assez proches de ce que facture un prestataire.

Le fait de travailler avec un prestataire permet en outre d’effectuer une pression sur lui,de lui exprimer son mécontentement si la productivité ou la qualité faiblissent ou si ladiscipline est mal assurée. Il fera sans doute de son mieux pour corriger ces problèmes etplacera des personnes gracieusement sur le projet, peut-être des personnes en inter -contrat.

Surtout, il est très facile de changer de prestataire ou de pays si les conditions ne sontplus telles qu’on le souhaite, soit que le personnel devient trop coûteux, soit que les loisévoluent dans un sens défavorable, soit encore que l’on n’a simplement plus besoind’opérations en offshore. Avec une filiale, c’est évidemment beaucoup plus d ifficile.

EN RÉSUMÉComparaison des coûts d’une filiale avec ceux d’un prestataire offshore

Les coûts des réalisations dans une filiale ne sont pas toujours beaucoup moins élevés que ceuxfacturés par un bon prestataire en offshore. La comparaison des coûts réels est difficile à effectuerdans les moindres détails. De nombreux critères de comparaison doivent être considérés, dontcertains se mesurent à un risque accru (fiscalité, management) ou à la perte de certains avantages(flexibilité, prestations centrales comprises, etc.).

La dépendance au management de la filiale

En créant une filiale, on devient dépendant, non plus d’un prestataire, mais du managemen tque l’on a mis en place.

On constate les mêmes problèmes de choix du manager pour une filiale en offshore quepour une filiale commerciale. Le problème dans un pays de l’offshore est toutefois pluscomplexe, car le profil recherché est plus rare.

Le manager d’une filiale commerciale est essentiellement cadré par ses objectifs, alorsqu’avec une entité de services informatiques pour un donneur d’ordres, on rechercheavant tout la personne qui saura gérer les embauches, l’administration et la fiscalité. C’estun poste certes intéressant mais qui ne satisfait pas souvent les managers ambitieux, quiveulent avant tout développer leurs propres affaires pour leur profit. Un tel manager estdonc difficile à trouver et encore plus à remplacer. C’est pourquoi on décide si souventd’envoyer une personne sur place, le temps de trouver le remplaçant, avec tous lesproblèmes que cela peut entraîner.

Dans certains pays, il n’est pas rare de devoir faire face à des rackets ou à des pratiquesmafieuses. Le manager d’un prestataire compétent saura sans doute mieux répondre auxintimidations, par exemple en faisant état de liens avec des projets gouvernementauxsensibles. Cela décourage généralement les mafieux, qui ne souhaitent surtout pas entreren conflit avec les États.



85

EN RÉSUMÉLes principaux risques liés à une filialeLes risques sont nombreux et de natures très diverses. Les principaux sont liés au management quel’on met en place, à la fiscalité et aux usages locaux. On risque aussi dans certains pays de faire faceà des tentatives de racket ou d’intimidation contre lesquelles on se trouvera démunis.

Le prestataire offshoreLe prestataire offshore est le choix le plus naturel et le plus flexible. C’est le mode de fonc-tionnement qui apporte le plus d’avantages à la société cliente. Il permet notammentd’atteindre les objectifs de sécurité, de flexibilité et de coûts que l’on s’est fixés.

La base de la collaboration est un contrat ou un accord de partenariat, dans lequel onprécise clairement les obligations des parties et le mode de fonctionnement, en régie ouau forfait.

Le mode de fonctionnement doit être déterminé avant de choisir le prestataire offshore.Certains prestataires, surtout parmi les géants de l’offshore, ne savent pas toujourss’adapter au mode voulu par le client.

Il est important de préciser dans le contrat tous les éléments que l’on souhaite traiter :facturation, services intégrés et refacturés, engagements relatifs à la gestion du personnelet à la sécurité, etc. C’est un document qui sert régulièrement (voir le chapitre 9 pour plus dedétail sur les contrats en offshore).

Il ne faut pas hésiter à façonner le partenariat exactement comme on le souhaite et nesurtout pas adopter le modèle présenté par le prestataire.

ÉTUDE DE CAS

Des managers ambitieux

J’ai rencontré des cas où le manager ambitieux déclarait suivre scrupuleusement les lois du pays etdisposait des reçus qui convenaient pour toutes ses transactions. En réalité, l’essentiel des tâchesadministratives était réalisé, comme le plus souvent dans ces pays, en séparant l’officiel de l’offi-cieux, la différence allant dans sa poche. Une fois découvert, il ne souhaitait pas même avouer unequelconque malversation. Au contraire, il expliquait qu’il avait su optimiser les dépenses et qu’ilétait normal que les profits de ces optimisations lui reviennent.Un autre manager avait créé une activité parallèle avec les équipes. Il réalisait des projets offshorepour d’autres sociétés, à l’insu de la maison mère. Les paiements étaient reçus sur un compte ouvertà cet effet, et les revenus étaient distribués entre les développeurs qui participaient à ces dévelop-pements et le manager.

Modes de fonctionnement avec le prestataire

Régie, forfait ou régie forfaitée, tous les modes de fonctionnement peuvent être envisagésavec un prestataire en offshore. De même, toutes sortes d’équipes peuvent être consti-tuées : fluides selon les besoins, dédiées ou isolées des autres employés du prestataire.L’accord liant le prestataire et le client permet de définir précisément comment on souhaitetravailler ainsi que les objectifs de sécurité, de confidentialité et de flexibilité que l’on souhaiteatteindre. Le contrat garantit le bon fonctionnement des opérations et le succès des projets.



86

Les labels qualitéLes certifications ISO 9000/9001 ou CMM 3/5 et plus sont certainement des labels dequalité qui donnent une certaine dimension à un prestataire. Le terme « qualité » est enfait ambigu. Un label qualité indique que la société a mis en place un plan qualité garan-tissant la gestion d’un ensemble d’activités selon des procédures pleinement documen-tées, sur lesquelles le personnel a été formé et qui sont appliquées quotidiennement. Enrevanche, ces labels ne garantissent en rien la qualité finale du produit livré.

De plus, ces labels peuvent ne couvrir qu’une partie de l’activité de la société. Il convientdonc de vérifier la nature des activités certifiées lors du choix d’un prestataire.

Si l’on est soi-même certifié avec l’un de ces labels, les procédures prévoient de demanderaux fournisseurs s’ils le sont aussi. Si tel n’est pas le cas, les mêmes procédures permet-tent d’exiger de voir ces procédures de façon à pouvoir juger de leur qualité. Ces certifica-tions sont intéressantes en cas de prestations au forfait mais ne sont pas applicables à laproduction de logiciel en régie. Dans ce cas, on demande généralement au prestataire demettre en œuvre les méthodes du client.

Dans tous les cas, les labels qualité démontrent la rigueur atteinte par les sociétés qui lesdétiennent. Même dans le cas où l’on met en place ses propres méthodes, on peut êtrecertain que la société saura s’y plier.

EN RÉSUMÉCertifications de qualité

Les sociétés qui disposent de labels de qualité démontrent leur capacité à être rigoureuses. L’utili-sation de procédures certifiées n’est pas adaptée aux projets en régie, où le client met en place sespropres méthodes et procédures.

Les marges des prestatairesLa plupart des prestataires offshore réalisent une marge nette de 10 à 30 % de la sommefacturée. Sur des affaires isolées sans commission d’apport d’affaires et sur des sujetssuffisamment simples ou bien définis pour ne présenter que très peu de risques, on peutatteindre 40 % de marge, voire davantage. Il est normal et même sain que le prestataireréalise une marge suffisante.

Certains prestataires offshore travaillent à prix coûtant, voire à perte. Ils ont tellementenvie de remporter les affaires qui se présentent qu’ils calculent les coûts au plus juste.Une fois l’affaire remportée, ils rognent sur tous les postes, à commencer par le salairedes informaticiens, et les services sont réduits au minimum. Le client de l’offshore a donctout intérêt à ce que son prestataire soit satisfait de sa marge.

Le prestataire fait tout son possible pour ne pas perdre un client qui lui garantit une margeraisonnable. Il cherche à le satisfaire à tout prix, même s’il doit fournir plus de servicesque convenu. Avec une marge faible ou nulle, le prestataire n’hésite pas à réaffecter sesmeilleurs collaborateurs sur des projets où la marge est plus importante. Les pressionsdu client sont presque sans effet, car peu lui chaut de perdre un projet qui lui rapporte peu .

EN RÉSUMÉUne marge correcte est une garantie de succès

Rechercher systématiquement les prestations aux tarifs les plus bas donne rarement une producti-vité satisfaisante. Il est préférable d’offrir une marge raisonnable au prestataire en offshore afin qu’ilait un intérêt personnel à ce que son client soit satisfait.



87

Travailler avec un partenaire en offshore offre tous les avantages de l’outsourcing. Onobtient la pleine flexibilité des équipes, les meilleurs profils, la possibilité de créer leséquipes rapidement et un niveau de coût raisonnable. Si le partenariat ne convient plus,on peut en changer sans démarches complexes.

Le joint-venture en offshoreBien souvent, le choix de monter un joint-venture découle d’une volonté de garder uncontrôle fin sur les équipes et de réduire les coûts, lorsqu’on ne dispose pas d’un mana-gement suffisamment expérimenté ou d’une expérience assez solide du pays pour créerune filiale.

L’objectif est d’acquérir les compétences en management et l’expérience du pays quimanquent. Si le partenaire est lui-même un prestataire offshore, on pense qu’il mettracertaines ressources en commun, notamment pour la gestion des embauches et la sélec-tion des collaborateurs. Le partenaire et la société locale partagent leurs compétencespour prendre ensemble l’initiative de créer la nouvelle structure.

Dans certains cas, la création du joint-venture a pour objectif de démarrer en offshore uneactivité de prestataire de services animée par le partenaire local. Cet objectif, qui consisteà démarrer une société commerciale dans le pays distant, n’est pas étudié dans ce livre,qui se concentre sur les sociétés qui souhaitent avant tout réaliser leurs projets en offshore .

Les partenaires du joint-venture

Bien souvent, le joint-venture associe le client et son prestataire en offshore aprèsplusieurs années de travail en commun. Le client souhaite disposer à la fois des avan-tages du travail avec un prestataire et de ceux d’une filiale. Il désire aussi conserverl’équipe dont il dispose, qui est simplement transférée dans la nouvelle structure. Leprestataire en offshore continue d’assurer certains services centraux, tels que comptabi-lité, gestion des ressources humaines, gestion des recrutements, accès aux profils trèsexpérimentés, informatique interne, etc.

Dans ce type de montage, la marge nette du partenaire en offshore diminue. Les opéra-tions ayant toutefois plus de chances de s’inscrire dans la durée, il peut espérer que lesvolumes traités augmentent également.

Comparaison des différents partenariatsLe tableau 4.2 récapitule les éléments de comparaison entre les différents modes de fonc-tionnement des équipes en offshore.

Tableau 4.2. Comparaison des modes de fonctionnement en offshore

Critère de comparaisonProjet sur Internet

Filiale en offshore

Prestataire offshore

Joint-venture

Flexibilité des ressources Forfait - ++ -

Capacité à embaucher de bons profils

+ + ++ -/+/++



88

Les modes de gestion des équipes outsourcées

Si l’on choisit de travailler avec un prestataire offshore plutôt que de créer une filiale ouun joint-venture, on peut choisir de travailler au forfait ou en régie. Les projets confiés àune filiale ou à une société montée en joint-venture sont exclusivement assurés en régie.À l’opposé, les petits contrats signés sur Internet sont toujours au forfait. Les projetsconfiés à un prestataire offshore peuvent avoir les deux modes de fonctionnement.

Avec les projets au forfait, le client ne se préoccupe théoriquement plus de la gestion duprojet, qui est de la responsabilité unique du prestataire. À l’inverse, avec les projets enrégie, le client décide de son implication sur le projet et peut aller jusqu’à en prendrel’entière responsabilité.

Si le client est une société de services locale, il peut réaliser des développements pour lecompte de ses propres clients. Ces projets sont le plus souvent réalisés au forfait. Enrevanche, la société de services sous-traite généralement le projet en régie pour disposerd’un contrôle très fin sur les réalisations.

Il est possible d’introduire une part de forfait dans les projets en régie. La base demeurela régie, mais le prestataire s’engage à réaliser certaines parties du projet pour unesomme fixée à l’avance.

La figure 4.1 illustre les différents types de développements que l’on peut trouver entreune société locale, cliente de l’offshore, et ses clients.

Critère de comparaisonProjet sur Internet

Filiale en offshore


Joint-venture

Capacité à embaucher rapidement

+ - ++ -/+

Faible coût des prestations ++ + + +

Sécurité des informations - ++ + ++

Mode de fonctionnement Forfait Régie RégieForfaitRégie forfaitée

Régie

Possibilité de monter une équipe dédiée et isolée

- ++ + +/++

Taille des projets Très petits 20 à 40 années/homme au moins par an

Très petits à très grands projets

20 à 40 années/homme au moins par an

Capacité à arrêter les prestations

++ - ++ -

Tableau 4.2. Comparaison des modes de fonctionnement en offshore(suite)



89

Importance de la localisation du prestataireLa localisation géographique du prestataire a une importance déterminante sur le choixdu mode de fonctionnement. Si le partenaire peut être géré à distance, le décalage horairepermettant de travailler efficacement avec lui, et qu’il soit facilement accessible, on peutconsidérer sereinement le mode régie. La facilité à travailler ensemble de façon interac-tive est déterminante pour des prises de décision en temps réel, fondées sur des échangestéléphoniques et des messages instantanés.

Lorsque le prestataire est plus éloigné et que les horaires de travail ont peu de recouvre-ment, voire pas du tout, le travail en régie n’est plus efficace. Il faut lui préférer le travailau forfait, grâce auquel le prestataire est plus indépendant pour gérer le projet et prendredes décisions.

C’est là une des différences majeures entre le travail en offshore aux États-Unis et enEurope. Les pays de prédilection de l’offshore pour les Américains sont l’Inde, les Philip-pines et plus généralement l’Asie, qui n’ont pratiquement pas de recouvrement horaireavec les États-Unis. Lorsque les clients américains travaillent avec des pays plus proches,comme le Mexique ou le Canada, ils travaillent généralement en mode régie.

La figure 4.2 illustre les plages horaires de travail de quelques villes et montre les plageséventuelles de recouvrement.

Figure 4.1. Relations entre une société, ses clients et le prestataire offshore

Figure 4.2. Recouvrement des heures de travail entre les pays de l’offshore et les pays clients



90

Les livres américains traitant des développements en offshore n’envisagent pas, le plussouvent, le travail en régie. La situation est totalement différente pour l’Europe, où lespays de l’Est et le Maghreb, qui sont faciles d’accès, proposent des prix très attrayants etne sont qu’à deux ou quatre heures de vol de Paris. Il est possible d’opter pour le travailen régie avec ces pays et de bénéficier pleinement de ses avantages. Le client peut de lasorte intervenir au quotidien dans les développements, répondre aux questions aumoment où elles sont posées et se rendre sur place aussi souvent que de besoin pourrégler les problèmes au cas par cas.

EN RÉSUMÉL’offshore en Europe et aux États-Unis

Pour les États-Unis, le principal pays de l’offshore, l’Inde, a environ douze heures de décalagehoraire. Le mode de travail en régie est inefficace avec un tel éloignement. Lorsque le client est enEurope de l’Ouest, toute une série de pays d’offshore (Europe de l’Est, Maghreb, Moyen-Orient) sontà moins de quatre heures de vol de Paris et ont moins de deux heures de décalage horaire. Il peut dece fait bénéficier des avantages d’une gestion de projet en régie.

Le projet au forfaitLe mode de fonctionnement au forfait est le plus naturel lorsqu’on décide de confier unprojet de développement à un tiers. Si l’on a un projet à réaliser, on le définit aussicomplètement que possible, et on laisse les candidats proposer une réalisation au forfait.On a ainsi l’impression d’être protégé de tous les aléas du projet et d’obtenir le meilleurcoût de réalisation. Pour se protéger encore plus, on ajoute des pénalités si les livraisonsintermédiaires ou le produit final ne sont pas livrés dans les temps ou si la qualité estinsuffisante.

Si le projet est important, des problèmes ne tardent pas à surgir. Les prestataires ont faitdes propositions très basses afin d’emporter l’affaire, mais leurs prix sont si bas que leprojet n’est plus rentable dès lors que l’on découvre des imprévus, qui demandent untravail supplémentaire. La plupart du temps, certaines parties sont bien spécifiées tandisque d’autres restent assez vagues. Parfois, le client lui-même n’a pas pleinementconscience des points laissés imprécis dans les spécifications et les découvre au fur et àmesure par les questions du prestataire. Si le projet est long, il se peut de plus qu’il veuilleapporter des modifications au produit ou qu’il soit nécessaire de prendre en compte denouvelles contraintes techniques.

Le client peut refuser de négocier un ajustement du forfait initial, en considérant que lesincertitudes sont normales et qu’on les retrouve dans tous les projets au forfait, ou aucontraire préférer négocier des modifications, ce qui suppose qu’il les a prévues et qu’ildispose de la réserve budgétaire nécessaire.

Les projets qui se prêtent le mieux aux réalisations au forfait

Lorsque le projet est petit ou facile à définir dans son intégralité, il est possible de le réaliserefficacement au forfait. Si le projet est important, évolue au fil du temps ou est difficile àdéfinir et que le prestataire découvre les tâches à réaliser en cours de progression, il seprête moins à une réalisation au forfait ou nécessite des renégociations pour prendre encompte les changements et les nouvelles exigences.



91

Certains projets au forfait essaient de se protéger des modifications en cours de dévelop-pement en prévoyant un volume d’ajustements inclus dans le forfait (voir la section « La régieforfaitée », plus loin dans ce chapitre).

Les dangers des développements au forfait

Le prestataire s’engage à respecter les livraisons intermédiaires et la livraison finale selonle cahier des charges qui a été défini au moment de la signature du contrat. Il gère leprojet indépendamment de son client, en prenant lui-même les risques, et considère quetoute intervention du client est source de déstabilisation et peut générer des retards. Saplus grande crainte est de voir le client disserter sans fin en cours de projet sur les spéci-fications en ajoutant ici et là de nouvelles contraintes.

S’il le peut, le prestataire évite de faire appel au client et essaie de répondre de lui-mêmeaux zones d’ombre de son projet en choisissant la solution la moins coûteuse. Il se dit quesi le client veut que des points soient corrigés, ils pourront l’être au cours d’un autreprojet subséquent, probablement lui aussi au forfait.

En réalité, dès que le projet devient un tant soit peu important, les zones d’ombre nemanquent pas, et le travail d’ajustement des spécifications est considérable. Ces ajuste-ments peuvent être tellement importants que si le produit livré s’en tient strictement auxspécifications initiales, sans traiter les zones d’ombre, il peut être totalement inutilisable.

EN RÉSUMÉLes risques des développements au forfait

Dans les projets de taille moyenne ou importante, les imprécisions des spécifications initiales ou leschangements qui surviennent au cours du projet prennent une importance cruciale, au point que l’onne peut les ignorer sans créer un produit insatisfaisant pour les utilisateurs finals. Il faut alorsentamer des renégociations du contenu et du prix du projet ou prévoir, lorsque c’est possible, unprojet complémentaire pour traiter les manques. Les renégociations du contrat ne manquent jamaisde créer des tensions entre le prestataire et son client, tensions qui se trouvent amplifiées par ladistance et les différences culturelles.

Les négociations d’ajustement en cours de projet

L’impact des renégociations entre un prestataire offshore et son client sur un projet auforfait ne doit pas être négligé. Sur un premier projet, le prestataire et le client veulentrester dans le budget initial, au-delà même de ce qui est raisonnable. Une renégociationmène souvent à de nombreux doutes et peut aller jusqu’à la perte de confiance, voire,dans des cas extrêmes, à l’arrêt du projet.

Le client est toujours surpris par le coût des modifications que lui annonce le prestataire.Le prestataire est quant à lui toujours tenté de chiffrer les modifications avec une margeconfortable ou de rattraper d’éventuelles sous-estimations des efforts de développement.

Le manager du projet chez le client se trouve alors dans une situation fort délicate. Il n’apeut-être pas anticipé ces négociations et n’a alors aucune réserve budgétaire pour négo-cier avec le prestataire. S’il en a, elles sont généralement très faibles. Il doit remonter hautdans la hiérarchie pour tenter d’obtenir une rallonge budgétaire. Si le produit n’est passatisfaisant, il sait de surcroît qu’il sera tenu pour responsable.

Le responsable du projet chez le prestataire est dans une situation non moins inconfor-table. Il travaille avec une marge réduite, résultant d’une farouche concurrence entre les



92

prestataires au moment de l’attribution du projet, et ne peut accepter de surcharges sansrisquer de travailler à perte.

Lorsque le client durcit sa position pour ne pas renégocier le forfait, le prestataire faitsouvent de même. Il fait valoir qu’il s’en est tenu strictement aux spécifications accompa-gnant le contrat au forfait. S’il a du retard, il se peut même qu’il cherche à poser des ques-tions dilatoires au client afin de retarder la livraison. Les relations entre les partenairespeuvent dès lors se tendre à l’extrême. Fort du respect de son engagement contractuel, leprestataire s’attend à recevoir la totalité du paiement. De son côté, le client reçoit unproduit à peine utilisable quoique satisfaisant aux spécifications.

Si le prestataire a eu la chance de remporter l’affaire avec une marge importante, il peutaccepter un certain volume de modifications sans demander systématiquement une rené-gociation du forfait. Si l’ensemble des modifications peut être pris sur la marge, la relationpeut rester cordiale.

Dans presque tous les cas, la relation entre le prestataire et le client est tendue à la find’un projet important. Une fois la confiance érodée, la distance et la différence culturellese chargent d’amplifier les tensions qui surgissent immanquablement.

La transparence de la gestion de projets au forfait

Dans la majorité des cas, on n’attache pas suffisamment d’importance à la façon dont ledéveloppement au forfait est réalisé. On pense que le cadre contractuel, avec ses péna-lités en cas de défaut, suffit à contraindre le prestataire de services à réaliser le projetcomme il convient. Or certains prestataires perdent pied très rapidement, se noient dansleurs réalisations ou essaient de combler les flous fonctionnels des spécifications pareux-mêmes, s’éloignant de ce fait des attentes du client. Ce dernier ne découvre l’étenduedes problèmes que parce que la livraison n’arrive pas ou, lorsqu’elle arrive, parce qu’elleest partielle ou d’une qualité insuffisante. Il est alors bien tard pour engager des actionscorrectives.

Le client peut exiger dans le contrat définissant la réalisation au forfait que le prestatairelui offre une transparence totale sur la progression du projet. Il peut de la sorte juger deson avancement et de la qualité des instruments de suivi mis en place par le prestataire.Si le suivi est effectué au moyen d’un référentiel ou d’un outil de suivi de la gestion duchangement et des anomalies, les indicateurs sont objectifs et disponibles en continu.Le client voit alors son produit se construire jour après jour et peut réagir dès que lespremiers problèmes surgissent.

EN RÉSUMÉLa gestion de projet au forfait

Dans les projets gérés au forfait, il est essentiel de mettre en place une gestion de projet quipermette au client d’en suivre la progression de façon continue. Cette exigence est à prévoir dansl’accord contractuel.

La régieLe fonctionnement en régie est certainement le plus efficace avec une équipe en offshore,à condition que la localisation du prestataire s’y prête. Avec la régie, le client prend lecontrôle du management du projet. Le prestataire assure la mise à disposition desressources demandées dans les temps et gère la discipline locale, la sécurité et les



93

ressources humaines. Pour tout le reste, c’est le client qui manage le projet, prend lesdécisions fonctionnelles et techniques et choisit les méthodes à mettre en œuvre.

L’équipe en offshore peut être considérée comme une extension des équipes locales, avecun contrôle identique du client sur la façon dont elle fonctionne. Ce dernier peutremplacer les personnes qui ne conviennent pas, en promouvoir d’autres et suivre ledétail de la production de chacune des équipes. Les procédures appliquées sont dans leprolongement de celles utilisées localement par le client, rendant plus naturelle la relationentre les équipes distantes et locales.

Les risques de désaccords avec le prestataire sont limités, puisqu’il a peu de responsabi-lités. Le client est le seul responsable de l’échec éventuel du projet, à condition que deserreurs bloquantes ne proviennent pas directement des domaines de compétence duprestataire.

Le succès est tout de même partagé. Le prestataire assure les recrutements et prend soinque la motivation reste forte et que les collaborateurs appliquent efficacement les direc-tives du client. Il veille à éviter les départs en masse vers d’autres prestataires quioffriraient des conditions plus intéressantes et crée ou maintient un bon esprit d’équipe.

Le tableau 4.3 montre comment les responsabilités sont partagées entre le client et leprestataire.

Tableau 4.3. Partage des responsabilités entre le client et le prestataire offshore de projets en régie

Domaine de responsabilité Client Prestataire offshore

Recrutement des équipes Valide les profils. Organise le recrutement.

Réduction des équipes Choisit les personnes à retirer. Organise les réductions d’équipe.

Méthodes et procédures – Fournit la méthode à appliquer.– Forme le personnel.– Suit l’application de la méthode.

Vérifie la bonne application des directives du client.

Reporting Définit et exploite le reporting. Automatise et vérifie la véracité des informations fournies.

Sécurité des informations Définit le niveau de sécurité souhaité.

Fait appliquer les procédures de sécurité.

Gestion de projet et actions correctives

Gère le projet et les actions correctives.

Peut proposer des améliorations.

Tâches centrales (informatique interne, vacances, maladies, gestion du personnel)

Définit les exigences souhaitées. Gère les tâches centrales et la motivation en général.

Gestion des rémunérations Propose des ajustements. Gère les rémunérations, ainsi que les politiques de primes et de bonus.



94

EN RÉSUMÉTravailler en offshore en régie

Le travail en offshore en régie est le meilleur moyen de créer une relation de partenariat, de motiverl’équipe distante comme une équipe locale et d’atteindre le meilleur niveau de qualité. Le client gèrela majorité des aspects du projet et en prend la totale responsabilité.

La régie forfaitée et plafonnéeLa régie forfaitée vise à combiner les avantages de la régie et ceux du forfait. Cetteapproche est généralement retenue par le client qui souhaite faire un appel d’offres pourdisposer des meilleurs tarifs et qui sait que le forfait pur poserait d’inévitables problèmesde fonctionnement dans la durée si les spécifications devaient être incomplètes ouévoluer.

En réponse à l’appel d’offres, la meilleure proposition est retenue. Le client ajoute alorsune dose de régie afin de gérer les changements dans certaines limites définies aussiprécisément que possible.

Il peut arriver que le prestataire qui travaille déjà en régie avec une équipe en offshoreveuille isoler certaines parties du projet pour les traiter au forfait. Avec le forfait, le clientespère que le prestataire sera plus actif et les équipes plus motivées, tout en limitant sesrisques financiers.

Les retours d’expérience montrent que ce mode mixte ne fonctionne pas vraiment et quel’un des modes, régie ou forfait, finit par l’emporter. Si l’on cherche à apporter davantagede flexibilité au fonctionnement au forfait par une dose de régie, le mode forfait s’estomperapidement.

Le client qui souhaite travailler en régie peut s’inquiéter d’un poste de dépense ouvertdont il ne sait pas définir les limites. La régie plafonnée permet de s’entendre sur unplafond, le plus souvent pour chaque phase d’un projet. Ce plafond constitue une limitequi ne peut être dépassée et qui n’est pas un objectif à atteindre par ailleurs.

Choisir le bon mode de fonctionnementComme nous l’avons vu, le client de l’offshore a le choix entre trois modes de fonctionnementprincipaux.

Le tableau 4.4 compare les modes au forfait et en régie, la régie forfaitée consistant àdéplacer le poids sur l’un ou l’autre de ces modes.

Tableau 4.4. Critères de choix du mode de fonctionnement d’un projet en offshore

Type de projet Critère Régie Forfait

Petit projet Facilité à gérer le projet complètement défini + ++

Responsabilité de la gestion du projet chez le prestataire - ++

Disposer du meilleur produit en première livraison + ++

Contrôle sur le coût du projet + ++

Mise en place des méthodes du client pour la gestion du projet ++ -



95

Régie ou forfait

Il apparaît que le fonctionnement au forfait est bien adapté aux petits projets. Il permet de faire unappel d’offres et d’exiger que le prestataire s’y tienne. Il n’offre en revanche que peu de possibilitésde gérer les changements en cours de projet. La régie donne la pleine responsabilité du projet auclient. Ce mode est bien adapté aux projets importants et à une relation de partenariat dans la duréeavec le prestataire.

Conclusion

Ce chapitre a traité du mode de fonctionnement en offshore. Le choix entre régie et forfaitest une question importante, d’ailleurs constamment débattue de nos jours.

C’est en mode régie que l’on parvient à tirer le plus d’avantages de l’offshore. En contre-partie, cela exige plus d’efforts de la part du client, dont les compétences sont mises àcontribution pour organiser et suivre le travail des équipes. Le contrôle exercé sur le projetétant maximal, les managers techniques du client passent de la position de simples clientsà celle de donneurs d’ordres pouvant directement influencer les réalisations.

Type de projet Critère Régie Forfait

Petit projet(suite)

Choix du prestataire par appel d’offres - ++

Esprit de partenariat avec le prestataire ++ -

Motivation des équipes en offshore + ++

Transparence de la progression du projet et anticipation de la qualité et de la date de livraison

++ -

Grand projet Facilité à gérer le projet avec ses modifications et ses imprécisions initiales

++ -

Responsabilité de la gestion du projet chez le prestataire - ++

Disposer du meilleur produit en première livraison ++ -

Contrôle sur le coût du projet +/++ +

Mise en place des méthodes du client pour la gestion du projet ++ -

Choix du prestataire par appel d’offres + ++

Esprit de partenariat avec le prestataire ++ -

Motivation des équipes en offshore ++ +

Transparence de la progression du projet et anticipation de la qualité et de la date de livraison

++ -

Tableau 4.4. Critères de choix du mode de fonctionnement d’un projet en offshore(suite)



96

Le fait de disposer d’une grande liberté d’action, d’un contrôle fin des équipes et de coûtspar collaborateur raisonnables permet de mettre en œuvre les meilleures pratiques etde les expérimenter sur des projets réels. Il s’agit là de bien plus qu’une simple gestion deprojet. C’est une expérience personnelle, où les managers du client peuvent donner lapleine mesure de leurs capacités.

En tenant compte des retours d’expérience qui constituent la matière essentielle de cetouvrage, les managers expérimentés pourront tirer un grand plaisir de leurs accomplis-sements en offshore, dont ils ne manqueront pas de réclamer la paternité.


97

Chapitre 5

Choisir le projet à externaliser en offshore

Ce chapitre traite des différents types de projets informatiques susceptibles d’être exter-nalisés en offshore. À chaque type de projet correspondent un mode de fonctionnement,une organisation des ressources humaines et des méthodes adaptées. Tous ne conviennentpas à l’outsourcing.

Bien choisir le projet que l’on compte confier à un prestataire offshore et lui affecterl’organisation qui lui convient sont donc des conditions essentielles, surtout si l’on faitses premiers pas et que tout soit à construire.

La difficulté à réaliser un projet varie de façon parfois inattendue. On peut facilement setromper sur l’évaluation de la difficulté des projets. Si les petits projets paraissent plus facilesà réaliser que les gros, on s’aperçoit bien vite que les choses ne sont pas aussi simples.

Une part importante des causes d’échec d’un projet proviennent du client lui-même etnon du prestataire. Les facteurs qui influencent significativement le succès ou l’échecd’un projet en offshore sont en définitive assez peu nombreux. L’expérience montre quemême les éléments qui pourraient paraître évidents aux chefs de projet expérimentés seprésentent comme des pièges, dans lesquels nombre d’entre eux se laissent prendre.

Les managers doivent en conséquence porter toute l’attention qui convient au choix desprojets confiés à une équipe en offshore et aux précautions à prendre pour en garantir lesuccès.

Les éléments structurants des projets en offshore

Le prestataire en offshore s’attend légitimement à recevoir de son client les élémentsnécessaires à la réussite d’un développement, à commencer par des spécificationsexhaustives. Il s’attend également à connaître le niveau de finition ou de qualité demandéde façon à pouvoir valider les livrables et en assurer la recette par le client. Le prestatairesouhaite en outre que le client soit réactif et attentif aux besoins et difficultés expriméspar l’équipe distante.

Le succès d’un projet de développement est toujours fortement couplé à la qualité de sagestion (gestion du référentiel et du changement, processus itératif, gestion de la qualité,de la motivation, etc.).



98

Les éléments récapitulés dans les sections qui suivent permettent de définir plusieurstypes de projets et de les classer suivant la facilité à les confier à un prestataire offshore.

La documentation fonctionnelleLe premier élément pour juger de l’éligibilité d’un projet à l’outsourcing en offshore est lacapacité du client à définir totalement le contenu de l’application. Plusieurs approchessont possibles pour cela. Le client peut disposer de la complétude des spécifications,s’organiser pour les fournir au fur et à mesure de la progression du projet ou faire en sorteque celles-ci soient produites par le prestataire sur la base d’informations exhaustives.

La figure 5.1 illustre les différentes sources de spécifications que l’on peut définir pourcréer la documentation fonctionnelle du produit à développer. Ces sources ne sont biensûr pas équivalentes.

Le tableau 5.1 récapitule les différences majeures entre les sources d’informations donton peut disposer pour définir exhaustivement le produit.

Tableau 5.1. Avantages et inconvénients des sources des spécifications

Source des spécifications

Avantage Inconvénient

Spécifications complètes fournies par le client dès le début du projet

Le client prend la pleine responsabilité du produit souhaité.

Le client voudra certainement revenir sur les spécifications pour les améliorer ou prendre en compte des aspects oubliés. La stabilité est rarement assurée.

Figure 5.1. Formalisation des spécifications


Chapitre 5 – Choisir le projet à externaliser en offshore

99

On doit être capable de fournir à l’équipe en offshore une documentation aussi complèteque possible afin de lui permettre de travailler efficacement. Pour atteindre un niveaude qualité des spécifications suffisant, il est nécessaire d’analyser ces dernières afin dedétecter incohérences, imprécisions et aspects oubliés. Si le produit est nouveau, lepremier jet des spécifications sera certainement très éloigné des spécifications complètesfinales. Dans tous les cas, le travail de finalisation est important.

Le reverse-engineering présente un avantage important puisqu’on dispose d’un produitfonctionnellement complet que l’on peut analyser en profondeur en cas de besoin. Lesajouts et modifications fonctionnels sont plus aisés à réaliser puisqu’on s’appuie sur unédifice complet et cohérent.

Discipline très complexe, la formalisation des spécifications est le sujet de très nombreuxouvrages. Une tendance récente, considérée comme la plus efficace, de description des

Source des spécifications

Avantage Inconvénient

Spécifications fournies par morceaux par le client au cours du projet

– Le client prend la pleine responsabi-lité de la définition du produit.– Il peut prendre plus de temps pour s’assurer de la bonne définition du produit souhaité.

– Les spécifications ne sont pas stables.– Les fonctionnalités nouvellement définies peuvent influencer celles qui sont déjà fournies.– Le travail de définition de l’architec-ture globale ne peut être réalisé sur des spécifications partielles, rendant la définition des composants réutilisables plus aléatoires.

Manuel utilisateur détaillé Le document provenant d’une appli-cation existante est immédiatement disponible.

La définition fonctionnelle du produit est d’un niveau élevé, qui ne suffit pas à définir tous les comportements du produit. C’est une source d’informa-tion qui doit être fortement complétée par le client.

Définition visuelle des fonctionnalités (maquettage)

Le client peut valider ses spécifications auprès d’utilisateurs.

La définition par maquettage ne suffit pas à définir tous les comportements du produit. Le client doit fournir de nombreuses informations complé-mentaires.

Reverse-engineering d’une application existante

– Le client peut se concentrer sur la validation fonctionnelle et les nouvelles fonctionnalités.– Les spécifications ont le formalisme souhaité par l’équipe en offshore.– L’équipe distante travaille sur l’élaboration des spécifications et acquiert une réelle compétence métier.

– Le prestataire peut avoir du mal à spécifier les nouvelles fonctionnalités de façon cohérente avec l’architecture du produit existant.– Si le produit souhaité représente une évolution fonctionnelle importante, il se peut que le reverse-engineering soit une étape inutilement lourde.

Tableau 5.1. Avantages et inconvénients des sources des spécifications(suite)



100

fonctionnalités consiste à les exprimer sous forme de cas d’utilisation (use cases). Ceux-cidécrivent les fonctionnalités selon les actions que réalisent les utilisateurs avec leur voca-bulaire habituel. Cette description linéaire est aisée à lire et à comprendre. L’aspect visuelest séparé de l’aspect fonctionnel, permettant ainsi de traiter les sujets relatifs à l’inter-face utilisateur séparément.

Des méthodologies telles que RUP (Rational Unified Process) et XP (eXtreme Program-ming) mettent en avant ces principes de spécification. Les cas d’utilisation sontcomplétés par des spécifications supplémentaires, qui décrivent une fois pour toutes leséléments fonctionnels réutilisables. Les exigences (requirements) incluent parfois, en plusdes aspects fonctionnels, des contraintes techniques, comme certaines technologies àemployer, une bibliothèque à réutiliser ou des objectifs de performance à atteindre.

Cette approche, de même que tous les autres moyens de décrire exhaustivement le sfonctionnalités d’un produit, exige un travail minutieux et complet.

EN RÉSUMÉDes spécifications formalisées et complètes

Quel que soit le mode que le client de l’offshore choisit pour exprimer les fonctionnalités du projet àréaliser, l’équipe en offshore doit retravailler ces informations pour obtenir une représentationexhaustive et structurée du produit à réaliser. Le plus souvent, l’équipe en offshore essaiera d’utiliserune formalisation des spécifications sous la forme de cas d’utilisation selon une approche de typeRUP ou XP.

Avec l’offshore, les spécifications prennent une importance prépondérante. La communica-tion sur l’objectif fonctionnel du projet doit être parfaitement formalisée, ne serait-ce queparce que les échanges de questions-réponses sont fortement consommateurs de temps.

Si l’on décide de travailler au forfait, les spécifications représentent le document essentielsur la base duquel le prestataire s’engage à livrer le produit attendu. C’est aussi à partird’elles qu’il peut estimer la charge de travail, les risques encourus par la réalisation duproduit et, au finale, le coût du forfait. Toute modification des spécifications en cours deprojet peut avoir d’importantes répercussions, car on devra renégocier non seulement letravail supplémentaire nécessité par les nouvelles fonctions, mais aussi le travail déjàréalisé, devenu inutile du fait des changements.

Le client oublie souvent que le travail déjà réalisé peut être en partie inutilisable. Il atoujours l’impression que le prestataire présente exagérément un travail comme perdu etque ce dernier en profite parfois pour rattraper financièrement d’autres tâches qu’il asous-estimées. Le prestataire a en fait toujours du mal à estimer ses charges, et il chercheà maximiser les charges, ne serait-ce que pour ne pas devoir renégocier les modificationsmineures à venir, qui sont ainsi couvertes par une marge élevée sur les modificationsimportantes.

Quel que soit le mode de développement, régie ou forfait, le prestataire et le client se réfè-rent en permanence aux spécifications, qui restent présentes sur les bureaux de tous lesinformaticiens, développeurs et testeurs. Toute modification apportée aux objectifs fonc-tionnels est immédiatement mise à jour dans les use cases. Ces derniers constituent de lasorte un des ensembles de documents les plus structurants du projet.

La façon d’établir les spécifications du produit mais aussi leur qualité, leur stabilité et leurexhaustivité conditionnent pour une grande part l’organisation du projet en offshore etpar là même ses chances de succès.



101

Indépendance du projet à l’égard des influences externesIl n’est pas rare qu’un client local confie à une équipe en offshore une partie d’un projet,par exemple un module d’une application plus vaste, l’équipe locale conservant la main-mise sur les parties principales du projet et sur le cœur technique de l’application. Dansd’autres cas, le client, qui travaille sur des réalisations importantes, répartit les dévelop-pements chez plusieurs prestataires et en conserve une partie chez lui.

Dans tous ces cas, la dépendance du projet traité en offshore à l’égard des réalisationslocales ou de celles confiées à d’autres prestataires en offshore accroît la complexité degestion et de distribution du projet.

Les développements multisites sont particulièrement délicats. Pour les réussir, il fautparvenir à définir une architecture du produit qui structure des composants techniques etfonctionnels dont on connaît toutes les interdépendances. Les composants peuvent alorsêtre éventuellement confiés à des équipes différentes, à condition d’essayer de limiter lesdépendances.

Les développements réellement indépendants sont toutefois rares lorsque les équipessont distribuées. Les couches techniques forment un lien de dépendance important entretous les composants, tout particulièrement la gestion de l’accès aux données et la struc-turation de la base. Si des modifications sont apportées aux spécifications, il faut que lesarchitectes globaux puissent en étudier l’impact et repèrent éventuellement les modifica-tions des design patterns correspondants.

Lorsqu’un projet est réalisé à la fois chez le client et chez un prestataire en offshore, ilarrive bien souvent que les parties les moins importantes, les moins intéressantes ou lesplus fastidieuses soient confiées à l’offshore. Les équipes locales gardent pour elles lesparties les plus motivantes et les plus critiques. De ce fait, les parties confiées à l’offshorerisquent de ne faire l’objet que d’un suivi distrait du gestionnaire de projet, ce qui rend lacollaboration plus complexe. Les questions restent longtemps sans réponses, ou bien cesdernières n’ont pas la précision attendue. Ce n’est généralement qu’au moment des inté-grations que les manques de communication apparaissent au grand jour.

La synchronisation entre les référentiels de plusieurs sites apporte une complexitésupplémentaire. Il est, par exemple, pratiquement impossible d’éviter les problèmes decoordination des builds entre les équipes. Les interdépendances, même légères, sontdifficiles à résoudre et ralentissent la stabilisation du développement.

Même lorsqu’elles paraissent faibles, les dépendances existent toujours à partir dumoment où le projet est éclaté sur plusieurs sites et portent leur lot de difficultés. L’utili-sation d’un référentiel bien géré, accompagné des workflow gérant la circulation deséléments et imposant des processus permet cependant de lisser certains problèmes.

EN RÉSUMÉLes projets distribués et l’offshore

Les projets dont les livrables sont créés de façon distribuée sont beaucoup plus complexes à géreret demandent une expertise approfondie de la gestion de projet en offshore et du bon usage d’unréférentiel comme moyen de synchronisation des processus.

Les développements distribués doivent donc être évités dans la mesure du possible. Si l’on souhaitemalgré tout répartir les développements, il convient de porter toute l’attention nécessaire à l’équipedistante en répondant à ses questions et en assurant une communication aussi fluide que possible.



102

C’est d’autant plus nécessaire lorsque les tâches qui lui sont confiées sont d’une importanceinférieure à celles réalisées localement, car cela conduit par une pente naturelle à des négli-gences.

Compréhension fonctionnelleCertains sujets fonctionnels sont faciles à comprendre, tandis que d’autres demandentune formation importante. Les spécifications n’étant jamais vraiment exhaustives, unimportant suivi fonctionnel des développements est nécessaire pour détecter au plus tôtles erreurs fonctionnelles.

Si l’on parle d’un produit de facturation, d’e-commerce ou de gestion de stocks, on peutconcevoir que les architectes et les informaticiens comprennent le contenu des spécifica-tions de façon univoque. Ils sont capables de rectifier d’eux-mêmes les imprécisions,voire de détecter certaines incohérences.

En revanche, si l’on travaille sur un sujet qui s’accompagne d’un lourd jargon, de règlesmétier complexes ou de domaines inconnus des architectes, les spécifications doiventêtre impeccables. Les imprécisions dans le texte ne sont que rarement corrigées parl’équipe offshore, qui peut même ne pas se rendre compte des ambiguïtés des documents.De plus, si la documentation initiale en français est traduite en anglais, des erreurspeuvent apparaître. Un glossaire est alors essentiel.

On a tout intérêt à former certains collaborateurs en offshore au domaine métier pour leurdonner les meilleures chances de comprendre les spécifications détaillées. Ces formationsne doivent pas être sous-estimées, car elles peuvent changer le cours d’un projet.

Un projet dans un domaine fonctionnel complexe dont les spécifications ont été rédigéespar des experts du métier a toutes les chances d’être mal compris. Il faut donner beau-coup de confiance aux équipes en offshore pour qu’elles osent poser les questions sur lessujets qui les bloquent ou dont elles ne sont pas sûres. Il ne faut surtout pas que ces ques-tions soient prises pour un aveu de faiblesse ou que les collaborateurs distants, percevantl’agacement du client, essayent de deviner par eux-mêmes l’intention des spécificationssans consulter les responsables fonctionnels. Avec le temps et des échanges réguliers etconstructifs, ils apprendront le vocabulaire du métier et seront plus efficaces.

EN RÉSUMÉLes domaines fonctionnels complexes

Lorsque le projet traite d’un sujet fonctionnel complexe et utilise un jargon obscur, le projet est plusdifficile à maîtriser. Les erreurs de compréhension non détectées peuvent se multiplier en offshore.

Si l’on traite de sujets fonctionnels complexes, des formations sur le métier sont nécessaires. Il estde surcroît essentiel de donner confiance aux équipes afin qu’elles osent poser toutes les questionsqui leur sont utiles.

La complexité techniqueContrairement à ce que l’on pourrait penser au premier abord, la complexité techniqued’un projet n’a pas beaucoup d’impact sur la difficulté à le gérer et sur ses chances desuccès. Bien sûr, plus un projet est complexe techniquement ; plus il est difficile. Mais sila résolution technique est confiée à l’offshore et que le projet ne soit pas synchroniséentre deux sites, il ne devrait pas engendrer trop d’effets négatifs.



103

Lorsqu’on doit s’appuyer sur des briques logicielles importantes, comme un ERP (Enter-prise Resource Planning), un logiciel de facturation ou des modules existant par ailleurschez le client et qui sont stables durant le projet, on peut créer une équipe performanteen formant le personnel sur ces sujets en offshore (ils peuvent même obtenir une certi-fication de développeur, si elle existe). Loin d’être bloquants, ces sujets peuvent êtresources de motivation.

Le plus souvent, le client demande au prestataire offshore de faire ses recommandations,qui sont ensuite validées par des maquettes. Le prestataire offshore aime généralementles challenges techniques et se montre heureux de faire des propositions parmi lesquellesle client pourra choisir. Il faut bien sûr lever ces incertitudes techniques au plus tôtdans le projet.

Si l’on exige que la complexité technique d’un projet soit exclusivement résolue chez leclient, le sujet devient plus délicat, surtout si le client est moins compétent que l’équipeen offshore sur les technologies concernées. Si l’équipe distante présente des solutionssupérieures acceptables par le client, il est très motivant pour elle de voir sa solutionacceptée. À l’inverse, travailler sur une base technique considérée à juste titre commemauvaise est une source de démotivation à long terme.

Validation par le clientLa capacité à définir la façon dont on va valider les livrables est un atout considérable, quidonne de grandes chances de succès au projet confié à l’offshore. Le prestataire peut dèslors réaliser les tests que le client exécutera lui-même pour recetter les livrables.

Cela demande toutefois une bonne formalisation de la part du client. Ce dernier peut biensûr étendre ses tests de recette une fois le premier lot vérifié pour tester ce que personnen’a encore testé. Cette phase initiale permet de stabiliser les premiers livrables, d’encomprendre le niveau de finition et de limiter les échanges entre le client et le prestataireavant d’obtenir une version satisfaisante.

Ces tests ne sont toutefois pas faciles à définir, car ils nécessitent une base de donnéesreprésentative de tous les cas à traiter. Lorsqu’on travaille à la modernisation d’une appli-cation, on peut parfois récupérer la base existante pour les premiers tests en construisantun outil permettant de la convertir de l’ancien modèle au nouveau. Dans les autres cas, la basedoit être construite à la main. Elle est alors le plus souvent petite et a peu de chance d’êtreaussi efficace. Tous les projets ne permettent donc pas à l’équipe distante de recetter leproduit facilement.

Lorsqu’il n’est pas possible de réaliser des tests efficacement en offshore, il arrive que lesproblèmes ne soient détectés chez le client que longtemps après la fin des réalisations.Le prestataire met généralement beaucoup de temps à comprendre la stratégie de test deson client et à adapter le produit livré à la qualité attendue.

EN RÉSUMÉLa recette chez le prestataire

Lorsqu’on peut communiquer un jeu de tests de recette complet au prestataire en offshore accom-pagné d’une base de données convenable, on limite fortement les échanges qui ont habituellementlieu au moment des premières livraisons. La qualité livrée est immédiatement supérieure, et l’onparvient rapidement à une bonne efficacité dans les échanges ainsi qu’à une meilleure productivitédes réalisations en offshore. La gestion du projet chez le client s’en trouve de surcroît allégée.



104

Le premier projet

Le premier projet que l’on mène avec une équipe en offshore est déterminant pour lacollaboration future. Le client souhaite souvent commencer par un petit projet test. Sonobjectif est de ne s’engager que sur des montants relativement faibles et de mettre àl’épreuve l’équipe en offshore qu’il ne connaît pas.

Il arrive que des sociétés se lancent directement sur de grands projets complexes et avecdes équipes importantes. Elles ont monté l’équipe et sélectionné le prestataire avec soin.Elles se disent qu’un petit projet de test où l’on travaillerait avec des méthodes diffé-rentes ne prouverait pas grand-chose et ne ferait que retarder les autres réalisations.

Dans tous les cas, le premier projet est un projet de rodage, qui permet à la collaborationde se mettre en place et où l’on apprend à se connaître. On cherche surtout à comprendrela nature et les habitudes de la société avec laquelle on travaille. On découvre commentcommuniquer et gérer les problèmes et les personnalités.

Un petit projet de testLorsqu’on choisit de réaliser un petit projet de test avec son partenaire, on souhaite avanttout tester son futur partenaire. On démarre le projet en mode forfait, avec une équipe etune date de livraison définies.

Pour ne pas risquer d’être la cause de l’échec éventuel du test, le client choisit un projetaux spécifications simples ou faciles à définir. Le budget est limité, au cas où les chosestourneraient mal. La plupart du temps, le client a l’intention d’engager par la suite desprojets plus importants pour lesquels il souhaitera appliquer des procédures strictes, enmode régie.

Du point de vue du prestataire, il faut avant tout livrer le produit dans les temps.Qu’importe s’il doit faire intervenir ses meilleurs techniciens et développeurs en plus del’équipe que le client a choisie ou s’il doit faire travailler le double de personnes. Le projetdoit aboutir, et il fera tout pour qu’il soit un succès.

Sur un petit projet, et surtout sur le premier projet test, on ne s’embarrasse pas deméthodes. On met rarement en place un référentiel et pratiquement jamais sur unpremier projet de test. Les méthodologies, même les plus élémentaires, ne sont pas vrai-ment appliquées. Le projet ne représentant guère plus de quelques mois/homme, laméthode n’est pas d’une importance déterminante.

Même si le projet aboutit le plus souvent, qu’en déduire de part et d’autre ? Le client peutestimer qu’il a trouvé une équipe capable et motivée. En réalité, le fonctionnement auforfait a masqué au client le déroulement du projet, dont il ne sait presque rien. Il ne peuttirer aucune conclusion sur la capacité du prestataire à gérer une méthodologie ou mêmele changement puisque le projet est resté figé durant sa réalisation. Tout au plus, peut-iltirer un enseignement sur les qualités humaines de l’équipe et du prestataire en général.En tout état de cause, il n’a guère plus d’éléments nouveaux pour juger de son aptitude àgérer des projets importants ni à appliquer correctement des méthodes.

De son côté, le prestataire n’a pas non plus appris grand-chose. La satisfaction du clientlui donne l’impression que l’affaire est gagnée, mais il ne sait rien de la compétence de ce



105

dernier pour piloter des projets de grande ampleur. Il ignore tout des qualités humaineset professionnelles des managers qu’il a côtoyés.

EN RÉSUMÉPetit projet de test

Un petit projet de test bien défini n’apporte que peu d’informations sur la capacité du prestataire oudu client à gérer de grands projets en offshore. Il ne renseigne en rien sur les capacités de commu-nication, organisationnelles ou méthodologiques des uns et des autres.

Un module périphériqueIl n’est pas rare qu’un client teste son prestataire en offshore en lui confiant une réali-sation réduite peu engageante sous la forme d’un module d’une application plusimportante développée localement.

Pour les équipes locales, le développement de ce module ne poserait aucun problème etpourrait être réalisé en quelques semaines ou mois. Le client est ainsi en droit de penserque si l’offshore ne fonctionne pas correctement, il pourra toujours se rabattre sur undéveloppement local. De plus, il pourra comparer la productivité en offshore avec laproductivité locale, puisque le projet est chiffré en interne.

Contrairement au petit projet de test décrit précédemment, ce projet a peu de chances deréussir. Toutes les conditions de l’échec sont en effet réunies : le projet n’est pas claire-ment défini ; il dépend d’éléments techniques bien connus des informaticiens d u clientmais pas des équipes en offshore ; les modules centraux évoluent avec les dévelop-pements.

La seule chance d’aboutir pour le prestataire consiste à appliquer coûte que coûte desprocédures assez strictes, notamment sur la définition du produit à créer et sur les inter-faces avec les modules développés chez le client. S’il peut isoler son projet des autresréalisations, il aura éliminé les incertitudes sur ce qu’il doit effectivement réaliser. Il devraprendre l’initiative de créer des spécifications exhaustives qui lui serviront de référence.Il se peut que le prestataire doive pour cela envoyer une personne chez le client afind’assurer la réalisation des spécifications en interaction directe avec le chef de projet.

Côté client, on compare à l’issue du projet les temps de développement constatés enoffshore avec ceux en local, et l’on obtient, comme il se doit, des écarts d’un facteur 3,voire 5. Les développeurs en déduisent qu’il n’est pas intéressant de travailler avec l’offshor e,que les coûts sont plus élevés, que les efforts de management sont énormes et que l’onn’arrive pas à communiquer efficacement. Au finale, les conclusions sont si négativesqu’elles peuvent conduire à décider de cesser de travailler avec l’offshore, à la plus grandejoie des informaticiens locaux. Non seulement ils ont éliminé un danger, mais ils sesentent confortés dans l’idée qu’ils sont irremplaçables, extrêmement productifs et qu’ilsparticipent directement à la valeur de la société.

Ces conclusions sont forcément erronées puisque c’est la nature même du projet qui estla cause de l’échec : on n’a pratiquement aucune information sur le prestataire en off-shore ; on ne peut juger ni de la productivité des équipes, ni de la qualité des méthodeset du management ; le plus souvent, on a appliqué la moitié des procédures, celles quiconcernent l’équipe offshore, sans traiter la partie censée échoir au client.



106

EN RÉSUMÉModule test d’un programmeConfier, en premier projet, la réalisation d’un module d’une application à une équipe offshore offrepeu de chances de succès. Toutes les conditions sont en fait réunies pour échouer. Même si leprojet aboutit, la productivité sera si pauvre que le client en conclura qu’il n’est pas intéressant detravailler en offshore. Ces projets ne peuvent réussir que s’ils sont traités avec la même attentionqu’un projet majeur.

Un projet ambitieux comme premier projetIl arrive qu’une société commence immédiatement par un projet d’une certaine ampleur,représentant plusieurs années/homme. Son souhait est d’avoir un test en grandeur réelle,avec un projet géré comme le seraient les projets futurs.

Le client comprend qu’il prend un risque. Il se fait accompagner dans ce premier projetpour s’assurer qu’il se donne les meilleures chances de succès et choisit avec soin sonprestataire offshore et son équipe. Il prend garde de ne pas se trouver dans une des situa-tions les plus porteuses d’échec, même si le projet peut dépendre d’autres développe-ments locaux. En un tel cas, il traite avec une extrême attention les points de dépendanceet la communication.

Pour gérer le projet, le client met immédiatement en place tous les éléments qu’il jugeutiles. Il met notamment en place des processus réfléchis, avec livrables précis, référentiel,gestion du changement et processus itératif.

La figure 5.2 illustre les phases d’un tel projet.

Figure 5.2. Évolution de la satisfaction du client sur un premier projet ambitieux



107

Lorsque les premiers livrables sont reçus, on s’aperçoit de la distance qui sépare ce quele client souhaite de ce que le prestataire a construit, et toutes les causes menant à cettesituation semblent insolubles. Une longue phase d’ajustement peut être nécessaire pourcorriger les dysfonctionnements. Certains n’y parviennent jamais, et la satisfaction duclient continue de décroître jusqu’à ce que le projet soit abandonné.

Dans la plupart des cas, le client et le prestataire travaillent ensemble pour corriger lesdysfonctionnements. L’expérience acquise sur ce type de projet permet de rétablir lasituation plus rapidement et de stabiliser le projet avec un niveau de satisfaction plusélevé. Lorsque le client a pu fournir des informations précises sur la recette du projet, onparvient généralement à limiter les effets désastreux des premières livraisons.

Un tel projet apporte de riches enseignements sur le prestataire et permet de mener uneanalyse précise du projet pour en tirer des conclusions sur les développements en offshore.

EN RÉSUMÉVrai projet de testAvec un projet test important confié à l’offshore, on observe pratiquement toujours la même évolu-tion de la satisfaction du client. Au début, il est content, voire euphorique. La première livraison leramène douloureusement sur terre. Comme les dysfonctionnements rencontrés pour obtenir unrégime stable de travail peuvent être corrigés plus ou moins rapidement selon l’expérience, la satis-faction revient.

Typologie des projets pour l’offshore

Suivant son type, un projet peut être plus ou moins difficile à outsourcer. La typologie desprojets s’appuie sur des critères tels que la qualité et la stabilité de la documentation,l’indépendance à l’égard des autres projets, la complexité fonctionnelle ou la facilité à lerecetter.

On distingue plusieurs types de projets :

• Les projets de reverse-engineering, qui permettent de cadrer les attentes du client etsont particulièrement favorables aux réalisations en offshore.

• Les grands projets, en supposant qu’ils puissent être correctement spécifi és, qui permet-tent de mettre en œuvre une méthodologie et de bien contrôler les réalisations en offshore.

• Les réalisations, qui viennent compléter des développements locaux. Ce sont desprojets plus difficiles à réaliser, car ils interagissent avec un projet externe.

• Les petits projets, auxquels il est difficile d’appliquer une méthodologie stricte, car ellese révélerait trop coûteuse par rapport aux réalisations du projet.

• Les projets purement techniques, qui servent de socle technique à des développe-ments fonctionnels qui restent chez le client.

Projet de reverse-engineeringLes projets de reverse-engineering sont particulièrement favorables à l’offshore. Leurparticularité est de confier à une équipe en offshore le développement d’une applicationexistante, dont on estime les fonctionnalités satisfaisantes, afin de la moderniser ou del’enrichir.



108

Bien souvent, le client ne dispose pas d’une documentation formalisée sur le produit àdévelopper, les fonctionnalités étant disponibles dans le produit lui-même. Dans certainscas, le code source n’est pas entièrement disponible ou est plus ancien que la version enproduction.

On peut confier à l’équipe offshore l’analyse du produit (exécutable et code source) afinde créer des cas d’utilisation à partir de l’existant. De cette façon, les collaborateursdistants apprennent le domaine fonctionnel et créent des spécifications qui ont le niveaude détail et la formalisation souhaités. Le responsable fonctionnel peut alors ajouter cequ’il souhaite aux spécifications pour prendre en compte des évolutions ou des fonction-nalités nouvelles ou tout simplement pour corriger le travail des équipes distantes.

Les spécifications sont stables et complètes puisque le produit d’origine fournit toutesles informations nécessaires et permet de trouver des réponses aux questions oubliéesdans les spécifications.

L’écriture de spécifications à partir d’un produit existant n’est pas pour autant chosefacile. Le vocabulaire, ou glossaire, doit être défini, de même que la philosophie du produit,les règles, notamment de validation, les calculs et les valeurs par défaut lorsqu’elles sontcontextuelles. L’équipe offshore peut définir tout cela d’après le code source, s’il estdisponible, faute de quoi un expert fonctionnel doit s’en charger. L’aide d’un expertfonctionnel est indispensable chez le client pour couvrir ces domaines.

Lorsque le projet est peu important, il est très important de ne pas sauter la phase decréation des spécifications, qui permet de s’accorder. Sans spécifications complètes avanttout développement, le risque d’échec est important. La complétude des spécificationspermet en outre de définir l’architecture du produit à réaliser. Si l’on ne dispose de spéci-fications que dans le cours du projet, chaque livraison peut remettre en cause l’architec-ture fonctionnelle.

EN RÉSUMÉLes projets de reverse-engineering

Les projets de reverse-engineering sont parmi les plus efficaces à confier en offshore. Les spécifica-tions, fournies par le produit à réécrire et son code source, sont stables par essence, et presquetoutes les questions fonctionnelles trouvent des réponses dans l’analyse du produit existant.Les résultats sont le plus souvent très satisfaisants.

Grand projet correctement spécifiéUn projet bien spécifié permet d’utiliser la pleine puissance des méthodes et de l’off-shore, surtout pour un projet de grande taille. Sur un petit projet, on a du mal à pleine-ment utiliser les procédures. Le surcoût qu’elles induisent est en effet difficile à justifier,d’autant que les collaborateurs, moins nombreux, parviennent généralement à saisirl’intégralité du projet.

Les procédures et la méthodologie sont incontournables pour assurer la gestion desprojets importants. On doit synchroniser le travail de plusieurs équipes, revoir le contenufonctionnel ou l’améliorer durant le développement, et il n’est pas impossible quecertains changements majeurs, techniques ou fonctionnels, soient à prendre en compte.

Si le grand projet s’appuie sur une méthodologie industrielle, la formalisation des spéci-fications est difficile à finaliser du fait de l’étendue de ce qui doit être spécifié et de ladurée du projet, qui suppose que des événements viendront perturber le contenu ou



109

certains choix. La méthodologie permet le plus souvent de stabiliser les spécifications parmorceaux, en permettant ainsi au client de lisser les efforts des responsables fonctionnels.

La mise en place d’une méthodologie apporte un confort important. Le projet disposenon seulement de processus bien définis et de livrables formalisés, mais encore d’unesérie d’indicateurs, qui permettent de suivre la progression et les difficultés rencontrées.

EN RÉSUMÉLes grands projets

Les grands projets permettent de mettre en œuvre des approches méthodologiques industrielles etde former les informaticiens sur les aspects fonctionnels et sur la méthode. La stricte application desprocédures apporte un grand confort dans la gestion de projet et augmente significativement leschances de succès.

Projet lié à des développements chez le clientUn tel projet est toujours délicat à mener, comme nous l’avons vu précédemment dans cechapitre. Tout au long du projet, les développements des différentes équipes doivent sesynchroniser.

Les procédures, qui tiennent ici une place clé, n’ont pas toujours la rigueur nécessaire auxdéveloppements en offshore. Comme elles fonctionnent correctement pour les besoinslocaux, le client ne perçoit pas le besoin de les améliorer. Pour l’offshore, ces procéduresse révèlent incomplètes et floues, notamment quant à la gestion du référentiel et deschangements.

Comme expliqué précédemment, la partie du projet réalisée chez le client progresse, etpersonne ne se soucie vraiment du prestataire offshore, auquel une faible priorité estattribuée.

Ce type de projet, qu’il soit le premier ou non, mène généralement à l’échec. Sur un projetimportant, la part confiée à l’offshore atteint rarement plus de 30 % des efforts de déve-loppement du projet global. Si l’économie de coûts de l’offshore est de 40 %, l’économieréelle générée pour le projet global ne dépasse guère 12 % et peut être légitimementconsidérée comme trop faible en comparaison des efforts à fournir.

EN RÉSUMÉLes projets distribués entre le client et l’offshore

Un projet distribué doit appliquer la méthodologie utilisée par le client, qui est souvent moinsexigeante pour les besoins locaux que pour les réalisations en offshore. La communication est diffi-cile à assurer avec les équipes distantes, et si les tâches confiées à l’offshore sont d’une importancemoindre que celles traitées en local, le projet offshore peut être marginalisé et mener à l’échec.

Petit projetSur un très petit projet, il est naturel d’éviter de mettre en œuvre des procédures lourdes,sauf s’il s’agit d’un projet critique, auquel on souhaite appliquer une gestion stricte.

Comme l’illustre la figure 5.3, les coûts de mise en œuvre des procédures sont élevés surun petit projet en comparaison des efforts à fournir pour réaliser un petit projet.

Les petits projets ne peuvent s’appuyer efficacement sur une méthodologie et sont doncfortement dépendants de la qualité et du travail des chefs de projet en offshore et chez leclient.



110

La figure 5.4 illustre l’importance de certains rôles clés. Lorsque plusieurs chefs de projetdoivent synchroniser leurs travaux, la méthodologie devient rapidement incontournable.

Dans un petit projet, tout au plus met-on en place une gestion de référentiel et du chan-gement. Pour les projets assez stables, on se satisfait d’un répertoire partagé pour distri-buer l’information. On ne maintient pas la notion de version ni de baseline, qui lie leslivrables d’une version. Le changement est géré par des échanges d’e-mails, des tableauxsous Excel se chargeant de maintenir les informations sur les modifications et les anomaliesqui doivent être traitées.

La simplicité de ce type de projet permet au chef de projet en offshore d’en saisir la tota-lité. Si le travail est tout de même réalisé en couches, en séparant couches techniques etfonctionnelles, ce sont souvent les mêmes personnes qui travaillent sur ces différentsdomaines.

Le chef de projet du client a peu d’éléments pour suivre le projet. Il fait confiance au chefde projet en offshore et attend les livraisons pour juger du travail accompli. La gestion despetits projets est beaucoup plus difficile à assurer que celle des grands, nécessairementbien organisés et aux procédures strictement appliquées. Le résultat du projet repose surles qualités des chefs de projets et leur capacité à communiquer efficacement.

EN RÉSUMÉLes petits projets en offshore

Les petits projets sont souvent plus difficiles à manager que les grands. Faute du temps nécessairepour mettre en place des méthodes et procédures rigoureuses, on ne peut s’appuyer que sur lesqualités personnelles des managers. Tout imprévu se traduit en un retard.

Figure 5.3. Efforts comparés de gestion des procédures et de réalisation d’un petit projet



111

Projet de fondations techniquesCertains clients confient aux équipes en offshore des projets exclusivement techniques,comme les fondations techniques d’une application. Les développements fonctionnelssont réalisés ailleurs en s’appuyant sur ce socle technique. Les fondations sont version-nées et gérées comme un produit du marché, dont on contrôle toutes les évolutions etqui est parfaitement adapté aux attentes des développeurs fonctionnels.

Ces projets offrent l’avantage d’être assez faciles à spécifier entièrement. Les spécifica-tions sont relativement stables, et les ajouts sont des services complémentaires égale-ment faciles à exprimer. Les équipes en offshore comprennent parfaitement lesspécifications qui ne sont que techniques. La livraison est toujours accompagnée d’unedocumentation complète à destination des programmeurs.

Ce type de projet demande beaucoup de rigueur pour garantir un service prenant encompte les anciennes versions des couches techniques (pas de dépréciation des fonction-nalités d’une version à une autre plus récente).

Il est possible de modifier les couches techniques sans toucher aux évolutions fonction-nelles. Par exemple, sur un produit fonctionnellement figé, on peut améliorer les perfor-mances de certains services d’accès aux données et ajouter des traces ou d’autresaméliorations sans toucher au code fonctionnel. Les développeurs doivent simplementêtre rigoureux dans les tests de fonctionnement de ces couches techniques. Des tests deperformance et de charge peuvent être assurés de façon routinière.

Impo

rtan

ce d

u rô

le

Figure 5.4. Importance respective des différents rôles clés



112

Ce type de projet est lié aux développements chez le client mais n’en dépend pas. Il esten cela très différent d’un développement modulaire, où le développeur appuie sontravail sur des directives en perpétuel mouvement et où les spécifications sont incom-plètes. Au contraire, ce projet peut être totalement isolé des autres développements, cequi apporte une forte sérénité dans sa réalisation. La plupart des questions qui surgissenttrouvent leurs réponses au sein de l’équipe distante.

Ces projets permettent une pleine utilisation de l’offshore en explorant plusieurs optionstechniques afin de retenir la meilleure. Sans offshore, on ne consentirait pas à investirdans des explorations techniques, et l’on choisirait la solution qui semble la meilleure oula moins risquée sans réellement expérimenter les autres possibilités.

Le domaine fonctionnel est pratiquement inexistant dans ce genre de projet, même si lesspécifications techniques découlent évidemment de besoins fonctionnels ou de consi-dérations sur l’utilisabilité du produit à réaliser. Les développeurs des fondationstechniques peuvent ne pas connaître le domaine fonctionnel dans lequel leurs dévelop-pements seront utilisés. Il est de plus possible que de mêmes fondations techniquessoient utilisées dans des domaines fonctionnels différents. Le domaine technique estbien souvent un sujet sur lequel les développeurs en offshore sont tout particulièrementcompétents.

EN RÉSUMÉLes projets de fondations techniquesFaciles à spécifier, stables et naturellement isolés, les développements de fondations techniques oude bibliothèques mathématiques sont des candidats idéaux aux développements en offshore.

Tour d’horizon des types de projetsLe tableau 5.1 donne une vue d’ensemble des projets que l’on peut confier à l’offshore etdes critères qui permettent de comparer les efforts à fournir.

Tableau 5.1. Types de projets offshore et efforts à fournir

Type de projetFacilité

à le manager

Formation fonctionnelle

Pertinence comme premier projet

Importance des

procédures

Emploi d’outils (référentiel,

changement)

Chance de

succès

Petit projet indépendant

++ + - -/+ ++

Petit module d’un projet plus important

- ++ - ++ ++ -

Fondations techniques d’un développement fonctionnel

+ + -/+ ++ ++

Grand projet indépendant

++ + ++ ++ + +



113

On voit clairement que tous les projets sont loin d’être égaux lorsqu’il s’agit de les confierà un prestataire en offshore. C’est pourquoi il faut porter une grande attention à ceux quel’on souhaite externaliser vers des équipes offshore et anticiper les difficultés. Le premierprojet est particulièrement important, et il nécessite de se donner les meilleures chancesde succès.

Se préparer à éprouver ces difficultés est un atout clé pour les éviter ou les corriger. Quelsque soient la taille et le type du projet, la source de dysfonctionnement la plus importanteest la plus ou moins bonne qualité des spécifications et la stabilité du projet.

Conclusion

La nature même du premier projet que l’on confie à une équipe en offshore donne claire-ment le ton de la coopération. La prudence du client, qui cherche à confier un petit projetsatellite, peut facilement mener à un échec des réalisations distantes. Comme le but dece premier projet est justement de qualifier le mode de travail et de tester le prestataire,on conclut alors souvent que le prestataire est responsable de celui-ci.

Les efforts à fournir pour réussir des projets mal choisis, ou difficiles par nature, fontappel à de nombreuses qualités du prestataire. Au-delà des compétences techniques, illui faut faire preuve de psychologie avec le client qui ne comprend pas ou ne veut pascomprendre les difficultés auxquelles font face les collaborateurs distants.

Dans cette relation, les collaborateurs du client jouissent souvent d’une forme d’immu-nité. Le prestataire ne se permet pas de critiquer le travail des collaborateurs du client,qui sont pourtant parfois clairement responsables des difficultés rencontrées en offshore.La diplomatie est de mise et le prestataire doit rapidement comprendre le rôle et lepouvoir de ses interlocuteurs pour parvenir au succès.

Dans les projets en offshore, tous les projets sont loin d’être égaux. La taille et la naturedu projet influent grandement sur son succès ou son échec. La timidité mène tout natu-rellement à des résultats médiocres, et ses conclusions sont finalement peu utiles pourvalider la possibilité de travailler avec un prestataire en offshore ou évaluer ses capacités.

Type de projetFacilité

à le manager

Formation fonctionnelle

Pertinence comme premier projet

Importance des

procédures

Emploi d’outils (référentiel,

changement)

Chance de

succès

Reverse-engineering d’un petit projet

+ + + + ++

Reverse-engineering d’un projet important

++ + ++ ++ ++ ++

Tableau 5.1. Types de projets offshore et efforts à fournir(suite)



114

Paradoxalement, les clients qui semblent les plus hardis et qui se lancent directementdans un projet important en mettant en place les processus qui conviennent ont plus dechances de succès et travaillent plus sereinement. De même, ceux qui confient des projetsplus critiques prêtent naturellement plus d’attention au prestataire, et le projet ne s’enporte que mieux.


115

Chapitre 6

Les risques de l’offshore

Les sociétés qui envisagent de confier certaines de leurs réalisations en offshore asso-cient presque toujours cette initiative à un risque important et mal maîtrisé. Il convientcependant de relativiser les risques attribués aux développements en offshore car nombred’entre eux sont aussi élevés, voire davantage, lorsque les développements sont réaliséslocalement, au sein même de la société, à l’exemple du risque que des créations origi-nales soient divulguées à la concurrence.

De nombreux clients de l’offshore présupposent que certains sujets sont particulièrementexposés. Une crainte fort répandue est que le prestataire en offshore ne détourne le codequi lui est confié pour créer un produit concurrent ou le revendre. D’autres craintesconcernent la sécurité des communications entre sites ou le montant des marges prélevéespar le prestataire.

Force est pourtant de constater que le plus grand risque qui menace un projet en offshoreest que le client ne sache pas le gérer à distance. Nombreux sont en effet les projets queles clients se révèlent incapables de gérer, tout en reportant la responsabilité de l’échecsur leur prestataire. Pour ce dernier, le risque principal est que le client ne paye pas, etchaque nouveau client est pour lui une source d’inquiétude.

Le partenaire

Lorsqu’on choisit de travailler avec un prestataire en offshore, il est essentiel de savoir àqui l’on a affaire. Le client se trouve démuni pour juger du sérieux de son partenaire.Certains prestataires n’ont pas même d’existence légale, en dépit de la qualité profession-nelle de leurs sites Internet, de leurs nombreuses références et du grand nombre depersonnels qu’ils emploient.

Pour se prémunir des conséquences notamment juridiques de telles collaborations, il estcourant de demander au prestataire de communiquer ses statuts, si possible traduits enanglais. On peut ainsi connaître la nature de la société ainsi que l’identité des associés.

La structure de l’actionnariat est importante pour comprendre le type de société auquelon a affaire. Si l’on découvre que la société du prestataire est en fait une fi liale d’un éditeurde logiciel américain, on prendra soin de s’assurer que l’activité de développement que



116

l’on en attend sera gérée avec tout le sérieux nécessaire. Si la société est la filiale, peut-être récente, d’un grand prestataire indien, on se demandera quel sera l’impact du projetqu’on souhaite lui confier sur la stratégie de ce prestataire. On peut aussi légitimementredouter que la société ne soit liée à un concurrent.

L’existence de références parfois remarquables n’est pas un gage que la société est juri-diquement constituée. Les clients précédents n’ont peut-être pas pensé à vérifier sonstatut ou ne s’en sont pas préoccupés. Il vaut toujours mieux vérifier cette situation parsoi-même.

EN RÉSUMÉStatut du partenaire

Il est important de bien connaître son partenaire. Il est recommandé pour cela d’exiger les statuts dela société en offshore et de les faire traduire avant de prendre sa décision. Il est important que leprestataire ait une existence légale.

Les litiges en offshore

Lorsque des tensions surgissent avec le partenaire en offshore, il ne faut pas hésiter àrechercher un médiateur susceptible d’aider les parties à trouver une solution à l’amiableau lieu de laisser la situation se dégrader. Il peut être utile de prévoir une telle clause dansles contrats qui lient le client au prestataire, car ces médiateurs donnent généralementd’excellents résultats.

En cas de litige, le client peut avoir un contrat-cadre avec un cabinet d’avocats, lui permet-tant de consommer un certain volume d’heures d’avocat (retainer). Cela rend le coût degestion du litige pratiquement nul. Même s’il doit payer un cabinet d’avocats pour sesprestations, le client utilisera son cabinet habituel, dont il contrôle assez bien les coûts.

Pour le prestataire, la situation est tout autre. Il doit prendre un avocat dans un paysdistant qu’il connaît mal, aux tarifs très élevés en comparaison de ceux en vigueur dansson pays. La gestion du litige s’accompagne de surcroît de voyages et de séjours à l’hôtel,qui en alourdissent encore le coût. Dans ces conditions, seul un litige réellement importantpeut justifier de telles dépenses par le prestataire pour se défendre ou attaquer.

Les décisions des tribunaux dans le pays du client ne sont pas toujours faciles à faireappliquer dans les pays de l’offshore, surtout s’il s’agit de sommes modiques ou de resti-tution de code source. Bien que théoriquement applicables dans les pays de l’offshore,les condamnations sont rarement exécutées dans la réalité. Par exemple, les procèsintentés par les grands éditeurs pour la protection des licences ont porté peu de fruits. Lafaible volonté des juridictions des pays de l’offshore d’exécuter les condamnations estparfois amplifiée par la perception que la décision est injuste puisque le prestataire n’apu défendre ses chances à armes égales.

Pour éviter de telles situations, le client peut avoir intérêt à prendre un excellent avocatdu pays de l’offshore. Les décisions de justice éventuelles sont alors beaucoup plusfaciles à faire appliquer. Les coûts des avocats sont par ailleurs modiques dans certainspays d’offshore, et il est possible d’être correctement représenté.


Chapitre 6 – Les risques de l’offshore

117

Protection de la propriété intellectuelle

La première préoccupation d’un chef d’entreprise ou d’un responsable du développementconcerne la propriété intellectuelle qui est transférée en offshore et tout particulièrementles codes source. On associe assez naturellement la valeur d’un développement à soncode source, et l’on souhaite le protéger au mieux.

La crainte que les sources qui ont servi à réaliser le projet soient détournés par le presta-taire ou un de ses collaborateurs n’est pas sans fondement. Quand on voit comment leslois sur les copyrights sont ouvertement ignorées dans les pays de l’offshore, on a toutlieu de redouter que les produits du client soient détournés. Même si on ne sait pas exac-tement ce qui pourrait arriver au code source, on panique à l’idée de le retrouver sur unautre marché géographique ou de voir le prestataire le revendre à des concurrents.

Si le risque de détournement de la propriété intellectuelle existe bel et bien, il est rarequ’il se concrétise à des fins commerciales. Les prestataires en offshore opèrent dans deszones où, bien souvent, il n’existe pas de réel marché local du logiciel, rendant l’exploita-tion de tels détournements peu rentable et fortement risquée. Les produits de grandediffusion commercialisés sur Internet sont beaucoup plus exposés car la fraude peut êtreinitialisée par une seule personne indélicate et mener à des profits certes faibles, maisrapidement acquis.

C’est finalement en terme de réutilisation sur d’autres projets que le risque est le plusimportant, d’autant que les informaticiens qui réutilisent un code qu’ils ont un jour crééy perçoivent avant tout un gain de temps et n’y voient pas forcément malice.

Propriété du code sourceIl existe de fait un risque juridique sur la propriété du code source. Dans la plupart despays, le payeur n’est pas nécessairement le propriétaire du code source, car c’est le créateurdu code qui en est le propriétaire naturel.

Certains prestataires en offshore mettent clairement en avant leur désir de construire desoffres de produits à partir des réalisations qui leur sont confiées. Ils font valoir qu’ils sontles propriétaires du code source, dont ils accordent une licence éternelle au client payeur.Parfois, le prestataire revend des services sur la base d’un développement réalisé pour unpremier client. Celui-ci, payant pour un plein développement, peut accepter que le pres-tataire réutilise le cœur du développement pour construire d’autres solutions. Gagnantainsi du temps, le prestataire reverse alors des droits au client pour avoir utilisé du codedéveloppé initialement pour lui.

De tels arrangements ne peuvent se produire que si le prestataire agit en tant qu’utilisa-teur final ayant un besoin d’exploitation et qu’il n’envisage pas de revendre le logiciel. Parexemple, un client industriel qui met au point une gestion de stock s’appuyant sur un ERPdu marché peut ne pas s’opposer à ce que son prestataire essaie de packager le produitet de le revendre, pour peu que le coût du projet s’en trouve diminué. Ce client n’étant pasun éditeur de logiciel, il souhaite avant tout optimiser les coûts de ses réalisations.

Pour la plupart des clients de l’offshore, cette situation est toutefois inacceptable. Ilsveulent avant tout utiliser les forces de production en offshore pour créer leurs produits



118

dans les meilleures conditions possible. À leurs yeux, le prestataire ne doit avoir aucundroit sur les réalisations en offshore, tout particulièrement s’ils sont éditeurs de logiciels.

En réalité, ce sont les clauses du contrat qui déterminent qui est le propriétaire de la créa-tion intellectuelle. Comme nous le verrons au chapitre 9, consacré au contrat avec lepartenaire, le contrat doit clairement préciser que la propriété intellectuelle de toutes lescréations en offshore, incluant le code source et tous les éléments créés ou échangés aucours du projet, revient au client et que le prestataire n’a aucun droit sur elles.

Une règle claire consiste à imposer que les productions réalisées dans le cadre du projet(code source, notes, spécifications, etc.) portent la mention Copyright… Client… Année…Cela permet non seulement de marquer les documents comme protégés, mais aussi defaire la preuve au besoin que les collaborateurs en ont été pleinement informés.

EN RÉSUMÉPropriété du code source

La propriété du code source comme de toute création réalisée chez un prestataire en offshore doitêtre clairement attribuée par contrat au client. En effet, le payeur des prestations n’est pas nécessai-rement le propriétaire juridique de la création.

Rétention des sources en offshoreLa situation devient rapidement délicate lorsqu’un conflit se développe entre le client etle prestataire. Si les paiements ne sont pas effectués comme ils le devraient, le prestataireoffshore commence le plus souvent par bloquer la livraison du code source, si c’est tech-niquement réalisable. Si le client n’a pas honoré ses factures par négligence ou du fait dedifficultés passagères, l’effet de ce bras de levier est désastreux. Le client ressent toute lapuissance de la rétention du code source, se sent pris en otage et perd rapidementconfiance dans le prestataire.

Quelle que soit la situation concrète, le prestataire n’a guère que deux moyens de pressionsur le client : la rétention du code source et la dissolution de l’équipe de développement.Cette dernière, lorsqu’elle va au-delà de la simple menace, est le plus souvent la marqued’une volonté de mettre fin à la relation commerciale plutôt que de rechercher un accord.La rétention du code source et des livrables est donc la seule arme réelle en possessiondu prestataire s’il souhaite poursuivre la collaboration.

Le fait d’avoir exprimé dans un contrat que le prestataire n’a aucun droit à exercer unerétention des livraisons n’est guère dissuasif dès lors que le prestataire considère que leclient ne respecte pas ses propres engagements et que la situation est déjà conflictuelle.

La tension a toutes les chances de monter d’un cran si le client s’imagine que le presta-taire va utiliser le produit qu’il garde en otage à son propre profit. Il s’agirait en ce cas nonplus d’un moyen de pression, mais d’un acte délictueux, mettant potentiellement endanger l’activité de la société cliente. Ce risque n’est pas une vue de l’esprit, et il arriveque de petits prestataires qui n’ont pas été payés considèrent unilatéralement que leproduit du client leur échoit en dédommagement des impayés.

EN RÉSUMÉRétention des sources comme moyen de pression

Un prestataire en offshore utilise volontiers la rétention des codes source comme moyen de pressionsur son client en cas de conflit. Les protections contractuelles sont sans effet pour interdire auprestataire de retenir les livrables.



119

Faire appel à un médiateur est un signe fort de recherche de conciliation. Lorsqu’un clienttraite avec un représentant local de l’offshore comme expliqué au chapitre 2, certainsprestataires disposent d’un agent commercial dans le pays du client , ce dernier jouenaturellement un rôle de médiateur, pour peu qu’il ne soit pas lui-même impliqué dansle conflit. Le recours à un médiateur est abordé au chapitre 9.

La meilleure solution pour se protéger du blocage des livrables est de mettre en place unréférentiel dans lequel toute la production est déposée au fur et à mesure de sa création.Le référentiel du prestataire est synchronisé en temps réel, ou presque, avec celui duclient. Dès lors, le prestataire ne peut exercer de chantage sur la production réalisée, et leblocage des livrables ne peut concerner que la production à venir, ce qui est beaucoupmoins grave.

Cette synchronisation en continu est très importante en offshore, et ce, à plusieurs titres.Le fait de demander explicitement la livraison du code source est toujours perçu commeune attitude agressive. Le prestataire se demande pourquoi son client le lui demande. Aumieux, il s’imagine que le client effectue une revue de code ou critique l’organisation dessources. Il suppose peut-être aussi que le client veut interrompre la collaboration et récu-pérer ce qui lui est dû avant de l’annoncer au prestataire. Si la demande de livraison ducode source est faite en situation de conflit, il y a toutes les chances que le prestataire laprenne comme une déclaration de guerre et qu’il ne livre pas les éléments demandés.

EN RÉSUMÉProtéger les sources par une synchronisation permanente

Pour éviter que le prestataire exerce une pression sur le client en bloquant les livrables, il est recom-mandé d’organiser une gestion de référentiel obligeant le prestataire à y placer régulièrement tousles éléments de la production. Le référentiel est synchronisé en temps réel ou quotidiennement avecle référentiel chez le client, engendrant une livraison continue de la production. Le blocage des livrai-sons par le prestataire ne peut dès lors concerner que le futur, ce qui est moins contraignant pour leclient.

Arrêt des prestations en situation de conflitLorsque les prestations s’interrompent du fait d’un conflit, des règlements peuvent êtredus au prestataire alors que les livrables ont été remis au client dans leur intégralité. Indé-pendamment des responsabilités de chacun dans la rupture, le prestataire considère ence cas qu’il est en droit de récupérer son dû sur les actifs dont il dispose, y compris le codesource.

De son côté, le client peut estimer avoir perdu beaucoup plus que la somme restant dueau prestataire. L’absence des dernières livraisons et les retards sur la production peuventreprésenter pour lui des montants très importants. Il peut même envisager de poursuivrele prestataire pour le préjudice et les dommages qu’il a subis.

Nombre de prestataires n’hésitent pas, en compensation de la dette du client, à tenter devendre le produit à leur compte ou à réutiliser le code source pour leurs propres dévelop-pements. Le seul moyen pour un client d’empêcher un prestataire de le faire est de négo-cier avec lui, non seulement en raison de l’aléa judiciaire, mais parce que les décisions dejustice ne sont pas toujours appliquées, d’autant plus dans les pays de l’offshore.



120

EN RÉSUMÉUne fin conflictuelleLorsque les prestations se terminent en situation de conflit et que des sommes restent dues au pres-tataire, ce dernier considère le plus souvent qu’il peut disposer à son gré du produit développé pourson client. Il est toujours préférable de privilégier la négociation plutôt que la rupture.

Utilisation de bibliothèques de programmesOutre le risque de détournement de la propriété intellectuelle du code source, il convientde s’attacher à protéger ce dernier contre l’inclusion de sections de code qui seraient lapropriété de tiers.

Il peut être tentant pour les développeurs en offshore d’employer des portions de code« empruntées » à des tiers plutôt que de les développer eux-mêmes. Pour gagner dutemps ou parer au plus vite à leurs insuffisances, ils peuvent employer du code qu’ilspensent libre car provenant de projets Open Source aussi bien que du code sourcecommercial.

Ce risque est plus courant qu’il n’y paraît. Par exemple, un développeur qui travaille surun domaine technique précis a de grandes chances de se voir confier des projets simi-laires. Très naturellement, parfois sans même penser à mal, il se peut qu’il réemploie du

ÉTUDE DE CAS

Déliquescence du partenariat

Un éditeur américain utilise des ressources en offshore pour réaliser des produits très spécialisésconcernant l’analyse de données d’une production pétrolière. Peu confiant par nature, il se méfiedes prestataires en place et monte sa propre équipe dans un joint-venture. Il embauche pour celaun manager de sa connaissance dans le pays.Le projet démarre bien, et les premiers projets sont satisfaisants. Bientôt, la société aux États-Unisconnaît des difficultés, et ses revenus se font erratiques. Sans visibilité, l’éditeur cesse ses paiementsau joint-venture en offshore sans donner d’explications. Les mois passant, le manager de la struc-ture offshore exige d’être payé.Après six mois sans paiement ni explications, le manager passe à l’action et entre en contact avecdes clients de l’éditeur auxquels il explique sa situation, à son avantage bien sûr. Il explique qu’ilest désormais propriétaire du produit et qu’il en assurera dorénavant la maintenance à 30 % duprix pratiqué par l’éditeur américain.Les clients contactent immédiatement l’éditeur américain. Ce dernier se veut rassurant, mais le malest fait. L’éditeur tente de régler le problème en cherchant à négocier avec le manager en offshore.Il constate alors que son joint-venture n’existe plus et que le manager opère à partir d’une sociétéqu’il a créée pour ce produit.Le manager a contacté tous les clients de l’éditeur qu’il connaissait afin de leur proposer d’acquérirle produit à travers lui. L’éditeur américain menace de poursuivre son ancien manager et ceux quise sont associés à lui, arguant du fait que les lois du pays de l’offshore sont intraitables quant aurespect de la propriété intellectuelle.Essuyant un refus de la part de tous les clients contactés, le manager disparaît finalement, et leschoses en restent là, fort heureusement pour l’éditeur américain. Ce dernier mettra cependant untemps considérable à redorer son blason, sans parvenir à rétablir tout à fait sa crédibilité.



121

code du projet précédent. Puisqu’il a un même problème à résoudre, il lui semble natureld’appliquer une même solution. L’ennui est que ce code source ne lui appartient pas maisappartient au client du projet précédent.

Si même il est conscient du problème, il peut se dire que les deux clients ont peu de chancesde découvrir la réutilisation du code. Le problème peut devenir sérieux si le premierclient, propriétaire du code, a fait de ces couches techniques un atout concurrentiel qu’ilprotège autant que possible et qu’il en découvre l’usurpation.

Il se peut aussi que le code réutilisé provienne d’une solution logicielle à licence payante,comme Oracle TopLink ou des parties de BEA WebLogic. Bien évidemment, ces produitssont soumis au paiement de licences, le plus souvent selon l’utilisation que l’on en fait,par processeur. Si l’on ne contrôle pas correctement le code source, on peut découvrir quela solution nécessite des licences payantes pour être déployée.

Il n’est guère possible de se protéger de ce risque par contrat, car si le prestataire utiliseun tel code source et qu’il y ait un réel préjudice, il est hautement probable qu’une actionen justice condamne ceux qui auraient bénéficié de la fraude, en l’occurrence le client, enmême temps que le prestataire. De plus, si le prestataire ne peut honorer les dommageset intérêts exigés, ce qui est plus que probable puisque les sommes en jeu peuvent serévéler très élevées, le client seul solvable se retrouve seul tenu de dédommager la partielésée.

Pour avoir quelque efficacité, le contrat doit bien sûr interdire explicitement l’utilisationde code source externe sans l’accord explicite du client mais surtout s’accompagner d’unsuivi régulier des développeurs, surtout dans les domaines techniques, car ils sont lesplus tentés de réutiliser des programmes licenciés. Ajoutons que ces blocs logiciels sontassez faciles à détecter avec des outils d’analyse de code.

EN RÉSUMÉCodes source utilisés frauduleusement

Le contrat entre le client et le prestataire précise qu’il est interdit au prestataire d’utiliser des codessource qui sont soumis à des droits d’usage ou qui appartiennent à un tiers. Il est fortement recom-mandé d’assurer un suivi rigoureux de ces règles dans le cours des développements.

Fractionnement du code sourceCertains clients, surtout parmi les éditeurs de logiciels, ne veulent pas donner la totalitédu code source d’une application à un prestataire de peur qu’il puisse être détourné. Celalimite fortement la nature des projets susceptibles d’être confiés aux équipes en offshore.Ces dernières ne peuvent que travailler sur des modules autour du noyau central ou surles fondations techniques des applications. Le plus souvent, on leur confie des projetspériphériques, ce qui engendre les effets négatifs mentionnés au chapitre précédent.

Les clients qui donnent tout le code source de leur produit au prestataire choisissentparfois de contrôler les accès à chaque module du code par le biais d’un référentiel defaçon que personne ne puisse disposer du code source complet. Rien n’empêche cepen-dant les développeurs du prestataire de collationner le code de chaque module afin d’enreconstituer l’intégralité. Si l’intégration et le déploiement sont assurés en offshore, lespersonnes qui s’occupent de ces tâches ont nécessairement accès à l’ensemble desmodules pour pouvoir les compiler et les déployer.



122

La plupart des clients considèrent que la protection qu’apporte le fractionnement du codesource est illusoire et préfèrent faire confiance au prestataire pour atteindre une produc-tivité maximale.

Confidentialité des informations

Il est habituel de demander au prestataire de signer un accord de confidentialité, ou NDA(Non Disclosure Agreement), avec le client. Assez standard, ce type d’accord décrit cequ’est une information confidentielle et indique le plus souvent que les mêmes protectionsdoivent être portées à ces informations du client qu’aux informations confidentielles duprestataire. Bien souvent, cet accord est signé par le management du prestataire, et lescollaborateurs distants n’en sont pas informés.

Il peut être plus judicieux du point de vue psychologique de demander à chaque collabo-rateur travaillant pour le client de signer l’accord de confidentialité. Dans les pays del’offshore où l’on ne signe que très peu de documents et où le contrat de travail lui-mêmen’est pas toujours écrit, le fait d’apposer sa signature à un accord de confidentialitéengage réellement. On peut de plus en profiter pour rappeler certaines règles concernantle respect de la protection de la propriété intellectuelle.

EN RÉSUMÉAccord de confidentialité

Le client demande à chaque membre de l’équipe en offshore de signer un accord de confidentialitéexprimant clairement quelles sont les informations jugées confidentielles et certaines autres règles,notamment sur la protection de la propriété intellectuelle. Cet accord est perçu comme un engagementpersonnel fort.

Les informations confidentiellesLe prestataire en offshore a forcément accès à un ensemble assez vaste d’informationsque le client souhaite protéger. Il peut s’agir de codes source (voir la section précédente), despécifications ou d’informations sur le produit, ses anomalies ou ses faiblesses connues.

Le client souhaite naturellement assurer la protection de ces informations, à commencerpar le fait de ne pas les rendre accessibles à tous chez le prestataire offshore, en particu-lier aux visiteurs. Toutes les informations confidentielles, ou presque, sont renduesdisponibles sous forme informatique. Il est important de savoir précisément où se trou-vent ces informations et comment elles sont gérées, car, à défaut de protection, ellespeuvent être aisément copiées sur n’importe quel poste du réseau local.

Dans les cas où l’on aurait choisi de monter sa propre filiale en offshore ou un joint-venture, les informations sont naturellement isolées. C’est d’ailleurs souvent l’une desraisons qui conduit à monter ce type de société en offshore.

Gestion d’un référentiel

Si l’on souhaite contrôler les informations qui sont rendues disponibles chez le presta-taire, la première chose à faire est de mettre en place un référentiel. IBM Rational Clear-Case, par exemple, est un excellent outil pour cela. Il possède notamment une option



123

multisite permettant de synchroniser les référentiels distants. Ses principaux concurrentssont Merant PVCS et Continuus.

Le prestataire doit s’assurer que tous les éléments et informations sont placés dans leréférentiel. Chaque élément du référentiel ayant ses propres règles d’accès édictant qui ale droit de voir ou de modifier chaque fichier, on peut savoir qui a extrait un élément,à quel moment et s’il a changé quelque chose.

La figure 6.1 illustre les différents moyens de partager des informations entre un site enoffshore et le client. Ces différents moyens de partage d’informations ne sont pas inter-changeables. Les référentiels sur un LAN, par exemple, comme ceux que proposent Tele-logic ou IBM Rational, offrent la meilleure sécurité, mais à un coût important.

Les gestionnaires de documentation tels que Microsoft SharePoint peuvent jouer un rôleassez similaire pour rassembler l’information et en protéger l’accès. Les gestionnaires deréférentiels tels que ClearCase permettent toutefois de gérer plus efficacement les opéra-tions relatives au développement. On y trouve notamment des fonctionnalités de gestiond’un ensemble de fichiers et de codes source formant une version de référence (baseline)et la possibilité d’y associer une gestion du changement permettant de suivre le workflowdes corrections d’anomalie et des demandes d’évolution.

Séc

urité

Coût

Référentiel sur un LAN isolé

Référentiel sur le LAN du partenaire

Répertoires partagés

Serveur de messagerie

Figure 6.1. Solutions de partage d’information



124

Les serveurs de messagerie

Les serveurs de messagerie recueillent eux aussi des informations confidentielles par lebiais des messages échangés. Avec des équipes importantes, il est intéressant d’isoler leserveur de messagerie chez le prestataire de sorte à le dédier à l’équipe. Le gain en confi-dentialité est important.

Si l’on ne met pas en place un serveur de messagerie dédié, le serveur de messageriecommun contient des informations du prestataire, du client et d’autres clients, lesquellesse retrouvent dans les sauvegardes. Le client n’a alors aucun contrôle sur la localisationet la gestion de ces sauvegardes. De plus, les administrateurs du serveur chez le prestatairepeuvent ouvrir les comptes des utilisateurs et voir les informations qui y sont placées.

En dédiant un serveur de messagerie, on obtient une confidentialité accrue, et le presta-taire peut exiger l’application de procédures strictes pour en assurer l’administration sansrisque. Le serveur de messagerie peut aussi garder les traces de tous les messages reçuset envoyés pour analyse en cas de problème. Ces traces sont accessibles à un administrateurde serveur.

Isolement des équipesLorsqu’un projet mobilise une équipe importante en offshore, le client peut demander auprestataire d’isoler cette équipe du reste de la société. L’isolement est naturel en cas decréation de filiale ou de joint-venture en offshore. Dans les petites équipes, de moins devingt personnes, l’isolement des équipes et du réseau peut toutefois se révéler tropcoûteux en comparaison de la taille des projets.

Par ordre d’importance, il faut isoler le réseau du projet du reste du réseau du partenaireen offshore puis isoler physiquement le lieu où travaillent les collaborateurs du projet. Ondoit aussi mettre en place les procédures qui assureront l’efficacité de cette séparation(voir ci-après).

Isolement du réseau local

L’isolement d’une partie du réseau local du partenaire peut être total ou partiel. On peut,dans un premier temps, mettre en place des serveurs dédiés au client, avec des règlesd’isolement et des audits pour vérifier que ces règles sont appliquées. De cette façon, leclient peut exercer un contrôle fin sur la gestion des serveurs, les sauvegardes et les droitsd’accès.

Ces mesures peuvent toutefois se révéler insuffisantes. Les serveurs, par exemple, sonttoujours physiquement accessibles par tous les collaborateurs en offshore. Une personnemal intentionnée pourrait trouver le moyen de les pénétrer afin de récupérer des informa-tions. De plus, le client ignorant comment le réseau est géré, il ne peut être certain qu’unniveau de sécurité suffisant est appliqué.

Le client peut donc souhaiter isoler totalement son réseau local de celui du prestataire.Aucun composant réseau n’est alors partagé, et les utilisateurs du réseau du prestatairene peuvent accéder physiquement à celui du client. Une telle option a un coût important.Le client doit acheter le matériel réseau (switch, pare-feu, serveurs, système de sauvegarde),les licences (systèmes d’exploitation, serveur de messagerie, logiciel de sauvegarde, etc.) et



125

la bande passante sur Internet. De plus, le réseau passant sous sa responsabilité, il luifaut certainement embaucher des administrateurs pour le gérer en offshore.

Le contrôle des accès

Pour s’assurer que les informations sont correctement protégées, on peut organiserl’isolement des équipes en offshore. Elles travaillent en ce cas dans des salles sépa-rées, accessibles uniquement aux membres de l’équipe du client. Pour être efficace, cesystème nécessite que l’accès aux locaux soit contrôlé par des cartes personnelles, quiidentifient chaque personne entrante et sortante et mémorisent les heures de passageaux portes.

Même si toutes les personnes concernées disposent d’une carte personnelle d’accès dansles locaux, encore faut-il qu’elles ne fassent pas entrer d’autres personnes. Certainssystèmes sophistiqués proposent des sas à une personne, qui garantissent des accèsphysiques individuels. D’autres contrôlent les sens entrée et sortie afin que seules lespersonnes qui sont effectivement sorties puissent entrer à nouveau, évitant de la sorte leprêt de cartes. Des caméras peuvent être ajoutées au système pour contrôler les entrées-sorties.

Toutes ces règles d’accès ne sont toutefois pas faciles à appliquer, et l’on constatesouvent, à l’occasion des fêtes, par exemple, la présence de nombreuses personnes exté-rieures non autorisées. L’isolement des locaux ne s’avère efficace que si l’équipe est

ÉTUDE DE CAS

Non-respect des règles de gestion du réseau local

Une société opte pour la mise en place d’un réseau local dédié. Deux administrateurs réseau fontpartie de l’équipe du client, elle aussi clairement dédiée, pour gérer les soixante ordinateurs del’équipe. Le réseau doit être parfaitement isolé, avec des équipements, un serveur de messagerie etune bande passante sur Internet également dédiés. Les règles sont strictes et clairement expriméespar écrit.Après quatre mois de travail avec ces équipes, on s’aperçoit que la synchronisation du référentielentre Paris et l’offshore ne fonctionne pas correctement et qu’elle est d’une lenteur intolérable,surtout la nuit.On dépêche une mission d’audit. Il apparaît que certaines règles ne sont pas respectées. Le respon-sable de l’informatique interne du prestataire maintient de fait un rôle de supérieur hiérarchiqueenvers les administrateurs qui travaillent dans l’équipe dédiée du client, laquelle lui demandesouvent des conseils pour la configuration de certaines machines. Constatant l’énorme quantité debande passante inutilisée la nuit, ce responsable a mis en place un système autorisant les utilisateursdu réseau du prestataire à accéder à cette bande passante après une certaine heure.Le prestataire n’imposant pas de règles strictes sur l’emploi d’Internet, un certain nombred’employés téléchargent toutes les nuits musiques, films et programmes et saturent la bandepassante. Il ne reste pratiquement plus rien pour les usages professionnels du client qui souhaiteréaliser ses synchronisations de nuit.Sans audit, il aurait été impossible de détecter ces dysfonctionnements et d’y remédier. Des sondeset des outils recherchant les vulnérabilités ont ensuite été utilisés régulièrement pour détecter cesaccès non autorisés.



126

suffisamment importante pour que le prestataire lui dédie un étage entier, naturellementisolé du reste des locaux.

EN RÉSUMÉIsolement des équipes

L’isolement des équipes en offshore devrait toujours être réalisé lorsque ces dernières sont impor-tantes et qu’on recherche un niveau de sécurité ou de confidentialité élevé. En isolant les équipes etle matériel et en les dédiant à l’activité du client, on parvient à se démarquer des règles en vigueurchez le prestataire et à appliquer les procédures qui conviennent le mieux.

Les fuites chez des concurrentsLes clients peuvent craindre que le prestataire fournisse des prestations à un concurrentet qu’une partie du savoir ou que certaines informations confidentielles soient divulguéesà cette occasion. Ce risque est particulièrement important pour les éditeurs de logiciels.

La nature des informations confidentielles peut concerner les spécifications, des partiesdu code source, des informations sur le plan produit, etc. Un collaborateur passant d’unclient à un autre ou, pire, une personne travaillant à temps partiel sur deux projets diffé-rents du prestataire peut transmettre de telles informations à la concurrence, sanstoujours s’apercevoir de leur valeur.

Certains contrats essaient de se prémunir contre de tels risques. Une autre solutionconsiste bien sûr à créer une filiale ou un joint-venture en offshore afin de contrôler plei-nement les activités de la société. Il est aussi possible d’identifier les autres clients duprestataire et d’interdire éventuellement à ce dernier de travailler avec certains d’entreeux (voir le chapitre 9).

EN RÉSUMÉSe protéger des fuites vers les concurrents

Un client qui redoute que le prestataire offshore traite avec un concurrent et que des informationsconfidentielles lui parviennent peut se protéger par contrat. Il est de la sorte possible d’interdire auprestataire de traiter avec des concurrents figurant nommément dans le contrat. Cette interdictionperdure souvent après la fin du contrat.

Réutilisation du code source

Dans les pays où la propriété intellectuelle est une notion pour le moins vague, on peutcraindre que certains candidats à un emploi chez un prestataire ne cherchent à faire valoirnon seulement leurs capacités propres, mais aussi le code source et autres élémentsqu’ils ont emportés d’un emploi précédent. Malheureusement, certaines sociétés nerejettent pas systématiquement de telles propositions et se laissent tenter.

Dans de nombreux pays, les programmeurs quittent la société qui les employait enemportant leur code source, voire le code source complet du projet sur lequel ilstravaillaient. Ils n’ont pas nécessairement l’intention de le réutiliser, mais ils le conser-vent en souvenir de leur travail. Certains d’entre eux vont parfois plus loin et réutilisentsans le dire dans de nouveaux projets des portions de code déjà produites pour peu queles technologies employées le permettent. Inutile de préciser que ces pratiques ne sontpas spécifiques de l’offshore et qu’on les constate aussi dans nos pays, où elles sont toutaussi difficiles à contrôler.



127

Si l’on ne peut totalement s’en prémunir, du moins peut-on les rendre plus difficiles àréaliser. Tout d’abord, on s’assure que tous les employés signent l’accord de confidentia-lité précisant quelles sont les informations confidentielles, ainsi que les règles les concer-nant et les risques encourus par l’employé qui ne les respecteraient pas. La gestion duréférentiel permet ensuite de savoir si une personne a tenté de retirer l’ensemble ducontenu du projet sans raison.

EN RÉSUMÉProtection contre la réutilisation de code

On peut partiellement se protéger contre la réutilisation de son code source en demandant à chaquecollaborateur de signer un accord de confidentialité qui engage sa responsabilité personnelle en casréutilisation de ce code dans d’autres réalisations.

Protection de la méthodeCertains clients, notamment les sociétés de services, considèrent que leurs méthodes,procédures et documents de suivi font partie intégrante de leur valeur, voire leur donnentun avantage concurrentiel. Il est essentiel pour eux que la valeur attribuée à la méthodesoit perçue comme telle par le prestataire.

Ces éléments sont particulièrement vulnérables en offshore. La confidentialité des méthodesest rarement comprise, et la plupart des informaticiens n’hésitent pas à les réutiliser voireà les communiquer à des tiers. Ils le font le plus souvent sans malice et s’imaginentsimplement qu’ils en ont le droit. Il n’est pas facile de se protéger de ce risque de fuite,surtout si la méthode synthétise des bonnes pratiques qui n’ont par ailleurs rien d’innovant .

La meilleure solution est d’insérer ce sujet dans les formations réalisées sur place etd’ajouter les méthodes aux informations confidentielles clairement identifiées dansl’accord de confidentialité.

Augmentation brutale des coûts des prestations

Un prestataire offshore peut souhaiter augmenter le tarif de ses prestations, par exemplelorsque les salaires des informaticiens connaissent une hausse brutale dans le pays. Detelles situations résultent généralement de l’âpre concurrence que se livrent les presta-taires ou d’une demande accrue liée à l’implantation de grandes sociétés étrangères. Il sepeut aussi que l’inflation en dollars engendre une forte réduction du pouvoir d’achat. Leprestataire souhaite en ce cas ajuster ses tarifs pour retrouver la valeur de sa facturationen début de contrat. Certains contrats prévoient d’ailleurs d’indexer les prestations sur letaux d’inflation en dollars ou en euros.

Quelles qu’en soient les raisons, il arrive que le prestataire exprime le besoin d’augmenterfortement ses tarifs.

EN RÉSUMÉAjustement des prix sur l’économie du pays

Il est commun de prévoir un ajustement des tarifs du prestataire en fonction du taux d’inflation endollars ou en euros. Faute de cela, le prestataire risque de ne plus retrouver sa marge dans lesprestations fournies.



128

Il n’est pas rare que le prestataire demande une réévaluation de ses tarifs parce qu’il a faitune proposition initiale trop basse afin d’obtenir le contrat. Il attend généralement un anavant de demander un tel ajustement et masque les véritables raisons du problèmederrière des considérations économiques on conjoncturelles.

Les différences de tarifs entre un nouveau contrat et les précédents chez un même pres-tataire peuvent aller du simple au double, voire davantage si la comparaison porte sur desprestations au forfait et en régie. Certains projets calculés au plus juste au commence-ment du contrat ne génèrent plus aucune marge. Le risque est alors que le prestataire sedésintéresse des projets à faible marge et en retire les meilleurs de ses collaborateurspour les affecter à des projets plus profitables.

Le client ne doit donc pas s’enorgueillir des bas tarifs qu’il a négociés en offshore parrapport à ceux pratiqués par son prestataire avec d’autres clients car il n’en aura que pourson argent. Pour accepter ces tarifs, le prestataire a dû recruter les candidats qui accep-taient les salaires les plus bas, les meilleurs profils et les plus stables ayant échu auxautres clients.

EN RÉSUMÉBas tarifs et qualité des prestations

Il n’est pas souhaitable que les tarifs pratiqués pour un client soient largement inférieurs à ceuxappliqués aux autres clients du prestataire. L’équipe du client sera vite identifiée comme étant àfaible marge et sera négligée, voire utilisée pour construire d’autres équipes pour d’autres clients. Lepersonnel sera clairement de qualité inférieure, ce qui se ressentira sur la productivité et la qualitédes prestations.

Il est généralement suffisant de se situer dans une moyenne raisonnable des tarifs appliquéschez le prestataire, sans nécessairement s’aligner sur les plus élevés.

En cas de tarifs exagérément bas, le prestataire ne manque pas d’émettre des requêtesafin de les ajuster. Le client aurait tort d’ignorer systématiquement ces requêtes, carcertaines demandes d’ajustement peuvent être justifiées. C’est le cas, par exemple, lorsquele client a négocié des conditions spéciales pour couvrir une période financièrementdifficile pour lui et que ces conditions perdurent alors que sa situation s’est améliorée.

Si le prestataire ne parvient pas à se faire entendre, il peut frapper un grand coup sur latable et exiger l’ajustement, en menaçant de ne pas livrer les codes source et autres livra-bles, voire de dissoudre l’équipe. Le client porte alors sa part de responsabilité dans lacrise. En ignorant les demandes du prestataire, il s’est exposé au risque de voir ce dernierpréférer arrêter un partenariat qui ne lui apporte pas de marge. Il ne s’agit pas là vraimentd’un chantage.

Monter deux équipes en offshorePour se prémunir de tout risque en offshore, il est envisageable de monter deux équipeschez des prestataires différents, chaque équipe appliquant strictement les mêmes procé-dures et méthodes. En cas de problème avec l’un des prestataires, on bascule les tâchessur l’autre, et ce, d’autant plus facilement que les règles de codage, de documentation etde reporting sont les mêmes sur les deux sites.

Cette solution doit être notamment considérée pour tout projet un tant soit peu straté-gique. Elle implique cependant un coût plus important. La gestion des projets répartis estbeaucoup plus délicate, les problèmes de communication, de synchronisation et surtout



129

d’intégration multisite faisant perdre en productivité et induisant un coût plus important.Les visites sur place sont également plus longues et coûteuses, car au lieu de rendre visiteà une seule équipe, on se déplace sur les deux sites.

Le montage de deux équipes peut être considéré de plusieurs façons. Il est possible demonter deux équipes de taille comparable, qui collaborent au même projet. Les réali-sations sont distribuées sur les équipes de façon à confi er à chacune un ensemblefonctionnel aux dépendances externes faibles. Chaque équipe peut donc travailler indé-pendamment de l’autre. Le résultat du travail des deux équipes est ensuite assemblé pourconstruire le produit final. On atteint de la sorte plusieurs objectifs : on s’assure une solu-tion de repli si l’un des prestataires venait à se révéler défaillant, et aucun des deux sitesne dispose de la totalité du produit, ce qui est un gage de sécurité. En revanche, lesprojets doivent être synchronisés entre les équipes, et les points de dépendance des réali-sations doivent être gérés avec précision.

Cette organisation ne manque pas de créer une concurrence entre les équipes, qui, biengérée, peut se traduire par une augmentation de la productivité de chaque équipe. Ellepeut à l’inverse devenir néfaste si chacune des équipes cherche à établir sa prééminence,par exemple, en ne fournissant pas de réponses aux questions posées par l’autre équipeou en traînant pour livrer les éléments qui lui sont nécessaires.

On peut aussi choisir de créer une équipe principale et une équipe de repli, beaucoupplus petite. L’essentiel des réalisations est donné à l’équipe principale, la seconde sevoyant confier de petites réalisations indépendantes ou peu importantes. Il importe en cecas de s’assurer que la petite équipe connaît le produit et les méthodes en vigueur. En casde nécessité, la petite équipe servira de noyau à une équipe rapidement construite.

Les surcoûts opérationnels sont dans ce cas assez faibles car le client se concentre surl’équipe principale et ne perd pas de temps à gérer l’équipe secondaire.

On peut encore considérer de confier à deux équipes en parallèle les mêmes réalisations.Les coûts sont alors doublés. Cette approche ne manque pas de créer une vive concur-rence, car les réalisations des deux équipes sont directement comparables, et le travail dela meilleure équipe part en production, sanctionnant ainsi l’équipe perdante. Une épéede Damoclès pend sur l’équipe la moins performante, qui risque à tout moment de se voirdissoute sans que cela affecte le moins du monde les réalisations du client. Le gain enproductivité peut, dans une certaine mesure, compenser le doublement des coûts.

Le tableau 6.1 résume les avantages et inconvénients de chaque approche.

Tableau 6.1. Avantages et inconvénients de la création de plusieurs équipes en offshore

Deux équipes de même taille

se partageant le projet

Une équipe principale et une petite équipe de repli

Deux équipes effectuant les mêmes réalisations

Productivité L’impact sur la productivité peut être positif s’il existe une saine émulation ou négatif si l’une tente de nuire à l’autre pour établir sa prééminence.

Similaire à une équipe unique

Concurrence très forte en permanence et compétiti-vité accrue



130

Les paiements du client

Nous avons déjà abordé certains effets de l’absence ou du retard de paiement des facturesdu prestataire par le client. Les réactions du prestataire sont, dans l’ordre, de bloquer leslivrables, de menacer de dissoudre l’équipe, de dissoudre effectivement l’équipe etdisposer du produit à sa convenance. Il est rare qu’il décide de poursuivre son client, saufdans le cas où il aurait une représentation dans le pays de ce dernier.

Lorsqu’un conflit réel surgit entre le prestataire et le client, celui-ci peut décider de ne paspayer son prestataire. Le conflit peut avoir pour origine des clauses contractuelles nonrespectées, une productivité anormalement basse ou encore un taux de démission oude licenciement révélant un problème de management local. Il vaut alors mieux payerle prestataire partiellement de façon à exercer une pression forte mais raisonnable pour lecontraindre à honorer ses engagements.

Les retards de paiementComme expliqué au chapitre 3, le fait de payer en retard résulte le plus souvent en unretard de paiement de l’équipe offshore. La régularité des paiements est donc un desfacteurs les plus appréciés des prestataires comme des collaborateurs. Un client qui faitde son mieux pour régler au plus tôt le prestataire est d’autant mieux valorisé et doncservi. De plus, la régularité des paiements peut venir compenser en grande partie unemarge faible et faire en sorte que le client ne soit pas négligé.

Deux équipes de même taille

se partageant le projet

Une équipe principale et une petite équipe de repli

Deux équipes effectuant les mêmes réalisations

Confidentialité Les réalisations sont parta-gées entre les équipes qui ne voient, chacune, qu’une partie du produit complet.

L’équipe principale dispose de tout le produit. L’équipe de repli peut ne disposer que d’une vue partielle.

La confidentialité est réduite, car les deux équi-pes disposent du produit complet.

Protection contre un problème avec le partenaire

Repli aisé de toutes les réalisations sur un site unique. La bonne applica-tion des méthodes rend ce transfert beaucoup plus facile.

Le repli sur la petite équipe est assez délicat, car de nombreux postes doivent être rapidement pourvus et le matériel est souvent sous-dimensionné.

Le passage d’une équipe à une autre se fait sans heurts.

Impactsur les coûts

Les surcoûts sont surtout organisationnels (déplace-ments et matériels).

Faibles surcoûts si l’on restreint les déplacements et les investissements chez le prestataire de repli.

Les coûts sont doublés pour les prestations offs-hore. Les déplacements sont également doublés.

Tableau 6.1. Avantages et inconvénients de la création de plusieurs équipes en offshore(suite)



131

Payer dans les temps n’est pas toujours chose facile. Si les éléments pour établir la facturesont un tant soit peu complexes bien souvent, elles prennent en compte le nombre dejours travaillés par collaborateur, mais aussi les vacances, les heures supplémentaires etdes éléments refacturés à prix coûtant , le prestataire peut facilement commettre deserreurs de facturation. Certaines erreurs sont difficiles à détecter. Par exemple, il se peut quel’on ait défini par contrat un nombre de jours de congé annuel minimal pour les collaborateurset qu’aucun d’eux ne puisse être facturé sur l’année pour plus de jours que le maximumdéfini. Pour vérifier la facture, le client doit pointer pour chaque collaborateur le nombre dejours de congés qu’il a effectivement pris afin de vérifier qu’il n’est pas facturé au-delà de cequi est prévu ou encore vérifier qu’un jour férié en offshore n’apparaît pas comme un jourtravaillé.

Les corrections de factures peuvent générer de nouvelles erreurs. Le temps s’écoule alorssans engager de paiement. Si un décideur est en vacances, en voyage ou simplement peudisponible, les allers-retours prennent parfois des semaines, pendant lesquelles les colla-borateurs mécontents ne sont pas payés.

Il est possible de s’entendre pour que les factures soient honorées à réception, quitte àce que les ajustements éventuels soient reportés sur la facture suivante.

Les risques politiques locaux

Comme expliqué au chapitre 2, les pays de l’offshore peuvent présenter des risquesd’instabilité politique ou économique. À moins d’événements d’une réelle gravité, la vieéconomique est peu affectée, et les informaticiens continuent de travailler, parfois au prixd’une perte de productivité ou d’un absentéisme accru.

Seules les crises de grande ampleur peuvent arrêter un projet. Il ne s’agit pas alors d’évé-nements isolés mais de catastrophes naturelles, de guerres civiles ou d’autres séismesmajeurs. Les événements politiques qui ont marqué la fin du régime de Ceausescu enRoumanie ont à peine perturbé les prestations des équipes roumaines en offshore. Il enest allé de même en Ukraine, où les manifestations massives de contestation de l’électionprésidentielle de 2004 n’ont en rien perturbé les projets offshore en cours.

Dans certains pays, les risques en matière de sécurité sont tels que les chefs de projet dessociétés clientes refusent de se rendre sur place. Cela concerne de très nombreux pays, etmême l’Inde, le premier pays de l’offshore, a plusieurs fois frôlé la guerre avec le Pakistan.

Le choix d’un pays de l’offshore doit tenir le plus grand compte de ce type de risque,même s’il n’a pas de lien direct avec le coût des prestations. Le premier effet des situa-tions à risques est le refus des chefs de projet locaux et autres collaborateurs de se rendrechez le prestataire.

Les licences des outils de développement

Le risque juridique que fait peser l’emploi par le prestataire de logiciels sans licence estdifficile à évaluer. Dans la plupart des pays de l’offshore, en effet, les droits d’utilisation



132

des logiciels sont pour le moins équivoques, et l’on trouve des éditions complètes deWindows XP, Oracle Server ou Microsoft Exchange Server, par exemple, pour quelquesdollars. Il ne s’agit pas pour autant de versions pirates, puisqu’elles comportent lestimbres ou hologrammes attestant que des droits ont été versés au gouvernement sur lavente de ces marchandises.

La crainte d’être poursuivi pour avoir bénéficié de licences illégales est loin d’êtreinfondée. On peut s’en protéger en exigeant par contrat que les logiciels mis à la disposi-tion du client soient acquis en pleine conformité avec les lois du pays. Le prestataire, etnon le client, est tenu de s’assurer que cette clause est respectée. On peut aussi demanderconfirmation écrite que tous les produits ont été acquis officiellement.

Le problème se complique lorsque c’est la légalité même des licences qui laisse à désirer.Nombre de gouvernements des pays de l’offshore permettent que des logiciels sanslicences soient vendus en toute légalité dans des magasins officiels et en perçoivent lestaxes afférentes. Chacun a beau savoir que les droits de ces logiciels ne sont pas acquittésà l’éditeur, cela reste le moyen d’acquisition de logiciels le plus naturel dans ces pays.

Même avec la meilleure volonté, il est bien difficile de vérifier que les licences que le pres-tataire utilise ont été acquises en toute légalité. Certaines licences en apparence légalespeuvent avoir été upgradées illégalement ou déployées sur plus de machines qu’autorisé,par exemple.

Lorsque le réseau est géré par le prestataire offshore, le client peut se satisfaire d’unesimple vérification que les licences sont légalement acquises. Il n’en va pas de même sile réseau est dédié à un client, dans une filiale ou dans un joint-venture, par exemple. Leclient peut être tenu pour responsable de la gestion des licences sur son réseau,puisqu’elles ont été déployées selon ses directives. Il est en ce cas nécessaire qu’ils’assure de la légalité de toutes les licences.

Il est cependant peu probable qu’une organisation quelconque dans un pays de l’offshoreait les moyens de contraindre un prestataire à se soumettre à un audit pour vérifier lalégalité des licences déployées.

EN RÉSUMÉVérification des licences en offshore

Lorsque le réseau est géré par le prestataire, il doit être établi contractuellement que ce dernier metà disposition du client des licences logicielles acquises légalement selon les lois du pays. Lorsque leclient gère son propre réseau dédié, c’est à lui de faire la preuve qu’il a acquis les licences des logicielsqu’il utilise.

Les licences apportées par le clientUne difficulté symétrique concerne les licences des logiciels apportés par le client afind’être utilisés en offshore. Dans ces pays, le marché parallèle des logiciels qui est enfait le marché principal est à l’affût de toutes les nouvelles versions des produits. Il y adonc un risque que la version apportée par le client devienne la souche de duplicationsillicites.

Pour les logiciels de très grande diffusion, comme les systèmes d’exploitation, les suitesbureautiques, la CAO ou l’édition de vidéos, les pirates trouvent très facilement lessources qui leur permettent de sortir les versions récentes sur les marchés parallèles enmême temps voire avant leur sortie officielle. En revanche, certains logiciels professionnels



133

coûteux ne sont pas toujours disponibles rapidement sur ces marchés. Lorsqu’un clientde l’offshore arrive avec un produit réputé rare, il se peut que celui-ci soit immédiatementcopié pour être revendu à des structures qui se chargent de le dupliquer. Les moyens delutte contre les experts du piratage que l’on trouve dans ces pays étant généralementinopérants, une fois la copie du logiciel transmise, elle échappe à tout contrôle.

L’éditeur du logiciel peut se retourner contre le client, lequel est censé faire des effortsraisonnables pour protéger les licences mises à sa disposition, d’autant plus si le produitdupliqué a conservé le numéro de série attribué à la version du client.

Pour se protéger de ce type de fraude, la meilleure solution reste d’alerter le prestataire.Les accords de confidentialité peuvent inclure les produits logiciels originaux et exigerque le prestataire et les collaborateurs les protègent d’une diffusion frauduleuse.

Retrait des protections des logicielsLorsqu’on apporte un produit logiciel en offshore, on est fréquemment surpris d’entendreles administrateurs réseau demander s’ils peuvent en déployer une version sans protec-tion, beaucoup plus facile à gérer, quand ils ne le font pas de leur propre chef, sans mêmeposer la question. Le paradoxe est que les limitations des verrouillages pénalisent ceuxqui ont acquitté les licences alors que ceux qui utilisent ces mêmes produits piratés lesdéploient et les réinstallent comme ils le souhaitent.

Les textes qui accompagnent les licences précisent souvent que l’on ne doit pas essayerde retirer les systèmes de protection. On a beau informer les services informatiquesinternes du prestataire qu’ils doivent déployer les licences conformément aux directivesde l’éditeur, on constate bien souvent dans la réalité que les produits ont été déployéssans protection. Il suffit pour s’en convaincre de demander un redéploiement et deconstater que celui-ci ne fait l’objet d’aucune question posée à l’éditeur, alors même queles méthodes de verrouillage employées sur ces logiciels demandent d’entrer des numérosfournis par le support client à chaque opération majeure.

Les risques sociaux chez le client

Les risques sociaux en local, chez le client, ont été brièvement introduits au chapitre 3pour souligner l’importance de la communication de la société locale pour expliquer à seséquipes sa stratégie en offshore. Cette communication vise à réduire les forts risquesd’incompréhension des objectifs des réalisations en offshore, surtout si la société n’a pasl’intention de se séparer de ces équipes pour les délocaliser. En l’absence de communi-cation, les collaborateurs locaux supposeront que la société a les pires intentions.

Les syndicats et les représentants du personnel manquent rarement de s’opposer à l’utili-sation de ressources en offshore, dans laquelle ils ne voient que la menace que lesemployés de la société soient délogés au profit de personnels distants engagés à vil prix.

On aura beau expliquer que cette décision apportera plus de force à la société, qui pourramieux se placer face à ses concurrents, que l’intérêt des employés locaux pour leur travails’en trouvera renforcé en leur permettant de se concentrer sur les tâches les plus créativesou que cet apport à la capacité de production nécessitera davantage de ressources locales



134

et résultera probablement en embauches, on n’évitera pas complètement les risques derejet par les équipes locales.

Une bonne communication interne peut réduire considérablement ces risques, surtoutsi elle est poursuivie dans le temps et non ponctuelle. Si la société fait la preuve queses actions sont en phase avec son message, les inquiétudes tombent assez rapidement.Il importe surtout de communiquer sur les affaires remportées grâce à l’offshore endémontrant qu’elles n’auraient pu l’être autrement.

EN RÉSUMÉInquiétudes du personnel localLorsqu’une société commence à travailler avec un prestataire en offshore, sa communication localeest indispensable pour réduire les inquiétudes du personnel. Une communication réussie met enavant les avantages que l’entreprise et ses employés en retireront.

Un changement de méthodologie et d’organisation du développement visant à intégrerune démarche industrielle peut susciter le malaise chez certains membres des équipes dedéveloppement. Comme expliqué précédemment, ce sont les profils polyvalents qui sontles plus inquiets, car une telle réorganisation réduit le plus souvent leur poste, aupara-vant transversal, à une fonction. L’expérience prouve toutefois que ces personnes démis-sionnent rarement, surtout si le management prend soin de leur confier des missionsvalorisantes.

D’une façon générale, le passage à l’offshore s’effectue plutôt bien, après une période decrise inévitable mais rarement longue.

Conclusion

La meilleure façon de limiter les risques de toute nature avec un prestataire en offshoreest de parvenir à créer une communauté d’intérêts avec lui. Si la réussite du client doitêtre également celle du prestataire, les problèmes se règlent d’eux-mêmes. À l’inverse,lorsque le client perd confiance, négocie tous les prix, essaie de réduire en permanencela marge du prestataire ou investit en audits pour vérifier que les directives sont appli-quées, la relation de partenariat se détériore immanquablement. La contrainte devenantexterne au prestataire, celui-ci porte moins d’attention à protéger les intérêts de sonclient.

Lorsque le prestataire réalise que son partenariat est solide et fiable, il souhaite s’yinvestir à long terme, et les opérations se déroulent mieux. Les audits deviennent dès lorspratiquement inutiles, le prestataire défendant les intérêts du client en même temps queles siens.


PARTIE 22Préparation des projets

en offshoreLa première partie de l’ouvrage a introduit la culture de l’offshore et décrit lefonctionnement et les motivations des prestataires qu’on y rencontre. Laprésente partie aborde la préparation des projets en offshore, qui commencepar le choix du projet à confier au prestataire. En association avec ce projet, leclient doit aussi choisir un mode de fonctionnement convenant à la fois à sespréférences et à la nature du projet à réaliser.

Une fois choisi le projet à réaliser en offshore, vient la question essentielle duchoix du prestataire, qui découle pour l’essentiel des préférences du client etdu type de projet à réaliser. C’est un choix déterminant, car selon la localisa-tion, et donc la culture, du prestataire, certains modes de fonctionnement sontpermis tandis que d’autres sont interdits.

La mise au point du contrat qui lie le client et le prestataire constitue ladernière étape de cette phase préparatoire. C’est une étape cruciale, qui doitpermettre de définir les détails de la coopération avec le prestataire concernanttout à la fois le fonctionnement quotidien, les éléments facturables, la gestiondes relations humaines et les limites de responsabilité des deux parties.

Référence de la relation, le contrat donne en outre le ton de la coopération.Trop dur, il met le prestataire sur la défensive et rate son objectif, qui est deréunir les conditions du succès. Trop permissif, il donne lieu à des dérives, quel’on ne parvient plus à contrôler. Le bon équilibre est difficile à atteindre, etl’on ne peut y parvenir que par une gestion précise de tous les éléments qui leconstituent.

Cette partie s’achève sur les grands principes qui président à la gestion deprojet en offshore.


137

Chapitre 7

Évaluer son projet pour l’offshore

Côté client, le succès des opérations en offshore dépend autant de la compréhension du fonc-tionnement de l’offshore et de la mentalité des collaborateurs dans ces pays que du choixdu projet et de l’organisation mise en place pour le mener à bien. Ce chapitre se concentresur la préparation du projet en interne chez le client et aborde les éléments les plus déter -minants pour juger de la qualification du projet à être confié à un prestataire en offshore.

Pour démarrer un projet en offshore, il faut au préalable s’assurer que le management dela société soutient le projet et en connaît les objectifs et les conditions. Si les orientationssont mouvantes, certaines décisions importantes peuvent être remises en question,mettant parfois en danger le projet dans sa totalité. Par exemple, si le management consi-dère la sécurité sur le site en offshore comme une priorité, il peut s’inquiéter qu’un projetn’ait pas mis en place un niveau de sécurité suffisant et aller jusqu’à l’arrêter.

La simple décision de travailler avec l’offshore est parfois difficile à prendre du fait de sesmultiples implications. Même si la décision est acquise au cours d’un comité de direction,sa mise en œuvre peut se révéler délicate, surtout si la décision n’a pas fait l’unanimitéau sein du comité.

La décision doit tenir compte de tous les aspects des développements en offshore : choixdu projet, du prestataire, des équipes et des collaborateurs en interne, communicationauprès des autres équipes, outils de gestion de projet, sécurité, investissements, etc. Sile comité découvre les problèmes au fur et à mesure qu’ils se posent, les décisionspeuvent être remises en question. Dans certaines sociétés, cette décision doit remonterjusqu’au conseil d’administration à titre de direction stratégique. Les enjeux stratégiquesde l’offshore pour la société doivent alors être clairement présentés et mesurés.

La question spécifique du choix du prestataire est abordée en détail au chapitre 8 et n’estpas traitée dans le présent chapitre, bien qu’elle relève au premier chef de l’évaluation duprojet.

La position du responsable R&D

Le responsable recherche et développement peut être personnellement opposé à l’offshore ,pour de bonnes ou mauvaises raisons. Son opinion est d’une grande importance pour lesuccès des opérations en offshore. Il a de nombreuses raisons d’y être a priori opposé.



138

Il peut percevoir cette initiative comme une perte de contrôle ou d’influence sur le déve-loppement et estimer qu’elle met en cause la qualité du travail passé. Il peut aussis’imaginer que ses équipes de développement sont menacées ou, s’estimant peu armépour gérer les projets efficacement en offshore, qu’il risque de se retrouver en situationd’échec.

Si le responsable R&D est motivé par les réalisations plus que par les coûts, il est vrai-semblable qu’il sera particulièrement réticent à utiliser des ressources en offshore. À l’inverse,s’il est pleinement impliqué dans la rentabilité des développements, il cherchera claire-ment à réaliser plus et à garantir la flexibilité de ses ressources, même si l’opération comportecertains risques.

Dans la plupart des cas, un responsable R&D gère l’utilisation d’un budget. Il réalise avecfiabilité certains développements en utilisant les ressources à sa disposition et cherche àobtenir la meilleure productivité localement. Il peut se montrer exigeant, demander plus detravail et porter beaucoup de soins à gérer et suivre son activité. Le fait de viser 40 %d’économie ou plus en utilisant des ressources en offshore est une logique complètementdifférente.

Le responsable R&D raisonne souvent en évolution par petits pas. L’acquis est rarementmis en question. Les plus grands changements qu’il ait à connaître sont d’embaucher uneéquipe pour un projet majeur, réduire la taille d’une équipe ou adopter une nouvelletechnologie en conservant l’environnement global. Avec les développements en offshore,il s’agit de commencer une activité à partir de rien. Équipes, méthodes et modes de fonc-tionnement sont à reconsidérer en totalité.

Pour beaucoup de responsables R&D, cela se traduit par des risques à prendre et peu àgagner, même si les gains apportés par l’offshore peuvent être importants pour la société.Pourtant, si le responsable R&D s’y oppose, la décision d’employer des ressources enoffshore a peu de chances de réussir.

Toute décision a donc des chances d’être remise en cause si le responsable R&D ne faitpas partie du comité de direction et que son avis ne soit connu qu’une fois la décisionarrêtée. Il peut même lancer une véritable croisade contre l’offshore.

Les objectifs du client

Le client doit définir ses objectifs à court et à long terme. Le tableau 7.1 donne une idée desquestions auxquelles il doit répondre avant de se lancer dans des opérations en offshore.

Tableau 7.1. Questions stratégiques concernant l’offshore

Catégorie Question Importance

Implication en offshore

Quelles sont les raisons qui poussent la société à sous-traiter en offshore ? 3

Quels seront les projets confiés en offshore ? 2

Quel pourcentage des développements sera réalisé en offshore à long terme ?

2


Chapitre 7 – Évaluer son projet pour l’offshore

139


Budget Quelles sont les priorités budgétaires ? 2

Quelle économie vise-t-on en offshore ? 2

Dispose-t-on d’un ordre de grandeur des dépenses qui seront impliquées ? 2

Sécurité Quel est le niveau minimal de sécurité que l’on souhaite atteindre ? 3

Souhaite-t-on évaluer plusieurs solutions de sécurité et leur coût de façon à choisir celle qui convient le mieux au client ?

1

Projet test Veut-on réaliser un projet test ou souhaite-t-on démarrer sur un projet important ? 3

Quels enseignements espère-t-on du projet test ? 3

Quel serait le projet test ? 2

Management Qui va prendre en charge le management des opérations en offshore ? A-t-il suffisamment d’expérience ?

2

Est-il motivé pour l’offshore ? 3

Veut-on placer une personne de la société en offshore chez le prestataire offshore pour contrôler ou manager les équipes distantes ?

3

L’offshore complète-t-il les opérations locales ou est-il censé les remplacer partiellement et, si oui, de quelle façon ?

3

Souhaite-t-on se faire accompagner dans la mise en place ou le management des opérations en offshore ou embaucher une personne expérimentée sur l’offshore ?

2


Peut-on déjà décider du type de montage que l’on souhaite en offshore ? 2

Quelle taille d’équipe pense-t-on construire ? 3

Veut-on monter une équipe en offshore ou deux équipes ? 3

Y a-t-il des contraintes particulières que l’on souhaite prendre en compte ? 2

Métho-dologie et procédures

Quelle méthodologie veut-on mettre en œuvre ? La méthodologie locale peut-elle être appliquée en offshore ? Quels documents a-t-on pour expliquer et supporter cette méthodologie ?

2

Souhaite-t-on utiliser une méthodologie standard comme RUP ou XP ? Si oui, comment ?

2

Souhaite-t-on se faire accompagner par un consultant pour la mise en place de la méthodologie retenue ?

2

Cette méthodologie sera-t-elle aussi appliquée en interne ? 2

Tableau 7.1. Questions stratégiques concernant l’offshore(suite)



140

De ces décisions découle l’ensemble des actions fondatrices des opérations en offshore.Mieux vaut donc avoir l’essentiel des réponses aux questions du tableau avant decommuniquer en interne sur l’initiative de l’offshore. Celles-ci doivent être consignéespar écrit et conservées avec une confidentialité raisonnable. Si l’on change d’avis surcertaines d’entre elles, les solutions devront probablement être revues ou remises enquestion.

Un des points essentiels de ce questionnaire est de déterminer ce que représente l’initia-tive de l’offshore pour la société. Ces développements distribués se limiteront-ils à desdéveloppements mineurs ou sont-ils censés devenir une direction majeure pour le client ?Il est bien évident que la mise en place de l’offshore sera très différente selon que l’onconsidère le prestataire comme une force d’appoint utilisée par période ou qu’il s’agit deconstruire un ensemble de ressources à utiliser pour la majorité des réalisations. Sansune définition globale des objectifs, il est très difficile de démarrer les opérations depréparation de l’offshore.

Pour éviter de payer cher les premières expériences, il est utile de se faire accompagnerpar des personnes qui ont une réelle expérience de l’offshore. Les conseils de tellespersonnes peuvent éviter certaines erreurs qui sont très difficiles à corriger par la suite.

Définition des budgets

La définition des budgets est comme toujours primordiale. Il faut bien sûr que le budgetpuisse satisfaire aux ambitions et objectifs de la société.

Bien souvent, les calculs budgétaires ne sont faits qu’à moitié. On compte les coûts duprestataire en offshore, et l’on néglige la gestion de projet, les équipements, les déplace-ments, les formations, la communication, etc. À ce stade, il ne s’agit pas nécessairementde calculer tous les coûts mais d’avoir une idée générale des investissements et des coûtsde fonctionnement de l’offshore. Si le budget est limité, les mêmes solutions ne serontpas les mêmes que si le projet est considéré comme stratégique, notamment pour lagestion du référentiel et de la sécurité. Pour chaque sujet, il est bon d’établir rapidementune limite haute et basse des investissements auxquels on souhaite consentir.


Formation et conseil

Quelles formations envisage-t-on de donner aux collaborateurs en offshore sur les aspects fonctionnels, organisationnels et techniques ?

1

Quel accompagnement va-t-on retenir pour avoir plus de chances de faire correctement fonctionner l’offshore dès la première mise en œuvre ?

2

Outils de suivi de projet

Quel investissement est-on prêt à consentir pour les outils de suivi en offshore ?

2

Est-on prêt à investir dans des progiciels de gestion de projet ? 3

Tableau 7.1. Questions stratégiques concernant l’offshore(suite)



141

Le tableau 7.2 récapitule les principaux sujets ayant un impact budgétaire significatif surle projet offshore, au-delà des coûts directement liés aux réalisations.

Dès que les décisions sont suffisamment définies, le budget est établi pour chaque moisafin de mieux en comprendre la répartition dans le temps. À cette étape, il s’agit surtoutde vérifier que les décisions sont compatibles avec les moyens et les budgets.

Tableau 7.2. Questions concernant les principaux postes budgétaires

Catégorie Question

Gestion de projet et formation

Quel budget faut-il envisager pour des outils de gestion de projet (suite méthodologique) ? Quelle est l’étendue des outils qui seront retenus ?

Est-il nécessaire d’équiper l’offshore de telles licences ? Sont-elles déjà à disposition ?

Coût des formations éventuellement nécessaires ?


Combien de personnes doivent-elles les utiliser ? Selon le pays et le prestataire, établir une estimation du coût. Ne pas oublier les équipes de test et les autres rôles de mentors, si nécessaire.

Selon le moyen de communication retenu, quels sont les besoins en bande passante ? Vérifier la disponibilité de la bande passante et son prix. Celle-ci peut être beaucoup plus coûteuse que dans le pays du client.

Évaluation des autres coûts en offshore : communications téléphoniques, licences (si nécessaire), etc.

Licences et matériel

Le matériel des informaticiens est-il compris dans le coût des prestations ? Quel en sera le coût ?

Les licences sont-elles mises à disposition par le prestataire ? Quel en sera le coût ?

Quels sont les serveurs et autres matériels qu’il faudra acquérir pour que le prestataire travaille efficacement, notamment les serveurs de développement, d’intégration et de test ?

Management et déplacements

Quelles sont les personnes chez le client qui travailleront sur l’offshore ? Qui sera à temps plein/partiel ? Doit-on embaucher des personnes supplémentaires chez le client ?

Souhaite-t-on se faire accompagner par un conseil ?

Quels sont les budgets de déplacement à prévoir, avec quelle fréquence ? Quel en sera le coût (avion, taxi, logement, restaurant) ? Il s’agit des déplacements en offshore des collaborateurs du client et ceux des collaborateurs en offshore se rendant chez le client.

Sécurité Quelles sont les dépenses additionnelles pour les niveaux de sécurité souhaités ? Est-ce en accord avec les objectifs de sécurité ?



142

Sécurité

La sécurité est un sujet critique au commencement du projet mais qui faiblit fortementdès que le projet démarre. Au moment où l’on décide de ce que l’on veut faire en offshore,on souhaite presque toujours un niveau de sécurité extrêmement élevé. C’est là une atti-tude normale car on ne connaît pas encore bien son partenaire en offshore et l’on chercheà se protéger.

Le plus important est de définir le niveau de sécurité minimal que l’on souhaite sur lesprojets en offshore. Le tableau 7.3 récapitule les questions à se poser pour construire leniveau de sécurité adéquat pour le projet. Une mesure de coût est donnée à titre indicatif.

Tableau 7.3. Questions relatives à la sécurité en offshore

Catégorie Question Décision Coût

Prestataire offshore Souhaite-t-on travailler avec un prestataire en offshore ou veut-on créer une équipe dédiée, un joint-venture ou une filiale ?

Sécurité 5

Veut-on isoler le réseau local utilisé par les collaborateurs du client du reste du réseau local du prestataire ?

Sécurité 3

La zone de travail doit-elle être dédiée et disposer d’un système de contrôle d’accès personnalisé ?

Sécurité 1

Veut-on placer des caméras ou des webcams dans les salles de travail ?

Sécurité 1

Référentiel Veut-on utiliser un référentiel contrôlant les droits et motifs d’extraction d’éléments pour chaque utilisateur ?

Gestion 2

Veut-on mettre en place un référentiel se synchronisant périodiquement avec celui du client ?

Gestion 2

Authentification et communications

Veut-on mettre en place une authentification forte (comme des cartes à puce) pour identifier les utilisateurs sur le réseau ?

Sécurité 1

Veut-on installer un VPN avec sécurité forte pour communi-quer entre le prestataire et le client ?

Sécurité 1

Contrat Faut-il concevoir un contrat contraignant pour assurer la sécurité ?

Sécurité 0

Veut-on mettre en place un engagement personnel de confi-dentialité ?

Sécurité 0

Présence sur place Veut-on assurer une présence sur place chez le presta-taire ?

Sécurité 3



143

Le projet de test

Décider de démarrer avec un projet test revient souvent à ne pas décider réellement ceque l’on souhaite faire et à différer la décision de s’engager. Le projet démarre alors dansun environnement flou, et l’on ne construit pas vraiment la base des projets futurs. Si leschoses ne sont pas gérées convenablement, il est possible que l’on ne tire pratiquementaucune information d’un projet test pour la suite des opérations.

Si l’on choisit de démarrer un projet de test en offshore, il est indispensable de définir lesconclusions que l’on souhaite en tirer et de mener le premier projet de façon à obtenirl’éclairage désiré. Par exemple, si l’on veut juger de la capacité du prestataire à appliquerune certaine méthodologie ou de la productivité de l’équipe, il faut mettre le prestataireen condition.

De même, il faut que le projet reçoive un niveau d’attention suffisant de la part du clientde l’offshore pour atteindre un succès raisonnable. Si le premier projet, qui est toujoursplus difficile que les suivants, ne bénéficie pas du travail nécessaire de la part du client,les résultats ne préjugeront en rien des capacités du prestataire.

Le tableau 7.4 donne une idée de la plupart des sujets que l’on peut estimer lors d’unpremier projet. Il compare l’enseignement que l’on peut tirer d’un premier projet test à unprojet futur au forfait et en régie.

Tableau 7.4. Capacité d’évaluation des qualités du prestataire sur un premier projet test

Sujet à estimer sur un premier projet testÉvaluation pour un

projet au forfaitÉvaluation pour un

projet en régie

Qualité de l’équipe en offshore Basse Haute

Fiabilité du travail réalisé Moyenne Moyenne

Capacité de l’équipe en offshore à utiliser les procédures du client

Basse Moyenne

Application des règles de sécurité Basse Haute

Capacité à gérer les projets de façon indépendante en offshore et qualité des managers

Basse Haute

Qualité du reporting et de la pertinence des informations rapportées et fiabilité des annonces de livraison

Moyenne Haute

Transparence de la communication, qualité des informations échangées et facilité à remonter les problèmes pour les gérer avec le client

Moyenne Haute

Capacité à travailler de façon itérative Basse Moyenne

Capacité à gérer efficacement les intégrations Moyenne Moyenne



144

D’autres critères, particuliers pour chaque client, peuvent être évalués lors des premiersprojets tests, comme la capacité à traiter des informations en français, la qualité desdéploiements, etc.

Choix du projet de testSi l’on souhaite effectuer un test avec le prestataire offshore, il faut être en mesure d’entirer les enseignements attendus. Dans la réalité, démarrer un projet de test au forfaitpour travailler ensuite en régie apporte peu d’enseignements.

Le mieux est de demander au prestataire de réaliser un projet de test dans un mode régieavec des règles de fonctionnement strictes, afin de bien évaluer son équipe. Générale-ment, on choisit un petit projet assez facile à définir, avec des caractéristiques proches decelles qui font un bon projet au forfait. On y applique cependant les règles de fonctionneme ntd’un projet en régie et le suivi qui convient.

Il faut que le projet corresponde au moins à trois ou quatre itérations, une itérationdurant souvent entre quatre et six semaines. Il faut parvenir à valider le travail itératif etles iteration assessments. L’équipe doit comporter au moins quatre ou cinq développeurspour observer les premiers problèmes d’intégration.

Si possible, il est utile de mettre en place l’outil de gestion du référentiel que l’onsouhaite utiliser par la suite. Si le prestataire n’en possède pas, il peut être judicieux dese le faire prêter par son éditeur pour évaluation ou de le louer pendant la durée du test.La gestion du référentiel est essentielle au bon fonctionnement de l’équipe.

L’équipe de test doit comporter au moins deux personnes pour être signifi cative. On peut dela sorte observer la qualité de l’organisation des tests et la réalité des informations fournies.

Un reporting léger doit être mis en place pour analyser la capacité de l’équipe offshoreà annoncer les mauvaises nouvelles. On laissera l’équipe se débrouiller pour réaliser àdistance les intégrations et les déploiements chez le client à des fins de recette ou de testen leur suggérant des voies possibles.

Sujet à estimer sur un premier projet testÉvaluation pour un

projet au forfaitÉvaluation pour un

projet en régie

Entente entre le client et le prestataire et bonne ambiance de travail

Haute Haute

Capacité à assimiler le domaine fonctionnel du client Moyenne Haute

Capacité à créer des cas d’utilisation pour les dévelop-pements

Basse Haute

Capacité à gérer efficacement le changement Basse Haute

Organisation et qualité des tests Moyenne Moyenne

Le succès du premier projet laisse-t-il présager du succès des opérations futures ?

Basse Haute

Tableau 7.4. Capacité d’évaluation des qualités du prestataire sur un premier projet test(suite)



145

La taille du projet doit être compatible avec tous ces éléments. La nature fonctionnelledu projet de test ne doit pas être particulièrement bloquante par sa complexité ou sadépendance avec d’autres applications. Il est bon que le projet soit aussi isolé quepossible de toute dépendance externe, faute de quoi l’on ne jugerait plus vraiment de lacapacité de l’offshore.

Démarrer avec un vrai projet importantLorsqu’on choisit de ne pas tester le prestataire en offshore mais de démarrer directe-ment avec un vrai projet, ce que de nombreux clients choisissent lorsqu’ils souhaitenttravailler en régie, il convient de bien choisir le premier projet.

Comme nous l’avons vu au chapitre 5, il faut que le produit à développer soit bienspécifié. Une réécriture d’un produit existant est toujours un bon choix pour un premierprojet, même si le produit est complexe et fonctionnellement riche.

Il importe en outre que les choix techniques soient arrêtés. Il n’est pas souhaitable, parexemple, qu’un débat soit toujours en cours sur le choix de Microsoft .Net ou de Java.

Définir les objectifsIl y a tout avantage à définir par écrit au plus tôt l’objectif d’un projet. Un tel document,souvent appelé vision, permet de rassembler les équipes autour d’un même objectif final.Cet objectif sera rappelé lors de toutes les décisions majeures prises en cours de projetet servira de référence pour décider si le projet est un succès ou un échec.

EN RÉSUMÉUn objectif commun

Le document de vision du projet définissant son contenu et sa date de livraison représente le pointde convergence de toutes les décisions.

Choix des managers de l’offshore chez le client

Le choix de la personne qui, chez le client, va prendre en charge le management du projeten offshore est primordial. Dans tous les cas, à l’exception des projets au forfait, il estpréférable que cette personne soit dédiée à cette tâche.

Lorsque l’équipe grandit, on peut compter un chef de projet chez le client pour dix à vingtdéveloppeurs, accompagnés de cinq à dix testeurs pour une application de gestion. Lechef de projet est aussi accompagné chez le client de mentors (architectes et expertsméthodologiques) pour suivre les sujets techniques, fonctionnels et organisationnels.

Le responsable fonctionnel est le responsable des spécifications. C’est lui qui valide leschangements fonctionnels et recette, avec une équipe, les livraisons du prestataire.

Il est important de gérer directement les membres des équipes en offshore et d’éviter den’être en contact qu’avec le chef de projet, voire le chef d’équipe en offshore.

Le tableau 7.5 récapitule les rôles assurés par le ou les chefs de projet qui suivent desréalisations en offshore chez le client. Ces rôles peuvent bien entendu être répartis surplusieurs personnes.



146

Tableau 7.5. Rôle du chef de projet chez le client

Rôle Description

Connaître l’équipe gérée

Suivre les performances et les qualités de chacun des membres de l’offshore (développeurs et testeurs)

Connaître les capacités de management des chefs d’équipe et des chefs de projet en offshore

Connaître leur capacité à respecter les procédures et les directives

Gérer le projet

Suivre les mises à jour régulières des spécifications à la suite de discussions avec les respon-sables produit et les chefs de projet

Gérer les plans d’itération, c’est-à-dire le contenu de la prochaine itération avec des objectifs ambitieux et tenables

Gérer et valider le planning détaillé de l’équipe en réagissant aux retards et en essayant d’en comprendre les raisons et les solutions de contournement

Détecter tous les points posant problème et devant être améliorés

Répondre au plus vite à toutes les questions techniques et fonctionnelles posées en offshore, rechercher l’information où elle se trouve et donner des explications complémentaires lorsque c’est nécessaire.

Gérer la priorité des anomalies et demandes d’évolution dans les itérations

Procédures Vérifier et faire appliquer les procédures mises en place par le client

Proposer des évolutions des procédures lorsqu’elles ne sont pas satisfaisantes ou qu’elles sont trop difficiles à appliquer.

Prendre connaissance de tous les rapports de suivi du projet et proposer éventuellement des améliorations

Tests Suivre la qualité des livrables communiqués aux tests

Vérifier l’existence et la qualité des plans de tests

Suivre l’automatisation des tests et les problèmes posés

Suivre le résultat des feuilles de test de l’application en cours de développement

Interface Servir d’interface avec le responsable produit afin qu’il réponde aux questions posées par les équipes offshore et qu’il valide les documents fonctionnels.

Servir d’interface entre les équipes techniques en offshore et le responsable technique du client

Avertir des dysfonctionnements de toutes sortes qui doivent être résolus (réseau local, commu-nications, obligations du prestataire non respectées, etc.).

Maintenir à jour son équipe sur la vie de l’entreprise, les priorités, etc.



147

Le chef de projet doit sans doute se rendre en offshore entre une fois par mois et une foispar an, selon les tâches à réaliser et les problèmes à traiter. Il est accompagné le caséchéant de responsables fonctionnels, d’architectes ou d’autres spécialistes.

Sa motivation est essentielle. Lorsque le chef de projet aime travailler avec des personnesde différentes cultures, c’est un atout important pour le succès des opérations. Les profilsà éviter sont bien entendu les personnes opposées à l’utilisation de l’offshore, qui consi-dèrent que les personnes en offshore sont a priori moins compétentes.

Placer un représentant du client chez le prestataireUne décision très importante dès avant le commencement des développements concernela façon dont on souhaite gérer l’équipe en offshore. Naturellement, le client pense qu’ilobtiendra un meilleur contrôle en plaçant une personne à lui en offshore. Comme nousl’avons vu, cette personne envoyée dans le pays de l’offshore ne peut se substituer au chefde projet chez le client.

La fonction principale du chef de projet est de garantir la fluidité du travail en assurantune bonne communication entre le personnel en offshore et les personnes impliquées surle projet chez le client. Il est en quelque sorte l’avocat du prestataire chez le client. Unreprésentant du client chez le prestataire ne peut donc assurer ce rôle.

La décision de placer une personne chez le prestataire est avant tout motivée par la sécu-rité. Elle vise à vérifier la façon dont les directives sont appliquées et à contrôler ladiscipline locale.

Comme expliqué au chapitre 4, on recherche avant tout une relation de confiance et detransparence avec le prestataire. Tous les collaborateurs du client qui souhaitent tra-vailler avec des équipes en offshore se tournent naturellement vers le chef de projet quele client a envoyé sur place. Les équipes en offshore se trouvent totalement masquées parcelui-ci, qui est le seul point de contact des collaborateurs du client. Comme il n’y a plusde communications directes entre les collaborateurs du client et les équipes en offshore,le risque est de déresponsabiliser le prestataire, puisqu’un représentant du client a pourmission de suivre les opérations et de prendre les décisions. Se sentant moins exposé, leprestataire propose moins volontiers de faire des efforts pour atteindre certains objectifsou pour faire intervenir ses spécialistes sur les sujets complexes.

Pour toutes ces raisons, on trouve peu de chefs de projet des clients en permanence chezles prestataires en offshore, sauf dans les filiales ou les joint-ventures. Par contre, il esttoujours très efficace que les chefs de projet effectuent des séjours de quelques jours àune semaine chez le prestataire pour suivre les projets. De façon symétrique, la venue decertains membres de l’équipe offshore chez le client, pour suivre une formation, parexemple, est efficace et peut être perçue comme une récompense.

Si toutefois le client décide d’envoyer une personne sur place en permanence, il faut quecette dernière soit bien choisie. Il convient d’éviter autant que possible l’effet d’écran surles opérations en offshore. L’envoyé du client doit non pas s’impliquer directement dansla gestion de projet, mais se concentrer sur le suivi méthodologique et l’application desrègles de sécurité. Il faut en outre évidemment qu’il soit prêt à s’expatrier.

Ce rôle de représentant du client exige de grandes capacités de communication. Aprèsquelques mois sur place, celui qui en a la charge risque de se sentir absorbé par l’équipedistante et d’en devenir un membre à part entière. Il doit donc rester vigilant et êtrecapable en toutes circonstances de faire appliquer les procédures. Il doit en outre avoir



148

une pratique affirmée des développements informatiques afin d’être à même de prendredes décisions bénéfiques au projet.

EN RÉSUMÉLe représentant du client en offshore

Envoyer un représentant chez le prestataire risque de masquer les opérations en offshore et deréduire la transparence recherchée. En cas de décision en ce sens, le choix de la personne pour ceposte doit être effectué avec soin afin d’éviter cet effet d’écran et d’être vraiment utile chez le pres-tataire.

Se faire accompagner pour démarrer l’offshoreCertains consultants expérimentés sur l’offshore peuvent aider à monter les équipes quiconviennent. Beaucoup de ces consultants font partie de sociétés qui représentent elles-mêmes des prestataires en offshore. Choisir un de ces conseils revient le plus souvent àchoisir le prestataire et le pays avec lesquels on va travailler.

Certains consultants ne représentent pas un prestataire en offshore mais mettent à dispo-sition leur expertise afin de donner au client de meilleures chances de succès, dès sespremières réalisations. L’expérience qu’ils apportent permet de monter rapidement deséquipes compétentes. Ils peuvent de surcroît garantir un prix convenable des prestationsoffshore en aidant le client non seulement à estimer précisément le budget de ses opéra-tions, mais aussi à faire les choix adéquats, que cela concerne le chef de projet, l’organi-sation ou le suivi de projet.

Certains consultants peuvent intervenir dans la durée pour assurer le suivi d’un projet etcorriger les procédures afin qu’elles s’adaptent à l’esprit du client et aux types de projetsqu’il souhaite réaliser.

EN RÉSUMÉLe conseil à l’offshore

Un consultant offshore permet au client de bénéficier d’années d’expérience dans ce domaine.Certains consultants ne sont pas liés à un prestataire et peuvent aider à le choisir. Ils peuvent enoutre se révéler utiles pour la gestion du projet dans la durée.

Méthodologie et procédures

La définition du cadre méthodologique et des procédures que l’on veut mettre en œuvreest une décision structurante pour le reste des opérations en offshore. Certaines sociétés,comme IBM Rational, proposent des cadres méthodologiques exhaustifs.

Les cadres méthodologiques dont dispose le client sont rarement arrêtés et figés avecsuffisamment de soin pour pouvoir être exportés facilement. Les objectifs pour lesquelsils sont conçus se limitent le plus souvent à assurer une certaine formalisation de laproduction d’une équipe locale de développement fonctionnant correctement.

S’il est toujours possible de laisser le prestataire proposer la méthodologie qu’il maîtrise,le risque pour le client est de ne pas se sentir à l’aise avec l’approche proposée. Je recom-mande plutôt pour ma part d’utiliser les méthodologies éprouvées du marché, comme



149

RUP (Rational Unified Process), XP (eXtreme Programming) et quelques autres, qui offrentl’avantage d’être immédiatement documentées, complètes et disponibles.

Les approches itératives plutôt qu’en « V » sont généralement bien adaptées au travail avecl’offshore. Ces méthodologies ne doivent toutefois pas être adoptées en bloc. Il est préfé-rable de les adapter à l’esprit et aux souhaits du client. Le travail d’adaptation de la métho-dologie peut être réparti entre le client et le prestataire lorsqu’il s’agit de modifications àformaliser.

Le recours à une méthodologie standard permet de nourrir sa mise en œuvre d’articles,de forums et d’outils innombrables. Il peut en outre être utile de se faire accompagner parun consultant expérimenté, qui aidera à se concentrer sur les éléments réellementimportants.

EN RÉSUMÉAdoption d’une méthodologie standard

Il est recommandé d’adopter une méthode standard, le plus souvent RUP ou XP, afin de disposerimmédiatement d’une documentation complète et cohérente à adapter au projet et à la culture del’entreprise.

On peut aussi choisir de ne pas utiliser de méthodologie formelle. On se concentre en cecas sur certains éléments de reporting ou certains principes que l’on applique en dehorsde tout cadre strict. On adopte en ce cas une attitude essentiellement réactive pourcorriger chaque problème lorsqu’il se pose.

Le choix de la méthodologie et des procédures est une décision essentielle. Elle influencedirectement le choix du prestataire et les premières actions à entreprendre lorsquel’équipe est créée. Certains prestataires ne sont pas suffisamment stricts pour travailleravec des méthodologies ou ne veulent appliquer d’autres procédures que les leurs.


Avant de se lancer dans un projet en offshore, il est nécessaire d’évaluer les formationsqui seront nécessaires pour démarrer le projet correctement.

Le tableau 7.6 donne un ordre d’idée des formations et conseils qui peuvent être envi-sagés avant le démarrage d’un projet.

Tableau 7.6. Formations et conseil à l’offshore

Domaine Commentaire Lieu Formateur/consultant Utilisateur

Formation Formation fonctionnelle sur le domaine traité. Des rappels peuvent être nécessaires par la suite.

Offshore Responsable fonction-nel

Chefs de projet,développeurs, testeurs

Formations techniques dans le cas où l’on utilise des fonda-tions techniques existantes.

Local ou offshore

Responsable technique Équipe technique



150

Cet accompagnement doit être défini avant de commencer à monter les équipes enoffshore afin d’organiser au plus tôt les formations. Celles qui auront lieu chez le presta-taire peuvent prendre du temps si un visa est nécessaire et si des supports de formationdoivent être envoyés sur place.


Le choix des outils de suivi de projet est également à engager avant le commencement duprojet. Pour les projets importants, ces outils conditionnent souvent le succès des opéra-tions.

Les deux outils les plus importants sont la gestion de référentiel et la gestion des anoma-lies et du changement. Les anomalies sont les points du développement qui ne sont pasconformes aux spécifications. Le changement correspond aux modifications des spécifi-cations non conformes aux attentes des utilisateurs.

Chez certains éditeurs, les outils de gestion des anomalies et du changement sont parfoisséparés en deux produits. Le gestionnaire de version marque les différentes versions,tandis que le gestionnaire du changement note quels changements sont réalisés pourpasser d’une version à une autre. Chez IBM Rational, une option de ClearCase (gestion de

Domaine Commentaire Lieu Formateur/consultant Utilisateur

Formation(suite)

Méthodes et procédures, si l’on met en place une méthode du marché.

Local et offshore

Formateur extérieur Sélection des équipes locales et en offshore

Méthodes et procédures, si l’on met en place la méthode interne du client de l’offshore.

Offshore Responsable méthodes Sélection de l’équipe en offshore

Conseil Démarrage de l’offshore et accompagnement à la mise en place

Local Consultant extérieur Chefs de projet du client

Mise en place de la méthodo-logie

Local et offshore

Consultant extérieur Sélection des équi-pes locales et en offshore

Mise en place de l’offshore Local et offshore

Consultant extérieur Tous

Formation des chefs de projet du client de l’offshore

Local Consultant extérieur Chefs de projet du client de l’offshore

Suivi du projet Local et offshore

Consultant extérieur Tous

Tableau 7.6. Formations et conseil à l’offshore(suite)



151

la configuration) permet la synchronisation à travers plusieurs sites (ClearCase Multisite).Cette fonctionnalité est particulièrement utile pour assurer la réplication des informa-tions.

Ces outils représentent un investissement non négligeable. Certains modes d’utilisationpermettent de réduire le coût des licences, mais au prix d’une perte de finesse des infor-mations. Par exemple, au lieu de disposer de licences individuelles, on peut souscrire deslicences de groupe, mais en perdant au passage l’information sur l’individu qui a réaliséune action pour ne tracer que son groupe.

Les outils de test, qui permettent d’automatiser les tests et plans de test, sont égalementtrès utiles. D’autres outils, comme ceux de gestion des exigences, permettent de suivreles exigences d’un produit, de garder les liens avec les livrables qui en découlent et de leurdonner des priorités de réalisation. On trouve enfin des outils relatifs à la modélisation età d’autres domaines, comme la couverture de test sur le code source, la documen tation, etc.

Lors de cette phase d’évaluation du projet, il s’agit de déterminer si l’on utilisera tout oupartie de ces outils et de définir globalement le budget nécessaire. Si l’on n’utilise pasdéjà ces outils en local, l’assistance d’un consultant technique peut se révéler nécessaire.

Conclusion

À partir des réponses apportées aux questions posées dans ce chapitre, on peut faire uneévaluation assez complète du projet que l’on souhaite gérer en offshore. On ne cherchepas encore à déterminer tous les détails de ces choix, mais on sait répondre aux questionsles plus importantes et communiquer sur ce que l’on souhaite réaliser en offshore.

À ce stade, on a identifié le projet que l’on souhaite réaliser et défini ses objectifs ainsique les conditions de sa réalisation. On a de surcroît un ordre de grandeur des dépenseset des sujets sur lesquels on investira pour travailler efficacement avec le prestataire. Lemanagement de la société peut dès lors se prononcer en toute connaissance de cause surla décision d’outsourcer le développement en offshore.

Certaines questions posées dans ce chapitre sont primordiales pour jauger les chancesde succès des développements en offshore. Si l’on n’est pas capable d’y répondre, celadonne une idée de l’embarras dans lequel les équipes chez le prestataire ou chez le clientse trouveraient lors de la réalisation du projet. Par exemple, si l’achat d’un outil de gestionde référentiel est refusé alors que les objectifs de sécurité sont élevés, les chefs de projetse trouveraient à devoir atteindre des objectifs sans disposer des moyens nécessaires etdéclareraient rapidement la mission impossible à réaliser.

Une feuille Excel fournie en annexe reprend l’essentiel des questions posées dans cechapitre afin d’évaluer le projet à réaliser. Ses entrées et pondérations peuvent êtrecomplétées ou modifiées en fonction des souhaits du client et de la réalité du projet.


153

Chapitre 8

Choisir le prestataire et les équipes offshore

La proximité, la culture, la taille et le profil du prestataire déterminent directement lemode de fonctionnement que l’on peut mettre en place avec l’offshore, forfait ou régie,ainsi que le type de suivi des opérations, la fréquence possible des déplacements, etc.En choisissant un prestataire, le client adopte aussi un peu sa culture. Il suit les événementspolitiques et économiques du pays, et les membres de son personnel qui travaillent avecle prestataire nouent des amitiés parfois durables avec les collaborateurs en offshore.Le choix du prestataire s’accompagne souvent d’a priori. Le management du client associeà tort ou à raison à chaque pays et à chaque culture des qualités et des défauts quiinfluencent ses décisions. Par exemple, si le pays a la réputation de ne pas respecter lapropriété intellectuelle, le client mettra en place des règles de sécurité très strictes, et, s’ilest réputé avoir un faible niveau d’éducation, il s’organisera pour concentrer les tâchescomplexes en local et ne laisser à l’offshore que les tâches plus faciles.Parfois, le client fait le choix du pays parce qu’un de ses collaborateurs y connaît un pres-tataire et qu’il mise sur cette affinité personnelle, voire sur l’engagement du collabora-teur, plutôt que sur un choix réfléchi. Parfois, le choix se porte sur l’Inde du fait de sanotoriété comme pays de l’offshore sans même envisager d’autres possibilités, de la mêm efaçon que l’on choisit une marque sur sa réputation.Dans certains cas, le client recherche le prestataire ayant les meilleures compétencesdans un domaine très précis. Il peut, par exemple, privilégier un prestataire qui fournit desdéveloppements à un éditeur de logiciels dont le client utilise les progiciels. Le fait d’avoirun interlocuteur qui connaît parfaitement les progiciels autour desquels il réalise desdéveloppements spécifiques offre probablement d’excellentes compétences. Dans d’autrescas, le client recherche des services ciblés, comme la création de scénarios de dessinsanimés accompagnant des jeux.Certains prestataires sont spécialisés dans des domaines fonctionnels pointus, commeles applications pour les opérateurs de télécommunications ou les développements rela-tifs aux effets spéciaux pour le cinéma. Le choix du prestataire est dans ces cas gouvernépar son profil, et il se peut qu’un seul prestataire réponde aux critères définis.Dans tous les cas, il convient de sérier les critères de choix. On se concentre d’abord surle pays et la ville du prestataire puis sur le prestataire lui-même et enfin sur la constitu-tion des équipes. Cette dernière étape étant directement liée au choix du partenaire, lavalidation du partenariat tient compte également de la mise à disposition des premiersmembres de l’équipe et de la façon de l’assembler.



154

Critères de choix du prestataire en offshore

Avant de choisir son prestataire, il importe de se poser les bonnes questions quant auxtypes de projet que l’on souhaite confier à l’offshore, au mode de fonctionnement àmettre en place, etc. Presque toutes les réponses à ces questions sont décisives pourpouvoir choisir efficacement le prestataire.

À ce stade, on liste les éléments à prendre en compte en prenant soin d’éviter toute idéepréconçue. Les critères à soupeser attentivement sont récapitulés au tableau 8.1.

Tableau 8.1. Critères de choix du prestataire offshore

Critère Commentaire

Affinité pour certains pays

On peut indiquer que l’on préférerait travailler avec certains pays plutôt que d’autres. Il peut y avoir des questions relatives à des éléments culturels, religieux ou simplement géographiques.

Exclusion de pays présentant des risques pour certains clients de la société. Par exemple, des managers peuvent souhaiter éviter des tensions entre pays arabes et Israël.

Relations particulières avec un pays donné du fait, par exemple, de l’origine du manager de la société

Communication et voyage

Décalage horaire maximal acceptable pour que l’on puisse travailler en phase avec le presta-taire. Le travail est toujours beaucoup plus efficace dans les pays à faible décalage horaire.

Temps nécessaire pour se rendre sur place. Si le pays est proche, il est possible de réaliser de courts voyages pour résoudre des problèmes urgents. Moins fatigués, les voyageurs sont de surcroît plus efficaces.

Nécessité de disposer de visas pour se rendre sur place pour des citoyens du pays du client mais aussi pour d’autres nationalités présentes dans la société (Algérie, Tunisie, Maroc, États-Unis, etc.)

Risque que le pays soit dangereux pour les déplacements des chefs de projet et qu’ils ne souhaitent pas se rendre sur place.

Équipe Capacité à créer une équipe de la taille souhaitée dans le futur. On essaiera de donner des ordres de grandeur de l’équipe à créer et de celle que l’on souhaite dans le futur.

Possibilité de créer une équipe isolée et flexibilité de la façon de la monter

Autre critère Capacité à travailler en français. Cela restreint les pays candidats au Maghreb, au Liban et, dans une moindre mesure, à la Roumanie et à l’Île Maurice.

Capacité à appliquer la méthodologie souhaitée

Capacité à travailler en régie

Volonté de choisir un pays dont on estime qu’il demeurera longtemps un pays d’offshore.


Chapitre 8 – Choisir le prestataire et les équipes offshore

155

Le critère de la langue est évidemment déterminant si l’on choisit de travailler exclusive-ment en français ou dans une autre langue que l’anglais avec l’équipe offshore. Le choixdu prestataire se restreint immédiatement, tandis que le tarif des prestations est plusélevé que dans certains pays qui travaillent essentiellement en anglais.

La distance en avion est un autre critère important. Si l’on souhaite se rendre dans la villedu prestataire en moins de quatre heures et que l’on veuille au moins un vol par jour, lechoix est évidemment plus limité. Si l’on souhaite de surcroît des communications prati-ques, cela réduit le choix aux métropoles où l’on trouve des aéroports internationaux, lesvilles secondaires ou universitaires se trouvant le plus souvent exclues.

Localisation du prestataire

Le choix du pays fait habituellement l’objet de longs débats, tant les intervenants chez leclient ont des idées bien arrêtées sur la question. Ce choix est influencé par de nombreuxéléments, qui mêlent considérations professionnelles, personnelles et idées reçues.

Certains anticipent leur voyage dans le pays et retiennent des critères tels que l’enso-leillement, la proximité de la mer ou des sites agréables à valeur touristique. À l’inverse,d’autres ne veulent pas être accusés de privilégier le tourisme et optent pour des paysfroids, réputés travailleurs.

La sécurité dans le pays et les événements géopolitiques influencent fortement les choix.Les appartenances ethniques jouent aussi un rôle, un manager originaire d’un pays del’offshore affichant, par exemple, souvent une préférence marquée pour ce pays, même sises racines y remontent à plusieurs générations.

Le choix d’un pays inadéquat est un fardeau que l’on traîne longtemps. Il peut nuire forte-ment à un projet, voire le faire échouer. La mentalité du pays, les affinités culturelles éven-tuelles avec celui du client et la qualité des managers du prestataire sont les principauxfacteurs de succès.

Décalage horaire et distance géographiqueLes critères les plus faciles à évaluer sont le décalage horaire et la durée du voyage.

La figure 8.1 illustre mieux qu’un long discours les distances relatives des pays de l’offshoreet l’éloignement de l’Inde, de l’Asie et de l’Île Maurice. La notion de nearshore y apparaîtavec évidence lorsque des clients européens travaillent avec des prestataires d’Europe del’Est.

Si l’on choisit un pays tel que le Vietnam ou la Chine, le décalage horaire peut à lui seulêtre une cause d’échec. Comment piloter une équipe qui travaille l’essentiel de son tempsalors qu’on ne travaille pas chez le client. Avec sept heures de plus qu’en France, la Chinen’offre pratiquement pas de recouvrement avec les heures de travail locales. Le Vietnam,avec huit heures de décalage, impose pratiquement de ne travailler que par échanged’e-mails et interdit tout chat et conversation téléphonique.

Même en Inde, tant prisée pour l’offshore, les quelque cinq heures de décalage horaireavec la France limitent les communications interactives à quelques heures par jour.



156

Figu

re 8

.1. P

ays

d’of

fsho

re e

t fus

eaux

hor

aire

s



157

Dans les pays d’Europe de l’Est et du Maghreb, au contraire, le décalage horaire varieentre zéro et deux heures, ce qui est peu perturbant pour un travail interactif au quotidien.

Le décalage horaire n’empêche pas toujours de bien travailler. L’Inde travaille assez effi-cacement avec les États-Unis malgré un décalage horaire de douze heures. Ce décalage atoutefois fortement influencé les modes de fonctionnement avec ce pays des clientsaméricains, qui choisissent presque toujours les développements au forfait. Dans cemode, le prestataire prend plus pleinement la responsabilité des réalisations locales etn’a pas besoin d’une interaction soutenue avec le client.

Le prestataire en offshore peut décider de travailler en horaires décalés afin d’assurer uncertain recouvrement avec le rythme de travail du client. Les prestataires d’Europe de l’Estcommencent souvent leur journée à midi, par exemple, afin d’assurer un recouvrementmaximal avec leurs clients.

Pour les clients d’Europe de l’Ouest, un grand nombre de pays d’Europe de l’Est offrentd’excellentes conditions à environ trois heures de vol de Paris. Ils disposent de bonnesuniversités, d’un très grand nombre d’informaticiens très qualifiés et pratiquent des tarifscompétitifs, qui ne sont challengés que par certains pays d’Asie, comme le Vietnam, laChine ou les Philippines.

Les pays d’Europe centrale, tels que la Roumanie, la Pologne, la République tchèque, laSlovaquie et la Bosnie, pratiquent des tarifs significativement plus élevés, probablementdu fait de leur rapprochement avec la Communauté économique européenne, lequelassure par ailleurs une plus grande sécurité pour la relation contractuelle, la stabilité poli-tique et les lois en vigueur.

Les pays du Maghreb et certains pays du Proche-Orient (Liban, Israël) offrent égalementdes décalages horaires faibles avec l’Europe de l’Ouest.

Pour une société française, l’Inde et l’Asie n’offrent pas des conditions idéales du fait deleur éloignement, du décalage horaire et des différences culturelles. Même l’Île Maurice,qui offre pourtant une ouverture sur le français comme langue de travail, est peu attractivepar rapport aux pays proches, même si cette destination hautement touristique a d’autresatouts à faire valoir.

Le tableau 8.2 (au verso) recense les décalages horaires, distances, temps de vol, niveauxde coûts et langues de travail des principales destinations d’offshore. On peut y constaterque de nombreux pays offrent une grande proximité avec la France.

D’autres questions doivent évidemment être prises en compte, comme le service de trans-port aérien entre le pays du client et le site en offshore. La capitale est souvent beaucoupmieux desservie que les villes de province, qui nécessitent le plus souvent non seulementun changement d’avion, mais aussi d’aéroport, voire dans certains cas de se rendre surplace en train. La fréquence des vols est un autre élément discriminant pour juger de lafacilité d’accès du site, notamment pour les séjours de courte durée.

Il va de soi que certaines destinations sont beaucoup plus attirantes que d’autres. L’ÎleMaurice, par exemple, est une destination touristique bien connue, qui éveillera toujoursplus d’intérêt que Minsk ou Tallin. Favoriser l’aspect touristique peut toutefois seretourner contre le décideur chez le client. Pour peu que les réalisations en offshoreconnaissent des difficultés, il risque de se voir reprocher d’avoir fait le choix du soleilplutôt que de la productivité. À l’inverse, personne ne songera à critiquer le choix d’unpays froid, à l’attrait touristique limité, où le but des visites ne peut être que profes-sionnel.



158

Si les sociétés américaines avaient eu la chance de disposer de pays d’offshore à troisheures de leurs centres de décision nationaux, on peut être certain qu’elles n’auraient pashésité à leur confier leurs développements en offshore. Cette chance, nous l’avons enEurope avec les pays de l’Est et du Maghreb, et nous aurions tort de ne pas la saisir.

EN RÉSUMÉProximité et décalage horaire

Les pays de l’offshore présentent une très grande diversité quant à la distance qui sépare le client duprestataire. Dans la mesure du possible, on a intérêt à choisir un partenaire dans un pays proche,bien desservi par des liaisons aériennes, ayant un faible décalage horaire, et dont la culture est facileà appréhender par les collaborateurs du client. Cela permet de travailler plus efficacement en moderégie. L’éloignement, qui rend le contrôle des équipes distantes plus difficile, favorise naturellementun fonctionnement au forfait.

La culture du paysLe choix du pays implique que l’on va vivre avec sa culture et ses habitudes. Il faut consi-dérer ici la culture sous plusieurs aspects : quelle sera son influence sur la façon detravailler du prestataire, sur les collaborateurs du client qui se rendront sur place etsur les collaborateurs du prestataire que l’on invitera pour des formations ou desdéploiements ?

Tableau 8.2. Pays d’offshore et décalage horaire avec Paris

PaysDécalage horaire**

DistanceTemps de vol *

Niveau de coût

Langue de travail

Belarus (Minsk) 1 h 00 1 831 km 2 h 40 1-2 Anglais

Ukraine (Kiev) 1 h 00 2 026 km 3 h 00 1-2 Anglais

Roumanie (Bucarest) 1 h 00 1 876 km 2 h 30 2-3 Anglais, français

Bulgarie (Sofia) 1 h 00 1 752 km 2 h 20 2-3 Anglais

Inde (Bangalore) 4 h 30 7 837 km 9 h 30 2-3 Anglais

Maroc (Rabat) – 1 h 00 1 830 km 2 h 40 2-3 Français

Tunisie (Tunis) 0 h 00 1 487 km 2 h 00 2-3 Français

Algérie (Alger) 0 h 00 1 370 km 1 h 50 2-3 Français

Île Maurice 3 h 00 9 440 km 11 h 00 2-3 Anglais, français

Chine (Shanghai) 7 h 00 9 230 km 11 h 00 1 Anglais

Russie (Moscou) 2 h 00 2 480 km 2 h 15 2-3 Anglais

Russie (Saint-Pétersbourg) 2 h 00 2 131 km 2 h 45 2-3 Anglais

Russie (Novossibirsk) 5 h 00 6 211 km 6 h 30 1-2 Anglais

Liban (Beyrouth) 1 h 00 3 185 km 4 h 00 3 Anglais

Philippines (Manille) 7 h 00 10 740 km 15 h 00 1 Anglais

Vietnam (Hanoï) 6 h 00 9 205 km 11 h 20 1 Anglais, français

* Temps de vol direct, même s’il n’existe pas de vol direct.** Certains décalages horaires varient dans l’année selon les heures d’été et d’hiver. Ces dernières ne sont pas pra-tiquées dans tous les pays et, lorsqu’elles sont appliquées, ne sont pas toujours déclenchées aux mêmes dates.



159

On s’intéressera d’abord à la facilité de compréhension réciproque des personnes quidoivent travailler ensemble et à l’efficacité que l’on peut imaginer en obtenir. Faute decela, la distance culturelle a toute chance de jouer un rôle de frein à l’efficacité de la rela-tion. La lisibilité des collaborateurs en offshore et la proximité culturelle avec eux sontdes atouts évidents. Les collaborateurs du client ont généralement peu travaillé avecl’étranger, et les rares contacts professionnels qu’ils ont eus étaient certainement avecdes Nord-Américains ou des Européens de pays limitrophes. Il est très improbable quetous les chefs de projet se sentent à l’aise avec des collaborateurs d’une autre culture.

Les pays d’Europe de l’Est et du Maghreb sont globalement culturellement proches de laFrance. Les Anglais trouvent pour leur part une affinité culturelle certaine avec l’Inde dufait de leur passé colonial dans ce pays. Si l’on a le choix, il vaut toujours mieux retenirdes cultures proches.

Les déplacements en offshoreComme expliqué précédemment, la facilité à organiser les déplacements en offshoreentre en ligne de compte dans les critères de choix du pays du prestataire. Il faut que lespersonnes appelées à se rendre sur place n’aient pas de problèmes particuliers pouraccepter ces déplacements.

Si la localisation du partenaire en offshore est agréable et ensoleillée, le collaborateurappréhendera sans doute ce voyage avec plaisir, surtout lors des premiers voyages, quiauront une dimension de découverte. La répétition des séjours devient cependant vitepesante et peut mener à un rejet si la durée de vol est importante.

L’orientation politique et sociale de certains pays peut susciter le refus de certains colla-borateurs de se rendre chez le prestataire, surtout si l’on y constate une intolérance auxreligions ou des attitudes racistes.

La facilité à obtenir des visas, que l’on parle du collaborateur du prestataire ou du client,est un autre facteur à prendre en compte. En règle générale, l’obtention de visas pour desdéplacements professionnels ne soulève pas vraiment de difficulté, sauf exception.

La sécurité dans le pays du prestataire joue aussi un rôle, notamment dans les pays régu-lièrement soumis à des menaces terroristes ou qui présentent un fort désordre social. Ilest probable que durant les périodes où la sécurité est réduite, les chefs de projet refuse-ront de se rendre sur place. Même s’il est impossible de prédire comment les événementsvont évoluer dans chaque pays, certaines destinations demeurent plus exposées qued’autres.

Inviter les collaborateurs de l’offshoreIl n’est pas inutile d’évaluer les conditions dans lesquelles un client peut inviter desmembres des équipes du prestataire offshore.

Les pays de l’offshore qui se situent dans la Communauté européenne ont la capacitéd’envoyer plus facilement des collaborateurs chez le client que les pays qui ont la répu-tation d’être des foyers de main-d’œuvre illégale. Les procédures pour faire venir cescollaborateurs sont plus simples et ont plus de chances de succès.

Un collaborateur de l’offshore peut avoir du mal à s’habituer à vivre, ne serait-ce que quel-ques mois, dans le pays du client. Par exemple, certains collaborateurs en offshorepeuvent bénéficier dans leur pays d’une assistance permanente pour le ménage, lacuisine, etc., et se trouver perdus dans le pays du client sans cette assistance. Ce type



160

d’habitude culturelle est évidemment impossible à généraliser, tant les modes de viepeuvent différer d’une personne à une autre d’un même pays.

En règle générale, les collaborateurs de l’offshore obtiennent des visas sans difficulté, quece soit pour des formations ou pour accompagner leurs livraisons. Les services de l’immi-gration veulent avant tout éviter que les informaticiens invités ne viennent remplacer desemployés du client. Ils comprennent que certaines réalisations distantes doivent êtreaccompagnées ou que des formations soient nécessaires lors de collaborations avec unpartenaire distant.

Ce qu’ils interdisent c’est que les sociétés qui emploient localement des collaborateursde l’offshore payent des salaires sans commune mesure avec les usages locaux ou, pireencore, qu’elles facturent à leurs propres clients des services réalisés avec une main-d’œuvre illégale.

La langue de travailLes clients français de l’offshore privilégient généralement les pays où l’on parle leurlangue. Les seuls pays d’offshore vraiment francophones sont les pays du Maghreb et leLiban. Ailleurs, il est toujours possible de monter des équipes francophones, puisque lefrançais est très répandu comme seconde langue vivante, mais ce critère de sélectionlimite grandement les embauches (Roumanie, Île Maurice, Vietnam). Dans ces pays,l’anglais prend d’ailleurs le dessus à l’école, et le français n’est plus la langue de prédilectiondes jeunes ingénieurs.

Il faut aussi considérer que le Maghreb, le Liban et la Roumanie sont des pays chers pourl’offshore en comparaison de certains pays d’Europe de l’Est. Le prix des prestations sesitue le plus souvent autour de 3 000 euros par mois, voire davantage, alors que dansd’autres pays on descend à 1 800 ou 2 200 euros par mois pour des profils excellents.

La question de l’anglais comme langue de travail pour un client francophone ne doit pasêtre surestimée. La plupart des Français ayant un anglais scolaire sont capables detravailler efficacement avec l’offshore. Les communications sont le plus souvent écrites(messages et chats), et les fautes d’anglais sont de toute façon partagées des deux côtés.Le travail est finalement efficace, car chacun utilise des phrases simples et concises.L’important est d’exiger que tous les collaborateurs du prestataire en offshore aient unniveau minimal d’anglais, mesuré par des tests, comme ceux proposés par BrainBench(www.brainbench.com).

Chez de nombreux clients de l’offshore, on trouve une forte volonté d’internationalisa-tion, qui passe par l’adoption de l’anglais. L’offshore peut tout à fait s’inscrire dans cettetendance et être un motif supplémentaire pour adopter l’anglais comme langue de travail.

Le fait que l’anglais soit la langue de travail n’impose pas que tous les documents fournisà l’offshore soient rédigés en anglais. Les documents en français ou dans une autre languepeuvent être facilement traduits en anglais et exploités sans problème par le prestataire.

EN RÉSUMÉImportance de la langue de travail

Mieux vaut rester le plus ouvert possible et travailler en anglais, sauf si le français est incontournablechez le client. La plupart des pays de l’offshore utilisent l’anglais comme langue de travail principale. Letravail en anglais peut être tout à fait efficace, même lorsque les collaborateurs locaux ne le maîtrisentque de façon approximative. En choisissant l’anglais comme langue de travail, on peut travailler avecpratiquement tous les pays de l’offshore et obtenir ainsi des prestations aux meilleurs tarifs.




161

Le système éducatif en offshoreLa qualité des universités et le nombre de diplômés sont essentiels pour choisir le paysoù l’on souhaite trouver son prestataire.

S’il est bien délicat de comparer des villes universitaires de pays différents, la taille et ledynamisme des universités techniques en offshore peuvent être mis en balance. On peutconnaître le nombre de diplômés pour chaque université, repérer les équivalences avecdes universités étrangères (qui sont rares), déterminer quelles sont les universités lesplus désirables, etc. La réputation locale de certaines universités peut aussi donner uneidée de leur qualité. On pourra confirmer cette estimation par l’évaluation des personnesrencontrées au cours des entretiens.

Les villes, et parfois même les pays, qui ne possèdent pas une quantité suffisante dejeunes diplômés peuvent être incapables de fournir les ressources et compétences que l’onrecherche. En contrepartie, on y trouve souvent la possibilité de constituer des équipes àdes tarifs beaucoup plus bas.

EN RÉSUMÉLes villes universitairesIl est fortement recommandé de travailler dans la capitale ou dans les grandes villes étudiantes où l’on ades chances de trouver de meilleures ressources en quantité suffisante. Les villes secondaires peuventrapidement poser des problèmes d’embauche si l’on doit constituer des équipes rapidement.

L’offshore dans la duréeDans certains pays qui offrent aujourd’hui des conditions intéressantes pour l’offshore,on sent bien que l’essor économique est tel que les différences de salaires se réduirontrapidement au point de rendre caduques les possibilités d’économies.

Cette évolution prend toutefois bien plus de temps qu’on ne le croit généralement. Despays tels que la Pologne, la République tchèque, la Hongrie et la Roumanie ont été consi-dérés un peu rapidement comme des pays qui n’offriraient bientôt plus de réel intérêtpour l’offshore. Bien que plus chers que d’autres pays, ils ont tout de même préservé leurstatut de pays d’offshore, et il est peu probable que cette situation change brutalementdans les années qui viennent.

Les pays qui sont entrés ou qui vont entrer dans la Communauté économique euro-péenne seront probablement plus rapidement en phase avec le reste de l’Europe occiden-tale, puisqu’ils bénéficient de conditions économiques plus favorables et ont démontréune certaine maîtrise de leur économie locale. D’autres pays présentent peu de signes decroissance économique véritable et restent essentiellement repliés sur eux-mêmes,comme le Belarus.

L’Inde connaît un immense succès de ses services de développement. Les grands cabi-nets d’analyse de marché prévoient un triplement des salaires des informaticiens dans lesannées à venir, ce qui ne manquera pas d’être répercuté sur les tarifs des prestatairesoffshore. Il faut en tenir compte si l’on recherche un prestataire offshore stable.

Deux prestataires en offshoreDans certains cas, on peut vouloir monter deux équipes en offshore chez deux prestatairesdifférents dans deux pays différents (voir le chapitre 7). Cela peut se révéler utile si l’un despays vient à traverser une période de troubles.



162

Pour basculer les projets d’un site sur l’autre, il faut utiliser une même méthodologie et demêmes procédures sur les deux sites. Il faut en outre mettre en place des instruments métho-dologiques et des outils permettant de contraindre la bonne application des procédures.Il est recommandé de choisir les sites dans deux villes peu éloignées, afin de faciliter lesvoyages de l’une à l’autre. Par exemple, si l’on retient des pays d’Europe de l’Est, on peutchoisir Kiev (Ukraine) et Minsk (Russie), qui ne sont éloignés que de 575 km ou bien Bucarest(Roumanie) et Kiev.On peut décider de ne pas attribuer une part égale de travail aux deux prestataires, l’unétant utilisé comme prestataire principal, l’autre faisant clairement office de prestatairede repli, recevant des tâches plus légères afin de le familiariser avec les procédures, laméthodologie et le formalisme retenus si le client devait décider de basculer le projet surcelui-ci. Cela permet de ne pas perdre en efficacité lors de la gestion de projet tout enpréservant une solution de rechange immédiatement applicable.Certaines sociétés ont pour philosophie de ne pas donner la tierce maintenance applica-tive, ou TMA, au prestataire qui réalise la solution, afin de mieux garantir la qualité de ladocumentation et la maintenabilité du produit. On peut aussi appliquer ce principe enoffshore en choisissant deux prestataires, l’un réalisant la création de la solution, l’autrela TMA. Durant la phase de réalisation, le prestataire devant assurer la TMA peut setrouver impliqué, comme dans le cas d’un prestataire de repli, si ce n’est que, dans ce cas,il prend à sa charge la TMA une fois la solution livrée.

Choisir le prestataire

Pour choisir efficacement son prestataire, il faut avoir défini au préalable le ou les paysavec lesquels on souhaite travailler. Le choix du partenaire est bien entendu déterminant.Avant d’engager le processus de sélection, il faut avoir décidé de la façon dont on sou-haite travailler, notamment au forfait ou en régie, car ce sujet doit être immédiatementabordé avec le prestataire.Selon la taille des projets que l’on souhaite confier à l’offshore et leur importance straté-gique pour la société, on peut effectuer la sélection du prestataire de façon plus ou moinsstructurée. L’effort de structuration de la sélection est cependant toujours préférable, carcela affiche clairement le professionnalisme du client.

La demande d’informations au prestataire offshoreQuels que soient les objectifs du client, il est souhaitable de les exposer dans un docu-ment, rassemblant ce que l’on souhaite réaliser et ce que l’on attend du prestataire.Appelé RFI (Request For Information), un tel document peut être ensuite ajouté enpréambule à l’accord de partenariat, afin de rappeler en cas de besoin les raisons de lasélection du prestataire.Le RFI met en lumière les conditions spécifiques de la prestation en mentionnant leséléments qui ne sont pas évidents à réaliser ou les désirs peu courants du client, commela mise en place d’une méthode ou de règles de sécurité strictes ou encore l’isolement del’équipe. Ce document doit être très synthétique et ne pas dépasser une vingtaine depages. Certains prestataires peuvent se révéler incapables de respecter certaines direc-tives du client ou ne pas souhaiter travailler ainsi. Il importe donc de recevoir desréponses écrites, qui évitent les interprétations.



163

Le tableau 8.3 récapitule les principaux sujets à traiter dans un RFI.

Tableau 8.3. Sujets traités dans le RFI envoyé au prestataire offshore

Sujet Commentaire

Objectifs en offshore

Exprime les désirs du client en offshore, sur le premier projet comme sur les projets futurs.Les points à mentionner sont :– La taille des équipes à court et long terme.– Les types de projets qui seront confiés au prestataire, etc.

Identité du prestataire

Concerne l’identité du prestataire, la taille de son entreprise, ses références, ses autres activités, s’il en a, ainsi que la répartition des employés et du chiffre d’affaires entre ces activités. Les points particuliers à demander sont :– Les liens particuliers avec d’autres sociétés clientes.– Les résultats du prestataire sur les dernières années (même si c’est une donnée peu significative dans ces pays).– Les actionnaires de la société.– Une copie traduite des statuts.– La façon dont la société souhaite être payée et, si le destinataire des paiements est une autre société, la nature des liens entre cette société et celle du prestataire.

Coût des prestations

On peut annoncer la somme sur laquelle on souhaite s’engager ou laisser le prestataire faire une proposition. Il est assez facile de voir sur Internet quels sont les prix couramment pratiqués dans le pays et demander des tarifs agressifs. Les points particuliers à aborder sont :– Le détail de ce qui est compris dans les prestations.– Le détail de ce qui sera facturé séparément, notamment les machines, serveurs, équipements réseau, téléphones, etc.

Collaborateurs Décrit le type de collaborateurs que l’on cherche à embaucher. Les points particuliers à aborder sont :– La recherche de rôles et de profils types (chefs de projet et d’équipe, responsables procédures, intégration, test, etc.).– La capacité des collaborateurs à parler anglais (ou français) et la façon de valider leur niveau.– L’obligation des collaborateurs à ne travailler que pour le client.– La présentation du noyau des équipes à constituer en offshore. Ce sujet fera sans doute partie des étapes de sélection du prestataire.

Formation Indique si l’on souhaite disposer de personnel formé à des sujets particuliers, voire dispo-ser de personnes ayant reçu des certifications (par exemple, sur des développements périphériques à un ERP ou à un progiciel du marché). Les points particuliers à aborder sont :– La façon dont le prestataire compte organiser ces formations.– Les dates auxquelles le personnel sera formé.– La façon dont la prise en charge des formations sera assurée.

Mode de fonctionnement

Présente le mode de travail attendu (régie/forfait) et les méthodes et les outils que l’on souhaite employer. Les points particuliers à aborder sont :– Les produits logiciels qui sont maîtrisés sur place.– Les licences disponibles et pour une utilisation par la société cliente.– Les documents de suivi que l’on souhaite obtenir.– Le contrôle exercé chez le prestataire.



164

Même dans le cas où l’on travaille avec un représentant local dans le pays du client, cedocument est important. Il sera utilisé de la même façon par ce représentant pour choisirle prestataire.

Si l’on n’a pas de raison de choisir a priori un partenaire plutôt qu’un autre, le RFI peut êtreenvoyé à plusieurs partenaires choisis en aveugle sur Internet afin de recueillir rapide-ment des réponses et de se faire une première opinion. La façon de répondre est souventsignificative, et l’on peut en tirer quantité d’informations sur le prestataire.

D’une façon générale, la mise au point de ce document est un excellent investissement,qui assoit plus fermement les bases du partenariat en démontrant le professionnalismedu client.

Les principaux éléments de choixCertains points du cahier des charges sont plutôt administratifs et n’ont que peud’influence sur le choix du prestataire, tandis que d’autres sont primordiaux. Ce sont cesderniers qui sont détaillés dans cette section.

À partir des réponses écrites au RFI, on choisit quelques partenaires potentiels que l’onira rencontrer sur place. Si la taille du projet ne justifie pas un déplacement, on peut orga-niser des conférences téléphoniques pour mener les entretiens.

La taille de la société

Le premier critère est sans doute la taille du prestataire, qui doit être en accord avec lesobjectifs du client. Il est peu probable qu’une société de vingt personnes puisse efficacementmonter une équipe de cinquante personnes.

À l’inverse, on peut craindre de ne pas être suffisamment considéré si l’on crée une équipede sept personnes dans une société comptant cinq mille employés et où la taille moyennedes équipes dépasse les cinquante personnes.

Sujet Commentaire

Management Concerne le type de contrôle que l’on souhaite avoir sur l’équipe, notamment sur la rému-nération, les bonus, l’organisation, la hiérarchie, etc. Ces sujets peuvent susciter des réticences importantes chez le prestataire.

Sécurité Expose la nature des informations disponibles sur place et le niveau de sécurité que l’on souhaite appliquer sur le site en offshore. Les points particuliers à aborder sont :– Les contrôles d’accès et autres éléments relatifs à la sécurité.– Les engagements personnels des collaborateurs de respecter les règles de confiden-tialité.

Déplacements et communication

Concerne les voyages de certains collaborateurs en France et la mobilité que l’on attend des ressources. La bande passante que l’on estime nécessaire est mentionnée.

Marketing Concerne la publicité que le prestataire souhaite faire de cette collaboration, en précisant s’il peut la rendre publique et de quelle façon.

Jeu d’essai de facturation

Consiste à demander au prestataire d’estimer les coûts totaux pour une équipe d’une taille donnée afin de déceler d’éventuelles facturations inattendues.

Tableau 8.3. Sujets traités dans le RFI envoyé au prestataire offshore(suite)



165

L’attitude de la sociétéLa façon dont le prestataire répond aux questions permet de détecter son état d’esprit.Certains prestataires se posent en donneurs de leçons, laissant présager qu’ils cherche-ront à imposer leur mode de travail. D’autres se présentent comme des champions de laméthodologie, révélant une certaine rigidité. D’autres encore cherchent avant tout à satis-faire le client en l’écoutant et en respectant ses directives.

Le statut de la sociétéLes sociétés qui ne sont pas officiellement constituées doivent être évitées. Les risques sontnon seulement que les opérations que l’on monte sur place se déroulent mal, mais aussi quele client soit accusé de divers délits liés à l’absence de statut juridique de leur prestataire.

En cas de société légale, il importe de bien comprendre comment les décisions sontprises dans la société et qui doit faire partie des négociations contractuelles. Si la sociétéa d’autres activités, il faut apprécier précisément la part qu’y occupent les développe-ments en offshore. Les autres activités peuvent être l’édition de logiciels ou des servicespour des entreprises locales.

La maturité du prestataire dans le domaine des développements logiciels offshore doitaussi être vérifiée.

Le noyau central des collaborateurs du projetIl est toujours difficile pour le prestataire de présenter les premiers collaborateurs quitravailleront avec le client. Ce dernier met toujours en avant des collaborateurs de qualité,mais il y a tout lieu de penser qu’ils sont occupés sur d’autres projets, dans lesquels ilsjouent des rôles importants.

Tout dépend en fait du nombre de collaborateurs que l’on souhaite rassembler à l’avenirchez le prestataire. Si l’on parle d’une équipe de quarante à soixante personnes, on peuts’attendre à être pris au sérieux et à recevoir des profils de candidats. En étudiant cesprofils, le client peut tirer beaucoup d’informations sur le prestataire. S’il s’agit de monterune équipe de dix collaborateurs, il est vraisemblable que le prestataire présentera unseul chef de projet et que l’enseignement à en tirer sera assez limité.

Le client cherchera ensuite à rencontrer de préférence les collaborateurs parmi lesmeilleurs du prestataire, qui travaillent avec lui depuis longtemps et qui sont imprégnésde la culture de la société. Il ne doit pas hésiter à leur poser beaucoup de questions surcette dernière. Les réponses à ces questions seront parfois plus enrichissantes que cellesau questionnaire adressé au prestataire.

Les deux caractéristiques importantes pour évaluer la société sont la franchise et la capa-cité de synthèse des personnes rencontrées. La franchise des collaborateurs imprégnésde la culture du prestataire permet d’anticiper la transparence de la relation future. Elleest assez facilement détectable à l’ouverture d’esprit des réponses et à la volonté de nepas cacher les points faibles.

L’esprit de synthèse est représentatif de la capacité à exposer des situations complexes,telles qu’elles se présentent en offshore. Le client peut y repérer l’autonomie laissée auxchefs de projet, car il existe une forte corrélation entre la profondeur des réponses deschefs de projet et l’autonomie qui leur est donnée.

Les autres critères d’évaluation des profils sont évidemment leurs qualités relationnelleset techniques. Comme nous le verrons, l’évaluation du personnel en offshore est une



166

tâche difficile, les repères habituels n’étant guère transposables. Par exemple, le CV quiest créé avec tant de soins dans les pays occidentaux est souvent assemblé quelquesminutes avant l’entretien dans les pays d’offshore. Nous abordons ce sujet en détail auchapitre 11, consacré à la gestion des ressources humaines en offshore.

Les coûts

On considère ici les coûts des prestations comme élément de choix du prestataire. Il estsurtout important de comprendre comment les coûts sont découpés, ce qui est comprisdans les tarifs par personne et ce qui est facturé en plus.

Il n’est pas toujours souhaitable de rechercher le coût le plus faible. Un bon partenariatdonne de bien meilleurs résultats si le contrat est profitable aux deux parties. Ces coûtspeuvent se situer dans la moyenne de ceux pratiqués localement. Plus l’équipe est impor-tante, plus les coûts doivent se rapprocher de la moyenne basse.

Le plus important à ce stade est d’être en mesure de comparer les coûts efficacement, carles prestataires n’incluent pas tous les mêmes prestations dans les coûts humains.

Le fait que les coûts varient énormément d’un prestataire à un autre crée un sentiment demalaise. On s’explique mal des écarts de 1 500 à plus de 3 000 euros par mois pour desservices comparables. Le tableau 8.4 permet de mieux comprendre ces différences de tarif.

Tableau 8.4. Éléments des coûts des prestations offshore

Sujet Commentaire

Coût facturé par personne

Demander le découpage des coûts par profil, afin de pouvoir disposer de coûts plus faibles pour les profils les moins qualifiés ou pour les étudiants qui travaillent pendant leurs dernières années d’études.

Vacances et maladies

Vérifier que l’on ne paie que les jours travaillés. Certains prestataires considèrent que le client doit payer certains jours de vacances comme des jours travaillés, ce qui augmente le prix de la journée travaillée. La facturation au jour travaillé est plus juste.

Facturation à l’heure

Se méfier du nombre d’heures travaillées dans une journée, car cela peut faire une grande différence si l’on a choisi une facturation à l’heure.

Prestations incluses

Bien souvent, les prestations incluses sont tout sauf claires. On trouve généralement le poste de travail du collaborateur (en espérant qu’il convienne), les locaux, l’électricité, une faible bande passante Internet et une utilisation modérée du téléphone. Il importe de savoir ce qui est inclus et ce qui ne l’est pas, ce qui n’est pas inclus risquant d’être refacturé. Dans un RFI, les prestataires ont intérêt à répondre dans le sens susceptible de plaire au client potentiel et à cacher les prestations refacturables.

Bande passante Internet

La bande passante dédiée est généralement facturée séparément. Celle-ci peut être très coûteuse dans certains pays (plus de 1 500 euros par mois). Pour avoir le contrat, le pres-tataire dit disposer d’une bande passante sur Internet mais cache son étroitesse.

Matériel Certains prestataires achètent le matériel de travail des collaborateurs, principalement les ordinateurs, selon les besoins exprimés par le client. Ils demandent alors généralement une durée minimale de contrat. D’autres refacturent tout le matériel qu’ils ont acquis au client. Il faut compter 75 à 200 euros de plus par personne et par mois lorsque tout le matériel est inclus.



167

Il faut être particulièrement vigilant à l’égard des coûts des prestations qui ne seraient pasmaintenus dans le temps. La plupart des prestataires sont capables de casser les prixpour obtenir l’affaire, voire de faire de premières réalisations à perte.

On peut considérer que le tarif minimal proposé au client est de l’ordre de deux fois etdemie le salaire local d’un collaborateur. Avec ce ratio, le prestataire génère une faiblemarge, voire des opérations à prix coûtant. Il est préférable de viser des prestations à uncoût supérieur à cette valeur. Si le collaborateur perçoit 600 dollars, le prestataire doitfacturer 1 500 dollars pour ne pas être perdant. Pour générer 25 % de marge, il doit proposerune tarification d’environ 2 000 dollars.

Les locaux

La qualité du lieu de travail n’est pas qu’une considération esthétique. On travaille mieux,et les résultats sont de meilleure qualité lorsqu’on dispose d’un environnement agréable.Dans les pays aux étés chauds, l’air conditionné est un atout important, que ce soit pourla productivité des hommes ou pour la protection du matériel. Dans les saisons froides,les salles de certains prestataires sont mal isolées, et il arrive que les collaborateurstravaillent emmitouflés dans de gros manteaux, près d’un chauffage individuel soufflantun air tiède.

Si l’on compte constituer une équipe importante, mieux vaut exiger des locaux d’unniveau de confort élevé, à la plus grande joie des collaborateurs.

Les références du prestataireLes références du prestataire et son mode de travail avec ses clients réclament une atten-tion particulière. Il ne faut pas hésiter à appeler certains de ces clients pour recueillir leurévaluation du prestataire.

Sujet Commentaire

Téléphone Le téléphone est souvent inclus mais limité au strict nécessaire.

Serveurs et réseau

Les serveurs ne sont pratiquement jamais inclus dans les prestations. Par contre, tant que le réseau n’est pas isolé, l’administration du réseau est généralement incluse.

Statut des collaborateurs

Le prestataire peut être réticent à aborder ce sujet, notamment si les salaires ne sont qu’en partie déclarés.

Mode de fonc-tionnement et taille de l’équipe

Les modes de fonctionnement au forfait sont souvent plus chers par personne. La taille du projet peut toutefois faire baisser le tarif des prestations.

Salaires des informaticiens

Il est utile de comparer les salaires des informaticiens du prestataire avec ceux des autres prestataires du pays afin de détecter d’éventuels écarts significatifs (en nature ou en avan-tages, notamment sous forme de congés payés).

Qualité des locaux

La qualité de l’environnement de travail peut expliquer des coûts plus élevés. Il faut compter entre 50 et 125 euros supplémentaires par mois et par personne pour des locaux de qualité.

Tableau 8.4. Éléments des coûts des prestations offshore(suite)



168

Le tableau 8.5 récapitule les principales questions à poser aux clients du prestataireconcernant les références de ce dernier.

Les références rapportées par ces clients se révéleront le plus souvent en accord avec ceque l’on constatera par la suite de soi-même.

Le contrat de partenariatLe choix du prestataire est officialisé par la signature de l’accord de partenariat (voir lechapitre 9).

La présentation du contrat à signer est une étape délicate car les accords dont on aconvenu oralement prennent une tout autre dimension une fois couchés sur le papier, surtoutlorsque des pénalités sont applicables dans certains cas et qu’on ne les a pas évoquéesen détail.

Il n’est pas rare que le contrat mette très longtemps à être signé et que le travailcommence bien avant sa signature définitive. Une fois le travail commencé, on tend àoublier le contrat, et certains clients de l’offshore travaillent pendant plusieurs années surun projet de contrat jamais signé et pourtant appliqué comme s’il l’avait été.

Relations avec le partenaireComme le terme partenariat l’indique, il est toujours préférable d’entretenir des relationstelles que le succès de l’un soit aussi le succès de l’autre. Un tel objectif n’est pas exagéréen offshore, où les bénéfices mutuels sont faciles à atteindre.

Lorsqu’une relation de confiance et de respect mutuels s’établit, des propositionsnouvelles apparaissent pour résoudre les problèmes. Le prestataire veut autant queson client trouver les meilleures solutions pour un travail toujours plus efficace. Uneconfiance mutuelle, affirmée par le temps, est la meilleure garantie d’une collaborationefficace.

Constitution des équipes

La constitution des équipes doit faire partie des premiers sujets abordés avec le presta-taire. Le plus souvent, le client demande à rencontrer les premiers collaborateurs qui

Tableau 8.5. Questions concernant les références du prestataire

Question Commentaire

Condition du projet mené avec le prestataire

– Quelle est la taille de leur projet ? Quelle est la taille de l’équipe ?– Est-il terminé ou toujours en cours ?– Est-ce un forfait, de la régie ou autre chose ?– Est-ce un succès ?

Défauts et faiblesses du prestataire

– Le client a-t-il dû faire face à des défauts ou faiblesses du prestataire ?– Lesquels ?



169

constitueront le noyau central. Lors de la signature du contrat, le prestataire offshore metimmédiatement à disposition certaines personnes clés pour constituer l’équipe. Ontrouve généralement le responsable de l’équipe en offshore et des chefs de projet (une ouplusieurs personnes), auxquels peut s’ajouter un architecte ou un responsable des procé-dures si l’équipe est importante.

L’équipe noyau comporte rarement plus de quatre à six personnes. Il faut être conscientde l’effort important consenti par le prestataire pour retirer ces éléments de qualitéd’autres projets, où ils jouaient un rôle important. Il s’agit d’un exercice délicat, car s’ildéshabille brutalement d’autres projets, il y a tout lieu de craindre qu’il ne fasse un jourde même avec le nouveau client.

L’organigramme de l’équipe projet est très important pour cadrer les demandes faites auprestataire offshore. Sans cet organigramme, le prestataire a tendance à présenter lescandidats immédiatement de façon à les facturer au plus tôt. La gestion de l’embauchedes collaborateurs ainsi que leur validation doivent être prévues dès le commencementde façon à éviter les mauvaises surprises.

Ces sujets sont abordés lors du choix du prestataire afin de valider son mode de recrutementet de gestion du personnel.

L’embauche des collaborateursIl est important que le client joue un rôle important dans le management du personnel,notamment au stade de la validation des embauches. Il lui revient de déterminer lesprofils recherchés et les caractéristiques de chaque membre du personnel.

Le client peut souhaiter que tous les collaborateurs en offshore parlent anglais de façon àpouvoir s’adresser à chacun d’eux sans intermédiaire. En le signalant immédiatement, celapeut se révéler une contrainte forte pour le prestataire, qu’il répercutera sur ses tarifs. Danscertains cas, on ne souhaite imposer l’anglais courant qu’aux chefs d’équipe. Cela limitegrandement les promotions par la suite, et l’on est contraint de ne jamais s’adresser direc-tement aux développeurs ou aux testeurs, même pour en valider les embauches.

Certains prestataires, souhaitant assurer une constitution rapide des équipes, nemanqueront pas d’affirmer qu’il n’est pas nécessaire que tous les membres de l’équipeparlent anglais. Il est envisageable d’accepter des candidats qui ne parlent pas suffisam-ment bien la langue de travail pour autant qu’ils s’engagent à atteindre un niveau suffi-sant dans cette langue avant une date limite. Le prestataire peut alors organiser des coursd’anglais intensifs.

L’expérience montre que lorsqu’on ne peut communiquer avec certains membres deséquipes, le client est toujours pénalisé. En ayant deux classes de collaborateurs, ceux quiparlent anglais et peuvent accéder à certains postes, et les autres, avec lesquels on nepeut communiquer directement, on se ferme certaines possibilités de management. Parexemple, on ne peut analyser les procédures qui ne fonctionnent pas bien, puisqu’on nepeut interroger tous les membres de l’équipe, ni les raisons des faibles performances. Onne peut pas davantage mettre en place des binômes pour chaque rôle afin d’assurer unremplacement éventuel, ni assurer la promotion des développeurs ou des testeurs dequalité, voire la simple communication sur la vie de la société. La traduction par un inter-médiaire est dans tous ces cas insuffisante pour travailler efficacement.



170

L’entretien d’embaucheL’entretien d’embauche en offshore est souvent l’occasion d’un choc culturel. Danscertains pays, les CV n’existent pratiquement pas ou, s’ils existent, sont créés sans convic-tion quelques minutes avant l’entretien. Le prestataire liste les postes à pourvoir sur sonsite Internet. Les candidats qui répondent renseignent leur expérience professionnelle ettechnique. Parfois, ce formulaire est directement fourni en guise de CV, masquant ainsitoute possibilité de détecter la personnalité du candidat.

Le cursus professionnel des candidats n’est pas toujours compréhensible. Peu habituésà se présenter, il n’est pas rare qu’ils n’aient jamais passé d’entretien d’embauche, mêmeà 35 ou 40 ans. Ils expriment mal leur parcours professionnel, et le client reste pantoisquand il entend en réponse aux raisons des changements de poste d’un candidat qu’iln’était plus payé depuis quatre mois ou que les propriétaires de la société avaientdisparu.

Il est recommandé d’exiger du prestataire offshore qu’il réalise le premier niveau de sélec-tion des candidats afin de valider leurs compétences techniques sur le sujet où ils devronttravailler. Il ne faut pas hésiter à insister si l’on veut que le futur supérieur hiérarchiquesoit impliqué dans le recrutement. Faute de cela, il risque de voir arriver une recrue quiest déjà embauchée et sur laquelle il n’a plus rien à dire.

EN RÉSUMÉL’entretien d’embauche, loin des pratiques occidentales

L’entretien d’embauche en offshore est un exercice auquel le candidat est peu préparé. L’on yconstate parfois d’immenses différences culturelles. Lors des entretiens d’embauche, le prestatairese concentre généralement sur les compétences techniques du candidat et néglige les aspectscomportementaux ou la motivation.

Certaines caractéristiques importantes des candidats ne sont pratiquement pas évaluéespar les prestataires en offshore, qui s’intéressent surtout aux compétences techniques. Leclient peut donc se concentrer sur les caractéristiques comportementales, du type :pourra-t-il travailler efficacement en équipe ? s’est-il intéressé aux domaines fonctionnelsqu’il a abordés dans le passé ? est-il capable de structurer sa communication ?

Certains candidats sont extrêmement nerveux et ont du mal à ne pas trembler. D’autresne disent rien ou répondent rarement aux questions autrement que par oui ou par non.D’autres encore savent que pour ne pas parler il faut poser des questions, si possible auxréponses longues, comme sur l’histoire de la société cliente.

On s’aperçoit au finale qu’il est difficile de comparer un entretien dans le pays du clientet en offshore. Le candidat n’a pas la même volonté de se vendre pour avoir le poste. Il sesait compétent et ne peut imaginer qu’on ne le choisisse pas. Certains candidats neposent même aucune question sur le poste proposé. Lorsqu’on leur demande s’ils saventpour quel poste ils sont là, ils n’en ont aucune idée et sont avides d’informations.

La période d’essaiQuel que soit le mode de recrutement, interne ou externe, on doit prévoir contractuelle-ment avec le prestataire une période d’essai pour chaque nouveau collaborateur. Cettepériode d’essai peut être de un à trois mois, indépendamment de la législation du pays.Si la durée retenue est courte, on peut la négocier comme un essai gracieux du collabo-rateur en attendant qu’il fasse vraiment partie de l’équipe.



171

Il ne faut pas oublier que l’on peut se séparer assez facilement d’un collaborateur selonles conditions contractuelles que l’on a définies. Cette période d’essai n’a donc pas lamême valeur engageante qu’une période d’essai dans le pays du client.

EN RÉSUMÉLa période d’essai

La période d’essai est avant tout contractuelle entre le prestataire et son client. Elle doit être géréeavec précision pour mieux constituer les équipes en offshore. Parfois, la période d’essai correspondà une mise à disposition gracieuse de certains profils par le prestataire offshore afin que le clientpuisse mieux les évaluer.

Au terme de la période d’essai, le client fait le point avec les personnes en contact avec lenouvel arrivant pour décider de le valider ou non. Comme il s’agit d’un accord avec le pres-tataire, on peut aussi demander que cette période soit reconduite.

Les formationsPour bien prévoir les formations, il faut anticiper la date à laquelle les membres deséquipes commenceront à être efficaces. Bien évidemment, les formations fonctionnellespeuvent être assurées en interne si le nombre de personnes présentes dans l’équipe estsuffisamment important. Au début, le client forme directement les premiers chefs deprojet, architectes et testeurs sur les sujets fonctionnels.

Si les développements s’appuient sur des fondations techniques comportant certainesapproches de programmation, une période d’apprentissage technique importante estnécessaire avant que le nouvel arrivant puisse être réellement efficace.

Les formations externes sur des technologies de progiciels sont également à prévoir endétail. Il peut être nécessaire d’obtenir des certifications, de faire venir des formateurs etde trouver des développeurs expérimentés sur des sujets précis. L’organisation de cesformations peut se révéler difficile et coûteuse. Il faut donc prévoir les moyens decontraindre le prestataire à respecter ses engagements.

Conclusion

Le choix du prestataire est une décision clé clairement identifiée par toutes les sociétésqui s’engagent dans des développements en offshore. La comparaison des prestatairesest complexe, et il est facile de se tromper, du fait de la distance géographique et cultu-relle. Ce chapitre a dégagé un ensemble de questions permettant de mieux choisir sonprestataire et d’éviter un grand nombre de pièges.

Le choix du prestataire doit être suivi d’une période d’attention soutenue de la part duclient afin de démarrer la coopération naissante sur des bases solides et de partager unobjectif commun qui assurera le succès des deux parties. La difficulté à gérer le projet,rendue plus complexe par la distance et les différences culturelles, peut toutefois assom-brir l’avenir de ce partenariat naissant. Pour se donner les meilleures chances de succès,il convient de cadrer ce partenariat par un contrat bien équilibré et une gestion de projetparticipative, seule à même de rendre tous les participants au projet responsables de sonsuccès. C’est le sujet du chapitre 9.


173

Chapitre 9

Le contrat avec le prestataire offshore

Ce chapitre aborde tous les thèmes que l’on peut rencontrer dans un contrat avec un pres-tataire en offshore dans le cadre d’un fonctionnement en régie. Les sociétés qui gèrentdes projets au forfait y trouveront également des informations utiles, comme la protec-tion de la propriété intellectuelle, tandis que d’autres seront sans objet.

Le fonctionnement au forfait implique que l’on n’a pas de contrôle sur l’organisation ni letravail au quotidien du prestataire. Ce dernier prend seul la responsabilité de livrer leproduit en temps et en heure avec la qualité requise ou d’assurer des livraisons intermé-diaires. La façon dont une certaine dose de forfait peut être introduite dans les contratsen régie est également abordée.

L’annexe de l’ouvrage reprend sous forme de check-list tous les points traités dans cechapitre.

Considérations générales sur le contrat

Le contrat est utilisé presque quotidiennement pour régler des affaires courantes chez unprestataire, et l’on n’y recourt pas uniquement en cas de conflit. Depuis la gestion descongés jusqu’à la qualité des locaux en passant par les responsabilités des deux partieset les services facturés, tous ces points font constamment référence au contrat.

Le contrat sert bien sûr également de référence en cas de litige, notamment ceux relatifsà la propriété intellectuelle, à la gestion des impayés ou à la rétention du produit duclient.

Nous ne nous étendons pas sur les clauses que l’on retrouve dans tous les contrats etnous concentrons sur les clauses spécifiques des développements en offshore.

Le mode de fonctionnement que l’on choisit pour travailler avec le prestataire définit letype de contrat que l’on signe avec lui. Comme expliqué aux chapitres 2 et 4, les projetsau forfait sont au premier abord les plus tentants. À moins de traiter un projet simple,court ou facile à documenter dans sa totalité, il est toutefois difficile de tirer pleinementparti des avantages du forfait en offshore.

Les projets au forfait rendent les opérations opaques puisque le prestataire se voit confi er lapleine responsabilité de la gestion du projet, assortie de pénalités lorsque les engagements



174

ne sont pas tenus. Le client ne se permet de contrôler les opérations chez le prestataireque lorsque le projet se déroule mal. On souhaite alors non seulement auditer le projet,afin de mieux comprendre la nature du mal, mais aussi vérifier la capacité du prestataireà tenir les engagements futurs et, surtout, s’assurer d’éventuelles actions correctives et deleurs effets.

Même si l’on souhaite de part et d’autre travailler au forfait, le client peut réaliser qu’iln’aura pas son produit dans les temps s’il n’intervient pas de façon énergique pour réta-blir un fonctionnement normal. On introduit alors une forme d’ingérence du client dansle projet, qui le rend plus proche du fonctionnement en régie.

De nombreuses questions abordées dans ce chapitre valent pour la régie comme pour leforfait.

Validation du contratLe contrat est le plus souvent rédigé en anglais afin d’être bien compris du prestataire. Letribunal compétent est spécifié comme celui où le client est domicilié, car c’est toujoursplus sûr en cas de conflit.

Les avocats du client sont parfois partiellement compétents pour revoir et valider de telscontrats, qui peuvent exiger une connaissance des lois du pays du prestataire offshorepour en assurer la validité, notamment lorsque des moyens sont prévus pour contraindrele prestataire à appliquer certaines dispositions. Les avocats réellement compétents surces sujets internationaux sont peu nombreux.

Plusieurs points généraux sont à vérifier en priorité dans le contrat de partenariat avec leprestataire. Il faut vérifier en premier lieu que le client ne se rend pas coupable demarchandage ou de prêt illicite de main-d’œuvre. Si le client cherche à obtenir uncontrôle très étroit des équipes du prestataire, il peut définir des règles qui l’exposent àde telles poursuites. Les employés doivent rester sous la direction de la hiérarchie de leursociété et non du client.

Il faut en outre vérifier que les employés du prestataire ne peuvent se faire reconnaîtrecomme des employés du client du fait de certaines dispositions du contrat. De tellesdispositions peuvent être un rattachement hiérarchique, même déguisé, à un collabo-rateur du client, des directives du client qui primeraient sur celles du prestataire, la miseen place de processus client, comme les demandes de congés, susceptibles de prouver unemploi déguisé.

Le prestataire prend évidemment garde de vérifier la situation juridique de son partenairede sorte que l’utilisation de ressources en offshore n’apparaisse pas comme de l’emploidéguisé. Lorsque des collaborateurs du prestataire sont appelés à se rendre régulière-ment chez le client pour y travailler, par exemple, ils peuvent tenter de se faire reconnaîtrecomme ses employés de fait.

Avec le mode régie, il importe de ne pas s’exposer à des lois qui exigeraient que dupersonnel en régie employé sur de mêmes postes pendant une durée dépassant uncertain seuil soit formellement embauché. Le terme « régie » est ici un abus de langage,les informaticiens cherchant en fait à désigner un mode de travail opposé au forfait. Tradi-tionnellement, une société reçoit dans ses locaux le personnel placé en régie qui estmanagé par ses cadres. Le personnel en offshore étant distant, on ne peut théoriquementparler de régie, qui suppose le placement sur site. À défaut d’un meilleur terme, on parleaujourd’hui couramment de régie pour les projets facturés au temps consommé, par


Chapitre 9 – Le contrat avec le prestataire offshore

175

opposition au forfait, quel que soit le lieu où se trouve le personnel en régie, et quelle quesoit l’organisation hiérarchique. L’anglais utilise l’expression time and material, qui est plusjuste. Les avocats sauront trouver les meilleures façons d’éviter cet écueil en spécifiantune définition du mode régie dans le contrat.

Le préambuleComme dans tout contrat, on peut placer en préambule certains éléments qui, sans fairevraiment partie du corps du contrat, y jouent tout de même un rôle. Par exemple, on peutexprimer pourquoi on a choisi ce prestataire et la nature des opérations que l’on souhaitemener localement. On peut y inclure tout ou partie de la proposition de services, laréponse au RFI ou une lettre d’intention signée entre les parties. Ces documents peuventmentionner des points qui ne sont pas repris dans le contrat proprement dit.

Bien que ce texte ne soit en rien contraignant pour les signataires, en cas de litige, on peuty faire référence et démontrer au partenaire que ses engagements ne sont plus pleinementtenus ou que la société a évolué au point de changer de nature.

Utilisation ultérieure du contratCertaines clauses du contrat peuvent être utiles à de nombreux intervenants sur lesprojets. Cela concerne notamment les jours travaillés, les vacances, les embauches, lespréavis, les heures supplémentaires et même les moyens de pression que le client peutexercer sur le prestataire. Chez le prestataire, les chefs de projet doivent connaître cesdispositions du contrat, car elles ont un impact sur le déroulement de leurs réalisations.

Les chefs de projet n’ont toutefois qu’une vision partielle des engagements contractuels.Le plus souvent, certaines informations ne leur sont communiquées qu’en réponse à unequestion précise surgissant dans le déroulement du projet. Mieux vaut donc concevoir laforme du contrat de sorte à en extraire facilement certaines parties pour les communiqueraux personnes intéressées, en conservant d’autres parties confidentielles, financières ouhors de propos.

La propriété intellectuelle

La protection de la propriété intellectuelle des réalisations en offshore est l’une desconditions essentielles pour que le client travaille efficacement et sereinement avec leprestataire. Il s’agit non seulement de s’assurer que la réalisation est la propriété du clientet qu’elle est correctement protégée, mais aussi que le prestataire n’introduit pasd’éléments qui appartiendraient à un tiers et dont l’exploitation pourrait impliquer l’achatde licences ou serait interdite.

La première précaution à prendre est, bien sûr, de protéger la propriété intellectuelle dela production outsourcée. Les règles relatives à la propriété intellectuelle peuvent varierd’un pays à un autre. En l’absence de mention spéciale, la propriété intellectuelle estgénéralement attribuée au créateur et rarement au client payeur. Il faut donc préciserdans le contrat que toute la production du prestataire au cours du projet est octroyée defaçon pleine et entière au client donneur d’ordres, qu’elle soit réalisée par les employésofficiellement salariés ou par tous les autres intervenants que le prestataire pourraitutiliser, que ce soit dans les locaux du prestataire ou en dehors.



176

Il importe d’éviter tout débat sur la nature des intervenants ou le lieu de la production,certains d’entre eux pouvant ne pas être des employés du prestataire. Il faut égalementprendre soin d’inclure toute la production, en incluant les documentations relatives àl’adaptation de la méthode, les guidelines, les modèles des rapports de suivi de projet,les spécifications, les modèles d’analyse et de design, les architectures générale ettechnique, les codes source, les plans de test, les architectures physiques des plates-formes matérielles, ainsi que tous les messages et documents échangés pour répondreaux questions ou passer des directives complémentaires ou correctives.

EN RÉSUMÉProtection de la propriété intellectuelle

Le contrat garantit que la totalité de la production réalisée en offshore par tous les intervenants estla propriété intellectuelle du client. Il se concentre surtout sur la propriété des spécificationsfonctionnelles et du code développé par le prestataire.

Une bonne pratique consiste à exiger que tous les documents créés en offshore portentla mention Copyright NomSocClient 2006, All Rights Reserved. Cette mention a plusieursavantages. Elle marque de façon certaine la propriété de chaque élément et assure quetoutes les personnes travaillant pour le prestataire savent de façon évidente que laproduction est la propriété intellectuelle du client.

Réutilisation d’éléments appartenant au prestataireDans certains cas, le prestataire peut avoir déjà développé des fonctions ou des servicesdont le client pourrait bénéficier. Il peut s’agir de la réutilisation d’éléments de méthodeou de procédure, de services techniques ou encore de modules fonctionnels standardssusceptibles d’apporter un gain de temps, comme la gestion de commandes et de stockssur les sites de commerce électronique.

Ces éléments peuvent être vendus par le prestataire. Ce dernier peut aussi en conserverla propriété intellectuelle et en concéder la licence d’exploitation à titre gratuit ou payant.Par exemple, un prestataire peut avoir développé un moteur de facturation très flexible,qu’il propose de mettre à la disposition du client, souvent pour une somme modique.Parfois même, l’utilisation de certains composants est accordée au client à titre gracieux.Ces prestataires font de ces blocs fonctionnels et composants un atout concurrentiel.

Un article général peut indiquer que tous les éléments proposés au client et utilisés dansles réalisations dont le prestataire est propriétaire sont cédés gratuitement pour une libreutilisation commerciale dans le contexte de cette réalisation, sauf dans les cas où ilsferaient l’objet d’une négociation séparée. Il est en effet essentiel de se protéger d’unprestataire peu scrupuleux qui ferait valoir après coup que le produit réalisé utilise deséléments dont il est propriétaire et pour lesquels il demande une compensation. Avec unetelle clause, le prestataire reste le propriétaire des éléments qu’il a fournis et en accordeune licence perpétuelle à son client.

Le prestataire peut aussi avoir mis au point une méthode et des procédures qu’il proposeà ses clients. La situation est alors un peu différente, car ce prestataire souhaitera lesappliquer à tous ses projets. De son côté, le client peut souhaiter étendre ses propresméthodes à l’offshore au lieu de celles de son prestataire. Certains prestataires font deleurs procédures un avantage concurrentiel et obtiennent des certifications ISO 900X et



177

CMM. Le contrat doit clairement prévoir comment le projet doit être organisé du point devue de la méthodologie et si cette dernière doit elle-même être protégée.

Protection d’éléments appartenant au clientLe client peut disposer de composants techniques ou fonctionnels réutilisables. Lecontrat doit en ce cas assurer leur protection chez le prestataire.

Lorsque le client est une société de services, il se peut qu’il souhaite protéger sa métho-dologie, laquelle participe, selon lui, à la valeur de la société et contribue à lui donner unavantage concurrentiel. Le prestataire, qui assure assez naturellement la protection descodes source, peut ne pas se rendre compte qu’une méthode doit aussi être protégée. Ilfaut en ce cas prendre soin de noter explicitement dans le contrat que celle-ci est et restela propriété exclusive du client et qu’elle doit être protégée.

Il en va de même de tout autre élément qui ne serait pas protégé de façon évidente.

Introduction d’éléments appartenant à des tiersIl convient d’identifier tous les éléments qui ne relèvent pas de la pleine propriété duclient dans le produit réalisé en offshore. Avant de les inclure dans le produit, il faut quele client possède une licence d’utilisation accordée par son propriétaire ou en connaisseles conditions d’acquisition ou d’exploitation. Ces licences, regroupées sous forme deliste, incluent celles accordées par le prestataire et celles de tiers.

Les contraintes relatives à ces composants sont clairement mentionnées, qu’il s’agisse delicences perpétuelles sur paiement unique, de licences gratuites (freeware), de licencesOpen Source, de licences dont le coût est calculé par utilisateur ou par processeur, ou decontraintes imposant de mentionner le nom de l’éditeur sur l’application.

Si le prestataire souhaite intégrer des produits ou composants licenciés, le contrat définitles procédures à suivre pour soumettre la demande d’utilisation de ceux-ci et la façondont le client les accepte ou les rejette. Il est essentiel de faire porter la responsabilité dunon-respect de ces procédures sur le prestataire. Si des produits externes qui n’ont pasété validés par le client sont tout de même inclus dans les réalisations et doivent êtreretirés, le travail qui en résulte est à la charge du prestataire.

Réutilisation de code personnelComme expliqué précédemment dans l’ouvrage, les développeurs, tout particulièrementen offshore, ont la fâcheuse tendance à réutiliser du code qu’ils ont téléchargé sur Internetou qu’ils ont conservé d’un projet antérieur, sans se soucier des droits qui se rapportentà ce code. Lorsqu’ils s’en soucient, ils peuvent estimer que s’ils en corrigent ou en améliorentcertaines parties, il leur appartient et devient libre de droits.

Il est bien difficile de contrôler d’où provient le code source qu’un développeur saisit surun projet. Seules une bonne communication du client et du prestataire et une disciplinepersonnelle de chaque développeur sont à même d’assurer la transparence des droits surle code.

Le contrat doit indiquer expressément que tout code extérieur qui serait utilisé dans lecadre du projet doit être formellement validé par le client, sur la base d’informationscomplètes sur l’origine de ce code. Le contrat peut désigner une personne ou un rôleresponsable pour effectuer ces validations.



178

Protection contre la concurrence

Il est légitime de redouter que le prestataire ne signe un contrat de prestations offshoreavec un concurrent du client. Dans un tel cas, les collaborateurs du prestataire seraientamenés à parler avec d’autres équipes et à comparer méthodes, fonctionnalités, solutionstechnologiques et plans stratégiques. Cela ne manquerait pas d’arriver aux oreilles desdécideurs du concurrent, lesquels pourraient en faire un usage agressif.

Il est même possible qu’un collaborateur passe du projet du client à celui d’un concurrent,tout en restant salarié du même prestataire. Il ferait alors profiter au concurrent de l’expé-rience acquise sur le développement du client, ce qui ne manquerait pas d’irriter cedernier, voire de le mettre en danger. Un client voyant un concurrent commencer àtravailler avec son prestataire en offshore serait en droit de s’inquiéter de fuites volon-taires ou involontaires.

Le contrat permet de se prémunir de plusieurs façons de ce genre de situation. On peut,par exemple, interdire au partenaire en offshore de travailler avec des concurrents directs.Pour ce faire, on peut faire figurer nommément dans une liste toutes les sociétés aveclesquelles le prestataire ne serait pas autorisé à travailler ou définir précisément lesdomaines interdits. Dans les deux cas, on ne peut envisager une telle approche que si lesexclusions sont précises. Par exemple, un domaine qui serait identifié comme le tradingd’instruments de Foreign Exchange sur Internet pourrait figurer au contrat, mais pas « lecommerce électronique sur Internet », trop général.

Le prestataire accepte plus volontiers ce type de clause si le volume d’affaires avec leclient est important et si le domaine d’exclusivité est suffi samment réduit. La clausepeut indiquer un volume d’affaires minimal. Si le volume d’affaires reste en deçà decette valeur, le prestataire peut demander une compensation pour garantir cette exclu-sivité.

On peut aussi prévoir que si le prestataire souhaite travailler avec une société explicite-ment listée dans le contrat, il demande au client de confirmer que l’interdictions’applique bien. En effet, certaines sociétés importantes estimées concurrentes peuventconfier des projets à l’offshore dans un tout autre domaine que celui où le client opère,levant ainsi tout problème de confidentialité.

Non-respect des règles de confidentialité

Le prestataire doit veiller à ce que le personnel de sa société connaisse et respecte scru-puleusement les règles relatives à la propriété intellectuelle et à la confidentialité desinformations. Si le prestataire ou le client se rend compte du non-respect de celles-ci, ildoit en informer immédiatement l’autre partie.

Le prestataire est censé prendre les sanctions qui conviennent pour punir l’employé quine respecterait pas ces règles. Si le collaborateur a sciemment transgressé les règles avecl’intention de nuire ou d’en tirer profit, ne serait-ce que pour se faire valoir auprès d’unautre employeur potentiel, le contrat doit contraindre le prestataire à le licencier sanspréavis pour faute grave. Au besoin, il devra engager des poursuites contre lui. Il est trèsimportant que les collaborateurs comprennent la réalité de la propriété intellectuelle.



179

Les services du prestataire offshore

Cette section traite des aspects contractuels relatifs à la fourniture des services de baseet des services complémentaires. La réalité concrète du partenariat en offshore est lafourniture de services de prestations humaines.

La mention des services de base, consistant à mettre à disposition du client des collabo-rateurs, ne suffit généralement pas et doit s’accompagner de la fourniture de servicescomplémentaires, tels que matériel, bande passante Internet, administration de réseau,supervision de la sécurité, etc., essentiels au fonctionnement du partenariat. Ces servicespeuvent être facturés séparément ou être inclus dans le coût de mise à disposition desressources humaines.

La langue de travailLe contrat définit la langue de travail qui sert à communiquer entre les équipes du clientet celles du prestataire, incluant la documentation du projet.

Les collaborateurs du prestataire parlent bien sûr entre eux dans leur langue natale. Onpeut imposer que tous les échanges écrits (messages et messages instantanés) utilisentla langue de travail. Une telle mesure risque toutefois d’être peu populaire et de réduirequelque peu la productivité. Une autre solution consiste à imposer que les décisions outoute information utile résultant d’une telle communication soient résumées dans lalangue de travail et transmise aux personnes concernées.

Le client peut disposer de documents dans sa langue locale, qui n’est pas nécessairementla langue de travail, qu’il souhaite communiquer au prestataire comme des éléments dedocumentation du projet. Il peut s’agir d’un manuel utilisateur ou de spécifications. Si leclient prévoit de fournir souvent au prestataire des documents dans sa langue locale, ilpeut demander que le prestataire s’organise en conséquence et inclut un ou plusieurstraducteurs dans l’équipe ou recourt à un service de traduction.

Si l’on doit employer fréquemment des documents traduits, il est fortement recommandéde disposer en permanence d’un traducteur en offshore afin de répondre aux questionsdes développeurs et architectes, notamment si la traduction n’est pas claire ou si ellesemble incorrecte.

Prestations de base et services complémentairesD’une manière générale, il n’est pas raisonnable de complexifier à outrance la facturationni la supervision du prestataire en offshore. Il est préférable de forfaitiser le maximum deservices complémentaires dans les prestations humaines, à condition de veiller que leforfait soit assez bien calculé.

Ce serait une erreur de considérer que puisque ces services sont inclus, le client n’a pas às’en préoccuper. Encore faut-il savoir comment ils sont définis pour juger s’ils sont effec-tivement rendus et s’ils sont suffisants et adaptés pour travailler efficacement avec l’off-shore. Par exemple, si la bande passante sur Internet est incluse, le prestataire fournit-ille débit minimal convenu, et ce débit est-il suffisant ? Si les postes de travail sont inclus,sont-ils efficaces pour le travail demandé aux collaborateurs distants ?



180

Si l’on décide de ne pas inclure ces services additionnels dans les facturations forfaitairespar collaborateur, mais de les payer au réel, éventuellement avec une marge additionnelle,le client doit faire l’effort de suivre les coûts réels engagés par le prestataire. Ce travailadministratif peut se révéler lourd si l’équipe en offshore est importante.

Certains services ne peuvent être inclus dans la facturation des collaborateurs du fait deleurs coûts élevés ou de leur forte dépendance aux souhaits de la société cliente etdoivent être facturés séparément. Par exemple, le prestataire ne fournira probablementpas les suites logicielles, assorties de contrats de maintenance, nécessaires au développe-ment dès lors qu’il s’agit de produits coûteux. Le prestataire ne voudra probablement pasnon plus inclure les serveurs de test des réalisations en offshore, surtout si la plate-formeconsiste en plusieurs serveurs en architecture n-tiers et que le client souhaite absolumentéclater physiquement les tiers sur différents serveurs pour réaliser les déploiements et lestests en offshore.

Certains services peuvent être naturellement inclus dans les prestations offshore ourefacturés au client, comme l’administration du réseau, qui est toujours incluse dans lesprestations des petites équipes, mais pas nécessairement dans celles des équipes plusimportantes.

Dans tous les cas, il convient de bien comprendre ce qu’incluent les prestations deservices en offshore. Ces services inclus expliquent en grande partie les différences impor-tantes que l’on constate entre les salaires effectivement versés par le prestataire auxcollaborateurs et le prix par collaborateur facturé au client.

Devise de facturation et risque de changeLa devise utilisée dans les opérations commerciales avec l’offshore est majoritairementle dollar, même lorsqu’on traite avec les pays de l’Europe de l’Est. Certains prestatairesmontrent cependant une préférence pour l’euro, motivée par la perte de valeur du dollarpar rapport à l’euro.

Le dollar est souvent considéré comme la seconde monnaie nationale dans les pays del’offshore, et les opérations importantes, comme l’achat d’une maison ou d’une voiture,sont mentionnées en dollars. Les taux de change présentent souvent un split achat/ventetrès faible avec la monnaie locale, rendant particulièrement fluide la conversion entre le dollaret la monnaie locale dans les deux sens. Le split avec l’euro est généralement beaucoupplus important, n’assurant pas la même fluidité des échanges.

La plupart des habitants des pays de l’offshore connaissent le cours du dollar au jour lejour. Même si la loi l’interdit fréquemment, on peut payer en dollar dans presque tous lescommerces, surtout lorsque les sommes sont importantes. Les salaires sont presquetoujours définis en dollars, ce qui permet, dans une certaine mesure, de se protéger del’inflation.

Les négociations avec le prestataire sur le montant des services ont donc toutes les chancesd’être en dollars, même si le client exige que le contrat soit conclu en euros. Dans ce cas,le risque de change est limité aux montants des prestations refacturées au réel et indexéessur le dollar, ce qui ne représente qu’une faible partie du montant de la facturationmensuelle.

Lorsque le prestataire dispose de montants en monnaie locale à refacturer en dollars ouen euros, le contrat définit la façon de choisir le taux de change pour établir les factures.



181

Il précise la source du taux de change et la date à laquelle on fixe le choix de façon à levertoute ambiguïté, surtout si l’on traite avec un pays qui a un fort taux d’inflation.

Si le taux de change devient très avantageux pour le client et que les prestations soientfacturées à un prix qui ne laisse qu’une faible marge au prestataire, celui-ci risque deperdre totalement sa marge et ne plus trouver un réel intérêt au contrat. Il peut dès lorsêtre amené à souhaiter le dénoncer ou le renégocier.

Par exemple, si le mois/homme est fixé à 2 000 euros à une période où un euro vaut undollar, et que le taux de change évolue à 1 euro pour 0,7 dollar, le prestataire, qui paye sesemployés et ses fournisseurs en dollars, ne perçoit plus que 1 400 dollars, au risque d’uneprestation à perte. Une telle situation n’est pas forcément à l’avantage du client. Si lasituation perdure, ce dernier constatera probablement une perte de productivité des pres-tations, voire le départ des meilleurs membres de l’équipe et leur remplacement par descollaborateurs qui acceptent des salaires plus faibles.

L’unité de facturation des prestations de baseLes prestations de base correspondent à la mise à disposition des ressources humaines,avec parfois un certain lot de services complémentaires inclus dans ces prestations. Enrègle générale, ce poste correspond à 75 à 100 % de la facture totale du prestataireoffshore.

L’unité de facturation des prestations, qui peut être le mois, le jour ou l’heure, a uneinfluence importante sur la façon dont le prestataire en offshore utilisera ses collabora-teurs. Chacune de ces unités présente des avantages et des inconvénients. Nous verronsque la facturation à la journée est la plus recommandée.

Le choix de l’unité de facturation n’a toutefois d’importance que pour les prestations enrégie. Pour les prestations au forfait, l’unité de mesure importe peu, le calcul de la propo-sition n’ayant pas besoin d’être exposé en détail au client.

Facturation à l’heure

La facturation à l’heure est la plus communément pratiquée pour les clients américainsou britanniques. Son principal inconvénient est que les journées de travail facturéesdépassent souvent largement les huit heures. Même avec un nombre fixe de collabora-teurs, on ne peut savoir exactement ce que le prestataire facture en fin de mois car lenombre d’heures travaillées varie grandement. De plus, ce mode de facturation pousse leprestataire à facturer mécaniquement toutes les heures travaillées.

Pour effectuer sa facturation, le prestataire met en place un reporting détaillé par jour etpar personne. Si le client exige d’être livré dans les temps, cela peut être compris commeune demande d’heures supplémentaires et se traduire par une hausse significative desmontants facturés. On constate parfois qu’une équipe travaille douze heures par jour etque le montant des factures augmente de 50 % par rapport à ce que l’on avait anticipé. Sile collaborateur est lui-même rémunéré à l’heure, ce mode de facturation pousse à lasurconsommation puisqu’il peut augmenter ses revenus en travaillant davantage.

Il est toujours possible de limiter contractuellement le nombre d’heures travailléeschaque jour, toute heure supplémentaire devant être approuvée par le donneur d’ordres.Un effet pervers surgit toutefois. Pour éviter que ses équipes ne fassent des heures supplé-mentaires gratuites, le prestataire limite strictement le nombre d’heures travaillées aux



182

heures facturables. Si le contrat prévoit huit heures, le prestataire s’arrangera pourdémontrer que chaque collaborateur a travaillé exactement huit heures, et jamais plus.

Ce type de facturation est également problématique pour le donneur d’ordres. Commentpeut-il exiger de rattraper un retard, par exemple, s’il refuse que le prestataire fasse desheures supplémentaires ? Le prestataire peut accepter d’assurer des heures supplémen-taires sans les facturer s’il se sait responsable du retard. Autrement, il n’a aucune raisonde faire un cadeau à son client, sauf à le faire valoir comme un effort exceptionnel.

EN RÉSUMÉFacturation à l’heure travaillée

La facturation à l’heure travaillée pousse naturellement le prestataire en offshore à facturer toutesles heures supplémentaires, ce qui peut augmenter significativement les montants des facturesmensuelles. À l’inverse, le prestataire limite strictement les heures travaillées à ce qui est convenucontractuellement, interdisant tout travail supplémentaire volontaire des collaborateurs. Dans lesdeux cas, le client est perdant.

Facturation à la journée

La facturation à la journée consiste à facturer chaque journée travaillée par chaque colla-borateur selon le montant prévu au contrat. Le contrat définit un nombre d’heuresnominal par journée, le plus souvent entre sept et dix heures, et comment les heures etles journées supplémentaires sont comptabilisées. Les heures supplémentaires nepeuvent être facturées qu’après accord formel du donneur d’ordres.

Ce type de facturation à la journée est assez favorable au donneur d’ordres. Il y retrouveson mode de fonctionnement habituel en local avec ses cadres, dont certains travaillentlongtemps après les heures de bureau.

Le prestataire met en place un outil de gestion des temps de travail, souvent à l’heure,afin de suivre la présence sur les lieux et le détail du travail accompli. Cet outil n’est pasimmédiatement utilisé pour calculer les heures supplémentaires.

Lorsque des efforts supplémentaires doivent être consentis, ils le sont généralement surla journée de travail en fournissant quelques heures de plus, éventuellement rattrapables.Peut-être travaillera-t-on moins un autre jour, mais cela reste du ressort du prestataire enoffshore ou de chaque collaborateur. Il peut arriver que le prestataire demande à sonclient l’autorisation de facturer un jour de vacance un collaborateur en compensationd’un certain volume d’heures supplémentaires reconnu par tous.

Le donneur d’ordres peut toujours demander formellement des heures supplémentaires.Il s’agit le plus souvent de jours ou de demi-journées supplémentaires, le samedi ou leweek-end. Le contrat doit donc déterminer la façon dont les heures supplémentaires sontfacturées, notamment si les tarifs sont identiques quel que soit le jour ou s’ils sont plusimportants le week-end, par exemple.

EN RÉSUMÉFacturation à la journée

La facturation à la journée est la plus simple. Elle permet une gestion du personnel assez similaire àcelle que l’on observe en local. Les efforts exceptionnels sont souvent fournis naturellement, sansfacturation d’heures supplémentaires. C’est un mode de facturation efficace, qui est recommandédans les contrats avec les prestataires offshore.



183

Facturation au moisLa facturation au mois correspond à facturer pour chaque mois travaillé une sommedéfinie contractuellement pour chaque collaborateur. Si un collaborateur ne travaille pastous les jours du mois, les jours non travaillés sont le plus souvent déduits au prorata desjours ouvrés.

Avec ce mode de facturation, le prix de la journée travaillée varie selon le nombre de joursouvrés dans le mois. Le suivi budgétaire est assez aisé, puisque les budgets et les facturationssont le plus souvent organisés par mois. À l’inverse, avec les facturations à la journée ouà l’heure, le coût du mois/homme varie selon le nombre de jours ouvrés dans le mois.

La facturation au mois offre les mêmes avantages pour la gestion des heures supplémen-taires que la facturation à la journée.

EN RÉSUMÉFacturation au mois

La facturation au mois est aussi intéressante pour le client que la facturation à la journée. Le prix dela journée varie selon le nombre de jours ouvrés dans le mois.

Les heures supplémentairesDans tous les cas, la façon de gérer les heures supplémentaires doit être clairementdéfinie dans le contrat de partenariat. L’objectif est de créer un climat de collaboration,grâce auquel le prestataire et le client travaillent réellement ensemble sur le projet. Demême que les salariés locaux du client sont prêts à rester plus tard pour achever destâches importantes, il est important que les collaborateurs distants soient motivés pourfaire d’eux-mêmes ces efforts supplémentaires.

On essaie le plus souvent de limiter le recours aux heures supplémentaires et de favoriserles rattrapages de façon à ne pas dépasser les budgets arrêtés. On peut établir commeprincipe que le client ne paie pas d’heures supplémentaires, quitte à y déroger en casd’extrême nécessité.

Les deux méthodes de facturation des heures supplémentaires les plus usitées sont lafacturation au prorata des horaires facturés pour un travail normal et la facturation selonun barème prédéfini.

La facturation au prorata est la plus simple. On applique les mêmes tarifs aux heuressupplémentaires et aux journées normales de travail. Même si le collaborateur concernéperçoit des indemnités à un taux horaire plus élevé, la facturation au client s’appuietoujours sur les taux des journées ouvrées.

Si l’on choisit d’utiliser un barème d’heures supplémentaires, elles sont facturées selonune grille donnant le taux horaire de chaque période, par exemple une fois et demie letarif horaire du collaborateur.

L’organisation des heures supplémentaires est particulièrement critique lorsqu’ontravaille avec des équipes à fort décalage horaire et que l’on a l’intention d’organiser desréunions téléphoniques à des heures confortables pour le donneur d’ordres, c’est-à-direen dehors des heures de travail du prestataire. Par ailleurs, si l’on utilise des ressourcesen offshore pour l’administration de plates-formes, il est très commun d’organiser ledéploiement d’applications en dehors des heures ouvrées, la nuit et le week-end. Il estimportant de s’assurer en ce cas que l’on pourra faire travailler les collaborateurs durantces périodes.



184

Absences et congés

Le client n’est facturé que pour les journées et les heures effectivement travaillées par lescollaborateurs. Le prestataire en offshore ne facture donc jamais les jours non travaillés,quel qu’en soit le motif (vacances, maternité, maladie, famille, motifs injustifiés, etc.).

Le fait que le prestataire ne facture pas cette journée à son client ne signifie pas que lecollaborateur ne doive pas être payé pour autant, notamment s’il est en congés payés. Leprestataire peut très bien avoir l’obligation légale de payer un certain nombre de jours decongés payés ou d’absences pour maladie.

Le contrat stipule si les absences doivent être rattrapées à l’initiative du collaborateur.On rencontre des prestataires qui organisent librement ces rattrapages. Par exemple, siun collaborateur part une semaine en vacances et travaille cinq samedis en rattrapage, ilse retrouve avec 260 jours travaillés dans l’année. Ce type d’organisation n’est pas effi-cace, car la personne qui travaille seule ne peut pas toujours être aussi performante quelorsqu’elle peut interagir avec ses collègues. De plus, son absence a pu retarder certainestâches.

Accepter une forte flexibilité favorise la tendance de certains collaborateurs à prendre unsecond emploi. Ils peuvent se libérer des jours entiers pour leur second poste lorsqu’ilsen ont besoin, sans perdre la moindre part de la rémunération de leur premier emploi. Ilest recommandé d’interdire contractuellement le rattrapage systématique des absences,qui ne doit être autorisé que par le client. Une certaine tolérance est acceptable pourrattraper les absences exceptionnelles de quelques heures le jour même ou les jourssuivants.

Le client peut contraindre les collaborateurs en offshore à prendre chaque année unnombre de jours de congé précisé contractuellement, de façon à définir clairement lebudget des équipes offshore sur l’année. Les rapports de suivi d’activité permettent detracer le nombre de jours restant à prendre. Il est bon de prévoir une répartition dansl’année de ces congés de façon à ne pas risquer de voir tous les collaborateurs disparaîtreen même temps.

Les congés et les absences n’étant pas facturés, le prestataire doit rendre compte préci-sément dans sa facture mensuelle des jours travaillés et non travaillés.

ÉTUDE DE CAS

Un prestataire qui utilise son client pour se justifier

Un prestataire en offshore rencontre des difficultés financières et cherche à réduire ses coûts partous les moyens possibles. Dans son pays, les congés payés sont d’environ 20 jours par an. Le pres-tataire pratique une différenciation entre les salaires officiels et les salaires réels, les salaires offi-ciels dépassant rarement 50 dollars, et les salaires réels se situant autour de 500 dollars. Le clientprincipal du prestataire exige que les collaborateurs prennent effectivement leurs 20 jours decongés.Le management du prestataire paye depuis longtemps les congés sur la base du salaire réel. Dufait de ses difficultés croissantes, il décide de changer le mode de rémunération des congés et dene payer que les salaires officiels. Sa décision se révélant très impopulaire, il la justifie en se targuantde la clause contractuelle avec son client principal qui stipule que les absences et congés ne sontpas facturés.



185

Les sous-projets au forfaitUn projet en régie n’interdit en rien de demander de traiter des sous-ensembles du projetau forfait. Cette pratique peu courante lorsque la relation en régie fonctionne de façonsatisfaisante peut se révéler utile lorsque le client estime que la productivité du presta-taire est trop faible.

Le contrat peut prévoir que certains contrats au forfait puissent être exécutés sur la basede documents contractuels précisant les tâches à exécuter, même si le cadre général dela relation est la régie. Le personnel dédié à ces projets au forfait sera exclu de la factura-tion en régie pendant toute la durée où le projet au forfait est exécuté, jusqu’à validationde la livraison finale par le client, qui devra être aussi prompte que possible.

Certains clients appliquent une méthode itérative et gèrent le contenu de l’itération auforfait. Une itération demandant souvent entre quatre et six semaines, elle peut êtremaintenue raisonnablement stable durant son exécution, et le prestataire peut s’engagersur des délais. Les changements éventuels sont reportés sur l’itération suivante. Lesprocédures et modes de fonctionnement imposés par le client sont bien connus du pres-tataire, lequel peut les prendre pleinement en compte dans l’estimation des charges.

En fin d’itération, l’assessment d’itération permet de juger de la part qui n’a pas été réalisée.Le contrat réglant le fonctionnement du forfait par itération peut définir le mode de calculd’une pénalité en fonction des retards constatés. On est alors certain que le prestataireconsidérera ses engagements sur l’itération avec sérieux et fera tous les efforts néces-saires pour tenir ses objectifs.

Le contrat peut définir que les itérations peuvent être forfaitisées et préciser les règles dedéfinition et d’analyse de l’atteinte des objectifs ainsi que le calcul des pénalités associées.

Si l’on souhaite adosser au contrat de façon courante la forfaitisation des itérations, ilconvient d’abord d’atteindre un niveau de fonctionnement stable selon l’approcheméthodologique du client. Les premières itérations sont souvent loin d’atteindre lesobjectifs. On apprend à connaître les hommes, on met en place une méthode, et lestâches à fort risque ou liées à des études de faisabilité y sont importantes.

La forfaitisation des itérations ne peut être appliquée efficacement qu’une fois qu’elles sontsuffisamment stables. Tant que ces conditions ne sont pas réalisées, on peut extraire desparties stables des premières itérations et leur appliquer un fonctionnement au forfait.

Facturation des collaborateursLorsqu’on n’a pas encore travaillé avec l’offshore, on peut être tenté de mettre en placeun mode de facturation qui attribue un montant propre à chaque collaborateur, sur labase de ses compétences ou du salaire qu’il perçoit. En offshore, ce mode de facturationpar individu est assez délicat à gérer.

Le mécontentement est si fort que plusieurs personnes menacent de démissionner. L’affaire vientaux oreilles du client, qui se voit contraint d’intervenir auprès du prestataire pour éviter le départ de colla-borateurs. Le client explique au personnel que, s’il est normal qu’il ne paie pas les jours non travaillés,cette disposition est sans rapport avec les obligations du prestataire de payer leurs congés.Le client fera finalement signer au prestataire un avenant au contrat l’obligeant à payer les congéspayés sur la base des salaires réels de tous les collaborateurs travaillant avec lui.



186

L’expérience et la compétence sont des éléments subjectifs, dont l’appréciation varie aucours du projet. Si le client applique ce type de facturation par personne au début duprojet, il n’est pas à même d’apprécier les qualités de tous les collaborateurs en offshore.En cours de projet, il peut souhaiter revoir certains taux pour prendre en compte lestalents qui se sont révélés et, ce qui est plus important à ses yeux, pour baisser les tarifsdes collaborateurs qui n’auraient pas délivré les performances attendues.

Des renégociations fréquentes entre le client et le prestataire sont toujours délicates etgénèrent des tensions inutiles. Il y a peu à gagner à remettre en question continuellementdes tarifs par personne, les sommes en jeu étant globalement faibles puisque augmenta-tions et réductions finissent par s’équilibrer. Il y a en revanche beaucoup à perdre, lesdivergences d’appréciation sur le personnel entre le client et le prestataire risquant deperpétuer les tensions.

EN RÉSUMÉFacturation forfaitaire des profils

Il est recommandé d’utiliser une facturation forfaitaire pour le personnel en offshore, c’est-à-dire unesomme unique pour tous les profils ou par grande catégorie de personnel. Cette approche de lafacturation est la plus efficace, et elle permet de conserver un bon esprit de partenariat entre leprestataire et son client.

L’expérience montre qu’il vaut mieux traiter la tarification du personnel globalement endéfinissant une somme unique pour tous les collaborateurs, éventuellement par grandecatégorie, par exemple standard et expert, sans entrer dans le détail de l’expérience et dela compétence de chacun. Cette approche est d’ailleurs le mode de tarification le pluscommun des prestataires en offshore.

Si l’on emploie des équipes très importantes, on peut affiner cette facturation en définis-sant des catégories de collaborateurs et de compétences particulières. Par exemple, onpeut adopter le découpage de facturation proposé au tableau 9.1, qui permet d’ajuster encontinu les catégories. Ce type de distribution ne reflète pas pour autant la productivitédes collaborateurs.

Tableau 9.1. Distribution des profils par expérience

Junior Jusqu’à deux ans d’expérience sur les sujets utiles

Intermédiaire Deux à quatre ans d’expérience sur les sujets utiles

Senior Cinq à huit ans d’expérience sur les sujets utiles

Expert Plus de huit ans d’expérience sur les sujets utiles

Compétences particulières – Base de données– Administration Windows– Développement EJB– Développement .Net– Expertise sécurité– Expertise méthodes– Capacité exceptionnelle de management



187

Un autre type de distribution consiste à allouer un niveau de performance ou de compé-tence en définissant deux ou trois catégories, par exemple assistant, standard et expert.L’attribution de chaque personne à une catégorie est faite manuellement, selon desrègles contractuelles revues tous les six mois.

Le tableau 9.2 donne une idée de ce type de distribution.

Quel que soit le mode de tarification utilisé, les montants facturés par collaborateurdoivent inclure les services intégrés de base, comme la mise à disposition de locaux,d’électricité, etc.

Les services intégrés dans les prestations

Les services qui sont naturellement intégrés dans les facturations des collaborateursdoivent être clairement définis. Certains de ces services sont évidents, comme le lieu detravail, le mobilier courant, l’électricité, le nettoyage des locaux, la gestion administrativede l’équipe et de la paye, etc. Tant que l’équipe est restreinte, le prestataire peut fournirces services sans engager de dépenses supplémentaires. Pour les grosses équipes, leprestataire doit investir, et il est difficile d’identifier la taille seuil à partir de laquelle lesressources lui coûtent vraiment.

Les prestataires qui travaillent avec une équipe importante comprennent vite que lagestion administrative de l’équipe va leur prend beaucoup de temps. Une ou plusieurspersonnes doivent suivre à plein temps les absences, les congés, la facturation, lesservices refacturables, les embauches, etc. Bien souvent, le prestataire tente de facturerce personnel comme faisant partie de l’équipe du client. Il revient à ce dernier de décidersi ces rôles sont de la responsabilité du prestataire ou s’il accepte de les payer.

D’autres services sont moins clairement de la responsabilité du prestataire. Le tableau 9.3récapitule les services susceptibles d’être exclus des prestations par personne.

Tableau 9.2. Distribution des profils par niveau de compétence

Expert Personnel aux compétences affirmées correspondant à un certain niveau de formation ou d’expé-rience

Standard Personnel débutant provenant de bonnes universités ou n’ayant pas de compétences techniques fortement affirmées (testeur fonctionnel)

Assistant ou junior

Personnel débutant ou assistant n’ayant pas de compétences fortes et assurant une période de formation ou de stage

Tableau 9.3. Services pouvant être exclus des prestations par personne

Service Commentaire

Administration réseau

Lorsque l’équipe est petite, ces services sont toujours intégrés dans les coûts des presta-tions des collaborateurs. Ils sont parfois facturés séparément lorsque l’équipe dépasse un certain seuil et demande plus d’une personne à temps plein. Si le client demande un réseau séparé ou des conditions particulières de sécurité, ce service est facturé séparément.



188

Lorsque des services ne sont plus intégrés, ils doivent être gérés comme des servicescomplémentaires. Ce sujet est traité plus loin dans ce chapitre.

Réduction de la facturation sur la base du nombre de collaborateurs

Dans la plupart des contrats, des réductions sont accordées si le nombre de collabora-teurs ou le montant facturé atteint certains seuils (voir tableau 9.4). Cette méthode de réductionest assez efficace et ne prête pas à confusion, par opposition aux calculs sur le nombre decollaborateurs.

Par exemple, une facture de main-d’œuvre de 80 000 dollars donnera lieu aux remisessuivantes :

• 5 % de remise sur la tranche 80 000-30 000, soit 2 500 dollars ;

• 5 % de remise supplémentaire sur la tranche 80 000-50 000, soit 1 500 dollars ;

• 5 % de remise supplémentaire sur la tranche supérieure à 75 000 (5 000 dollars), soit250 dollars.

La remise totale est de 4 250 dollars, soit une remise globale de 5,3 %.

Le mode d’attribution des remises doit être univoque et sans interprétation possible. Parexemple, les calculs de remise s’appuyant sur le nombre des collaborateurs sont souvent

Service Commentaire

Locaux et mobilier

Ces services sont généralement intégrés. Lorsque le client exige une surface par individu supérieure à celle pratiquée habituellement ou des conditions de travail particulières, ces services font l’objet d’un ajustement du prix de chaque collaborateur mais restent inclus dans les prestations par personne.

Embauche des ressources

Lorsque le client demande l’embauche d’un grand nombre de personnes, il peut être néces-saire de mettre en œuvre des moyens exceptionnels, que le prestataire facturera au client (annonces).

Serveur de fichiers

Lorsque les volumes stockés deviennent importants ou si l’on doit déployer des produits particuliers, comme un gestionnaire de configuration, ces services sont généralement refacturés au client.

Tableau 9.4. Attribution de réductions par volume de prestation

Montant mensuel facturé (en dollars)

Pourcentage de réduction accordé

De 0 à 30 000 Pas de réduction

À partir de 30 000 5 % de remise appliquée sur les sommes supérieures à 30 000 dollars

À partir de 50 000 5 % de remise supplémentaire sur les sommes supérieures à 50 000 dollars

Supérieur à 75 000 5 % de remise supplémentaire sur les sommes supérieures à 75 000 dollars

Tableau 9.3. Services pouvant être exclus des prestations par personne(suite)



189

difficiles à appliquer car il faut s’entendre sur la façon de compter les ressources et laremise.

Les formations générales

Les formations générales du personnel ne sont généralement pas facturées au client, saufaccord explicite entre les parties. Si l’on recherche des programmeurs Java, par exemple,et que l’on trouve d’excellents profils en C++, le prestataire organisera à ses frais lesformations qui conviennent pour rendre les collaborateurs pleinement opérationnels surles développements en Java. Le prestataire ne pourra ni refacturer les temps de formation,ni les heures supplémentaires éventuelles qu’il devra engager.

Il est sans doute bon de définir précisément ce que sont les formations générales. S’ils’agit de former à un langage standard, il est clair que ce sera une formation générale,mais considérera-t-on que l’apprentissage des interfaçages avec SAP ou avec d’autresprogiciels de forte diffusion du marché est une formation standard ? Selon le projet et lescompétences demandées, il est recommandé de lister les compétences générales etcelles qui seront réputées spécifiques du projet.

Parfois, le prestataire proposera de placer un nouveau collaborateur dans l’équipe sans lefacturer durant un ou deux mois à titre de formation. Ce mode de formation par immer-sion ralentit le travail du personnel en place, mais le stagiaire produit rapidement untravail qui rattrape le temps perdu en formation.

Les formations spécifiques

Les clients qui utilisent des technologies rares ou qui ont besoin d’utiliser certains progi-ciels du marché dans leurs développements ne peuvent s’attendre à ce que le prestatairedispose de candidats connaissant ces produits ou même qu’il puisse les trouver facile-ment.

Certains de ces progiciels sont relatifs à un marché vertical, à une activité donnée ou sontassez confidentiellement utilisés. Le client doit alors prendre en charge la formation dupersonnel à ces technologies ou s’entendre contractuellement avec le prestataire pourque les formations soient à sa charge.

Dans la mesure du possible, les formations sont données en offshore, en envoyant unformateur sur place. Quand cela n’est pas possible, il peut être nécessaire d’organiser lesformations chez un prestataire agréé en local. Cela peut soulever des difficultés si, parexemple, le client est en France et que les organismes de formation locaux ne proposentque des sessions en français. Il faut en ce cas organiser des formations dans un pays oùles formations sont effectuées en anglais. Si la formation est assurée en Grande-Bretagne,un organisme doit inviter formellement les stagiaires. Cette procédure administrativeexige que l’hôte s’engage moralement que ses invités respecteront les lois du pays,notamment celles relatives à l’immigration.

Il est généralement préférable de trouver un organisme de formation dans le pays del’offshore ou dans un pays proche afin d’assurer ces prestations chez le prestataire oudans un pays ne posant pas de problèmes.

Le contrat note clairement les formations qui sont sous la responsabilité du prestataireet celles qui sont refacturées ou assurées par le client.



190

Les services complémentairesLes services complémentaires peuvent être la source de dépenses importantes, qui vien-nent s’ajouter aux prestations de base. Il est recommandé de négocier précisément lesniveaux de service attendus et la partie qui les prend financièrement en charge. Certainsservices exigent des précautions particulières, comme la mise à disposition des licenceslogicielles chez le prestataire.

Les services complémentaires peuvent être forfaitisés et s’ajouter au coût du personnelou refacturés au réel. Lors de la négociation du contrat, il est recommandé de s’entendresur un tarif par personne sans services complémentaires. On listera tous les servicesforfaitisés, et on négociera le coût de chacun d’entre eux. Ces coûts seront ajoutés au tarifde base des collaborateurs pour obtenir des services forfaitisés.

Le tableau 9.5 récapitule les services complémentaires que l’on peut trouver dans unerelation avec un prestataire en offshore. Certains services sont intégrés aux prestationshumaines tandis que d’autres sont régularisés sur présentation des frais réels. Le tableauindique les points qui requièrent une attention particulière lorsque le service est inclusdans les prestations et lorsqu’il est facturé séparément. Sans être exhaustive, cette listedonne un bon aperçu des points à considérer.

Tableau 9.5. Services complémentaires aux prestations humaines

Service Inclus dans les prestations Non inclus dans les prestations

Ordinateur de travail pour les informaticiens

Préciser la périodicité de remplacement des machines et la façon d’en choisir les modèles

Prévoir les règles de remplacement et les budgets

Serveur de fichiers Définir si le serveur est dédié ou partagé, ainsi que les caractéristiques et la dispo-nibilité.

Prévoir les règles de remplacement et les budgets

Serveur de test ou de déploiement

Non recommandé Étant donné le coût élevé des plates-formes et la faible prédictibilité de leur durée de vie, il est préférable de prévoir un achat refacturé.

Imprimante et autre périphérique

Habituellement inclus sur les petits projets

Lorsque leur utilisation est dédiée à une équipe, ces périphériques et leurs consommables sont souvent refacturés au réel.

Bande passante Internet réservée au client

Le prestataire inclut généralement dans le coût des prestations l’accès à Internet de sa société et une bande passante non garantie. Ce n’est acceptable que pour les faibles besoins en bande passante.

Si l’on souhaite disposer d’une bande passante importante, il est préférable de prendre un accès dédié refacturé.

Frais de commu-nication téléphonique

Les frais de communication standards sont généralement inclus dans les pres-tations. Les communications téléphoni-ques sont limitées.

La refacturation au réel des frais télé-phoniques permet aux équipes en offshore d’utiliser plus librement le téléphone.



191

Le client doit prévoir un budget pour les services complémentaires. Il doit égalementprévoir les accroissements de certaines factures lors des remplacements du matériel.L’expérience montre que le client n’a habituellement aucun problème pour acheter pourle prestataire le matériel nécessaire en offshore en début de contrat mais qu’il a tendanceà oublier les budgets nécessaires à son remplacement.

Forfaitisation des services complémentaires

On peut décider de lier le paiement des services complémentaires à chaque employé sousla forme d’un surcoût du tarif de base. Cette forfaitisation suppose que le prestataire

Service Inclus dans les prestations Non inclus dans les prestations

Frais de recrutement Les frais de recrutement ne sont généra-lement pas refacturés au client.

Les frais occasionnés par des demandes particulières (annonces, etc.) peuvent être refacturés.

Locaux Les locaux font généralement partie de la facturation de base et ne font pas l’objet de paiements complémentaires.

Les locaux peuvent être refacturés s’ils correspondent à des exigences précises du client.

Air conditionné (salle serveurs ou de travail)

Habituellement inclus sans paiements spécifiques

Non recommandé

Agencement des locaux

Habituellement inclus sans paiements spécifiques

Non recommandé

Service de sécurité élevée

Les services de sécurité élevée (gardien de nuit, vidéosurveillance, etc.) peuvent être inclus dans la facturation.

Ces sommes peuvent être refacturées au réel afin de faciliter le changement des règles.

Contrôle d’accès Généralement inclus lorsque le presta-taire dispose naturellement d’un tel système.

Les installations peuvent être refactu-rées au client si les demandes sont spécifiques.

Bureau pour accueillir les visiteurs

Ces frais sont parfois refacturés selon le taux d’utilisation des salles.

Non recommandé

Administration de réseau avec gestion de la messagerie

Pour les petites équipes, ces services sont généralement inclus.

Pour les grosses équipes, ces services sont généralement refacturés ou bien des ressources sont ajoutées à l’équipe en place.

Licences des logiciels standards (Office, Exchange, systèmes d’exploitation, etc.)

Habituellement inclus Non recommandé, car la responsabilité du contrôle des licences serait en partie chez le client.

Licences des logiciels non standards

On peut les inclure lorsque ces produits sont déjà déployés chez le prestataire.

Il est recommandé d’acquérir ces licences pour le prestataire lorsque ces produits sont déployés pour un client de façon dédiée.

Tableau 9.5. Services complémentaires aux prestations humaines(suite)



192

s’engage sur un niveau de service minimal défini contractuellement. Par exemple, labande passante sur Internet est clairement définie et mesurée afin d’évaluer si le presta-taire tient ses engagements.

Les prestations qui sont le plus souvent incluses au forfait sont typiquement la mise àdisposition du réseau local, incluant sa maintenance et son administration, les serveursde fichiers, les postes de travail des informaticiens, les frais de téléphone et la bandepassante Internet. Si le client a des exigences particulières, ces prestations sont facturéesindépendamment.

Le tarif de base du collaborateur se trouve ainsi augmenté de petites sommes complé-mentaires correspondant aux services forfaitisés. On voit de la sorte clairement que l’onpaye, par exemple, 60 dollars par mois pour le poste de travail du collaborateur, 50 dollarspour Internet, etc. Une telle approche permet de conserver le détail des services rendussans entrer dans une facturation au réel, dont les très nombreux détails sont difficiles àcontrôler mensuellement. Les tarifs des services forfaitisés peuvent être revus annuelle-ment ou sur demande d’une des deux parties.

La forfaitisation est souvent accompagnée de certaines obligations pour le client. Parexemple, il s’engage à maintenir une équipe d’au moins quinze personnes durant un ande façon à couvrir l’achat des postes de travail par le prestataire.

Les licences logicielles standardsLe client n’a généralement pas la volonté de gérer les licences logicielles chez son pres-tataire en offshore. Il lui faut cependant se protéger des poursuites susceptibles d’êtreengagées contre lui si une organisation vient à découvrir que le prestataire emploie deslogiciels sans licence. Il est fortement recommandé d’exiger par contrat que les logicielsmis à la disposition du client par le prestataire soient acquis selon les dispositionslégales du pays du prestataire.

Le contrôle de la légalité des acquisitions des licences est de la responsabilité du presta-taire et non du client. Déjà difficile à réaliser dans la propre société du client, un telcontrôle est impossible de l’extérieur et à distance.

Le contrat prévoit que le prestataire s’engage à certifier par écrit que les licences utiliséesdans sa société sont légalement acquises selon les lois en vigueur dans son pays. Le clientdoit pouvoir exiger un tel certificat à tout moment.

La sécuritéLe client peut être tenté de prévoir un niveau de sécurité très élevé, surtout la premièrefois qu’il travaille avec l’offshore, qui peut se révéler très coûteux. Le client se rend vitecompte qu’il dépend en fait des règles de sécurité en place chez le prestataire, surlesquelles il a peu d’influence. Par exemple, il ne peut imposer des règles de sécuritéstrictes sur le réseau local si elles ne sont pas en accord avec celles mises en place chezle prestataire.

Si l’on souhaite un niveau de sécurité réellement élevé, il convient d’isoler la majeurepartie de l’équipe et de ses ressources et d’en prendre le contrôle en totalité. Le servicede sécurité est alors refacturé au client au réel.

Il ne faut pas oublier de prévoir le personnel dédié à l’administration locale de la sécurité.Ces dispositions doivent être prévues au contrat, car elles ont un impact important sur lescoûts et la structuration de la facturation.



193

Gestion des matériels et logiciels achetés en offshore

Lorsque des biens sont acquis par le prestataire pour l’usage exclusif d’un client et refac-turés à ce dernier, on peut considérer que le matériel appartient au client, même si, léga-lement, la question est beaucoup plus complexe. Il est recommandé de prévoir desclauses qui donnent au client un certain contrôle de ces matériels, notamment en fin decontrat, lors de la réduction définitive des effectifs, ou lorsque le client n’en a plus besoin,afin de pouvoir éventuellement les revendre et de déduire le prix de la revente de la factu-ration.

Il est illusoire d’envisager l’expédition de ce matériel chez le client. Les règles douanièreset le coût du transport rendent ces transferts peu intéressants. Cela vaut d’ailleurs dansl’autre sens, pour l’achat du matériel.

Il est important de suivre la vie du matériel en offshore. On peut demander au prestatairede transmettre une liste de tout le matériel (roster) acquis par le client avec les informationsqui permettent de suivre le parc (date d’achat, localisation, état de fonctionnem ent, etc.).Cela permet d’identifier le matériel en panne, détruit, volé ou perdu et d’agir en consé-quence. Cette liste peut être communiquée avec chaque facture afin de s’assurer qu’elleest mise à jour régulièrement.

Le prestataire s’engage à protéger les licences de tous les logiciels qui ont été mis à sadisposition par le client. Cette protection vise notamment la communication de ces logi-ciels à un tiers qui les reproduirait pour les placer sur le marché du logiciel dans le paysde l’offshore. Cette clause contractuelle doit être claire et être accompagnée d’un devoird’information aux collaborateurs en offshore.

Assurance-vol et incendie

Le matériel mis à la disposition du prestataire doit être couvert par une assurance-vol etincendie souscrite par le prestataire. Le client peut exiger une copie du contrat d’assu-rance pour en vérifier l’existence.

Le plus souvent, il s’agit du contrat couvrant tous les biens et locaux du prestataire. Il n’estcependant pas rare que des prestataires n’aient aucune assurance pour couvrir leurs locaux .

Bureaux visiteurs et salles de réunion

Les prestataires en offshore ne prévoient pas systématiquement de réserver des espacesde travail à l’accueil des visiteurs ou pour organiser des réunions. Si l’on veut être certainde disposer de ces salles, il faut les prévoir contractuellement.

Le prestataire peut demander au client une participation financière, qui est généralementforfaitisée.

Appartement en offshore

Si des visites des représentants du client sont régulièrement effectuées chez le presta-taire, on peut se demander si l’hôtel est la meilleure solution. Dans certains pays, leshôtels de qualité sont coûteux et offrent un service médiocre. On peut préférer demanderau prestataire de louer un appartement sur place à l’année, permettant éventuellementd’y conserver certaines affaires personnelles.

Ce type de prestation est pratiquement toujours refacturé au client.



194

Qualité du cadre de travailOn peut demander au partenaire de garantir un cadre de travail propre et confortable pourl’équipe dédiée au client. Le niveau de qualité demandé peut être supérieur aux condi-tions que le prestataire a l’habitude de fournir à ses collaborateurs.

Les engagements minimaux peuvent être les suivants :

• surface minimale par collaborateur ;

• air conditionné et ventilation des salles ;

• éclairage par lumière naturelle ;

• qualité du mobilier et de l’éclairage électrique ;

• propreté des locaux ;

• propreté des lieux d’aisance.

On peut ajouter d’autres éléments si l’on considère qu’ils sont importants. Il n’y a pas lieupour autant d’exiger des conditions très au-dessus de celles que l’on trouve dans lesmeilleures sociétés du pays. Si des travaux sont nécessaires ou si les coûts sontimportants, le prestataire ne manquera pas d’augmenter ses tarifs pour couvrir lesdépenses.

À l’inverse, si le partenaire n’assure pas les engagements définis contractuellement, onpeut prévoir une pénalité, par exemple de 5 à 10 % des sommes facturées.

Il est difficile de définir les détails d’application des pénalités. S’il manque un seul élément,doit-on appliquer la pénalité complète ou au prorata des exigences ? La pénalité doit-elles’appliquer si l’air conditionné tombe en panne et n’est pas réparé avec promptitude ?Malgré ces difficultés d’application, l’ajout de pénalités au contrat offre un moyen depression efficace lorsque le prestataire manque clairement à ses engagements.

Gestion des factures

La facturation des prestations est toujours un sujet délicat. L’établissement des facturesest difficile puisque l’on doit tenir compte des absences, rattrapages et heures supplé-mentaires, ainsi que des services complémentaires refacturés, qui demandent parfois unsuivi spécifique.

Des termes de paiement trop agressifs peuvent mettre les prestataires dans l’embarras,surtout lors des premiers mois du partenariat, où le prestataire engage des dépensesimportantes.

On trouve fréquemment des erreurs dans les factures sur des montants relatifs assezfaibles. Bien souvent, le prestataire est de bonne foi. Si le client exige des factures exacteset réclame des ajustements successifs, ces derniers risquent de retarder ses paiements etde perturber le déroulement des prestations.

Les termes de paiementLes sociétés occidentales sont habituées à négocier des termes de paiement qui leur sontfavorables. En France, par exemple, il est fréquent de recevoir des factures dont le termeéchu est à soixante jours fin de mois, payables le 10 du mois suivant, soit trois mois



195

après leur date d’émission. Les prestataires en offshore ne sont pas coutumiers de cestermes de paiement. Dans leur pays, les factures émises sont généralement payablesà réception.

Les prestataires qui n’ont pas travaillé avec la France peuvent même ne pas réaliser quede tels termes existent. S’ils sont peu méticuleux, ils risquent de ne pas aborder le sujetet de découvrir avec horreur que les paiements se font attendre.

Bien que cela puisse ne pas être en accord avec les règles comptables du client, le paie-ment des factures recommandé est à réception ou à trente jours au maximum. Ces termesde paiement garantissent la meilleure productivité en phase de démarrage.

Paiement sans délai

Les factures du prestataire deviennent assez complexes dès que les équipes dépassent uncertain seuil. Par expérience, si l’équipe atteint plus de trente collaborateurs, les facturescomportent presque toujours des erreurs de quelques pour cent du montant de leurmontant.

Les échanges pour corriger les factures sont souvent longs. Si certaines demandes decorrection sont justifiées, d’autres relèvent d’erreurs d’appréciation du client. Parexemple, une personne absente une journée, alors que cette journée est facturée, peutavoir effectué un rattrapage, ou bien cette absence peut venir en compensation d’heuressupplémentaires.

Un prestataire qui n’a pas de réserves importantes de trésorerie peut ne pas régler lespleins salaires de ses collaborateurs tant qu’il ne reçoit pas son paiement. Il est toujourspréférable que le client paie promptement ses factures pour maintenir la motivation descollaborateurs et ne pas repousser les meilleurs profils.

On peut prévoir, par exemple, que la facture du prestataire soit envoyée par e-mail avantle 10 du mois pour les services du mois précédent et que le paiement soit effectué avantle 20. Un tel arrangement permet aux collaborateurs de connaître la date de paiement deleurs salaires, ce qui est le plus important pour leur motivation.

Pour pouvoir payer le prestataire rapidement, il faut avant tout éviter les multipleséchanges de rectification des factures. Le mode de règlement illustré à la figure 9.1 estrecommandé, car il permet d’éliminer totalement les retards de paiement dus aux rectifi-cations de factures.

Si le client fait de réels efforts pour payer rapidement le prestataire, ce dernier doit êtreclairement contraint de payer l’équipe dans les temps. Il peut être utile de mentionnerdans le contrat que l’on a défini des dates limites pour la présentation de la facture, lespaiements et le versement des salaires.

Le contrat peut aussi prévoir que les collaborateurs soient payés dans les temps même sile client paye son prestataire en retard. On peut exprimer une limite à cet engagement duprestataire en précisant que cet engagement n’est valide que si les sommes dues etéchues sont en deçà d’un certain seuil.

Une pénalité de retard peut être définie en cas de retard de paiement des salaires de plusd’une semaine, par exemple.



196

Paiements partiels des facturesLorsque le client constate que les services prévus au contrat ne sont pas assurés correc-tement, il peut vouloir forcer le prestataire à respecter ses engagements ou à améliorerson service.

Les manquements du prestataire peuvent être très divers, comme un contrôle d’accès quin’est toujours pas en place, une discipline lâche, des négligences sur certaines commandes,des départs nombreux résultant de fautes de management du prestataire, etc. Il est bon deprévoir les moyens d’exercer une pression forte, mais raisonnable, sur le prestataire pourle contraindre à agir. Certains engagements peuvent être accompagnés de pénalités s’ilsne sont pas respectés, par exemple.

Figure 9.1. Processus de paiement des factures du prestataire



197

Après plusieurs échanges de messages sans effet, le client voudra le plus souvent forcerle prestataire à respecter ses engagements. L’arrêt du paiement des factures n’est pas unebonne solution, car elle engendre des situations de tension, qui peuvent nuire à la pour-suite du partenariat.

Pour que la pression soit efficace, il faut à la fois que le prestataire soit puni et que lessalaires des collaborateurs soient protégés, faute de quoi on effectue la pression avanttout sur soi-même.

Un bon compromis consiste à prévoir dans le contrat que le paiement d’une partie de lafacture est retenu jusqu’à la correction du problème constaté. Cette partie ne sera resti-tuée en totalité que si certaines conditions sont vérifiées, comme le paiement régulier descollaborateurs et de certains services, tels que les abonnements à Internet.

Pénalité de retard de paiement du clientDe nombreux prestataires souhaitent motiver le client à payer ses factures sans délai.Certains d’entre eux proposent une réduction de 1 ou 2 % en cas de paiement immédiatde la facture par virement ou encore une pénalité pour retard de paiement à appliquer surla facture suivante selon un barème défini. Parfois, bonus et pénalités s’appliquent selonla date du paiement (un bonus en cas de paiement rapide et une pénalité en cas deretard).

La pénalité de retard peut être perçue par le client comme un droit à payer en retard etcomme une obligation pour le prestataire à honorer ses engagements à l’égard des colla-borateurs, ce qui n’est probablement pas l’objectif du prestataire.

La clarté est de loin préférable sur tous ces sujets essentiels au bon fonctionnement del’équipe. Au lieu de chercher à les éviter, mieux vaut s’entendre clairement sur un fonc-tionnement. Il est clair que les prestataires en offshore ont de faibles réserves de tréso-rerie. Si le paiement de la facture n’est plus directement lié au versement des salaires descollaborateurs, la négociation sur les termes de paiement et les pénalités de retarddevient plus facile, comme avec n’importe quel fournisseur.

Rétention de paiement et suspension de serviceDans le cas où le prestataire ne tiendrait pas ses engagements, le client peut souhaiterdisposer du droit de suspendre ses paiements. Celui-ci se donnera ce droit même si celan’est pas explicitement exprimé dans le contrat.

Dans tous les cas, il est bon de se protéger de la suspension de service du prestataire pourretard de paiement.

On peut, par exemple, limiter la suspension de service aux cas où les retards de paiementdépassent un seuil donné. Par exemple, on peut indiquer que si les sommes dues etéchues au prestataire sont d’un montant supérieur à un montant fixé à l’avance, le pres-tataire pourra suspendre la fourniture du service. On précisera alors que les sommesrestent dues par le client.

Les augmentations de tarifLes augmentations de tarif des prestations en offshore sont un autre sujet délicat.

Le client est généralement d’accord pour que le prestataire ajuste ses tarifs pourconserver une marge proche de celle qu’il a négociée au début du partenariat. Le client



198

souhaite aussi que son équipe reçoive un niveau de salaire en accord avec ceux pratiquéslocalement et que celui-ci soit régulièrement réévalué pour rester équilibré avec lemarché.

Les salaires étant souvent exprimés en dollars, ils se trouvent parfois fortement dévaluéslorsque le taux d’inflation en dollars en offshore est important, surtout lorsque le dollarperd régulièrement de sa valeur par rapport aux autres grandes devises (euro, yen et livreanglaise).

Il n’y a pas de raison de refuser que les tarifs du prestataire soient revus à la hausse pourpermettre aux collaborateurs de son équipe de maintenir leur pouvoir d’achat. Pourautant, il n’est pas acceptable que le prestataire en profite pour augmenter sa marge, àmoins que cela ne fasse l’objet d’une négociation spécifique.

L’ajustement des prestations sur un taux d’inflation en dollars n’est que partiellementutile. À défaut d’une meilleure méthode, on peut la retenir, mais en l’ajustant sur unmélange de taux d’inflation en dollars et en euros afin d’éviter les effets d’une forte déva-luation d’une des deux monnaies.

Si le taux d’inflation est une bonne base de calcul, il n’est pas toujours représentatif del’augmentation des salaires moyens des informaticiens dans le pays de l’offshore, qui estparfois bien plus importante que l’inflation. Comme il n’existe pas d’indicateur fiable surce sujet, le client a tout intérêt à rester ouvert à des ajustements complémentaires s’ilssont correctement justifiés par le partenaire. Le client jugera comme bon lui semble de ladécision à adopter.

Gestion des équipes

Les possibilités de management des équipes par le client sont plus ou moins intrusiveset peuvent fortement influencer la collaboration avec le prestataire.

La flexibilité des équipes dont le client souhaite disposer peut aussi poser des problèmescomplexes au prestataire, qui doit ajuster ses effectifs comme il convient.

Les conditions et limites des actions du client doivent donc être définies et cadrées dansle contrat de partenariat.

Précautions quant au statut des collaborateursComme expliqué précédemment, il est important de se protéger contre d’éventuellesactions en justice visant à démontrer que les collaborateurs du prestataire sont desemployés déguisés du client, avec tous les avantages et protections qui l’accompagnent.Ce type de démonstration s’appuie généralement sur le fait que les collaborateurs reçoi-vent directement leurs ordres du client et que le prestataire n’a aucun rôle hiérarchiqueréel.

Pour éviter cela, le contrat doit clairement spécifier que les collaborateurs en offshore nesont pas des employés du client et qu’ils ne peuvent faire valoir ce statut. Il faut égalementfaire attention à certaines clauses. Par exemple, il faut éviter de demander que le clientcontrôle les salaires des collaborateurs du prestataire ou qu’il les manage directement.



199

Mieux vaut exposer que les directives du client sont communiquées au prestataire afind’être appliquées par son management.

De même, certaines lois imposent que l’emploi de personnel en régie à un même postesoit limité à une durée maximale, au-delà de laquelle le personnel concerné doit êtreembauché par le client. Il est important de considérer que le terme « régie » est abusifdans le cas de l’offshore puisqu’il s’oppose simplement au mode forfait. En réalité, il nes’agit pas vraiment de régie mais d’un équivalent de l’expression anglaise time and material,qui indique que l’on paie pour le temps passé et les dépenses occasionnées. Il s’agit doncd’une prestation de services réalisée par le prestataire dans ses locaux, selon les direc-tives du client.

Si le client choisit d’envoyer un de ses employés chez le prestataire pour assurer le mana-gement de l’équipe, il est essentiel de faire viser le contrat par un avocat pour s’assurerque cela ne pourra être interprété dans le sens d’un statut d’employeur du client. Cerisque réel ne doit pas être pris à la légère, car les conséquences peuvent être très lourdes.

Le statut d’employé du prestataireCertains prestataires emploient des collaborateurs sans pour autant les embaucher offi-ciellement. Cette situation peut être dangereuse à plusieurs titres, comme expliqué auchapitre 3. Le contrat doit prévoir que tous les collaborateurs travaillant pour le clientsoient des employés officiels du prestataire. Si le prestataire sous-traite certaines réalisations,il doit en notifier le client.

On peut demander au prestataire d’insister sur les règles de sécurité et de confidentialitésur lesquelles on souhaite que les collaborateurs s’engagent sciemment. Ces engage-ments peuvent faire l’objet d’un document de type NDA (Non Disclosure Agreement)signé par le collaborateur au moment où il rejoint le projet et conservé à la fois par lui-même et par le client.

Le NDA expose les accords de confidentialité, en insistant sur la définition des informa-tions confidentielles et sur la propriété intellectuelle afin d’en protéger la communicationet d’interdire l’introduction de code source qui appartiendrait à des tiers. Il précise enoutre que le personnel n’est pas autorisé à communiquer à des tiers les logiciels mis à sadisposition par le client en vue d’une distribution dans le pays de l’offshore. Il insisteenfin sur les clauses qui subsistent après le terme du contrat d’embauche, notamment laconfidentialité des informations.

Dans le cas où un collaborateur quitte le projet, qu’il reste chez le prestataire ou non, ilest recommandé de lui transmettre une copie de ce document pour lui rappeler les enga-gements qu’il a signés et qui survivent à son départ du projet.

Constitution des équipesIl est indispensable de maîtriser à tout moment les procédures relatives aux embauches.Un organigramme cible, maintenu par l’équipe en offshore, tient en permanence à jour laplace de chacun dans l’organigramme, la date prévue d’arrivée, les qualités et compé-tences recherchées, etc. Ce document doit être prévu contractuellement et servir de réfé-rence pour suivre les embauches.

Si l’on recherche des collaborateurs qui possèdent certaines caractéristiques communes,comme des traits de caractère (capacité à travailler en équipe) ou un niveau de maîtrise



200

d’une langue de travail (anglais ou français), ces dernières doivent être clairement expri-mées dans le contrat, avec le niveau attendu lorsqu’il est possible de le définir. Ellespeuvent toutefois rendre les recrutements plus difficiles et avoir une influence sur lesniveaux de prix pratiqués, et donc sur le tarif des collaborateurs.

Pour chaque poste, les caractéristiques que devront présenter les candidats sont égalementconsignées.

Le contrat doit exprimer comment les candidats seront recrutés, c’est-à-dire si le clientdéléguera totalement le processus de validation au prestataire ou s’il y sera intégré. Il estrecommandé que le client valide les candidats sélectionnés afin que l’équipe soit construiteavec des personnalités avec lesquelles il aime travailler. Ce processus peut être sommai-rement présenté en annexe du contrat.

Le niveau de validation des candidats présentés au client doit être défini afin de s’assurerque, du point de vue du prestataire, chaque candidat remplit les caractéristiques deman-dées. Lors de l’entretien avec le client, un document pourra résumer les avis despersonnes ayant rencontré le candidat et son CV. Le prestataire peut proposer de comblerpar des formations les lacunes des candidats.

Durant ces entretiens, le client valide surtout la personnalité et les capacités du candidat.Le client peut accepter ou refuser le candidat sans avoir à se justifier, même s’il est forte-ment recommandé qu’il en explique les raisons. Sans règles strictes du processus derecrutement, le prestataire peut avoir tendance à présenter tous les candidats quienvoient leurs CV, surtout si le client a déjà refusé plusieurs candidats et que le presta-taire se sente frustré de voir un filtre sévère appliqué à sa sélection.

Il faut également définir le statut des candidats qui ont passé les tests du prestataire avecsuccès mais qui n’ont pas encore été validés par le client. Si le client se rend très souventen offshore, on peut demander à ces candidats d’attendre sa prochaine visite. Dans lamajorité des cas, le prestataire pourra vouloir retenir le candidat. Certains prestatairesacceptent de prendre le candidat dans leur équipe gratuitement jusqu’à sa validation parle client. D’autres souhaitent que ce temps soit facturé au client si le candidat est accepté.

Lorsqu’un candidat est accepté, il est bon de prévoir une période d’essai, non qu’il soitdifficile de s’en séparer par la suite, comme dans de nombreux pays occidentaux, maispour tenter de combler certaines de ses lacunes, comme la maîtrise de l’anglais. Celapermet d’enfoncer le clou sur certaines caractéristiques que l’on souhaite vraiment voirrespecter.

Flexibilité des équipesLa flexibilité des équipes est l’avantage le plus important que recherche le client quitravaille avec des ressources en offshore. Cette flexibilité est facile à organiser mais peutêtre lourde à gérer pour le prestataire.

Le contrat précise que le client peut retirer du projet toute personne qu’il désire avec unpréavis court et raisonnable, le plus souvent un mois, sans avoir à motiver sa décision. Leclient peut expliquer ses décisions, et a même intérêt à le faire, mais sans y être obligécontractuellement.

Pour les collaborateurs qui ont clairement montré des faiblesses ou une attitude inappro-priée, le client peut demander leur retrait de l’équipe immédiatement en motivant sadécision.



201

Les collaborateurs qui sont retirés de l’équipe du client ne sont pas nécessairement licen-ciés par le prestataire. Ce dernier peut les affecter à d’autres projets, leur demanderd’attendre le prochain contrat ou les licencier.

Les contraintes relatives aux recrutements peuvent être définies dans le contrat. Le pres-tataire ayant tout intérêt à trouver les candidats très rapidement, il n’est toutefois pasindispensable de prévoir de contraintes à ce sujet.

Les règles de réduction des effectifs peuvent être très dures pour le prestataire, qui peutse retrouver avec des locaux vides, des postes de travail non amortis ou de nombreuxemployés dont il doit se séparer, au risque de ternir sa réputation et d’avoir plus de malà recruter de nouveaux collaborateurs par la suite.

Le prestataire peut demander que la réduction des effectifs soit graduelle. Par exemple, ilpeut demander qu’on ne réduise pas les équipes de plus de sept personnes ou 15 % dunombre d’employés en place chaque mois. Les réductions graduelles ne sont cependantpas particulièrement recommandées, car elles entretiennent dans l’équipe du prestataireun climat de méfiance mois après mois.

Retrait de ressources à l’initiative du prestataireLe prestataire peut souhaiter retirer des ressources de l’équipe du client et les remplacerpar d’autres. Il peut, par exemple, les placer sur un autre projet, où elles seront plus utiles,ou bien le collaborateur peut lui-même souhaiter quitter le projet. Celui-ci a peut-êtrel’impression de stagner, d’avoir des difficultés avec son client qui ne reconnaît pas sescapacités ou encore de s’entendre mal avec ses collègues.

Les conditions de sortie d’un collaborateur à son initiative ou à celle du prestatairedoivent être définies et ne sont pas nécessairement symétriques des conditions de sortied’un collaborateur à l’initiative du client.

On peut, par exemple, prévoir :

• Une notification d’une durée supérieure, par exemple de deux mois, alors que la noti-fication du client est d’un mois.

• La possibilité de refuser le départ du collaborateur, par exemple si l’on estime qu’il estutile à la sortie du produit ou que sans lui le risque de retard augmente.

• L’engagement du prestataire à trouver un remplaçant de niveau comparable soumis àl’acceptation du client.

• Un temps de formation du remplaçant à la charge du prestataire, notamment si lesdeux personnes sont présentes ensemble sur le projet durant la période de transition.

Embauche de collaborateurs par le clientLe client peut souhaiter embaucher localement certains collaborateurs du prestataire enoffshore. Ce genre d’initiative est excellent pour le moral de tous les collaborateurs, qui yverront une possibilité d’émigrer dans d’excellentes conditions.

Le prestataire peut souhaiter interdire au client de faire des propositions d’embauche àses collaborateurs ou les permettre en échange d’une indemnité.

Isolement des équipesLorsqu’on constitue une équipe assez importante, de plus de vingt personnes, on peutdemander qu’elle soit physiquement isolée du reste des collaborateurs du prestataire.



202

Les salles de travail ne sont alors autorisées qu’au personnel travaillant pour le client. Lecontrat doit prévoir les règles d’accès à ces salles, notamment pour les visiteurs et lespersonnes travaillant dans d’autres départements, comme l’informatique interne.

Le but de cet isolement est d’accroître la protection des informations confidentielles.Cela pose assurément des problèmes si le client modifie souvent la taille de ses équipes.Le prestataire peut demander de facturer le lieu de travail, indépendamment desressources humaines.

Le montant des salairesOn peut demander contractuellement que le prestataire verse des salaires à ses collabo-rateurs dans la moyenne haute de ce qui est pratiqué dans son pays par les prestatairesoffshore. Même s’il n’est pas si facile d’établir cette moyenne, tant les données sontsubjectives et difficiles à vérifier, on peut se protéger de la sorte des départs de personnesà la recherche d’un meilleur salaire.

Il est dangereux de demander un contrôle total des salaires des collaborateurs enoffshore, car cela pourrait s’apparenter à une reconnaissance d’embauche. Le clientsouhaite avant tout que la valeur d’un collaborateur soit correctement corrélée avec sonsalaire, surtout pour les collaborateurs dont il est modérément satisfait. Il souhaite enoutre que les salaires de chaque collaborateur soient le plus proportionnels possible à lasatisfaction qu’ils procurent.

On peut espérer que le prestataire reste ouvert à une relation de confiance et qu’il acceptede discuter des rémunérations de ses équipes. Il est néanmoins peu probable qu’il laisseson client définir les salaires de ses collaborateurs. Après tout, il sait sans doute mieuxadresser ce sujet que son client.

Promotions et réorganisationsLe client peut demander à organiser son équipe comme il le souhaite pour l’adapter aumieux à ses ambitions et à son mode de travail.

Les réorganisations doivent être discutées ouvertement avec le management du presta-taire avant d’être mises en place et les avis des uns et des autres écoutés. Lorsque leséquipes sont réduites, il convient de respecter un équilibre des compétences des collabo-rateurs. Le client est toujours tenté de ne conserver que les meilleures ressources, quisont probablement aussi les mieux payées. Le prestataire n’a pas forcément le même avis,car si tous les collaborateurs devaient être facturés au même tarif, il perdrait automati-quement une part importante de sa marge.

Le contrat peut spécifier la façon dont les réorganisations sont gérées. Il est préférableque le client s’assure contractuellement d’avoir le dernier mot sur ce sujet, même s’il atout intérêt à traiter ces réorganisations en bonne entente avec le management du pres-tataire. En tout état de cause, il n’est pas souhaitable que le client se voie imposer despersonnes dont il ne veuille pas à des postes clés ou qu’il ne puisse engager la réorgani-sation qu’il désire.

Les employés à temps partielLa motivation d’utiliser des employés à temps partiel peut provenir du client, qui n’a pasbesoin de certaines ressources à temps complet, ou du prestataire, qui ne souhaite pas



203

allouer une de ses ressources rares sur un unique projet. Ces profils à temps partiel sontgénéralement de haut niveau et peuvent avoir un point de vue de valeur lors des réunionsde management.

Il est recommandé de fixer contractuellement les périodes où ces personnes à tempspartiel travaillent pour le client de façon à s’assurer que l’on peut facilement organiser desréunions avec eux. On vérifiera notamment que toutes les personnes à temps partielpourront être présentes simultanément pour organiser des réunions de direction deprojet.

Les doubles emplois des collaborateursComme expliqué précédemment, certains collaborateurs peuvent avoir l’habitude decumuler des emplois. Cette pratique pouvant être très pénalisante pour le client, il estimportant d’exiger dans le contrat que les collaborateurs ne puissent cumuler les emplo is.Cela doit en outre être inclus dans le contrat d’embauche du collaborateur.

Mise en place et suivi de la méthode

Le problème de la mise en place d’une méthode chez le prestataire ne se pose réellementque sur les projets d’une certaine taille. Les petits projets mettent en effet rarement enœuvre une méthodologie formelle et s’appuient surtout sur les compétences du chef deprojet en offshore et sur une bonne entente entre le client et le prestataire. Les chosessont très différentes lorsqu’on travaille sur un projet important, qui doit être structuré etorganisé.

Dans les projets au forfait en offshore, les aspects procéduraux sont entièrement à lacharge du prestataire, lequel met en place la méthodologie qu’il maîtrise bien. Le plussouvent, celle-ci est présentée au client et fait partie des motivations du choix du presta-taire. Le client n’a pas de raison de s’immiscer dans les procédures ou le fonctionnementinterne du projet si le projet progresse correctement. Le client ne s’intéresse au fonction-nement interne du projet que lorsque le prestataire se montre incapable de tenir sesengagements.

Les projets en régie, au contraire, sont gérés par le client selon la méthodologie qu’il achoisie. Celle-ci se fond le plus souvent avec ses propres méthodes internes en tenantcompte des particularités de la gestion de projet en offshore. Dans les sections quisuivent, nous nous concentrons surtout sur les aspects contractuels relatifs aux méthodeset procédures des projets en régie permettant au client de contrôler la gestion du projet.

Imposer ses procédures au prestataireTous les prestataires ne sont pas prêts à adopter les procédures que leur présentent leursclients. Certains travaillent essentiellement au forfait et ne souhaitent pas que le clients’immisce dans la gestion du projet. Ils pensent que leur méthodologie est supérieure,que leur personnel est formé pour la mettre en œuvre et que les exigences du client surce sujet ne peuvent qu’engendrer moins de rigueur et moins de contrôle. Le contrat doitdonc prévoir que le client puisse mettre en place la méthodologie qu’il souhaite.



204

La mise en place d’une méthodologie doit s’accompagner d’outils pour la mettre enœuvre et en forcer la bonne application, le plus souvent au travers de workflows configu-rables. Ces outils pouvant se révéler très coûteux, le contrat doit définir qui du client oudu prestataire fournit les licences correspondantes. Dans certains cas, le prestataire endispose déjà et peut simplement acquérir des licences complémentaires. Le déploiementde ces outils exige souvent des machines dédiées et une bande passante importante pourassurer les synchronisations entre les référentiels.

Les rapports de suiviLes procédures qui sont mises en place par le client visent généralement, en plus d’uneorganisation rigoureuse du projet, à obtenir une meilleure transparence de la progressiondes tâches de développement. Certains rapports fournis au client par le prestatairepeuvent être perçus comme intrusifs, voire hostiles par les collaborateurs.

Les rapports de suivi de projet sont généralement peu critiqués s’ils rapportent la réalitésur la progression du projet, les statistiques sur les anomalies, etc. En revanche, cesrapports peuvent susciter le malaise s’ils sont perçus comme excessivement intrusifs,comme les suivis des entrées-sorties, des salaires versés, de l’attribution de bonus, etc.

Le client doit tenter d’identifier les informations potentiellement conflictuelles qu’il pour-rait demander au prestataire et inclure dans le contrat la fourniture des informationspermettant d’effectuer un suivi fin du travail. Le mieux est de communiquer un modèle desdocuments de suivi pour valider que le prestataire puisse fournir toutes les informationsdemandées.

Le suivi de projet au forfaitSi le prestataire travaille au forfait, il est théoriquement entièrement responsable dusuccès du projet. Le client ne doit pas s’interdire pour autant de contrôler la progressiondu projet et de s’assurer que les engagements du prestataire sont remplis dans les tempset avec la qualité requise.

Si le projet progresse de façon impeccable, le client n’a aucune raison d’intervenir chez leprestataire, ses interventions pouvant engendrer des perturbations sur le projet ou mêmedes retards.

Si les livraisons intermédiaires sont en retard ou d’une qualité insuffisante, le client peutse trouver en difficulté, et les pénalités sont pour lui une bien maigre compensation. Leprojet peut être critique et lié à d’autres projets dont il est une pièce essentielle. La péna-lité pour retard que le prestataire doit payer ne compense pas, de beaucoup, le préjudiceet le trouble organisationnel qu’apporte un retard important de livraison. La pénalitépour retard n’a pour fonction que de motiver le prestataire à faire des efforts pour livrerdans les temps. S’il ne parvient pas à gérer le projet, on est dans une tout autre situation,et aucune pénalité ne pourra le contraindre à corriger ses erreurs ou à mettre desressources supplémentaires sur le projet.

Trop souvent oubliés, les trois points suivants devraient être mentionnés dans toutcontrat de projet au forfait :

• Disposer d’une transparence totale du projet en cours de réalisation par le biaisd’audits ou de n’importe quelle communication régulière d’éléments de suivi duprojet. Par exemple, le client peut souhaiter analyser certains codes source pour



205

s’assurer du respect des standards ou suivre les anomalies détectées. On peutdemander que le prestataire dispose de moyens automatisés pour assurer la transpa-rence, notamment au travers d’outils de gestion de référentiel ou du changement(anomalies et évolutions) et d’outils de suivi du planning.

• En cas de retards significatifs une notion complexe à définir en cours de projet ,le client peut intervenir directement sur les procédures en place, voire déléguer despersonnes pour la gestion du projet. Le statut des pénalités est à prévoir dans le casoù le prestataire perd le contrôle de son projet. Une pénalité fixe pourrait couvrir enpartie les efforts supplémentaires auxquels le client est contraint. En effet, le client quiveut sauver son projet doit parfois assurer lui-même la gestion du projet. On peutimaginer un débrayage du projet du forfait en mode régie, si le client le souhaite et estcapable d’assumer ce rôle.

• En cas d’impossibilité à rétablir une saine gestion de projet, le client peut prévoir unelivraison en l’état de la totalité du projet pour le confier à un autre prestataire ou lereprendre lui-même. Les conditions financières doivent en ce cas être précisées pourdéterminer quand le client peut déclarer l’arrêt du projet chez le prestataire et lescompensations à envisager.

D’autres clauses sont bien sûr à prévoir. Les contrats au forfait n’offrant pas beaucoup despécificités en offshore, ils ne sont pas détaillés dans l’ouvrage, qui se concentre sur lesprojets en régie.

Communication et références

Lors de ses démarches commerciales et marketing, le prestataire souhaite démontrer sescapacités à réaliser des projets et veut souvent faire état du ou des projets réalisés.

Dans l’esprit du partenariat, il est normal que le client aide le prestataire à trouverd’autres affaires, ne serait-ce qu’en servant de référence. Le client n’a pas pour autantenvie de trouver des articles de presse faisant état de certaines de ses réalisations enoffshore. Si le client est une société de services, par exemple, il peut craindre que sesclients ne lui demandent une tarification réduite, puisque les coûts de développement enoffshore sont connus pour être faibles. Quant aux éditeurs, ils peuvent craindre quel’image qui découle de l’utilisation des ressources en offshore n’incite à douter de leursolidité ou de la qualité de leurs réalisations. Beaucoup d’autres raisons peuvent justifierque les clients ne souhaitent pas que leur partenariat avec un prestataire en offshore soitcommuniqué publiquement.

Il convient donc de placer dans le contrat les règles que l’on souhaite voir respecter par leprestataire lors de ses communications, que ce soit sur son site Internet, lors de prospec-tions, au cours de communications publicitaires ou encore lors d’échanges directs avecun prospect qualifié.

Voici quelques options possibles :

• Toute communication à la presse ou à un média de communication de masse (pério-dique, quotidien, télévision, site Internet, publipostage, mailing de masse) doit êtreavalisée par le client, qui pourra choisir d’interdire la publication de toute informationà son sujet.



206

• Le prestataire peut faire référence au projet réalisé avec le client sans citer son nom.Le client validera le texte utilisé lors des communications de masse afin qu’il ne puisseêtre trop clairement identifié.

• Les communications orales ou écrites à destination d’une société peuvent mentionnerle nom du client. On peut ajouter au besoin des conditions restrictives, comme inter-dire de présenter l’architecture technique de la solution développée. Le client peutdemander une validation des textes de ces communications.

Trop souvent, des communications incontrôlées donnent lieu à des communications erro-nées, parfois dévastatrices.

On peut prévoir des pénalités importantes en cas de non-respect de ces clauses. Autre-ment, le prestataire calculateur se dira que l’effet positif qu’il peut tirer de cette commu-nication est plus important que l’éventuelle mauvaise humeur de son client.

La rupture du contrat

La rupture d’un contrat est toujours un moment difficile pour celui qui n’en a pas prisl’initiative et le plus souvent pour les deux parties. Il est important de décrire les engagement sdes deux parties lors de cette période délicate.

Le client comme le prestataire peuvent chercher à rompre le contrat. Dans tous les cas, ilfaut terminer proprement le partenariat et donc à la fois les services fournis par le presta-taire et les obligations de paiement du client. Il faut aussi prévoir la restitution de toutesles informations propriétaires et confidentielles. Le prestataire peut demander que leclient verse la totalité des factures en souffrance avant de remplir toutes ses obligations.

Comme évoqué précédemment dans ce chapitre, il est souhaitable de communiquer auxcollaborateurs un document leur rappelant leurs obligations quant à la confidentialité età la propriété des éléments en leur possession.

Les deux parties signataires du contrat ont un préavis souvent asymétrique à respecterpour retirer les ressources humaines de l’équipe des collaborateurs engagés sur un projet,le prestataire devant généralement respecter un préavis plus important que le client.

ÉTUDE DE CAS

Un prestataire bavard

Un éditeur de logiciel développe un produit dont une version spécifique est exploitée par unebanque qui met ce service à la disposition de ses clients d’entreprise. Le produit est développé enoffshore. Un journaliste, faisant un article sur l’offshore, parle à l’un des responsables marketing duprestataire offshore. En l’absence de règles, et puisque l’éditeur est très peu connu, contrairement à labanque qui exploite le service, le responsable marketing omet de mentionner l’éditeur et expliqueque le prestataire réalise un produit qu’il décrit en détail pour une banque dont il mentionne le nom.Cette communication approximative, mêlant vérité et inventions mettant en valeur le prestataire,est immédiatement remarquée par la banque, qui menace de cesser d’utiliser le produit et demettre un terme à ses relations avec l’éditeur. Elle exige en outre des dommages et intérêts pourcette communication abusive qui nuit à son image.



207

Les biens achetés au réel, comme le matériel et les serveurs, peuvent être revendus (leprix de la revente venant en déduction des factures dues par le client), être envoyés auclient ou abandonnés au prestataire. Le matériel prêté par le client lui est retourné à sesfrais lorsque c’est possible.

Les services récurrents qui sont refacturés au réel et peuvent faire partie d’un abonne-ment avec une durée minimale doivent être traités contractuellement. Par exemple, si leprojet s’arrête et que l’abonnement à une ligne Internet soit d’au moins deux ans en offshore ,il faut trouver le moyen de gérer cela contractuellement.

Une fois les services terminés, le contrat peut rester en effet, même s’il ne donne lieu àaucun service ni aucun paiement. C’est un cadre contractuel, qui permet si on le souhaitede démarrer d’autres services sur les mêmes bases.

Protéger la propriété intellectuelle au-delà du partenariatQuelle que soit la raison de la fin du contrat de partenariat, que ce soit un différend ouune fin prévue des prestations, il faut s’assurer que les clauses sur la protection de lapropriété intellectuelle lui survivent.

Si on le juge nécessaire, on peut donner à chacun des collaborateurs un document leursignifiant que les informations confidentielles qui leur ont été communiquées sonttoujours protégées par les accords sur la protection de la propriété intellectuelle et parles accords de confidentialité, pendant une durée spécifiée au contrat. On peut demanderque ce document soit signé, mais on ne peut contraindre les collaborateurs à le faire. Defait, ces règles s’appliquent même si le collaborateur ne signe pas le document.

Il faut aussi prévoir la restitution ou la destruction de tous les éléments dits confidentiels(documents, répertoires sur le disque dur, référentiels, etc.) Le contrat mentionne quedes audits ayant pour objectif de vérifier la bonne application de ces directives pourrontêtre effectués localement après la fin du contrat pendant une durée à déterminer.

Dans la réalité, il est rare que le prestataire détruise effectivement tous ces éléments.Il en conserve généralement une sauvegarde, même s’il clame qu’il a tout restitué oudétruit, sans intention de nuire. Beaucoup de chefs de projet aiment aussi à conserver lestrophées de leurs missions et à disposer d’une sauvegarde complète qui leur sert d’aide-mémoire sur certains sujets.

Arbitrage et médiationSi des conflits sérieux éclatent entre le prestataire et son client, il est bon de prévoir lerecours à la médiation ou à un arbitrage. Ce sont des procédures formelles, avec des arbitresou médiateurs compétents, qui respectent une charte officielle.

La médiation est particulièrement efficace. Les statistiques montrent que plus de 90 %des cas portés auprès des médiateurs mènent à une résolution à l’amiable du conflit.Dans le cas de l’offshore, le choix de la médiation est particulièrement important, car leconflit en justice est rendu fort complexe par la problématique transnationale.

Les services proposés par les médiateurs peuvent se faire en anglais si le besoin s’en faitsentir. Il est recommandé de demander à l’avocat qui valide le contrat d’y inclure uneclause de médiation avant de faire appel à la justice.



208

Conclusion

Le contrat est un sujet délicat, dans lequel le client cherche à définir clairement l’étenduede son contrôle sur les équipes que met à sa disposition le prestataire et souhaite à la foisse garantir des moyens d’action et responsabiliser le prestataire.

La plupart des thèmes contractuels participent à la définition d’un bon équilibre entre leprestataire et son client. Un contrat trop dur ou trop contraignant conduit le prestataire àadopter une attitude défensive consistant à préserver une marge suffisante par tous lesmoyens. Il se réfugie alors derrière le contrat pour faire valoir chacun de ses droits,remplace le personnel en place par des collaborateurs moins coûteux et oublie parfoisl’objectif de livraison final. À l’inverse, un contrat trop permissif laisse le client sansmoyens d’action efficaces pour imposer sa méthode de travail ou rectifier les erreurs.

Les recommandations de ce chapitre ne sont pas toujours toutes applicables. Certainesd’entre elles seraient impossibles en France, par exemple, comme le NDA signé parchaque collaborateur ou les réductions de salaire, alors qu’elles sont tout à la fois légales,acceptables et même courantes dans les pays de l’offshore.


PARTIE 33Gestion des projets

en offshoreCette partie traite de la réalisation des projets en offshore. Nous supposons icique le client a bien compris les mécanismes majeurs de l’offshore, que le projeta été soigneusement choisi et que le contrat qui le lie au prestataire est conçude telle sorte à lui donner un contrôle suffisant sur le déroulement des opéra-tions. Nous supposons également que le client a choisi de travailler essentiel-lement selon un mode régie, qui permet de profiter pleinement de tous lesavantages de l’offshore.

Un grand nombre des remarques qui parsèment les chapitres qui suivent pour-raient s’appliquer à des projets réalisés localement au lieu de l’offshore etporteraient probablement aussi pleinement leurs fruits. Ces bonnes pratiques,qui apportent gain de productivité et confort dans la gestion des projetslocaux, deviennent des garanties de succès lorsqu’on travaille avec une équipedistante.

Nous insistons particulièrement sur la gestion des ressources humaines etl’organisation hiérarchique, qui permet d’obtenir une forte adhésion des équipesau projet. Une bonne organisation des hommes est toujours beaucoup plusefficace que la mise en place d’une méthodologie stricte. Lorsque des hommesaux responsabilités clairement définies veulent faire aboutir un projet etmettent leur énergie en commun pour y parvenir, ils parviennent à contournerles défauts des procédures pour aboutir à un fonctionnement efficace.

La méthodologie est en revanche essentielle pour définir les éléments produitspar les différents intervenants, définir les workflows les plus importants etassurer une bonne compréhension de l’état du projet selon des indicateursobjectifs partagés entre les intervenants. L’approche itérative, qui est tropsouvent mal comprise, assure une saine pression sur les équipes et permet dejuger la progression du projet sur les réalisations et non pas sur des estima-tions humaines. Elle apporte en outre une unité des éléments créés dans les



210

équipes. La planification, une tâche toujours délicate, est elle-même mieux définie parl’approche itérative.

La qualité des réalisations en offshore est parfois mise en question. Nous portons uneattention particulière à montrer comment la contrôler pour atteindre des niveaux de finitionsatisfaisants à toutes les étapes.

Le déploiement sur des plates-formes en architecture n-tiers à plusieurs serveurs, avecdes configurations parfois complexes du middleware, peut être source de problèmes.Cette phase est trop souvent négligée, car on se concentre avant tout sur l’écriture duprogramme en offshore plutôt que sur les tâches périphériques. Une autre activiténégligée à l’offshore est l’exploitation des plates-formes de production. Cette tâche estgénéralement confiée à du personnel local alors que l’offshore peut apporter plus de flexi-bilité pour la supervision et la haute disponibilité de la plate-forme.


211

Chapitre 10

Les points clés de la gestion de projet

en offshoreCe chapitre traite essentiellement du commencement de la relation de partenariat avec leprestataire en offshore, un moment à la fois excitant et délicat de la vie du projet. Lessujets abordés peuvent aussi s’appliquer à un projet en cours que l’on souhaite réor-ganiser.

Si les principes énoncés valent pour les projets locaux comme pour les projets en offs-hore, ils prennent une importance accrue lorsqu’on travaille avec des équipes distantes.Ces principes doivent constituer le socle de l’organisation du manager du client qui gèredes projets en offshore.

Une bonne organisation des hommes et des principes méthodologiques affirmés sont lesmeilleures garanties de succès.

La satisfaction du client

Les participants au projet chez le prestataire et le client sont impatients de démarrer leprojet encore exempt de défaut et de déception, et chacun se persuade que cette fois le projetse déroulera sans anicroche. Chez le client, le budget attribué est convenable. On y aprévu les dépenses pour les effectifs, le matériel et les voyages. Le prestataire affiche lui-même un excellent état d’esprit et désire très bien faire. Armé de l’expérience de tous lesproblèmes rencontrés dans le passé, il pense pouvoir les éviter et atteindre un fort niveaude satisfaction du client.

Les différences culturelles sont alors perçues comme intéressantes et enrichissantesintellectuellement. On va apprendre à travailler avec une équipe que l’on ne connaît pasencore, mais qui a déjà démontré son expertise. De part et d’autre, on veut montrer cedont on est capable et on souhaite que le projet qui démarre soit un exemple.

Le démarrage du projet est un moment où le prestataire et le client s’observent et oùtoutes les actions et réactions vont avoir une importance amplifiée, susceptible de laisserdes traces durables. Chez le prestataire, c’est un moment de tension, car le moindre accro-chage avec le client peut donner lieu au remplacement du personnel qui en est la cause,voire à l’annulation du contrat si la confiance devait chuter.



212

Les premiers problèmes surgissent avant même de transmettre le moindre exécutable.Les ressources n’ont peut-être pas les compétences souhaitées ; le prestataire présentecertaines personnes qui ne conviennent pas du tout, ce qui inquiète le client ; certainschefs de projet sont de fortes têtes ; les locaux de travail sont décevants ; etc. Les motifsd’irritation s’accumulent, mais au fond tous sont assez faciles à corriger.

La figure 10.1 illustre l’évolution de la satisfaction du client telle qu’on la constate le plussouvent lors d’un premier projet en offshore. On y voit que le crédit que l’on accorded’emblée vacille dès que le travail commence. La déception est généralement immenselors des premières livraisons pour ensuite remonter vers un niveau de satisfaction enrapport avec les attentes de l’équipe de management du client. Le retour à une satisfactionacceptable dépend de l’expérience des personnes impliquées pour trouver rapidementdes solutions aux sujets d’insatisfaction.

Lors du démarrage du projet, on découvre comment l’équipe distante accepte et appliqueles procédures. Ce sont encore des sujets complexes. Ce chapitre traite de cette phasedifficile, où le travail réalisé est beaucoup moins important que la façon dont on met enplace les équipes et de bonnes pratiques de gestion de projet, tout en sachant qu’on n’estpas en contact quotidien avec les équipes distantes. Cet éloignement exige rigueur etorganisation pour faire en sorte que le projet trouve par lui-même les meilleurs cheminslorsque les procédures font défaut.

Pour atteindre les meilleures chances de réussite et éviter quantité de pièges, le managerdu client doit garder à l’esprit certains principes clés. Bien que ces principes soient simples,on constate qu’ils sont rarement appliqués dans la réalité. Paradoxalement, on rencontrenombre de managers qui expliquent fort bien ce qu’il faut faire et agissent à l’opposé.

Figure 10.1. Satisfaction du client sur le premier projet


Chapitre 10 – Les points clés de la gestion de projet en offshore

213

Garder une vision claire des objectifs de management

Le travail avec l’offshore a rapidement tendance à devenir touffu et confus. Des questionsde tous ordres surgissent, et de nombreux domaines organisationnels qui se règlentd’eux-mêmes localement demandent en offshore une intervention du client. Il est trèsfacile de se laisser absorber par les problèmes secondaires portés sur le devant de lascène par le prestataire et qui nuisent à la gestion des tâches importantes.

La coopération commence souvent alors que le contrat n’est pas finalisé. Comme cedernier est assez volumineux, les révisions peuvent être longues à négocier et à valider.On s’est certes entendu sur les bases essentielles du contrat, comme les tarifs, les heuressupplémentaires, les matériels et les services additionnels les plus importants, maiscertaines clauses sont en cours de relecture et d’amendement. Les tensions qui survien-nent pendant cette période peuvent suspendre la signature du contrat et amplifier lesattitudes défensives, ce qui peut nuire au démarrage du projet.

Dans un projet en régie, le client est le donneur d’ordres, et il dirige à tout moment leprojet. Il peut lui arriver de changer d’avis, de se tromper et de se raviser. Ces change-ments se produisent tout le long du projet, qu’il s’agisse d’adaptation à des conditions demarché qui ont changé, de technologies qui ont évolué ou encore de recherche d’unemeilleure productivité. Certains de ces changements peuvent viser à se protéger defaiblesses du prestataire ou au contraire à profiter de certains points forts que l’on nesoupçonnait pas avant de commencer.

Dans tous les cas, il convient de s’assurer que les décisions sont toujours contrôlées parle client et d’éviter que le prestataire ne fasse certains choix pour son propre confort,surtout pendant les ajustements de procédures qui ont lieu en début de contrat. Les pres-tataires en offshore savent que c’est un moment où ils peuvent assez facilement imposerleur point de vue.

Dans ce brouhaha de décisions de tous ordres, où les sujets importants sont mêlés auxsecondaires, il est essentiel que le manager du client conserve des objectifs organisation-nels clairs et qu’il les considère comme un fil directeur pour toutes les décisions qu’ilprend. Cette recommandation s’applique tout autant à la phase de démarrage du projetqu’à la suite des réalisations.

Le tableau 10.1 récapitule les principaux objectifs du projet, que le manager du client àl’offshore doit garder à l’esprit.

Tableau 10.1. Objectifs clés du projet

Objectif Commentaire

Constitution et validation du noyau dur de l’équipe

Il faut se concentrer sur les principaux profils manquants. Les compétences méthodologiques et en management sont souvent les plus difficiles à pourvoir, car elles découlent davantage d’un trait de caractère (souvent rare en offshore) que d’un apprentissage.

Assurer les formations fonctionnelles et techni-ques

Les compléments de formation doivent être assurés auprès des personnes qui sont capables d’en assimiler le contenu et de le restituer aux équipes. Certaines formations peuvent être complexes à organiser et impliquent un délai important.



214


Mise en place des méthodes essentielles

À tout moment dans le projet, des processus doivent couvrir les nouvelles acti-vités que l’on démarre. Il faut que les procédures soient à la fois suffisantes pour coordonner efficacement le travail des équipes, bien adaptées aux besoins et évolutives pour s’harmoniser avec les conditions d’application.

Mise en place des outils de production et méthodo-logiques

Pour être réellement efficaces, les procédures doivent s’accompagner d’outils adaptés afin d’en assurer la mise en œuvre et, lorsque c’est possible et néces-saire, d’en forcer les workflows.

Mise en place des services complémentaires essentiels

Certains services complémentaires insuffisants ou mal rendus peuvent devenir bloquants. Il faut parfois pousser le prestataire à mettre en place des services qui lui coûtent et qu’il retarde volontairement.

Définition fonctionnelle du produit à réaliser

Cette activité est essentielle. Il peut y avoir deux phases. La première, souvent imprécise, correspond à l’expression des besoins. La seconde consiste en la mise aux normes de ces spécifications, peut-être sous la forme de cas d’utilisa-tion et de spécifications supplémentaires afin de les exploiter au mieux selon la méthodologie appliquée.

Mise en place du processus itératif

Le processus itératif est primordial pour gérer un projet efficacement en offshore. C’est le seul moyen de juger de l’avancement du projet et d’en tirer les conclusions pour améliorer les points faibles. Cela nécessite une bonne compréhension du sujet et une certaine rigueur de toutes les phases de la réalisation.

Définition de l’architecture technique, du choix du middleware et de la validation des faisabilités

L’infrastructure technique du projet est la base du développement. Les choix techniques impliquent des validations de la faisabilité ou de la pertinence des solutions proposées. D’autres choix garantissent l’utilisabilité du produit final ou le respect de certaines exigences (performances ou déploiement). Ces choix doivent être validés aussitôt que possible pour ne pas découvrir des problèmes majeurs en fin de développement.

Mise en place des documents de suivi du projet et des plannings

Dès lors que le projet commence à se construire, même sur les phases de spéci-fication ou d’analyse, il convient de disposer des documents qui permettront de suivre la progression du projet et de vérifier la bonne tenue des objectifs finaux. La construction des plannings par itération est une approche importante de la gestion des projets en offshore.

Décision sur les phases d’analyse et de design de l’architecture et de la modélisation

Il est utile de bien poser les bases du développement que l’on souhaite réaliser, notamment dans la construction de l’architecture du produit afin de repérer les composants indépendants et les parties fortement réutilisées. C’est une phase qui peut être longue et qui doit précéder le démarrage du codage de l’applica-tion.

Vérification de la bonne application des normes et procédures

La mise en place des normes et procédures n’est utile que si elles sont pleine-ment utilisées. L’utilisation partielle de celles-ci mène à des suivis de progression approximatifs, et donc à de mauvaises décisions.

Tableau 10.1. Objectifs clés du projet(suite)



215

Les objectifs clés présentés dans ce tableau ne sont bien sûr pas exhaustifs. Chaqueprojet ayant ses spécificités, on trouvera des sujets particuliers à traiter ou d’autres quiprendront une importance plus appuyée. Les objectifs listés ici, à peu près dans l’ordreoù on les rencontre, conviennent cependant à nombre de projets.

Ces objectifs sont essentiellement organisationnels. Les chefs de projet en offshorepeuvent se sentir pressés par des objectifs opérationnels, comme la livraison d’analysesou de programmes, qu’ils jugent plus importants. Ils ont souvent l’impression que lestâches organisationnelles sont secondaires et qu’ils sont surtout jugés sur les tâchesopérationnelles et sur le respect de leurs engagements sur les livrables.

Pour que ces tâches organisationnelles progressent correctement, il faut qu’elles soientclairement identifiées comme des objectifs sur lesquels on jugera aussi les qualités descollaborateurs. On rencontre souvent des organisations où l’on attribue des priorités auxtâches à réaliser et où les tâches organisationnelles reçoivent une priorité moyenne et nesont jamais réalisées. Pour mettre en place les procédures qui conviennent, il est essentielde placer certaines de ces tâches en priorité élevée.

Si la mise en place de la méthodologie ne progresse pas correctement, on a tout intérêt àdédier une personne en offshore pour en garantir la mise en place. Il est assez courant demettre en place un mentor sur les procédures afin d’en assurer l’application.

EN RÉSUMÉObjectifs et personnes dédiées

Avec la distance, les problèmes de communication sont souvent plus intenses. Il faut se concentrersur certains objectifs organisationnels clairs qui structurent le projet et apportent productivité ettransparence, ainsi qu’un suivi plus aisé du projet.

En concurrence avec des objectifs directement opérationnels, les tâches organisationnelles sontsouvent délaissées par les chefs de projet. Il importe de s’assurer qu’elles sont bien intégrées dansleurs objectifs et de leur faire comprendre qu’ils seront aussi jugés sur leur volonté à appliquerméthodes et procédures.


Recherche de la qualité à tous les niveaux des réali-sations, notamment pour les tests unitaires

La qualité d’une réalisation passe par une recherche de la qualité à tous les échelons de la production. Tous les intervenants doivent rechercher cette qualité optimale dans leur domaine de responsabilité.

Mise en place d’un suivi de builds réguliers puis quotidiens et automatisés

La seule façon de s’assurer de la réelle progression du projet est le build pério-dique. Il apporte une meilleure compréhension des régressions et des problèmes d’assemblage des composants au cours du projet et permet de valider la progression des livraisons recettables.

Industrialisation et automatisation des tests

Les tests automatisés offrent une excellente appréciation de la qualité d’un build. Ils peuvent être effectués sur les builds quotidiens.

Automatisation des compi-lations et déploiements

L’automatisation du déploiement est essentielle pour assurer la fiabilité de la solution sur les plates-formes.

Tableau 10.1. Objectifs clés du projet(suite)



216

Transparence de la communication

La communication est rarement naturelle entre deux sites distants et requiert toujours uneffort important et volontaire. On ne se rend pas toujours compte de la quantité d’infor-mation qui est échangée entre les membres d’une équipe locale et son managementautour de la machine à café, au cours de déjeuners ou simplement lors de rencontresfortuites dans les couloirs. On prend la pleine mesure de l’importance de ces échangesinformels lorsqu’on les perd en travaillant avec une équipe distante.

Les collaborateurs, qu’ils soient locaux ou distants, n’aiment afficher ni leurs faiblessesni leurs échecs. Ils essaient de les masquer et de les corriger avant que leur hiérarchie s’enaperçoive et ne les reconnaissent que lorsqu’ils ne peuvent plus les cacher. Si cette atti-tude est humaine, elle n’en est pas moins préjudiciable lorsqu’on travaille avec uneéquipe en offshore et qu’on cherche par tous les moyens à détecter aussi tôt que possibleles problèmes pour trouver les actions correctives les plus appropriées.

Si l’équipe distante apprend à être transparente à tous les niveaux, le travail avec elle s’entrouve grandement simplifié. L’équipe distante ne peut être transparente que si le clientse montre juste et tolérant. Lorsque l’équipe distante, en essayant d’appliquer les recom-mandations de transparence du client, fait état de problèmes, qu’il s’agisse d’un retardque l’on anticipe, de personnel insuffisamment formé ou du départ inopiné d’un membreclé de l’équipe, il est primordial que le client réagisse. Il travaille alors avec le prestatairepour trouver des solutions. Il n’est pas question de chercher systématiquement les coupa-bles éventuels à punir. Les reproches seraient compris comme une forte réprimande. Dèslors, les managers du prestataire n’essaieraient plus de faire part de leurs difficultés etpréféreraient les masquer et essayer de les résoudre avant qu’elles soient découvertes.

Si une personne est clairement responsable de dysfonctionnements, surtout s’ils décou-lent directement de ses erreurs, il convient de lui apprendre à les éviter ou de le placer àun poste plus en accord avec ses qualités. La responsabilité de ces échecs est avant toutcelle du management de l’offshore ou du client qui n’a pas su placer la bonne personneau bon endroit et qui a donné au collaborateur des tâches au-dessus de ses capacités. Lepunir pour ne pas avoir atteint ses objectifs et le laisser à son poste sans changement estillogique. La punition n’a de sens qu’en cas de négligence ou d’une volonté manifeste demal faire. Si les managers de l’équipe distante connaissent certains problèmes mais lescachent au client, ils doivent être réprimandés.

Lorsqu’un problème est identifié, il se peut que le prestataire n’ait pas toutes les informa-tions nécessaires pour décider comment le corriger. Il se peut que le problème n’en soitpas vraiment un et qu’il découle simplement de modifications des priorités du client. Leclient peut prendre des décisions qui excèdent les responsabilités du prestataire. Il peut,par exemple, décider de retarder une version de quelques semaines ou de déplacercertaines fonctionnalités vers une release ultérieure. Le client doit alors repréciser lesengagements du prestataire afin de les adapter aux nouvelles priorités.

Lorsqu’un problème est détecté tôt, bien des moyens permettent de rétablir un bon fonc-tionnement, comme ajuster les effectifs ou redéfinir les contenus des versions. Lorsquele prestataire cache un problème en essayant de le résoudre par lui-même, il restreintrapidement le spectre des actions correctives à appliquer.



217

La transparence crée un état d’esprit qui conditionne la façon de collaborer entre le pres-tataire et le client. Sans elle, le client suppose que le prestataire cherche à lui cacher denombreux problèmes et passe son temps à tenter de les découvrir. De son côté, le pres-tataire pense avant tout à éviter les réprimandes et dissimule tout ce qui peut en occa-sionner. On connaît aussi ces attitudes de suspicion et de dissimulation avec les équipeslocales, mais la distance avec le site de production rend les défauts de communicationbeaucoup plus difficiles à gérer.

EN RÉSUMÉCommunication transparente

Une communication transparente entre le prestataire et le client découle d’un niveau de confiancefort et d’un véritable esprit de partenariat. Le prestataire fait état de ses difficultés au plus tôt pourrechercher avec le client les meilleures solutions. De son côté, le client se montre tolérant etconstructif pour traiter les sources des problèmes. La confiance qui va de pair avec cette communi-cation transparente rend le travail beaucoup plus productif, réactif et constructif, donnant à l’équipedistante une motivation plus forte et au client un confort équivalent au travail avec une équipe locale.

Gestion des risques

Il est important d’estimer en permanence quels risques sont susceptibles d’avoir unimpact sur le succès du projet. Pour une bonne gestion des risques, tous les membr esdu projet doivent s’exprimer sur le sujet, qui ne doit pas devenir un domaine réservé dumanagement.

Les personnes directement impliquées sur certaines tâches perçoivent mieux les risquesimportants. Chaque chef d’équipe peut donc rassembler les risques perçus par sonéquipe, même ceux qui se situent au-delà de la responsabilité personnelle de chacun.Une procédure peut permettre de discerner l’importance et la redondance de chaquerisque identifié et d’adresser les plus importants avec l’attention qu’ils méritent afin detrouver des solutions pour les réduire ou prévoir des actions de contournement.

Par exemple, si une personne travaille au développement de couches techniques quidoivent être fortement utilisées par les développeurs fonctionnels dès l’itérationsuivante, il peut savoir longtemps à l’avance que celles-ci ne seront probablement passuffisamment stables pour que le code fonctionnel s’appuie sur elles. S’il se fait entendresuffisamment tôt, il est possible de prévoir un autre ordonnancement des tâches pouréliminer les effets négatifs d’un retard anticipé.

Certains risques sont identifiés au-delà des responsabilités individuelles de celui qui lesmentionne. Ainsi, un développeur peut s’inquiéter de la difficulté à construire l’équipe detest ou de la capacité à tester la production.

Chaque tâche de développement peut être associée à un risque. Lorsqu’on traite pour lapremière fois une solution technique, on n’est pas certain de respecter une exigencede performance avec une technologie donnée, ou encore on s’inquiète de la qualité del’architecture d’un composant. Les exemples de risques sont donc très nombreux.

Dans tout projet, il convient d’éliminer au plus tôt les risques les plus importants. Celapermet de fiabiliser les projections en éliminant les facteurs d’incertitude mais aussi de



218

trouver des solutions de remplacement si un problème apparaît comme bloquant. Le risqueest un facteur décisif dans l’attribution des priorités des tâches.

EN RÉSUMÉGestion des risques

Tous les collaborateurs doivent pouvoir faire état d’un risque dans leur domaine de responsabilitécomme dans tout autre domaine. L’identification des risques est de la responsabilité de tous. Lesrisques sont traités selon leur importance fonctionnelle afin que le risk manager puisse définir despriorités. Il importe d’éliminer en premier lieu les risques élevés, de façon à apporter plus de stabilitéau projet et à se donner éventuellement le temps de trouver des solutions de contournement.

Bien que tous les collaborateurs puissent exprimer des risques, le risk manager est chargéde les rassembler dans une liste (voir modèle en annexe) aux côtés des actions correctivespossibles et de leurs chances de réussite. Chaque risque doit disposer d’un propriétaire(owner), qui a pour tâche de le documenter dans le temps et d’avertir le management si lerisque se confirme ou disparaît. Le rôle de risk manager peut exister sur tous les types deprojets, quelle qu’en soit la taille. Sur les petits projets, ce rôle peut ne consommer quequelques heures par mois, alors qu’il peut représenter une charge de travail importantesur d’autres projets.

Pour être efficace, il convient de classer les risques pour ne se concentrer que sur ceux quisont réellement importants. On peut appliquer avec succès une mesure des risques enmultipliant la probabilité que le risque se produise par l’importance du risque mesurée,par exemple, entre 1 et 10. On s’attache surtout à ce que la valeur des risques soit assezjuste en les comparant entre eux.

Les pondérations sont discutées lors des réunions de management de sorte que l’impor-tance et la probabilité attribuées soient en accord avec l’avis de chacun. En cas de désaccord,le risk manager propose les valeurs qui semblent les plus justes. Cette liste de risques estvivante. Les mesures sont revues périodiquement et ajustées en fonction de l’évolutionde la situation afin que les risques reçoivent toujours l’attention qu’ils méritent.

Recherche de la qualité

La qualité, comme la sécurité, est à la fois une des exigences les plus fortes et un desmaillons les plus faibles. Les collaborateurs ne se concentrent pas toujours suffisammentsur la qualité de leur production, surtout s’ils savent que leurs défauts seront détectés etcorrigés par la suite.

La livraison personnelle peut facilement devenir le but unique, indépendamment de laqualité du livrable, que l’on considère comme corrigible par la suite. Cette attitude estencore renforcée si des primes ne sont accordées qu’en fonction de la mise à dispositiondu livrable personnel, sans se soucier de leur qualité.

Cette attitude est particulièrement amplifiée avec les équipes distantes. On se rendmoins facilement compte à distance que des développeurs livrent précipitamment desprogrammes que l’équipe de test peut à peine compiler. Ils estiment que la livraison deleur production dans les délais est ce qui sera facilement remarqué, alors même que laqualité du livrable est toujours plus discutable.



219

Il en va de même des aspects procéduraux, qui sont souvent mal appliqués chez le pres-tataire, car difficiles à cerner. Comme les procédures sont aussi mal respectées locale-ment chez le client lui-même, les équipes distantes s’imaginent volontiers qu’elles n’ontpas à s’en soucier davantage.

Il faut être intransigeant sur le respect des procédures en offshore, qui doivent être prisesen compte au même titre que la mise à disposition du livrable. La tolérance que l’onconstate en local sur les processus s’explique par le fait que l’on mesure mieux le contexteet les efforts nécessaires pour parvenir à l’objectif souhaité lorsqu’on voit les hommes etles efforts fournis. La communication est aussi plus fluide, et les inquiétudes sont plusfacilement levées. À l’offshore, au contraire, où l’on ne voit pas les équipes qui réalisentle travail sans respecter les procédures, on est prompt à imaginer un immense laisser-aller ou une désorganisation inacceptable.

La qualité n’est pas un objectif facile à atteindre, et le laisser-aller sur ce sujet peut menerà des pertes de temps et de visibilité sur l’avancement d’un projet. Par exemple, il se peutque le temps de développement pour une première livraison approximative soit de vingtjours de travail et qu’il en faille trente de plus pour la finaliser avec le degré de qualitésouhaité. Si l’objectif de qualité avait été pris en compte immédiatement, il aurait étéatteint en trente jours tout compris.

La recherche de la qualité est garante d’un travail plus efficace à tous les niveaux. Lorsquele testeur affirme avoir exécuté son scénario de test avec attention, si l’on sait que lavolonté d’une qualité optimale existe, on peut penser que les tests sont bien réalisés.Sans cette volonté constante, rien n’est jamais sûr, les procédures dérapent, et personnene sait vraiment comment considérer une livraison lorsque son état de qualité est inac-ceptable.

Le respect de la qualité devrait être motivé par tous les moyens possibles, en rejetantsimplement les livrables qui ne respectent par les engagements de qualité et en motivantpar des primes le respect de la qualité. Par exemple, la faible quantité d’anomalies détec-tées lors de la livraison d’un programme aux tests peut être considérée comme unélément d’appréciation motivant une prime.

La planification du projet doit elle aussi tenir compte de la qualité des livrables. Il s’agitnon seulement de prévoir un livrable à une date donnée mais aussi de s’assurer que lelivrable ne sera considéré comme livré que s’il atteint un certain niveau de qualité. Si tousles intervenants tiennent compte de la qualité, leur planification devient ainsi plus juste.

EN RÉSUMÉLe critère qualitéLa qualité doit être considérée comme un critère d’appréciation du travail de chacun, au même titreque la remise des livrables dans les temps. Une telle pratique permet d’obtenir une meilleure fluiditédes procédures, une confiance dans les livraisons et une bonne estimation des charges et desplannings.

Procédures utiles

Lorsqu’on met en place un cadre procédural, il apparaît que les domaines que couvrentdes approches structurées, comme RUP ou XP, sont beaucoup plus vastes que ce dont on



220

a réellement besoin. Comme toutes ces procédures et documents ont une utilité plus oumoins grande, on se sent obligé de les mettre en place tout de même.

Par exemple, un document définit dans ces procédures le produit que l’on veut créer etles ressources à allouer au projet. Ce point peut souvent être un casse-tête à gérer. Si l’onconnaît ce que l’on souhaite créer, on ne sait pas toujours le définir précisément ni si l’on estprêt à garantir des moyens pour sa réalisation. Personne ne souhaite vraiment s’engagersur un tel document, qui peut faire l’objet de polémiques.

En réalité, ce document n’est pas bloquant quant à la méthodologie. Les ressources pour-ront être réduites en cours de projet, le contenu sera peut-être modifié et d’autres événe-ments viendront sans doute perturber le cours du projet. Dans tous les cas, le responsabledu projet s’adaptera pour faire fonctionner le projet au mieux, que ce document décrivantle contenu du produit souhaité et les moyens à mettre en œuvre existe ou non.

La mise en place d’une méthodologie peut être complexe ou fluide. La fluidité sera essen-tiellement le résultat de la mise en place des seules procédures réellement utiles aux yeuxde tous. La complexité provient le plus souvent de l’incompréhension des collaborateursou de la poursuite d’informations inexistantes ou sur lesquelles personne ne souhaites’engager. Les collaborateurs en offshore comprennent que l’on a besoin de workflow etd’éléments de suivi mais acceptent mal que les procédures soient approximatives ouinutiles.

Il convient alors de repérer toutes les procédures et normes qui sont réellement néces-saires et de les mettre en place en prenant soin de former le personnel non seulement surles procédures elles-mêmes, mais aussi sur le plan qualité complet en en expliquantl’utilité et la portée.

Pour être efficaces, faciles à appliquer et correspondant à la situation en cours, les procé-dures doivent être adaptées en permanence. Chaque participant doit pouvoir exprimerdes remarques, et ces dernières doivent être prises en compte pour assurer l’améliorationet l’efficacité des procédures. Les procédures seront alors fermement respectées, et l’onpourra considérer leur non-application comme inexcusable.

EN RÉSUMÉProcédures bien comprises

On veillera à mettre en place des procédures utiles et bien comprises par les personnes qui doiventles appliquer. On évitera de mettre en place des procédures ou normes dont l’utilité pratique estdiscutable, même si elles sont intellectuellement utiles. Les procédures doivent être en constanteadaptation pour être rendues fluides et efficaces et être appliquées par les membres du projet.

La méthode itérative

Le mode de travail itératif est l’une des clés de la gestion de projet en offshore. Ce modèlese définit par opposition au modèle en waterfall, ou en V, qui ne permet pas de détectersuffisamment tôt les problèmes ni de construire des plannings stables.

Le travail par itération est la base de la plupart des processus industriels modernes. Ils’appuie sur un découpage du projet en tranches de temps, souvent fixées par avance etd’une durée définie, dans lesquelles on distribue les tâches du projet de façon à éliminer



221

le plus tôt possible les incertitudes et les risques. On définit ainsi une feuille de routepour réaliser le projet en distribuant tout ce qui doit être réalisé dans ces itérations.

La figure 10.2 illustre le contenu des différentes itérations, montrant que l’importance destâches accomplies lors des itérations varie selon la phase du projet. Lors des premièresitérations, les activités relatives à la modélisation sont plus importantes, pour ensuitelaisser plus de place à l’implémentation et aux tests dans les itérations suivantes. Toutesles itérations incluent très tôt les activités d’implémentation (codage) et de test de façonà fournir des livrables exécutables qui démontrent les faisabilités et l’avancement duprojet.

Pour conduire efficacement une approche itérative, il convient de mettre en place unegestion stricte des exigences que l’on souhaite trouver dans le produit final. La grandemajorité des exigences correspond à des features fonctionnelles, mais on peut égalementy trouver des exigences sur les temps de réponse ou sur des choix technologiques.Chaque exigence reçoit une série d’attributs permettant de la qualifi er. On trouve typi-quement l’importance de l’exigence, le risque qui y est associé, sa stabilité (risque-t-onde modifier sa définition ?), sa complexité ou sa charge, les grandes dépendances(prédécesseurs), etc.

En utilisant les attributs, il est possible de définir une séquence théorique des exigencesà réaliser. Chaque société définira sa stratégie pour traiter ces exigences. On cherche, parexemple, à lever en priorité les risques et les incertitudes sur les faisabilités, les exigencesles plus importantes et celles qui sont les plus complexes. Cette séquence est utiliséepour ordonner le séquencement des réalisations.

Figure 10.2. Contenu des itérations



222

Défini grossièrement à partir de la gestion des exigences en début de projet, le contenude chaque itération est détaillé peu de temps avant son commencement. Cela permetd’être en phase avec les événements récents susceptibles de rendre certains objectifsinatteignables ou hors de propos.

Les objectifs doivent être ambitieux et réalisables. Ils concernent tous les membres deséquipes et tous les domaines du projet, qu’il s’agisse d’analyse, de développement, detest, de script, de procédure ou de déploiement.

À la fin de l’itération, on dispose généralement de livrables et si possible d’exécutables,que l’on peut recetter et comparer aux objectifs. L’objectif est de juger de la progressiondu projet en fonction d’éléments tangibles et non d’informations invérifiables fourniespar les chefs de projet. En l’absence de processus itératif, on est contraint de mesurer laprogression d’un projet en interrogeant les team leaders, qui gèrent les petites équipes dequelques personnes. Même s’ils sont au cœur du projet, leur avis n’est pas pour autantqualifié. Par exemple, un développeur peut ne pas objectivement savoir quelle quantitéde travail lui est nécessaire pour atteindre un livrable avec le niveau de qualité suffisant.L’expérience montre que les erreurs de plus de 100 % sont courantes sur ce sujet.

L’itération représente la réalité du progrès en comparant ce qui est livré à ce qui étaitprévu. Il faut que l’itération soit suffisamment longue pour permettre un réel accomplis-sement des équipes et suffisamment courte pour disposer de plusieurs itérations sur leprojet afin de mettre en place les actions correctives nécessaires. L’expérience montreque des itérations de l’ordre de quatre à six semaines conviennent assez bien aux projetsd’environ un an.

Le contenu de l’itération est stable puisqu’il concerne une durée assez courte, qui connaîtpeu de changements. Ceux-ci seront certainement planifiés sur les itérations suivantes enrespectant la stabilité de l’itération en cours. Les objectifs qui ne sont pas atteints sontalors de la responsabilité de l’équipe en charge de la réalisation. Cette dernière ne peutdès lors expliquer les retards par des événements extérieurs, comme des changementsd’orientation ou des décisions qui ont eu des effets plus profonds qu’on ne l’avait anti-cipé, le contenu de l’itération étant stable. Les retards sont le plus souvent dus à deserreurs d’appréciation ou d’anticipation. Par la suite, l’équipe fera plus attention à bienestimer les charges afin d’être capables de tenir leurs engagements, apportant ainsi plusde rigueur à la planification et incluant le niveau de qualité souhaité.

Le planning détaillé permet aussi de mesurer pleinement l’impact des déficiences dans lacommunication, notamment lorsque des questions restent longtemps sans réponses, oules retards de livraison des éléments dont dépendent les réalisations. Dans tous les cas,il sera possible d’identifier la cause des retards et son responsable afin d’engager desactions correctives.

À la fin de chaque itération, on tire les conclusions qui conviennent. Elles permettent demettre à jour les attributs des exigences, fort de l’expérience de l’itération qui se termine.On pourra ainsi noter qu’un risque est levé, prendre en compte de nouvelles prioritésfonctionnelles ou ajuster les prévisions de charge.

La figure 10.3 illustre la façon dont les conclusions de l’itération qui se termine affectentles itérations suivantes. L’itération qui suit directement celle qui se termine est pratique-ment entièrement définie par les tâches qui sont déjà engagées et ne peut être fortement



223

modifiée. Les conclusions de l’itération 2, par exemple, commencent à avoir une réelleinfluence sur les itérations 4 et suivantes.

Le contenu de l’itération suivante est défini avant la fin de l’itération et ajusté jusqu’à lafin de celle-ci.

Les conclusions que l’on peut tirer de l’itération sont de plusieurs ordres :

• Quels sont les objectifs atteints et ceux qui ne le sont pas ? Pour quelle raison ne sont-ils pas atteints ? Quelles actions peuvent être engagées pour rattraper ce retard aucours de l’itération suivante, ou bien le planning global doit-il être ajusté ?

• Y a-t-il des causes récurrentes de non-atteinte des objectifs ? Est-ce du fait d’uneéquipe ? La cause peut-elle être éliminée ?

• Quelle expérience peut-on en tirer pour les itérations suivantes sur les hommes et lesprocédures ? Quels ajustements sont nécessaires ?

• Le planning des itérations du projet est-il compatible avec l’expérience que l’on aacquise ? Doit-on le revoir pour prendre en compte l’expérience accrue ?

D’autres avantages de l’organisation en itérations ne manquent pas d’être constatés,notamment les suivants :

• On conserve une pression plus forte sur les équipes en offshore. Elles ont toujours desobjectifs à court terme et démontrent leur réelle capacité à produire.

• Les objectifs sont confrontés aux réalisations. Il n’y a pas de marge de négociation pourexpliquer que l’objectif est pratiquement atteint et que les causes ne viennent pas del’équipe mais de l’extérieur.

• On détecte les problèmes beaucoup plus rapidement que dans les cycles en waterfall caron traite tôt les sujets les plus critiques, et l’on en déduit la faisabilité des réalisations.Plus on avance dans les itérations, plus elles sont réalistes et fiables. L’expériencemontre qu’à partir de 30 ou 50 % du projet, les itérations sont très fiables et permettentd’anticiper précisément la progression du projet.

Itération 1

Terminée

Archivée

Itération 5

Future

Ebauche de planning

Itération 4

Future

Planning en construction

Itération 3

Prochaineitération

Planningprécis

Itération 2

En cours

Planning validé

Instant présent

Flexibilité du contenu des itérations

Figure 10.3. Stabilité du contenu des itérations



224

• On favorise le travail en équipe puisque les objectifs à atteindre peuvent être multi-disciplinaires. Par exemple, un objectif de livraison testée signifie que le produit estlivré et pleinement testé. Le développeur qui sait être jugé sur cet objectif va certaine-ment accompagner la livraison jusqu’à la fin des tests.

• Les objectifs organisationnels et de qualité ne sont plus oubliés. Ils font partie inté-grante des objectifs de chaque itération puisque seuls les livrables respectant cesobjectifs sont considérés.

EN RÉSUMÉLe processus itératif

Le processus de développement par itération présente bien des avantages et devient incontour-nable dès lors qu’on travaille en offshore. Il permet tout à la fois de mesurer la réalité de la progres-sion du projet, de conserver une productivité optimale de tous les membres des équipes et deconstruire des planifications plus sûres, qui s’appuient sur une expérience objective. De plus, il favo-rise le travail d’équipe pour assurer les objectifs.

De petites équipes couvrant tous les domaines

Lors de la distribution des rôles des équipes, les points clés suivants doivent être présents àl’esprit :

• Les équipes sont de petite taille, entre deux et cinq personnes, de façon à ne pasdemander de capacités de management aux team leaders. Ces derniers doivent être capablesd’appréhender facilement la totalité du travail de leur équipe.

• Les responsabilités sont clairement définies pour tous les rôles. Il est important queles problèmes rencontrés en offshore trouvent une réponse sur place, qu’il s’agisse desujets techniques, d’informatique interne, fonctionnels, architecturaux ou de procé-dure. Certains responsables en offshore peuvent solliciter leurs correspondants chez leclient pour obtenir les réponses qui leur font défaut sur le site.

• Les objectifs de chaque collaborateur ne s’arrêtent pas à la livraison de leur productionpersonnelle. Celle-ci contribue à un objectif d’équipe qui vise à livrer un exécutable dequalité convenable aux utilisateurs. Chaque collaborateur doit comprendre que seslivrables personnels ne sont importants que dans la mesure où ils contribuent aulivrable final. Il doit accompagner sa production pour s’assurer de son bon usage dansla suite du projet. Par exemple, le développeur ne doit pas se désintéresser de l’activitéde test qui suit la livraison de son code, mais, à l’inverse, il doit s’assurer que le testeurpeut travailler sur sa production dans les meilleures conditions afin de fournir unlivrable de qualité à l’utilisateur.

• Tous les collaborateurs sont pairs. Les développeurs ne sont pas supérieurs auxtesteurs parce qu’ils seraient plus compétents techniquement. Le rôle souvent dénigréde testeur s’avère d’une importance capitale puisqu’il représente l’utilisateur final.

• La qualité est la préoccupation constante de tous les membres des équipes.

• L’action et l’initiative dans le respect des procédures sont privilégiées au détriment del’attentisme et de la passivité. L’absence d’action doit être sanctionnée et non uneinitiative malencontreuse.



225

Responsabiliser l’offshore

Le client de l’offshore a souvent le réflexe initial de ne pas faire confiance au prestataire.Ne connaissant pas les managers, il ne souhaite pas les responsabiliser et veut garder lecontrôle des décisions. Ce type d’approche déresponsabilise les équipes en offshore ettend à réduire significativement la productivité.

À partir de petites équipes, aux domaines de responsabilité circonscrits, il convient aucontraire de confier des responsabilités à chaque membre de l’équipe, qui doit se sentircapable d’agir, d’étudier les effets de ses actes et de les corriger. Le client a tout intérêt àrespecter cette liberté de décider et à ne pas imposer systématiquement ses décisions.

Par exemple, une équipe en difficulté doit pouvoir organiser d’elle-même l’attributiontemporaire de une ou deux personnes provenant d’autres équipes pour terminer certainestâches. La validation finale sera sans doute confirmée par le client, qui jugera de la perti-nence de cette décision après en avoir discuté avec des managers du prestataire.

La responsabilisation s’applique à tous les étages de la hiérarchie. Il faut œuvrer pourqu’elle soit distribuée dans les équipes. Si des managers refusent de déléguer leursresponsabilités, les effets positifs de la responsabilisation des équipes en offshore sontperdus.

Gestion des tâches clés

Lorsque des tâches clés ne sont pas bien assurées en offshore, il faut en contraindre lagestion avec toute l’attention voulue.

Un premier moyen pour cela est de les inscrire dans les objectifs des itérations et de leurattribuer des responsables bien identifiés. Si cela ne suffit pas, on peut dédier une personneà la gestion exclusive de ces tâches. Cela revêt une importance toute particulière pour lestâches organisationnelles ou la mise en place de procédures.

EN RÉSUMÉGestion des tâches clés

Certaines tâches clés, organisationnelles ou relatives aux procédures difficiles à mettre en œuvre,risquent de rencontrer l’inertie des équipes. Pour parvenir à les réaliser, il faut les inscrire commeobjectifs clairs des itérations et dédier une personne à leur gestion. C’est tout l’avantage des faiblescoûts des ressources en offshore que de pouvoir se le permettre.

Conclusion

Il est de première importance de comprendre la portée des recommandations abordéesdans ce chapitre pour la gestion des projets en offshore. On peut penser que ces remarquess’appliquent de la même façon à tous les projets informatiques, ce qui est vrai en règle



226

générale. Dans le cas des réalisations en offshore, ces sujets prennent toutefois uneimportance accrue.

Bien que difficile à mettre en œuvre, l’approche itérative ne présente que des avantagesen offshore. Elle cadre au plus juste le travail des collaborateurs, maintient une pressioncontinue et permet de clairement identifier les responsabilités.

La responsabilisation de l’offshore est non moins capitale pour atteindre le meilleurniveau de qualité et de productivité. Trop souvent, le client cherche à imposer sa main-mise sur les équipes distantes et à transformer le prestataire en une sorte d’usine decodage, qui ne doit surtout pas prendre de décisions, ce qui ne peut que le déresponsa-biliser.

À défaut de prendre pleinement en compte ces questions clés, il reste sans doute possiblede réussir ses projets en offshore, mais sans atteindre le meilleur des capacités du pres-tataire. Les qualités personnelles viennent parfois compenser une méthodologieinadaptée. En appliquant les recommandations de ce chapitre, il est possible d’optimiserles chances de succès du projet.


227

Chapitre 11

Gestion des ressources humaines

Les hommes sont essentiels à la réussite du projet et au succès des opérations. Nousavons déjà traité de leurs motivations, ainsi que des procédures d’embauche et de sélec-tion. Ce chapitre aborde l’organisation des ressources humaines, qui contribue plus forte-ment au succès du projet que l’industrialisation des développements, cette dernière nepouvant donner sa pleine puissance que si l’organisation humaine est performante.

L’organigramme cible définissant le profil de chaque poste à pourvoir permet de struc-turer les échanges avec le prestataire sur les recrutements. Il convient de le maintenir àjour en permanence afin de l’adapter aux profils réels embauchés, qui ne manquentjamais de modifier le projet initial.

Quelques règles importantes permettent de monter des équipes qui fonctionnent effica-cement dans tous les environnements et savent s’adapter aux conditions changeantesque l’on rencontre toujours en cours de projet. Même les défaillances des procédures etdes workflows trouvent naturellement des solutions lorsque l’organisation des hommeset de leurs responsabilités est bien gérée.

Identification des profils

Une attention toute particulière est portée aux profils à fort potentiel, qui sont très nom-breux mais nécessitent d’être accompagnés pour se révéler. Dans les pays de l’offshore,certains collaborateurs n’ont pas la possibilité d’exprimer tout leur talent. Le manage-ment des hommes et l’initiative personnelle sont rarement mis en avant, et les managersne se soucient guère de détecter le potentiel de chacun afi n de l’exploiter. On favoriseau contraire trop souvent le travail silencieux, qui, à la longue, devient le fossoyeur desambitions.

Chez les jeunes collaborateurs, le processus de désillusion n’a pas encore fait son œuvre,et maints profils ne demandent qu’à s’exprimer. On trouve aussi, mêlés à ces profils rareset de qualité, tout autant de jeunes ambitieux sans grande envergure, qui s’imaginent unpeu vite que le monde les attend. Si ces profils existent aussi dans le pays du client,en offshore, on rêve plus volontiers à des carrières sans limite, à l’exemple de quelquesréussites spectaculaires.



228

Le management est une qualité si rare dans les pays de l’offshore que l’on se trouvesouvent contraint de miser sur le potentiel des candidats plutôt que sur leur expérience.On doit donc mettre en place une organisation par petites équipes de quelquespersonnes, dont le management (middle management) est simple à assurer et permet desaisir tous les aspects de la production. Les vrais postes de manager, gérant plus d’unedizaine de personnes, sont réservés à un très petit groupe de collaborateurs, qui doit êtrechoisi avec soin.

Les recruteurs peuvent faire de nombreuses erreurs dans la sélection des managers, aveu-glés par l’assurance de quelques candidats. Pourtant, certaines personnes ont tellementpeu le sens du management qu’elles sont capables de nuisances néfastes au projet.Lorsqu’on se rend compte d’une telle erreur de casting, il faut immédiatement retirer àces collaborateurs leurs responsabilités de manager.

Nous ne parlons pas ici de simples carences de travail ou d’une passivité excessive, maisde personnes qui engagent des actions qui vont à contresens de la direction souhaitée,ajoutant des difficultés inutiles au projet. Un exemple vécu d’une telle attitude estcelui d’un manager d’équipe fraîchement nommé affirmant que le choix de Java commeenvironnement de développement ne plaisait pas à certains développeurs et décidantque ses équipes pourront choisir de développer en Java ou en .Net.

Lorsqu’on crée une équipe, il faut être ouvert à tous les profils de qualité afin de nesurtout pas rater les vrais talents autour desquels la bâtir. L’offshore offre à qui sait lesvoir de nombreux profils inhabituels de qualité. Pour les accueillir, il faut parfois ajusterl’organigramme cible. Ces profils vont d’excellents techniciens à des personnes dont onperçoit une recherche de la qualité alliée à une forte capacité de travail en passant parceux qui démontrent une grande sensibilité à l’organisation de tests.

Napoléon et la gestion des hommes

On aurait demandé à Napoléon, à l’époque où il disposait d’une immense armée,comment il s’y prenait pour organiser la gestion de tant d’hommes aussi rapidement. Ilaurait répondu qu’il suffisait de mesurer deux traits de caractère : la paresse ou l’acti-vité et l’intelligence ou la sottise. Cela lui permettait de répartir les hommes en catégories eten rôles.

Les paresseux passifs constituaient l’essentiel de l’infanterie, car, disait l’empereur, onen trouve une quantité effroyable. Les actifs intelligents fournissaient ses officiers decampagne, car ils pouvaient déployer une énergie colossale pour parvenir à faireexécuter à l’infanterie les manœuvres que l’on souhaitait. Les paresseux intelligentsdevenaient généraux, car ils trouvaient toujours la meilleure façon d’atteindre unobjectif, en utilisant les moyens à la fois les plus efficaces et demandant le moins d’effort.

Et il se serait arrêté là. Son interlocuteur, perplexe, lui aurait alors demandé ce qu’il enétait de la quatrième catégorie. Napoléon aurait répondu : « Ah ! les hommes actifs etsots ? Ceux-là, je les fusille. »


Chapitre 11 – Gestion des ressources humaines

229

Distribution des responsabilités

La distribution des responsabilités est certainement l’une des clés du succès des opéra-tions en offshore. La distribution des rôles sur les hommes et la gestion des ressourceshumaines ne sont pratiquement jamais abordées dans les méthodologies telles que RUPet XP. En revanche, Microsoft propose un cadre de travail avec MSF (Microsoft SolutionsFramework), qui traite essentiellement de la gestion des hommes et de la mise en placede flux simples (www.microsoft.com/msf), notamment à travers leur modèle d’équipe (teammodel). De nombreux principes de MSF complètent harmonieusement les recommandationsde RUP et XP.

Les sections qui suivent exposent certains principes assez proches de la démarche duframework MSF.

Petites équipesLe premier principe de gestion des ressources humaines en offshore est de construire depetites équipes soudées, dans lesquelles les personnes s’assistent mutuellement pouratteindre un objectif commun. Ce dernier est le plus souvent un livrable utilisateur, c’est-à-dire exploitable et recettable par son utilisateur. Le livrable final résultant de ce travaild’équipe (développeurs, testeurs, architectes, mentors) est l’objectif commun, les objectifsindividuels ne faisant que contribuer à cet objectif commun.

Pour que ce modèle fonctionne, les règles suivantes doivent être respectées au sein del’équipe :

• La qualité des productions individuelles comme des livrables de l’équipe est la préoc-cupation de tous.

• Chaque membre de l’équipe communique de façon transparente avec les autrescomme vers l’extérieur, tout particulièrement si des réalisations externes dépendentde leurs livrables.

• L’équipe respecte ses engagements de livraison aux dates prévues, avec la qualitémaximale raisonnablement atteignable.

La construction de petites équipes permet de conserver au sein de celles-ci l’investisse-ment d’une responsabilité personnelle. Chacun des membres de l’équipe est en contactquotidien avec tous les autres et peut saisir l’intégralité de l’avancement du projet.

Les mentors et les architectes interviennent à temps partiel dans ces équipes. Ils partici-pent intégralement à leurs réalisations en fournissant tous les services dont elles ontbesoin pour tenir leurs engagements. Mentors et architectes participent également àl’harmonisation du travail entre les équipes afin d’en accroître la cohérence.

Rôles des collaborateurs d’une équipeIl convient de définir clairement les rôles à remplir dans chaque équipe, sachant quecertains d’entre eux seront assurés par une personne à temps partiel et d’autres parquatre ou cinq personnes à temps plein.

Le tableau 11.1 récapitule l’ensemble de ces rôles. La colonne Client indique si l’ontrouve ce rôle chez le client, la colonne Offshore si le rôle peut être assuré en offshore, et


http://www.microsoft.com/msf


230

la colonne Partagé/dédié si le rôle est pleinement intégré à une équipe à temps completou partagé entre les équipes à temps partiel.

Tableau 11.2. Rôles des équipes projet

Rôle Description Client Offshore Partagé/dédié

Chef de marché (interface client)

Assure la relation entre le ou les utilisateurs finals du produit et le reste de l’équipe et négo-cie les changements du spectre fonctionnel avec les utilisateurs ainsi que les retards. Aide à déterminer les priorités fonctionnelles selon ce qu’attend le client.

Oui Non Partagé

Chef de produit

Propriétaire des spécifications détaillées du produit, il les a fait valider auprès des personnes qui conviennent. Complète les spécifications nécessaires au cours du projet avec les équi-pes techniques et en traitant leurs questions.

Oui Rarement Partagé

Réalisation technique

Les tâches de ce rôle comprennent l’analyse, le design, le codage et les tests unitaires des réalisations.

Non Oui Dédié

Testeur Assure que le produit développé correspond aux spécifications ainsi qu’aux autres exigences, comme les volumes et les temps de réponse. Fait le point sur le niveau de qualité du produit.

Parfois Oui Dédié

Mentor technique

Gère les sujets techniques complexes entre plusieurs équipes (architecte, expert technique, responsable méthode, etc.).

Parfois Parfois Partagé

Responsable déploiement

Assure le déploiement du produit sur les différentes plates-formes cibles et vérifie que la configuration des serveurs permet de faire fonctionner le service efficacement.

Oui Oui Partagé

Responsable exploitation

Assure l’exploitation de la plate-forme et son administration, ainsi que le respect du SLA (Service Level Agreement).

Oui Oui Partagé

Responsable éducation

Prend en charge la création de tous les éléments qui vont servir à accompagner l’utili-sateur ou les prospects dans la découverte et l’utilisation du produit.

Oui Oui Partagé ou dédié

Responsable projet

Gère l’ensemble des équipes afin de les synchroniser entre elles et vérifie le contenu et la gestion des itérations.

Oui Non Partagé



231

Certains rôles peuvent être cumulés par une même personne dans les petits projets,tandis que d’autres ne doivent jamais être cumulés sauf à prendre le risque d’en dénaturerla mission. Par exemple, si l’on demande au développeur de tester sa propre réalisation,la nature même de la fonction de test est perdue.

Le tableau 11.2 recense les postes qui peuvent être cumulés et ceux qui doivent êtrepartagés entre plusieurs équipes.

Dans chaque équipe, on trouve certains rôles chez le client et d’autres chez le prestataireen offshore. Le plus souvent, les rôles de chef de marché et de chef de produit sontassurés par le client, qui définit le produit à réaliser. Le chef de produit assure aussi unrôle de recette des livraisons en contrôlant que le produit livré correspond aux exigences.Il est pour cela souvent assisté d’une équipe de recette, qui vérifie le fonctionnementdes livrables, ceux-ci ayant été testés par l’équipe de test le plus souvent située chez leprestataire.

Certains mentors définissent chez le client les grandes lignes à respecter, comme leschoix technologiques et les lignes architecturales du produit.

En offshore, on trouve chez le prestataire les rôles qui correspondent à la majorité dela masse de travail à réaliser, notamment les rôles de développement, test et déploie-ment, ainsi que la plupart des mentors (architecte, responsable procédures, experttechnique, etc.).

Tableau 11.2. Cumul des rôles

Chef de marché

Chef de produit

Dévelop-pement

Testeur Déploiement Exploitation Éducation

Chef de marché

Oui Peu souhaité

Peu souhaité

Peu souhaité

Peu souhaité

Oui

Chef de produit

Oui Peu souhaité

Oui Peu souhaité

Peu souhaité

Oui

Dévelop-pement

Peu souhaité

Peu souhaité

Non Oui Peu souhaité

Peu souhaité

Testeur Peu souhaité

Oui Non Oui Oui Oui

Déploiement Peu souhaité

Peu souhaité

Oui Oui Oui Peu souhaité

Exploitation Peu souhaité

Peu souhaité

Peu souhaité

Oui Oui Peu souhaité

Éducation Oui Oui Peu souhaité

Oui Peu souhaité

Peu souhaité



232

Certains rôles se trouvent tout autant en offshore que chez le client, selon les préférencesde ce dernier, comme les équipes d’exploitation, qui supervisent et administrent lesplates-formes matérielles, et les équipes d’éducation, qui produisent les manuels utilisa-teur et d’autres documents marketing en plusieurs langues. Certains prestataires offshoresont exclusivement spécialisés dans ces services de rédaction et de localisation.

Malgré l’éclatement des rôles d’une équipe, l’essentiel des réalisations est localisé dansles équipes du prestataire (développement, test, mentors), sous la supervision du chef deprojet qui se trouve chez le client. Parfois, certains sujets remontent jusqu’aux mentorsdu client ou au chef de produit, lorsque les spécifications sont incomplètes ou impré-cises, par exemple, ou lors de choix technologiques ou procéduraux importants.

Comme expliqué précédemment, l’objectif de l’équipe est un livrable collectif. Le chef deproduit du client participe entièrement au succès de ces réalisations en accompagnant leséquipes distantes (il participe au travail de plusieurs équipes), avec la réactivité, la qualitéet l’attention voulues. Si une équipe n’assure pas ses engagements, le chef de produitpartage l’échec avec elle.

Bien appliqué, ce mode de fonctionnement réduit les effets de l’éloignement entre leséquipes distantes et locales, la bonne communication étant dans l’intérêt de tous.

Partager la responsabilité et rendre compte de son rôleLa responsabilité de la réalisation des engagements d’une équipe est partagée de façonindivise entre tous ses membres. Dans le même temps, chacun est comptable et respon-sable de ses engagements personnels.

En appliquant ce principe à une équipe, les différents collaborateurs ne peuvent rejeterune faute sur leurs collègues puisque cela n’a aucune importance et que personne necherche de coupable individuel. C’est l’équipe dans son intégralité qui atteint ou manqueson objectif. Une livraison défectueuse est de la responsabilité de tous. L’équipe doitdonc s’entraider pour atteindre ses objectifs, chacun pouvant agir au-delà de son strictdomaine de responsabilité.

Si chaque membre de l’équipe a ses responsabilités propres, il n’en communique pasmoins avec les autres sur les problèmes rencontrés sur ses livrables personnels, les autresmembres aidant tout naturellement les collaborateurs en difficulté en vue de tenirl’objectif accepté.

C’est une équipe de pairs. Aucun membre n’en prend la direction, et le succès est consi-déré comme celui de tous. Le chef de projet chez le client, qui gère plusieurs équipes, joueauprès d’elles un rôle de conseil, parfois d’arbitre, et, si le besoin s’en fait sentir, demanager afin de prendre les décisions qui s’imposent. Il peut ainsi rappeler à l’ordrecertaines équipes qui ne respectent pas les règles de fonctionnement, intervenir auprèsde certains membres, notamment chez le client, afin qu’ils assurent correctement leursrôles ou encore démanteler des équipes qui fonctionnent mal.

Donner le pouvoir de décision aux collaborateursPour qu’une équipe soit réellement motivée, il faut qu’elle soit capable de s’engagerd’elle-même sur ses livrables, dans le cadre précis de ce que l’on attend d’elle. Ellenégocie et accepte collégialement après ajustements les objectifs qui lui sont proposés.



233

Il est inutile de lui imposer des objectifs qu’elle sait ne pouvoir atteindre. Cela serait à lafois contre-productif et démotivant et nourrirait un fort sentiment d’injustice.

Si l’équipe assume formellement son engagement de livraison, l’atteinte des objectifsdevient l’affaire personnelle de chacun de ses membres. Pour que cela fonctionne, tousles membres de l’équipe doivent évidemment faire part de leurs difficultés à atteindre lesobjectifs personnels dès qu’ils en ont connaissance afin de rechercher ensemble des solu-tions, à la fois au sein de l’équipe et avec le chef de projet chez le client, qui peut apporterun éclairage utile.

La pleine responsabilisation de l’équipe sur ses objectifs n’a de sens que si elle s’accom-pagne du pouvoir de décider, dans certaines limites. L’équipe doit pouvoir décider de toutce qui lui semble utile pour atteindre les objectifs. Si les décisions ne concernent quel’équipe, cette dernière dispose de tout pouvoir. Si elles concernent d’autres équipes,elles sont soumises à l’arbitrage du chef de projet chez le client. Ce dernier respecte cetteliberté de décision, dans la mesure du possible. S’il n’est pas d’accord avec certainesdécisions, il peut jouer un rôle de conseil.

La contrepartie du pouvoir de décision est la transparence de la communication. Le chefde produit veille à ne pas punir les porteurs de mauvaises nouvelles ni à rechercher à toutprix les responsables. Au contraire, il se concentre sur l’analyse des causes et sur lesmoyens de les éviter dans le futur. Une attitude punitive a pour effet, comme nous l’avonsvu à plusieurs reprises, de réduire la transparence.

EN RÉSUMÉEngagement personnel des membres des équipes

Les objectifs des équipes sont collégialement négociés et acceptés par leurs membres, qui considè-rent l’engagement acceptable et réalisable. L’équipe dispose d’une forte autorité sur la gestion deses objectifs et peut décider des actions à mener pour les atteindre. Le chef de projet du client joueun rôle de conseil et d’arbitre.

Favoriser les initiativesLe climat de travail doit permettre aux collaborateurs de s’exprimer et de poursuivrecertaines de leurs initiatives. En cas de crise ou de dysfonctionnements récurrents, il estprobable que certains collaborateurs auront d’excellentes idées pour améliorer l’organi-sation afin de les résoudre et apporter une efficacité supérieure.

Dans les organisations fortement hiérarchisées, la décision de corriger les problèmesrelève directement des managers. Moins en contact avec le quotidien des tâches réaliséesque leurs collaborateurs, ils ne perçoivent pas toujours clairement les causes initiales desproblèmes qu’ils voient apparaître trop tard, lorsque le mal a pris racine. La plupart desdécisions correctives des managers interviennent sur les effets et non sur les causesinitiales, qui leur restent inconnues.

Il est important de ne pas laisser une trop forte hiérarchie s’installer, où seuls les mana-gers d’un certain niveau seraient entendus. À tous les niveaux, on peut remarquer desdysfonctionnements susceptibles d’être facilement corrigés. Tous les collaborateurs doiventpouvoir exprimer leurs propositions pour corriger des problèmes, améliorer les procé-dures ou l’organisation et être reconnus pour leur esprit d’initiative. Si des primes sontutilisées chez le prestataire, on peut récompenser les initiatives qui sont effectivementmises en œuvre.



234

De même, les initiatives des managers doivent être appréciées. Il vaut mieux qu’unmanager entreprenne de corriger un problème par une action qui ne porte pas ses fruits,voire qui mène à d’autres problèmes, plutôt que de rester inactif.

EN RÉSUMÉFavoriser les initiativesIl est important de montrer à chaque collaborateur que l’on en espère non seulement un travail dequalité, mais également une capacité de proposition et d’innovation. Toutes les initiatives doiventêtre écoutées, et l’on s’attache à reconnaître les auteurs des propositions effectivement appliquées.

Mentors et rôles centrauxLes équipes décrites précédemment gèrent le plus souvent des développements techniquesou fonctionnels. Elles doivent pour cela s’appuyer sur des services centraux de plusieursnatures :

• Les architectes techniques et fonctionnels, qui maintiennent une vision globale del’architecture du produit.

• Les chefs de projet, qui synchronisent le travail des équipes afin d’assurer l’harmoniedes intégrations et des décisions interéquipes.

• Les mentors, qui mettent en place certaines recommandations et règles et en suiventl’application. On trouve des mentors dans des domaines techniques ou procéduraux.

Ces rôles centraux assurent la cohésion du travail des différentes équipes. En dédiant despersonnes à ces rôles, on garantit en outre que certaines des tâches organisationnellessont assurées et qu’elles ne seront pas délaissées au profit de tâches de production.

Les tâches architecturales permettent de conserver une architecture uniforme entre leséquipes, de repérer les design patterns au fur et à mesure que le produit s’étend et d’iden-tifier les restructurations nécessaires de l’architecture de l’application en vue d’enaccroître l’efficacité. Ils peuvent également participer à la mesure de l’impact des change-ments d’exigences, en étudiant les composants affectés et en estimant l’importance desévolutions.

Les autres mentors assurent un rôle d’évangélisation, d’harmonisation, de conseil et decontrôle. Le mentor sur le langage de programmation, par exemple, peut à la fois définircomment utiliser le langage (règles de nommage, interdiction d’utiliser certainesméthodes et fonctions, contraintes sur les volumétries, modèles de programmation, etc.)et en assurer l’application, tout en aidant certains développeurs en difficulté.

Des mentors peuvent être dédiés à l’environnement de programmation, à la base dedonnées (persistance et gestion du modèle de données), aux middlewares et autres outilsintégrés dans le développement, aux méthodes et procédures, à l’analyse et au design(souvent liés à l’architecte), à l’utilisabilité (interface utilisateur), etc.

Les mentors peuvent être dévolus à plein temps à ces tâches ou les assurer à tempspartiel, en étant eux-mêmes mentors d’autres sujets ou bien développeurs/testeurs dansune équipe. Le choix de l’organisation des mentorats dépend du poids que l’on souhaitedonner à chacun des domaines. Si l’on veut que les procédures et méthodes soient bien appli-quées, on peut dédier un mentor à ces tâches, auquel on confiera un pouvoir fort afin decontraindre les équipes à les appliquer et de lui permettre de bloquer certaines livraisons.

Le client peut attribuer des tâches de mentors à certaines personnes de façon perma-nente ou seulement pendant quelques mois, le temps que tous les membres des équipes



235

comprennent l’importance des règles et les appliquent naturellement. Le mentor peutensuite passer à temps partiel sur ce sujet.

Communication avec le clientUn des avantages des petites équipes est qu’elles permettent d’organiser des communi-cations directes avec les personnes impliquées chez le client, ce qui n’est pas l’attitude laplus naturelle en offshore. Le manager du prestataire préfère le plus souvent centraliserla communication avec le client de façon à contrôler les informations échangées. Cecontrôle crée le plus souvent un filtre important sur les informations transmises. De plus,comme la personne en charge de communiquer en offshore n’est pas à la source des infor-mations, les informations ont de grandes chances d’être déformées, édulcorées ou mêmefausses, non par malveillance, mais par manque d’implication ou simplement par incom-préhension du problème. Il faut éviter les intermédiaires dans la mesure du possible.

Il est vivement conseillé de mettre en place une communication directe des équipes endirection des correspondants chez le client, qui détiennent le plus souvent les rôles dechef de produit et de chef de projet (voir figure 11.1). Le client met ainsi en interface directeavec l’équipe en offshore un chef de produit capable de répondre aux questions fonction-nelles (spécifications, éclaircissements, priorités, etc.), un chef de projet qui suit le travailde plusieurs équipes et en assure la synchronisation et quelques mentors qui traitentde questions d’architecture générale, de procédures, de choix technologiques, d’outils dedéveloppement, etc. Toutes les questions susceptibles de se poser en offshore peuventde la sorte trouver réponse.

Offshore

Equipe fonctionnelle 1

Equipe fonctionnelle 2

Equipe technique 1

Mentor 1

Mentor 2

Client

Chef de produit

Architecte technique

Responsable deprojet

Figure 11.1. Communication directe entre le client et l’offshore



236

Dans certains cas, si le chef de produit est très occupé, le chef de projet chez le client peutétudier les questions des équipes distantes et s’organiser pour obtenir les réponses despersonnes responsables.

EN RÉSUMÉCommunication directe avec le client

Pour disposer d’une excellente communication entre l’équipe offshore et le client, il convient demettre en place une communication directe entre les personnes qui rencontrent effectivement lesproblèmes en offshore et les personnes capables d’y répondre chez le client. La centralisationhiérarchique en offshore induit toujours une part d’opacité et de déformation qui est nuisible à l’effi-cacité des échanges.

Communications défectueusesParfois, la personne qui est censée fournir les réponses aux questions de l’équipe en off-shore se laisse déborder, ne répond plus aux messages ou le fait trop rapidement, engen-drant erreurs et omissions. Quelle qu’en soit la raison, une communication défectueuseempêche l’équipe en offshore de travailler correctement et risque de la conduire à ne pou-voir tenir ses objectifs. Certes, l’équipe tentera tout de même de réaliser ces objectifs, ferapreuve d’initiative et cherchera d’elle-même les bonnes réponses, mais, en cas d’échec, ilfaudra reconnaître que la cause ne lui incombe pas. Ajoutons que le prestataire offshorese trouve toujours en situation difficile lorsqu’un représentant du client ne montre aucunempressement à répondre aux questions, car il ne peut se permettre de critiquer ouverte-ment le travail du donneur d’ordres.

Pour éviter de telles situations, il est essentiel de définir clairement le processus deséchanges entre les équipes du client et du prestataire. On peut, par exemple, établir desmesures de l’efficacité des communications, comme une volumétrie des questions paréquipe, un suivi des transitions d’un état à un autre (question ouverte et close), un temps deréponse imposé, une typologie des questions (complément d’informations fonctionnellesou techniques, cohérence fonctionnelle, etc.) et réponses (compléments aux spécifications,exceptions, question sans objet, etc.). Certains outils de gestion du changement proposentdes workflows pour gérer ce type d’échange et permettent de construire des indicateursefficaces.

EN RÉSUMÉSuivi des communications client/prestataire

Afin d’éviter que des questions importantes restent trop longtemps sans réponses, au risque deretarder les livraisons et de déstabiliser la production, on prendra soin de suivre les échanges entrele client et les prestataires. Toutes les questions posées doivent emprunter un chemin clair, et leséchanges bloqués être clairement identifiés.

Questions d’ordre généralLes questions d’ordre général, qui ne relèvent pas directement de la réalisation du projetinformatique, restent souvent cantonnées dans un vide procédural. Ces questions n’ontpas de propriétaire clair, et l’on observe que les personnes capables d’y répondre ne sontpas directement impliquées dans les problèmes que l’on cherche à résoudre.

Par exemple, une équipe se plaint que l’air conditionné ne fonctionne pas correctementou bien on recommande d’acheter un autre serveur pour modifier certaines organisations



237

et les rendre plus efficaces ou encore on souhaite augmenter la bande passante dédiéeafin d’assurer des synchronisations plus efficaces.

Le problème se complique si le suivi des questions directement liées aux développe-ments est géré par l’outil de gestion du changement, car ces questions générales n’y trou-vent pas naturellement leur place et se trouvent exclues des communications structurées.De même, si une décision est prise sur ces sujets généraux, il faut en suivre l’application, fautede quoi, sans propriétaire désigné, elle a de grandes chances d’être indéfiniment ignorée.

Il est important de mettre en place un suivi de ces questions ouvertes en nommantun propriétaire pour chacune d’elles. L’annexe de l’ouvrage fournit un modèle d’un teldocument de suivi.

EN RÉSUMÉQuestions et décisions d’ordre général

Ces questions et ces décisions tombent facilement dans un vide procédural, car elles ne font pasdirectement partie du processus de production. De plus, elles ne trouvent pas toujours naturelle-ment un responsable, et les outils de communication qui se concentrent sur la production lescouvrent mal. Souvent essentielles à la bonne marche du travail, ces questions doivent être suiviesavec attention. Si le suivi n’est pas assuré par les outils en place, il faut créer un document de suividédié indiquant le propriétaire de chaque question.

Chef de projet et petits projets

Lorsqu’on entreprend un petit projet en offshore, il est souvent difficile de mettre en placedes procédures strictes, car elles seraient exagérément coûteuses par rapport au volumedes tâches de développement.

Pour ces petits projets, le succès des opérations dépend essentiellement de la capacitédu chef de projet en offshore à prendre en charge sa mission et de celle du chef de projetchez le client à communiquer efficacement avec son correspondant en offshore.

En règle générale, il vaut mieux refuser de démarrer le projet en offshore tant que l’on n’apas trouvé le chef de projet qui convient, dans lequel on aura toute confiance et quis’entendra raisonnablement bien avec les équipes locales.

EN RÉSUMÉLe chef de projet des petites réalisations

Dans les petits projets, les procédures sont le plus souvent légères. Le succès du projet dépendalors fortement des capacités du chef de projet en offshore, ainsi que de sa motivation et de sacapacité à communiquer efficacement. Mieux vaut ne démarrer un petit projet en offshore que si l’ondispose d’un chef de projet donnant toute satisfaction.

Les primes

La rémunération est souvent directement utilisée par les managers en offshore pourmotiver les personnels. L’efficacité de ces primes est pourtant loin d’être démontrée,



238

surtout pour les développeurs et plus généralement les collaborateurs techniques. Cesderniers sont principalement motivés par leur poste et la reconnaissance de leur travail.

Une prime est rarement motivante. Mal employée, elle a en revanche toute chance d’êtredémotivante. Par exemple, si une prime est en place et qu’un collaborateur qui a travaillécorrectement ne l’obtienne pas, il se considère comme injustement puni et se démotive.Par ailleurs, les objectifs individuels sont extrêmement difficiles à définir ou créent deseffets pervers plus significatifs que la motivation recherchée.

Si l’on veut mettre en place des primes de motivation, il convient de le faire correctement.L’analyse des résultats doit être faite avec ouverture d’esprit, en recherchant toujoursl’équité.

Primes démotivantesLa plupart des primes octroyées dans les entreprises sont des primes de motivation surdes objectifs personnels. Bien souvent, afin de ne pas organiser des entretiens troprapprochés pour analyser la réalisation des objectifs, ces primes sont attribuées tous lessix mois ou, pire, annuellement. Cela signifie que les objectifs sont le plus souvent définissix mois ou un an à l’avance. Avec une telle anticipation, les objectifs ne correspondentbien souvent à aucune réalité au moment où l’on en étudie la bonne réalisation.

Une prime courante consiste à récompenser la livraison dans les temps d’un produit,alors même que la date de livraison prévue est à au moins trois ou quatre mois. Dans lamajorité des cas, cette livraison est perturbée par d’autres événements, qui en retardentla sortie, ou certaines fonctionnalités, qui sont abandonnées ou remises à plus tard. Leretard n’est donc pas nécessairement le signe d’un travail médiocre. De plus, la prime neprend pas en compte la bonne volonté ni l’efficacité du collaborateur dans ces situationsmouvantes. Pire encore, on encourage ainsi à se concentrer sur des tâches définies àl’avance au détriment de l’adaptation aux urgences, qui surviennent à tout moment.

Par exemple, une équipe a l’objectif de remettre un livrable à une date donnée. Commeelle le livre deux semaines en retard, elle se voit supprimer sa prime. Cela semble juste.Pourtant si ce retard de seulement deux semaines est dû au fait qu’on lui a demandé deréaliser dans le même temps de nombreuses autres tâches considérées comme plusurgentes et qu’elle les ait assurées avec célérité et qualité, la suppression de la primeapparaît comme manifestement injuste. Un effet pervers se déclenche, et la prochaine foisqu’on lui demandera de réaliser des tâches urgentes, elle préférera assurer d’abord cellesqui conditionnent l’attribution de la prime, au détriment des priorités de la société.

Dans la plupart des équipes techniques, de tels effets pervers se vérifient régulièrement.

Un autre exemple de prime « de démotivation » consiste à prétendre transformer lapersonnalité d’un collaborateur. Par exemple, si l’on s’aperçoit qu’un collaborateur estplutôt introverti, communique peu de lui-même ou ne s’intègre pas bien dans son équipe,on peut être tenté de lui fixer des objectifs afin qu’il change d’attitude. Malheureusement,son caractère n’évoluera pas aussi rapidement ou même ne changera jamais. S’il peutfaire des efforts pour communiquer plus efficacement, il ne pourra changer de caractère.Lui donner de tels objectifs frise donc le harcèlement puisqu’ils sont inatteignables. C’estau management de s’adapter à la personnalité de ses employés en définissant des postesoù ils donneront le meilleur d’eux-mêmes. L’expérience prouve que ce type de primemène à de longues périodes de troubles.



239

EN RÉSUMÉPrime de démotivation

Les populations techniques sont souvent motivées par leur travail et font de leur mieux. Une primemal conçue, qui ne serait pas attribuée à certains collaborateurs alors qu’ils sont en droit d’estimerla mériter, entraîne immanquablement une forte démotivation, dont la durée dépend du caractère dechacun.

Les primes sont rarement des sources de motivation en elles-mêmes pour les collaborateurs techni-ques, qui trouvent les sources de leur motivation dans l’intérêt pour leur travail ainsi que dans lareconnaissance de leurs pairs.

Primes collectivesOn peut définir des primes collectives sur la réalisation des objectifs des itérations. Unesomme est alors à répartir entre les membres de l’équipe selon une règle bien définie etacceptée comme juste par tous, sachant que certaines personnes travaillent dansplusieurs équipes à la fois.

De telles primes ont l’avantage de valoriser le travail d’équipe et de montrer que la sociétéreconnaît le travail réalisé. L’objet de la prime étant les itérations, lesquelles varient leplus souvent de trois à six semaines, il y a de grandes chances que les objectifs demeurentinchangés. Si des priorités supérieures doivent prendre la main, le management en tientcompte et juge intelligemment de l’atteinte des objectifs.

Il ne faut pas oublier que refuser injustement ou exagérément l’attribution de la prime estperçu comme la sanction d’un mauvais travail et que cela entraîne des répercussionsnégatives si c’est injustifié.

À l’inverse, accorder une pleine prime à une équipe qui n’a pas l’impression de la méritera des effets négatifs sur sa motivation. Cela lui donne l’impression que l’on place la barremoins haut, que l’on est surproductif et que l’on peut travailler moins.

La prime collective donne surtout ses pleins effets positifs lorsque l’objectif n’est pasatteint et que le travail dans l’équipe n’a pas été correct, tout particulièrement si desmembres de l’équipe ont géré leurs objectifs de façon personnelle en perdant l’espritd’équipe et en ignorant les problèmes qu’ont rencontrés les autres membres. La non-attribution de la prime joue alors un rôle de rappel à l’ordre.

Lorsqu’une équipe fonctionne correctement, elle doit toucher ces primes collectives régu-lièrement. Cela s’apparente à une augmentation de salaire, si ce n’est que des dysfonc-tionnements momentanés de l’équipe sont immédiatement pénalisés. S’ils se répètent,cela relève plutôt d’un problème de management, qui doit être réglé par l’intervention duclient.

Primes pour travail exceptionnelUne autre façon d’accorder des primes, qui semble inique au premier abord mais est fina-lement assez juste, consiste à faire choisir par un collège de managers leurs bénéficiairespour des réalisations passées. Cette prime vient alors comme une surprise.

Elle paraît injuste, car ses critères ne sont pas clairement définis à l’avance et qu’ils s’appuientsur une appréciation qualitative du travail, ce que l’on cherche généralement à éviter. Cetteprime est aussi intrinsèquement juste puisqu’elle juge de la capacité de certains membresdes équipes à réagir à des situations de crise, précisément imprévisibles.



240

Pour éviter l’effet de surprise associé à cette prime, on peut insérer dans les séances dedébriefing des objectifs d’itération des nominations motivées pour cette prime, chaquemanager pouvant proposer une ou plusieurs personnes pour la recevoir. Les nominés, quidoivent être peu nombreux, peuvent être des individus ou des équipes. Un collège demanagers analyse ensuite les nominations et décide de l’attribution de la prime.

Les échanges au cours de ces réunions sont intéressants, car les motifs invoqués peuventêtre considérés comme exceptionnels par une équipe et normaux par une autre. Parexemple, une équipe propose une citation en expliquant qu’une personne a travailléjusqu’à 21 heures durant toute une semaine. Certains managers s’insurgent en expliquantque leur équipe travaille ainsi régulièrement.

Ce genre de prime fonctionne bien, car elle est inattendue et par là même ne génère pasd’effets pervers. De plus, elle permet de démontrer aux informaticiens, qui se plaignentvolontiers de ne pas voir leur travail reconnu, que le management sait apprécier leurvaleur. Il n’y a généralement pas de déception à se voir refuser une prime puisqu’elle n’estpas due par avance. Enfin, elle montre l’exemple à ceux qui hésitent à faire des efforts etqui voient leurs collègues récompensés.

Cette prime concerne une à deux personnes sur vingt chaque mois, et son montant indi-viduel ne dépasse guère 200 à 500 dollars. Pour bien fonctionner, elle doit conserver soncaractère exceptionnel. La plupart des itérations n’occasionnent pas de prime, et seulesles itérations critiques ou de crise donnent lieu à une série de nominations.

EN RÉSUMÉPrimes exceptionnelles

Les primes accordées sur l’observation d’un comportement exceptionnel, après que les événementsse sont produits, sont généralement bien accueillies et génèrent une motivation naturelle.

Les malusEn offshore, il est courant d’attribuer des malus. Par exemple, on peut indiquer qu’à partirdu mois suivant, le salaire d’un collaborateur sera réduit si son niveau d’anglais n’atteintpas une mesure donnée, par exemple sur BrainBench.

Cela se révèle utile lorsqu’on a défini un poste pour un candidat et que celui-ci ne montrepas toutes les qualités requises. On lui demande alors de se mettre à niveau rapidementen considérant qu’il ne mérite pas le salaire octroyé s’il ne remplit pas les qualités voulues.

Certains prestataires généralisent abusivement le malus. Si un collaborateur ne tientpas un engagement, par exemple, il se voit immédiatement puni d’une retenue sur salaire.Il va sans dire que ce type de pratique est réellement démotivant.

Conclusion

La gestion des hommes est l’un des sujets à la fois les plus délicats et les plus importantspour assurer le succès d’un projet en offshore. Avec une bonne vision de ce qui doit êtreréalisé et une bonne répartition des rôles et des responsabilités, on parvient à obtenir uneproductivité honorable et une capacité naturelle à s’ajuster aux changements.



241

Certains estiment que le cadre méthodologique suffit à assurer le contrôle et la producti-vité d’un projet et placent la méthode avant la gestion des hommes. Chaque nouveaucollaborateur doit embrasser la méthode en place, et l’on s’imagine qu’il s’épanouiradans ce cadre. À l’opposé de cette approche, l’expérience recommande de miser avanttout sur les hommes et d’adapter l’organisation, si certains profils le méritent, afin depermettre aux talents exceptionnels de s’exprimer pleinement.

La motivation des équipes est le meilleur gage de productivité. Cette motivation va depair avec une relation de confiance mutuelle, qu’il faut parfois un peu forcer au commen-cement pour initier le cercle vertueux. Divers moyens permettent d’asseoir la confiance,comme de donner le pouvoir de décision à l’équipe du prestataire ou reconnaître sesaccomplissements avec des bonus ou d’autres moyens de motivation.

La méthodologie permet en ce cas d’apporter l’harmonie entre les équipes, ainsi que lavision et la rigueur nécessaires aux projets, en complément d’une bonne gestion desressources humaines.


243

Chapitre 12

Processus et méthode

La gestion d’une équipe informatique à distance demande bien évidemment plus derigueur que celle d’une équipe locale. Pour que cette approche puisse être appliquéesimplement, il faut l’accompagner d’un outillage approprié pour organiser, contraindre etsuivre le travail réalisé à distance.

La mise en place d’un processus de développement structuré est souvent intimidante. Onse retrouve en face d’une forêt de tâches, de rôles, de documents et de flux complexes,dont on ne perçoit pas immédiatement la portée. La seule exploration des processus n’estpas à la portée de tous. Les guides qui accompagnent ces méthodologies ne sont réelle-ment efficaces que si l’on a l’expérience qui convient pour les appliquer intelligemment.L’application à la lettre des directives d’installation mènerait à un échec certain, car ellesprévoient tous les cas de figure et sont d’une lourdeur excessive.

Les méthodologies formelles sont assez nombreuses. La plupart des grands éditeurs delogiciels ont créé la leur, et certains l’incluent dans leurs offres de produits ou la vendenten la mettant plus ou moins en avant. Les deux approches méthodologiques qui se déta-chent assez nettement sont le RUP (Rational Unified Process) d’IBM (www-306.ibm.com/software/awdtools/rup/) et XP (eXtreme Programming) (www.extremeprogramming.org/). Micro-soft propose avec MSF (Microsoft Solutions Framework) son propre cadre de travail, quicomplète sur de nombreux sujets les approches du RUP ou de XP en insistant davantagesur la gestion des hommes et les flux de travail que sur la structuration des processus etdocuments (www.microsoft.com/msf/).

Ce chapitre se penche sur les quelques éléments qui doivent impérativement être implé-mentés lorsqu’on travaille avec l’offshore. La plupart des méthodologies récentes appli-quent ces recommandations, bien qu’en les présentant de façons assez différentes.

La méthodologie et les hommes

La méthodologie ne garantit pas un résultat indépendamment des équipes en place.Comme expliqué au chapitre 11, le succès d’un projet est avant tout conditionné par laqualité des hommes, leurs interactions, leur management et leur motivation.


http://www-306.ibm.com/software/awdtools/rup/

http://www-306.ibm.com/software/awdtools/rup/

http://www.extremeprogramming.org/

http://www.microsoft.com/msf


244

Plus le projet est important, plus la méthodologie est indispensable, car il faut harmo-niser le travail entre différentes équipes et gérer des masses importantes d’informations.Lorsque le projet est très petit, les efforts nécessaires pour déployer des procéduresindustrielles prennent un poids exagérément important par rapport aux tâches de produc-tion, et l’on privilégie des procédures légères. Les qualités humaines font toute la différencedans ces projets légers.

Les méthodes essaient de prendre en compte toutes les étapes d’un projet, depuis lespremiers moments, quand le projet prend forme, jusqu’aux évolutions et corrections duproduit final en exploitation et à la préparation du projet suivant.

La mise en place d’une méthodologie est souvent dépersonnalisante. Elle vise à struc-turer les échanges et la traçabilité et à centraliser les responsabilités. La plupart des outilsméthodologiques utilisent la gestion de work orders, qui attribuent des tâches unitaires àdes personnes d’une façon plus ou moins automatique. Les développeurs qui découvrentleurs tâches dans ces outils méthodologiques, assorties de dates de livraison, ontl’impression de n’être que des exécutants, qui ne décident de rien. Il est donc importantde respecter les motivations, engagements, initiatives personnelles et responsabilitésque chacun apporte aux tâches qu’il réalise.

Cela peut paraître évident, mais lorsqu’on met en place une méthodologie, on tend às’imprégner de tous les concepts, et l’on a tendance à oublier le facteur humain. Il estimportant de ne demander aux collaborateurs d’engager leur pleine responsabilité ques’ils ont pu étudier et accepter les tâches à réaliser et s’ils ont effectivement la possibilitéde mener à bien les réalisations. Un collaborateur que l’on tient pour responsable detâches sur lesquelles il ne s’est pas engagé personnellement ou pour lesquelles il n’a pasde possibilité d’agir se désintéresse de ses objectifs.

Si certains outils méthodologiques peuvent mener à des effets négatifs sur la gestion desressources humaines, ces mêmes outils utilisés correctement peuvent aider à structurerl’organisation des workflows et l’utilisation du référentiel tout en conservant les motivationset responsabilités des collaborateurs.

Procédures et outils méthodologiques n’ont de sens que pour accompagner les collabo-rateurs dans la structuration de leur travail et dans les échanges d’informations. On doitdonc mettre en place ces méthodes et outillages avec la volonté de préserver l’initiative,la responsabilisation et l’engagement personnels des collaborateurs.

EN RÉSUMÉOutils méthodologiques et motivation

Les outils méthodologiques peuvent mener à une gestion des ressources humaines réduisant lescollaborateurs à des rôles d’exécutants. La motivation et l’engagement des collaborateurs sontessentiels pour garantir le succès et la qualité des réalisations. Il faut donc veiller à conserver cesvaleurs dans le management des ressources humaines lors de la mise en place des procédures.

Un autre piège des méthodologies est la façon dont elles présentent les rôles. Un rôleassure un certain nombre de tâches ciblées. Le nom des rôles est souvent trompeur, carcertains d’entre eux correspondent à des postes (par exemple, développeur), tandis qued’autres se rapprochent d’une activité (par exemple, test designer), qui doit être assurée. Lesrôles peuvent être très précis, comme test reviewer, même si cela ne correspond pas à unposte à temps plein.


Chapitre 12 – Processus et méthode

245

Les collaborateurs qui ont peu d’expérience des descriptions des rôles dans les métho-dologies les associent à tort à des postes à temps plein. Certains rôles semblent en outreêtre plus valorisés que d’autres. Ainsi, l’analyste semble plus gradé que le développeur etle test designer que le testeur. C’est un piège qu’il faut éviter dès le commencement. Lesrôles présentés dans les méthodes ne correspondent pas nécessairement à un poste. Ils’agit plutôt de fonctions consistant à effectuer certaines tâches et à prendre la responsa-bilité de certains livrables. Par ailleurs, les méthodologies n’expliquent pas commentdéterminer l’attribution des rôles aux postes ni si certains rôles peuvent être cumulés parune même personne sans être dénaturés.

Le chapitre 11 montre comment construire des équipes efficaces. Sur les postes identi-fiés, on doit allouer des rôles à la méthodologie. Les rôles d’analyste et de développeur,par exemple, sont souvent alloués aux mêmes personnes afin de ne pas répéter les erreursdes débuts de l’informatique, quand l’analyste concevait le programme et le pupitreurentrait le code. Il est peu motivant pour un développeur de recevoir un modèle de designentièrement conçu par une personne qui ne codera pas et de se contenter de réaliser uncode, bien souvent en critiquant le travail fait en amont. De même, l’analyste qui conçoitses modèles d’analyse sans coder une seule fonction ne peut travailler ses modèles avecle même soin que s’il sait devoir les coder.

EN RÉSUMÉRôles, postes et méthodologies

Les méthodologies attribuent des rôles précis à des activités et à des livrables. Il se peut que descollaborateurs s’associent à des rôles choisis pour leur aspect valorisant et intéressant correspon-dant plus ou moins à leur rôle courant. Les rôles des méthodologies ne sont pas des postes, et unposte cumule souvent plusieurs rôles.

Choix de la méthodologie et des outils

Les outils permettent d’améliorer les communications avec l’offshore en rendant transpa-rents les workflows, les livraisons et la progression du projet. Ce chapitre ne prétend pasaider à choisir la méthodologie ou les outils qui doivent être utilisés pour travailler avecdes équipes en offshore. Il propose simplement un tour d’horizon des fonctionnalités lesplus utiles pour les projets en offshore parmi celles offertes par la plupart de ces outils dedéveloppement.

En tout premier lieu, il importe de choisir une méthodologie qui utilise une approcheitérative et qui est correctement accompagnée de l’outillage permettant d’en appliquer,voire d’en forcer les principes essentiels.

La méthodeLa méthode peut se présenter sous la forme d’un produit packagé et versionné, pour lesméthodologies qui sont gérées comme des produits, tel le RUP, ou sous forme d’archivecompressée à télécharger sur Internet. Qu’elle soit livrée sur un CD ou disponible sur leWeb, elle doit être adaptée aux besoins du projet.



246

La solution la plus simple pour installer la méthode consiste à créer un intranet à partirdu site brut proposé par la méthodologie et de le personnaliser selon les activités,livrables et workflows que l’on souhaite mettre en œuvre.

Les méthodes couvrent le plus souvent un spectre beaucoup plus large de situations quecelles que l’on rencontre dans un projet réel. Certains flux, comités ou documentspeuvent n’avoir qu’une utilité réduite dans le cadre d’un projet. Il faut donc adapter lecadre méthodologique afin de ne déployer que les éléments utiles, tout en respectant lesprincipes de base.

La méthodologie elle-même doit être mise en place de façon itérative et permettre derevenir sur des éléments dont la définition ne serait pas pleinement efficace et que lescollaborateurs voudraient améliorer.

Le référentielLe référentiel est l’outil le plus important de l’outillage méthodologique. Il reçoit tous leséléments qui sont créés, modifiés ou utilisés dans le cours du projet. On trouve aussi biendes textes, contenant des informations générales sur le projet, que des documentsméthodologiques, des codes source, des scripts, des plans de test, etc. On peut y placerles différents jeux de données de test, ainsi que tous les outils qui permettent dereconstituer l’intégralité de l’environnement de développement et de déploiement.

Le référentiel permet de conserver le versionnement de tous les éléments que l’on y place. Onpeut ainsi retourner à des versions antérieures et savoir qui a effectué des modificationset quand.

C’est tout particulièrement sur la gestion du code source que l’on trouve les mécanismesles plus évolués. Le référentiel peut être lié aux autres outils qui sont mentionnés dans lasuite du chapitre et qui permettent de gérer des informations sur le changement, mainte-nant ainsi non seulement les différentes versions des éléments mais les changementsopérés sur ceux-ci. De cette façon, l’utilisateur extrait un code source du référentiel poureffectuer un ou des changements (correction d’anomalie, évolution fonctionnelle,nouvelle fonctionnalité, etc.) qui sont demandés dans l’outil de gestion du changementet le replace dans le référentiel une fois le changement effectué.

Le premier objectif de la gestion de référentiel est de gérer les extractions pour modifica-tions et l’insertion de l’élément modifié. Le programmeur peut bloquer un élément pouréviter que plusieurs personnes ne travaillent dessus en même temps sans le savoir.L’outil sait aussi gérer la fusion de modifications simultanées si ces dernières sontsituées dans des parties différentes du code. Il peut tout aussi bien demander auprogrammeur de résoudre les recouvrements de modifications.

Pour créer une version d’un produit, on identifie des baselines, qui sont un ensembled’éléments versionnés qui doivent être extraits simultanément pour être compilés. Ceséléments doivent être compatibles entre eux et s’assembler correctement. Par exemple,si l’on fait évoluer une interface technique, les anciens programmes qui utilisent l’inter-face précédente ne fonctionnent plus. Il faut donc attendre que les programmes aient étéretravaillés pour prendre en compte la nouvelle interface afin qu’ils fonctionnent ànouveau. La baseline identifie les versions des éléments qui sont compatibles avec lanouvelle interface afin de les compiler et créer un produit exécutable.

Une baseline peut être « promue » selon l’état de test et de stabilité du produit exécutable.La baseline peut ainsi correspondre à une version en cours de développement (très



247

instable), en cours de test unitaire (instable), à intégrer pour test (boguée), testée (stable)et recettée (très stable), etc., selon le cycle de promotion choisi par le client.

Un autre mécanisme de base du référentiel est la gestion des streams. Un stream est unchemin de développement sur lequel on peut agir indépendamment des autres chemins.À partir d’un développement, on peut souhaiter figer une version pour la stabiliser, parexemple. Les anomalies seront appliquées au stream de livraison jusqu’à obtenir unestabilité suffisante. Par ailleurs, sur le stream de développement, de nouvelles fonction-nalités sont ajoutées, qui n’apparaissent pas dans le stream de livraison. Les anomaliescorrigées dans le stream de livraison doivent être également corrigées dans le stream dedéveloppement.

La figure 12.1 illustre un stream créé pour validation, sur lequel on doit corriger lesanomalies 1 et 3. Les nouveaux développements et les autres corrections d’anomalies nesont pas réalisés sur le stream de développement, lequel est conservé aussi stable quepossible de façon à pouvoir en établir le niveau de qualité. S’il devait continuellement êtreen évolution, on ne pourrait estimer son niveau de qualité.

On peut créer plusieurs streams en parallèle selon les objectifs que l’on s’est fixés :

• Version majeure : création d’une version majeure suivante, qui ajoute un ensembleimportant de fonctionnalités, voire s’accompagne de couches techniques retravaillées.

Figure 12.1. Gestion des streams



248

• Version spécifique : ajouts fonctionnels pour un client spécifique donnant lieu à unedérivation client du produit.

• Service Pack : livraison sous forme de patch d’un ensemble de corrections d’anomalies.

• Hot Fix : correction urgente d’un bogue bloquant à livrer dès que possible sur laversion en production.

Cet exemple montre qu’on peut entreprendre quatre séries de modifications en parallèlesur les mêmes codes source, avec des objectifs de livraison client qui varient entre quel-ques heures (Hot Fix) et plusieurs mois, voire plus d’un an, dans le cas du travail sur unenouvelle version majeure. Le référentiel sait gérer ces streams différents et, dans unecertaine mesure, assister à la fusion des actions d’un stream sur l’autre, comme reporterla correction de l’anomalie urgente sur les autres streams , afin d’éviter les régressions.

Le référentiel assure la sécurité des informations qui lui sont confiées. Il est, par exemple,possible d’assurer une partition des informations entre des personnes ayant accès àcertains éléments et d’autres qui n’y ont pas accès.

Certains référentiels sont conçus pour être utilisés sur plusieurs sites, avec réplicationtotale ou partielle des éléments. Lorsqu’on travaille avec un prestataire distant, on peutrépliquer, en temps réel ou périodiquement, toutes les informations relatives à leursdéveloppements. Tous les éléments placés dans le référentiel se retrouvent immédiate-ment chez le client et réciproquement, tandis que les éléments qui ne sont pas synchro-nisés restent locaux.

Le référentiel est au cœur de l’outillage méthodologique. C’est l’outil sur lequel tous lesautres s’appuient. Il est donc à choisir avec beaucoup de soins.

Gestion du changementL’outil de suivi du changement on sépare parfois la gestion des anomalies et celledes évolutions ou nouvelles fonctionnalités assure plusieurs rôles, notamment lessuivants :

• Il permet de suivre précisément toutes les détections d’anomalies ou demandes dechangement en garantissant qu’aucune information ne se perd.

• Il permet de mettre en place un flux de traitement des requêtes. On peut, par exemple,définir des phases de qualification des anomalies, au cours desquelles on détecte si ledéfaut signalé est bien une anomalie et si elle n’est pas déjà répertoriée. Une foisqualifiée, l’anomalie suit un chemin qui permet de lui associer les informations néces-saires pour décider de la corriger et quand (importance, temps estimé de correction,risques d’instabilité, etc.).

Le flux de gestion de l’anomalie ou de la demande est configurable. On peut trouver desflux très différents selon la nature de la requête. Par exemple, une anomalie techniquesuit un chemin différent d’une demande d’évolution fonctionnelle. Ces flux doivent êtreconfigurés par le client pour s’adapter au mieux à son organisation et à la répartition desrôles dans la société.

Cet outil est généralement fortement couplé au référentiel, car toutes les demandes dechangement donneront probablement lieu à des interventions sur les codes source. Onsouhaitera suivre ces modifications avec les versionnements des éléments dans le réfé-rentiel.



249

L’outil de gestion du changement est indispensable lorsqu’on travaille en offshore. Ilpermet notamment d’éviter que le client et le prestataire s’attendent mutuellement et quedes requêtes de changement se perdent. Il évite aussi les erreurs de communication surles niveaux de priorité des requêtes.

Les petits projets ne nécessitent pas toujours de tels outils, parfois lourds et coûteux. Il esten ce cas nécessaire de les remplacer par des procédures strictement appliquées afin decommuniquer efficacement.

EN RÉSUMÉGestion du référentiel et du changement

Les outils indispensables à la gestion de projet en offshore sont le référentiel et les outils de gestiondu changement. Ils garantissent un suivi rigoureux de la production et de toutes les requêtes échangéesentre les équipes ainsi qu’une traçabilité de l’état de santé du développement.

Comme indiqué au tableau 12.1, le référentiel et les outils de gestion du changementfournissent un grand nombre de mesures des développements en cours.

Gestion des exigencesLes outils de gestion des exigences permettent de suivre toutes les exigences fonction-nelles et techniques qui ont été exprimées sur un projet. Chaque exigence est associée àune série d’attributs, comme l’importance de la fonctionnalité, une estimation de la duréede travail pour la réaliser, le risque lié à cette exigence ou tout autre élément que l’onsouhaite utiliser pour les qualifier.

Tableau 12.1. Mesures issues des outils de gestion du référentiel et du changement

Mesure Utilisation

Nombre d’anomalies Mesure de la santé du produit, avec des informations sur la sévérité des anoma-lies connues. On étudiera particulièrement l’évolution des anomalies connues, le temps de résolution, la distribution par fonction, etc.

Nombre de requêtes de changement ou d’évolution

Mesure de la stabilité du produit. On étudiera particulièrement l’impact de ces requêtes sur les livraisons finales et la distribution des requêtes par fonction.

Temps de transition des requêtes dans un flux de travail

Cette mesure permet de comprendre le temps nécessaire entre la détection d’une anomalie et sa résolution et de repérer les décisionnaires qui prendraient un temps exagéré pour les traiter.

Stabilité des spécifications

On peut mesurer la stabilité des documents de spécifications en observant les mises à jour réalisées sur celles-ci, montrant ainsi la stabilité des demandes faites aux équipes de développement.

Taille des fonctions en lignes de code

Comptabilise les lignes de code de chaque fonction du produit.

Changements des lignes de code

Mesure du nombre de lignes de code modifiées, ajoutées et supprimées par fonction sur une période, montrant les domaines d’activité et la nature des interventions



250

Ces attributs sont utilisés pour déterminer le contenu de chaque itération. Les décisionssont prises non plus en lisant le contenu de chaque exigence mais en travaillant directe-ment sur ses attributs. Lors des premières itérations, on choisit le plus souvent d’éliminertoutes les incertitudes techniques et les risques les plus forts de façon à rendre les itérationssuivantes de plus en plus fiables. À l’inverse, avant une livraison importante, on cherche àfavoriser la stabilité, et les derniers développements concernent des tâches peu complexeset à faible risque. Les fonctionnalités portant une part de risques sont reportées à uneversion ultérieure, si c’est possible.

Les outils proposant une gestion des exigences maintiennent le plus souvent un lienentre l’exigence et tous les autres éléments qui en découlent, permettant de garder unecartographie des réalisations. Certains outils permettent aussi de gérer les workflows demodification des exigences.

Les exigences peuvent aussi être gérées sous forme de tableau de type Excel. On perdalors les mécanismes de liens entre une exigence et les éléments dérivés, mais ce n’estpas essentiel dans tous les projets.

EN RÉSUMÉGestion des exigences et itérations

La gestion des exigences permet d’associer à chaque exigence des attributs afin de déterminer lespriorités selon lesquelles on construit un produit. Les attributs permettent, par exemple, d’éliminerles risques et de réaliser les tâches complexes le plus tôt possible dans le projet de façon à pouvoirenvisager d’autres approches tant qu’il en est temps. Les engagements sur les itérations deviennentde plus en plus fiables au fur et à mesure de la progression du projet puisque les sources d’incerti-tude sont progressivement éliminées.

La gestion des exigences est une tâche continue. Les attributs que l’on pose au débutd’un projet changent au fur et à mesure des réalisations. Il est possible, par exemple, quetoute une série de fonctionnalités présentent un fort risque dû à une incertitude tech-nique commune. Une fois cette incertitude levée, le risque doit être mis à jour pour toutesles fonctionnalités qui en dépendent. À l’inverse, de nouvelles difficultés ou de nouveauxrisques peuvent apparaître.

L’importance des fonctionnalités change également. Il se peut qu’une fonctionnalitéconsidérée comme secondaire devienne soudainement primordiale parce que l’utilisa-teur la réclame explicitement. La gestion des exigences est ainsi un document vivant, quidoit être mis à jour régulièrement, au moins à chaque itération, puisque c’est une dessources essentielles de détermination du contenu de l’itération future.

Gestion des flux (workflow)Les workflows permettent de définir les états possibles d’un élément (information, docu-ment, fichier, etc.) et sa circulation entre les personnes qui le traitent et décident de lefaire changer d’état. La plupart des outils de gestion du changement et des exigencesincluent un outil de gestion de workflow des informations qu’ils gèrent.

La mise en place d’une gestion stricte des workflows relatifs au changement (anomalieset évolutions) est primordiale. Ces informations sont échangées en permanence entre lessites, et certaines informations peuvent être critiques. Si un seul workflow doit être définisur un projet, ce doit être celui-ci.



251

Les workflows formalisés permettent de gérer des indicateurs de suivi et de mieuxcomprendre les dysfonctionnements éventuels. Ils prennent une grande importance lorsdes développements en offshore en permettant de contrôler finement certains flux chezle prestataire.

On trouve des workflows dans certains outils de gestion du changement et de référentiel.Il existe aussi des outils dont l’unique objet est de définir des workflows multiusages dansles sociétés. Dans tous les cas, on définit pour chaque type de livrable un cheminement àtravers des états. Pour passer d’un état à un autre, des acteurs doivent réaliser certainesactions pour attribuer un nouvel état au livrable.

Gestion des testsLa gestion des tests est aussi un élément important de l’outillage méthodologique. Letableau 12.2 recense les fonctions d’un certain nombre d’outils de test.

Pour le travail avec l’offshore, il est particulièrement important de s’accorder sur une repré-sentation de l’état de qualité du produit. L’outil de gestion des tests permet de conserverl’état courant de tous les résultats de test et de les partager entre le client et le prestataire.

Il faut également être certain de ce que l’on teste. Il est souvent préférable de ne pasutiliser une version du produit exécutable copiée de machine en machine et de prévoir àla place un déploiement à partir de procédures automatisées qui extraient le code sourcedu référentiel. On est alors certain de disposer de l’exacte représentation du code sourceplacé dans le référentiel et qu’aucun autre élément n’est nécessaire à la création del’exécutable. On teste de fait aussi les procédures d’extraction des sources, de compilationet de déploiement.

Tableau 12.2. Fonctions des outils de test

Outil Fonction

Gestion des tests Gère les scénarios de test couvrant les spécifications (cas d’utilisation), ainsi que les données des tests et les résultats.

Robot de test Automatise les séquences d’actions permettant de répéter automatiquement des tests et de s’assurer de l’absence de régression sur des fonctionnalités. À tout moment, on peut comparer le comportement du système avec un comportement attendu.

Test de charge utilisateur

Injecte des actions que pourraient engager des utilisateurs soit sous forme de séquence d’actions enregistrées, soit directement sous forme de requêtes. L’injecteur d’activité permet de moduler comme on le souhaite une charge utilisateur afin d’étudier le comportement du système en charge.

Analyse de comportement technique(profiling)

Permet d’analyser le comportement du système lorsqu’il est sollicité par une série de requêtes ou transactions. On peut connaître, par exemple, le temps CPU consommé par chaque méthode ou fonction, l’évolution de la gestion de la mémoire, les échanges entre les composants, etc.

Couverture des tests

Permet de tracer les lignes de code effectivement exécutées lors d’un traitement. Cela peut se révéler utile pour visualiser les parties du code qui ne sont pas exécutées lors des tests et augmenter les scénarios de test en conséquence.



252

Gestion de la documentationCertaines suites méthodologiques disposent d’outils de construction des dossiers dedocumentation du projet à partir d’une grande quantité d’informations.

Ces outils sont peu utiles dans le cours des réalisations des projets informatiques. Ilssont surtout utilisés pour créer un corpus de documentation une fois le projet terminé.

Mise en place de la méthodologie

Les méthodologies sont souvent très intimidantes, et de nombreuses sociétés ne parvien-nent pas à les mettre en place efficacement. Elles apparaissent comme un mur infranchis-sable et sont de ce fait reléguées au rang des créations intellectuelles qui ne sont pasréellement applicables. Parfois, on estime qu’elles sont certainement utiles à d’autres,mais que le cas que l’on rencontre les rend inefficaces. Il va de soi que les méthodologiessont applicables à tous les projets et sont partout aussi difficiles à mettre en œuvre.

Les sections qui suivent récapitulent les principales difficultés de mise en place d’uneméthodologie industrielle et les façons de les résoudre.

Méthodologie et offshore

Lorsqu’on démarre un projet avec une équipe distante et que l’on souhaite mettre enœuvre une méthodologie, on pense souvent étendre l’application de cette méthodologieà toute la production de la société et donc à ses équipes de développement locales.L’intention est louable, mais elle complexifie énormément la tâche. Il n’est guère facile demener de front deux déploiements de la méthodologie tout à fait différents.

Mettre en place une méthodologie industrielle pour une équipe en place depuis denombreuses années chez le client est avant tout un travail de communication consistant àchoisir le chemin de migration vers la méthodologie le plus efficace. Lorsqu’on l’installepour une nouvelle équipe, comme une équipe que l’on crée en offshore, on peut choisir del’imposer, puisque les participants adoptent à la fois le client, le projet et la méthodologie .

Le déploiement de la méthodologie dans l’équipe remet en question les rôles de chacun.Les responsabilités des informaticiens et la façon de travailler sont redéfinies, souvent enspécialisant les rôles et en leur retirant certaines responsabilités. Les collaborateurs sefocalisent tout naturellement sur ce qu’ils vont perdre plutôt que sur les avantages de lanouvelle organisation. Comme l’organisation existante est le résultat d’années d’ajuste-ments successifs, la nouvelle méthodologie, avec ses fonctionnements encore bruts,apparaît en outre comme inférieure et fait l’objet de violentes critiques.

Pour éviter ces écueils, il suffit d’isoler le déploiement de la méthodologie industrielle enoffshore de celui sur les équipes locales. On peut traiter les deux projets en parallèle etde façon indépendante, si possible décalée dans le temps. Il est beaucoup plus facile demettre en place une méthodologie industrielle sur un projet distant, où l’on conçoitimmédiatement l’utilité des procédures à mettre en œuvre, que sur une équipe locale quifonctionne raisonnablement bien et qui sera certainement réticente à changer de modede travail.



253

Se concentrer sur l’essentielUn autre piège classique lorsqu’on déploie une méthodologie est de vouloir la mettreintégralement en œuvre. Les méthodologies industrielles cherchent à couvrir toutes lessituations que l’on peut trouver sur un projet, nombre d’entre elles n’ayant aucune utilitépour un projet donné.

Il convient de prendre suffisamment d’altitude pour comprendre pourquoi ces recomman-dations sont prévues dans la méthodologie et décider si l’on doit couvrir tels et tels pointsou s’ils sont sans objet dans le cadre du projet. De plus, les méthodologies souhaitantêtre complètes, elles prévoient des documents ou des procédures qui ne sont pastoujours utiles et qui peuvent être difficiles à rédiger.

Par exemple, un des documents initiaux prévoit de lister les ressources allouées au projetalors que le budget peut ne pas être si clair. Les managers ont peut-être prévu certainesréserves pour couvrir des retards et des dysfonctionnements, par exemple, et ne souhai-tent pas en faire état. La personne qui chercherait à tout prix à obtenir ces chiffres se heur-terait à un refus du management. Les responsables financiers pourraient alors s’élevercontre la méthode, la jugeant trop intrusive.

Il convient donc de comprendre les éléments essentiels de la méthodologie, d’enrespecter les principes fondateurs et d’adapter le reste à la réalité du projet que l’on gère.Un grand nombre de documents peuvent ne pas avoir une grande importance dans lecadre du projet. Il peut aussi y avoir des informations impossibles à obtenir, ne serait-ceque le budget réel du projet.

Ce sont les objectifs forts, centrés sur les éléments structurants de la méthodologie etauxquels on ne doit pas déroger, que l’on mettra en place au plus tôt.

EN RÉSUMÉSe concentrer sur les éléments essentiels

Seuls les quelques éléments essentiels des méthodologies doivent être mis en place sans délai. Lesautres éléments doivent être considérés comme optionnels et d’une priorité faible. Ils ne seront misen place que si le problème qu’ils résolvent a besoin d’être couvert dans le projet.

Dans les méthodologies RUP et XP, les principes essentiels que l’on doit absolumentrespecter dans un projet confié à une équipe distante sont, par ordre d’importance :

• le développement par itérations avec une gestion intelligente de celles-ci ;

• une documentation exhaustive et structurée des fonctionnalités à développer, sipossible sous forme de scénarios d’utilisation ;

• une architecture logicielle facilitant la distribution du projet en composants et sonévolution ;

• la construction aussi fréquente que possible, au moins une fois par itération, d’unbuild permettant de valider la réalité de la progression du projet.

Favoriser la motivationLa gestion des ressources humaines et ses principes motivants visant productivité etqualité ne doivent pas être oubliés lors de la mise en place des procédures. Il est communde se concentrer sur les procédures et d’oublier la gestion des ressources humaines.

Comme nous l’avons vu, l’application formelle et automatique des procédures d’uneméthodologie réduit les responsabilités et dépersonnalise les rôles. Plus les hommes



254

reçoivent de directives contraignantes, moins ils se sentent responsables de leur produc-tion, et plus la productivité baisse.

Il faut veiller à ce que la motivation de chacun ne soit pas atteinte par la mise en placed’une méthodologie industrielle. Il faut certes faire entrer chaque collaborateur dans unrôle structuré avec les responsabilités qui y sont attachées, mais les procédures doivent avanttout permettre aux hommes de travailler plus efficacement et d’éviter les malentendus etles situations floues où l’on ne sait comment faire ni qui doit décider.

On veillera surtout à ne jamais mettre en place des procédures qui dévalorisent leshommes. Gérer les équipes de développement comme des exécutants qui reçoiventdes ordres de développement selon un outil de workflow, sans engagement personnel sur lesréalisations et sans créativité, est dévalorisant et ne peut qu’entraîner une réduction dela motivation et donc de la qualité du travail.

EN RÉSUMÉDes procédures au service des hommes

Les procédures doivent aider les hommes à travailler plus efficacement en réglant de façon univoquel’état des documents, leur circulation et leur validation. L’organisation des rôles et des équipes doitêtre telle qu’elle favorise la motivation et la responsabilisation. Il est utile de garder les hommes auplus près de chacun des livrables dont ils sont responsables afin que le succès ou l’échec de chaquelivraison puisse clairement s’appliquer à ceux qui y ont participé.

Les outils d’aide au travail des collaborateurs

Les outils qui accompagnent la méthodologie sont hautement configurables pours’adapter à la façon de travailler que l’on souhaite mettre en place et aux procédures quel’on veut utiliser. Il ne s’agit pas de considérer que ces outils doivent imposer aux colla-borateurs leur façon de travailler.

Par exemple, le principe itératif est rarement directement intégré dans les outils. Denombreux workflows sont organisés autour des itérations dans la méthode, comme laconstruction du contenu des développements de chaque itération qui découle d’uneanalyse globale du réalisé, ainsi que de l’expérience et des tâches restant à réaliser. Si l’ontrouve effectivement des outils pour gérer ces informations, l’organisation en itérationdoit être mise en place par ceux qui s’occupent de la méthodologie et qui définiront lesguidelines du processus itératif.

Mise en place progressive des procédures

Le très grand nombre de rôles, documents, activités, workflows et guides que proposentles méthodologies est déroutant de prime abord. Il est recommandé de ne mettre en placeque ce qui est réellement utile au projet au fur et à mesure que les besoins apparaissent.La méthodologie accompagne ainsi le développement selon les principes forts que l’onveut faire respecter.

Adopter une méthodologie ne signifie pas en accepter tous les aspects. La plupart desfonctionnalités qu’elle propose sont modifiables sans pour autant distordre la métho-dologie.

Par exemple, RUP recommande de mettre en place un comité pour gérer les demandes dechangement. Ce comité (change control board) est censé réunir toutes les personnes concer-nées par les changements. Cette recommandation est généralement très utile puisqu’elle



255

permet que toutes les parties soient informées et s’expriment. Elle suppose cependantune organisation lourde, puisque les personnes concernées sont nombreuses et que lesréunions ont toute chance de s’éterniser.

Il est souvent préférable de nommer une personne pour gérer les modifications fonction-nelles et une autre pour les modifications techniques. Selon la nature des changements,ces responsables s’organisent et lancent les consultations qui conviennent auprès despersonnes réellement concernées afin de les associer aux évolutions. Seules les décisionsmajeures, comme le remplacement d’un outil technique important du développement,font l’objet de réunions plus générales en vue d’aboutir à une décision concertée.

Le planning

La plupart des méthodologies abordent assez peu la problématique de la planification,alors même qu’il s’agit d’un des aspects fondamentaux de la gestion de projet. On trouvetoutefois souvent la possibilité d’exporter des tâches ou même des parties de planning àpartir de certains outils méthodologiques. Il est parfois possible de les importer, mais lagestion du planning n’est pas réellement intégrée dans les suites méthodologiques.

Les sections qui suivent se penchent sur plusieurs aspects de la gestion de planning misen œuvre efficacement dans des projets et qui s’accordent bien avec les principes itératifs.

De même que la mise en place des processus peut monopoliser toute l’attention, un chefde projet peut faire l’erreur de se concentrer sur la gestion du planning, au détriment detous les autres aspects. Il croit pouvoir piloter toutes les opérations en offshore à traverscelui-ci et en oublie les principes d’itération et la gestion des hommes. Pour éviter cela,nous proposons une approche permettant de lier l’efficacité d’un planning avec les prin-cipes méthodologiques essentiels.

Le tableau 12.3 indique plusieurs niveaux de planification permettant de gérer le dévelop-pement du projet.

Tableau 12.3. Niveaux de planification

Planification Fonction Utilisation

Release plan Distribue les fonctions sur les différentes livrai-sons du produit en faisant apparaître les livraisons de validation.

Permet de gérer la distribution des livrables dans le temps afin de les communiquer au client utilisateur du produit. Les différentes livraisons peuvent concerner des livraisons préliminaires pour validation ou des livraisons successives en production. C’est le planning rendu public qui correspond à un engagement envers les utilisateurs.

Plan de déve-loppement

Distribue le contenu des itérations pour atteindre les objectifs.

Permet de distribuer les objectifs des livraisons par itération jusqu’à la fin du projet en utilisant des charges estimées grossièrement. Ce planning va de pair avec le plan de charge des itérations.



256

Tous ces plannings sont revus et corrigés après chaque itération pour tenir compte del’expérience acquise. L’itération dirige fortement le plan de développement. C’est l’unitéde temps selon laquelle on prévoit la progression et les ressources. Seule l’itération encours est planifiée avec tous les détails. Comme elle est de courte durée, elle ne doit pasêtre perturbée par des éléments extérieurs.

Le plan des itérations définit le contenu du plan détaillé de l’itération. On y découvre ledétail des dépendances entre les tâches et les attributions à chaque informaticien,notamment les disponibilités, compétences, etc. Si nécessaire, les résultats du planningdétaillé sont pris en compte dans le plan des itérations afin de parvenir à plus de précisiondans les plannings suivants.

Gestion des corrections et des nouveaux développementsLes équipes de développement doivent réaliser de nouveaux développements (nouvellesfonctionnalités, corrections majeures planifiées ou évolutions majeures). Elles sontégalement sollicitées pour des corrections d’anomalies, dont certaines doivent être prisesen compte au plus tôt. Ces demandes de correction doivent être gérées convenablementpour ne pas perturber les engagements en cours des équipes.

De nombreux ouvrages recommandent de créer une équipe dédiée aux correctionsd’anomalies afin de séparer les développeurs qui travaillent sur celles-ci et ceux quitravaillent sur les nouvelles fonctionnalités. L’avantage majeur de cette approche estd’isoler l’équipe travaillant sur les nouvelles réalisations et de garantir ainsi la progres-sion stable et planifiée du projet, avec des équipes qui ne seront pas perturbées par lesdemandes urgentes de correction, qui interrompent les tâches en cours et retardent leslivraisons. Son autre effet bénéfique est de limiter et contrôler mécaniquement la quan-tité de travail que l’on peut investir dans les corrections d’anomalies en fonction dunombre de personnes qui y sont dédiées. On évite ainsi que les développeurs décidentdes priorités entre les tâches de développement planifiées et celles relatives à des correctionsurgentes.

Planification Fonction Utilisation

Plan de charge des itérations

Renseigne sur la charge de réalisation de chaque itération pour réaliser le release plan.

C’est la première confrontation du release plan avec la réalité. On voit si les ressources disponibles permettent de réaliser le planning attendu et l’on peut le modifier au besoin pour le rendre réaliste. On ne se préoccupe pas encore de la séquence des tâches ni des tâches périphériques aux déve-loppements.

Plan détaillé de l’itération

Inclut le détail de l’itération qui est sur le point de démarrer ainsi que tous les détails de toutes les tâches planifiables.

Ce planning permet de suivre l’itération dans le détail, ainsi que les affectations à chaque personne. On peut ainsi suivre la progression dans l’itération et comprendre les causes des retards.

Tableau 12.3. Niveaux de planification(suite)



257

On peut opposer trois inconvénients majeurs à cette approche :

• Difficulté à garder motivés les développeurs qui passent leur temps à corriger desanomalies.

• Difficulté à convaincre les développeurs qui travaillent sur les nouveaux développe-ments à viser la meilleure qualité, alors qu’ils savent qu’ils ne corrigeront pas lesanomalies qu’ils ont créées.

• Difficultés engendrées par les multiples fusions de codes source écrits par des déve-loppeurs différents pour gérer les corrections d’anomalies et les nouveaux dévelop-pements.

À l’opposé, l’avantage majeur d’une équipe dédiée aux corrections d’anomalies est l’assu-rance de la bonne maintenabilité des codes source puisqu’ils sont pris en main pard’autres développeurs que ceux qui les ont initialement écrits.

Une autre façon efficace de séparer les activités de correction des nouveaux développe-ments est d’allouer une proportion du temps d’une équipe aux corrections en interdisantque les développeurs ne dépassent cette allocation. Le pourcentage de temps alloué auxcorrections est déterminé pour chaque équipe et pour chaque itération selon le niveaud’effort que l’on souhaite fournir sur ces tâches.

En mode de maintenance d’une application qui continue à évoluer normalement, on peutallouer 20 % du temps d’une équipe à corriger les anomalies et les 80 % restants auxnouvelles réalisations. Cette organisation présente plusieurs avantages :

• On isole effectivement les deux types de traitement du code.

• On assure que la personne qui a codé la fonction intervient elle-même sur ses correc-tions. Elle est alors la plus efficace pour déterminer la cause de l’anomalie et ne pas lareproduire sur les nouveaux développements.

• On peut choisir le moment qui convient pour réaliser ces corrections de façon à ne pasavoir à gérer des fusions de corrections sur deux streams qui évoluent en parallèle.

Si l’on ne prend pas soin d’isoler parfaitement les corrections d’anomalies des nouveauxdéveloppements, les équipes techniques annoncent trop souvent qu’elles ont favorisél’une ou l’autre activité de leur propre initiative. Seul le temps prévu doit être consommésur chacune de ces activités si l’on veut être capable de planifier les réalisations ou deconstruire certains indicateurs.

EN RÉSUMÉCorrections et nouveaux développements

Pour pouvoir planifier les nouveaux développements et la quantité d’anomalies qui peuvent êtrecorrigées, il est important d’isoler le temps réservé aux corrections d’anomalies de celui dédié auxnouveaux développements et aux évolutions majeures.

Pour résoudre cette question, deux approches sont communément retenues. La première consisteà constituer une équipe de correction d’anomalies dédiée à cette tâche, une autre équipe ne s’occu-pant que des nouvelles réalisations. La seconde solution consiste à allouer à chaque équipe dedéveloppement une répartition du temps à passer aux corrections des anomalies et aux nouveauxdéveloppements et à s’assurer que ces proportions sont respectées.



258

Release, Service Pack, patch et Hot FixIl existe plusieurs façons de livrer une nouvelle version d’un produit selon le degréd’urgence des ajouts et corrections à apporter.

En règle générale, plus le contenu est important, plus il est long et difficile de le recetteret de le stabiliser, et plus il faut de temps pour le livrer. En revanche, une correctionsimple, bien circonscrite et apparemment sans danger, peut faire l’objet d’une correctionrapide, de tests limités et d’un déploiement prompt avec un risque limité.

Le tableau 12.4 présente un découpage de différents types de livrables selon l’urgence dubesoin rencontré.

Tableau 12.4. Livraisons et risques

Livrable Besoin Préparation Description Risque

Nouvelle version

Livrer de nouvelles fonctionnalités importantes et des évolutions majeures

Planifiée plusieurs mois à un an à l’avance, avec environ une version par an

Des modifications importantes sont réalisées sur le produit. Le modèle de la base de données et la plupart des composants chan-gent. Tous les tests sont réalisés entièrement avant livraison.

Très faible

Version mineure

Livrer de nouvelles fonctionnalités peu volumineuses et des évolutions majeures

Planifiée plusieurs mois à l’avance

Les versions mineures sont tech-nologiquement proches des versions majeures. Les différen-ces résident dans le volume des nouvelles fonctionnalités livrées et, chez les éditeurs de logiciels, la présentation commerciale de la version.

Très faible

Service Pack

Livrer une série de corrections d’anomalies et quelques évolutions fonctionnelles

Régulière dans le temps et planifiée à l’avance

Les corrections des anomalies sont livrées en bloc dans un Service Pack entièrement testé. On reste dans un fonctionnement planifié à l’avance.

Très faible

Patch Livrer une ou quel-ques corrections d’anomalies qui doivent être déployées rapidement et ne peuvent attendre une livraison planifiée.

Procédure d’urgence faible ou moyenne avec livraison non planifiée

Une ou plusieurs anomalies gênantes ne peuvent attendre le prochain Service Pack ou une livraison mineure ou majeure. Une série limitée de corrections sont effectuées et testées rapidement. On réalise des tests automatisés pour vérifier les régressions. La partie modifiée est testée en profondeur. Avec des tests réduits, le produit suit un cycle de validation rapide mais normal.

Moyen



259

La méthodologie doit prévoir les différents types de release et avertir les participants auprojet des risques pris sur les urgences fortes et les coûts relatifs souvent élevés, quipeuvent affecter le reste de la production. Un patch interrompt certaines tâches en cours.On travaille sur un stream qui devra être reporté sur tous les autres streams, multipliantd’autant les efforts. Les tests pour valider cette livraison n’ont d’utilité que pour ce patch,et de nombreux tests manuels doivent être réalisés. Si l’on multiplie fortement le recoursaux tâches urgentes, on ralentit significativement les autres réalisations.

Il est donc important de porter une attention particulière à ces procédures si l’on veut quel’urgence des requêtes soit respectée comme il convient, en tenant compte des risques etdes coûts de chaque action. Les différents streams doivent pouvoir être créés et gérés parle référentiel pour limiter les risques et apporter la flexibilité et la réactivité souhaitées.

Le release planLe release plan est assez proche de la gestion des exigences. On peut le représenter sousforme de tableau listant toutes les features que l’on souhaite réaliser, avec les datesprévues de livraison aux utilisateurs, ou sous forme de planning, afin de mieux juger del’étalement dans le temps des livraisons.

Le tableau de release plan donné en annexe permet de suivre toutes les exigences etde les attribuer à chaque release. On y trouve également une estimation de la charge dechaque fonctionnalité permettant d’estimer globalement le nombre de jours de codagealloué à chaque release, qui sera à comparer au nombre de jours disponibles que l’onanticipe de façon à estimer grossièrement la faisabilité du plan. On s’entendra sur ce quereprésente cette charge. Le plus simple est de mesurer la charge de codage et de définirdes règles permettant d’y ajouter une charge d’analyse (architecture), de test ou d’autresinterventions de mentors, ces charges dépendant de la nature de l’intervention (évolutionou nouvelle fonctionnalité).

Bien souvent, l’état des cas d’utilisation, ou UC (Use Case), est renseigné dans le tableau.Les cas d’utilisation ne sont pas toujours disponibles dès le commencement du projetmais sont parfois créés au moment où l’on en a besoin. Il est important de suivre la dispo-nibilité des spécifications détaillées pour s’assurer que les équipes sont capables decommencer à travailler au moment prévu.

Le release plan est mis à jour régulièrement. On vérifie que les priorités qui ont été poséessont toujours valides, en tenant compte de l’expérience acquise au cours des itérations etdes changements de priorité éventuels des clients.

Livrable Besoin Préparation Description Risque

Hot Fix Livrer une correction bien isolée pour corri-ger une anomalie criti-que dès que possible. Le produit n’est peut-être pas utilisable sans cette correction.

Urgence très élevée. La correction des anomalies est pleine-ment préemptive.

La correction est portée sur le code source en production. Ces tâches de correction sont préemptives. L’urgence fait que l’on réduit les tests uniquement aux parties modifiées. Parfois, la correction est directement effec-tuée sur le site de production.

Élevé

Tableau 12.4. Livraisons et risques(suite)



260

Plan de développement et charge des itérationsLe plan de développement consiste à distribuer le release plan par itération. On ne cherchetoujours pas à donner le détail des tâches ni à définir les personnes qui travailleront surchacune d’elles, mais on se concentre sur la charge de travail.

On introduit pour cela certaines dépendances des grands blocs de développement. Parexemple, s’il faut que certaines fonctionnalités techniques soient disponibles pour que lesdéveloppeurs fonctionnels commencent à les utiliser, on s’arrange pour s’assurer de leursréalisations dans l’itération qui précède les développements fonctionnels qui les utilisent.

Pour chaque itération, on peut raisonnablement anticiper la charge de travail disponible pourde nouveaux développements. Les autres charges de travail découlent de ces hypothèses.On prévoit le travail de correction des anomalies, selon l’avancement des développe-ments dans le projet æ les premières itérations n’auront probablement pas de chargeaffectée aux corrections d’anomalies æ, ainsi que le travail de test, d’architecture, etc.

On peut essayer d’anticiper les besoins d’embauche et les congés selon les dates desitérations afin d’affiner au mieux les plans d’itération. Le client peut aussi utiliser desrègles pour ajouter des quantités de travail et représenter les risques. Par exemple, onattribue 30 % de charge supplémentaire à toutes les tâches de risque technique élevé.

Toutes ces hypothèses sont posées par écrit et accompagnent chaque itération.

La création du plan de charge des itérations est un travail assez théorique, qui permet devérifier plus finement que dans le release plan le réalisme du planning. Ce documentfournit la base de ce qui deviendra le planning détaillé de l’itération.

En fin d’itération, lorsqu’on dispose du retour d’expérience, on retourne sur tous les plan-nings, tout particulièrement sur le plan de développement et le planning de charge.

Les trois plannings illustrés à la figure 12.2 montrent la façon de suivre l’impact des déci-sions et événements sur les livraisons. On peut prendre des décisions en collaborationavec les équipes distantes en restant concentré sur l’itération en cours. On ne perd doncpas la vision globale du plan des livraisons, qui représente l’engagement envers les utili-sateurs. Le processus itératif est bien appliqué et se gère assez naturellement par la struc-turation des plannings.

Figure 12.2. Les planifications



261

Le planning détaillé de l’itérationLe planning détaillé de l’itération présente toutes les tâches de tous les membres deséquipes avec un détail précis de celles-ci. Elles durent de deux à cinq jours et détaillentles attributions de chaque personne. Ce planning est dans la directe continuation duplanning de l’itération précédente.

La gestion du planning d’une équipe en offshore est particulièrement importante. Moyenessentiel de communication entre le prestataire et le client, elle consiste à mettre enœuvre une planification réellement utile aux deux parties.

Généralement, on construit le planning à l’aide d’outils tels que Microsoft Project.

La plupart des méthodologies proposent des modèles qui s’appuient sur les phases duprojet, chaque fonctionnalité étant regroupée dans la phase. Dans la réalité, mieux vautorganiser le planning autour des domaines fonctionnels, et ce pour deux raisons :

• Les phases du projet sont rarement séquentielles dans la réalité. Par exemple, la phased’inception (création) du projet, où l’on travaille sur les spécifications et la préparation,s’étend en réalité jusque très tard dans le projet, puisque des spécifications finaliséessont bien souvent fournies juste avant le développement de certaines tâches prévuestard dans le cours du développement.

• Il est préférable de confier aux responsables d’équipe la définition du détail du plan-ning des tâches dont ils sont responsables. Chacun d’eux maîtrise le planning completde son équipe en tenant éventuellement compte de points de synchronisation avec lesautres équipes qui fournissent des livrables sur lesquels il doit se synchroniser.

On peut définir une série de règles pour construire le planning détaillé. Récapitulées autableau 12.5, ces règles doivent être adaptées au projet que l’on rencontre.

Tableau 12.5. Règles de construction du planning

Règle Description

Définir le guide du planning Le guide du planning décrit précisément comment il doit être construit, avec le plan de structuration des tâches, les règles de nommage, etc. Par exem-ple, il est pratique de nommer les tâches relatives à une requête de change-ment par un libellé qui commence par l’identifiant de celui-ci.

Définir les chefs d’équipe responsables de leurs plan-nings

Chaque responsable d’équipe construit son planning détaillé, qui corres-pond à ses engagements sur l’itération. Ce planning est construit conjointe-ment avec son équipe, laquelle doit accepter les engagements pris dans celui-ci. Le planning est donc essentiellement regroupé par domaine fonctionnel.

Lister toutes les dépendan-ces entrantes

Le planning commence par lister toutes les dépendances des livraisons provenant d’autres équipes ou du client. Il arrive souvent que le projet prenne du retard du fait de retards de livraison d’éléments provenant du client. Comme il est toujours difficile pour le prestataire de faire des reproches à son client, le planning permet de mettre en évidence les responsabilités des retards, y compris celles du client.



262

Le modèle de planning fourni en annexe reprend ces recommandations. Tous les aspectsdu modèle ne sont pas présentés ici, notamment la gestion des priorités des tâches, lessynchronisations entre itérations, etc.

Comme expliqué précédemment, les engagements des équipes et des hommes concer-nent avant tout des réalisations livrables, recettables et utilisables, plutôt que des livra-bles personnels représentant des états intermédiaires. Le planning doit de mêmes’organiser autour des livrables d’équipe, dont on suit la date de livraison. On laisse ainsiune grande latitude aux équipes pour organiser leurs livrables intermédiaires.

Il est recommandé de mettre à jour les pourcentages d’avancement du projet régulière-ment au cours de l’itération, par exemple toutes les semaines. Cela permet de mieuxcomprendre le détail des causes de retard dans une itération. Le chef de projet estime lespourcentages d’avancement de chaque fonctionnalité.

Le planning doit être perçu non comme un outil permettant d’identifier le coupable d’unretard mais comme une aide pour comprendre les problèmes qui se posent afin d’éviterqu’ils se reproduisent.

Les causes les plus classiques de retard sont les erreurs d’estimation de charge, lesretards de livraison d’autres équipes dont on dépend, des directives du client demandantde se concentrer sur une tâche urgente non planifiée ou encore l’absence de réponse àune question importante. Tous ces problèmes peuvent être améliorés à condition d’uneattention soutenue du chef de projet du client.

Règle Description

Verrouiller le temps alloué aux corrections d’anomalies

Quelle que soit la méthode retenue pour allouer du temps aux corrections d’anomalies, le planning liste les temps alloués par personne pour les correc-tions d’anomalies. Ce temps peut être alloué avec précision à chaque ressource.

Lister toutes les tâches de développement

Ces tâches sont listées par domaine fonctionnel et identifient précisément les requêtes de changement ou les nouveaux développements.

Lister les tâches de fond qui ne correspondent pas à des livrables explicites

Ces tâches de fond concernent l’application de procédures, comme la remise à niveau des règles de nommage ou l’amélioration de l’utilisation des couches techniques. Par exemple, on réserve certains jours pour harmoniser les méthodes d’accès aux données après des recommandations de l’équipe technique. On trouve aussi les tâches d’optimisation de fonctions.

Lister les tâches de management

Les managers réservent le temps nécessaire au management (suivi, réunion, planification, etc.).

Lister toutes les dépendances sortantes

Le planning liste précisément tous les livrables qui sont attendus par une autre équipe.

Assembler les plannings Les sous-plannings de chaque équipe sont assemblés par un responsable du planning, qui vérifie la cohérence de chacun d’eux et les assemble en un planning général.

Tableau 12.5. Règles de construction du planning(suite)



263

Analyse de l’itération terminéeLe processus itératif révèle toute sa puissance si l’on prend soin de réaliser des iterationassessments (analyses d’itération). Ces dernières visent à analyser les objectifs qui n’ont pasété atteints et à comprendre les raisons qui ont contribué à l’échec.

Le modèle d’iteration assessment donné en annexe en présente la structuration. Il est recom-mandé d’utiliser un document par équipe. Le chef de projet du client assemble les iterationassessments provenant des équipes et en contrôle la cohérence. Par exemple, si une équipeest en retard du fait d’une livraison tardive d’une autre équipe, cet événement doit seretrouver dans l’assessment de l’équipe en faute.

Certaines raisons peuvent expliquer des retards, sur lesquelles on peut intervenir effica-cement. Par exemple, si le client livre les spécifications tardivement, il est certainementpossible d’éviter ce type de cause de retard. D’autres permettent de mieux connaître leséquipes, comme la sous-estimation systématique du travail à réaliser.

L’analyse de l’itération doit aller beaucoup plus loin qu’une simple revue des dysfonction-nements de l’itération. Selon les résultats constatés, le chef de projet peut reconsidérertous les éléments du projet :

• Les procédures ont-elles été mises en défaut ? Certaines procédures sont-ellesmanquantes ou leur application pose-t-elle des problèmes ?

• Les équipes en place sont-elles adaptées à ce que l’on souhaite faire ? Certaineséquipes ont-elles besoin d’assistance ? Faut-il changer les membres de ces équipes ?Faut-il revoir l’organigramme ? Les mentors ont-ils joué leur rôle ?

• Les équipes chez le client ont-elles été la cause de retard du fait de réponses tardivesaux questions ? Y a-t-il eu des changements de priorité au cours de l’itération ? Celaaurait-il pu être évité ?

• Le plan de développement doit-il être revu ? Le plan de charge doit-il être ajusté ? Lesperformances constatées doivent-elles influencer les plannings ? Quelle est la profon-deur des ajustements ? Le release plan peut-il être maintenu ? Y a-t-il des impacts surles coûts ?

• Le matériel et l’environnement de travail sont-ils adaptés ? Les moyens matériels sont-ils la cause de certains problèmes ?

• A-t-on bien pris en compte les enseignements de cette itération pour définir l’itérationsuivante (assistance aux équipes en difficulté, assistance à la planification, etc.) ?

Valider la réalité des réalisations

La seule validation vraiment utile de la progression d’un projet est la vérification régulièrede la réalité et de la qualité des livrables recettables. Les estimations d’un chef de projetsur l’avancement de son travail sont hautement douteuses.

Par exemple, un chef de projet peu expérimenté aura beaucoup de mal à savoir s’il aatteint 80 % de progression. Dans de nombreux cas, on s’aperçoit qu’il a à peine atteint lamoitié de sa tâche, malgré son estimation. Cela peut être dû à une sous-estimation de



264

l’effort nécessaire pour finaliser une tâche. Seuls les livrables recettables, c’est-à-dire quel’on peut réellement vérifier, permettent de quantifier une progression.

La distance rend la communication moins efficace. Cette dernière est limitée aux échangesformels, et le client a peu de moyens de se rendre compte par lui-même des problèmes.Si les collaborateurs distants comprennent que le client ne peut vérifier la réalité dutravail accompli, ils peuvent être tentés de cacher leurs retards et leurs problèmes enespérant les résoudre avant que le problème apparaisse au grand jour et cause des diffi-cultés. C’est aussi l’une des raisons pour lesquelles le client doit utiliser les informationssur les problèmes pour aider les équipes à les résoudre et non pour rechercher et punirles coupables.

Le seul moyen pour les participants au projet de se rendre compte de l’avancement réeldu projet est de le prouver par la réalité de la progression. L’intégration des réalisationsen continu permet de vérifier que les développements s’intègrent correctement, et lestests vérifient la qualité des livrables.

Intégration continue et périodiqueComme expliqué à la section précédente, l’intégration est le seul moyen de s’assurer dela progression des tâches de développement. Le code réalisé est compilé et intégré à uneversion en cours de construction afin de donner lieu à des tests unitaires ou fonctionnelset techniques plus complets. On peut décider de réaliser des intégrations périodiques,avec une période aussi courte que possible, ou l’intégration continue ou quotidienne.

Pour être utile, il faut que l’intégration soit recettée, au moins sommairement, afin dedétecter les régressions majeures. Il est évident que si l’on a une intégration quotidienne,seuls les tests automatisés sont réellement efficaces puisqu’ils permettent de ne pasconsommer une main-d’œuvre de test exagérée. Ces tests automatisés peuvent êtreexécutés de nuit, après une intégration et un déploiement eux-mêmes automatisés. Aumatin, on analyse les sujets qui n’ont pas bien fonctionné pour éventuellement les

ÉTUDE DE CAS

Une dure journée

Une anecdote exprime très bien la situation que rencontrent la plupart des managers de dévelop-pements informatiques, tout particulièrement en offshore.Une livraison importante est prévue pour le 30 du mois. Le manager explique aux chefs de projetl’importance de la livraison pour cette date, et tous se mettent au travail. Le 5 du mois, le managerfait le tour des chefs de projet, qui répondent l’un après l’autre que ce sera prêt dans les temps. Le15 et le 20, le message est identique. Le 25, ils annoncent que ce sera dur. Le 29, ils font savoirque ce sera très dur mais qu’on y arrivera quand même.Arrive le 30. Les chefs de projet expliquent qu’ils étaient presque prêts mais que, lorsqu’on a intégréleur partie avec celle d’un autre groupe, on s’est rendu compte d’incompatibilités majeures et qu’ilfallait retravailler le code en profondeur. Le produit sera prêt au mieux trois semaines plus tard.Dure journée ! Le 29, tout allait bien, et on a pris trois semaines de retard en une journée…



265

corriger. Sans une telle automatisation, mieux vaut viser une intégration hebdomadaireou bihebdomadaire, avec un test minimal de non-régression.

L’intégration continue est très difficile à obtenir mais offre de très nombreux avantages,notamment les suivants :

• On dispose d’éléments tangibles pour vérifier la réalité des livraisons et leur qualité etles comparer aux engagements de livraison.

• La pression est maintenue de façon continue sur les équipes de développement, quine peuvent masquer leurs problèmes de production en espérant se rattraper par lasuite.

• Les problèmes d’intégration entre les productions des différentes équipes sontdétectés immédiatement si les modules livrés ne s’intègrent pas bien avec le reste del’application.

• Si des tests automatisés sont mis en place, chaque intégration est testée, et les régres-sions sont immédiatement détectées, rendant ainsi leurs corrections plus aiséespuisqu’on sait qu’elles proviennent obligatoirement des derniers éléments livrés.

• Le bon déroulement des tests automatisés de l’intégration quotidienne permet égale-ment de vérifier le bon fonctionnement des procédures en place, notamment sur lagestion du référentiel.

L’avantage le plus important est bien sûr de confronter la livraison avec la réalité et la vali-dation de la qualité du livrable. On n’a même plus à demander aux chefs de projet si lafonctionnalité est livrée pour la considérer comme terminée. On s’adresse directement àl’équipe de test pour recueillir son avis sur le livrable. Le chef de projet livre tout naturel-lement sa production pour être testée dès que le code source est prêt.

L’obtention d’une intégration continue est un objectif difficile, qui ne peut être atteintque si l’on a réussi à mettre en œuvre un ensemble de procédures. Pour parvenir à mettreen place une intégration continue, il faut avoir su gérer correctement les points suivants :

• Un processus efficace de livraison dans le référentiel afin que les différents streamssoient correctement gérés. Cela nécessite généralement une gestion efficace de tout lecycle de développement et de test.

• Un mode de promotion des éléments afin de pouvoir qualifier les builds.

• Un planning efficace permettant d’attendre harmonieusement les livrables dans unordre cohérent.

• Une automatisation des déploiements et des tests sans laquelle l’intégration continuen’a qu’un intérêt réduit.

La recherche de l’automatisation des tests est particulièrement importante lorsqu’on gèredes développements en offshore. Il s’agit d’abord d’automatiser la construction du build,donc l’extraction du référentiel des codes source, la compilation de ces codes et ledéploiement sur la plate-forme cible. Une fois le déploiement réalisé, on peut engager lestests automatisés qui signalent les régressions sur le build, tant fonctionnelles qu’àl’égard des performances.

La production de builds continus testés automatiquement chaque nuit garantit l’applica-tion de procédures strictes et permet de suivre exactement la progression du projet quantà la réalité des livraisons.



266

Les tests unitairesLes tests unitaires sont considérés comme une étape essentielle pour parvenir à un bonniveau de qualité de la production. Le développeur teste les fonctionnalités élémentairesd’un programme indépendamment de la façon dont il a été codé afin d’en valider le fonc-tionnement. C’est la première étape des tests visant à vérifier que le programme est inté-grable et testable.

Il est important de limiter les allers-retours entre les équipes de développement et detest. Pour les réduire dès les premières livraisons des exécutables, il convient de s’assurerque les exécutables livrés aux équipes de test sont d’un niveau de qualité suffisant pourne pas recéler de dysfonctionnements. Pour cela, le développeur prend en charge lepremier niveau de tests unitaires afin de vérifier que les exécutables implémentent lesfonctionnalités décrites dans les cas d’utilisation.

La plupart des développeurs n’aiment guère tester leurs réalisations et transmettent troprapidement leur code aux équipes de test, estimant qu’ils trouveront bien les anomalies.Ces échanges sont consommateurs de temps. Les équipes de test s’arrêtent en rencon-trant des anomalies bloquantes, qui doivent être documentées et retournées aux déve-loppeurs. Si les anomalies sont trop nombreuses, il est rapidement impossible d’anticiperla date à laquelle l’exécutable sera suffisamment stable. Les équipes de test s’impatien-tent, perdent du temps à rédiger des change requests, et une tension en résulte souvententre les testeurs et les développeurs.

Si, au contraire, la livraison est tout de suite d’un niveau de qualité suffi sant, l’équipede test ne trouve que des anomalies mineures, quelques anomalies majeures et dans derares cas des anomalies bloquantes.

Les scénarios des tests unitaires peuvent être définis par les équipes de test, qui deman-deront que ceux-ci soient en premier lieu réalisés par les équipes de développement oupar les chefs de produit qui les associent directement aux cas d’utilisation. On peutdécider de formaliser le jeu de données utilisé lors de ces tests afin qu’il soit représentatifde tous les cas fonctionnels possibles. Le résultat des tests unitaires est livré aux équipesde test avec l’exécutable de façon à garantir un certain niveau de qualité.

Automatisation des rapports de suiviDe la même façon que l’on peut automatiser les tests, il est souhaitable d’automatiser lesrapports de suivi des développements afin d’éliminer toute interprétation humaine dansl’appréciation de l’avancement du projet.

On cherche alors à s’appuyer autant que possible sur les sources d’information dont ondispose. Si l’on a pu mettre en place le référentiel, la gestion du changement, unprocessus avec des procédures strictes, un planning représentant réellement la progres-sion du projet et des résultats de test fiables, on dispose de l’essentiel des informationsdont on a besoin pour construire des rapports de suivi.

Les procédures doivent être organisées de sorte à obtenir ces informations régulièrementet à donner une vision fiable et objective de l’avancement du projet. Si nécessaire, undétail précis de certains sujets qui ne fonctionnent pas correctement permet de choisirles meilleures actions correctives.



267

Conclusion

La mise en place d’une méthodologie pour l’offshore se résume à certains principesessentiels, sur lesquels il importe de se concentrer. À l’inverse, il ne faut pas se laisserdépasser par le grand nombre de procédures et documents qui sont d’une importanceréduite mais consomment beaucoup de temps.

Plusieurs principes clés ne tolèrent aucune dérogation, notamment les suivants :

• On respecte l’organisation des hommes, conçue pour garantir un fort niveau de moti-vation et de productivité. Mieux vaut disposer d’une équipe motivée et organisée, avecdes rôles bien définis, plutôt que de procédures censées organiser tous les aspects duprojet. Les procédures doivent venir en support de l’organisation humaine pour larendre plus efficace et régler les échanges entre les équipes.

• On applique un mode de travail itératif, de façon à maintenir des objectifs stables àcourt terme. Les managers planifient ainsi le travail plus aisément, et chacun disposeen permanence d’objectifs à court terme permettant de vérifier la progression du projetsur des livrables tangibles.

• On utilise des outils pour organiser et appliquer strictement les workflows autour de lagestion du référentiel et du changement. On dispose ainsi de mesures de la qualité deslivrables et de moyens de travailler en équipe efficacement.

• On cherche à mobiliser toutes les équipes sur la qualité des livrables individuels etd’équipe. La qualité des livrables à tous les niveaux est le garant d’un meilleur travaild’équipe et d’une plus grande fiabilité des plannings.

Ces règles universelles sont d’autant plus importantes lorsqu’on travaille en offshore, oùtous les défauts de qualité et de communication sont amplifiés.


269

Chapitre 13

Gestion des tests et de la qualité

Lorsqu’on travaille avec une équipe en offshore, on doit naturellement prévoir d’y placerune équipe pour assurer les tests. L’objectif est d’améliorer la communication avecl’équipe de développement et de réduire le coût de ces tâches dévoreuses de temps. Laqualité de la production du code doit être vérifiée et contrôlée par les membres del’équipe de test, qui fonctionnent de pair avec les développeurs. Ils vérifient notammentles aspects fonctionnels et techniques du code (performances, sécurité et respect desrègles méthodologiques) afin de juger de la qualité des fonctions et du produit final.

On considère communément que l’objectif de l’équipe de test est de trouver les anoma-lies d’un produit. On pourrait aussi définir son rôle comme consistant à déterminer l’étatde qualité d’un livrable ou d’un produit complet de façon objective et continue. Il s’agitici de mesurer le risque que l’on prend à livrer un produit. Cela implique tout autantd’identifier les anomalies connues que d’estimer la qualité des parties du produit surlesquelles on n’a jamais effectué de test ou dont les tests remontent à une version anté-rieure.

Il s’agit d’un travail complexe, où il est souvent plus important de mesurer les risquesintroduits par les zones d’ombre que de suivre les anomalies déjà détectées à travers unworkflow.

On commence par tester le comportement fonctionnel. Le produit livré correspond-il auxfonctionnalités décrites dans les documents de spécification ? On s’intéresse ensuite aurespect de certaines normes visibles par l’utilisateur, comme les règles relatives à l’IHM(interface homme-machine), dont on veut vérifier la bonne application. On s’inquièteenfin des exigences techniques, notamment des performances et de l’architecture, et dela consommation des ressources (processeur et mémoire).

La sécurité est toujours considérée comme une préoccupation importante si l’applicationest accessible par Internet ou par un grand nombre d’utilisateurs. Les objectifs de sécuritésont rarement exprimés d’une façon technique. On souhaite le plus souvent que le niveaude sécurité soit suffisant, sans vraiment définir ce que cela signifie. L’équipe de test doitcependant s’assurer que le niveau de sécurité est mesuré.

Sans faire formellement partie des engagements de livraison, la vérification des procé-dures et règles méthodologiques apporte un confort supplémentaire pour gérer les évolu-tions et asseoir le contrôle sur le produit. Il arrive que certaines procédures soient érigées



270

en règles incontournables, comme de refuser de tester des programmes qui ne vérifientpas certaines règles.

Pour disposer d’une vision juste de l’état de qualité d’un produit, l’équipe de test doit dis-poser de nombreuses informations. Elle doit aussi gérer son temps de façon à compren-dre précisément où se trouvent les gisements d’incertitudes sur la qualité et à trouver lesmeilleures façons d’en avoir une vision claire. De plus, l’équipe de test doit en perma-nence être tenue au courant des attentes du client afin de concentrer ses actions sur lesdomaines les plus utiles.

Les tests commencent aussi tôt que possible, dès l’apparition des premiers livrables.Tous les livrables peuvent être recettés. Plus tôt on connaît les erreurs et les anomaliessur le produit, moins la correction est coûteuse et moins leurs effets sur les autreséquipes de développement sont perturbateurs. Attendre d’avoir un ensemble suffisant defonctionnalités pour commencer les tests est un leurre, qui cherche souvent à masquerune finition insuffisante des premières livraisons, et donc probablement un retard. Lestests correspondent à la confrontation avec la réalité des livrables.

Les tests unitaires

Les tests unitaires constituent la charnière entre l’équipe de développement et l’équipede test. Leur fonction est de vérifier le fonctionnement de chaque élément d’une fonctionselon sa description dans les spécifications détaillées. Pour que le développeur puissecommuniquer son code à l’équipe de test, il faut qu’il fonctionne raisonnablement bien.

C’est avec les tests unitaires que l’on garantit que les rôles sont effectivement respectésentre les équipes de test et de développement. Le développeur accompagne ses produc-tions jusqu’à un point où leur fonctionnement est correct à ses yeux. Pour y parvenir, ildoit vérifier lui-même par des tests unitaires que sa réalisation respecte les spécificationsdétaillées.

Il est inutile que les livrables soient échangés plusieurs fois entre les équipes de dévelop-pement et de test avant de parvenir à couvrir les fonctionnements de base décrits dansles cas d’utilisation. Ces échanges répétés entraînent une perte importante de producti-vité et des tensions entre les équipes de développement et de test. Les plannings déra-pent, et les équipes de développement voient leur production renvoyée pour correctionun grand nombre de fois. Ces échanges créent de surcroît des tensions entre les collabo-rateurs, qui voient leurs plannings glisser et réalisent qu’ils ne pourront tenir leurs enga-gements.

L’équipe de développement doit effectuer elle-même les tests unitaires visant à vérifierque le produit qui sera livré aux équipes de test correspond aux fonctionnalités atten-dues. Pour ce faire, elle dispose de cahiers de test unitaire comportant des jeux dedonnées stables et adaptés, précisant la nature des tests qui doivent être réalisés. Ledéveloppeur ne considère sa production livrable aux tests que si elle a passé avec succèsles tests unitaires. Le fait de les réaliser lui-même lui permet de corriger rapidement lesdysfonctionnements.

L’équipe de test qui reçoit un livrable s’attend à un niveau de qualité assez élevé. Il fautque le développeur soit réellement motivé pour livrer la meilleure qualité qu’il peut


Chapitre 13 – Gestion des tests et de la qualité

271

atteindre. Certaines équipes en offshore donnent des bonus aux développeurs selon lefaible nombre d’anomalies détectées par l’équipe de test afin de favoriser une qualitéoptimale entre les tests et les développements. Le développeur reçoit une prime pour laqualité de sa livraison, et le testeur pour sa capacité à trouver les anomalies.

Le résultat des tests est consigné dans un tableau indiquant quels tests ont été exécutéset leurs résultats. La première tâche du testeur est d’exécuter les tests unitaires sur saplate-forme de test afin de vérifier que le développeur a atteint le niveau de qualitéminimal permettant de commencer les tests.

Si le client choisit de ne pas monter une équipe de test chez le prestataire et d’assurer lui-même les tests localement, la formalisation des tests unitaires qui était déjà fortementsouhaitable, devient incontournable.

EN RÉSUMÉTests unitaires et productivité

Les tests unitaires vérifient le comportement d’une fonction. Pour assurer une meilleure efficacitédes équipes de test et de leurs échanges avec les équipes de développement, il faut convenir d’unniveau de qualité minimal des éléments livrés par les développeurs aux testeurs. Les développeursassurent la réalisation des tests unitaires avant de transmettre leur production aux équipes de test.

Les tests unitaires sont décrits formellement par des cas de test préparés par les équipes de test oupar les chefs de produit et sont accompagnés d’un jeu de test représentatif de tous les cas à tester.On garantit ainsi que le niveau minimal de qualité attendu par les testeurs est assuré par les équipesde développement.

Les tests fonctionnels

Les tests fonctionnels ne peuvent être correctement réalisés que si l’on dispose de spéci-fications détaillées, complètes et à jour. Les modifications des spécifications et les ajoutsdoivent faire l’objet d’une mise à jour immédiate des documents de référence.

L’IHM est également construite à partir des documents de référence, souvent à l’aided’une boîte à outils permettant d’appliquer une normalisation.

Les tests sont construits sous forme de plans de test que l’on peut demander aux équipesen offshore d’élaborer en s’appuyant sur les spécifications ou les règles de l’IHM. Onessaie ainsi de couvrir toutes les actions et de vérifier le comportement du produit,d’abord avec des tests positifs (le produit assure-t-il le service qu’il est censé rendre ?)puis avec des tests négatifs (le produit gère-t-il toutes les erreurs qui peuvent seproduire ?). Les tests sont naturellement placés sous la supervision du chef de produit,qui en apprécie la qualité et l’exhaustivité.

À chaque itération, un point complet est effectué sur les livraisons. L’état d’avancementdu produit est entièrement testé afin d’évaluer sa qualité. On peut aussi essayer de viserune intégration continue avec un build quotidien, bihebdomadaire ou hebdomadaire.

L’équipe de test s’inquiète en permanence du niveau de qualité du produit. À chaquebuild, le testeur cherche à savoir quel est l’état de qualité de chaque fonction, puisqu’elleest potentiellement modifiée.



272

Si les développeurs n’ont pas modifié le code source de la fonction depuis qu’elle a ététestée, on peut supposer que les résultats antérieurs sont toujours valides, sans toutefoispouvoir en être certain. Il se peut que cette fonction fasse appel à d’autres services, quiont eux été modifiés ou qui contiennent depuis peu des anomalies. On peut aussi avoirfait une correction mineure, théoriquement bénigne et parfaitement circonscrite, quiengendre des anomalies majeures inattendues dans d’autres parties du produit. Il se peutencore que la fonction ait subi des régressions sans que les causes en soient évidentes.

On ne peut vraiment connaître l’état de qualité d’une fonction qu’en la testant entière-ment. Plus les tests sont anciens, et moins les résultats obtenus lors de ces tests sontfiables quant au dernier build.

Le test d’une fonction est long et répétitif, et il est pratiquement impossible de réalisermanuellement tous les tests à chaque intégration, surtout si celles-ci ont lieu trèsfréquemment. Il faut recourir aux tests automatisés pour qualifier les builds quotidiensou bihebdomadaires.

Les tests minimaux, ou MATIl est recommandé de séparer les tests fonctionnels en deux niveaux de test, les testsprofonds, qui correspondent à des tests complets de toutes les fonctionnalités, et lestests rapides, ou MAT (Minimal Acceptance Test) , qui couvrent succinctement une sériede fonctions essentielles.

Il faut généralement plusieurs jours à l’équipe de test pour réaliser les tests complets,alors que les MAT sont davantage limités dans le temps. L’idéal est de les exécuter endeux heures. S’ils sont automatisés, on peut aller plus loin dans leur exécution que s’ilssont réalisés manuellement.

Les MAT n’étant pas exhaustifs, ils ne peuvent garantir pleinement le fonctionnement duproduit. Ils se concentrent sur les scénarios d’utilisation les plus importants et les plusutilisés par les clients. Ces tests légers peuvent être réalisés rapidement lorsqu’onsouhaite s’assurer d’un niveau de qualité minimal ou qu’il n’y a pas de régression majeureévidente.

Un MAT est construit de façon à couvrir l’effet d’une action au minimum sur tous lesmodules et tous les aspects techniques de l’application. Au moins une utilisation de tousles composants est testée, ainsi qu’au moins un accès à tous les outils de middleware, defaçon à détecter, par exemple, l’absence de déploiement d’un fichier.

Le MAT est utilisé chaque fois que l’on doit vérifier rapidement que le produit fonctionnecorrectement et qu’on n’a pas le temps de le tester totalement. On utilise le MAT pourvalider que le livrable reçu par l’équipe de test fonctionne, par exemple quand on doitlivrer un patch ou des Hot Fix. Il permet en outre de vérifier qu’un déploiement est correct,puisqu’il est censé utiliser au moins une fois tous les aspects techniques du produit, etdonc tous les fichiers, tous les éléments du middleware et tous les types d’interactionsavec l’extérieur.

Les MAT sont une série de tests très importants, que l’on a tout intérêt à automatiser afind’en augmenter l’étendue. Ils doivent être exécutés le plus souvent possible, parfois surune même version mais sur des plates-formes différentes. Ils peuvent alors faire office detests de validation de déploiement et servir de référence tout au long du travail avecl’équipe distante.



273

EN RÉSUMÉTests profonds et tests minimaux

Les tests profonds permettent de juger de l’état de qualité d’un produit dans son intégralité selon unplan de test complet. Ces tests très longs ne peuvent être effectués sur tous les builds. Ils neconviennent donc pas lorsqu’on doit livrer une version rapidement.

Les tests minimaux, ou MAT (Minimal Acceptance Test), couvrent succinctement tout le produit, ententant de se concentrer sur les scénarios les plus importants. Les MAT sont généralement automa-tisés. Utilisés pour toutes les recettes rapides visant à estimer l’état de qualité du produit ou àdétecter les régressions majeures, ils peuvent également servir à valider le déploiement sur uneplate-forme.

Juger de l’état de qualitéLes MAT peuvent être exécutés sur tous les builds, donnant ainsi une première idée del’état de qualité et de stabilité d’une livraison. Cet aperçu est toutefois peu profond, et ilne permet pas de juger de l’état du produit ni de sa progression dans le temps vers unproduit stable, utilisable et de qualité.

Pour suivre l’état de qualité, on peut utiliser un tableau, dit Acceptance Sheet, permettant desuivre le résultat et l’ancienneté des tests pour chaque fonctionnalité (feature). On visua-lise de la sorte sur un même document les résultats des tests les plus récents et l’état deconnaissance que l’on a des campagnes de tests plus anciennes. Un modèle de tableaude ce type est fourni en annexe.

Le tableau 13.1 indique les principes de fonctionnement de l’Acceptance Sheet .

Le tableau montre que l’on ne connaît de façon sûre que l’état de la fonctionnalité 1, lesautres fonctionnalités n’ayant pas été testées sur la dernière campagne de test. On ne saitpas vraiment quel est l’état de la fonctionnalité 3, dont les derniers tests sont anciens.Pour les fonctionnalités 2 et 4, on dispose d’une connaissance vraisemblable de l’état dequalité, puisque les informations remontent à la campagne de test précédente. L’état dechaque colonne peut bien sûr être codé par des couleurs représentant visuellement l’état

Tableau 13.1. Exemple d’Acceptance Sheet

FonctionnalitéCampagnede test 12

Campagnede test 13

Campagnede test 14

Campagnede test 15

Campagnede test 16

Fonctionnalité 1 Bogue mineurCR0034, CR0035

Bogue mineurCR0034

OK

Fonctionnalité 2 OK Bogue majeurCR0056

Fonctionnalité 3 OK

Fonctionnalité 4 Bogue majeurCR008

OK Bogue mineurCR0087

OK



274

de qualité. Lorsqu’une anomalie est identifiée, on place son code dans la case qui lareprésente de façon à vérifier son état ou sa priorité plus facilement.

L’analyse de l’Acceptance Sheet permet de se faire une idée du risque que l’on prend àlivrer une version. On peut juger de la qualité du produit global, des régressions (on passedu vert au jaune ou au rouge), du risque que l’on prend en ne retestant pas une fonction-nalité d’après l’ancienneté du dernier test passé avec succès, et l’on dispose du détail desanomalies connues sur chaque fonctionnalité.

Si le produit est destiné à plusieurs plates-formes de déploiement, par exemple, si l’on aune portabilité sur plusieurs systèmes d’exploitation ou plusieurs bases de données, onpeut prévoir d’effectuer une rotation des plates-formes de test et de noter la plate-formeutilisée pour les tests pour chaque campagne de test.

Ce tableau est particulièrement utile pour les développements en offshore car il permetde connaître la stabilité d’un produit en cours de construction. Cela évite que les équipesde validation ne travaillent sur des fonctionnalités dont les anomalies sont connues. Ilpermet également de donner des priorités de réalisation aux tests. Il sert alors d’outil dedécision sur les tests à réaliser et évite de travailler sur des fonctionnalités connues pourêtre boguées de façon à se concentrer sur celles qui sont réputées saines.

Si l’on dispose d’une intégration continue et si des tests automatisés sont exécutés quoti-diennement, on voit le produit non seulement se construire pas à pas, mais se stabiliser.On dispose d’une source d’information permettant de juger de la réalité de l’informationfournie par les équipes sur la progression du développement.

Les tests fonctionnels transversauxLes procédures décrites précédemment cloisonnent fortement les tests par fonction etpar module, toute l’organisation étant structurée par composant. De son côté, l’utilisateurs’intéresse avant tout à des tests métier, qui sont transversaux et suivent son chemine-ment à travers des séries d’actions faisant appel aux différents modules de l’application.

Il se peut que deux modules soient communément utilisés ensemble, par exemple, lamise à jour d’une information doit être reprise dans un tableau synthétique faisant partied’un autre module. Le cloisonnement par module peut faire que l’on ne teste jamais cescroisements de mises à jour. Les tests transversaux visent à combler ces défaillances. Ilssont souvent organisés sous forme de scénarios métier, dans lesquels on accompagne lesactions d’un utilisateur final à travers un cheminement sur plusieurs modules.

Si nous insistons ici sur un sujet qui peut paraître évident c’est qu’il est une source récur-rente de problèmes avec l’offshore lorsqu’on met en place une méthodologie industriellepour la première fois. On a alors tendance à se concentrer sur des tests très structurés, etl’on en oublie la vision d’ensemble.

Lorsqu’on met un produit testé par fonction entre les mains d’un utilisateur final, desanomalies majeures sont souvent trouvées dès les premières minutes d’utilisation, qu’ilétait impossible de détecter lors des tests de fonction. La confiance s’effondre alors rapi-dement, surtout si l’on a affirmé que le produit était bien testé, fort des nombreux testscloisonnés effectués.

Comme les tests par module et par fonction, les tests transversaux doivent être assuréset renseignés dans des Acceptance Sheets. Les scénarios sont beaucoup plus difficiles àréaliser, car ils peuvent être très nombreux. Les chefs de produit sont particulièrement



275

sollicités pour donner une réalité métier à ces tests. Lorsque les utilisateurs fi nals rencontrentde nouvelles anomalies, ces cas de test sont ajoutés aux tests transversaux. Les teststransversaux sont structurés et documentés. Ils sont en outre reproductibles.

Les tests intuitifsLes tests intuitifs sont des tests qui ne sont pas formalisés. On y fait ce que l’on veut pourdétecter des anomalies selon son intuition ou son expérience. Les tests formalisés nepeuvent en effet tout prévoir. Par exemple, il est possible que l’on ne prévoie pas de testerformellement la couleur du fond d’écran, bien qu’elle soit définie dans la charte graphiquedu projet. Une erreur sur la couleur de l’écran est pourtant immédiatement visible de toututilisateur.

C’est un des défauts que l’on attribue très souvent aux équipes en offshore. On dit qu’ellessuivent les procédures à la lettre mais ratent les erreurs les plus flagrantes, sous prétextequ’elles ne sont pas détectées dans les scénarios de test.

Le testeur qui connaît les développeurs et leurs erreurs peut anticiper les domaines où ilscréent le plus souvent des anomalies et peut les rechercher directement. Bien sûr, cestests ne sont pas reproductibles et ne sont pas documentés, mais ils sont d’une remar-quable efficacité.

Il est recommandé d’allouer un certain temps sur chaque itération pour ces tests intuitifs.

Enrichissement des testsLorsque des anomalies sont détectées par les utilisateurs, il est important de comprendreoù se trouve la faille dans les processus de test et de la combler, dans la mesure dupossible, afin d’éviter que cette famille d’anomalies ne perdure.

Comme les équipes de test sont distantes, il est essentiel que les anomalies détectées endehors d’elles leur soient transmises et qu’elles soient considérées non comme desfautes de leur part, mais comme des failles à combler.

Si l’on ne prend pas soin d’avertir les équipes de test des anomalies, les testeurs nepeuvent améliorer les processus de test. Du côté du client, on pensera que les testeurs nesont pas très efficaces puisqu’ils travaillent en dehors de la réalité. Il faut donc toujourscommuniquer aux équipes en offshore le niveau de satisfaction des utilisateurs. Cettecommunication n’est jamais naturelle. Il est du ressort du chef de projet du client de fairecomprendre aux équipes distantes ce que pensent les utilisateurs du produit.

Si les équipes en offshore estiment que le produit est apprécié alors que l’utilisateur seplaint d’une grande quantité d’anomalies, l’hiatus de perception peut vite devenir intolé-rable et est compris comme un signe de dysfonctionnement majeur de l’offshore. Il estfacile de mettre en place un retour d’information sur la satisfaction des clients et sur lavie du produit. Les retours positifs sont de surcroît des sources de motivation. Quant auxretours négatifs, ils motiveront la concentration sur les faiblesses constatées.

Grâce à une communication efficace, l’équipe de test comprend les problèmes des utili-sateurs et propose des moyens d’y remédier. Elle se trouve plus impliquée dans la vie duprojet, et il y a tout lieu d’espérer que la recherche de la qualité s’en trouve renforcée.



276

EN RÉSUMÉSatisfaction des utilisateurs et motivation

Les équipes en offshore doivent être informées du niveau de satisfaction des utilisateurs finals. Unedifférence de perception de ce niveau devient vite intolérable. Une bonne connaissance de la satis-faction des utilisateurs peut être une source de motivation et de concentration sur les sujets les plusimportants pour ces derniers.

Les tests techniques

Les tests techniques n’attirent vraiment l’attention que lorsque le projet va mal ou queles performances ne sont pas au rendez-vous. On en trouve une grande variété, depuis lestests de performance jusqu’aux tests de charge, en passant par les tests des servicestechniques.

Si le client travaille sur un projet important et qu’il ait choisi d’automatiser certains tests,on peut mettre en place plusieurs types de tests techniques en s’appuyant sur cette auto-matisation. On pourra ainsi détecter les régressions sur les temps de réponse et identifierla modification qui en est la cause.

Bien souvent, l’équipe qui s’occupe des services techniques jouit d’une situation particu-lière. Sa production n’est pas directement testée par les équipes de test puisque cesdernières ne peuvent aisément tester des bibliothèques de fonctions sans interface utili-sateur. Cette production est cependant recettable et testable, et il n’y a pas de raison queles services techniques ne soient pas testés comme les autres. Le testeur représente ici leclient de ces services, c’est-à-dire les développeurs fonctionnels.

Les testeurs des services techniques construisent de petites applications qui les utilisent.Les scénarios de tests peuvent être formalisés. Le meilleur test est encore la mise encondition, consistant à appliquer la nouvelle version des services techniques aux réalisa-tions fonctionnelles existantes. L’équipe de test technique peut vérifier ce fonctionne-ment sans que les équipes chargées des développements fonctionnels soient affectéespar les périodes de stabilisation. Les nouveaux services techniques sont livrés après queles développements fonctionnels ont été vérifiés.

Bien souvent, une production défaillante de services techniques peut retarder des livrai-sons, alors que les équipes fonctionnelles n’y sont pour rien. Pour que les équipes char-gées des développements fonctionnels s’engagent pleinement sur leurs itérations, il fautéviter dans la mesure du possible que ces défaillances extérieures ne leur donnent l’occa-sion de se déresponsabiliser. Si l’on parvient à isoler les livraisons des services techni-ques, on fait plus clairement endosser leurs responsabilités par les équipes.

Couverture des tests

Certains produits de test permettent de tester la couverture des tests en marquant leslignes de code exécutées lors des séquences de test. Ces produits ne sont malheureusementpas disponibles pour tous les langages de programmation.



277

Lorsqu’on peut les utiliser, ils se révèlent très utiles pour repérer des pans entiers du codesource qui n’auraient pas été testés. On peut dès lors revoir les scénarios de test ouestimer les tests partiels suffisants.

Ce type d’outil permet d’éliminer une forte incertitude sur les anomalies cachées dans leproduit. Si l’on connaît précisément les portions de code testées régulièrement, et surtoutles fonctions qui ne font pas encore l’objet de tests structurés, on peut estimer assezjustement le risque que l’on prend en considérant l’application comme testée. On neconnaît certes pas la quantité d’anomalies qui persistent, mais on a une bonne idée durisque que l’on prend si l’on décide de ne pas tester ces parties de code source.

Comme les tests en offshore sont le plus souvent fortement structurés, on peut savoirprécisément quelle est la proportion du code source qui est contrôlée régulièrement.

Il est recommandé de lancer une campagne de détection de la couverture des testslorsque le produit est terminé environ aux trois quarts. Cela permet de décider des actionscorrectives à engager en ayant encore le temps de les réaliser.

Vis-à-vis du client comme des utilisateurs finals, il est particulièrement valorisant depouvoir quantifier la quantité de lignes de code testées de façon automatisée, à la foisrégulièrement et occasionnellement. Cela n’excuse sans doute pas d’éventuelles anomaliesmajeures mais fait la preuve de l’engagement de moyens sur les tests.

Les tests de déploiement

Situés à la charnière entre l’offshore et le client, l’intégration et le déploiement sont desactivités délicates. Les plates-formes chez le client sont souvent différentes de cellesqu’on utilise en offshore, et les problèmes de déploiement sont très courants.

Comme pour la plupart des autres activités, le livrable, c’est-à-dire l’application déployée,doit être recetté. Pour ce faire, on peut exécuter un scénario de test à la main ou exécuterle MAT, ou une version réduite du MAT, de façon automatisée. Une exécution sans erreurdu MAT ou d’une version réduite est indicative d’un bon déploiement.

Tests et mesure du risque

Lorsque les équipes de test sont proches des utilisateurs, elles sont perçues assez natu-rellement comme étant chargées de limiter les risques d’insatisfaction. Avec des équipesde test en offshore, les utilisateurs se montrent toutefois moins tolérants aux erreursqu’ils détectent et sont prompts à déclarer les testeurs éloignés des réalités.

Les équipes de test ne doivent jamais perdre de vue qu’elles représentent les utilisateursdans l’équipe en offshore. De ce point de vue, elles sont les plus importantes. Ellesdoivent en être conscientes, et l’importance de leur rôle doit être reconnue de tous lesautres collaborateurs. Les développeurs ont parfois l’impression qu’une hiérarchie par lacompétence s’établit naturellement. Donner une grande valeur aux tests bouscule cettehiérarchie et affirme le rôle des testeurs.



278

Lorsque les équipes de test se mettent dans la peau de l’utilisateur final, elles doiventmesurer les dysfonctionnements du produit comme le ferait cet utilisateur. Pour cela,elles doivent comprendre exactement comment le produit sera utilisé.

Les fonctionnalités du produit qui sont utilisées en permanence doivent être parfaite-ment testées car l’utilisateur ne tolère aucun défaut. Les mauvais alignements, leslenteurs d’exécution, les fautes d’orthographe, etc., lui sont insupportables. Il est enrevanche beaucoup plus tolérant à l’égard des fonctionnalités qu’il utilise rarement et quipeuvent comporter certaines anomalies, même plus graves, pour peu qu’elles ne créentpas de gêne importante. Les testeurs doivent donc prendre de l’altitude par rapport auxprocédures pour comprendre par eux-mêmes l’importance relative des différents tests.

Les régressions sur un produit créent des réactions particulièrement vives de la part desutilisateurs. S’ils peuvent comprendre qu’un cas ne fonctionne pas, ils considèrentcomme de la pure négligence qu’une anomalie apparaisse sur des fonctionnalités quidonnaient satisfaction auparavant.

La mesure du risque ne peut être juste que si l’on essaie de l’estimer tel qu’il est perçupar le client. Les équipes de test pourraient passer un temps infini pour assurer qu’unproduit ne contient pas d’anomalies et se comporte comme on le souhaite. Il convientdonc de vérifier régulièrement que le temps passé à contrôler un produit est rentable. Unetelle estimation est toutefois délicate. Plus le temps passe, plus les anomalies sont diffi-ciles à détecter, et plus leur coût de détection devient important.

Si les tests sont bien organisés, ils doivent permettre de se concentrer d’abord sur lesanomalies le plus importantes. Le moment arrive ensuite où l’on préfère mettre le produiten production et gérer les anomalies détectées par les utilisateurs plutôt que de continuerà détecter d’autres anomalies.

La figure 13.1 illustre le rythme de détection des anomalies build après build comparé aucoût des détections et au nombre d’anomalies non détectées dans le produit.

Le risque est difficile à estimer, car on ne sait pas vraiment mesurer les anomalies restéescachées dans le produit. On prend les décisions par rapport au nombre d’anomaliesrépertoriées et à la difficulté à détecter de nouvelles anomalies. C’est pour éviter que cettedernière mesure ne soit faussée que l’on recommande d’exécuter des tests intuitifs endehors de toute procédure. Cela permet de ne pas appliquer les mêmes scénarios de testmécaniquement, car ceux-ci découvrent de moins en moins d’anomalies lors des buildssuccessifs jusqu’à ne détecter que les anomalies de régression lorsque tous les scénariosont été vérifiés avec succès au moins une fois.

EN RÉSUMÉMesure du risque et coût des tests

Le risque doit être estimé par rapport aux engagements du client sur la livraison du produit et surtoutpar rapport à la satisfaction des utilisateurs. Les équipes de test sont les plus proches représentantsdu client et des utilisateurs chez le prestataire. Il est important qu’elles essaient de mesurer enpermanence le risque en se mettant à la place de l’utilisateur et en estimant son niveau de satisfac-tion. Elles doivent se faire les avocats des utilisateurs.

Les décisions doivent être prises en visant la satisfaction des utilisateurs finals afin de déterminercomment équilibrer les tests pour limiter au mieux le risque d’insatisfaction. On détermine ainsi lepourcentage des tests structurés (scénarios de test réalisés régulièrement), automatisés, techniqueset intuitifs. L’équipe de test doit être une force de proposition pour optimiser le risque, tant auprès duclient que des autres équipes chez le prestataire.



279

Conclusion

Bien souvent, les équipes de test sont considérées comme moins importantes que leséquipes de développement. Les services qu’elles rendent sont souvent mal considérés, etelles sont tenues pour responsables de nombreux maux dont elles ne portent pourtantqu’une responsabilité limitée. Toute anomalie qui serait détectée après leur travail estconsidérée comme inacceptable.

En réalité, les testeurs assurent avant tout des tâches planifiées et documentées, dont onpeut juger la bonne ou mauvaise réalisation de façon assez simple. C’est leur premièremission, mais il ne faut surtout pas qu’ils s’arrêtent là. Ils doivent représenter le client etl’utilisateur du produit chez le prestataire et faire tout leur possible pour limiter lesrisques sur le produit et accroître la satisfaction des utilisateurs.

Le travail des équipes de test est extrêmement difficile, car elles sont les coupablesdésignés de tous les maux, ou presque. Comme elles assurent les dernières tâches avantlivraison, elles sont toujours pressées par le client pour terminer leurs tâches de test au plusvite. C’est d’autant plus difficile que, bien souvent, elles ont reçu les livrables en retard dela part des équipes de développement. Lorsqu’une anomalie grave est découverte,l’équipe de test est immédiatement montrée du doigt pour ne pas l’avoir découverte

Figure 13.1. Coûts et efforts de détection d’anomalies



280

avant l’utilisateur, même si cette anomalie ne fait pas partie des scénarios de testhabituels.

Les équipes de test ont un travail beaucoup moins créatif et motivant que la plupart desautres équipes en offshore. Leur travail est répétitif, et il est difficile de leur conserver uneforte motivation.

Les équipes de test doivent s’aligner en permanence sur les attentes du client, ce qui leurdemande un effort d’écoute continu, que les autres équipes n’ont pas besoin d’effectuerdans de telles proportions. C’est d’autant moins facile qu’il s’agit d’une écoute à distancedu client pour comprendre sa façon de réaliser la recette et les sujets qui lui tiennentle plus à cœur. Les équipes de test sont bien les meilleurs représentants du client chez leprestataire et doivent être reconnues comme tels, si l’on souhaite rendre leur rôle plusmotivant et influent.

Une équipe valorisée et bien organisée apporte un confort important dans la livraison desexécutables et permet de stabiliser beaucoup plus tôt les livrables en leur faisantatteindre un niveau de qualité satisfaisant aux exigences du client. Elle évite en outre leséchanges inutiles entre le client et le prestataire pour stabiliser le produit.

Lorsqu’on parvient à créer une telle équipe de test, le travail en offshore devient beaucoupplus simple, et l’on évite de nombreux heurts. La satisfaction est au rendez-vous, chez leclient comme chez le prestataire.


281

Chapitre 14

Intégration et déploiement

Lorsqu’on travaille avec des équipes en offshore, on se concentre avant tout sur les équipesde développement. Les équipes de test sont parfois oubliées, surtout si l’on ne fait pas ladifférence entre test et recette et qu’on place cette dernière chez le client, et il est rare quel’on pense aux équipes d’intégration et de déploiement. Les premières livraisons au client sontalors des casse-tête souvent cités en exemple des difficultés à travailler avec l’offshore.

Les produits qui sont aujourd’hui développés en offshore ne se transportent pas aussifacilement qu’on le croit. Le temps des exécutables aisément transportables a pratique-ment disparu. Les déploiements actuels sont multiserveurs. Ils demandent une compila-tion sur la plate-forme cible et s’accompagnent du déploiement et de la configuration detoute une série d’autres produits périphériques (base de données, serveur d’applications,message queueing, équilibreur de charge, etc.).

Les premiers déploiements concernent des exécutables qui ne sont pas tout à fait fina-lisés et dont les procédures d’installation sont encore inexistantes ou tout juste émer-gentes. Ce qui fonctionne en offshore ne fonctionne pas nécessairement localement. Sil’on n’a pas prévu de créer une équipe d’intégration et de déploiement et que le produitnécessite une gestion de plate-forme avancée, on peut être certain que le déploiement dela solution sera perçu comme un problème. Ce problème s’envenime rapidement pourpeu que le client s’agace de ne pouvoir appréhender le produit que ses chefs de projet enoffshore disent fonctionner raisonnablement bien et qu’il perde confiance dans la qualitéde la production en offshore.

Si l’on reconnaît l’importance du déploiement et de la configuration de la plate-forme, onpeut choisir de créer une équipe d’intégration et déploiement (ID) pour automatiser,configurer et déployer la production des équipes distantes. On peut aussi étendre leursresponsabilités pour assurer la supervision et l’administration des plates-formes, venantainsi en support des équipes du client.

Gestion des plates-formes

La gestion des plates-formes inclut celle de tous les progiciels utilisés avec le produit. Ony trouve bien sûr les systèmes d’exploitation, la base de données, mais aussi le



282

middleware (serveurs EJB, servlets, etc.) et, éventuellement, les progiciels fonction-nels sur lesquels s’appuie l’application. Ces produits demandent une gestion souventassez lourde pour suivre leur configuration, assurer les optimisations, étudier lesmises à jour des versions et préparer les migrations vers une nouvelle version de certainscomposants.

L’équipe ID a pour responsabilité de configurer les couches techniques. Elle doit pourcela connaître précisément le fonctionnement interne de l’application afin de déterminerles services qui doivent être ouverts sur les serveurs. Par exemple, en maintenant la listede tous les protocoles utilisés entre les composants et les serveurs, elle peut filtrer effi-cacement les échanges entre les serveurs en n’autorisant que les flux utiles, en améliorantdu même coup le niveau de sécurité de la plate-forme.

L’équipe ID a aussi pour responsabilité d’organiser la création des scripts d’assemblagedes builds et de déploiement vers les différentes plates-formes cibles. Elle analyse lesdemandes d’évolution exprimées par le client et propose des plans d’action. Par exemple,si l’on veut que l’application, développée en Java et déployée jusqu’à présent sur desserveurs sous Windows, puisse être déployée sur une plate-forme sous Linux ou si l’onsouhaite utiliser un serveur d’applications JBoss au lieu de BEA WebLogic, l’équipe IDétudie les problèmes potentiels et propose un plan d’action que le client choisirad’activer ou non.

L’équipe ID s’assure de produire les notices de déploiement et de maintenance des appli-cations, surtout lorsque l’hébergement est assuré par un tiers, qui est responsable d’uncertain niveau de service et qui assure lui-même toutes les tâches de déploiement. Ellepeut en outre assurer la supervision des plates-formes en vérifiant que l’application peutêtre administrée par les outils de supervision du marché. Elle peut proposer, par exemple,que le produit supporte des interfaces d’administration plus riches afin d’assurer unesupervision plus fine.

Assurer un service de supervision des plates-formes de production vingt-quatre heuressur vingt-quatre et sept jours sur sept n’est pas toujours facile et exige au moins cinqcollaborateurs. Les équipes ID offshore peuvent assurer un tel service, parfois avec uneflexibilité et pour un coût très intéressants.

Comme nous le voyons, l’équipe ID n’est pas une équipe mineure dans l’organisation desréalisations offshore. Elle joue un rôle charnière au moment de la livraison et peut fournir unequantité de travail importante pour accompagner la solution une fois déployée, allégeantd’autant le travail des équipes du client.

EN RÉSUMÉL’équipe IDUne équipe dédiée à l’intégration et au déploiement en offshore (ID) complète harmonieusement leséquipes de développement et de test en accompagnant les livrables jusqu’à fournir une solutiondéployée et recettable sur une plate-forme supervisée. L’offshore apporte à cette discipline forte-ment consommatrice de ressources de précieux avantages en terme de coûts et de flexibilité pourachever les travaux de construction de la solution.


Chapitre 14 – Intégration et déploiement

283

Fondations techniques et procédures

On peut décomposer en couches les éléments techniques sur lesquels s’appuie l’applica-tion, comme l’indique le tableau 14.1.

Tableau 14.1. Fondations techniques

Couche technique Fréquence des évolutions Intégration et déploiement

SE (système d’exploitation)

Service Packs assez fréquents et nouvelles versions rares

– Étude et validation des nouvelles versions– Prise en compte des nouvelles possi-bilités– Évaluation des risques et proposition d’une méthode de migration sur les nouvelles versions ou d’autres SE

Middleware, base de données, serveur d’applications (EJB), etc.

Service Packs assez fréquents et évolution le plus souvent annuelle des produits

Mêmes tâches que pour les SE

Configuration et opti-misation des systè-mes d’exploitation et du middleware

Évolutions très fréquentes lors des premiers déploiements et peu d’évolu-tions une fois le système stable

– Étude des évolutions du produit– Recommandations pour faire un produit plus propre, par exemple en limi-tant les protocoles– Étude des performances du système et proposition d’évolutions

Supervision Évolution rare des outils de supervision – Suivi des outils de supervision de la plate-forme– Création de nouvelles sondes ou d’interfaces pour mieux suivre le comportement de la plate-forme

Scripts de création de builds et de déploiement

Évolutions liées aux versions majeures ou aux nouvelles cibles technologiques

– Création des scripts avec les fichiers de configuration des déploiements– Maintenance de ces scripts

Versions majeures de l’application

Évolutions le plus souvent annuelles ou rares

– Mise à jour des scripts de déploiement.– Mise à jour des procédures de vérification du produit déployé

Service Packs Périodicité assez courte de release des Service Packs

Création des scripts de déploiement

Patch et Hot Fix Périodicité aléatoire Création des scripts de déploiement



284

En identifiant les différentes couches techniques utilisées par le projet, on peut en indus-trialiser la gestion par couche et éviter qu’elles deviennent des sources de dysfonctionne-ment lors des livraisons au client ou lors des déploiements chez les utilisateurs.

Chacune de ces couches techniques peut être versionnée, et les évolutions peuvent êtregérées selon des procédures similaires à celles des évolutions fonctionnelles. Toute demandede changement des fondations techniques doit suivre un workflow, à l’image des demandesd’évolution. L’équipe ID expose alors son analyse et les risques attachés aux changements.

Certaines évolutions peuvent avoir un impact déstabilisant, qui peut exiger que l’onattende le moment adéquat afin d’en limiter les effets. Par exemple, si l’on gère une appli-cation de comptabilité, on peut éviter de mettre à jour une plate-forme vers la fin del’année, moment où un grand nombre de sociétés clôturent leur exercice.

L’organisation des fondations techniques est l’un des problèmes majeurs à résoudrelorsqu’on gère des projets avec une équipe offshore et que l’application est délicate àdéployer. On néglige souvent de mettre en place les procédures qui conviennent pourgérer ces différentes fondations techniques. Sans cadre procédural, ces dernières diffèrentrapidement de celles du client, engendrant des différences de comportement du fait de ladifférence de versions ou de configurations d’éléments techniques. Chacune des couchestechniques doit être associée aux procédures permettant de les gérer sans ambiguïté.

Il est fréquent que le client ne parvienne pas à déployer les premières livraisons du parte-naire. Après quelques tentatives d’assistance par téléphone et messagerie, le clientdemande à certains collaborateurs en offshore de venir chez lui pour l’aider. Une fois chezle client, ils forment des spécialistes pour assurer les déploiements ultérieurs. Ces spécia-listes chez le client sont toutefois souvent occupés à d’autres tâches, comme le supporttechnique pour les utilisateurs, ou assurent des déploiements d’autres applications oud’autres tâches. Ils ne sont donc pas aussi performants que les collaborateurs du presta-taire pour l’application développée en offshore.

Les migrations techniques majeures ou le support de nouvelles technologies sont desdécisions importantes, qui impliquent de nombreux intervenants. Les raisons de cesévolutions sont multiples. Les utilisateurs peuvent vouloir utiliser des technologies plusrécentes, par exemple pour combler certains trous de sécurité ou apporter un gain deperformance, ou souhaiter installer des corrections d’anomalies gênantes.

Certains utilisateurs peuvent demander avec force que leur fournisseur leur donne uneversion compatible avec leurs choix stratégiques. Ces choix peuvent concerner des techno-logies qui ne sont pas supportées par l’application. Par exemple, l’utilisateur peut deman-der que la base de données soit Microsoft SQL Server, alors que seul Oracle Server estsupporté et que le travail technique peut être trop limité pour supporter cet autre serveurde données.

La quantité de test à réaliser sur chaque version doit être considérée avec attention, carc’est un coût récurrent inévitable. Les équipes de test et celles d’intégration et de déploie-ment peuvent évaluer les tâches à réaliser. Si le client le décide, les tests peuvent êtredimensionnés de sorte à assurer également ces tâches.

Pour les applications complexes, le déploiement de l’application peut donner lieu à desanomalies qui ne sont dues qu’à des différences entre les plates-formes de test et deproduction. Lorsqu’on parle de déploiement de plates-formes multiserveur, aux configu-rations fortement sécurisées et qui gèrent de façon très étroite les services et les proto-coles utiles, il est indispensable de mettre en place des procédures de déploiement



285

strictes permettant de créer des plates-formes identiques. Les anomalies que l’on c onstatesur une plate-forme doivent pouvoir être constatées sur les autres, ou, si les plates-formes réagissent différemment, leurs différences doivent être connues et maîtrisées.

Le client détermine les procédures qui conviennent le mieux à la nature du projet et à laculture de l’entreprise. En tout état de cause, on peut s’attendre à ce qu’elles ne soientstables qu’après plusieurs tentatives.

EN RÉSUMÉGestion des fondations techniques et procédures

Les fondations techniques sont trop souvent négligées dans les projets en offshore. L’absence degestion de celles-ci crée une forte instabilité lors des livraisons des exécutables et génère une frus-tration importante chez le client.

Les fondations techniques devraient être gérées comme le sont les fonctionnalités, c’est-à-dire parversion. Les demandes d’évolution ou de changement doivent être gérées et suivies selon des procé-dures faisant intervenir tous les intervenants, après une estimation des coûts immédiats et récurrents.

Le déploiement chez le client

Certaines technologies sont trop complexes pour que le client, aussi compétent soit-il,soit capable de déployer localement le produit réalisé en offshore avant d’avoir formé desspécialistes. Cela vaut d’autant plus si le produit doit d’abord être déployé alors qu’il estencore en chantier et que les scripts automatisés de déploiement ne sont pas disponibles.

Fort de ses compétences sur les technologies utilisées, le client souhaite souventdéployer les livraisons par lui-même, sans toujours réaliser le mécontentement que celasuscite. Il y investit un temps considérable, pour finalement ne parvenir à déployer l’appli-cation que sur une plate-forme au comportement différent de celui observé en offshore.Le mécontentement croît encore lorsque les anomalies détectées chez le client ne sereproduisent pas chez le prestataire, parfois du fait de différences de déploiement. Ilrésulte des tensions inutiles et une perte de confiance. Le client peut même penser quele prestataire lui cache la réalité de la situation.

Le versionnement des fondations techniques permet de vérifier la conformité des plates-formes et de réduire les risques liés à ces dernières. Il est toujours bon de responsabiliserles équipes en offshore sur toutes les phases du projet, y compris le déploiement sur laplate-forme client. On recommande généralement que la première livraison chez le clientsoit effectuée par un collaborateur du prestataire qui se rend chez le client et lui expliqueen détail le contenu technique de l’application.

Le prestataire se trouve ainsi pleinement responsabilisé sur la qualité du déploiement. Iln’y a plus de fracture entre la production chez le prestataire et le déploiement chez leclient, et la continuité est garantie.

EN RÉSUMÉÉquipes offshore et déploiement

Les équipes en offshore peuvent jouer un rôle important pour le déploiement des solutions sur lesplates-formes du client, complétant de la sorte le travail de construction de la solution par undéploiement prêt à être recetté. Il est possible de s’assurer que les plates-formes en offshore et chezle client se comportent de la même façon et que les anomalies soient aisément réplicables.



286

Les tests chez le client

Certaines applications peuvent nécessiter des déploiements complexes. Dans les archi-tectures Java EJB ou .Net, par exemple, on peut trouver plusieurs couches de serveurs,depuis les serveurs de front-end, qui assurent l’interface avec les utilisateurs qui accèdentau service par Internet, jusqu’aux serveurs d’applications, qui détiennent la logique appli-cative, aux serveurs LDAP, qui gèrent les utilisateurs et leurs droits, et aux serveurs dedonnées, sans oublier les importations et exportations depuis et vers d’autres applica-tions sur la plate-forme (comptabilité, etc.). On trouve en outre des pare-feu et des équi-libreurs de charge, qui peuvent encore complexifier la solution. Pour de telles plates-formes, l’automatisation des déploiements est indispensable.

La qualité des déploiements est difficile à vérifier. Une fois les exécutables installés surles différents serveurs et les serveurs configurés comme il semble convenir, il faut encoreen vérifier le fonctionnement. Dans tous les cas, il faut être capable de recetter rapide-ment le déploiement sur la plate-forme. La fenêtre disponible pour assurer ces déploie-ments est souvent étroite, puisqu’ils nécessitent que le service aux utilisateurs soitsuspendu.

Le test sur la plate-forme du client est d’autant plus difficile que la plate-forme est fortementsécurisée. Les serveurs peuvent ne pas répondre au ping Internet et ne communiquer qu’àtravers certains protocoles, par exemple.

Pour résoudre ces problèmes, on peut commencer par vérifier que les exécutables sontdéployés comme prévu sur les différents serveurs. On peut ensuite exécuter un scénariofonctionnel de test qui a été automatisé par l’équipe de test, une sorte de MAT réduit etbien conçu en guise de test de validation de la plate-forme. Ce scénario peut avoir unobjectif technique en activant au moins une fois tous les exécutables sur tous lesserveurs. Il s’assure ainsi que les exécutables sont en place et qu’ils communiquent entreeux. L’équipe en offshore peut s’assurer de la sorte que la plate-forme ne présente pas dedysfonctionnement immédiatement détectable.

Ces tests essentiels pour assurer le fonctionnement du produit ne sont toutefois que trèspartiels. S’il y a plusieurs serveurs d’applications, on ne peut être certain que tous les serveurssont correctement déployés. On ne connaît pas non plus l’état de sécurité de la plate-forme æ il se peut que des éléments de sécurité n’aient pas été appliqués correctement,par exemple æ ni sa haute disponibilité.

Malheureusement, ces tests techniques sont extrêmement complexes et peuvent prendrebeaucoup de temps. C’est pourquoi l’on emploie souvent une plate-forme de préproduc-tion pour vérifier pendant une phase de test avant déploiement en production que lesscripts de déploiement fonctionnent correctement et pour organiser un bêta-test.

EN RÉSUMÉAutomatisation des tests de déploiement

La recette d’une solution sur une plate-forme complexe est difficile à réaliser d’une façon exhaus-tive. Les équipes offshore peuvent aider à réaliser ces recettes en fournissant des tests automatisésvalidant que tous les composants techniques répondent correctement sur la plate-forme cible.L’automatisation des déploiements est indispensable pour en assurer la réplicabilité.



287

Supervision des plates-formes

Si l’on cherche à disposer d’applications qui assurent un service sur des plages horairesimportantes, par exemple vingt-quatre heures sur vingt-quatre et sept jours sur sept (24/7), on a tout intérêt à faire appel à des ressources en offshore pour assurer la supervisionde la plate-forme. On conserve en ce cas une équipe chez le client afin d’assurer le pilo-tage de la plate-forme et prendre des décisions importantes, si le besoin s’en fait sentir.

L’équipe de supervision en offshore peut créer la documentation sur la gestion de laplate-forme, incluant toutes les actions à entreprendre pour résoudre chaque typed’anomalie, les règles de gestion de déploiement d’une nouvelle version, d’un patch oud’un Hot Fix, les façons de recetter un déploiement ou une plate-forme (recettes logicielleet matérielle), etc.

Un planning de supervision est défini pour les superviseurs, certains d’entre eux étantchez le prestataire et d’autres chez le client. Selon le niveau de service demandé, le super-viseur peut soit rester à proximité d’un point d’accès durant toute sa garde, soit avoiraccès à un ordinateur dans un temps donné. En cas d’incident sur la plate-forme, il estappelé (automatiquement ou manuellement) par l’hébergeur qui a détecté l’incident. Lesuperviseur suit alors les recommandations, en adaptant les solutions au cas précisrencontré.

Lorsqu’on a besoin d’assurer un service en 24/7, l’organisation de la supervision devientrapidement un casse-tête, qui ne peut être résolu qu’en désignant un nombre suffisant desuperviseurs. Pour une supervision continue, on parvient tout juste à assurer le service àpartir de cinq personnes. Même si la charge de travail est presque nulle et que la plate-forme ne connaît que peu de problèmes, on doit tout de même avoir un superviseur prêtà intervenir à tout moment. Dans certains cas, ce coût peut être rédhibitoire. Lesressources en offshore permettent de mettre en œuvre à moindre coût cette disponibilitéde la plate-forme.

Il faut certes toujours conserver un décisionnaire chez le prestataire pour trancher lesquestions complexes, nécessitant un investissement, ou encore pour les initiativesprésentant un risque sur le service à fournir. Par exemple, le décisionnaire peut prendrela décision d’ajouter un serveur ou de modifier la configuration des serveurs afin d’obtenirun meilleur niveau de sécurité.

C’est alors que l’utilisation de l’offshore se révèle particulièrement confortable en permet-tant de viser un taux de service élevé grâce à du personnel de haut niveau assurant lasupervision des plates-formes.

EN RÉSUMÉÉquipes offshore et supervision

Une équipe en offshore peut efficacement assurer la supervision de plates-formes de production etapporter un confort appréciable, tant pour la flexibilité, la couverture horaire et l’efficacité desservices. Elle peut compléter efficacement une équipe locale en lui donnant les moyens de travaillerefficacement.

On prendra cependant soin de s’assurer que la sécurité mise en place sur les moyens de communi-cation convient à la nature des services fournis par la plate-forme de production.



288

Préparation des livrables

Il existe plusieurs phases de préparation des livrables, dont la première consiste à extrairedu référentiel tous les artefacts (éléments) correspondant à la version que l’on souhaitecréer selon une baseline, pour peu que le référentiel soit géré correctement. On porte alorsune attention particulière à identifier les versions des composants que l’on souhaite inté-grer dans la livraison, tant chez le prestataire que chez le client. La gestion du référentieldonne sa pleine mesure pour isoler une version, y inclure la correction d’une anomalieisolée sur la version en production, préparer un Service Pack ou encore créer une versionmajeure.

L’extraction de tous les éléments compatibles à assembler peut être effectuée à l’aided’une procédure automatisée.

L’étape suivante de préparation des livrables consiste en la compilation des sourcesextraits du référentiel, éventuellement pour chacune des plates-formes cibles. La compi-lation peut également être automatisée.

On trouve ensuite les procédures de déploiement, le plus souvent configurables par unfichier XML décrivant la topologie du déploiement sur chacune des plates-formes.Parfois, certains logiciels de test vérifient quelques points techniques sur la plate-formepour en assurer le bon fonctionnement ou vérifier que certaines règles de sécurité sonttoujours correctement appliquées.

Si le projet est suffisamment important, il convient de s’assurer que ces procédures sontgérées de façon industrielle et automatisée. L’automatisation permet de réaliser desdéploiements rapides, sûrs et réplicables. On dispose ainsi d’une plate-forme de prépro-duction qui ne risque pas d’être déployée différemment de la plate-forme de production,que ce soit par inattention ou du fait de la complexité d’un déploiement manuel.

EN RÉSUMÉÉquipes offshore et déploiement des exécutables

L’organisation du déploiement des exécutables qui se trouvent dans le référentiel termine le travailde construction de la solution en offshore. L’équipe offshore peut préparer les scripts automatisantl’extraction, la compilation et le déploiement. C’est un des axes importants garantissant la stabilitéet la réplicabilité des déploiements.

Conclusion

L’intégration et le déploiement sont des disciplines fréquemment négligées. Lorsquec’est le cas, ils sont la source d’importants dysfonctionnements de l’accompagnement deslivrables chez le client et sur les plates-formes. Le plus souvent, le client se concentre sur lacréation du produit et néglige les tests. Il ne traite les procédures de déploiement que si desproblèmes surgissent et ne considère pas l’offshore pour l’exploitation de la plate-forme.

Le déploiement peut cependant être organisé avec la précision exigée par la taille duprojet. Les projets complexes, multitiers et visant une compatibilité avec plusieursfamilles technologiques, doivent être gérés avec beaucoup de soin. Même si les choix



289

technologiques peuvent avoir un impact majeur sur le développement (choix des techno-logies, structuration de l’architecture, organisation des tests, etc.), on peut mettre enplace la part de procédures qui convient à la nature du projet que l’on gère.

Lorsque ces procédures de gestion des intégrations et du déploiement ne sont pas appli-quées, les symptômes sont généralement les suivants : la plate-forme client se comportedifféremment de celle du prestataire, les corrections d’anomalies ne sont pas isolées, ona des difficultés à stabiliser les livraisons sur les plates-formes, qui prennent un tempsexagéré, etc. En réaction, on finit par mettre en place des procédures qui permettent d’enéviter les effets les plus graves.

Il est possible d’utiliser les ressources en offshore pour éviter ces désagréments etprendre en charge ces tâches administratives de gestion et de supervision des plates-formes. Elles offrent une grande flexibilité pour la réalisation de ces tâches difficiles àorganiser ainsi qu’un excellent niveau de service, tout en permettant de réaliser deséconomies substantielles.


291

Chapitre 15

Suivi de l’équipe offshore

Les chapitres précédents ont posé les bases des procédures qui permettent d’organiser leprocessus de développement et de rassembler les informations de suivi du projet. Leprésent chapitre aborde plus en détail le suivi de projet et propose plusieurs modèlesutilisables dans des projets en offshore.

Le suivi de l’équipe en offshore est évidemment un des facteurs clés de réussite desprojets distants. Nous l’avons déjà abordé au chapitre 11 en insistant sur l’importance dureporting. Nous traitons surtout ici des documents les plus importants qui facilitent cesuivi et le rendent efficace et sur la façon de les obtenir.

Rappels sur le suivi de projet

Comme expliqué précédemment dans l’ouvrage, trois grandes conditions doivent êtreréunies si l’on veut disposer d’un suivi efficace du projet confié en offshore :

• Travailler en mode régie. Dans le mode au forfait, la gestion du projet est entière-ment sous la responsabilité du prestataire, lequel n’a aucune raison de communiquerplus d’information que nécessaire sur l’avancement du projet. Il s’est engagé à effec-tuer des livraisons intermédiaires montrant l’avancement du projet, et ce sont les seulséléments dont le client dispose pour juger de sa progression. Si le projet va mal, leclient n’a pas les moyens d’agir pour corriger les dysfonctionnements ni mêmed’étudier plus en profondeur la gestion du projet.

• Mettre en place de procédures. La mise en place de procédures permet d’obtenir desinformations pertinentes sur la progression du projet et de construire des indicateursà la signification claire et partagée entre les intervenants du projet.

• Communiquer efficacement. On peut être tenté de placer un chef de projet du clienten offshore pour gérer l’équipe distante et assurer une meilleure communication. Nousavons vu que la personne qui arrive chez le prestataire assure bien sa mission dans lespremiers temps mais devient rapidement un écran à la communication.

Nous supposons dans la suite du chapitre que le projet est géré en mode régie, qu’ilemploie une méthode itérative et que les points essentiels de la méthodologie sont



292

raisonnablement implémentés pour permettre de communiquer les informations impor-tantes.

Rappelons que la méthodologie et le suivi des opérations doivent avant tout s’appuyersur une bonne organisation des équipes et des responsabilités et que l’objectif del’équipe est de fournir des livrables utilisateur et non pas uniquement des livrablespersonnels. Les procédures complètent alors efficacement la bonne organisation deséquipes.

Le suivi de projet n’est pas conçu pour diagnostiquer les causes du mal. Si des défautsmajeurs empoisonnent le projet, comme l’absence d’architecture sur un projet important,des tests mal adaptés ou des spécifications mal définies, le suivi est peu efficace, car onne parvient pas à s’entendre sur la signification des indicateurs qu’on met en place.Lorsque l’organisation de projet fait défaut, même une livraison n’est plus significative,les corrections des anomalies induisant une forte instabilité de la livraison dans son inté-gralité.

Le suivi des équipes ne peut vraiment fonctionner que si ces dernières sont elles-mêmesorganisées. Lorsqu’un projet est bien géré, il est beaucoup plus facile de mettre en placedes sondes objectives, dont la signification est entendue par tous de la même façon. Onpeut alors prendre de bonnes décisions, en tenant compte d’informations fiables.

Les mesures univoques

Lorsqu’on construit un reporting, il faut avant tout s’assurer que les mesures et les événe-ments que l’on observe ont la même signification pour tous. Certaines mesures neconviennent pas, sont ambiguës ou, pire, poussent à des comportements qui ne sont pasdans l’intérêt du projet.

Par exemple, sachant que le client observe certains indicateurs, le prestataire peut vouloiren favoriser la bonne tenue. Une erreur fréquente consiste à construire un indicateur pourmesurer la qualité d’une équipe de développement à tenir ses engagements de livraisondu code source. Cette livraison, certes importante dans un cycle de développement,devrait en fait passer au second plan pour laisser la primauté à la livraison recettée, ensortie de test, avec un niveau de qualité minimal ou, si l’on veut absolument un événe-ment plus proche des développements, la fin d’une recette unitaire vérifiée par l’équipede test.

Faute de cela, la livraison en sortie de développement sera peut-être réalisée dans lestemps, mais avec un niveau de qualité tellement variable que l’on ne pourra pas endéduire de façon certaine une date d’intégration. C’est pourtant cette date, à laquelle lecode est testé et déployable, qui intéresse avant tout le client.

Une autre mesure maladroite courante est illustrée par le taux d’avancement des modulesen cours de création. Cette estimation est proposée au jugé par les développeurs, alorsqu’ils ne sont pas certains eux-mêmes de la valeur qu’ils communiquent. On constateparfois que des taux d’avancement régressent, comme si le développeur défaisait ce qu’ilavait réalisé la veille. Des modifications des couches techniques nécessitent en fait deretravailler des couches fonctionnelles, et la prise en compte de ce travail mène à uneestimation plus défavorable du temps restant, ce qui explique la régression apparente.


Chapitre 15 – Suivi de l’équipe offshore

293

Certains indicateurs en apparence simples fournissent ainsi des valeurs souvent trom-peuses. En réalité, la plupart des mesures sont ambiguës et ne concordent pas avec cequ’elles sont censées représenter. La raison à cela est qu’elles sont entachées d’une partd’interprétation.

Les livrables, que l’on parle de programmes, de documents ou de formations, doivent êtrecorrectement définis pour qu’il n’y ait pas d’ambiguïté sur le niveau de qualité, qui esttoujours difficile à définir, ni sur le travail encore nécessaire pour en disposer dans un étatutilisable. La mesure elle-même, si elle est subjective, doit être définie clairement entreles participants. Par exemple, si l’on parle d’un niveau d’avancement du développementd’une fonctionnalité jusqu’à la livraison en production d’une fonction recettée, on peutdéfinir certains pourcentages clés, comme 10 % pour la fin de l’analyse et de design, 75 %pour la fin du développement (avec une recette unitaire réalisée par le développeur), etc.On peut ainsi définir des niveaux d’avancement pour chaque jalon correctement atteintselon l’avancement du codage et des tests d’une fonction.

Une autre erreur commune consiste à s’appuyer sur des mesures qui ne signifient pas lamême chose chez le client et chez le prestataire. La collecte des informations se fait assezfacilement chez le prestataire, car il comprend qu’elles sont réellement utiles au client.Par exemple, si un planning détaillé s’accompagne de mises à jour de la progression dechaque tâche et que certaines tâches montrent un retard significatif, le chef de projet duclient qui suit la progression de ces tâches blâme l’équipe en retard. Pourtant, cettedernière n’a fait que respecter les nouvelles directives du client en corrigeant une fonc-tionnalité de toute urgence. Si le chef de projet du client accuse à tort l’équipe distante,alors qu’elle a peut-être remarquablement travaillé, c’est qu’il suit un indicateur qui n’estplus significatif du travail de cette équipe.

Certains managers du client peuvent avoir tendance à piloter le projet uniquement àtravers certains indicateurs, alors que ceux-ci ne rendent compte que d’une partie infimede la situation en offshore. Lorsqu’un de ces managers demande à l’équipe en offshored’expliquer ses dysfonctionnements, il apparaît, comme dans l’exemple précédent,qu’une grande partie de ceux-ci se trouvent injustement exagérés par les moyens demesure et ne rendent pas compte d’autres problèmes ou directives tout aussi importants.Le manager ne peut dès lors que perdre rapidement du crédit aux yeux de l’équipedistante du fait de son mode de suivi très éloigné de la réalité.

Un suivi serré du planning peut faire apparaître que l’équipe en offshore n’a pas respectéses engagements de livraison, mais aucun indicateur n’expliquera facilement les raisonsqui ont mené à cette situation. Il se peut que des changements importants aient entraînédes retards ou bien que le planning, s’il n’a pas été géré par itération et qu’il date d’unepériode déjà ancienne, soit très éloigné de l’ordonnancement et de l’estimation réels destâches. Les reproches que l’on adresse alors sont injustifiés et démontrent l’incapacité duclient à suivre le projet.

De très nombreux exemples de ce type démontrent que l’on ne peut suivre un projet surla base de quelques indicateurs. La réalité ne peut être réellement perçue qu’en prenanten compte toutes les informations et en utilisant les bons indicateurs pour suivre aumieux les situations. Bien souvent, certains aspects de la gestion de projet ne peuventêtre facilement mesurés et rapportés par des sondes. Le déplacement sur place esttoujours nécessaire pour se rendre compte de la situation réelle.



294

Selon la phase du projet et les problèmes rencontrés en offshore, les indicateurs les plusimportants pour comprendre la situation ne sont pas forcément les mêmes. On seconcentre parfois sur les performances humaines et l’organisation des équipes, tandisqu’à d’autres moments ce sont les procédures qui sont au cœur de l’attention et que plustard on s’attachera à la qualité de la production.

Pour chaque préoccupation, le client choisit les indicateurs qui l’aident à mieuxcomprendre la situation et son évolution. Si ces indicateurs ont été peu utilisés, il faut lesajuster afin de s’assurer qu’ils ont la même signification pour ceux qui mesurent et ceuxqui sont mesurés.

Le client ne doit pas hésiter à ajouter certains indicateurs pour mieux suivre le détaild’une situation délicate, quitte à les abandonner une fois la situation résolue. Il ne doitpas non plus hésiter à remettre en question certains indicateurs trompeurs pour lesremplacer par des indicateurs univoques.

EN RÉSUMÉLes indicateurs et leur réalité

Les indicateurs font facilement apparaître des problèmes qui n’existent pas vraiment et ne détectentpas toujours des problèmes réels, pourtant connus de tous. Ils doivent donc être confrontés à laréalité pour s’assurer de l’information que l’on en tire. Il faut également s’assurer que les problèmescourants constatés sur le terrain sont identifiés.

Les indicateurs de suivi donnent toujours une vue partielle de la réalité et ne peuvent à ce titre êtreutilisés comme seule source d’information pour suivre efficacement un projet. Les mesures doiventavoir la même signification chez le prestataire et chez le client et être ajustées régulièrement.

Les visites au prestataire

Les déplacements réguliers chez le prestataire ne peuvent être évités si l’on veut suivreprécisément les prestations de l’équipe en offshore. Aussi sophistiqués soient-ils, lesindicateurs et mesures que l’on met en place ne sauraient rendre compte de toutes lessituations. Certains processus peuvent être finement et efficacement suivis par une séried’indicateurs, tandis que des paramètres tels que la motivation des équipes ou une pertede productivité sont pratiquement impossibles à rapporter. Des indicateurs peuvent êtreconsidérés comme les effets d’une démotivation sans pour autant permettre de détecterles causes des dysfonctionnements.

Pour mesurer pleinement ces sujets généralement complexes, il faut se rendre régulière-ment chez le prestataire en offshore. Comme expliqué précédemment, les visites chez leprestataire doivent être ouvertes afin de construire et maintenir un esprit collaboratif. Ilest beaucoup plus facile de détecter les dysfonctionnements les plus importants avecl’aide du management du prestataire plutôt qu’en essayant de les repérer s’il cherche àles dissimuler.

Une fois les problèmes repérés, on peut prendre les mesures qui conviennent et mettreen place, lorsque c’est possible, certains indicateurs spécifiques afin de suivre l’améliora-tion du dysfonctionnement de façon systématique, sur la base de sources d’informationexistantes ou créées spécialement pour suivre ce sujet.



295

Lors des voyages chez le prestataire, on retrouve presque toujours les mêmes sujets à traiter :

• Communication sur le projet tel qu’il est perçu par le client, avec présentation des insa-tisfactions les plus importantes et, éventuellement, félicitations pour les réussites.

• Analyse de chaque sujet difficile avec les intéressés et mise en place des actionscorrectives et des indicateurs de suivi lorsque c’est possible. Présentation de l’analysequi est faite des indicateurs sur les sujets délicats et prise en compte des commen-taires sur leur usage.

• Formations complémentaires ou explications détaillées de ce que l’on attend des équipes .

• Vérification avec les personnes concernées du respect des procédures en place etamélioration de ces procédures.

Ces entretiens peuvent être personnels ou s’élargir à des groupes de personnes. Il estfortement recommandé d’organiser les réunions avec toutes les personnes concernées etde ne pas se limiter aux supérieurs hiérarchiques.

Les documents de suivi

Le suivi de projet s’appuie sur plusieurs sources d’information. Plus le processus de déve-loppement est industrialisé, plus il est facile d’obtenir des mesures objectives et d’enautomatiser la collecte. On peut s’appuyer sur les sources décrites au tableau 15.1 (lessources notées en gras correspondent aux sources principales).

Tableau 15.1. Sources des documents de suivi

Source Type d’information Utilisation

Planning d’itération – Suivi de la progression dans l’itération– Travail de chaque collaborateur– Lourdeur des replanifications– Capacité à anticiper

– Suivi estimatif en cours d’itération– Validation en fin d’itération pour en tirer des informations fiables

Planning de version/projet Marquage de l’avancement du projet

– Replanification du contenu des itérations futures pour atteindre les objectifs de livrai-son du projet– Anticipation des retards

Plan de développement et planning de charge des itérations

Anticipation des charges de travail par itération

Planification des ressources humaines de chaque itération (compétences et quantité)

Objectifs d’itération/résultat des itérations

Contenu de tous les livrables de l’itération en cours ou de l’itéra-tion suivante

– Connaissance précise du contenu des réalisations à court terme et des objectifs de chacun– Essentiellement utile au jugement des réali-sations personnelles



296


Organigramme Organisation hiérarchique et des responsabilités des collaborateurs

Distribution des quantités de travail dispo-nibles, des flux d’information entre les personnes, des changements d’équipe, etc.

Référentiel Mouvements sur les documents et artefacts

– Métriques sur les mises à jour des documents de spécification (stabilité)– Évolution des codes source avec métriques précises– Dates exactes de remise

Gestion de changement Informations sur les anomalies, les changements et les work-flows

– Métriques précises des anomalies et de leurs changements d’état (volumes, temps passé dans certains états, temps de résolution)– Responsables des blocages dans les workflows– Métriques des évolutions et des changements– Anticipation des dates de correction, comparaison entre estimé et réalisé, renseignement du « reste à faire »

Gestion des besoins Informations sur les besoins exprimés

Métriques des changements des besoins exprimés et des dates anticipées et consta-tées de réalisation

Gestion des tests, résultats des tests

Ensemble des scénarios de test – Couverture fonctionnelle des tests– Résultats des tests (exécution/non-exécu-tion/erreurs)– Tests automatisés et leur couverture– État de qualité des builds– Estimation des risques à livrer le produit

Gestion des tests techniques

Tests techniques utilisant les environnements appropriés à formaliser

– Comportement technique du produit– Estimation de la charge technique accep-table sur le développement (volumes)

Autres tests et infor-mations techniques

Informations techniques relatives à des sujets clairement définis

– Tests de couverture des tests– Tests spécifiques sur des sujets précis (haute disponibilité)

Présence et autres indi-cateurs physiques en offshore

Comportement des collabora-teurs en offshore

Temps de présence des collaborateurs (entrées-sorties)

Gestion des temps et des activités

Rapport des temps passés par collaborateur

Métriques des coûts de développement et de la répartition des types de tâches (développement, tests, management, analyse, etc.)

Tableau 15.1. Sources des documents de suivi(suite)



297

Cette liste de sources d’indicateurs n’est pas exhaustive. De nombreux autres indicateurspeuvent se révéler utiles pour saisir les spécificités de chaque projet.

Dans tous les cas, les informations fournies par les documents de suivi doivent êtreconfrontées à la réalité afin d’en juger l’efficacité. Les réunions avec les managers et leséquipes qui ne fournissent pas la productivité attendue sont toujours nécessaires pourobtenir un avis objectif de la situation chez le prestataire.

Les sections suivantes approfondissent les documents de suivi les plus importants.L’objectif n’est pas d’exposer une méthodologie à appliquer mais de présenter les documentsles plus importants qui permettent de juger assez efficacement du travail en offshore etde sa progression.

Définition des objectifsLe document de vision permet de définir un objectif commun à toutes les équipes, afinque tous travaillent dans le même but. C’est cet objectif qui donne le sentiment d’appar-tenance à un projet, à une aventure.

L’objectif définit le contenu du projet à réaliser pour une date donnée, avec des exigencesde qualité et de stabilité. Il prévoit une évolution du contenu du projet afin de l’adapteren cours de réalisation aux contraintes fonctionnelles et techniques.


Indicateurs informatiques internes

Activité sur le réseau local – Usages divers sur l’activité des utilisateurs du réseau local et d’Internet– Métriques de saturation des machines et de la bande passante de communication

Évaluations périodiques Entretiens individuels périodi-ques des collaborateurs

Retour sur la motivation des équipes et sur les insatisfactions des collaborateurs

Liste des risques Suivi des risques identifiés Suivi des risques identifiés sur le projet et des actions correctives ou limitatives de ces risques

Suivi des décisions Document de suivi des décisions (en dehors des autres processus)

Suivi des décisions diverses n’entrant pas dans les autres documents de suivi, temps de réalisation, etc.

Factures du prestataire Informations sur la facturation – Coûts des prestations– Quantité de travail facturée avec détails de chaque collaborateur– Surcoûts inattendus

Mesure de l’économie de l’offshore

Comparaison des coûts consta-tés en offshore avec les coûts estimés chez le client

– Mesure de l’économie– Prise en compte des éléments d’inefficacité

Tableau 15.1. Sources des documents de suivi(suite)



298

La vision est exprimée par écrit afin d’être stable dans le temps, malgré les crises et lestensions. Faute de cela, elle pourrait évoluer en même temps que le projet, et les partici-pants au projet ne pourraient plus s’identifier à elle. Elle perdrait alors sa capacité àmotiver et rassembler les collaborateurs.

Le document de vision sert à définir le spectre fonctionnel du produit, les technologiesemployées, les utilisateurs, etc. Il sert de socle pour concevoir le plan des itérations afinde répartir grossièrement les livrables de chaque itération, définissant ainsi le plan deprogression du projet pour livrer en temps et en heure.

L’itérationLe plan de développement qui répartit le projet en itérations provient de plusieurs sources :

• Le résultat des itérations précédentes.

• L’avis des participants au projet sur ce qui peut être réalisé et sur les dépendancesentre les réalisations.

• Le document de vision, qui fixe l’objectif final.

• Le plan d’affectation des ressources disponibles pour les itérations.

L’iteration assessment permet de juger de la progression réelle du projet à partir d’un pointde livraison régulier. Il permet de planifier l’itération suivante et de prendre en compte, sinécessaire, une replanification des itérations futures ou du plan de charge (personnel àaffecter). C’est l’un des documents les plus importants de la gestion de projet, d’où l’ontire les conclusions les plus déterminantes. Toutes les conclusions s’appuient sur deslivrables recettables, et donc sur une progression formelle et vérifiable.

On en dégage des informations sur le travail réalisé par chacune des équipes, permettantde juger de la productivité de chacun. On peut construire des métriques sur la fi abilitéde chaque équipe à livrer dans les temps, permettant de jauger sereinement la charge detravail à réaliser. On peut aussi juger de l’impact des éléments extérieurs qui sont venusperturber le déroulement de l’itération, que l’on parle de la réalisation de risques, deblocages dus à des failles dans les procédures ou des effets des changements de prioritésou des modifications du produit.

Il peut être bon de construire des métriques sur ces éléments extérieurs et de les présen-ter aux personnes intéressées, notamment si certains retards sont dus à l’absence deréactivité du client, un cas très courant. On peut ainsi démontrer objectivement les effetsde certains changements de spécifications ou d’absence de décisions sur le processus dedéveloppement.

Par exemple, si un chef de produit ne répond pas aux questions des développeurs ou sides changements trop fréquents sont apportés aux spécifications, on peut en mesurerl’impact sur le développement et en étudier l’évolution dans le temps. Cette informationpeut être en partie croisée avec les modifications apportées aux cas d’utilisation et auxexigences qui sont conservées dans le référentiel.

Les documents liés aux itérations permettent de suivre globalement l’avancement duprojet et de communiquer aux intéressés les mises à jour des dates clés.



299

EN RÉSUMÉGestion par itérationLa gestion par itération permet de suivre périodiquement la progression d’un projet en constatant ladisponibilité des livrables et en évaluant leur niveau de qualité. Elle donne le pouls du projet etconfronte la capacité des équipes au réalisme des plannings.

Les planningsLes plannings sont, comme souvent, l’un des documents de base du suivi de projet.

Le planning de projet est mis à jour régulièrement en fonction du résultat des itérationsafin de prendre en compte l’expérience acquise. Il est directement lié au planning decharge, qui définit les ressources que l’on compte allouer à chaque itération à venir. Cesdeux documents, mis à jour lors des résultats des itérations terminées, permettent dedéterminer la façon de tenir l’objectif commun (ajouter du personnel si c’est possible etque cela ait un impact positif, retirer des fonctionnalités au produit pour le faire tenir dansle temps disponible et les reporter sur une version ultérieure, accepter de retarder la datede livraison, etc.).Ces plannings très généraux permettent de mesurer la progression globale du projet. Cesont des documents directement utilisables par les managers et les utilisateurs qui nesouhaitent pas s’encombrer de détails qu’ils pourraient ne pas comprendre.Le planning de l’itération est un document précis, qui détaille toutes les tâches de l’itéra-tion. Il permet de détecter régulièrement les problèmes rencontrés et de juger de laperformance des individus travaillant sur le projet. Il est utilisé pour comprendre l’impactréel des événements extérieurs à l’équipe en offshore qui peuvent justifier les retards delivraison ou l’impossibilité d’atteindre les objectifs de l’itération. Ces plannings, le plussouvent suivis chaque semaine, permettent de descendre à un niveau de détail très fin etd’attribuer les responsabilités des manquements aux personnes qui les ont effectivementcommis.Parmi les causes les plus communes de retard, on trouve les dépendances entre leséquipes, notamment dans les premières phases du projet. On peut ainsi démontrerl’impact des retards d’une équipe sur les autres équipes et aider toutes les équipes àmieux planifier leurs livrables afin que ces retards en cascade soient moins fréquents.L’utilisation de la méthode itérative retire beaucoup d’intérêt aux plannings, qui ne sontplus utiles que pour gérer et comprendre le contenu d’une itération. La vision globaledu projet est donnée par le plan de développement et le plan de charge, lesquels ontl’itération pour granularité.

EN RÉSUMÉGestion des plannings par itérationEn gérant des plannings avec l’itération comme unité de temps, on peut ajuster efficacement leshypothèses de charge et de priorité à partir des retours d’expérience des itérations. Seuls les plan-nings de l’itération en cours et de la suivante sont suffisamment précis pour identifier sans ambiguïtéles causes des dysfonctionnements constatés en fin d’itération.

La qualitéLa qualité se mesure aux anomalies détectées dans le produit, à la stabilité des spécifi-cations et des exigences, au respect des contraintes techniques (temps de réponse, sécurité ,technologies) et au respect de la documentation et des procédures en place.



300

C’est une mesure qui vient compléter les informations sur l’avancement du projet en teintantles livrables courants du niveau de finition que l’on constate.

Gestion des anomalies

La qualité du produit se mesure tout d’abord à l’aide de l’outil de gestion du changement(anomalies et demandes d’évolution des spécifications). C’est un outil complexe, quipeut fournir énormément d’informations selon les besoins rencontrés.

On en tire en premier lieu des informations statiques sur le nombre d’anomalies par fonc-tionnalité ou par niveau de gravité et leur évolution dans le temps. C’est une mesure assezjuste de l’état connu de l’instabilité d’un module et de son évolution vers un état stable.

On peut aussi vérifier le bon fonctionnement du flux de traitement des anomalies (depuisla détection jusqu’à la correction) en vue de repérer les points de blocage. On peut ainsimesurer par période de temps, par décisionnaire et par module le temps pendant lequelune anomalie reste en attente de traitement. On peut aussi repérer où agir pour accélérerle traitement de ces anomalies. On a trop tendance à accuser les équipes de développe-ment alors que l’essentiel du temps s’écoule dans l’attente de la qualification del’anomalie et de l’attribution de son niveau de gravité.

La gestion des anomalies permet de vérifier que les dates promises de correction sontrespectées (passage de l’anomalie à corriger à l’état corrigé et à tester), ce qui est facile àréaliser lorsqu’on utilise un outil de gestion du changement.

Bien souvent, les anomalies sont gérées à partir de données accessibles au moyen de diversoutils, comme Access ou Excel, pour construire la vue que l’on souhaite (historiques,tableaux croisés ou multidimensionnels, etc.) et qui convient à l’analyse que l’on veut faire.

Gestion du changement

La gestion du changement peut être mesurée à partir de plusieurs sources :

• L’outil de suivi de gestion du changement, pour mesurer les demandes d’évolutionsfonctionnelles.

• Le référentiel, qui prend en compte les modifications des documents de spécifications.

• La gestion des exigences.

Bien évidemment, les modifications fonctionnelles tardives sur des fonctionnalités déve-loppées et livrées sont plus coûteuses que les modifications réalisées avant que lesdéveloppements ne commencent. Pour mesurer l’impact d’une demande de modificationfonctionnelle, il faut la pondérer par l’état de la fonction modifiée.

On doit s’intéresser en particulier aux changements qui perturbent le développement(gravité, impact sur le développement). L’outil de gestion du changement alloue le plussouvent une charge de travail à chaque demande de changement qui permet d’en mesurerl’ampleur. C’est sans doute l’outil le plus important pour mesurer l’impact sur la qualité.

On peut utiliser ces formulaires de gestion du changement pour suivre d’autres informa-tions, comme l’origine de la demande de changement, et envisager comment on aurait pul’anticiper, afin d’éviter de répéter les mêmes erreurs dans la mesure du possible.

La quantité des modifications peut être un indicateur de qualité à même de faire appa-raître une mauvaise conception du produit ou des erreurs fonctionnelles. Les donnéesdes outils de gestion du changement sont généralement gérées dans une base de



301

données, qui, comme pour la gestion des anomalies, peut être exploitée par des applicationstelles que Access ou Excel pour construire le reporting souhaité.

L’Acceptance Sheet

L’Acceptance Sheet, ou feuille d’acceptation, présente l’état de la qualité du produit telqu’il est vu par l’équipe de test. Elle rassemble des informations sur toutes les anomalieset demandes de changement connues sur le produit ainsi que le dernier résultat connudes tests de chaque fonctionnalité.

Si l’on présente les résultats d’une campagne de tests sur une colonne, on peut suivrel’évolution de la qualité en comparant les colonnes.

Une fonctionnalité testée positivement il y a longtemps peut être considérée commeprobablement correcte, tout en sachant que plus le dernier test est ancien sur un code quin’a théoriquement pas changé, moins on est certain de l’état de qualité réel de la fonc-tionnalité.

Cette feuille, décrite au chapitre 13, présente de façon partagée la vision de l’équipe detest sur la qualité d’un produit, telle qu’elle leur apparaît compte tenu du temps limitédont elle dispose pour assurer la complétude des tests.

Le Minimal Acceptance Sheet

Ce document permet de disposer d’une vision rapide et réduite de l’Acceptance Sheet.Les tests sont limités mais utilisent tous les modules de l’application. Les régressions nesont pas toutes détectées, loin de là, mais les régressions majeures, comme celles quirésulteraient d’un module manquant, le sont.

On essaie généralement d’automatiser les tests des Minimal Acceptance Sheets afin devalider rapidement la livraison d’une correction urgente devant être déployée aussitôt quepossible.

La qualité technique

Les performances peuvent être mesurées régulièrement au cours des tests automatisés.On peut alimenter une base de données avec les résultats de ces tests (souvent une feuilleExcel), d’où l’on peut construire les rapports sur les performances et leur évolution dansle temps. Cette information peut être rapportée dans l’Acceptance Sheet, avec les résul-tats des tests fonctionnels. On peut ainsi surveiller dans le temps que les contraintes deperformance client sont respectées.

Longs et coûteux, les tests de charge ne sont pas suivis régulièrement au cours du projet.Il s’agit le plus souvent d’une campagne de tests réclamant beaucoup de ressources etdevant être effectuée dans un environnement étroitement surveillé pour que les conclusionssoient significatives.

Bien que complexes, les tests de profiling (analyse du comportement de chaque compo-sant de l’application) permettent d’optimiser les charges de chaque serveur des architec-tures multitiers. La collecte des informations est délicate, car il faut éviter de perturber lesmesures avec des événements annexes. Les outils de profiling produisent rapidement unvolume important d’informations difficiles à analyser. C’est une tâche longue qui ne doitêtre réalisée qu’en cas de nécessité, par exemple pour les tests de charge.



302

Respect des procédures

Des audits réguliers peuvent être pratiqués pour s’assurer de l’adhésion aux procédureset normes en vigueur. Selon le projet, on se concentre sur les éléments les plus impor-tants (sécurité, rapidité de développement, documentation, etc.). D’une manière générale,on trouve en priorité les audits suivants :

• Bonne tenue des spécifications. Vérification que toutes les décisions prises sur lesaspects fonctionnels sont reportées immédiatement dans les documents de spécifica-tions (cas d’utilisation) et, si nécessaire, dans l’architecture du produit. C’est un pointimportant, qui permet de s’assurer que les tests effectués correspondent aux inten-tions de développement.

• Respect des règles de codage. Vérification des règles de codage, souvent en utilisantdes outils permettant de repérer la plupart des dérogations aux règles, notammentl’utilisation de fonctions interdites ou des règles de nommage non respectées.

D’autres procédures peuvent prendre une importance plus marquée selon les spécificitésdu projet, comme les tests unitaires, la prise en compte des tests, les règles d’écrituredes cas d’utilisation, le respect des interfaces avec des produits ou des équipesextérieurs, etc.

La liste des risques

La liste des risques permet d’anticiper les risques susceptibles d’avoir un impact sur leprojet. Construite de façon collaborative, cette liste peut aussi donner une vision de laperception de certaines personnes ou équipes. Certains risques proposés sont réelset indiscutables, tandis que d’autres démontrent une crainte plus qu’une réalité etpermettent de mieux comprendre le fonctionnement de l’équipe en offshore.

EN RÉSUMÉLes indicateurs de qualité

La qualité est suivie par un ensemble d’indicateurs. Les indicateurs principaux concernent lesexécutables. Le suivi des anomalies et des demandes d’évolution peut être synthétisé dans undocument nommé Acceptance Sheet, qui donne une vision globale de la qualité par fonctionnalité.

D’autres indicateurs permettent de suivre la qualité technique des réalisations en offshore, ainsi quel’adhérence aux procédures et la gestion des risques.

Le rapport d’activité

Le document de gestion des activités ne donne pas d’information sur la progression duprojet mais permet de comprendre sur quoi les équipes ont passé du temps (par fonction-nalité et par activité). C’est un reporting essentiellement manuel, par lequel les collabo-rateurs rapportent périodiquement le détail de leur activité selon un formulaire et desrègles définis par le client. Ces informations sont parfois croisées avec les autres sourcesd’information afin d’en assurer la cohérence.

Certaines règles de constitution sont déterminantes, car elles définissent la façon dont onva pouvoir utiliser le rapport.



303

La périodicité permet de rendre compte d’une façon plus ou moins fidèle de ce qui s’esteffectivement produit. Un rapport mensuel a tendance à trop faire travailler la mémoire,tandis qu’un rapport quotidien masque les tâches courtes à la journée mais représenteune quantité de travail significative sur une semaine. Le rapport hebdomadaire constitueun bon compromis.

Pour décider efficacement du temps travaillé que l’on rapporte, il importe de répondre àun certain nombre de questions. Se limite-t-on aux heures prévues dans le contrat, quiseront effectivement facturées, ou comptabilise-t-on les heures supplémentaires nonfacturées ? Les heures supplémentaires facturées sont évidemment prises en compte,mais les heures additionnelles, durant lesquelles les collaborateurs ont travaillé de leurpropre initiative, doivent-elles être comptabilisées ? Si l’on choisit de les comptabiliser,on s’expose à des requêtes du prestataire, lequel peut vouloir, après coup, facturer cetemps passé. Il se peut aussi que certains employés en fassent état pour demander desajustements de leur salaire.

La granularité temporelle des tâches a un impact important sur la lecture des rapportsd’activité. Une granularité d’une heure offre une grande finesse pour des tâches relative-ment courtes, surtout rapportées à la semaine. Les granularités supérieures tendent àcacher les tâches de courte durée, qui, cumulativement, peuvent être importantes.

La nature des activités mesurées est aussi très importante. Il est conseillé d’identifier lestâches correspondant à la stabilisation des livrables (corrections, évolutions mineures,optimisations) et de les séparer des tâches relatives à de nouveaux développements. Onpeut de la sorte mesurer la nature des efforts.

Ce rapport peut être utilisé comme source d’information pour l’amortissement des fraisde recherche et développement lorsqu’on travaille sur les règles de comptabilité améri-caines, qui sont employées par la plupart des sociétés d’envergure multinationa le. Ondoit alors amortir toutes les dépenses de R&D qui surviennent après les spécifications etles études de faisabilité. On détermine ensuite, selon les activités, celles qui se situentavant et après ces activités seuil. Si l’on utilise d’autres règles, on peut faire en sorte queles rapports d’activité identifient clairement les tâches amortissables et celles qui ne lesont pas.

EN RÉSUMÉLe rapport d’activité

Le rapport d’activité permet de construire des analyses précises du fonctionnement de l’équipeoffshore. Le chef de projet peut calculer précisément le coût de certaines activités, ainsi que laproductivité des collaborateurs et la rentabilité des fonctionnalités développées.

Le rapport d’activité permet de noter la nature de chaque tâche réalisée afin d’amortir les charges derecherche et développement des tâches amortissables, si on le souhaite.

Les documents organisationnels

Les documents organisationnels concernent essentiellement la structure des équipes etles procédures en place, notamment le suivi des décisions qui concernent des sujets orga-nisationnels.



304

L’organigramme définit en permanence les dépendances hiérarchiques, l’appartenancede collaborateurs aux équipes en place et la description des postes existants et à pourvoir(avec la date prévue d’arrivée des collaborateurs).

Lorsqu’on travaille avec des équipes en offshore, on a moins l’occasion de rencontrer lescollaborateurs, et l’on peut oublier qui ils sont et les confondre. Comme les collabora-teurs du client ont moins l’habitude des noms étrangers, la mémorisation est moins aiséeet la confusion fréquente. Il est bon de prévoir un organigramme contenant les photos dechaque collaborateur, afin de se remémorer sans ambiguïté qui est qui.

C’est un document de suivi indispensable pour gérer et suivre les embauches et les rema-niements multiples qui surviennent en cours de projet.

La méthodologie doit être aussi bien documentée que possible si l’on veut que tous lescollaborateurs l’appliquent sans confusion. La méthodologie en elle-même ne fournit pasdirectement d’indicateur permettant de déterminer dans quelle mesure elle est bienappliquée. Le respect de la méthodologie provient essentiellement d’audits ciblés sur desdomaines particuliers.

Le document de suivi des décisions concerne généralement des sujets en marge du cyclede développement. On y trouve certaines décisions qui relèvent des engagementscontractuels, comme la mise à disposition de salles climatisées. C’est un des seuls docu-ments qui permette de suivre et de mesurer l’empressement du prestataire à appliquerles clauses du contrat. À ce titre, c’est un excellent indicateur de la mesure de l’attitudedu prestataire.

Les documents administratifs

Les documents administratifs concernent plusieurs types d’informations :

• la facturation, avec tous les éléments permettant de construire la facture ;

• les informations sur l’accès aux locaux ;

• les informations sur les vacances, maladies et autres absences.

La facture est bien sûr un document très important, qu’il convient de vérifier attenti-vement. Elle se vérifie essentiellement à partir du contrat (pour appliquer les tarifsqui conviennent à chaque personne), des documents indiquant la présence de chaquecollaborateur durant la période étudiée et d’autres éléments facturés (matériels, abonne-ments, services, etc.).

Les documents administratifs doivent permettre de construire un tableau des congés etabsences que l’on confronte à la facturation. Si le doute s’installe sur certaines personnes,on peut employer le référentiel (si l’on a un compte par utilisateur) ou la messagerie pourconstater l’activité du collaborateur pendant les journées en question. On peut aussiétudier les rapports d’accès aux locaux provenant des dispositifs de contrôle d’accès.

Si le prestataire est équipé d’un dispositif de contrôle d’accès personnalisé, notammentavec des cartes d’accès, on dispose de toutes les informations sur les entrées-sortiespermettant de contrôler le temps passé dans les locaux (mais pas nécessairement letemps passé à travailler). C’est parfois un indicateur intéressant dans les périodes de



305

démotivation des équipes ou après des événements difficiles, comme la réduction brutaledes effectifs d’une équipe.

EN RÉSUMÉLes documents administratifs

Les opérations chez le prestataire offshore sont cadrées par des documents administratifs quipermettent de vérifier les éléments intervenant dans la facturation, de définir les règles de fonction-nement administratif et de suivre la gestion des ressources humaines, notamment les vacances etles absences. Ces documents permettent de repérer les événements qui méritent une attentionsoutenue.

Mesure des économies

On peut mesurer les économies réalisées grâce à l’offshore ou, si la gestion de l’offshoreest désastreuse, leur surcoût. Un document rassemble les calculs de rentabilité desopérations en offshore. Les hypothèses servant aux calculs visent à ne jamais exagérer laprofitabilité pour éviter les critiques accusant d’exagérer le retour sur investissement.

Ce document permet non seulement de montrer l’économie réalisée et la rentabilité desopérations mais également les surcoûts que génèrent certains manques de réactivité.

On peut se servir de ce document pour chiffrer les surcoûts apportés par les changementsdes spécifications, lesquels peuvent indiquer qu’une réflexion plus approfondie avant lesdéveloppements pourrait apporter une économie significative.

Un exemple de tableau de calcul de ces économies est donné en annexe. L’expériencemontre qu’un tel tableau se complexifie rapidement si l’on souhaite obtenir des mesuresplus précises sur des sujets qui intéressent directement le management. Par exemple, onpeut essayer de mesurer des activités de correction d’anomalie, de typer les services pouren extraire certaines tâches réputées non productives, comme l’informatique interne, oubien se concentrer sur certaines activités, comme la supervision de plate-forme.

EN RÉSUMÉDocument de mesure de la rentabilité

Un document mesurant la rentabilité des réalisations en offshore permet d’estimer les économieset de mesurer leur évolution. Ce document permet aussi de communiquer efficacement sur ce sujet etd’éviter les rumeurs.

Automatisation des documents

Il est recommandé autant que possible de créer l’essentiel des documents de suivi defaçon automatisée. Nous avons décrit dans le cours de l’ouvrage la plupart des sourcesobjectives d’information disponibles. Certaines sources sont alimentées par l’utilisationdes outils de développement (référentiel, gestion du changement), tandis que d’autressont nourries par des comptes-rendus manuels (activités, progression dans le planning



306

d’itération, iteration assessment) de façon périodique. On trouve également des informationssur la progression du planning saisies périodiquement par les équipes en offshore.

Toutes ces données se trouvent dans des sources séparées. Il est recommandé deconstruire un tableau de bord permettant de rassembler l’accès à toutes ces informationset de construire automatiquement les rapports les plus usités. Certains outils de gestionde projet permettent de construire de tels tableaux de bord. Il est aussi possible de lesconstruire dans Excel ou Access, selon la nature des données que l’on doit traiter.

Il est important de disposer d’un point d’accès unique à toutes les informations. Les infor-mations les plus couramment utilisées sont présentées sous une forme pratique, corres-pondant à une utilisation confortable. Les autres informations, que l’on utilise moinssouvent, peuvent être accessibles dans une présentation plus brute.

Lorsque les données sont situées dans une base de données (gestion du changement,suivi des temps, etc.), on peut construire une base d’analyse. Cette base doit être conçuepour être exploitée par une application de type Access ou Excel afin de construire lestableaux recherchés et fournir des présentations graphiques ou des alertes. On disposeainsi d’un tableau de bord synthétique, qui met en avant les points à surveiller.

EN RÉSUMÉMesures automatiques

Dans la mesure du possible, il est préférable de construire les documents de suivi sur la base desoutils opérationnels du projet qui fournissent des indicateurs d’une valeur indiscutée (plannings,gestion des anomalies et des demandes d’évolution, gestion de la configuration). Ces mesures auto-matiques sont agrégées avec des mesures dont la source requiert une intervention humaine (gestiondes activités, progression du planning, comptes-rendus d’itération, etc.)

Afin de garantir un reporting complet en temps réel, les tableaux de bord sont construits de façonautomatisée afin de pouvoir disposer de la vue souhaitée et de définir les déclencheurs d’alerte quipermettent de prendre les décisions au plus tôt.

La sécurité

Certaines procédures ou règles, qui sont indépendantes de la gestion de projet, peuventen ralentir la progression. Le client presse l’équipe distante à rattraper le retard qu’elleaura presque toujours accumulé et valorise avant tout la rapidité de développement. Biensouvent, les procédures relatives à la sécurité sont oubliées, tant par l’équipe distanteque par le client, au profit d’une recherche de productivité à tout prix.

Selon l’importance qu’on accorde à la sécurité et au respect de ses règles, il convientde mettre en place les indicateurs adéquats, lorsque c’est possible, pour en vérifierl’application. C’est d’autant plus important lorsque le client presse le prestataired’accroître toujours plus la productivité et semble se désintéresser de ces règles, alorsqu’il les considère par ailleurs comme essentielles.

Par exemple, si un accord de confidentialité doit être signé par chaque collaborateur, onpeut construire un indicateur signalant le pourcentage d’accords signés par rapport aunombre de collaborateurs, cet indicateur devant être à 100 lorsque la procédure estrespectée. Si l’on souhaite que le réseau soit isolé du réseau local du prestataire, on



307

demande à la personne responsable d’exécuter certaines procédures de scan de ports, delancement de listeners, etc.

Périodiquement, un audit par échantillonnage peut être effectué pour s’assurer du respectdes règles et de la validité des indicateurs.

EN RÉSUMÉIndicateurs de respect des règles de sécurité

La sécurité fait souvent l’objet d’une attention exagérée au commencement des projets offshorepour être ignorée une fois que le projet a démarré. Il convient de mettre en place des indicateurs debonne application des règles de sécurité permettant d’en assurer le suivi tout au long du projet.

Conclusion

Le suivi de projet dépend grandement de la nature du projet sur lequel on travaille. Bienentendu, les phases de mise en place d’une équipe nécessitent de se déplacer plussouvent chez le prestataire afin de vérifier de visu la mise en place des équipes et des procé-dures.

Lorsque le projet est en phase d’analyse et de codage, on se concentre sur les indicateursde progression et de suivi du projet, puis on les améliore à chaque itération afin qu’ilssoient toujours plus représentatifs. Le client se concentre pour sa part sur les sujets fonc-tionnant moins bien ou sur les disciplines qui émergent en fonction de l’avancement duprojet, comme le déploiement.

Vers la fin du projet, on se préoccupe surtout de la stabilisation du projet et de la visionde son état de qualité.

Dans tous les cas, les visites sur place permettent de se rendre compte de la validité desindicateurs et de la situation réelle chez le prestataire. Lorsqu’une différence trop impor-tante est constatée entre la perception par les indicateurs et la situation chez le prestataire ,on cherche à améliorer les indicateurs afin de réduire cette distance.

Il est possible de construire les indicateurs au fur et à mesure de l’utilisation que l’onsouhaite en faire. Au commencement, on ne mesure que les processus de base, puis on yajoute des indicateurs plus fins, spécifiques des problèmes rencontrés ou anticipés.

Le suivi de projet est une discipline complexe. On se focalise trop souvent sur certainsindicateurs, qui prennent une importance prédominante, masquant la réalité de laprogression du projet pour en grossir certains aspects et en ignorer d’autres. Les indica-teurs sont mis à jour régulièrement. Les conclusions partagées par les intéressés et unsuivi sur le terrain permettent de disposer d’une perception efficace de la santé du projet.


PARTIE 44Annexe

Modèles et exemplesCette annexe présente certains documents évoqués dans le cours de l’ouvrage.Ces documents sont essentiellement de deux types :

• Des listes permettant de récapituler certains sujets traités dans l’ouvrage etpouvant jouer le rôle d’aide-mémoire. Ces listes ne sont pas exhaustives etpeuvent être complétées par des éléments spécifiques de chaque projet.

• Des exemples de rapports cités dans l’ouvrage. Ils peuvent également servirde source d’inspiration pour créer ou améliorer les documents que le lecteurpeut souhaiter utiliser pour le pilotage de projets offshore.

Ces exemples sont inspirés de documents réellement utilisés dans des projets.Ils sont ici simplifiés afin d’être plus faciles à comprendre. Ils sont générale-ment extraits d’outils permettant de traiter les informations qu’ils contiennentd’une façon structurée.

L’introduction de chaque document rappelle le chapitre qui y fait référence. Lelecteur pourra s’y reporter pour mieux comprendre leur cadre d’utilisation.

Évaluation du projet offshore

Le tableau 1 énumère les questions abordées au chapitre 7, qui permettentd’évaluer la nature du projet offshore et d’en estimer la difficulté. Le contenudétaillé des questions et l’impact des réponses sur les opérations en offshoresont exposés dans ce chapitre.



310

Tableau 1. Évaluation du projet en offshore

Domaine Sujet à traiterImportance de

répondre à cette question

Réponse

Décisions pour utiliser l’offshore

Quelles sont les raisons qui poussent la société à sous-traiter en offshore ?

3

Implication en offshore

Quels seront les projets confiés en offshore ? 3

Quel pourcentage de développements sera probable-ment réalisé en offshore dans le long terme ?

3

Budget Quelles sont les priorités budgétaires ? 2

Quelle économie vise-t-on en offshore ? 2

Dispose-t-on d’un ordre de grandeur des dépenses anticipées ?

3

Sécurité Quel est le niveau minimal de sécurité que l’on souhaite atteindre ?

3

Quelles sont les exigences de sécurité que l’on voudrait chiffrer pour décider de ce que l’on souhaite faire ?

2

Essai Veut-on réaliser un projet test ou souhaite-t-on démar-rer sur un projet réel ?

3

Quels enseignements espère-t-on du projet test ? 3

Quel serait le projet test ? 2

Management Qui, en interne, prend le management des opérations en offshore ?

3

Est-il motivé sur l’offshore ? A-t-on mis toutes les chances de son côté ?

3

Veut-on placer une personne de la société en offshore chez le prestataire, soit pour contrôler, soit pour mana-ger les équipes ?

3

L’offshore complète-t-il les opérations locales ou est-il censé les remplacer partiellement et, si oui, de quelle façon ?

2

Souhaite-t-on se faire accompagner dans la mise en place ou le management des opérations en offshore ?

2


Annexe - Modèles et exemples

311

Domaine Sujet à traiterImportance de

répondre à cette question

Réponse


A-t-on déjà décidé du type de montage de l’offshore ? (prestataire, filiale, joint-venture)

3

Quel pays a-t-on retenu pour construire l’équipe distante ? Quelles sont les règles de sélection du pays ?

3

Quelle taille d’équipe pense-t-on construire à terme ? 2

Y a-t-il des contraintes particulières à prendre en compte pour choisir le prestataire ?

2

Méthodologie et procédures

Quelle méthodologie veut-on mettre en œuvre ? La méthodologie locale peut-elle être appliquée en offs-hore ? Quels documents a-t-on pour expliquer et supporter cette méthodologie ?

3

Souhaite-t-on utiliser une méthodologie standard comme RUP ou XP ? Si oui, comment ?

2

Souhaite-t-on se faire accompagner par un consultant pour la mise en place de la méthodologie retenue ?

2

Cette méthodologie sera-t-elle aussi appliquée en interne ?

3


Quelles formations envisage-t-on de donner aux colla-borateurs en offshore sur les aspects fonctionnels, organisationnels et techniques ?

2

Quel accompagnement choisit-on pour faire correcte-ment fonctionner l’offshore dès la première mise en œuvre ?

2


Peut-on déjà décider de l’investissement que l’on veut consentir pour l’outillage des opérations en offshore ?

2

Veut-on chiffrer des solutions de progiciel de gestion de projet ?

3

Tableau 1. Évaluation du projet en offshore(suite)



312

Rapport de facturation

Les tableaux 2 à 4 donnent des exemples de rapports du prestataire offshore destinés àjustifier sa facturation. Ces rapports sont traités au chapitre 8.

Le tableau 2 présente la facturation des ressources humaines sur la base d’une factura-tion mensuelle. Le nombre de jours ouvrés du mois est rappelé afin de lever toute ambi-guïté, particulièrement lors d’une étude future. Le pourcentage correspond à l’allocationdu collaborateur sur le projet.

Le tableau 3 fait partie du rapport accompagnant la facturation. Il permet de suivre lesmouvements du personnel, notamment les validations des embauches.

Tableau 2. Facturation des ressources humaines sur une base mensuelle

Personnel Date

20 jours ouvrés dans le mois

#

Nom

Cat

égor

ie

Jour

s tr

avai

llés

Trav

ail

supp

lém

enta

ire

Tarif

men

suel

de

bas

e (e

n do

llar)

Pour

cent

age

Fact

urat

ion

Posi

tion

1 KARPOVITCH, Sergey DEV 20 0 3 000 100 % 3 000 Team Manager

2 KHVAL, Piotr DEV 20 0 2 200 100 % 2 200 Developer

3 VALAKHANOVICH, Alexandra

DEV 20 0 2 200 100 % 2 200 Development Team Leader

4 PUSHKIN, Dmitry TEST 15 0 1 800 50 % 675 Tester

5 SIGOV, Alexey TEST 20 1 1 800 100 % 1 890 Tester

6

7



313

Le tableau 4 permet de suivre les heures supplémentaires effectuées par les collabora-teurs en offshore. Il détaille notamment les heures supplémentaires approuvées et gardetrace des raisons qui ont motivé cette décision.

Tableau 3. Mouvements de personnel et validation des embauches

Changements et prévisions Date

Nouveaux arrivants

Nom Date d’arrivée Position Coût de basePourcentage d’allocation

Départs

NomDate de départ

Position Coût de basePourcentage d’allocation

BULGAKOV, Vitaly date Developer $2 200 100 %

Validation de période d’essai

NomDate

de validationPosition

BURAK, Igor date Technical Tester (Test Team)

Changement de poste

Nom Date d’effetPosition

précédenteNouvelle position

Commentaire

VALAKHANOVICH, Alexandra

date Developer Development Team Leader

Promotion



314

Points à considérer dans un contrat en mode régie

Le tableau 5 rassemble tous les points à considérer lorsqu’on élabore un contrat de pres-tations en offshore. Ces sujets sont traités en détail au chapitre 9. Le tableau récapituleles options que le client peut retenir pour définir le contrat. Le client peut aussi préférertraiter certains de ces points en dehors du cadre contractuel.

Tableau 4. Heures supplémentaires

Heures/jours supplémentaires Février 2004

Nom DateJours travaillés

supplémentairesApprouvé par Commentaire

SIGOV, Alexey Date 1 0,5 RBO Urgent deployment of bug fix

BULGAKOV, Vitaly Date 2 0,5 NOT Approved Not requested by management

Tableau 5. Options du contrat avec le prestataire

Points généraux

Vérifier que le prestataire est effectivement une personne morale

Vérifier le contrat pour se protéger d’une accusation de marchandage ou de prêt illicite de main-d’œuvre

Vérifier le contrat pour se protéger contre une embauche de fait du personnel du prestataire

Prévoir le recours à la médiation en cas de désaccord

Propriété intellectuelle

Attribuer la propriété intellectuelle des réalisations offshore au client

Inclure régulièrement tous les éléments créés au cours du projet dans les livraisons

Couvrir la production du personnel officiellement salarié ou non dans les clauses de propriété intellectuelle

Mentionner l’obligation de noter sur tous les documents la mention de copyright

Identifier les éléments qui sont la propriété de tiers

Définir les conditions d’utilisation des éléments qui sont la propriété du prestataire dans le projet

Définir les conditions d’intégration dans le projet des éléments externes et potentiellement soumis à des licences payantes



315

Prestations de base

Définir la devise de facturation

Définir la méthode de choix du taux de change euro/dollar

Définir le mode de facturation par mois, au jour ou à l’heure

Définir la langue de travail

Définir la langue des échanges professionnels internes au prestataire sur le projet

Définir le traitement des documents dans la langue locale du client (traducteurs)

Définir la gestion des heures supplémentaires chez le prestataire

Considérer l’interdiction des heures supplémentaires non approuvées

Définir la gestion des absences

Définir le nombre de jours de congé annuel, si nécessaire

Définir la liberté donnée au prestataire sur les rattrapages des absences et des congés

Décrire le mode de facturation des ressources humaines (par catégorie de profil, indexé sur le salaire ou forfaitaire)

Considérer une partie du travail au forfait dans le contrat en régie

Définir la fréquence des révisions des catégories de personnel servant à la facturation

Prestations complémentaires

Définir précisément les services intégrés dans les prestations par collaborateur et ceux qui font l’objet d’une facturation additionnelle.

Définir les services complémentaires qui sont fournis de façon forfaitaire dans le contrat.

Définir les services complémentaires qui sont refacturés au client et leur mode de calcul.

Définir le mode de calcul des remises pour les volumes importants

Définir les informations que le prestataire doit fournir à son client, surtout les informations qui peuvent poser un problème au prestataire.

Définir la liste des sujets de formations générales qui sont à la charge du prestataire.

Définir la liste des formations spécifiques qui sont à la charge du client.

Définir les matériels et logiciels qui doivent être déployés chez le prestataire et leur mode d’acquisition.

Définir la méthode de suivi du matériel et logiciels achetés ou déployés chez le prestataire

Définir les clauses de revente et/ou de mise à disposition du matériel lorsqu’il n’est plus utilisé.

Tableau 5. Options du contrat avec le prestataire(suite)



316

Prestations complémentaires (suite)

Prévoir la mise à disposition de salles de réunion en offshore

Décider du logement en offshore si des déplacements réguliers sont à prévoir.

Définir une qualité minimale du cadre de travail chez le prestataire

Prévoir une pénalité pour un défaut dans la qualité du cadre de travail (ou sur d’autres services qui ne seraient pas convenablement fournis).

Sécurité

Définir le niveau de sécurité attendu en offshore et les règles de sécurité les plus importantes

Considérer l’isolement du réseau local dédié au client

Prévoir un audit de fin de contrat

Factures

Définir la date de facturation et les conditions de règlement

Prévoir de définir le lien qui lie l’organisme qui facture le client avec le prestataire qui effectue le travail lorsque ce ne sont pas les mêmes entités.

Définir le mode de fonctionnement permettant un paiement rapide de la facture et la gestion des erreurs

Définir une procédure de gestion des ajustements de la facture

Définir les règles de paiement des collaborateurs en offshore lors des retards de paiement du client, si néces-saire

Prévoir une pénalité pour retard de paiement du personnel en offshore

Définir les règles et la périodicité des augmentations des prestations en offshore

Management

Prévoir si nécessaire que le prestataire applique la méthodologie du client.

Vérifier le statut des collaborateurs en offshore, notamment s’ils sont effectivement des employés du prestataire.

Prévoir que le prestataire notifie l’emploi de collaborateurs externes.

Prévoir l’utilisation d’un accord de confidentialité pour le partenaire et les collaborateurs travaillant sur le projet

Inclure un document rappelant les engagements du prestataire en fin de projet

Définir la procédure d’embauche et la définition de l’organigramme cible

Prévoir, dans la procédure d’embauche, de refuser un candidat en offshore sans avoir à le justifier




317

Suivi des risques

Le tableau 6 donne un exemple de feuille de suivi des risques, un sujet abordé en détailau chapitre 10. Le tableau associe à chaque risque un responsable, qui a pour tâche desuivre le risque et de mettre à jour ses attributs. Le plan de repli prévoit les actions àengager si le risque se réalise. Le responsable a identifié une ou plusieurs actions correc-tives permettant d’éliminer ou de réduire la portée du risque. Chaque action peut êtrevalidée ou rejetée par le management, ce dont on garde trace pour une éventuelle analyseultérieure.

Prévoir le statut des candidats détectés par le prestataire en attente de validation du client, particulièrement lorsqu’ils commencent à travailler par anticipation.

Définir le préavis de retrait des employés à l’initiative du client et du prestataire

Définir les règles de réduction des effectifs en offshore

Définir les règles de remplacement d’un salarié qui est retiré à la demande du prestataire (formation, recouvrement).

Prévoir les règles d’embauche par le client de collaborateurs du prestataire

Définir, si nécessaire, des règles fixant le niveau général des salaires des collaborateurs du client chez le prestataire

Prévoir si les salaires des collaborateurs en offshore peuvent être communiqués au client.

Définir l’influence que le client peut avoir sur les rémunérations en offshore.

Prévoir que le client puisse définir l’organisation de ses équipes chez le prestataire.

Prévoir de définir les règles de présence des collaborateurs en offshore à temps partiel

Définir les règles interdisant aux collaborateurs en offshore d’être employés par un autre employeur

Définir les grandes lignes des procédures à appliquer au projet

Définir précisément les informations de suivi les plus sensibles que le prestataire devra fournir au client.

Décider de l’isolement des équipes travaillant pour le client du reste des collaborateurs du prestataire

Prévoir la possibilité de licencier, voire de poursuivre le collaborateur qui ne respecterait pas certains engagements, notamment sur la confidentialité.

Prévoir la possibilité de retenir le paiement des factures si les engagements du prestataire ne sont pas remplis.

Prévoir d’interdire que le prestataire suspende ses services ou définir précisément la procédure et les pénalités en cas de non-respect des procédures.




318

Tabl

eau

6. S

uivi

des

ris

ques

ID

Domaine

Date de détection

Responsable

Période de réalisation du risque

Personnes/équipes impliquées

Niveau de risque

Probabilité de réalisation

Niveau de risque

État courant

Description

Effets anticipés

Plan de repli

Correction ID

Actions correctives

Propriétaire des actions correctives

État de l’action

Date de fin

39Te

ch10

/01/

2005

VBA

Cou

rt te

rme

IGR,

PG

A,

VBR

733

%2,

31En

atte

nte

de v

alid

a-tio

n pa

r VB

A

Les

serv

ices

de

déve

lopp

emen

t de

l’inte

rface

hom

e-m

achi

ne q

ui d

evai

t êt

re fo

urni

e pa

r l’é

quip

e te

chni

que

doiv

ent v

érifi

er q

ue

les

choi

x te

chni

-qu

es s

ont r

éalis

tes,

ce

qui

n’e

st p

as s

ûr

à ce

jour

.

Si d

es p

robl

è-m

es s

ont

renc

ontré

s et

s’

ils m

ènen

t à

choi

sir d

’aut

res

tech

nolo

gies

, on

peut

ant

icip

er

un re

tard

de

deux

moi

s.

Nou

s po

uvon

s ch

oisi

r de

reve

nir à

l’a

ncie

nne

vers

ion

des

outil

s IH

M.

39-1

Con

stru

ire u

n te

st

de fa

isab

ilité

pour

an

alys

er le

s pe

rfor-

man

ces

et e

stim

er

la ré

alité

du

risqu

e

SMA

En a

ttent

e de

val

idat

ion

par V

BA

10/0

3/20

05

39-2

Réal

iser

en

para

l-lè

le d

eux

appr

o-ch

es d

iffér

ente

s vi

sant

à a

ttein

dre

le

mêm

e ob

ject

if. L

e ch

oix

final

ser

a fa

it lo

rsqu

’on

aura

la

visi

bilit

é su

ffisa

nte.

IBA

Reje

té p

ar le

m

anag

emen

tN

A



319

ID

Domaine

Date de détection

Responsable

Période de réalisation du risque

Personnes/équipes impliquées

Niveau de risque

Probabilité de réalisation

Niveau de risque

État courant

Description

Effets anticipés

Plan de repli

Correction ID

Actions correctives

Propriétaire des actions correctives

État de l’action

Date de fin

40RH

15/0

1/20

05PL

AM

oyen

te

rme

ALL

490

%3,

6La

cor

rec-

tion

40-1

es

t app

li-qu

ée.

Au m

oins

40

% d

es

déve

lopp

eurs

et

des

test

eurs

ser

ont

prob

able

men

t ab

sent

s en

aoû

t, ju

ste

avan

t la

date

d’

une

rele

ase

maj

eure

.

Com

me

le p

lan-

ning

est

ser

ré,

on p

eut s

’atte

n-dr

e à

des

prob

lèm

es d

e qu

alité

ou

de

reta

rd.

L’ab

senc

e de

ce

rtain

s tes

teur

s re

ndra

le p

rodu

it pa

rticu

lière

men

t di

ffici

le à

val

ider

.

Trav

ail s

ur

le co

nten

u de

s ité

ra-

tions

pou

r ce

tte

pério

de e

t ca

lcul

des

dé

lais

. Le

sco

pe

fonc

tion-

nel d

e la

re

leas

e ris

que

d’êt

re

rédu

it.

40-1

Antic

iper

les

date

s de

vac

ance

s et

an

nonc

er q

ue le

s va

canc

es n

e pe

uven

t être

pris

es

en a

oût.

NG

IÀ

tent

er01

/03/

2005

40-2

Gon

fler l

es é

quip

es

avan

t aoû

t de f

açon

à

cons

erve

r une

pl

eine

cap

acité

de

prod

uctio

n en

aoû

t

NG

IRe

jeté

par

le

man

agem

ent

NA

Tabl

eau

6. S

uivi

des

ris

ques

(sui

te)



320

Suivi des décisions en offshore

Le tableau 7 illustre le suivi des décisions prises en offshore afin d’éviter qu’elles nesoient pas traitées. Ce sujet est traité au chapitre 11.

Gestion des exigences

Le tableau 8 présente la façon dont on peut définir certains attributs pour chaqueexigence afin d’établir les priorités de réalisation ou le suivi de chacune d’elles. La gestiondes exigences est souvent traitée dans un outil dédié permettant d’y associer un workflowet une traçabilité entre divers éléments.

Ce tableau est mentionné aux chapitres 11 et 12. Il comporte des informations sur laplanification, qui, ajoutées à la charge estimée, permettent de construire un planning par

Tableau 7. Décisions générales et suivi des décisions

ID

Dom

aine

Dat

e de

sou

mis

sion

Res

pons

able

Impo

rtan

ce

Des

crip

tion

Actio

ns p

ropo

sées

Dat

e de

l’ac

tion

Res

pons

able

de

l’act

ion

État

Dat

e de

fin

10 IT date IMA HIGH L’équipe offshore a besoin d’un autre serveur pour être capable de créer des builds quotidiens efficacement. Dans l’organisation courante, l’équipe de déploiement ne peut déployer une version à la fois pour les tests courants et pour les builds quotidiens.

Acheter un autre serveur et mettre à jour les procédures de déploiement

date EBO Définir un budget pour cette dépense non budgétisée et le faire valider par la direction financière

date

11 PROC date SMA AVG Définition d’une nouvelle procédure pour la demande de vacances

Une nouvelle procédure doit être créée.

date ELY Une trame de la procédure est propo-sée pour validation par le client.

date

date FLI Le processus complet est proposé pour validation.

date



321

itération (charge, prédécesseur, démarrage itération, itération cible, release). L’informa-tion sur l’avancement (état d’avancement) de la réalisation de l’exigence permet decommuniquer sur son état de disponibilité. Un marquage, par exemple, par des couleurspeut identifier si l’avancement est conforme à la planification ou en retard. Enfin, certainsattributs, comme la priorité, le risque, la charge (complexité) et la stabilité, permettent dedéfinir la priorité de traitement de l’exigence dans les plannings, afin de traiter en prioritéles exigences à fort risque et complexes.

Les attributs des exigences sont rafraîchis régulièrement pour prendre en compte lesinformations les plus récentes.

Iteration assessment

Le tableau 9 illustre la façon dont les résultats d’une itération peuvent être consignésdans le rapport d’iteration assessment. Ce sujet est abordé au chapitre 12. Les effets desrésultats des itérations sont utilisés pour éviter que les mêmes erreurs ne se répètent.L’expérience tirée de l’itération permet de mettre à jour les attributs des exigences(charge, priorité, risque, etc.).

Tableau 8. Gestion des exigences

ID

Mod

ule

Cod

e

Nom

Des

crip

tion

Dém

arra

ge it

érat

ion

Itéra

tion

cibl

e

Rel

ease

Prio

rité

Dis

poni

bilit

é de

s sp

ecs

État

d’a

vanc

emen

t

Cha

rge

Ris

que

tech

niqu

e

Stab

ilité

du

beso

in

Préd

éces

seur

18936237266 M1 M1-DA-01

Détruire un compte

Destruc-tion d’un compte et mise à jour des tables liées

6.1 6.1 V1.12 MOYEN 15/01/2006

ANALYSE 7 FAIBLE HAUTE Socle techni-que SC v1.11

18936237267 M3 M3-CT-06

Contrôle de saisie de la fonction F122

Contrôle de saisie de la fonc-tion F122

6.2 6.3 V1.12 HAUTE 22/02/2006

DEV 50 %

4 FAIBLE HAUTE Socle techni-que SC v1.11

18936237268 M2 M2-CT-04

Contrôle de saisie de la fonction F128

Contrôle de saisie de la fonc-tion F128

6.2 6.3 V1.11 HAUTE 18/01/2006

TEST 9 FAIBLE HAUTE Socle techni-que SC v1.11



322

Tabl

eau

9. E

xem

ple

d’it

erat

ion

asse

ssm

ent

Obj

ectif

sAs

sess

men

tC

omm

enta

ireDescription

Itération de début

Fin d’itération

Release

Priorité

Date de livraison

% de réalisation en fin d’itération

Raisons du retard

Effet du retard

Action corrective

Commentaire du client

Commentaire du prestataire

Trai

tem

ent

du c

hang

e re

ques

t C

R128

7

6B6B

11.1

HAU

TE26

/01/

2006

100

%

Réal

isat

ion

com

plèt

e du

U

C 1

2 de

ge

stio

n de

s no

uvea

ux

clie

nts

6A6B

11.1

MED

IUM

18/0

1/20

0680

%D

épen

ds d

e la

livr

aiso

n de

la n

ouve

lle v

ersi

on

des

serv

ices

tech

ni-

ques

qui

ont

été

livr

és

avec

reta

rd. L

a ré

alis

a-tio

n n’

est p

as e

n re

tard

au

trem

ent.

Livr

aiso

n no

n ef

fect

uée

Rattr

aper

le

reta

rd s

ur l’

itéra

-tio

n su

ivan

te

L’éq

uipe

n’a

pas

été

te

nue

au c

oura

nt

du re

tard

pou

rtant

pr

évis

ible

de

la

livra

ison

des

ser

vi-

ces

tech

niqu

es.

Réal

isat

ion

des

exig

en-

ces

123,

128

et

132

6B6B

11.1

MED

IUM

26/0

1/20

0650

%Le

s us

e ca

ses

spéc

i-fia

nt l’

exig

ence

132

ont

ét

é liv

rés

en re

tard

, ce

qui a

méc

aniq

uem

ent

indu

it un

reta

rd s

ur le

s dé

velo

ppem

ents

.

Livr

aiso

n no

n ef

fect

uée

Mei

lleur

e pl

anifi

-ca

tion

des

exig

ence

s. N

oti-

fier l

e ch

ef d

e pr

odui

t VBA

de

l’effe

t de

ces

reta

rds

Le c

hef d

e pr

odui

t est

to

mbé

mal

ade,

et

per

sonn

e n’

a av

erti

les

équi

pes

des

reta

rds i

ndui

ts.

Cha

que

chef

de

pro

duit

doit

avoi

r un

« ba

ckup

».



323

Obj

ectif

sAs

sess

men

tC

omm

enta

ire

Description

Itération de début

Fin d’itération

Release

Priorité

Date de livraison

% de réalisation en fin d’itération

Raisons du retard

Effet du retard

Action corrective

Commentaire du client

Commentaire du prestataire

Livr

aiso

n de

la

nou

velle

ve

rsio

n de

s se

rvic

es

tech

niqu

es

5F6A

11.1

HAU

TE15

/01/

2006

90 %

Des

bog

ues

ont é

té

déco

uver

ts, q

ui o

nt

rend

u im

poss

ible

l’e

xplo

itatio

n de

ces

se

rvic

es te

chni

ques

pa

r les

équ

ipes

fonc

-tio

nnel

les.

Reta

rds

sur

tout

es le

s éq

ui-

pes

fonc

tion-

nelle

s

Prév

oir u

ne

pério

de p

lus

impo

rtant

e en

tre

la fi

n du

dév

e-lo

ppem

ent e

t l’e

xplo

itatio

n pa

r les

aut

res

équi

pes

Réal

isat

ion

com

plèt

e de

l’e

xige

nce

156

6B6B

11.1

MED

IUM

23/0

1/20

0690

%Le

s te

sts

ne s

ont p

as

term

inés

du

fait

d’al

lo-

catio

ns s

uppl

émen

tai-

res

sur l

a va

lidat

ion

des

serv

ices

tech

niqu

es.

Livr

aiso

n no

n st

abilis

éePr

évoi

r une

pé

riode

plu

s im

porta

nte

entre

la

fin

du d

éve-

lopp

emen

t et

l’exp

loita

tion

par l

es a

utre

s éq

uipe

s

Tabl

eau

9. E

xem

ple

d’it

erat

ion

asse

ssm

ent(

suit

e)



324

Planning détaillé d’une itération

Le tableau 10 illustre la façon dont le planning détaillé d’une itération peut être construitdans Microsoft Project, comme expliqué au chapitre 12. Ce modèle sert de point de départà la planification du travail d’une itération (quatre à six semaines) pour chaque équipe(une à six personnes). Le détail des tâches doit être de quelques jours.

Les priorités découlent des exigences et de directives du management du client, de façonà bien identifier les tâches prioritaires sur l’itération. Les mécanismes internes de MicrosoftProject permettent d’ordonner les tâches selon leur priorité. Le modèle note clairementles livrables externes, dont certaines tâches de l’équipe dépendent, et isole les tâches decorrection et d’évolution de features des tâches réalisant de nouveaux développements afinde bien réserver la quantité de travail désirée sur chaque type d’activité.

Les tâches de documentation sont précisées de façon à garantir que les collaborateursprévoient le temps nécessaire à leur création et ne considèrent pas que la livraison d’unexécutable est le seul objectif. Les livrables dont d’autres équipes dépendent sont spéci-fiés afin de mesurer l’impact des retards et d’en avertir les équipes concernées. Ceséléments permettent de conserver les plannings alignés.

Les tâches de management (réunions, reporting) sont également prévues. Cela permet dedisposer de tous les types de tâches. Les collaborateurs devraient mesurer une utilisationdes ressources de 100 % une fois le planning finalisé.

Ces plannings peuvent être consolidés, mais c’est en définitive peu utile. Les chefs deprojet préfèrent suivre la progression du travail par équipe. On peut créer des macrofonc-tions ou de petits programmes permettant de reporter dynamiquement les jalons dedépendance d’un planning sur les plannings dépendants. Lorsqu’un chef d’équipemodifie son planning et déplace la date de livraison d’un élément, celle-ci se trouve miseà jour dans tous les plannings y faisant référence.

La feuille de recette (Acceptance Sheet)

Le tableau 11 donne un exemple d’Acceptance Sheet, un sujet détaillé au chapitre 13. Onpeut remarquer l’état de qualité de chaque feature pour chaque build. Chaque colonnereprésente un build, dont les tests sont le plus souvent partiels.

Les commentaires sur les cellules contiennent les anomalies détectées qui justifient lesétats en noir (anomalie bloquante) ou en gris plus ou moins clair (anomalie plus oumoins importante).



325

Tabl

eau

10. P

lann

ing

déta

illé

d’un

e it

érat

ion



326

Tabl

eau

11. E

xem

ple

d’A

ccep

tanc

e Sh

eet



327

Mesure des économies réalisées en offshore

Le tableau 12 donne un modèle de calcul des économies réalisées en confiant un projeten offshore par rapport à une réalisation locale, comme expliqué en détail au chapitre 15.

Les hypothèses de calcul doivent être choisies de sorte à ne pas prêter le flanc à la critiquequ’elles auraient été définies d’une façon favorable à l’offshore. Les « coûts totauxconstatés en offshore » doivent inclure toutes les dépenses annexes, y compris les dépla-cements sur place.

Le premier objectif de ce document est de renseigner la colonne « Économie réalisée ».On peut aussi tenter de valoriser d’autres valeurs, comme les « Jours perdus du faitde changements tardifs des spécifications », de façon à faire prendre conscience auxutilisateurs des coûts induits par ceux-ci.



328

Tabl

eau

12. M

odèl

e de

cal

cul d

es é

cono

mie

s ré

alis

ées

en o

ffsh

ore

(en

euro

)

Projet

Coût total constaté en offshore

Nombre de jours de travail pour l’offshore

Estimation du nombre de jours de réalisation

chez le client

Coût réalisation chez le client

Économie réalisée

Ratio d’économie

Jours perdus du fait de changements tardifs

des spécifications

Proportion des changements

Coûts des changements tardifs

Commentaire

Proj

ets

term

inés

Proj

et A

200

000

2 00

01

500

409

091

209

091

49 %

120

8 %

16 0

00

Proj

et B

120

000

1 20

01

000

272

727

152

727

44 %

100

10 %

12 0

00

Tota

l32

0 00

068

1 81

836

1 81

822

028

000

Réa

lisat

ions

cou

rant

es

Mod

ule

C-1

25 0

0025

022

060

000

35 0

0042

%10

5 %

1 13

6

Mod

ule

C-2

32 0

0032

030

081

818

49 8

1839

%0

0 %

0

Mod

ule

C-3

65 0

0065

063

017

1 81

810

6 81

838

%63

10 %

6 50

0

Tota

l pro

jet C

122

000

1 22

01

150

313

636

191

636

39 %

Mod

ule

D-1

12 0

0012

012

032

727

20 7

2737

%0

0 %

0

Mod

ule

D-2

8 00

080

7520

455

12 4

5539

%10

13 %

1 06

7

Tota

l pro

jet D

20 0

0020

019

553

182

33 1

8238

%

Coû

t tot

al d

u tra

vail

de ré

alis

atio

n14

2 00

01

420

1 34

536

6 81

822

4 81

839

%



329

Projet

Coût total constaté en offshore

Nombre de jours de travail pour l’offshore

Estimation du nombre de jours de réalisation

chez le client

Coût réalisation chez le client

Économie réalisée

Ratio d’économie

Jours perdus du fait de changements tardifs

des spécifications

Proportion des changements

Coûts des changements tardifs

Commentaire

Suiv

i de

proj

et

chez

le c

lient

28 0

0080

Autre

s fra

is c

lient

(v

oyag

es, e

tc.)

12 0

00

Tota

l18

2 00

01

500

1 34

536

6 81

818

4 81

850

%83

8 70

3

Vale

urs

et h

ypot

hèse

s

Coû

t moy

en d

u m

ois/

hom

me

clie

nt6

000

Coû

t moy

en g

estio

n de

pro

jet c

lient

7 00

0

Tabl

eau

12. M

odèl

e de

cal

cul d

es é

cono

mie

s ré

alis

ées

en o

ffsh

ore

(en

euro

)(su

ite)


331

A

Acceptance Sheet 273, 301Asie 38

B

Bangalore 43BrainBench 33, 43, 160budget 140

C

change 180chef de projet 14, 61

chez le client 146et petits projets 237

choisir le projet à externaliser 97communication 205, 216

avec le client 235sur les projets offshore 65

comparaisond’une filiale et d’un prestataire offshore 82des partenariats 87des sources des spécifications 98du choix des ressources 25

compétitivité 10complexité technique 102conditions de travail 75

confidentialité 122, 178conseil à l’offshore 148-149contrat 173

communication et références 205considérations générales 173de partenariat 168devise de facturation et risque de change 180gestion

des équipes 198des factures 194

mode de fonctionnement 85propriété intellectuelle 175régie 92rupture du 206services du prestataire 179termes de paiement 194transparence des forfaits 92

coûts 16, 40, 166augmentation brutale 127comparaison des 16d'une filiale en offshore 82d’un collaborateur de l’offshore invité 77définition du budget 140des prestations 166

et productivité 41joint-venture 87marge 86mesure des 53vacances 76

Index



332

D

décalage horaire 89, 155délocalisation 7déplacements en offshore 44, 159déploiement 63, 281

chez le client 285tests de 277

développement 52nearshore 29offshore 29offsite 29onsite 26

différences culturelles 26, 33, 78, 158documentation 59documents

administratifs 304automatisation 305fonctionnels 98organisationnels 303

E

éducation 42éloignement des équipes 30émigration 73équipe

choix de l’ 153choix du manager 145constitution 168, 199cumul de postes 52de recette 63doublement de l’ 161éloignement 30embauche des collaborateurs 169flexibilité 200formation 171gestion d’ 17invitation 77isolement 201

locale 56, 64modes de gestion 88noyau central 165offshore (suivi) 291profils 227qualité de l’ 20risques sociaux 133rôles 22, 60, 230salaires 53, 60

Europe de l’Est 38évaluer son projet pour l’offshore 137externalisation 64

F

facturation 181des collaborateurs 185retards de paiement 130

filiale 81flexibilité des équipes 17fonctionnement de l’offshore 79fondations techniques 111, 283forfait 25, 80, 90

dangers 91définition 10sous-projets 185suivi de projet 204

formalisation des spécifications 98formation 149, 171, 189

langue de travail 33

G

géants de l’offshore 45gestion

de la qualité 269de projet 209

communication 216méthode itérative 220objectifs de management 213


Index

333

petites équipes 224

points clés 211

procédures utiles 219

recherche de la qualité 218

responsabiliser l’offshore 225

satisfaction du client 211

des corrections et des nouveaux développements 256

des équipes 15, 17, 198

des plates-formes 281

des projets 35

des ressources humaines 227

chef de projet 237

communication avec le client 235

distribution des responsabilités 229

favoriser les initiatives 233

identification des profils 227

mentors et rôles centraux 234

pouvoir de décision 232

primes 237

des risques 217

des tâches clés 225

des tests 269

du changement 248

H

heures supplémentaires 183

horaires de travail 76

I

IBM Rational 21, 123

Inde 38

informaticiens 53, 55

motivation 67

salaires 68

intégration 63, 264, 281

invitation 77, 159isolement des équipes 124itération 220, 298

analyse 263planning détaillé 261release plan 260

J

joint-venture 87

L

label qualité 86langue de travail 31, 160licences 131, 192litiges 116livrables (préparation des) 288

M

Maghreb 38management 84manager 145marge du prestataire 86MAT (Minimal Acceptance Test) 272mentalités 35mentor 145, 230, 234mesure des coûts 53méthode 21, 148, 243

analyse de l’itération 263automatisation des rapports de suivi 266documentation 59efforts de gestion 110favoriser la motivation 253gestion

de la documentation 252de versions 258des corrections 256



334

méthode (suite)

des exigences 249

des flux 250

des tests 251

du changement 248

importance des rôles clés 111

itérative 220

mise en place 252

et suivi 203

planning 255

procédures et outils 244

produits 245

protection de la 127

référentiel 246

release plan 259

satisfaction du client 211

tests unitaires 266

valider la réalité des réalisations 263

MicrosoftMSF (Microsoft Solutions Framework) 243

SharePoint 123

mondialisation des tâches informatiques 7

montage des équipes 79

motivation 60, 67, 253

multinationales de l’offshore 45

N

nearshore 25

O

offsite 11, 25

onsite 11, 25

organigramme 304

outils de suivi de projet 150

outsourcingavantages 15principes 5

P

paiements du client 130pays de l’offshore 37personnel en régie 28perte d’emploi 14planning 255, 299premier projet 104prestataire 44

au forfait 80choix du 153

demande d’informations 162questions à se poser 154

collaborateurs 51communication avec le client 235contrat 168, 173culture du pays 158décalage horaire 155devise de facturation et risque de change 180évaluation du 143importance de la localisation 89joint-venture 15langue de travail 160, 179leaders locaux 47litige 116localisation 155marges 86modes de fonctionnement 85références 167services 179

complémentaires 190visites au 294

primes 60, 237procédures 148, 283processus de développement 243productivité 42


Index

335

profils 227projet

ambitieux 106de fondations techniques 111de reverse-engineering 107de test 104, 143module périphérique 105outils de suivi 150petit 109préparation 135typologie 107, 112

propriété intellectuelle 117, 120, 175, 207

Q

qualité 21, 218, 299des ressources 20gestion de la 269

questions stratégiques 138

R

rapportd’activité 302de suivi 204

Rational 21, 123ClearCase 122, 150

recette 63références 205référentiel 101, 122, 150, 246

gestion des streams 247régie 25, 92

coût 28définition 10forfaitée 94partage des responsabilités 93

release plan 259reporting 292responsable fonctionnel 62

ressources humaines 227rétention des sources 118reverse-engineering 99, 107RFI (Request For Information) 162risque 115

politique 131social 133sur les livraisons 258tests et mesure du 277

rôle 229attribution 22spécialisé 60

RUP (Rational Unified Process) 21, 31, 100, 149, 243

S

salaires 38, 60, 68, 202sécurité 122, 142, 192, 306

des locaux 77serveur de messagerie 124sous-projet au forfait 185spécifications 98stabilité politique 44suivi

de l’équipe offshore 291de projet 291

iteration assessment 298mesure des économies 305plannings 299qualité 299rapport d’activité 302

documents de 295supervision des plates-formes 287système éducatif 160

T

Telelogic 123termes de paiement 194



336

terminologie 9, 10

tests 21

automatisation 22

chez le client 286

couverture des 276

de déploiement 277

enrichissement des 275

et mesure du risque 277

fonctionnels 271

transversaux 274

fonctions des outils 251

gestion des 251, 269

intuitifs 275

MAT (Minimal Acceptance Test) 272

techniques 276

unitaires 266, 270

travail en offshore 67

U

universités 21, 42

V

vacances 76validation 103vocabulaire 13

W

workflow 21, 245, 250

X

XP (eXtreme Programming) 21, 31, 100, 149, 243


Eyrolles conduite-de-projets-informatiques-offshore

Engineering

Transcript of Eyrolles conduite-de-projets-informatiques-offshore