Conduite de projets informatiques offshore

Solutions d’entreprise

Eric O’Neill

Quels projets soustraiter en offshore ? ●

● Choix du pays et du prestataire ●

Évaluation des risques

● La relation contractuelle avec le prestataire ● ● ●

Méthodologie de suivi de projet

Tests, recette et déploiement

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

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.

Conduite de projets informatiques offshore

Eric O’Neill

Avec la contribution de Olivier Salvatori

ÉDITIONS EYROLLES 61, bd Saint-Germain 75240 Paris Cedex 05 www.editions-eyrolles.com

Le code de la propriété intellectuelle du 1er juillet 1992 interdit en effet expressément 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

Pour Alexandra

Table des matières 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

VII

Conduite de projets informatiques offshore

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

VIII

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

IX

Conduite de projets informatiques offshore

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

X

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

XI

Conduite de projets informatiques offshore

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

XII

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

XIII

Conduite de projets informatiques offshore

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

XIV

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

XV

Conduite de projets informatiques offshore

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

XVI

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 logiciel consomme une quantité importante de main-d’œuvre très qualifi ée, comptant bien souvent 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’autres besoins, changent d’avis ou qu’il est nécessaire de prendre en compte de nouvelles évolutions technologiques, avant même que le projet soit livré en première version. Ces évolutions sont parfois si importantes qu’elles s’apparentent à un nouveau départ du projet. D’autres projets consistent à saisir une occasion de marché, souvent liée à la réponse à un appel d’offres dont le livrable est attendu à une date pour le moins optimiste. Quelles que soient ses motivations, le responsable de projet a intérêt à livrer dans le laps de temps le plus court. Pour réaliser un tel projet, il faut disposer des ressources convenables, ce qui est rarement 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 de ces ressources une fois le projet terminé. Quant à l’emploi local de personnel en régie, il est extrêmement coûteux. Ce sont pourtant les solutions auxquelles on a traditionnellement recours. La réalisation de projets en offshore apporte une dimension nouvelle à la gestion des projets informatiques. Avec ce mode de travail, le responsable du projet peut réduire significativement les coûts de réalisation et mettre à la disposition du projet des informaticiens qualifiés, tout en bénéficiant d’une grande flexibilité de la taille de l’équipe, tant pour 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 de socié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 prestataire en 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 fiable et font continuellement face à des problèmes de qualité ou de retard, qu’elles ne parviennent pas à surmonter. Pour bénéficier pleinement des avantages de l’offshore, il faut apprendre à travailler avec un partenaire issu d’une autre culture et oublier partiellement l’expérience acquise avec des partenaires occidentaux. Il faut en outre se montrer capable d’apporter une rigueur

1

Conduite de projets informatiques offshore

nouvelle dans les réalisations afin de structurer les procédures et les échanges. Un mode de travail satisfaisant avec des informaticiens internes est rarement transposable à des réalisations réparties. La réalisation de projets en offshore est pourtant une évolution naturelle de l’informatique. 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és trop 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 travaillent sur une échelle de coûts sans commune mesure et subissent la rigidité de leurs ressources. Le travail avec une équipe en offshore bénéficie à tous, y compris aux informaticiens du donneur d’ordres, contrairement aux idées reçues. La nature de leur travail peut certes s’en trouver modifiée, ne serait-ce que pour s’adapter aux processus industriels. Les tâches de supervision, de management et d’architecture, par exemple, y prennent plus d’importance. Lorsque les réalisations en offshore sont bien gérées, la société dégage davantage de moyens 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. Il rassemble l’expérience de plus de douze années de réalisations en offshore dans de nombreux pays et avec de multiples prestataires. L’ouvrage commence par présenter la culture du développement en offshore et insiste sur la distance qui sépare le travail en local et celui en offshore. Ces différences culturelles nécessitent une grande rigueur de la part du client de l’offshore pour suivre et piloter les ré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’outsourcing des développements en offshore, il est essentiel de comprendre les raisons de leurs inquiétudes. Ces dernières vont bien au-delà d’une simple peur de perdre leur emploi au profit d’un informaticien distant moins coûteux. Une fois les fondations de l’offshore posées, l’ouvrage accompagne le donneur d’ordres tout au long des nombreux choix qu’il doit faire, depuis la sélection d’un prestataire jusqu’à la mise en place de l’organisation qui lui permettra de travailler effi cacement avec lui, à commencer par le contrat. Vient ensuite la gestion proprement dite des projets en offshore. Certaines pratiques pré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 pratiquement incontournable lorsqu’on travaille avec des équipes distantes.

2

Avant-propos

Organisation de l’ouvrage L’ouvrage est structuré en quatre parties : Partie I. Les principes de l’outsourcing Cette partie présente les grands principes qui président à l’externalisation des développements informatiques en offshore. Elle met en lumière les différences culturelles, trop souvent 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 souvent le 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 envisager pour externaliser ses projets informatiques. • Chapitre 3. S’intéresse au facteur humain des projets offshore, tant chez le donneur d’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 de projet. • Chapitre 5. Dresse une typologie des projets qui sont confiés en offshore et souligne l’importance du premier projet pour prendre la mesure des difficultés que l’on rencontre. • Chapitre 6. Traite des risques réels ou supposés pris par le donneur d’ordres en confiant des projets en offshore et insiste sur les effets négatifs des préjugés et d’une inquiétude exagérée sur leur succès. Partie II. Préparation des projets en offshore Cette partie traite des choix que le donneur d’ordres doit effectuer pour sélectionner le prestataire en se donnant les meilleures chances de succès et pour organiser le travail avec celui-ci. • Chapitre 7. Présente les différents types de projets que l’on peut confier à un prestataire offshore et montre toute l’importance du premier projet pour que le prestataire et le client apprennent à se connaître. • Chapitre 8. Aborde les critères de choix du prestataire offshore susceptibles de répondre aux ambitions du client. • Chapitre 9. Introduit les fondations du contrat qui lie le donneur d’ordres au prestataire offshore et montre comment formaliser un cadre strict permettant de travailler avec efficacité. Partie III. Gestion des projets en offshore Cette partie traite des principes clés de la gestion de projet en offshore et propose une série de recommandations pour garantir la transparence et le suivi effi cace des développements distants. • Chapitre 10. Détaille les fondamentaux de la gestion de projet en offshore et propose plusieurs 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éussite des projets offshore, afin de garantir des échanges fluides et de créer un climat de confiance réciproque entre le client et le prestataire.

3

Conduite de projets informatiques offshore

• Chapitre 12. Présente la méthode et les procédures à mettre en place pour tout à la fois structurer le travail avec le prestataire, assurer la productivité des équipes et fournir les principales sources d’un suivi rigoureux. • Chapitre 13. Introduit la gestion de la qualité permettant de disposer non seulement d’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 indicateurs et 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 recommandations faites tout au long de l’ouvrage afin que le lecteur puisse s’en servir comme aides à la décision. Elle propose en outre des modèles de documents illustrant les thè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 qui s’intéressent à ce sujet. Les lecteurs qui n’ont pas encore d’expérience de travail avec un prestataire en offshore y trouveront des recommandations leur permettant de s’y préparer efficacement 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 de certains dysfonctionnements. Les dirigeants d’entreprise trouveront les informations leur permettant de comprendre les 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éfi nir l’organisation à mettre en place en tenant le plus grand compte de la distance qui sépare leur mode de fonctionnement courant de celui qui est nécessaire en offshore. Les managers d’équipes informatiques pourront appréhender l’organisation de leurs collaborateurs pour obtenir un fonctionnement fluide et efficace avec un prestataire distant. Ils pourront également identifier les sources des dysfonctionnements et la façon d’y remédier. Les informaticiens, qu’il s’agisse de chefs de projet, de développeurs, de testeurs, d’architectes, d’analystes ou d’intégrateurs, pourront identifi er la place que tient leur rôle dans le contexte de l’offshore et les postes à fort potentiel. S’ils travaillent déjà sur des projets offshore, ils en tireront bénéfice pour améliorer la productivité et la fluidité des opérations. Les informations fournies dans l’ouvrage leur permettront d’être plus rapidement efficaces et d’éviter certains pièges.

4

PARTIE

1

Les principes de l’outsourcing Pour 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 la taille de ses équipes à ses besoins tout en bénéficiant d’une économie importante. Cette économie doit lui permettre de saisir des occasions, dont il ne pourrait profiter autrement. Lorsqu’on commence à travailler avec une équipe en offshore, on aborde un mode de fonctionnement différent de ce dont on a l’habitude, et ce, pour deux raisons essentielles. La première est que la culture comme les lois et l’é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 demandent davantage de rigueur et de contrôle sur les réalisations. L’expérience que le client peut avoir dans son pays ne lui est que de peu d’utilité pour réussir ses projets en offshore. Cette première partie traite principalement des différences culturelles que l’on constate entre les pays de l’offshore et leurs clients des pays occidentaux dans le domaine des réalisations informatiques. Ces différences doivent être bien comprises si l’on veut profiter des avantages de l’outsourcing sans risquer de sombrer 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 au long des années et d’une recherche de la justice. Les pays de l’offshore, qui offrent des niveaux de coûts des prestations humaines beaucoup plus faibles, n’ont jamais connu une telle stabilité. On y observe des revirements violents dans 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 voie la plus facile et tirent parti des lois inexistantes, généralement inadaptées, et

Conduite de projets informatiques offshore

surtout des pratiques, qui évitent les fiscalités contraignantes. La complexité de certaines de ces économies, notamment en relation avec l’informatique et Internet, ne se traduit pas toujours par les lois qui conviennent. De toute façon, nombre de lois ne sont pas appliquées. Les différents régimes politiques en place ont en commun d’avoir délaissé le droit du travail et la protection de la propriété intellectuelle. Dans certains pays, l’économie parallèle dépasse de loin en ampleur le marché officiel. Pour toutes ces raisons, les occasions à saisir en offshore sont immenses. Les droits d’entrée sur de nombreux marchés sont très faibles. Dans les pays qui profitent d’un bon niveau d’éducation scientifique, la fourniture de prestations informatiques en offshore en fait partie. On y observe cependant tous les défauts d’un marché en formation. La disparité 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, avec des prestataires qui emploient jusqu’à dix mille personnes, la majorité des pays de l’offshore se cherchent encore. Ils ne savent pas très bien comment organiser le travail pour que leurs 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 qui peuvent mettre en péril ses réalisations distantes. En matière d’outsourcing, tous les projets ne sont pas équivalents, tant s'en faut. Savoir choisir ses projets et anticiper les problèmes est la clé du succès. La deuxième partie de l’ouvrage traite de la préparation des projets en offshore, en insistant sur le contrat qui lie le prestataire et le client. La troisième partie est consacrée au travail avec le prestataire en offshore.

6

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 sont immédiatement visibles lorsque des produits locaux sont en concurrence avec des productions délocalisées. Quel que soit le domaine, confection, automobile, fabrication, assemblage, etc., la délocalisation bouleverse en profondeur la façon dont fonctionnent ces industries. Longtemps, la pratique de la délocalisation a été considérée comme une marque de qualité 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 recherchait la qualité, on regardait la mention Made in China comme une marque de fragilité et les 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 achetant un produit fabriqué en France et utilisant une main-d’œuvre française. Certains étaient prê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és dans 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’attachent à ces réalisations distribuées. Certains sujets abordés sont détaillés dans la suite de l’ouvrage, comme les motivations de l’offshore, les façons de travailler avec des équipes en 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. Les raisons à cela ne sont guère différentes de celles qui poussent les autres secteurs de la production à délocaliser : produire plus à budget constant, voire à budget réduit, produire plus rapidement pour arriver les premiers ou au meilleur moment sur les marchés les plus profitables, 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 ordinateurs, des cartes informatiques et plus généralement de tous les matériels électroniques.

7

Conduite de projets informatiques offshore

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é et de qualité, fabriquent en grande partie leurs matériels dans les pays où la main-d’œuvre est moins chère. Dans ce domaine du matériel informatique, la concurrence est telle que les marges font l’objet d’une attention extrême à toutes les phases de fabrication, du transport et de la distribution. L’objectif est de conserver à toutes les étapes un niveau de profitabilité tel que les revendeurs finals, les fabricants et les concepteurs disposent d’un produit compétitif et d’une marge suffisante. Personne ne s’attend à trouver la mention Made in France sur un ordinateur, un modem ou une carte informatique. Tout au plus, trouve-t-on les mentions Assemblé en France sur certains matériels. On aurait même plutôt tendance à considérer qu’une fabrication locale serait de qualité inférieure, car on ne pourrait y trouver les économies d’échelle et la rigueur des procédures qui sont appliquées dans les pays qui se sont spécialisés dans ces fabrications. La fabrication de matériel informatique égratigne au passage une idée reçue voulant que la mondialisation ne touche que des domaines à faible qualification. L’informatique nécessite en effet une main-d’œuvre qualifiée dans des domaines de pointe, où l’évolution technologique est extrêmement rapide et la qualité un critère essentiel. Ceux qui pensent que les 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. Critères de comparaison La capacité à comparer directement des produits de plus en plus semblables, notamment dans le domaine du logiciel, rend le facteur prix déterminant. L’outsourcing devient dès lors le moyen d’atteindre une production aux meilleurs coûts. Des produits très différents étant difficiles à comparer, on s’attache parfois à des critères subjectifs, tels que l’esthétique. La comparaison purement financière est en ce cas peu significative. Par exemple, le caractère très particulier des automobiles Morgan fabriquées au 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 évaluation artistique 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 cartes graphiques ou les cartes-mémoires. Les différences techniques et fonctionnelles sont naturellement estimées comme justifiant la différence de coûts  ce produit ne fait pas ceci et cela mais est moins cher de tant , mais l’acheteur porte la plus grande attention aux coûts.

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

8

Chapitre 1 – La mondialisation des tâches informatiques

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 besoins des utilisateurs afin d’identifier ce qui fait vendre un produit. Les informaticiens restent encore créatifs, mais le plus souvent à un niveau technique, concernant, par exemple, les architectures logicielles, certaines procédures ou les moyens de parvenir à une meilleure qualité. Même les sujets réputés très techniques relatifs aux frameworks de développement ont tendance à se standardiser et laissent moins de place à l’inventivité des informaticiens. 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 comparables entre eux, les coûts et la réactivité constituent des éléments de comparaison essentiels dans les décisions d’achat. On peut imaginer qu’il y aura un gagnant à ces confrontations. Celui-ci pourrait par la suite devenir un standard du marché, comme Microsoft avec ses suites Office ou Adobe avec Photoshop. Les développements informatiques réalisés par les sociétés de services sont soumis aux mêmes tendances. On considère que les réalisations d’un prestataire ou d’un autre sont assez 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 de produits préexistants. Ils ne comportent le plus souvent que des évolutions technologiques — on souhaite les mêmes fonctionnalités, dont on est content, mais utilisées avec des technologies plus modernes — ou n’implémentent que des ajouts fonctionnels mineurs et des corrections d’anomalies (maintenance applicative) d’une application dont on 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 capital de 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 sujet même de l’ouvrage, l’offshore désigne la sous-traitance d’un développement informatique dans un pays éloigné. Nous soulignons explicitement les cas où le terme prend une autre signification, par exemple en cas d’externalisation locale dans le pays du donneur d’ordres. Le terme local est relatif au lieu du donneur d’ordres, que ce soit son pays ou les locaux de sa société, tandis que les termes distant, délocalisé et offshore sont employés en référence au 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 du prestataire en offshore. Le terme prestataire désigne la société en offshore qui fournit des services informatiques en offshore aux sociétés généralement situées dans les pays d’Europe de l’Ouest ou aux États-Unis. Dans quelques cas rares, nous employons le terme client pour désigner les clients du donneur d’ordres d’une façon qui sera sans équivoque pour le lecteur.

9

Conduite de projets informatiques offshore

Terminologie employée dans cet ouvrage (suite) Le terme régie s’oppose à forfait. La régie désigne une sous-traitance, le plus souvent accompagnée d’une facturation du temps passé et d’une refacturation des dépenses engagé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 organisation. Le terme forfait suppose que le prestataire s’engage sur une réalisation à un tarif défini à l’avance, sur la base d’un document formalisé qui définit les engagements du prestataire 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 dans le 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 et dépenses directement liées au salaire pour l’employeur. On trouve ainsi le salaire brut, les charges sociales, les cotisations patronales diverses et le plus souvent les cotisations à la mutuelle.

La recherche de la compétitivité Les éditeurs de logiciels, comme les sociétés de services, sont entrés dans une ère où la compétitivité de leurs services et produits est le moteur essentiel du profit. Les développements informatiques requièrent des ressources souvent importantes et emploient une main-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 pas rare que certains projets dépassent la cinquantaine d’années/homme lorsqu’on intègre les tâches en amont du développement (élaboration de la vision, spécifications et préparation du projet) et les tâches en aval (test, déploiement, performance et maintenance corrective et évolutive). Si l’on considère en première estimation qu’une année/homme de développement en France 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 offshore constaté 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 souffle pour remporter des marchés, parfois même en augmentant sa marge propre. L’économie réalisée par une société qui fait appel à l’offshore peut ne pas être totalement répercutée sur le coût des prestations facturées à son client. Elle peut, par exemple, être partagée entre une réduction du coût de la prestation pour se positionner de façon plus agressive et 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 aux ressources de l’offshore pour réaliser leurs projets. Le différentiel de coûts est tel que ces sociétés peuvent y puiser une nouvelle dynamique les rendant tout à la fois plus compétitives et plus réactives.

10

Chapitre 1 – La mondialisation des tâches informatiques

Un éditeur de logiciel consacre habituellement entre 14 et 25 % de son chiffre d’affaires aux développements de nouveaux produits. Si, par exemple, il réalise un chiffre d’affaires de 15 millions d’euros, il consacre donc entre 2 100 000 et 3 750 000 euros à ses développements. L’éditeur est le plus souvent en concurrence avec d’autres, qui visent la même cible et rivalisent de créativité et de réactivité. Celui qui délocalise ses développements en offshore en réalisant 40 % d’économie voit ses capacités pratiquement doubler. Sa capacité à réaliser davantage de produits, plus rapidement et de meilleure qualité, car avec plus de tests, lui permet de mieux se positionner sur son marché et, dans le meilleur des 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é en local, 3 500 000 à 6 250 000 euros. Sa puissance de production se situe entre 23 et 41 % de son chiffre d’affaires, alors que son investissement n’est que de 14 à 25 % de ce même chiffre d’affaires. Ces valeurs et pourcentages, évidemment considérables pour un éditeur de logiciel, montrent clairement le dynamisme de celui qui a su passer en offshore et en retirer tous les fruits.

Offshore, outsourcing, délocalisation et développements distribués La délocalisation des projets informatiques s’est tout d’abord appelée offshore par analogie avec les plates-formes pétrolières, qui sont situées loin de la rive, par opposition aux développements simplement externalisés, dits offsite. Le terme offsite désigne une externalisation locale mettant à disposition des équipes de développement en régie ou au forfait. Le terme offshore situe clairement ces équipes dans un lieu lointain. La figure 1.1 illustre le sens des termes onsite, offsite et offshore.

Figure 1.1. Onsite, offsite et offshore

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

11

Conduite de projets informatiques offshore

Contaminé par de telles images, l’offshore a été trop vite associé à des manœuvres patronales visant le seul profit des actionnaires au détriment des employés qui, d’un coup, se retrouvaient hors jeu. Nous verrons que de telles attitudes, lorsqu’elles existent, sont surtout répandues dans le monde de la fabrication et qu’elles concernent peu les projets informatiques. Nous verrons en outre comment, dans certains cas, l’offshore peut au contraire être source de création d’emplois. L’ampleur des développements confiés à l’offshore a retenu l’attention des grandes entreprises de marketing qui vendent des études de marché. Constatant la montée en puissance de 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 profi t de l’offshore. Certaines de ces études donnent des chiffres alarmants, avec 10 à 20 % du nombre total d’informaticiens européens, canadiens ou américains qui seraient perdus au profit des pays de l’offshore. Le Canada, qui est souvent considéré comme un pays d’offshore pour les États-Unis, y apparaît comme doublement perdant : en tant que client d’offshore moins compétitif que d’autres pays et en tant que donneur d’ordres, un certain nombre d’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 et au Canada, pour jeter l’anathème sur une pratique jugée « antipatriotique » et d’exercer toutes sortes de pressions pour maintenir les développements localement. À l’opposé, le CSPP (Computer Systems Policy Project), un groupe de pression et de communication amé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. Alan Greenspan lui-même, directeur de la Réserve fédérale américaine, présente ouvertement l’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 aux besoins du marché et fournir au plus vite le produit demandé par les utilisateurs (voir http://www.cspp.org/reports/ChooseToCompete.pdf). De plus, sans l’offshore, certains fleurons de l’industrie américaine seraient moins compétitifs et risqueraient de perdre leur position dominante. L’initiative pro-offshore Le Computer Systems Policy Project se fait l’avocat de l’utilisation de l’outsourcing afin de permettre à l’industrie américaine de rester compétitive, réactive et concurrentielle. Il dé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 des emplois qui serait suivie de pertes d’emplois après que les entreprises auront perdu leur position concurrentielle.

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

12

Chapitre 1 – La mondialisation des tâches informatiques

L’image d’une exploitation honteuse des ressources humaines s’est hélas peu à peu attachée au concept même d’offshore, alors même que, dans le cas de l’informatique, ces ressources offshore sont mieux considérées, mieux rémunérées et mieux gérées que lorsqu’elles travaillent pour des entreprises du pays. En dépit de la réalité, l’offshore demeure 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 parle toujours 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 des attentes, 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 offshore ou à 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 aux limites de la légalité. Ce double sens entache évidemment la perception du développement offshore en lui associant la connotation de fiscalité laxiste, voire de blanchiment d’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és par les prestataires offshore. Ces derniers offrent les meilleures expériences professionnelles, les meilleurs salaires, les meilleures conditions de travail, et ces expériences sont celles qui sont le plus mises en avant dans les curriculum vitae des candidats aux recrutements.

Curieusement, le terme offshore n’est pas toujours mieux perçu dans les pays de l’offshore. Dans ces pays, qui sont souvent émergents, et dont la fiscalité est mal définie et souvent contournée, ce mot peut avoir une connotation encore plus négative qu’en France. En effet, de nombreuses entreprises de ces pays travaillant avec l’étranger montent des sociétés dans des pays encore plus favorables fiscalement pour y capter des fonds et ne reversent à leur pays d’origine que les sommes dues aux employés, maintenant ainsi une optimisation fiscale des flux financiers. On se retrouve alors dans une situation où les deux sens du terme offshore (fiscal et pour les développements informatiques) sont mêlés, ajoutant encore à la confusion des termes. Les autorités des pays de l’offshore tentent le plus souvent d’instaurer des conditions fiscales plus favorables aux entreprises, afin que les revenus de l’offshore soient effectivement 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 soit en France ou dans les pays d’offshore, de peur de choquer ceux qui pourraient lui associer des pratiques globalement négatives ou, pire encore, le confondre avec les pratiques fiscales offshore. De nombreuses sociétés préfèrent employer des expressions telles que développements géographiquement distribués ou outsourcing. L’ennui avec ces termes de rechange est que le concept d’éloignement disparaît. On parle aussi parfois de délocalisation. Tous ces termes se rapportent en fait au même sujet et le plus souvent au même concept d’offshore.

13

Conduite de projets informatiques offshore

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 pas précisée. Dans l’esprit de beaucoup d’informaticiens, outsourcing est devenu synonyme d’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 interne qu’externe, avec des sites de développement répartis à travers le monde. Elle est souvent employé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écifi quement les développements offshore. Enfin, le terme « délocalisation » est utilisé pour signifier une volonté d’externaliser des développements locaux. Quels que soient les termes utilisés, ils renvoient le plus souvent au concept de développement offshore.

L’offshore sans perte d’emploi C’est un fait que certaines sociétés déplacent massivement leurs ressources informatiques pour créer des équipes dans des pays d’offshore. Il est évident qu’en ce cas des emplois sont perdus dans le pays d’origine de ces sociétés au profit des pays d’accueil. La plupart du temps, cependant, il s’agit moins de rechercher une délocalisation massive que de bénéficier des avantages de l’offshore sans pour autant déstabiliser les équipes informatiques locales, lesquelles fournissent des services sur lesquels on souhaite continuer de s’appuyer. Le plus souvent, les sociétés françaises recourent à l’offshore, encore assez timidement faut-il le préciser, soit pour valoriser leurs réponses aux appels d’offres, soit pour réaliser des coups, comme sortir un nouveau module rapidement, ou minimiser des développements 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 les produits assez semblables ou d’un coût plafonné, les éditeurs qui ont besoin d’optimiser leurs 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 avec l’offshore et en retire des avantages. 2. Elle constate que ce dernier emporte des contrats en réponse à des appels d’offres en parvenant à 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 et trop accaparés par les tâches courantes. 4. Elle parvient à la conclusion qu’il lui faut à son tour se tourner vers l’offshore, seul capable de lui apporter l’oxygène nécessaire pour insuffler un nouveau dynamisme dans l’entreprise. Les sociétés qui adoptent cette démarche commencent par des développements offshore au coup par coup, embauchent en France un chef de projet pour suivre le développement et parfois une équipe de recette. Les chefs de produit voient aussi parfois leur nombre augmenter pour gérer les volumes accrus de spécifi cations des produits à réaliser en

14

Chapitre 1 – La mondialisation des tâches informatiques

offshore. Dans de nombreux cas, il n’est pas envisagé de réaliser ces développements en interne 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 accroissement des ressources locales de l’entreprise, laquelle pourra s’engager dans une stratégie plus agressive, 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’accompagne souvent 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 les nouveaux projets sont conservés localement, afin d’assurer une meilleure réactivité face aux demandes des clients par une plus grande proximité avec ces derniers.

Gestion des équipes offshore Les prestations offshore peuvent prendre de nombreux visages. La plupart des entreprises qui traitent en offshore travaillent avec un prestataire situé dans un pays favorable au montage d’équipes informatiques. Dans d’autres cas, l’entreprise s’établit elle-même dans 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 en utiliser 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 de Microsoft, 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 plus souhaitable. C’est assurément celui qui laisse le plus de liberté et de flexibilité à l’entreprise cliente tout en entretenant une réelle relation de client à fournisseur. Il arrive que des sociétés créent des joint-ventures avec des partenaires offshore, à l’exemple d’IBM au Belarus, qui traite avec des sociétés dans lesquelles elle a pris des participations significatives. Ces sociétés créées en joint-venture traitent également avec d’autres clients pour proposer leurs services de développement. Lorsqu’une entreprise crée sa propre filiale ou un joint-venture dans un pays offshore, elle cherche avant tout, outre de faibles coûts de prestation, à réduire au minimum la marge du partenaire. Ce choix peut aussi être motivé par la protection d’informations confidentielles ou relevant de la propriété intellectuelle ou encore par des motifs personnels du manager 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’arrangements qui soient à leur entier avantage. Dans certains cas, l’entreprise souhaite profiter tout à 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 prestataire offshore, 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éveloppement soit transparente. Tout cela est loin d’être facile.

15

Conduite de projets informatiques offshore

Les coûts Les économies résultant de développements offshore sont réelles, mais, de l’avis des sociétés qui y recourent, c’est presque un avantage secondaire, comme nous le verrons par la suite. La plupart des entreprises qui souhaitent se lancer dans l’offshore sans en avoir compris tous les mécanismes s’arrêtent à ces considérations. On entend très souvent parler de salaires d’informaticiens dans les pays de l’offshore qui se situeraient aux alentours de 120 à 300 euros par mois. Ces salaires semblent dérisoires en comparaison de ceux des informaticiens français, supérieurs d’au moins un facteur 15. Un tel calcul est cependant faux. Dans la réalité, on s’aperçoit que les prestations informatiques offshore descendent rarement en deçà de 80 dollars par jour, soit 1 680 dollars par mois, et que les tarifs les plus courants varient selon les prestataires et les pays entre 100 et 300 dollars par jour, soit entre 2 100 et 6 300 dollars par mois, parfois plus dans certains cas rares. Les prestations offshore 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 en France, des tarifs en régie des prestataires français et de ceux des prestations réalisées en offshore. Tableau 1.1. Comparaison des prestations journalières (en euro) Salaire français (chargé)

Régie chez un prestataire français

Prestation 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

Fonction

Ce tableau est toutefois trompeur car il ne compare pas des services équivalents. En offshore, la tarification comprend le plus souvent le collaborateur, son espace de travail et son équipement (ordinateur, accès à Internet, administration des serveurs). Les tarifs de régie locaux et à l’offshore s’entendent par journée effectivement travaillée et n’incluent pas, à la différence du salaire d’un collaborateur français, les périodes de vacances, qui augmentent le coût réel de la journée travaillée. Pour être comparé sur des bases équivalentes, le salaire français devrait donc être augmenté pour tenir compte des congé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 mesurer valablement les coûts.

16

Chapitre 1 – La mondialisation des tâches informatiques

La comparaison des coûts d’un développement en offshore avec un développement national est toujours complexe, car l’une des mesures est obligatoirement une estimation, 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 la direction des entreprises. Le plus simple pour mesurer le plus justement le coût des prestations offshore par rapport 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, les services centraux redistribués sur les employés, etc. On estime ensuite la durée/homme du projet s’il avait été réalisé localement et, de façon à ne pas favoriser ce calcul pour l’offshore, on fait l’hypothèse qu’aucune difficulté ne serait venue alourdir le poids du développement en local, comme l’impossibilité de recruter à temps, par exemple. On compare 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’offshore tels qu’ils sont facturés, y compris les frais de location de bande passante Internet ou de téléphone. On parvient généralement au résultat qu’un projet correctement géré en offshore génère entre 20 et 80 % d’économies par rapport au même projet géré nationalement, avec une espérance de gain moyenne de l’ordre de 40 %.

La gestion des équipes En 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 prestataire, les réduire à volonté. La rapidité de constitution de l’équipe dépend de l’importance du prestataire offshore. Les prestataires suffisamment implantés en offshore n’ont aucune difficulté à prélever sur leurs propres personnels une équipe de base constituant environ 20 % de l’équipe finale. Les prestataires bien exposés et qui maintiennent une bonne image dans leur pays peuvent facilement trouver des candidats de qualité pour les 80 % restants. Une équipe d’une cinquantaine de personnes peut ainsi être montée en quatre à six semaines par un bon prestataire offshore, même si cette équipe comporte certains 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 prestataire local ou en offshore. Tableau 1.2. Flexibilité des équipes Critère

Coût

Embauche de l’équipe en CDI (local)

Normal (salaire en CDI)

Rapidité de constitution Difficile

Capacité à réduire l’équipe Très difficile

17

Compétence Normale à bonne

Capacité d’accueil Difficile si l’on ne dispose pas des locaux et de l’infrastructure pour recevoir le personnel.

Conduite de projets informatiques offshore

Tableau 1.2. Flexibilité des équipes(suite) Rapidité de constitution

Capacité à réduire l’équipe

Coût

Embauche de l’équipe en CDD (local)

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

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

Normal à élevé Assez difficile selon l’utilisation de la régie

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 contractuellement

Normale à bonne

Forfait (local)

Élevé

Aisé

Naturelle en fin de contrat

Le prestataire tra- Très aisée vaillant au forfait prend contractuellement tous les risques, y compris ceux liés à la mise à disposition des compétences recherchées.

Offshore

Très faible

Très facile

Très facile, prévue par le contrat

Normale à excellente

Pratiquement impossible

Compétence

Capacité d’accueil

Critère

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

Très aisée

Sans recourir à l’offshore, une société doit bien évaluer ses objectifs et les moyens dont elle dispose. Elle a le choix entre embaucher en contrat à durée déterminée, prendre du personnel en régie, décider d’externaliser le projet au forfait auprès d’un prestataire local ou gérer le développement avec un prestataire offshore. Aucune de ces solutions ne se compare 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 la prudence. La réduction des effectifs est toujours délicate et pénible, surtout si ces personnes 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 dynamisme et une réactivité impossibles à atteindre au moyen de ressources distantes.

18

Chapitre 1 – La mondialisation des tâches informatiques

Même dans le cas où l’on penserait avoir besoin de ces ressources dans la durée et où l’on déciderait de créer une équipe, la constitution d’une équipe d’une cinquantaine de personnes est difficile et prend du temps. La recherche des candidats passe souvent par la publication d’une annonce dans les médias (presse, Internet, etc.). En cas d’urgence, il faut faire appel à un recruteur. On ne peut s’attendre à trouver de premiers collaborateurs avant 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, surtout lorsqu’un recruteur est impliqué. Pendant la période de constitution de l’équipe, le projet progresse lentement. Les postes se 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 les plus importants pour le projet, pouvant rester vacants. Un candidat en recherche d’emploi qui a postulé à d’autres postes proposés par d’autres entreprises peut de surcroît se désister au tout dernier moment. Ces désistements peuvent être d’autant plus importants que la société est petite, affiche de mauvais résultats, a peu de notoriété, est située en un lieu difficile d’accès ou offre des risques d’instabilité. La régie vient naturellement compléter les embauches. Certaines entreprises misent entiè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 choisit plusieurs sociétés pour fournir le personnel demandé , et offre une flexibilité très importante pour la gestion des effectifs. Les coûts sont en revanche significativement plus élevés que ceux de l’embauche directe de personnel. L’engagement contractuel détermine le plus souvent une période minimale où l’on doit conserver le personnel en régie et s’accompagne de clauses de remplacement au cas où une personne ne conviendrait pas. Avec la régie, on paye, parfois cher, la disponibilité rapide des ressources ainsi que la flexibilité de leur gestion. Aucune solution n’offre une flexibilité, une qualité et une réactivité comparables à celles de l’offshore. Pour un prix inférieur, on peut constituer l’équipe dont on a besoin très rapidement, 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 ressources humaines. Les engagements du client de l’offshore se limitent aux accords contractuels passés avec le prestataire offshore. Les clients de l’offshore peuvent ainsi bénéficier de l’avantage cumulé de ressources dédiées et d’une grande liberté quant aux ajustements de ces ressources. Les sociétés impliquées dans les développements souhaitent naviguer au plus près de leurs besoins, en maintenant une gestion rigoureuse de leurs engagements et de leurs dépenses. Elles veulent pouvoir conserver toute latitude d’action afin de réagir à des situations nouvelles, telles que changement de climat économique, annulation ou réduction de contrats. Les licenciements sont des actions toujours délicates, tant par les coûts qui les accompagnent que par les conséquences sociales et humaines. Les coûts peuvent être très importants, surtout s’ils ne découlent pas d’un motif économique ou s’ils donnent lieu à des

19

Conduite de projets informatiques offshore

conflits sociaux ou à une mauvaise ambiance persistante dans l’entreprise. Ces coûts vont bien au-delà des indemnités légales. Bien souvent, le préavis n’est pas effectué, les conditions 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 nouvel emploi. La flexibilité ne concerne pas que la gestion des ressources humaines. Savoir gérer des changements importants peut devenir une question de survie pour certaines sociétés de services ou des éditeurs de logiciels. Par exemple, une société de services peut voir un de ses projets abandonné par un client ou considérablement réduit. Même si le contrat définit des clauses de dédommagement en cas de dédit, ces derniers sont souvent loin de couvrir les dépenses d’arrêt du projet. Si la société ne dispose pas d’un autre contrat pour y 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 augmentation ou en réduction.

Un éditeur est lui aussi soumis à des nécessités de réaction rapide. Il lui arrive de modifier sa stratégie en cours d’année pour l’adapter aux nouvelles conditions du marché. Il se peut que les résultats ne soient pas aussi bons qu’espérés et que des projets soient abandonnés. Il se peut aussi que des développements liés à des engagements pour un client spécifique ne soient plus nécessaires du fait que le client s’est désengagé et ne souhaite plus acheter le produit de l’éditeur. Dans tous ces cas, seule une grande flexibilité des équipes permet de s’adapter aux conditions nouvelles et aux changements de l’environnement afin d’adapter la stratégie et de ne pas manquer les occasions qui se présentent.

La qualité des ressources Les bons prestataires des pays de l’offshore peuvent attirer les meilleures ressources locales. 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 profils des salaires et des conditions de travail bien meilleurs que n’importe quel autre type d’entreprise locale. La qualité du prestataire offshore importe ici beaucoup. Les plus petits, qui n’ont pas de réputation locale, peuvent avoir du mal à trouver les candidats recherchés. Les très gros prestataires adoptent quant à eux souvent un mode « optimisé » de gestion de leurs ressources 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 de projets « tournent » sur plusieurs projets. Le client de l’offshore ne dispose alors pas d’un excellent 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 prestataires ayant établi une excellente réputation locale deviennent assez vite des références, qui attirent les meilleurs profils du pays.

20

Chapitre 1 – La mondialisation des tâches informatiques

Certaines universités locales, comme le Belarusian State University, au Belarus, ou l’Institut Polytechnique de Bucarest, en Roumanie, sont fort réputées et rayonnent dans toute 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’image des grandes écoles françaises, cette réputation ne traverse toutefois pas bien les frontières, et ces universités de l’offshore nous sont généralement inconnues. Il est amusant de constater qu’aux États-Unis comme dans les pays de l’Est, la Sorbonne est considérée comme 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 peuvent disposer d’excellentes équipes et d’informaticiens de tout premier rang.

En choisissant correctement son prestataire offshore, il n’est pas difficile d’attirer les meilleurs profils sur un projet. Aucun profil technique n’est inaccessible. Les compé tences en matière de technologie récente sont courantes, et l’on constate une réelle expérience dans ces domaines. Les seules ressources difficiles à trouver en offshore sont les bons managers de niveau middle management et les équipes de test, mais n’est-ce pas non plus très souvent le cas en France ?

Les processus structurés Pour travailler efficacement avec une équipe distante, il est nécessaire de mettre en place une structuration stricte des procédures, notamment de recette, ainsi que des flux de travail, ou workflows, bien définis. Certains prestataires offshore souhaiteront appliquer leurs méthodes , mais d’autres sauront parfaitement se plier à des procédures standards, telles que le RUP (Rational Unified Process) ou XP (eXtreme Programming). Un processus bien mené offre une excellente vision de la progression du projet en même temps qu’une garantie de succès. Les enseignements tirés de tels processus pour la gestion de projet ont parfois une portée qui dépasse le projet géré en offshore. Un retour d’expérience peut dans de tels cas bénéficier aux développements internes de l’entreprise cliente 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 est essentiel de mettre en place des procédures de recette bien cadrées afin de travailler efficacement avec les équipes distantes et d’apprécier fidèlement le niveau de qualité des dé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êtatests. Les premiers clients utilisateurs du produit jouent alors un rôle important pour déboguer et recetter le produit, voire assurer la totalité de cette recette. Les tests peuvent

21

Conduite de projets informatiques offshore

cependant être automatisés au moyen de robots afin d’assurer un meilleur niveau de qualité 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 la fiabilité des livrables.

Si les équipes de test sont souvent difficiles à constituer dans les pays clients, et notamment en France, c’est parce que ces postes sont peu attrayants et que les tâches correspondantes 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 en offshore 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’on rencontre rarement dans les pays des clients, que ce soit en raison de leur coût ou de la difficulté à trouver les ressources adéquates.

Attribution de rôles aux personnes Grâce à l’offshore, on peut envisager d’attribuer des rôles à des personnes, comme le conseil technique, afin de s’assurer de la bonne utilisation du framework technique. On peut même se permettre de dédier la totalité du temps d’une personne à ces rôles afin qu’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élaissera pas au profit d’autres responsabilités. Ces rôles correspondent souvent à des tâches habituellement réparties sur plusieurs membres des équipes locales. Par exemple, le respect des guidelines, c’est-à-dire des règles de création d’artefacts, comme les règles de codage, de modélisation ou d’écriture de cas d’utilisation, et celui des procédures sont souvent de la responsabilité de chaque créateur des documents ou artefacts, alors que ces derniers doivent assurer ce rôle en plus de leur responsabilité principale. Le respect des guidelines et des procédures est le plus souvent perçu comme d’un niveau de priorité faible par rapport à la production des artefacts eux-mêmes, même si l’on répète bien souvent que ces procédures et guidelines doivent impérativement être respecté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 par tous. 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’un architecte technique, d’un intégrateur, de testeurs, de développeurs de programmes de tests, 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 positions sont indispensables pour sécuriser les réalisations et, d’autre part, parce c’est abordable financièrement. Le fait d’assigner un poste à temps plein à la bonne application des méthodes et procédures et à leur mise à jour en continu garantit un travail structuré, transparent et contrôlable.

22

Chapitre 1 – La mondialisation des tâches informatiques

L’un des premiers rôles généralement désignés est le responsable procédures, qui a pour mission d’assurer que les procédures sont effectivement en place, suffisamment précises et correctement appliquées. Une de ses missions est d’analyser dans la durée les besoins d’é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, cette responsabilité se trouvant répartie entre plusieurs chefs de projet. Il apporte pourtant un grand confort dans le traitement de tout nouveau développement ou changement. Il repère en outre les relations avec les composants existants et sait identifier les design patterns, 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 fonctionnels des développements techniques et fournir aux développeurs fonctionnels ce dont ils ont besoin pour travailler efficacement. Il peut aussi travailler avec les équipes de test pour réaliser des tests de performance ou de charge significatifs. Toute évolution des couches techniques peut être immédiatement traitée par l’architecte technique, qui est à même d’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, en garantit la bonne application.

Conclusion Les motivations incitant à travailler avec un prestataire offshore peuvent grandement varier selon les projets et les sociétés. Les sociétés qui pratiquent les développements en offshore 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étences des ressources que l’on trouve dans ces pays. Les plus petites se préoccupent davantage des coûts. Toutes recherchent la qualité des livraisons. Quel que soit le poids respectif que l’on accorde à chacun des avantages de l’offshore, on recherche toujours un mélange de ceux-ci. On veut réaliser plus, plus rapidement, avec plus de qualité, un meilleur contrôle, une meilleure visibilité pour le même prix ou même pour moins cher. Pour ambitieux qu’ils soient, de tels objectifs peuvent être atteints, à condition de travailler efficacement avec l’offshore. Le but de cet ouvrage est de montrer comment y parvenir.

23

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érales suivantes : • Onsite. Sur place, au sein de la société, avec des ressources propres ou externes en ré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 Onsite

Onsite (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 rapidement une équipe

–

+

+

++

++

Capacité à réduire les effectifs

–

+

+

++

++

25

Conduite de projets informatiques offshore

Nous supposons dans ce tableau que le prestataire offshore ou nearshore agit en mode régie. Les compétences nécessaires à la réussite d’un projet en offshore dépendent du mode 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 le contrôle total du projet et des ressources en offshore, les compétences en gestion de projet deviennent primordiales pour réussir le projet. Le client de l’offshore pourra tout de même s’appuyer sur les compétences en gestion de projet mises en place chez l e prestataire offshore. Nous montrons dans ce chapitre comment la société qui confie ses projets en offshore peut atteindre ses objectifs de flexibilité, de coûts et de garantie de succès. Nous étudions pour cela les divers chemins qu’elle peut emprunter et montrons que nous disposons de la possibilité de travailler en nearshore, ce qui permet d’atteindre pratiquement tous les objectifs 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 que partiellement utile pour éviter les nombreux pièges que l’on rencontre en travaillant avec les pays de l’offshore. Les difficultés abordées succinctement dans ce chapitre sont pour la plupart reprises dans les chapitres suivants afin d’en détailler les remèdes possibles. Il importe 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 avec lequel on décide de travailler. Le choix du pays de l’offshore définit donc en grande partie la nature des difficultés rencontrées. Un pays proche et sûr permet de se rendre périodiquement chez le prestataire et de réduire, par ces contacts réguliers, la distance culturelle entre les équipes.

Les développements onsite Une société qui souhaite réaliser des développements se dote des équipes qui permettent de les réaliser. C’est le plus simple et le plus naturel. Ses besoins en ressources complémentaires peuvent être plus ou moins importants, mais il est généralement possible d’anticiper une certaine quantité de développements afin d’assurer la maintenance corrective et évolutive à tout moment une fois le projet terminé. La maintenance des 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 assez précis du volume de développement nécessaire et permet d’estimer le nombre minimal de ressources. Comme nous l’avons vu au chapitre précédent, les ressources onsite recrutées posent des difficultés importantes si nous souhaitons conserver une grande liberté, que ce soit pour réduire les investissements en R&D ou pour les faire croître très rapidement. Les ressources embauchées agissent comme un filtre « passe-bas ». Elles ne laissent passer que les mouvements de basse fréquence. Autrement dit, les décisions vives, par lesquelles nous souhaitons constituer des équipes rapidement pour, peut-être, les réduire avec la même rapidité plus tard, sont impossibles à réaliser avec des équipes recrutées.

26

Chapitre 2 – Les chemins de l’offshore

Certaines sociétés considèrent que la valeur de leur entreprise se situe en partie dans les ressources dont elles disposent pour réaliser leurs projets, notamment pour les sujets qui sont au cœur de leur activité. Les développements qui sont considérés comme primordiaux (mission critical) sont souvent conservés en interne en vue d’une meilleure chance de succè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’un développement se situe au sein de l’entreprise. Si le projet réussit, l’équipe de R&D au sens 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é, le succès est le résultat complexe d’un ajustement continu dans le temps, où des rôles polymorphes 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 sur le domaine fonctionnel concerné, parviennent à jouer un rôle mixte de chef de produit, de chef de projet, de responsable des tests et même de décisionnaire final, assurant le succè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 en tirer de reconnaissance. L’équipe R&D est également responsable des échecs des projets. Certains collaborateurs sont 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 organisationnelle qui garantissaient le succès. Ces responsabilités, parfois imprécises, qui se révèlent surtout par le vide soudainement créé, rendent les remplacements encore plus délicats. Pour pallier cette dépendance aux circonstances, il est nécessaire d’apporter davantage de rigueur aux procédures et de s’assurer que le fonctionnement s’appuie non pas 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 management s’attache parfois à certains informaticiens parce qu’ils sont de bons compagnons et qu’ils créent un sain esprit d’équipe. Il y a aussi ceux qui sont là depuis toujours, qui ont participé aux premières heures de la société et dont on se souvient parce qu’ils avaient très bien réagi dans des périodes de crise. La façon de gérer le personnel embauché est le 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 émotionnelles conduisent à souhaiter conserver la majeure partie des effectifs. Pour toutes ces raisons, la flexibilité des équipes sur site est difficile à assurer, que ce soit pour 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é. Certaines personnes jouent parfois des rôles multiples et incontournables et contribuent directement au succès des développements. Les processus de décision concernant ces équipes impliquent une part émotionnelle importante, qui l’emporte souvent sur les raisonnements financiers.

27

Conduite de projets informatiques offshore

Le personnel en régie L’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 les rô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 fonctionnels du projet. La régie permet d’atteindre l’objectif de flexibilité des équipes, qui est si cher aux sociétés dynamiques.

Coût de la régie Le personnel en régie engendre un surcoût d’environ 50 %. Les tarifs d’un développeur se situent rarement en deçà de 300 euros par jour et atteignent parfois 800 euros par jour pour les profils les plus expérimentés. Au finale, non seulement les développements reviennent plus cher, mais il faut aussi fournir les ordinateurs et l’espace de travail pour le personnel en 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 souvent qu’après plusieurs mois la société qui utilise des ressources en régie oublie ses objectifs de flexibilité ou les difficultés rencontrées pour embaucher et qui lui avaient fait choisir la régie. Les surcoûts du personnel en régie deviennent lourds par rapport au coût du personnel 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 ressources en 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.

La flexibilité obtenue par le recours à du personnel en régie se paye cher, à la fois en surcoût de salaire, en formation et en intégration. Les équipes internes risquent de surcroî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ès leur départ, tout particulièrement lorsque la société s’appuie sur leurs compétences fonctionnelles ou de gestion de projet. Il est rare que ces mêmes personnes soient disponibles pour une mission future. Dans la majorité des cas, le management du projet reste dans la société cliente. Même si un chef de projet provient de l’extérieur en régie pour une durée limitée, il est le plus souvent prévu que la gestion du projet est transférée à un collaborateur local, de façon que la compétence tant technique que fonctionnelle reste à l’intérieur de la société. La société cliente maintient de la sorte toute sa propriété intellectuelle à l’intérieur de ses locaux. 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 se paye cher. Le personnel en régie doit être accueilli dans les locaux de l’entreprise comme le personnel embauché.

28

Chapitre 2 – Les chemins de l’offshore

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 sont effectué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 quotidienne est transférée au prestataire offsite. La société cliente atteint parfaitement ses objectifs de flexibilité et n’a pas besoin de fortes compétences en interne pour gérer le projet, une fois 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 plus souvent ses ressources ou utilise des compléments de ressources en régie. Il impute de surcroît une marge additionnelle sur sa facturation afin de se protéger des aléas du projet. Projets offsite et forfait Tous les projets ne s’adaptent pas bien au forfait. Plus le projet est long et complexe, et plus il est difficile à définir au moment de la signature du contrat avec le prestataire. Les projets au forfait conviennent assez bien aux petits projets bien définis et aux projets stables par nature, comme ceux consistant en l’implémentation de principes mathématiques ou les convertisseurs de formats de fichiers. Le forfait est peu efficace pour les projets longs et complexes, dont le contenu doit être révisé au cours de la réalisation. Selon la façon dont le projet est géré par la société de services, des effets néfastes peuvent nuire au projet, au client et à la société de services, voire, dans certains cas, mener à l’arrêt du projet.

L’utilisation de projets au forfait est souvent perçue comme une garantie de réussite pour un prix fixé d’avance. Comme expliqué précédemment, la gestion au forfait ne s’applique pas à tous les projets, et la garantie de satisfaction des utilisateurs finals du produit développé 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 engagements envers 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 en offshore.

Les développements offshore et nearshore Les développements offshore et nearshore sont similaires, la seule différence résidant dans la distance entre la société cliente et le prestataire de services en offshore. Le nearshore recourt à une équipe de développement assez proche géographiquement, dépassant rarement 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’il n’est pas rare d’injecter une part de forfait afin de donner à certaines réalisations un cadre

29

Conduite de projets informatiques offshore

à la fois pour le contenu et le prix des réalisations, même si ce cadrage est partiel, puisque le reste du projet est réalisé en régie. Dans le forfait pur avec une équipe en offshore, la distance importe peu, car le projet est entièrement défini au moment de la signature du contrat. Les échanges sont par conséquent moins fréquents et moins intenses que dans le 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 recouvrement horaire. En France, la possibilité de travailler en régie avec le nearshore est tellement efficace que le forfait ne se rencontre pratiquement jamais. Pour peu que l’on prenne soin de bien choisir son prestataire, le nearshore en régie permet 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 tous les 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 en conservant un contrôle précis des actions de l’équipe distante. L’accord contractuel dé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, dans certains 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 est essentielle au succès ses projets en offshore.

Éloignement des équipes La distance modifie fortement les façons de travailler. Que les équipes de développement soient éloignées de quelques kilomètres seulement ou de 5 000 kilomètres, un grand nombre de problèmes doivent être résolus pour travailler efficacement. Les problèmes qui proviennent de l’éloignement sont essentiellement résolus par les procédures mises en place et la formalisation des documents échangés. Cela paraît simple. Pourtant, la mise en place de procédures formalisées fait le plus souvent apparaître des défauts dans l’organisation interne de la société cliente, avec des rôles pas clairement 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 parfois qui décide, notamment lorsque les procédures concernent deux équipes distinctes de la société, qui sont gérées par deux directeurs, par exemple, la direction marketing, qui gère les 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 en place des procédures adaptées. Ces dernières doivent prendre en compte la culture de l’entreprise cliente et celle du prestataire, ainsi que la taille du projet et le personnel en place. Dans le mode au forfait, le client de l’offshore n’a pas vraiment de contrôle sur les procédures mises en place, lesquelles sont sous l’entière responsabilité du prestataire de services en offshore. Le mode en régie est de loin préférable si l’on souhaite contraindre le 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ées avec 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 limitations apportées à leurs responsabilités. La mise en place de procédures avec une équipe

30

Chapitre 2 – Les chemins de l’offshore

en offshore est beaucoup plus difficile qu’avec une équipe locale (voir la troisième partie de cet ouvrage). Pour y parvenir, il ne faut mettre en place que les procédures, outils et documents réellement utiles et qui doivent être utilisés immédiatement. Toutes les erreurs sur les mises en place de ces artefacts (procédures mal conçues, contradictions, lourdeur exagérée de certaines procédures) conduisent immédiatement à des dysfonctionnements . Il est fortement recommandé de s’appuyer sur des méthodes qui ont fait leurs preuves et qui sont pleinement documentées, comme le RUP (Rational Unified Process) ou XP (eXtreme Programming). Ces méthodes sont toutefois lourdes et difficiles à mettre en place. Pour ne pas ralentir la progression du projet par l’installation d’un cadre méthodologique, on pourra ne mettre en place que ce dont on a besoin au fur et à mesure de l’apparition de l’utilité de ces procédures, ce qui demande une bonne maîtrise et une bonne compréhension de la gestion du développement de logiciels. En revanche, il est né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, auxquelles ils ont parfois donné un nom. Ils considèrent que ces procédures leur apportent un avantage concurrentiel. Cela peut être vrai pour les développements au forfait, mais c’est assurément un frein pour les développements en régie, où l’on souhaite fondre développements distribués et internes. La maîtrise des méthodes standards du marché par un prestataire offshore peut être considérée comme un atout par rapport à des prestataires qui n’ont jamais utilisé de méthode formelle. L’éloignement accroît la difficulté à synchroniser efficacement les développements locaux et distants. Il se trouve assez souvent que la société locale conserve en interne les parties centrales du développement et ne confie à l’offshore que les parties complémentaires ou périphériques. Les développements doivent en ce cas s’intégrer correctement, alors même que les différentes parties du programme évoluent indépendamment. Les problèmes éventuels se résolvent par la mise en place de procédures strictes. Pour être efficaces, elles doivent être correctement appliquées à la fois chez les équipes françaises et en offshore. Les appliquer uniquement aux équipes en offshore ne serait qu’une demimesure. Il faut le plus souvent partager les outils et procédures les plus importants entre les équipes. EN RÉSUMÉ L’éloignement modifie la gestion de projet

Quand le prestataire de services est distant et travaille en mode régie, la gestion de projet et les procédures doivent être rigoureuses et réellement applicables pour réussir les projets. Il faut en outre que les rôles soient clairement définis et que l’organisation soit comprise et efficace.

La langue de travail Si certaines équipes en offshore utilisent le français comme langue de travail, notamment dans le Maghreb, en Roumanie, au Vietnam et à l’Île Maurice, la quasi-totalité des pays qui offrent des prestations offshore utilisent l’anglais. La majeure partie des prestations en offshore 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 langue natale est une difficulté. Il ne faut pas croire pour autant que les anglophones travaillent mieux avec les équipes offshore, car ils rencontrent un autre problème, aux effets beaucoup plus pervers. Américains et Anglais utilisent un vocabulaire plus complexe que les

31

Conduite de projets informatiques offshore

étrangers, avec des tournures idiomatiques, des postpositions qui changent le sens des mots, 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 ne demande pas toujours de répéter, espérant rattraper le sens qui lui a échappé dans la suite de la conversation. Au téléphone, c’est évidemment encore plus difficile. C’est là une difficulté bien connue des Américains qui travaillent avec l’Inde, par exemple. On la rencontre 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 pas parler anglais, bien qu’elles en soient capables. L’anglais nécessaire et suffisant pour travailler en offshore est pourtant rudimentaire. Il faut être capable de se faire bien comprendre par écrit et assez bien à l’oral. Un interlocuteur en offshore qui ne comprend pas l’anglais d’un Français ne va pas hésiter à dire qu’il n’a pas compris. Il sait que c’est difficile 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 phrases employées de part et d’autre sont d’un niveau plus simple. Les tournures idiomatiques et les faux amis, même parmi les plus courants, sont naturellement évités, puisqu’on n’est pas certain de ne pas se tromper. La diction est en outre plus lente, et on vérifie le plus souvent 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 la communication. Le vocabulaire est simple, les tournures de phrase légères et le sens des échanges univoque.

La communication écrite se trouve souvent facilitée par les très nombreux outils de traduction disponibles en ligne ou sur PC. Il est de la sorte possible de rechercher des synonymes, de vérifier le sens d’un terme ou d’en choisir un meilleur ou de corriger un texte à l’aide des correcteurs orthographiques et grammaticaux de traitements de texte tels 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 est parfois étonné de rencontrer un chef de projet en offshore qui a envoyé de nombreux messages 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 conversations téléphoniques ne laissant pas de traces, on leur préfère les messageries instantanées, telles que Windows Messenger, MSN Messenger ou ICQ, qui sont très efficaces pour régler en temps réel les problèmes ou transférer certains messages vers d’autres personnes concernées. Avec ces messageries instantanées, tous les utilitaires permettant de traduire, rechercher des synonymes ou détecter les fautes d’orthographe peuvent être activés. La langue de travail du projet doit être l’unique langue d’échange d’information sur le projet. Il est fortement recommandé d’interdire la langue locale dans toutes les conversations 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,

32

Chapitre 2 – Les chemins de l’offshore

par exemple, les messages et notes relatives à la gestion du projet devraient toutes être ré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 la langue de travail du projet ou lorsqu’un collaborateur de l’offshore se rend chez le client local. Le plus gros problème de langue que l’on constate est le refus de certains membres d’équipes locales au rôle incontournable dans les opérations en offshore de parler anglais. On peut découvrir derrière cette attitude des blocages psychologiques, voire une façon détournée de refuser l’offshore. Du côté des équipes offshore, on rencontre des niveaux d’anglais très disparates. Certaines personnes écrivent bien en anglais mais le parlent très mal. D’autres ont un accent incompréhensible ou un débit ultrarapide. Il est possible d’exiger du presta taire en offshore un niveau minimal d’anglais au sein de l’équipe qu’il met en pl ace. Des cours d’anglais peuvent être organisés, assortis de tests de niveau, comme le propose sur In ternet BrainBench (www.brainbench.com), qui délivre en outre des certificats d’aptitude. Le contrat liant le prestataire en offshore et son client peut prévoir un niveau défini par le nombre de points obtenus aux tests de BrainBench. Nous ne parlons ici que de la langue de travail pour la gestion du projet et non des corpus de documents produits, tels les spécifications ou les manuels utilisateur. Même si la langue de travail est l’anglais, il est possible de fournir au prestataire en offshore des spécifications en français, un programme à réécrire dont tous les commentaires sont en français, des documents méthodologiques ou des manuels utilisateur en français. Le prestataire en offshore sera presque toujours en mesure d’embaucher des personnes parlant français afin d’exploiter sans difficulté ces documents. En revanche, il ne faut pas espérer le voir produire des documents en français avec un niveau de qualité suffisant. Ce peut être alors le bon moment pour la société française d’opter pour l’anglais comme langue de travail afin de s’assurer un meilleur potentiel de croissance externe à l’international 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 équipes embauchées de se perfectionner afin de communiquer efficacement.

Les différences culturelles Les difficultés culturelles sont d’un tout autre ordre et posent de sérieux problèmes dans le temps, car elles sont souvent ignorées ou cachées. Les problèmes culturels sont sournois et 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é (du prestataire 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 client et celui de l’offshore. Dans certains cas, des collaborateurs en offshore affichent une attitude obséquieuse, ne voulant contredire en rien ce que le client demande. Dans d’autres cas, c’est l’inverse. Il n’est pas rare de rencontrer des collaborateurs en offshore qui, au nom d’un vif sentiment patriotique en réponse à une attitude jugée méprisante de certains clients, développent une posture d’opposition systématique à l’égard de ces clients.

33

Conduite de projets informatiques offshore

Il est vrai que le client fait parfois montre d’un sentiment de supériorité injustifiable et agit comme si les équipes offshore étaient « inférieures », ne comprenant rien et devant se contenter d’exécuter à la lettre les directives. Lorsqu’une telle attitude est partagée par les collaborateurs en offshore, on se doute que les relations sont vite tendues avant de se dégrader totalement. Les réactions à adopter face à un prestataire offshore doivent être très différentes de celles que l’on peut avoir avec une société de services locale. En offshore, si des erreurs sont commises et qu’on en fait le reproche au prestataire, cela peut générer une réaction de défi. Certaines personnes vont placer un point d’honneur à démontrer que ce n’est pas entièrement de leur faute ou que c’est facilement explicable. J’ai personnellement rencontré un manager d’une équipe offshore d’un pays dont je tairai le nom qui avait arrê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 une faiblesse, voire comme une faute, le fait de dire qu’ils n’ont pas compris ou de demander des informations complémentaires. En Asie, une attitude largement répandue consiste à ne jamais dire non, ce qui oblige l’interlocuteur à une gymnastique particulière pour poser les questions dans le bon sens. Par exemple, la réponse à la question « avez-vous tout ce qu’il vous faut pour travailler efficacement ? » est toujours « oui ». Il suffit souvent de formuler la question autrement, par exemple « avez-vous besoin de plus d’informations pour travailler efficacement ? », pour engager la discussion et se rendre compte du vaste champ d’interrogations en suspens. Les résultats inattendus des différences culturelles Plus l’éloignement culturel est important et plus les surprises qui en découlent peuvent être graves. Il est essentiel de conserver un esprit ouvert pour traiter ces surprises culturelles.

Dans certains pays, les problèmes culturels et religieux peuvent être insurmontables. Par exemple, monter une équipe au Liban en employant des musulmans et des israélites est l’assurance de conflits plus ou moins ouverts et de tensions régulières. J’ai moi-même gé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 ou le 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 étant peu développé et les occasions commerciales attirant essentiellement des hommes d’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 client français de se faire reconnaître comme un manager ou technicien compétent. Même si les collaborateurs offshore sont parmi les plus éduqués et les moins xénophobes du pays, ils feront montre de méfiance à l’égard des capacités et de la compétence de ces personnes typées. L’équipe offshore fera toutefois de son mieux pour travailler efficacement avec un tel chef de projet et dépasser ces préjugés. Les événements politiques internationaux ont parfois une résonance forte dans les pays de l’offshore, et la politique internationale de pays comme la France ou les États-unis

34

Chapitre 2 – Les chemins de l’offshore

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

Comprendre les mentalités Il est important de comprendre comment les collaborateurs avec lesquels on travaille pensent et quels sont leurs objectifs. Contrairement à une idée répandue, rares sont les développeurs de l’offshore à désirer émigrer vers les États-unis ou l’Europe de l’Ouest. La majorité d’entre eux aiment vivre entourés de leurs proches et n’aspirent pas à quitter leur famille. Ils souhaitent se marier et avoir des enfants qui grandiront près de leurs grandsparents, tout en leur apportant un niveau de vie agréable. Les États-unis ont à plusieurs reprises ouvert leurs frontières aux immigrants qualifiés dans 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 pays est globalement fausse. Ce que recherche avant tout la majorité d’entre eux c’est la stabilité de l’emploi, la régularité des paiements et un salaire leur permettant d’envisager un emprunt pour acheter un logement. Dans ces pays, les postes d’informaticiens sont presque toujours précaires. Lorsqu’un projet se termine, le prestataire se sépare le plus souvent immédiatement de ses collaborateurs. La stabilité est donc un facteur essentiel de satisfaction pour les collaborateurs en offshore. Le sujet des motivations humaines est traité plus en profondeur au chapitre 3.

Gérer les projets Comme expliqué au chapitre 1, les collaborateurs en offshore ont rarement de fortes compétences en matière de gestion de projet. On trouve certes des personnes qui ont déjà managé des projets avec des sociétés occidentales, mais, le plus souvent, les principes mêmes de la gestion de projet sont peu maîtrisés. Ceux qui ont parfois accompli des tâches précises de suivi des équipes ou d’avancement des projets ont rarement acquis une vision d’ensemble du projet et n’ont pas eu à prendre de décisions pour corriger les dysfonctionnements éventuels. Face à un nouveau projet, leur capacité à le gérer et à cré er les procédures adéquates est donc généralement faible. Les compétences en matière de management des ressources humaines sont également faibles. Il n’est pas rare de trouver des managers en offshore qui pensent innover en suggérant de mettre en place des techniques de management abandonnées depuis longtemps 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, quels qu’en soient les domaines. Même lorsqu’on se trouve en face d’une personne qui a acquis une certaine expérience, il convient de demeurer vigilant, car elle peut atteindre rapidement ses limites. Tout peut alors arriver. Mon expérience m’a convaincu, à quelques rares exceptions près, qu’il était préférable que le client de l’offshore prenne en charge la totalité du management d’un projet. Une fois que ce client sera en mesure d’apprécier à sa juste valeur les compétences du management local, il pourra décider de déléguer certains domaines de management, non sans accompagner ces responsabilités du reporting ad hoc.

35

Conduite de projets informatiques offshore

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éralement très rares. Mieux vaut s’entourer des compétences de ses propres collaborateurs si l’on veut garantir le succès de ses projets en offshore.

ÉTUDE DE CAS Un manager faisant illusion Une société française, éditrice de logiciels, dispose d’une équipe de développement d’une quinzaine 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 quasiment nulle, 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é, qui lui présente un chef de projet expérimenté. Dès les premiers contacts avec ce dernier, la société est impressionnée par son professionnalisme. Le chef de projet leur déclare qu’il ne peut travailler sans formalisation et qu’il souhaite apporter plus de rigueur dans les procédures. Il leur explique comment procéder, quels documents créer et comment les rédiger. L’éditeur français suit ces recommandations et fait l’effort de créer tant bien que mal les documents demandés, avec description des architectures, guides de codage, etc. Les questions du chef de projet sont d’abord des plus pertinentes, par exemple : « Comment allezvous valider nos livraisons et avec quels délais ? » Mais les choses ne tardent pas à se gâter. Les livraisons sont en retard, les sujets mal compris s’étendent, et l’incompréhension s’installe entre la France et le prestataire en offshore. Au bout d’un certain temps, l’éditeur de logiciels se rend compte que le chef de projet ne prend pas même la peine de lire les documents sur les spécifications 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 % de retard. 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ébut de projet mais n’a pas su s’adapter pour gérer son équipe, ni exploiter les documents qu’il a lui-même demandés. Un management direct de l’équipe par le client aurait certainement immédiatement détecté cet état de fait et aurait probablement été en mesure de prendre les décisions opportunes.

Le syndrome du poulet bien gras L’attitude du management de la société cliente de l’offshore est déterminante pour la réussite d’un projet. Il n’est pas rare de voir un membre du comité de direction qui n’est pas impliqué dans le développement s’inquiéter des marges que réalise le prestataire offshore. Cette personne, qui peut être le directeur général de la société, le directeur financier ou un responsable de business unit, considère volontiers que les responsables n’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 prestataire en offshore, lequel réalise, on en est certain, des marges abusives. Ce sentiment peut provenir de plusieurs sources. Des managers parlent de l’offshore avec des amis qui gèrent aussi des activités en offshore et échangent chiffres et opinions sur

36

Chapitre 2 – Les chemins de l’offshore

les prestations. Par exemple, l’un dit qu’il paye ses collaborateurs en offshore entre 400 et 600 dollars par mois, ce qui semble très peu à l’autre, dont la société débourse 2 000 dollars par mois pour chaque collaborateur. Nous verrons au chapitre 3 que ces différences s’expliquent très bien et que nous ne faisons là que comparer des services incomparables. L’impression de se faire avoir est parfois si bien ancrée que le manager franç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 ou américaines qui ont été tout bonnement flouées par un prestataire indélicat. Ceux-là ont tendance à mettre en place un suivi draconien au détriment de la productivité. D’autres encore partent du principe que la différence de niveau de vie entre les pays de l’offshore et 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 maladivement que toute action du prestataire a un objectif caché. Quelles que soient les raisons, le sentiment irrationnel de se faire rouler peut l’emporter sur la 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 prestations. On oublie alors que le prix pratiqué est certainement comparable à celui des autres prestataires 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. Certains d’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 salaires facturés. Si les vérifications entreprises par ces managers ne donnent rien, ils demeurent persuadé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éfiance exacerbé soit entretenu artificiellement entre le prestataire offshore et son client ne peut que 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 considé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 à la collaboration 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 lesquelles ces pays peuvent fournir des prestations de services informatiques de qualité. Nous y revenons beaucoup plus en détail dans la deuxième partie de l’ouvrage afin de guider le lecteur dans les critères de choix d’un prestataire offshore.

37

Conduite de projets informatiques offshore

Des salaires faibles Tous les pays qui offrent aux informaticiens des salaires faibles en comparaison de ceux du pays du client sont potentiellement candidats à la fourniture de prestations informatiques en offshore. Dans certains pays, les salaires mensuels bruts des informaticiens les moins bien payés sont de l’ordre de 100 dollars par mois. Les salaires élevés se limitent gé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’entre eux, on trouve un très large spectre de salaires dans une même équipe, avec des développeurs débutants payés 100 dollars et d’autres qui atteignent 1 500 dollars, voire davantage. C’est le cas de la plupart des pays de l’Est. Dans d’autres pays, notamment en Asie, on constate un resserrement entre 300 et 600 dollars au maximum. Même des pays où les salaires ne sont qu’un petit peu plus faibles que ceux du pays du client constituent 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 pour les 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 dans le 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 qui s’y attachent. Ce sujet est abordé en détail au chapitre 8. On peut raisonnablement estimer que les prestations en offshore sont facturées en moyenne entre 80 et 300 dollars par jour et par personne.

Inde, Europe de l’Est, Asie et Maghreb Le 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 aux sociétés américaines. L’environnement de l’Inde est très favorable. Les universités sont réputées et forment des scientifiques de haut niveau, qui travaillent depuis longtemps aux États-Unis. De nombreux postes de management importants sont tenus aux États-Unis et en GrandeBretagne par des personnes d’origine indienne. Certains de ces managers indiens ont su prendre 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 du monde se partageant les 20 % restants. Il est tout aussi intéressant de constater que plus de 80 % des clients de l’offshore sont aux États-Unis et au Royaume-Uni, pays culturellement proches de l’Inde. L’Europe de l’Est peut être considérée comme un immense réservoir de ressources futures 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) restent des pépinières très dynamiques, qui produisent en quantité des informaticiens de qualité. 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, la Pologne et les États baltes. Souvent, seule la capitale attire les meilleures ressources.

38

Chapitre 2 – Les chemins de l’offshore

En Asie, la Chine est un nouvel entrant très agressif. Dotée de quantité de ressources très capables, 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 tarifs ne 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’Île Maurice, très active pour proposer ses prestations offshore en France. De même, la Roumanie 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 pour l’Europe. On peut se rendre compte de l’éloignement de certains de ces pays et des pays limitrophes. On repérera notamment l’éloignement de pays tels que l’Inde, la Chine et l’Île Maurice, par rapport aux pays de nearshore, qui sont proches et faciles d’accès. Le tableau 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 contreexemples de sociétés prêtes à travailler pour moins cher ou d’autres demandant des tarifs très élevés.

Figure 2.1. Les pays de l’offshore

39

Conduite de projets informatiques offshore

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 ÉtatsUnis

2-3

Russie

Nearshore. Pays sous-exploité par les États-Unis, avec d’énormes réserves 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.

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

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

1

3

D’autres pays proposent des prestations offshore, surtout pour les États-Unis, mais ils sont peu attractifs pour l’Europe. On trouve dans cette catégorie les pays d’Amérique du Sud, 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. Tous les pays du continent américain ont un décalage horaire comparable à celui des ÉtatsUnis, qui compte quatre fuseaux horaires.

40

Chapitre 2 – Les chemins de l’offshore

Niveaux de coûts et seuils limites Dans chaque pays de l’offshore, les prestataires proposent des coûts très variables. On peut 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’est pas meilleur ou même dans certains cas est inférieur, les collaborateurs du prestataire offshore pouvant avoir du mal à gérer des prestations d’une qualité supérieure. Ce sujet est abordé en détail au chapitre 3.

Productivité

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

Les coûts des prestations sont liés à la productivité.

Dans certains cas, les coûts élevés nuisent à la productivité.

Les coûts bas nuisent à la productivité.

Coût par personne

Figure 2.2. Coûts des prestations et productivité

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 être nombreuses mais sont faciles à comprendre : le prestataire choisira des collaborateurs acceptant des salaires plus faibles, il ne fera pas d’efforts pour fournir un environnement de travail agréable, les bons profils seront rapidement placés sur d’autres affaires plus profitables, et les services complémentaires seront limités au strict minimum. On observe même parfois un phénomène plus étonnant : lorsqu’on paye le prestataire beaucoup plus qu’il ne pense nécessaire, il arrive que la productivité diminue rapidement. Cela peut s’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.

41

Conduite de projets informatiques offshore

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 leurs capacités, tout en négligeant leurs responsabilités directes. La figure 2.3 illustre l’existence d’une valeur optimale à verser au prestataire en offshore pour obtenir la meilleure productivité. Un versement plus important n’apporte plus de productivité, et tout niveau de prix inférieur entraîne une perte de productivité plus importante 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 ne sont pas toujours financièrement plus efficaces que les équipes locales et qu’il faut porter une attention soutenue à la recherche du point optimal. Figure 2.3 Productivité par dollar dépensé en offshore en fonction de l’économie réalisée

Productivité par dollar

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

Point de productivité optimal

Productivité aux mêmes coûts qu’en France La productivité n’augmente plus aussi rapidement que les coûts.

Coût des prestations

Universités et marques d’éducation Tous les pays où l’on trouve une main-d’œuvre à faible coût ne sont pas pour autant de bons pays de l’offshore. L’Afrique noire, par exemple, n’est généralement pas réputée pour abriter des pays d’offshore. Il est essentiel que les pays de l’offshore aient de bonnes ressources informatiques 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’éducation souhaité que dans la capitale ou dans certaines grandes villes. Dès que l’on quitte ces centres universitaires, la qualité des ressources s’en ressent. Les bons éléments préfèrent aller vivre dans la capitale, où ils trouvent des offres d’emploi au niveau de leurs attentes.

42

Chapitre 2 – Les chemins de l’offshore

Dans certains pays, comme l’Inde, des régions se sont spécialisées dans les prestations offshore et attirent les meilleurs profils. C’est le cas du Bangalore , qui est une vraie Silicon Valley de l’offshore en Inde, rassemblant l’essentiel des sociétés de haute technologie du pays dans la même région et, par là même, attirant les meilleures ressources qui cherchent à y faire carrière. S’il reste possible de constituer de bonnes équipes dans les provinces, c’est plus difficile. Les équipes importantes sont en revanche beaucoup plus difficiles à 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 pour créer rapidement les meilleures équipes.

Entre la capitale et les villes de province, on constate dans la grande majorité des cas des différences de salaires très importantes. Les villes de province sont souvent délaissées par les bons informaticiens, car les emplois gratifi ants et bien rémunérés y sont rares. On y rencontre cependant parfois un prestataire offshore de qualité, capable d’attirer les bons profils de la région. Les salaires pratiqués dans sa région étant inférieurs à ceux de la capitale, il peut proposer des tarifs très attractifs. De leur côté, les informaticiens de la région ne veulent pas risquer de perdre un bon poste dans une ville où les offres d’emploi intéressantes sont rares. Précisons que ces profils sont le plus souvent moins qualifiés que ceux de la capitale. Dans un certain nombre de pays de l’offshore, on trouve une pratique presque inconnue en France, consistant à organiser des challenges. Il existe deux types de challenges, ceux des entités gouvernementales du pays et ceux des grandes sociétés internationales. Par exemple, HP organise le HP Global Business Challenge (www.jaintl.org/hpgbc/) et IBM l’International Collegiate Programming Contest (http://icpc.baylor.edu/icpc/) et les International Mathematics Competition for University Students (http://www.imc-math.org/). Les gouvernements de certains pays d’offshore proposent des olympiades, comme le Belarusian Economics Olympiads, qui opposent le plus souvent des équipes. Les personnes les mieux placées dans les équipes bénéficient de conditions plus avantageuses pour continuer leurs études. Chaque année, les personnes ayant réussi à bien se positionner dans ces concours se voient offrir des postes dans les meilleures sociétés locales et parfois même les meilleures entreprises aux États-Unis. Les pays se plaisent à se classer entre eux selon les résultats obtenus à ces concours, qui font autorité. Une autre marque de qualité de l’éducation est incarnée par les certificats délivrés par des sites Internet, à l’image de BrainBench (www.brainbench.com). Comme pour les certifications des grands éditeurs, par exemple, Microsoft, une série de questions délicates sont posées sur Internet pendant une durée limitée. Le candidat s’engage sur l’honneur à ne pas se faire aider. Selon son succès ou son échec, il reçoit ou non la certification, accompagnée d’une note. Les domaines de certifications vont du français ou de l’anglais à la programmation 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 bonnes universités. La plupart du temps, une ou deux villes seulement correspondent à ces critères.

43

Conduite de projets informatiques offshore

La stabilité politique La stabilité politique du pays est un facteur important pour déterminer avec quels pays il est possible de travailler. Les apparences sont toutefois trompeuses. Des événements majeurs, comme la chute de Ceausescu en Roumanie, ont eu peu d’influence sur les prestations des équipes offshore. Les employés se sont présentés presque normalement et le travail a avancé comme les autres jours. De même, les tragédies politiques contemporaines en Israël et au Liban ont certes ralenti les prestations offshore mais ne les ont pas arrêtées. En règle générale, lorsqu’il y a des difficultés dans un pays, le fait de travailler pour des projets en offshore apporte une sécurité et une assurance face à la tourmente du pays. Les paiements proviennent de pays étrangers, qui ne connaissent pas les mêmes troubles, et dont la capacité à payer n’est pas affectée. La monnaie utilisée est le plus souvent le dollar ou l’euro, qui sont assez bien protégés contre les taux d’inflation galopants que l’on constate dans les pays en difficulté. Les employés peuvent penser, à juste titre, que les paiements de leurs salaires sont pratiquement garantis pour peu que le travail continue normalement. Même si le travail peut continuer localement, on doit se demander si les chefs de projet de la société cliente de l’offshore accepteront de se rendre sur place. Les déplacements en Algérie avaient été refusés par de nombreux chefs de projet dans la période où ce que l’on a appelé la montée de l’intégrisme s’accompagnait d’assassinats en masse. De même, les déplacements en Israël ne sont pas bien ressentis lorsque les attentats s’intensifient. Même l’Inde a commencé à poser problème lorsque les tensions avec le Pakistan se 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 les premiers troubles, il est toutefois possible que les chefs de projet du client de l’offshore refusent de se rendre sur place.

Les prestataires offshore À la manière des sociétés de services en France, les prestataires offshore vont de la toute petite société, parfois constituée d’une personne unique jusqu’aux géants, qui emploient plus de dix mille collaborateurs, comme en Inde. Les prestataires offshore commencent le plus souvent à travailler dans le domaine de la fourniture de services à des sociétés européennes ou américaines, souvent grâce à un ami qui est allé dans un de ces pays et qui, dans le cadre de son travail, a fait naturellement la 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. Par exemple, 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 consacraient à la pêcherie ou à l’exploitation forestière. La plupart de ces sociétés se sont

44

Chapitre 2 – Les chemins de l’offshore

finalement spécialisées et concentrées sur l’informatique, mais on en rencontre encore aux activités disparates. On peut classer les prestataires offshore en plusieurs catégories, mais il est parfois impossible d’attribuer une catégorie unique à un prestataire offshore. On trouve des géants, comme en Inde, des multinationales, des leaders locaux, des petits prestataires et des sociétés dédiées à un client.

Les géants de l’offshore Les géants de l’offshore ne se rencontrent pratiquement qu’en Inde. Ils ont souvent des filiales importantes dans de nombreux pays, comme les États-Unis, la Grande-Bretagne et 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éressent guère aux projets de moins d’une douzaine de personnes, ce seuil pouvant évoluer selon les périodes. L’Inde recevant la très grande majorité des prestations de conseil en offshore, ces dernières constatent une insuffisance des ressources de qualité susceptibles de gérer efficacement les projets et de communiquer avec les clients. Les profils plus communs sont en revanche toujours assez faciles à recruter, quitte à aller les chercher dans d’autres villes ou à les débaucher d’entreprises locales. Les chefs de projet expérimentés et les profils techniques plus pointus sont devenus des perles 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 le projet 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 de nombreux pays, notamment en Russie et dans d’autres pays de l’ex-URSS, étendant ainsi leur 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 les analystes prévoient une pénurie de main-d’œuvre informatique et le triplement des salaires locaux en Inde. Une telle augmentation des salaires entraînerait inévitablement une hausse significative des tarifs pratiqués par les prestataires offshore. Dans quelle mesure l’immense attraction dont l’Inde bénéficie aujourd’hui persistera-t-elle ? L’évolution probable de ces géants indiens consistera à proposer des prestations à partir d’autres pays de façon à maintenir des prix attractifs.

Les multinationales de l’offshore Certains prestataires offshore ont une présence multinationale, la maison mère étant située le plus souvent aux États-Unis et les centres de développement dans plusieurs pays d’offshore, souvent dans une même région. Par exemple, il arrive que l’on trouve des centres 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 collaborateurs, 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, par exemple, 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 total des personnes impliquées dans un projet.

45

Conduite de projets informatiques offshore

On commence à trouver de telles sociétés en France, bien que leur développement soit encore timide. Ces sociétés fonctionnent selon des règles strictes. Elles ont mis en place des procédures rigides, 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 lesquels les prestataires organisent la bonne marche du projet. Elles ont même souvent mis en place leur propre méthodologie, élaborée dans le temps et fonctionnant de façon satisfaisante. Cette méthodologie fait elle-même partie de ce qui est considéré comme un élément important de la valeur de l’entreprise. Les nouveaux membres y sont formés dès leur arrivée et signent des engagements de confidentialité, qui visent à en prévenir l’exportation vers d’autres équipes. On y trouve donc souvent une sensibilité extrême à la protection 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é va partitionner profondément les tâches qui sont confiées à chaque développeur, de façon que 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êtus d’un tee-shirt de même couleur, n’ont pas le droit de se parler entre eux, ni même d’essayer de lier connaissance. Ces sociétés acceptent rarement des prestations autrement qu’au forfait. De ce fait, elles ont peu de clients parmi les sociétés de services, qui sont plutôt leurs concurrentes, ou les éditeurs de logiciels. Le centre névralgique de ces sociétés est la maison mère, généralement située aux ÉtatsUnis. Elles adaptent leurs centres de développements selon l’évolution des marchés en essayant de maintenir une proximité géographique avec tous les sites offshore qu’elles créent.

Les leaders en offshore Les leaders locaux représentent sans doute le potentiel le plus important pour les développements offshore. Ce sont des sociétés qui ont choisi d’assurer des développements pour des sociétés essentiellement européennes et américaines. Elles comptent souvent plus de 100 collaborateurs et travaillent avec de nombreux clients selon des modes en régie ou au forfait. Parfois, les prestations démarrent et se poursuivent à la satisfaction de chacune des parties sans même qu’un contrat ait été signé. Ces sociétés essaient toujours de 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’effectuer une prospection commerciale. Ce dernier est rémunéré uniquement au succès. Il arrive que plusieurs représentants d’un même leader local travaillent de cette façon. Dans quelques 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 du prestataire 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 collaborateurs, mais ces cas correspondent généralement à la montée en charge progressive d’un

46

Chapitre 2 – Les chemins de l’offshore

projet. La moyenne des contrats se situe le plus souvent autour de la quinzaine de collaborateurs, incluant les équipes de test. Ces sociétés particulièrement flexibles sont capables de s’adapter aux méthodes de travail de chaque client. Vous pouvez, si vous le souhaitez, créer une équipe dédiée que vous contrôlez pleinement ou, au contraire, maintenir une équipe dynamique essentiellement 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 pour absorber 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 universités. Ils souhaitent attirer les meilleurs profils, notamment ceux qui ont obtenu les meilleures notes dans les universités ou aux olympiades et font tout leur possible pour apparaître comme une opportunité de choix pour les nouveaux diplômés. Les arguments qu’ils mettent en avant sont les conditions de travail, la nature des projets à réaliser, les technologies employées et, bien sûr, les salaires. La durée et la stabilité des contrats qui sont 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 et mé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’est pas rare de trouver un manager qui y donne des cours ou y tient un rôle honorifique assez important. Les étudiants en fin d’études trouvent par ailleurs dans ces sociétés des occasions de 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 équipes importantes très rapidement. Certaines d’entre elles proposent des cursus payants complémentaires à l’université afin de mieux préparer les nouveaux diplômés au monde du travail, notamment à la gestion de 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 organismes nationaux 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 fois d’é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 voient leur marché s’ouvrir et les contrats avec les entreprises nationales devenir de plus en plus nombreux et rentables. Les managers de ces sociétés sont parfois déroutants. Certains d’entre eux peuvent se montrer extrêmement sérieux et précis dans leurs communications et afficher soudainement de graves lacunes. D’autres sont plus fantasques encore et ne répondent aux questions posées que selon leur humeur. Pour travailler correctement avec eux, il faut prendre soi-même la communication en main et la gérer de bout en bout. Il ne faut pas hésiter à

47

Conduite de projets informatiques offshore

relancer les e-mails sans réponse, réexpliquer constamment ce que l’on attend du partenaire 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 pour travailler efficacement. S’ils offrent toutes les garanties de succès et de sérieux, ils ne sont pas toujours aisément discernables des autres prestataires offshore, plus petits. Cet ouvrage est principalement consacré à la conduite de projet avec ces leaders de l’offshore.

Les petits prestataires offshore En dehors des leaders de l’offshore, beaucoup de petites sociétés se démènent pour trouver des contrats. Parfois, elles ne sont pas même officiellement constituées et opè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 judiciaire. 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’autres travaillent depuis un appartement sommairement organisé, en exploitant chaque mètre carré disponible et en recourant à une installation informatique plus que précaire. Dans tous les cas, leur site Internet est magnifique, souvent meilleur que ceux des leaders ou des géants de l’offshore. Ces sites sont évidemment leurs meilleurs atouts commerciaux. 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 tout des pratiques des clients de l’offshore ou même simplement de ce qu’est un client ou la productivité. J’en ai connu qui exigeaient de toucher des royalties (droits de licence) avec un 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. A vec un peu de chance et de talent, quelques-uns de ces prestataires deviendront des leaders de l’offshore. EN RÉSUMÉ Les petits prestataires offshore

Malgré des tarifs souvent très avantageux et des sites Internet remarquables, les petits prestataires n’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 client Il arrive que des sociétés européennes ou américaines choisissent de créer leur propre structure dans le pays de leur choix, parfois en partenariat (joint-venture) avec une personne de confiance ou une société dans le pays. Les raisons de ces démarches sont vraisemblablement une recherche d’optimisation des tarifs payés pour les développements distribués ou une préoccupation accrue de confidentialité des informations que l’on souhaite contrôler en tous points.

48

Chapitre 2 – Les chemins de l’offshore

On retrouve ici un cas proche des multinationales, à la différence près que la société qui utilise l’offshore n’est pas nécessairement une société qui revend des prestations de services. On peut trouver un éditeur de logiciel ou un consommateur de développements informatiques, 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 de 100 à 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 demandent si les prestataires offshore ne s’octroient pas des marges exagérées, une part importante de 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, les loyers à payer pour les locaux, les périodes d’intercontrat, les efforts de management pour gérer les équipes, les commissions versées aux commerciaux ou apporteurs d’affaires, les bonus qui sont souvent payés aux collaborateurs et qui constituent une part de leur motivation, les commissions de vente et enfin les non-paiements de certains clients, qui voient 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 finalement compte 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 de l’offshore n’apporte aucun avantage franc, si ce n’est une maîtrise plus fine des coûts de développement. Ces sociétés sont moins expertes dans la gestion de l’exploitation d’une structure dans le pays de l’offshore, et leur gestion est souvent moins efficace et plus coûteuse. Dans les cas les plus favorables, on peut espérer réduire le coût des prestations 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 taux importants de renouvellement du personnel ou l’obscurité de la fiscalité locale, l’emportent sur les avantages, et l’on se retrouve à assurer des prestations de faible qualité ou d’un prix 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’elles doivent surmonter alors que ces derniers sont transparents lorsqu’on travaille avec un prestataire. Elles doivent en outre savoir travailler avec les lois et usages locaux, qui sont parfois opaques et contradictoires. Cela nécessite de savoir faire jouer ses relations pour régler les problèmes. Les comptes de ces sociétés en offshore feront partie des comptes de la maison mère et devront être tenus avec la rigueur des comptabilités françaises, ce qui 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 pas toujours 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’autres sociétés, par exemple, à la suite d’une réduction d’effectifs, qui laisse des ingénieurs de qualité sans travail, ou parce qu’ils souhaitent diversifier leur activité. Si l’on envisage de devenir le client d’un tel prestataire offshore, il faut porter une attention particulière au niveau de priorité que l’on peut avoir par rapport au client privilégié qu’est la maison mère.

49

Conduite de projets informatiques offshore

Évolution des pays de l’offshore Ce qui fait la vertu d’un pays de l’offshore peut s’évanouir avec le temps. Les salaires offerts ne resteront pas toujours aussi faibles, par exemple. En Pologne, notamment, ils ont augmenté de façon importante depuis l’ouverture aux marchés occidentaux. Il en va de même des pays qui ont pu et su se rapprocher de la Communauté européenne et qui ont 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 naturellement pauvres. Ils disposent de ressources naturelles importantes, d’une infrastructure industrielle certes vieillissante, mais avec des sites isolés montrant des capacités à exploiter avec succès les technologies les plus récentes. Bien souvent, ces pays ont d’excellentes université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 ont déstabilisés, et ils retrouveront productivité et richesse plus ou moins rapidement. Des pays comme la Russie, l’Ukraine, la Roumanie, la Pologne ou les Pays baltes atteindront certainement un niveau de vie comparable au reste de l’Europe, peut-être plus rapidement que le Belarus ou la Moldavie. Les prestataires offshore travaillent parfois avec des sociétés nationales mais pas aux mêmes tarifs que ceux pratiqués en tant que prestataire offshore. Cela concerne souvent des 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 informatiques nationaux continueront de se développer jusqu’au moment où les marges réalisées en tant que prestataire offshore et sur les marchés nationaux seront proches. Les prestations nationales s’effectueront à des niveaux tarifaires plus élevés. Au fur et à mesure que les salaires locaux s’élèveront, ces pays deviendront de moins en moins intéressants pour l’offshore. Les sociétés qui y proposaient des services en offshore deviendront des sociétés de services nationales 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 prestataires embauchent 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 certains profils du fait d’une forte demande sur le marché national, laquelle a rapidement fait monter 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 prestataire offshore et prestataire national. Du fait de l’évolution du marché national, de l’augmentation des salaires locaux et du rapprochement des tarifications offshore et nationales, le prestataire se tourne naturellement vers son marché national et devient moins intéressant comme prestataire offshore. Depuis la prophétie apocryphe de Napoléon en 1816, on se demande « quand la Chine s’éveillera », tant son potentiel est énorme. On peut raisonnablement imaginer que ce nouveau venu dans l’offshore restera une destination de choix pendant encore longtemps. L’Inde risque de saturer rapidement ses ressources informatiques si les prévisions se réalisent. On parle de triplement des salaires locaux dans les années à venir, ce qui rendra immanquablement les prestations indiennes moins intéressantes. Il n’est pas impossible que les nouveaux contrats de développement, notamment ceux des États-Unis, se recentrent sur l’Europe de l’Est, la Chine et l’Asie.

50

Chapitre 2 – Les chemins de l’offshore

Coût des prestations

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

Prestataire offshore

Marché national

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

Temps

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

Les pays de l’offshore présentent un paradoxe, qui tient à l’écart entre la qualité de leurs universités informatiques et leur niveau économique. Dans de nombreux pays, on peut toutefois penser que les conditions économiques vont plus ou moins rapidement atteindre 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 les sociétés de leur pays, se développeront de plus en plus sur leur marché national et seront de 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 font la richesse d’un pays au seul bénéfice des sociétés occidentales, qui exploitent à vil prix une main-d’œuvre de qualité. Il est vrai que l’image de sociétés riches qui utilisent d’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 officiels et de grandes sociétés ont besoin de développements, mais ces organismes payent

51

Conduite de projets informatiques offshore

pour cela beaucoup moins cher que les clients de l’offshore. Pour certains organismes gouvernementaux, les sommes payées pour des développements informatiques sont proches du symbole mais s’associent à d’autres arrangements, pas toujours clairement explicités. Des sociétés réalisent même certaines commandes gratuitement, dans l’espoir que des personnes influentes leur soient redevables. Bien souvent, les pays de l’offshore revendent massivement les produits progiciels des plus grands éditeurs à des prix extrêmement faibles, équivalents au coût de gravure du support, CD ou DVD. On peut ainsi acheter les suites Microsoft Office, Oracle, etc., pour quelques dollars, dans des magasins ayant pignon sur rue, au vu et au su de tous. Si de telles pratiques sont clairement illégales au regard du droit international, il convient de préciser que nombre de ces pays n’ont pas ratifié la reconnaissance du droit d’auteur ou l’ont fait de pure forme. La culture qui consiste à payer pour des logiciels le prix catalogue est absente dans la plupart des pays de l’offshore. Il n’existe d’ailleurs pratiquement pas d’éditeur de logiciel 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é des produits 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’offshore Le marché du développement national n’est pas totalement au point mort dans les pays de l’offshore. De grandes sociétés, tout particulièrement les banques nationales, les organismes gouvernementaux, les sociétés de téléphonie, etc., font appel à des sociétés de services 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 tout productivité 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 plusieurs postes 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, la banque conserve les personnels correspondants et leur confie des missions sporadiques qui ne prennent que quelques heures par semaine. Les développeurs cherchent donc un travail supplémentaire, au su de l’employeur, qui trouve cela normal. Il est vrai que les salaires de ces développeurs, qui ne dépassent guère 50 ou 75 dollars par mois, sont insuffisants 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 sont que 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 pour une seconde société, après ou avant ses heures de travail ou pendant les week-ends. Les salaires versés par les entreprises d’État ne sont jamais suffisants pour assurer ne seraitce que les besoins d’un jeune couple. Souvent, le second emploi est moins sûr et peut s’arrêter du jour au lendemain. Il est en revanche mieux rémunéré, parfois au pourcentage. Le développeur conserve donc son emploi stable, où l’on est peu exigeant, et se rattrape sur un autre emploi donnant des résultats à court terme. On rencontre parfois au cours des entretiens d’embauche des informaticiens qui viennent du 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

52

Chapitre 2 – Les chemins de l’offshore

management, de productivité, de travail en groupe, de rigueur et de qualité leur sont parfaitement étrangères, même lorsque les domaines fonctionnels dont ils ont l’expérience sont intéressants. Il n’est pas rare non plus de rencontrer des personnes qui ont travaillé plusieurs années sur un projet et ne connaissent que la couche technique qu’ils ont développée. Ils n’ont aucune idée du sujet fonctionnel traité par le produit développé. Cet état de fait est davantage 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 son pays, où la concurrence est vive, et d’où il sort bien placé n’ait pas envie de rejoindre ces sociétés nationales qui étouffent l’esprit d’initiative et jusqu’au simple élan.

Les informaticiens et l’offshore Les prestataires de l’offshore constituent un monde à part. Les salaires y sont deux à cinq fois supérieurs à ceux en vigueur dans les organismes d’État. Les compétences et les talents 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 correspondent mieux à une logique de rentabilité, et le succès de chaque projet doit être aussi bien assuré que possible. Un informaticien qui rejoint une des équipes de développement d’un prestataire 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 meilleurs collaborateurs de ses concurrents pour mieux garantir le succès de son projet. Les salaires s’adaptent donc assez rapidement à ce que chaque société est prête à débourser pour acquérir ou conserver ces profils. Certaines sociétés font directement participer leurs collaborateurs clés aux bénéfices du projet. En plus de tout cela, l’informaticien peut avoir l’occasion de voyager à l’étranger et de découvrir une autre culture, ce qui l’enrichit intellectuellement et lui permet de mieux comprendre ses clients et leurs attentes. Son salaire beaucoup plus élevé lui procure le plus souvent 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ême tenter de s’expatrier en valorisant son expérience et, très probablement, son excellente pratique 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 prestataires offshore. Les salaires y sont plus élevés et les projets plus intéressants tout en apportant une valeur ajoutée au curriculum vitae.

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

53

Conduite de projets informatiques offshore

On peut comprendre que la direction financière ou la direction générale veuille disposer de 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’entreprise, avec un montant important, de plusieurs centaines de milliers à plus d’un million d’euros. Les autres lignes du budget font apparaître des détails, comme les salaires de chaque personne, les dépenses marketing, qui sont souvent détaillées par poste et que tous voient et comprennent. La ligne « développement offshore » est cependant la plus importante. Pour peu que le mot « offshore » soit mentionné au lieu d’« outsourcing », cette ligne donne vite l’impression d’investissements sulfureux et suscite des demandes d’explications. ASTUCE Communiquer la rentabilité de l’offshore

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

On peut toujours donner un détail précis de la façon dont les sommes sont dépensées. Il est plus important de souligner les économies réalisées. De cette façon, les initiateurs de la décision de recourir à l’offshore apparaissent comme les responsables d’économies mesurables. Pour peu qu’une comptabilité analytique adéquate soit mise en place dans la 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 des coûts hypothétiques de la même réalisation en local. Cet exercice est difficile car on compare 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 calcul pré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 partie de leurs réalisations en offshore. Si les enjeux économiques sont de taille, les difficultés ne le sont pas moins. Pour mener au succès les projets outsourcés, il faut prendre en compte de nombreux sujets, à commencer par la gestion des ressources humaines et la mise en place d’une méthodologie rigoureuse, ce qui n’est pas si courant dans les projets gé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 partenaire avec soin, on peut bénéficier à plein des avantages de l’offshore. Lorsqu’on travaille en bonne intelligence avec le partenaire en offshore, on peut allier intérêt professionnel et personnel. La découverte d’autres cultures et d’autres façons de vivre ne peut manquer d’enrichir ceux qui s’y prêtent.

54

Chapitre 3

Les collaborateurs locaux et en offshore Ce chapitre aborde la gestion des collaborateurs du partenaire et du client. Le succès des projets en offshore dépend fortement des hommes et de la bonne compréhension de leurs attentes et motivations. Le travail avec l’offshore demande le plus souvent des modifications substantielles de la façon de travailler, tant pour l’organisation des équipes que pour les procédures. Certains collaborateurs locaux du client de l’offshore ne manqueront pas d’adopter une réaction de 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 au projet d’entreprise sur l’utilisation de l’outsourcing. Il importe surtout de bien comprendre ce qu’est le travail en offshore. Ce monde est si diffé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 une population souvent difficile à gérer dans la société. À la fois créatifs et hautement qualifiés, ils perçoivent des salaires élevés, qui ne les satisfont pourtant pas, et protègent leurs postes en rendant volontiers leur domaine opaque. Cette section se penche sur les motivations de ces équipes locales et sur les moyens d’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 aussi faible que possible. L’éditeur de logiciels cherche le plus souvent à travailler à budget fixe et à réaliser autant de produits ou d’évolutions que possible tandis que la société de services cherche à réduire le coût de sa production afin d’être plus compétitive et d’augmenter sa marge. Dans tous les cas, le salaire des informaticiens est au cœur des débats, avec une logique de coûts que la société de services cherche à réduire, ou avec une logique d’investissement pour les éditeurs de logiciels.

55

Conduite de projets informatiques offshore

Informaticien dans une société de services On a longtemps considéré que le travail de consultant pour une société de services était un 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 tournent 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 services proposant des postes intéressants pour des missions à long terme, il est aujourd’hui possible d’y faire carrière. Dans un environnement de plus en plus compétitif, les clients des sociétés de services cherchent toujours plus de qualité et d’engagement de leurs fournisseurs, pour une somme aussi réduite que possible. Pour réaliser leurs commandes, les dirigeants des sociétés de services recherchent, d’une part, des chefs de projet de confiance, qui sauront parler au client et mener à bien les projets, et, d’autre part, des coûts de production aussi faibles que possible afin de soumettre des offres compétitives. La compétitivité de l’offre est aujourd’hui essentielle pour remporter des affaires. Les sociétés qui veulent faire réaliser un projet comprennent que la grande disparité des montants des propositions de services informatiques ne va pas toujours de pair avec la qualité des réalisations, et ils ne veulent plus payer plus que nécessaire les programmes dont ils ont besoin. Certaines d’entre elles commencent à exiger dans leurs appels d’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 pour apporter 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éalisation de ses projets comme formant un coût, lequel servira de base au calcul de ses offres de services. Le salaire des informaticiens est ainsi maintenu aussi bas que possible afin de rester compétitif, à l’exception de certains profils rares, qui personnalisent les capacités du prestataire et en font la valeur. Les augmentations de salaire sont accordées avec parcimonie, puisqu’elles s’accompagnent toujours d’une perte de compétitivité et de profitabilité. 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 offres de 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 logiciels De leur côté, les éditeurs de logiciels utilisent leurs ressources de développement avec une logique d’investissement. Ils attribuent le plus souvent un pourcentage fixe de leur chiffre d’affaires à leurs développements, qui varie entre 14 et 25 %. Pour peu que l’éditeur soit coté en Bourse ou qu’il ait l’intention de l’être, il a les yeux rivés sur les résultats trimestriels, semestriels et annuels et sait qu’un investissement coûteux risque de peser lourd sur les résultats publiés. Le directeur des développements doit réaliser le plus de projets possible avec un pourcentage bien défini du chiffre d’affaires. Dans ces conditions, démarrer un nouveau projet

56

Chapitre 3 – Les collaborateurs locaux et en offshore

majeur, qu’il soit fonctionnel ou qu’il relève d’une migration technique, présente de grandes difficultés organisationnelles puisque l’essentiel des ressources est occupé à la maintenance et aux évolutions des produits existants. Comme on sait par ailleurs que l’on souhaite 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 à des ressources en offshore. Les équipes locales sont habituellement performantes, tant fonctionnellement que techniquement, et restent toujours plus efficaces, au moins dans les premiers temps, que les équipes en offshore, qu’il faudra former. De plus, travailler en offshore 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 nouveaux projets aux équipes en offshore, au risque de vexer les informaticiens locaux, lesquels resteront sur leurs « vieux » projets, aux technologies vieillissantes, ou aux équipes en place, en déléguant la maintenance évolutive à l’offshore, avec tous les problèmes de transmission 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évelopper beaucoup plus pour un budget donné, sans se soucier des fluctuations du nombre d’informaticiens dont il aura besoin.

Remplacer l’irremplaçable Les employés des sociétés disent souvent que la valeur d’une entreprise réside dans chacune des personnes qui la constituent. S’il est vrai que les employés participent effectivement à la production de la société, il n’est pas moins vrai que seules quelques rares personnes, à 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 un indicateur de sa taille et de sa puissance. En cas d’estimation de cette société par un acheteur ou un financier, le nombre des employés n’est pas considéré comme une donnée importante. On ne prend en compte que les données financières, à commencer par le chiffre d’affaires, la rentabilité et les revenus récurrents et sûrs, comme la maintenance des applications. Le compte du nombre de collaborateurs est presque considéré comme une 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 avec moins 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, savent comprendre les clients et trouver des solutions adaptées à leurs attentes. Ces qualités leur permettent d’emporter des affaires, d’en garantir le succès ou de concevoir de meilleurs produits, qui seront des succès sur les marchés logiciels. Si certaines personnes possèdent ces qualités rares, force est d’admettre qu’elles ne sont pas légion. La plupart des cadres techniques ne se voient pas moins eux-mêmes comme des personnes

57

Conduite de projets informatiques offshore

exceptionnelles et se plaignent de n’être pas mieux reconnus. Leurs salaires sont évidemment considérés comme sous-évalués. Ce sentiment est encore renforcé dans les domaines techniques, où intervient une certaine part de création. Quelle que soit l’équipe en place, à condition qu’elle soit de qualité, les questions techniques trouvent la plupart du temps des solutions acceptables et utilisables. À moins d’une réelle innovation, ce qui est très rare, il est probable que n’importe quelle équipe de qualité pourrait faire une proposition acceptable. L’équipe qui attend une reconnaissance 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ée comme remplaçable. De fait, la majeure partie des collaborateurs est remplaçable. Leur travail est certes nécessaire au bon fonctionnement de l’entreprise, mais que l’on ait affaire à ces collaborateurs ou à 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 sans trop de contraintes les fluctuations. 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 leur employeur, et celle des dirigeants de la société. Ces derniers reconnaissent certes les qualités de ces collaborateurs mais les considèrent comme plus ou moins interchangeables. Du coup, les collaborateurs sont d’éternels insatisfaits, qui espèrent toujours plus de reconnaissance de la part de leur employeur, tandis que ce dernier s’agace de l’importance exagérée qu’ils s’attribuent.

La décision d’utiliser des ressources en offshore est l’aboutissement de la réflexion du management, qui est généralement incomprise des informaticiens. La réalité est que l’on trouve assez facilement d’excellents profils dans les pays de l’offshore et que la plupart des é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 plus faibles 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éalisations techniques sont faites en dehors de la société. Il est même possible qu’une bonne utilisation de l’offshore accroisse la valeur de la société en démontrant sa capacité à être plus performante 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 les remplacer ou d’externaliser les réalisations sans perdre en productivité ni en qualité. En externalisant une partie de leurs réalisations techniques dans les pays de l’offshore, les décideurs gagnent en coûts et en flexibilité. La possibilité de rejet de l’offshore par les équipes locales doit cependant être traitée avec toute l’attention requise, faute de voir la gestion humaine des projets devenir fort complexe.

58

Chapitre 3 – Les collaborateurs locaux et en offshore

Transmettre le savoir Les informaticiens les plus compétents techniquement mesurent parfois avec beaucoup de précautions les informations qu’ils rendent disponibles à la société. Certains poussent cette 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 est essentielle au bon fonctionnement des équipes distantes. Les procédures qui sont mises en 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 transmission complète de toute la documentation de la production de l’offshore. Cette transmission s’effectue non seulement lorsque le projet arrive à son terme, mais aussi au fur et à mesure de l’avancée du projet. Les informations transférées aux chefs de projet permettent à ces derniers 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 les domaines dont ils sont responsables, espérant de la sorte protéger le caractère incontournable de leur poste. En refusant de s’inscrire dans les procédures en place, ils entretiennent en réalité un malaise au sein du management. Avec des ressources en offshore, de telles situations ne se rencontrent jamais, la documentation de toutes les réalisations étant l’une des règles élémentaires du travail avec un prestataire distant.

Documenter les projets Trop souvent, les informaticiens, managers, responsables fonctionnels ou chefs de projet considèrent la documentation comme une perte de temps. J’ai même souvent entendu des chefs de projet affirmer que les spécifications représentaient un travail peu utile et qu’ils préféraient la communication directe entre le responsable fonctionnel et le chef de projet, la jugeant plus réactive et efficace. Il n’y a aucun doute que travailler sans formalisation est plus agréable pour les développeurs. Les informaticiens se sentent plus libres et expriment plus facilement leur créativité. Lorsque le responsable fonctionnel est aussi le développeur, on arrive à créer une dynamique positive, qui atteint le plus haut niveau de productivité. Il est en revanche difficile d’impliquer d’autres informaticiens dans de tels projets, si ce n’est pour réaliser des tâches annexes, énoncées oralement par le chef de projet, ou savoir à l’avance ce que sera le produit en cours de développement. Si cette approche sans papier est assurément la plus efficace pour les développements de très petites équipes, elle ne convient plus pour les projets importants. La visibilité sur ce qui doit être fait, la distribution sur plusieurs équipes, les dépendances entre les équipes et, plus important encore, la nécessité de tester les applications, et donc d’assurer une recette objective, ne peuvent être assurées que si la documentation est saine, à jour et complète. Avec les développements en offshore, la mise à disposition de la documentation est une nécessité. Sans cette documentation, il y a peu de chance de travailler efficacement.

59

Conduite de projets informatiques offshore

Les développeurs en offshore n’apprécient guère plus le travail de documentation que les développeurs des autres pays, mais ils en comprennent mieux l’utilité et savent qu’il est impossible de s’en passer. EN RÉSUMÉ Une documentation complète et à jour

La documentation est le socle de la communication avec l’équipe en offshore. Elle doit être à tout moment disponible, complète et à jour, tout particulièrement pour les spécifications et les documents relatifs aux tests et à la recette.

Ajuster les salaires La gestion des salaires des informaticiens a toujours été un casse-tête. Rares sont ceux qui 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écessairement embaucher des ressources. Les informaticiens embauchés lors des périodes fastes ont 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 pas toujours les informaticiens, qui ne se fondent pas sur des critères de compétence, mais sur les conditions d’attribution du salaire à l’embauche. Dans les sociétés informatiques, les augmentations de salaire sont couramment de l’ordre de 1 à 3 % de la masse salariale des équipes de développement. Cela est de peu d’effet sur les salaires anormalement bas. À chaque discussion budgétaire, les frustrations cré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 conditions d’attribution sont difficiles à comprendre. Il arrive que les objectifs ne soient pas atteints pour des raisons indépendantes de la qualité du travail et de l’implication des informaticiens, 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 techniques consomme du temps et de l’énergie. Du fait de son externalisation, la gestion de ressources en offshore résout ces problèmes. La flexibilité des salaires que l’on rencontre dans la plupart des pays de l’offshore permet au prestataire de réduire ou d’augmenter la masse salariale comme il le souhaite et d’atteindre un bon équilibre. EN RÉSUMÉ Gérer les injustices des salaires

Le manager des équipes d’informaticiens en France doit constamment gérer une situation où les salaires ne reflètent pas la qualité ni la productivité des individus. Les sommes allouées pour les augmentations suffisent à peine à corriger les injustices patentes. La gestion des ressources en offshore permet 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ôles Pour 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 personn e a plusieurs rôles, ce qui est très souvent le cas, elle se concentre le plus souvent sur ceux qui lui plaisent le plus ou qui sont les plus gratifiants. Il n’est donc pas évident de garantir

60

Chapitre 3 – Les collaborateurs locaux et en offshore

que tous les rôles soient correctement assurés. Pour qu’un rôle un tant soit peu difficile soit 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, pour gérer le projet confié au prestataire offshore. Il porte le projet, et son travail contribue fortement au succès ou à l’échec du projet. Il est responsable de toute l’équipe, si cette dernière est assez petite (moins de 20 personnes). Sinon, le travail est partagé entre plusieurs 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 le projet. • Mettre en place le reporting, qui permet de suivre la progression du projet, le travail de chacun et la qualité des livrables. • Suivre effectivement la progression du projet et demander des explications sur les retards ou autres dysfonctionnements. • Répondre aux questions des équipes en offshore, tant sur des points bloquants, qui demandent une réponse fonctionnelle ou technique, que sur des questions organisationnelles. • Informer le chef de produit de la progression du projet et prendre avec lui les décisions visant à rattraper les retards ou changer le contenu de certains livrables. • Se rendre sur place pour mieux suivre les équipes distantes et communiquer sur la vie de 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 du chef de projet offshore est qu’il n’a pas de responsabilité fonctionnelle et qu’il ne définit pas 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 à plusieurs milliers de kilomètres. Leur poste est souvent mal compris, et la perception même de leur travail s’en trouve affectée. Il est d’usage de considérer que l’importance d’un poste peut être mesurée au nombre de personnes managées. Le chef de projet qui gère des équipes invisibles en offshore est perçu comme ayant moins d’importance et d’influence que celui qui gère une équipe plus petite, 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. Son salaire, 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.

61

Conduite de projets informatiques offshore

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 à partir des 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ègues ne 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 qui apprécie avant tout le management humain. Il m’est souvent arrivé de rencontrer des candidats 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. En interne, 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 gestion d’é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éellement 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, alors qu’un échec semblable rencontré sur un projet local entraîne des sanctions à l’encontre du chef de projet fautif. Le chef de projet offshore apparaît aux yeux du management comme un acteur presque passif, et la responsabilité de l’échec est reportée sur l’équipe distante. Je n’ai personnellement rencontré aucun exemple où le chef de projet offshore était considéré comme responsable des crises et problèmes d’un projet. De telles situations ne sont ni saines ni productives. Il est important de responsabiliser pleinement 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 se trouvent étonnamment déchargés de la pleine responsabilité des échecs et des problèmes rencontrés dans leurs équipes en offshore. Pour obtenir des résultats optimaux, il est essentiel que le chef de projet soit pleinement responsable 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 du produit et de son adéquation aux attentes des utilisateurs.

62

Chapitre 3 – Les collaborateurs locaux et en offshore

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éveloppement et décisions avec les personnes concernées en cas de retard, notamment pour alléger le produit de certaines fonctionnalités. • Fourniture et vérification des scénarios de tests ainsi que des jeux de données qui doivent ê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 souvent cumulé avec celui de chef de projet. C’est là un mélange des genres regrettable car les aspects fonctionnels et la gestion de projet prennent généralement le dessus au détriment du management de projet.

Les équipes de recette Il est souhaitable que les tests soient réalisés et automatisés en offshore avec des robots de test. Il faut tout de même recetter le produit livré chez le client pour en vérifier la qualité. Le responsable fonctionnel pilote ces opérations et y participe lui-même directement. Ce poste se rencontre toutefois rarement. On trouve bien des testeurs, mais il s’agit d’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’on observe. • Vérification que les messages et autres communications modifiant le contenu fonctionnel du produit ont été répercutés sur les spécifications (use cases, ou cas d’utilisation). • Vérification que les scénarios de test sont à jour par rapport aux spécifications (cas d’utilisation). • Test manuel du produit sur des fonctions complexes ou qui ont présenté une instabilité notoire. Intégration et déploiement Si les déploiements sont multitiers, comme le permettent les technologies récentes, leur gestion 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 directement à partir du code source, la constitution du build qui sera déployé sur la plateforme cible. Les fonctions de l’équipe d’intégration et de déploiement sont les suivantes : • constitution du build à partir du code source ;

63

Conduite de projets informatiques offshore

• 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 offshore pour 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 sept demande au minimum cinq personnes. Le recours à des ressources en offshore apporte assurément un confort et une rigueur industrielle à toutes ces tâches.

Présentation de l’externalisation auprès des équipes locales Même si tous les collaborateurs locaux peuvent comprendre les motivations objectives qui poussent le management à prendre la décision de faire appel à des ressources en offshore, cette décision est génératrice de malaise. Apparaît en premier lieu la crainte d’être licencié et remplacé par une ressource moins coû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, que ce travail perde de son attrait s’il doit être industrialisé, comme l’exige le développement en offshore.

Les développeurs locaux et l’offshore La première crainte du collaborateur local est de perdre son poste ou de voir certains de ses collègues perdre le leur. De grands groupes américains ont froidement décidé d’externaliser un tiers de leurs ressources informatiques. Cela s’est traduit par des licenciements massifs dans les entreprises concernées. Dans les plus petites sociétés de services ou chez les éditeurs de logiciels, on cherche moins à réduire les effectifs qu’à saisir des opportunités de marché. Les équipes restent en place, et l’on y ajoute une équipe en offshore. Les investissements sont en ce cas vite rentabilisé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 documentation, en plus d’être extrêmement rébarbative à créer pour les informaticiens, expose et fixe tout le savoir détenu et le rend transmissible à un tiers. Si un climat d’inquiétude se développe, la rumeur colporte vite que l’industrialisation des processus est le premier pas d’un plan caché visant à remplacer les informaticiens locaux. L’industrialisation peut aboutir à la spécialisation des métiers et interdire les rôles multiples, notamment ceux qui partagent des responsabilités fonctionnelles et techniques, qu’apprécient tant d’informaticiens. Ces derniers se voient contraints de choisir entre la technique et le fonctionnel, au risque de devoir renoncer à une partie intéressante de leur poste. Il va de soi que l’industrialisation des développements de logiciels peut être mise en place indépendamment de l’offshore. Elle peut viser, par exemple, à obtenir plus de prévisibilité dans les livraisons ou à s’assurer de disposer de toutes les informations relatives

64

Chapitre 3 – Les collaborateurs locaux et en offshore

à un projet. Le mécontentement qui en résulte n’est pas moins fort, si ce n’est que la crainte d’être remplacé par un collaborateur distant est absente. À rebours de ces frustrations, les enthousiastes de l’offshore y voient des possibilités d’ouverture. Ils apprécient principalement la possibilité d’être en contact avec de nouvelles mentalités et d’autres cultures. Si l’informaticien atteint l’âge où l’on commence à ne plus souhaiter développer soi-même pour préférer la gestion de projet, il y 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ègne dans les équipes de développement, ils se félicitent de la mise en place de processus d’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 enthousiastes inconditionnels de l’autre. Dans tous les cas, la direction doit bien communiquer sur la réalisation de projets en offshore afin d’expliquer les décisions telles qu’elles sont et de contrôler la rumeur qui pourrait prendre le pas sur la perception objective de la réalité. Il lui revient d’identifier les personnes favorables, qui pourront participer aux premières ré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’industrialisation des développements.

Communication sur les projets offshore Il est souvent nécessaire de rassurer les équipes locales en leur expliquant clairement comment l’offshore sera utilisé. Il est important d’expliquer que la société n’a nullement l’intention de licencier massivement ses équipes pour en constituer de semblables en offshore. Le tableau 3.1 récapitule les principales questions soulevées lorsqu’on communique sur la mise en place d’une équipe en offshore. L’agressivité des questions dépend bien sûr des 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édemment, 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.

65

Conduite de projets informatiques offshore

Tableau 3.1. Communication aux collaborateurs sur les réalisations en offshore 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 applicatives 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 chances 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 responsabilité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 licenciement 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 comparables.

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 technologies 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.

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 impliqué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 besoin l’utilisation de l’offshore.

Il est vain d’essayer d’obtenir à tout prix l’adhésion de l’ensemble des collaborateurs, car il y aura toujours des opposants résolus. On se bornera donc à convaincre des bonnes intentions du management les ténors des équipes de développement, qui sont écoutés de tous. La communication est une des clés de la réussite des projets distants. Si l’on doit réaliser un projet en offshore dans un climat d’opposition ouverte, on a de fortes chances d’échouer.

66

Chapitre 3 – Les collaborateurs locaux et en offshore

Le travail en offshore Cette section traite des spécificités du travail avec les pays de l’offshore. Selon les pays et les 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çons de penser et d’agir des informaticiens en offshore.

Les motivations des informaticiens Les motivations des informaticiens en offshore sont très différentes de celles des informaticiens locaux. Comme expliqué au cours des chapitres précédents, la vie dans un pays d’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 prestataire offshore se comporte. Certains dirigeants utilisent pleinement la faible protection sociale que l’on rencontre dans ces pays pour se séparer immédiatement de toute personne devenue moins utile. Par exemple, si un projet s’arrête, certaines sociétés licencient immédiatement tout 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 essaient de conserver leurs employés et de leur offrir dans les périodes d’intercontrat un salaire correspondant au minimum vital. Cette considération est à prendre en compte lors du choix 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’importe quel 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 maintenance d’applications Cobol, sont plus difficiles à pourvoir. On y parvient cependant plus aisément que 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 en grade, 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. Dans nombre de ces pays, l’on ne dispose pas toujours d’un compte bancaire, et les salaires ne sont 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 pour faciliter les démarches financières. Certaines sociétés offrent une telle assistance et s’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 offshore

Les premières motivations des informaticiens en offshore sont la stabilité de l’emploi et des revenus ainsi 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éressants et est prêt à aider ses employés attire les meilleurs candidats.

67

Conduite de projets informatiques offshore

Le salaire des informaticiens en offshore Dans la plupart des pays de l’offshore, la gestion des salaires des employés n’a rien de comparable avec ce que nous connaissons. Il est important de comprendre comment est rémunéré un collaborateur en offshore pour mieux 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êmes règles que localement. On trouve des personnes qui se sont bien présentées et ont obtenu un niveau salarial supérieur à ce qu’elles valent, des personnes qui sont arrivées au bon moment, etc. Le plus souvent, les lois sociales de ces pays sont très particulières. Comme nous le savons, il est impossible en France de réduire le salaire d’un employé sans son consentement. Dans les pays de l’offshore, les lois sont souvent beaucoup plus flexibles. Les ré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 points communs peuvent être observés dans tous les pays d’offshore. Les salaires faibles sont peu taxés par le gouvernement. Dès que l’on dépasse environ 150 dollars par mois, ce seuil pouvant varier selon le pays, la part qui revient au gouvernement devient plus importante. Afin de limiter les taxes et les retenues sur les salaires à verser au gouvernement, certains prestataires déclarent un salaire, dit officiel, de l’ordre de 50 dollars et versent le reste au salarié sans le déclarer. Le collaborateur est ainsi officiellement un employé du prestataire 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és privées, tandis que les sociétés publiques ne pratiquent que des salaires officiels, aux montants beaucoup plus faibles. Les gouvernements tentent sans grand succès de combattre ces pratiques, qui entretiennent une économie grise. Certains prestataires choisissent de déclarer la totalité des salaires afin d’être en conformité parfaite avec la loi et d’éviter de jongler avec des sommes circulant sur un circuit caché. Comme les informaticiens en offshore raisonnent en salaire net, c’est-à-dire, après dé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 choisir entre un salaire déclaré entièrement ou partiellement, le salaire net étant alors réduit des prélèvements légaux. Le contrat de travail est souvent oral. Lorsqu’il est écrit, il inclut surtout les contraintes de sécurité que l’employé doit respecter, mais le salaire lui-même n’est pas toujours précisé. Il n’est pas rare que les prestataires ne payent que les jours où ils ont besoin de leurs collaborateurs au salaire plein, les autres jours étant rémunérés sur la base du salaire officiel, beaucoup plus faible. Les collaborateurs qui ne travaillent pas sur un projet à pleintemps ne savent jamais en ce cas combien ils gagneront le mois suivant.

68

Chapitre 3 – Les collaborateurs locaux et en offshore

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é des salaires dont usent les prestataires en offshore contribue à la précarité que ressentent leurs collaborateurs.

Des salaires variables Les prestataires se permettent beaucoup de libertés quant à la façon de payer leurs employés. De nombreux managers motivent leurs équipes par le biais de bonus. On trouve des cas où le salaire versé est de 50 dollars, le reste étant versé sur appréciation des managers. Les salaires effectivement payés varient alors dans des proportions importantes d’un mois à l’autre. Les collaborateurs ne sont pas tous opposés à cette flexibilité des salaires, car cela leur permet 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 motivation de leurs collaborateurs. Il est vrai que ce système de primes ou de bonus leur permet de faire travailler leurs collaborateurs tard dans la nuit et durant des week-ends entiers. Ce système n’est toutefois pas sans faille, et les injustices sont nombreuses. Dès que l’équipe devient importante, les managers ne peuvent plus apprécier le travail effectivement réalisé par chacun. De plus, lorsque des développeurs font des journées de quatorze heures, les dernières heures travaillées sont peu productives. Les absences pour maladie ou pour raisons personnelles sont souvent sanctionnées. Le prestataire offshore décide parfois arbitrairement de réduire les salaires pour faire partager 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 collaborateur ne puisse répondre lorsqu’on lui demande combien il gagne. Il peut citer ses derniers salaires, 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 bonne chose, mais jouer sur la flexibilité des salaires au point que les employés ne savent pas combien 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 productivité et à la valeur réelle de chaque collaborateur. On peut ainsi construire une grille de rémunération dans laquelle le salaire de chaque collaborateur est en harmonie avec ceux de ses collègues. Être « trop payé » Comme on l’a dit, les salaires moyens des informaticiens dans les pays de l’offshore tournent 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 se produit parfois un effet inattendu. Le collaborateur devient immédiatement moins productif et change d’attitude vis-à-vis de son travail. Il se sent d’un coup très important et se mêle de sujets habituellement gérés par sa hiérarchie, comme si son augmentation lui donnait le droit d’agir à la place de ses supérieurs. Son poste, auquel on souhaitait le

69

Conduite de projets informatiques offshore

fidéliser, ne l’intéresse déjà plus, et il devient très difficile, voire impossible, de l’y faire retourner. Bien souvent, il ne peut que quitter la société après une série de heurts avec sa hiérarchie. J’ai pu observer ce type d’attitude au moins une fois chez chaque prestataire avec lequel j’ai travaillé. Il faut donc être conscient qu’une action visant à fidéliser un collaborateur par 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 comportement destructeur. Après de nombreux tâtonnements pour trouver un chef d’équipe compétent, on a choisi de promouvoir un chef de projet, nommé Valery. Après plusieurs mois d’observation, le client est satisfait. Il a enfin trouvé l’homme de la situation. L’équipe comptant environ soixante personnes, Valery se félicite de sa promotion. À la fin de la période d’observation, il reçoit son nouveau salaire, et sa rémunération passe de 400 à 1 200 dollars. Il commence alors à se mettre sous pression et s’attribue de son propre chef de nouvelles responsabilités. Sur certains sujets, il reste compétent et fournit un travail de grande qualité, mais il commence à s’immiscer dans les affaires de sa hiérarchie. Il veut gérer tous les aspects du management de son équipe, comme l’agencement des locaux, la gestion de la trésorerie du prestataire, le rythme 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 qui entraîne mécaniquement un retard dans le versement des salaires des collaborateurs, le prestataire ne disposant pas de réserve financière importante. Valery commence à s’inquiéter de la façon dont est gérée la trésorerie et se persuade que les affaires sont mal tenues. Il véhicule l’idée que les salaires pourraient être facilement payés si l’on constituait une réserve de trésorerie équivalant à plusieurs mois de salaires. Il en parle au manager de la société, qui lui explique que la marge est plus faible qu’il ne l’imagine et 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ée sur le client est nécessaire pour financer d’autres activités du prestataire. Valery n’en croit pas un mot et s’imagine que la marge est immense et doit permettre de constituer cette réserve rapidement. Il s’entête et en parle aux autres membres de l’équipe, qui ne peuvent évidemment qu’acquiescer. Il finit par en parler au client lui-même, lequel convient que le fonctionnement serait 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 la gestion de l’équipe en offshore. Les tensions avec la hiérarchie le minent, et il n’hésite pas à critiquer 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 cause progresse 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 recevoir les paiements du client, met certaines personnes dans la confidence et affirme être soutenu par le client, alors qu’il n’en est rien.

70

Chapitre 3 – Les collaborateurs locaux et en offshore

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éveloppeur, en affirmant que ce serait mieux ainsi. Son action n’en continue pas moins. Soutenu par un groupe de collaborateurs qui s’imagine que le client valide ses actions, Valery envoie un message 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 constituerait une 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 rien et pense renoncer à ce prestataire qui ne contrôle plus rien. Le président du prestataire démet alors Valery de ses fonctions, qui quitte la société quelques semaines plus tard.

Le salaire conditionnel du collaborateur Comme on vient de le voir, l’absence de paiement du client entraîne bien souvent la suspension du versement des salaires. Dans la plupart des cas, le prestataire paie les salaires si le retard ne dépasse pas un mois. Après deux mois de retard, cela devient plus rare. Les collaborateurs en offshore reçoivent donc leur salaire sous condition. Cela explique pourquoi les collaborateurs choisissent, autant qu’ils le peuvent, les projets sur lesquels ils veulent travailler. Un client mauvais payeur entraîne des revenus erratiques. Un client bon payeur assure des revenus réguliers. Les termes de paiement consentis par le prestataire à son client sont le plus souvent répercutés sur les collaborateurs. Si l’accord de paiement de la facture du prestataire est prévu à soixante jours fin de mois, payable au 10 du mois suivant, on constate un délai de l’ordre de quatre-vingt-dix jours entre l’émission de la facture et son paiement. Pendant les trois premiers mois, il y a donc de fortes chances que les collaborateurs en offshore ne soient 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 son prestataire en offshore. C’est l’un des critères de qualité et de sérieux les plus importants pour 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 salaires des collaborateurs en offshore. Sans réserve importante de trésorerie, le prestataire ne peut assurer plus d’un mois de salaires. Les collaborateurs en offshore, tout comme le prestataire, apprécient donc les paiements des factures dans les délais. Les collaborateurs qui ont la possibilité de choisir leurs projets en font un critère de sélection.

Les clients qui ne sont pas au courant de ce fonctionnement utilisent parfois le blocage des paiements pour exercer une pression sur le prestataire. La réalité est qu’ils exercent en 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 luimême, car ils nuisent à la productivité de l’équipe. L’un des effets inattendus de ce mode de fonctionnement est que les prestataires sont parfois moins agressifs pour recouvrer leur dû, puisque leurs dépenses propres sont plus réduites.

71

Conduite de projets informatiques offshore

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 du mê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 un client qui honore ses factures dans les temps.

Travailler sans être rémunéré Lors des entretiens d’embauche des collaborateurs, certains informaticiens expliquent qu’ils ont travaillé sans être payés pendant de nombreux mois et qu’ils ont décidé de quitter 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ême payé par son client, le chef de projet du client, qui n’est pas dans le circuit du paiement des factures, continue de demander des corrections et de nouveaux développements à son équipe distante. Les deux premiers mois sans paiement, l’équipe travaille normalement mais commence à s’inquiéter de l’absence de paiements au commencement du troisiè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 continuer le projet mais ne dispose plus des fonds pour le financer. Le plus souvent, le projet meurt lentement, sans vraiment qu’on y mette fin. Faute d’un message fort du client, les collaborateurs 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 luimême une petite entreprise. Il verse, par exemple, 30 % à la commande et 20 % en cours de 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 performances ou l’existence de bogues inacceptables. Une fois le produit reçu et installé, le client disparaît parfois purement et simplement en ne 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 corriger la qualité de la dernière livraison. Certains prestataires organisent des stages non rémunérés sur plusieurs mois. Le stagiaire teste 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, souvent peu 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é volontairement gratuitement plusieurs mois pour se constituer une expérience. D’autres prestataires, ou les mêmes, demandent que leurs collaborateurs réalisent gratuitement un premier projet test d’un client en leur proposant de n’être payés que si le client est satisfait. La plupart des collaborateurs en offshore ont fait l’expérience de travaux de plusieurs mois sans rémunération. C’est une expérience pénible, qu’ils souhaitent éviter dans le futur.

72

Chapitre 3 – Les collaborateurs locaux et en offshore

L’émigration vers les pays occidentaux Les collaborateurs en offshore connaissent les salaires des informaticiens occidentaux et rêvent parfois d’atteindre de telles rémunérations. Ceux qui ont émigré se rendent compte que ces montants, qui leur semblaient colossaux au départ, sont loin d’offrir le pouvoir d’achat qu’ils anticipaient.

É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 de projet confirmé, qui touche 800 dollars en offshore et qui se voit offrir un poste à Paris pour un salaire 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 ses 4 000 dollars de salaire brut deviennent 3 200 dollars nets après prélèvements des charges. Il paie aussi des impôts sur le revenu. L’appartement, qui lui coûtait entre 100 et 150 dollars dans son pays, passe à 1 000 à 1 800 dollars, par exemple à Paris. S’il envisage de s’éloigner de Paris, il doit acheter une voiture. L’assurance-automobile, de 30 dollars par an dans son pays, lui coûte 1 000 dollars. Si l’on ajoute la nourriture, la différence de revenu réel est beaucoup moins importante qu’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 de quelques années à l’étranger.

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 de l’Ouest avec un salaire immédiatement supérieur à celui auquel ils pourraient prétendre dans leur pays. Viennent ensuite les personnes qui ont travaillé dans leur pays et ont eu des enfants qui atteignent l’âge de 6 à 12 ans. Ils ont appris la langue de leur pays d’accueil et s’expatrient en disposant d’une certaine somme d’argent, qui leur permet de démarrer, souvent avec une offre d’emploi leur offrant une certaine sécurité. Leur objectif est 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’elle trace un chemin pour ses amis et collègues. Elle parle de ses conditions d’intégration et des astuces légales à sa disposition. Souvent, ceux qui ont émigré se sentent seuls et font leur possible pour que des personnes de leur pays, qu’ils connaissent bien, viennent les rejoindre. 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 qui choisissent d’émigrer découvrent rapidement que la différence entre les salaires n’est pas si importante 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.

73

Conduite de projets informatiques offshore

Le statut des collaborateurs en offshore Une des réalités de l’offshore est qu’on ne connaît jamais très bien le prestataire avec lequel 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 des ressources sans même être constitués officiellement en société. Leurs collaborateurs sont en ce 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 disposer de solides références, lesquelles n’ont probablement jamais décelé leur statut légal. Les collaborateurs 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 leur activité, la société se verra démantelée et son manager poursuivi, voire les collaborateurs eux-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’une grande clarté. De nombreuses sociétés font travailler leurs collaborateurs sans contrat de travail. Leur poste n’est pas décrit, leur salaire est vague, et les obligations respectives ne sont 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 e licenciement, 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 collaborateur est souvent payé au noir. Quand elles existent, les obligations légales ne sont pas toujours claires, notamment sur les salaires, les congés ou l’assurance-maladie. Le salarié est de bout en bout dans une situation précaire.

Dans certains pays, comme le Belarus, on trouve encore la notion d’enregistrement dans une commune pour avoir le droit d’y travailler. Cette pratique tend toutefois à disparaître dans 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 afin d’éviter la désertification de régions défavorisées. Les lois n’interdisent pas que l’on se délace d’une ville à une autre, mais, pour s’enregistrer dans une ville et pouvoir y travailler, il faut disposer d’un appartement ou d’un certificat d’hébergement. Sans cet enregistrement, 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 de travailler de façon non déclarée. Certains prestataires font travailler leurs collaborateurs dans le cadre d’un contrat de travail dûment signé par les deux parties et d’un salaire totalement déclaré. Le surcoût par rapport aux prestataires qui paient une partie des salaires au noir est généralement répercuté sur le tarif des prestations, dans une fourchette de 20 à 30 %. Si le client exige de son prestataire offshore de n’employer que des collaborateurs dûment déclarés et rémunérés, il doit s’attendre à une tarification plus élevée.

74

Chapitre 3 – Les collaborateurs locaux et en offshore

Même si ces pratiques en marge de la légalité sont très courantes et que la grande majorité des prestataires et autres sociétés privées y recourent dans les pays de l’offshore, elles ne vont pas sans risque pour le client.

Les conditions de travail chez le prestataire offshore Les conditions de travail offertes par le prestataire offshore contribuent grandement à attirer les 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, les dépenses relatives aux conditions de travail sont considérées comme superflues. De bonnes conditions de travail permettent pourtant non seulement de tirer le meilleur parti de 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 travail de chaque collaborateur est le plus souvent restreint, de façon à placer le plus de personnes dans une même surface. On trouve de grandes salles, avec de petits bureaux alignés, à peine plus grands que des tables d’écolier, où le silence n’est troublé que par le cliquetis des claviers et le ronronnement des ventilateurs. S’il est souvent relativement neuf, le mobilier est clairement bon marché et se détériore rapidement. Les salles de travail sont peu agréables. On rencontre fréquemment des salles aveugles, dans lesquelles une dizaine de développeurs travaillent sous un éclairage au néon fatigant. Dans les pays où il fait chaud l’été, l’air conditionné, lorsqu’il fonctionne, ne couvre que rarement toutes les pièces. Les premières pièces servies sont les salles serveur et les bureaux des managers les plus importants. Les salles où la majeure partie des développeurs 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âches délicates ou ennuyeuses. Les parties communes des immeubles sont généralement délaissées. Leur réfection est la dernière priorité, d’autant plus que les locaux du prestataire offshore ne détonnent pas vraiment par rapport à ceux des autres sociétés du pays. Les toilettes, par exemple, sont gé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 cigarettes fumées les mois passés. Des gravats de travaux anciens restent sur place, et personne ne songe à les enlever. Cette sombre description est loin d’être exagérée, même si tous ces travers ne se retrouvent pas systématiquement chez tous les prestataires. Il ne fait aucun doute qu’un mauvais cadre 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 sont essentiels pour obtenir le meilleur de leurs collaborateurs. Force est de constater que ces derniers font exception et que leurs efforts mêmes manquent de constance.

75

Conduite de projets informatiques offshore

Il est possible de prévoir contractuellement un cadre de travail agréable et propre, afin de fournir à 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 cet engagement soit ignoré, on peut prévoir une pénalité, par exemple en pourcentage du montant facturé pour les collaborateurs, si le cadre de travail ne satisfait pas aux exigences 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 travail agré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 le prestataire aura obligation de respecter.

Les horaires de travail Généralement, les horaires de travail en offshore sont assez peu différents de ce que l’on pratique en Occident. La journée commence vers 9 ou 10 heures et s’achève vers 19 heures, parfois plus tard. Certains prestataires font travailler des développeurs en second emploi. Ces derniers se présentent vers la fin de la journée de travail normale et restent entre six et huit heures dans 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 observe dix heures de décalage horaire. Les équipes arrivent donc entre 18 et 20 heures, ce qui risque de privilégier les seconds emplois. J’ai rencontré des équipes dont le client voulait économiser sur les stations de travail. Les développeurs faisaient donc les trois-huit sur ces machines, chaque poste de travail étant partagé par trois utilisateurs. Ce type d’organisation devient vite un casse-tête et n’est pas recommandé. Par exemple, il est impossible d’organiser une réunion avec tous les chefs de projet. Les vacances La 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é du personnel 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ût des prestations par personne sur l’année est très différent, de même que la quantité de travail. L’impact sur le budget annuel des opérations en offshore peut devenir très important si l’on travaille en régie avec une équipe fixe. Au forfait, les vacances ne sont qu’une contrainte, 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, les personnels 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 de congés payés que sur son salaire officiel. Lorsque le prestataire agit ainsi, les collaborateurs en offshore perçoivent un salaire très inférieur durant leurs congés et préfèrent souvent ne pas partir en vacances.

76

Chapitre 3 – Les collaborateurs locaux et en offshore

Le client a besoin de connaître le nombre de jours de vacances de ses collaborateurs afin d’établir un budget tenant compte des jours de travail disponibles en offshore. Le contrat doit donc spécifier le nombre de jours de vacances maximal et minimal par employé, afin de ne pas avoir la surprise de voir son budget augmenter de 20 % parce que les informaticiens 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 parfois très largement supérieur à ce que l’on rencontre localement. En plus des alarmes diverses placées ici et là, il n’est pas rare de trouver un ou plusieurs gardes qui veillent toute la nuit sur les locaux. Ce niveau de sécurité extrêmement élevé assure une excellente protection des informations et du matériel chez le prestataire. Généralement, les droits d’accès des collaborateurs sont clairement définis, empêchant, par exemple, un collaborateur de venir travailler en dehors des heures normales s’il n’est pas accrédité pour cela. De même, la sortie du matériel est 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’offshore à 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ématiquement 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édiatement opérationnelle. Certains clients invitent localement des salariés de leur prestataire à des fins de formation. 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 inviter temporairement un collaborateur lors des livraisons importantes, afin qu’il accompagne le 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 prendre en 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.

77

Conduite de projets informatiques offshore

Tableau 3.2. Coût d’un collaborateur de l’offshore invité en France(suite) 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 également 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.

On arrive assez rapidement à des montants comparables à ceux d’une personne embauchée localement. Ces invitations sont cependant très appréciées. Elles permettent de récompenser un collaborateur que l’on apprécie. Ce dernier s’enrichit de la culture et des pratiques d’un autre 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 jamais chez le prestataire en offshore.

Conclusion Les sociétés comprennent rapidement que pour être compétitives et réactives, il leur faut réduire les coûts humains des réalisations informatiques. Pour ce faire, l’utilisation de ressources en offshore demande beaucoup de précautions afin de ne pas risquer de dé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 parmi ces derniers, qui parviennent à monter les meilleures équipes, proposent à leurs collaborateurs 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 assurent 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 les projets locaux et en offshore. Le client qui souhaite exploiter tous les excès que permettent les lois des pays de l’offshore comprend vite que ce comportement ne conduit que rarement au succès. À l’inverse, si ces différences sont bien comprises, il est possible de motiver les équipes distantes, de maintenir une équité en leur sein et d’atteindre des résultats contrôlés et fiables.

78

Chapitre 4

Les modes de fonctionnement de l’offshore Ce chapitre expose les différents modes de fonctionnement que l’on peut envisager avec son partenaire ou sa filiale en offshore. Chaque mode couvre certains objectifs et présente des avantages et des inconvénients. Lorsqu’on n’a pas encore travaillé avec une équipe en offshore, on éprouve certaines difficultés à choisir entre les différentes options disponibles. La crainte que le partenaire ou les collaborateurs en offshore agissent pour détourner le produit, 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ère souvent la personne en charge de mettre en place l’outsourcing comme responsable de la sécurité. Pour légitime qu’il soit, en local comme en offshore, ce type de préoccupation ne doit pas pour autant guider tous les choix en retenant systématiquement l’option la plus sécurisée. On arriverait alors à un montage dont les coûts et les contraintes rendraient toute externalisation des développements impossible. Le besoin de limiter les risques pousse naturellement vers des réalisations au forfait. Si cette approche prend tout son sens lorsqu’on travaille avec de grands cabinets de conseil ou de grands intégrateurs, elle perd beaucoup de son intérêt pour une collaboration avec un prestataire en offshore, surtout sur des projets de taille importante. La réalité montre que l’approche au forfait est source de problèmes, qui l’emportent bien souvent sur les avantages attendus. Ce chapitre expose les avantages et inconvénients de chaque approche afin de rendre les choix 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 et de 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’un contrat prévoyant les défections du prestataire.

79

Conduite de projets informatiques offshore

• Si l’on souhaite confier des projets importants de façon récurrente et que l’on fasse de la sécurité et du contrôle des opérations une priorité par rapport aux coûts et à la flexibilité, 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 forfait Les sociétés qui ont de petits projets ou des projets qu’il est facile de définir dans leur totalité attachent peu d’importance au prestataire qui les réalisera. Elles veulent disposer de leur produit au coût le plus bas, en conservant une part importante du paiement à l’acceptation du produit livré, de façon à garder un moyen de pression sur le prestataire. Le projet est généralement facile à définir, soit par nature, soit au moyen d’une maquette commenté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 et l’envoient à quelques prestataires. Ce document est accompagné des conditions contractuelles les plus importantes, notamment le paiement d’au moins 50 % de la facture à validation de la livraison finale. Elles demandent aux prestataires pressentis de leur envoyer leur meilleure proposition. Le projet peut aussi être placé sur un site d’attribution de projets 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 à son affaire afin de le décrire aussi complètement que possible. Sans connaître les offres des concurrents, les prestataires candidats envoient leur proposition en annonçant à quel prix le projet peut être réalisé. À la fin d’une période donnée, le client retient la meilleure offre. EN RÉSUMÉ Les petits projets au forfait

Les petits projets au forfait, par nature stables, totalement définis et de taille modeste, peuvent être confiés à des prestataires choisis sur appel d’offres sur Internet. Cette solution donne généralement satisfaction pourvu que le projet s’y prête. C’est toutefois une solution risquée, tant pour le client, qui peut ne jamais disposer d’un produit satisfaisant, que pour le prestataire, qui peut ne jamais recevoir son dernier paiement.

Ce sont souvent des indépendants dans les pays de l’offshore qui remportent ce type de marché. Certains informaticiens indépendants répondent aussi à ces appels d’offres, à des niveaux de prix sans concurrence. On peut trouver des propositions à partir de 400 dollars par mois. Le niveau de compétence peut être très variable, allant de l’étudiant sans 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 en assurent le développement, à plusieurs, après les heures de travail. Même si ce sont de tels indépendants qui gèrent le projet, leur réponse à l’appel d’offres est souvent dissimulée sous une structure fantôme à des fins de crédibilité. On ne peut donc jamais vraiment savoir comment le projet est géré. Le plus souvent c’est sans importance, car le

80

Chapitre 4 – Les modes de fonctionnement de l’offshore

succès est au rendez-vous. Ce mode de fonctionnement n’offre toutefois pas de garanties suffisantes pour de grands projets ou des projets qui revêtent une importance stratégique pour le client. Dans tous les cas, l’engagement du prestataire sur la réussite du projet est faible. Si un autre travail plus profitable se présente, il bascule vers ce dernier et, dans le meilleur des cas, 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 pas payé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é cette approche avec une grande ouverture d’esprit. Si le client est prêt à accepter des retards et que le projet ne soit pas critique, la gestion de projet est aussi simple qu’efficace.

La filiale en offshore Les sociétés qui souhaitent assurer en offshore un volume important et régulier de réalisations ont souvent envie de créer une filiale en offshore. Si, dans certains cas, il s’agit de la 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 pas dé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 la proprié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 une meilleure rentabilité et une gestion plus fine. L’expérience montre qu’il est possible d’atteindre des coûts comparables avec un prestataire tout en disposant d’un total contrô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. Sauf dans de rares cas, il est démontré que l’on peut se prémunir des risques aux mêmes coûts avec un prestataire 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éficie pas des économies d’échelle apportées par un partenaire sur l’administration générale ou technique, la flexibilité des équipes, etc. Les chefs d’entreprise des prestataires locaux sont généralement rompus aux lois de leur pays et savent exactement comment faire fonctionner leur société dans les meilleures conditions. À 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.

81

Conduite de projets informatiques offshore

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 une personne appartenant au pays, même si le capital est détenu par des étrangers. Les démarches administratives peuvent être inextricables ou à tout le moins fortement consommatrices de temps. Des appuis auprès des administrations compétentes pour faciliter les démarches sont indispensables. Les grandes sociétés rencontrent moins de difficulté, car elles ont accès à des avocats spécialisés dans le droit de ces pays. Les coûts induits peuvent être cachés par des contrats à l’année avec des cabinets. Les sociétés plus petites qui s’y essayent rencontrent davantage d’aléas et à des coûts souvent très importants. Dans certains pays, l’effort n’en vaut pas la chandelle. Les pays qui sont en train de rejoindre la Communauté européenne offrent certainement plus de facilités pour créer une société à capital essentiellement occidental. Ces pays ont cependant plus de chances de rattraper rapidement leur retard économique et de devenir moins 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 gestion administrative peut de surcroît se révéler complexe. C’est pourquoi la création d’une filiale n’est justifiée que pour assurer la mise en place de règles de sécurité et de protection de la propriété intellectuelle strictes.

Avant de conclure hâtivement que l’on peut réaliser des économies importantes en créant une 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 offshore avec la somme facturée par un prestataire est telle que l’on se dispense de calculer plus loin. Le coût réel total du personnel dans la filiale en offshore, tenant compte de toutes les dépenses annexes de personnel, de locaux, d’administration et d’investissement, est cependant beaucoup plus important. Le tableau 4.1 récapitule les principaux postes à prendre en compte dans le calcul des coû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.

82

Chapitre 4 – Les modes de fonctionnement de l’offshore

Tableau 4.1. Avantages comparés d’une filiale et d’un prestataire offshore(suite) Poste

Filiale offshore

Prestataire offshore

Charges et taxes sur les salaires

Toutes les charges et taxes sont intégralement payées par la filiale, ce qui, dans certains pays, peut représenter un pourcentage 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 facturé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’utilisation 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 important 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 souhaitent 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’offshore, 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.

83

Conduite de projets informatiques offshore

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 les services généraux et la flexibilité naturelle de ses équipes, liée à ses activités avec plusieurs clients, lui permettent de tenir de telles marges. En créant une filiale, on ne dispose souvent pas de l’expérience de ces managers, si bien que les coûts finaux par personne 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 la discipline est mal assurée. Il fera sans doute de son mieux pour corriger ces problèmes et placera 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 sont plus 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 besoin d’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 ceux facturés par un bon prestataire en offshore. La comparaison des coûts réels est difficile à effectuer dans les moindres détails. De nombreux critères de comparaison doivent être considérés, dont certains 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 t que l’on a mis en place. On constate les mêmes problèmes de choix du manager pour une filiale en offshore que pour une filiale commerciale. Le problème dans un pays de l’offshore est toutefois plus complexe, car le profil recherché est plus rare. Le manager d’une filiale commerciale est essentiellement cadré par ses objectifs, alors qu’avec une entité de services informatiques pour un donneur d’ordres, on recherche avant tout la personne qui saura gérer les embauches, l’administration et la fiscalité. C’est un poste certes intéressant mais qui ne satisfait pas souvent les managers ambitieux, qui veulent avant tout développer leurs propres affaires pour leur profit. Un tel manager est donc difficile à trouver et encore plus à remplacer. C’est pourquoi on décide si souvent d’envoyer une personne sur place, le temps de trouver le remplaçant, avec tous les problèmes que cela peut entraîner. Dans certains pays, il n’est pas rare de devoir faire face à des rackets ou à des pratiques mafieuses. Le manager d’un prestataire compétent saura sans doute mieux répondre aux intimidations, par exemple en faisant état de liens avec des projets gouvernementaux sensibles. Cela décourage généralement les mafieux, qui ne souhaitent surtout pas entrer en conflit avec les États.

84

Chapitre 4 – Les modes de fonctionnement de l’offshore

ÉTUDE DE CAS Des managers ambitieux J’ai rencontré des cas où le manager ambitieux déclarait suivre scrupuleusement les lois du pays et disposait des reçus qui convenaient pour toutes ses transactions. En réalité, l’essentiel des tâches administratives était réalisé, comme le plus souvent dans ces pays, en séparant l’officiel de l’officieux, la différence allant dans sa poche. Une fois découvert, il ne souhaitait pas même avouer une quelconque 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 offshore pour 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éveloppements et le manager. EN RÉSUMÉ Les principaux risques liés à une filiale

Les risques sont nombreux et de natures très diverses. Les principaux sont liés au management que l’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 offshore Le prestataire offshore est le choix le plus naturel et le plus flexible. C’est le mode de fonctionnement qui apporte le plus d’avantages à la société cliente. Il permet notamment d’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 on précise clairement les obligations des parties et le mode de fonctionnement, en régie ou au forfait. Modes de fonctionnement avec le prestataire Régie, forfait ou régie forfaitée, tous les modes de fonctionnement peuvent être envisagés avec un prestataire en offshore. De même, toutes sortes d’équipes peuvent être constitué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 souhaite travailler ainsi que les objectifs de sécurité, de confidentialité et de flexibilité que l’on souhaite atteindre. Le contrat garantit le bon fonctionnement des opérations et le succès des projets.

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 toujours s’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 personnel et à la sécurité, etc. C’est un document qui sert régulièrement (voir le chapitre 9 pour plus de détail sur les contrats en offshore). Il ne faut pas hésiter à façonner le partenariat exactement comme on le souhaite et ne surtout pas adopter le modèle présenté par le prestataire.

85

Conduite de projets informatiques offshore

Les labels qualité Les certifications ISO 9000/9001 ou CMM 3/5 et plus sont certainement des labels de qualité qui donnent une certaine dimension à un prestataire. Le terme « qualité » est en fait ambigu. Un label qualité indique que la société a mis en place un plan qualité garantissant la gestion d’un ensemble d’activités selon des procédures pleinement documentées, sur lesquelles le personnel a été formé et qui sont appliquées quotidiennement. En revanche, 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 convient donc 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 demander aux fournisseurs s’ils le sont aussi. Si tel n’est pas le cas, les mêmes procédures permettent d’exiger de voir ces procédures de façon à pouvoir juger de leur qualité. Ces certifications sont intéressantes en cas de prestations au forfait mais ne sont pas applicables à la production de logiciel en régie. Dans ce cas, on demande généralement au prestataire de mettre 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 les détiennent. Même dans le cas où l’on met en place ses propres méthodes, on peut être certain 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’utilisation de procédures certifiées n’est pas adaptée aux projets en régie, où le client met en place ses propres méthodes et procédures.

Les marges des prestataires La plupart des prestataires offshore réalisent une marge nette de 10 à 30 % de la somme facturée. Sur des affaires isolées sans commission d’apport d’affaires et sur des sujets suffisamment simples ou bien définis pour ne présenter que très peu de risques, on peut atteindre 40 % de marge, voire davantage. Il est normal et même sain que le prestataire réalise une marge suffisante. Certains prestataires offshore travaillent à prix coûtant, voire à perte. Ils ont tellement envie 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 salaire des informaticiens, et les services sont réduits au minimum. Le client de l’offshore a donc tout 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 marge raisonnable. Il cherche à le satisfaire à tout prix, même s’il doit fournir plus de services que convenu. Avec une marge faible ou nulle, le prestataire n’hésite pas à réaffecter ses meilleurs collaborateurs sur des projets où la marge est plus importante. Les pressions du 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 productivité satisfaisante. Il est préférable d’offrir une marge raisonnable au prestataire en offshore afin qu’il ait un intérêt personnel à ce que son client soit satisfait.

86

Chapitre 4 – Les modes de fonctionnement de l’offshore

Travailler avec un partenaire en offshore offre tous les avantages de l’outsourcing. On obtient 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 offshore Bien souvent, le choix de monter un joint-venture découle d’une volonté de garder un contrôle fin sur les équipes et de réduire les coûts, lorsqu’on ne dispose pas d’un management suffisamment expérimenté ou d’une expérience assez solide du pays pour créer une filiale. L’objectif est d’acquérir les compétences en management et l’expérience du pays qui manquent. Si le partenaire est lui-même un prestataire offshore, on pense qu’il mettra certaines ressources en commun, notamment pour la gestion des embauches et la sélection des collaborateurs. Le partenaire et la société locale partagent leurs compétences pour 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 une activité 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ès plusieurs années de travail en commun. Le client souhaite disposer à la fois des avantages du travail avec un prestataire et de ceux d’une filiale. Il désire aussi conserver l’équipe dont il dispose, qui est simplement transférée dans la nouvelle structure. Le prestataire en offshore continue d’assurer certains services centraux, tels que comptabilité, gestion des ressources humaines, gestion des recrutements, accès aux profils très expérimentés, informatique interne, etc. Dans ce type de montage, la marge nette du partenaire en offshore diminue. Les opérations ayant toutefois plus de chances de s’inscrire dans la durée, il peut espérer que les volumes traités augmentent également.

Comparaison des différents partenariats Le tableau 4.2 récapitule les éléments de comparaison entre les différents modes de fonctionnement des équipes en offshore. Tableau 4.2. Comparaison des modes de fonctionnement en offshore Critère de comparaison Flexibilité des ressources Capacité à embaucher de bons profils

Projet sur Internet

Filiale en offshore

Prestataire offshore

Joint-venture

Forfait

-

++

-

+

+

++

-/+/++

87

Conduite de projets informatiques offshore

Tableau 4.2. Comparaison des modes de fonctionnement en offshore(suite) Projet sur Internet

Filiale en offshore

Prestataire offshore

Joint-venture

Capacité à embaucher rapidement

+

-

++

-/+

Faible coût des prestations

++

+

+

+

Sécurité des informations

-

++

+

++

Mode de fonctionnement

Forfait

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

Capacité à arrêter les prestations

++

-

Critère de comparaison

Régie

Régie Forfait Régie forfaitée

Régie

+

Très petits à très grands projets

+/++

20 à 40 années/ homme au moins par an

++

-

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 ou un 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 projets confié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 du projet, qui est de la responsabilité unique du prestataire. À l’inverse, avec les projets en régie, le client décide de son implication sur le projet et peut aller jusqu’à en prendre l’entière responsabilité. Si le client est une société de services locale, il peut réaliser des développements pour le compte de ses propres clients. Ces projets sont le plus souvent réalisés au forfait. En revanche, la société de services sous-traite généralement le projet en régie pour disposer d’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 demeure la régie, mais le prestataire s’engage à réaliser certaines parties du projet pour une somme fixée à l’avance. La figure 4.1 illustre les différents types de développements que l’on peut trouver entre une société locale, cliente de l’offshore, et ses clients.

88

Chapitre 4 – Les modes de fonctionnement de l’offshore

Figure 4.1. Relations entre une société, ses clients et le prestataire offshore

Importance de la localisation du prestataire La localisation géographique du prestataire a une importance déterminante sur le choix du mode de fonctionnement. Si le partenaire peut être géré à distance, le décalage horaire permettant de travailler efficacement avec lui, et qu’il soit facilement accessible, on peut considérer sereinement le mode régie. La facilité à travailler ensemble de façon interactive est déterminante pour des prises de décision en temps réel, fondées sur des échanges téléphoniques et des messages instantanés. Lorsque le prestataire est plus éloigné et que les horaires de travail ont peu de recouvrement, voire pas du tout, le travail en régie n’est plus efficace. Il faut lui préférer le travail au forfait, grâce auquel le prestataire est plus indépendant pour gérer le projet et prendre des décisions. C’est là une des différences majeures entre le travail en offshore aux États-Unis et en Europe. Les pays de prédilection de l’offshore pour les Américains sont l’Inde, les Philippines et plus généralement l’Asie, qui n’ont pratiquement pas de recouvrement horaire avec 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.2. Recouvrement des heures de travail entre les pays de l’offshore et les pays clients

89

Conduite de projets informatiques offshore

Les livres américains traitant des développements en offshore n’envisagent pas, le plus souvent, le travail en régie. La situation est totalement différente pour l’Europe, où les pays de l’Est et le Maghreb, qui sont faciles d’accès, proposent des prix très attrayants et ne sont qu’à deux ou quatre heures de vol de Paris. Il est possible d’opter pour le travail en régie avec ces pays et de bénéficier pleinement de ses avantages. Le client peut de la sorte intervenir au quotidien dans les développements, répondre aux questions au moment où elles sont posées et se rendre sur place aussi souvent que de besoin pour ré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écalage horaire. Le mode de travail en régie est inefficace avec un tel éloignement. Lorsque le client est en Europe 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 de ce fait bénéficier des avantages d’une gestion de projet en régie.

Le projet au forfait Le mode de fonctionnement au forfait est le plus naturel lorsqu’on décide de confier un projet de développement à un tiers. Si l’on a un projet à réaliser, on le définit aussi complè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 meilleur coût de réalisation. Pour se protéger encore plus, on ajoute des pénalités si les livraisons intermédiaires ou le produit final ne sont pas livrés dans les temps ou si la qualité est insuffisante. 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éaliser efficacement 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 se prête moins à une réalisation au forfait ou nécessite des renégociations pour prendre en compte les changements et les nouvelles exigences.

Si le projet est important, des problèmes ne tardent pas à surgir. Les prestataires ont fait des propositions très basses afin d’emporter l’affaire, mais leurs prix sont si bas que le projet n’est plus rentable dès lors que l’on découvre des imprévus, qui demandent un travail supplémentaire. La plupart du temps, certaines parties sont bien spécifiées tandis que d’autres restent assez vagues. Parfois, le client lui-même n’a pas pleinement conscience 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 veuille apporter des modifications au produit ou qu’il soit nécessaire de prendre en compte de nouvelles contraintes techniques. Le client peut refuser de négocier un ajustement du forfait initial, en considérant que les incertitudes sont normales et qu’on les retrouve dans tous les projets au forfait, ou au contraire préférer négocier des modifications, ce qui suppose qu’il les a prévues et qu’il dispose de la réserve budgétaire nécessaire.

90

Chapitre 4 – Les modes de fonctionnement de l’offshore

Certains projets au forfait essaient de se protéger des modifications en cours de développement en prévoyant un volume d’ajustements inclus dans le forfait (voir la section « La régie forfaité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 selon le cahier des charges qui a été défini au moment de la signature du contrat. Il gère le projet indépendamment de son client, en prenant lui-même les risques, et considère que toute intervention du client est source de déstabilisation et peut générer des retards. Sa plus grande crainte est de voir le client disserter sans fin en cours de projet sur les spécifications 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ême aux zones d’ombre de son projet en choisissant la solution la moins coûteuse. Il se dit que si le client veut que des points soient corrigés, ils pourront l’être au cours d’un autre projet 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 ne manquent pas, et le travail d’ajustement des spécifications est considérable. Ces ajustements peuvent être tellement importants que si le produit livré s’en tient strictement aux spé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 les changements qui surviennent au cours du projet prennent une importance cruciale, au point que l’on ne peut les ignorer sans créer un produit insatisfaisant pour les utilisateurs finals. Il faut alors entamer des renégociations du contenu et du prix du projet ou prévoir, lorsque c’est possible, un projet complémentaire pour traiter les manques. Les renégociations du contrat ne manquent jamais de créer des tensions entre le prestataire et son client, tensions qui se trouvent amplifiées par la distance 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 au forfait ne doit pas être négligé. Sur un premier projet, le prestataire et le client veulent rester dans le budget initial, au-delà même de ce qui est raisonnable. Une renégociation mè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 marge confortable 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’a peut-être pas anticipé ces négociations et n’a alors aucune réserve budgétaire pour négocier avec le prestataire. S’il en a, elles sont généralement très faibles. Il doit remonter haut dans la hiérarchie pour tenter d’obtenir une rallonge budgétaire. Si le produit n’est pas satisfaisant, il sait de surcroît qu’il sera tenu pour responsable. Le responsable du projet chez le prestataire est dans une situation non moins inconfortable. Il travaille avec une marge réduite, résultant d’une farouche concurrence entre les

91

Conduite de projets informatiques offshore

prestataires au moment de l’attribution du projet, et ne peut accepter de surcharges sans risquer de travailler à perte. Lorsque le client durcit sa position pour ne pas renégocier le forfait, le prestataire fait souvent de même. Il fait valoir qu’il s’en est tenu strictement aux spécifications accompagnant le contrat au forfait. S’il a du retard, il se peut même qu’il cherche à poser des questions dilatoires au client afin de retarder la livraison. Les relations entre les partenaires peuvent dès lors se tendre à l’extrême. Fort du respect de son engagement contractuel, le prestataire s’attend à recevoir la totalité du paiement. De son côté, le client reçoit un produit à peine utilisable quoique satisfaisant aux spécifications. Si le prestataire a eu la chance de remporter l’affaire avec une marge importante, il peut accepter 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 relation peut rester cordiale. Dans presque tous les cas, la relation entre le prestataire et le client est tendue à la fin d’un projet important. Une fois la confiance érodée, la distance et la différence culturelle se 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 le développement au forfait est réalisé. On pense que le cadre contractuel, avec ses pénalités en cas de défaut, suffit à contraindre le prestataire de services à réaliser le projet comme il convient. Or certains prestataires perdent pied très rapidement, se noient dans leurs réalisations ou essaient de combler les flous fonctionnels des spécifications par eux-mêmes, s’éloignant de ce fait des attentes du client. Ce dernier ne découvre l’étendue des problèmes que parce que la livraison n’arrive pas ou, lorsqu’elle arrive, parce qu’elle est partielle ou d’une qualité insuffisante. Il est alors bien tard pour engager des actions correctives. Le client peut exiger dans le contrat définissant la réalisation au forfait que le prestataire lui offre une transparence totale sur la progression du projet. Il peut de la sorte juger de son 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 du changement 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 les premiers 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 qui permette au client d’en suivre la progression de façon continue. Cette exigence est à prévoir dans l’accord contractuel.

La régie Le 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 le contrôle du management du projet. Le prestataire assure la mise à disposition des ressources demandées dans les temps et gère la discipline locale, la sécurité et les

92

Chapitre 4 – Les modes de fonctionnement de l’offshore

ressources humaines. Pour tout le reste, c’est le client qui manage le projet, prend les dé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, avec un contrôle identique du client sur la façon dont elle fonctionne. Ce dernier peut remplacer les personnes qui ne conviennent pas, en promouvoir d’autres et suivre le détail de la production de chacune des équipes. Les procédures appliquées sont dans le prolongement de celles utilisées localement par le client, rendant plus naturelle la relation entre les équipes distantes et locales. Les risques de désaccords avec le prestataire sont limités, puisqu’il a peu de responsabilités. Le client est le seul responsable de l’échec éventuel du projet, à condition que des erreurs bloquantes ne proviennent pas directement des domaines de compétence du prestataire. Le succès est tout de même partagé. Le prestataire assure les recrutements et prend soin que la motivation reste forte et que les collaborateurs appliquent efficacement les directives du client. Il veille à éviter les départs en masse vers d’autres prestataires qui offriraient 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 le prestataire. 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.

93

Conduite de projets informatiques offshore

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 motiver l’équipe distante comme une équipe locale et d’atteindre le meilleur niveau de qualité. Le client gère la majorité des aspects du projet et en prend la totale responsabilité.

La régie forfaitée et plafonnée La régie forfaitée vise à combiner les avantages de la régie et ceux du forfait. Cette approche est généralement retenue par le client qui souhaite faire un appel d’offres pour disposer des meilleurs tarifs et qui sait que le forfait pur poserait d’inévitables problèmes de 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 alors une dose de régie afin de gérer les changements dans certaines limites définies aussi précisément que possible. Il peut arriver que le prestataire qui travaille déjà en régie avec une équipe en offshore veuille isoler certaines parties du projet pour les traiter au forfait. Avec le forfait, le client espère que le prestataire sera plus actif et les équipes plus motivées, tout en limitant ses risques financiers. Les retours d’expérience montrent que ce mode mixte ne fonctionne pas vraiment et que l’un des modes, régie ou forfait, finit par l’emporter. Si l’on cherche à apporter davantage de flexibilité au fonctionnement au forfait par une dose de régie, le mode forfait s’estompe rapidement. Le client qui souhaite travailler en régie peut s’inquiéter d’un poste de dépense ouvert dont il ne sait pas définir les limites. La régie plafonnée permet de s’entendre sur un plafond, le plus souvent pour chaque phase d’un projet. Ce plafond constitue une limite qui ne peut être dépassée et qui n’est pas un objectif à atteindre par ailleurs.

Choisir le bon mode de fonctionnement Comme nous l’avons vu, le client de l’offshore a le choix entre trois modes de fonctionnement principaux. 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 Petit projet

Critère

Régie

Forfait

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

++

-

94

Chapitre 4 – Les modes de fonctionnement de l’offshore

Tableau 4.4. Critères de choix du mode de fonctionnement d’un projet en offshore(suite) Type de projet Petit projet (suite)

Grand projet

Critère

Régie

Forfait

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

++

-

Facilité à gérer le projet avec ses modifications et ses imprécisions initiales

++

-

-

++

++

-

+/++

+

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

++

-

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

Régie ou forfait

Il apparaît que le fonctionnement au forfait est bien adapté aux petits projets. Il permet de faire un appel d’offres et d’exiger que le prestataire s’y tienne. Il n’offre en revanche que peu de possibilités de gérer les changements en cours de projet. La régie donne la pleine responsabilité du projet au client. Ce mode est bien adapté aux projets importants et à une relation de partenariat dans la durée avec le prestataire.

Conclusion Ce chapitre a traité du mode de fonctionnement en offshore. Le choix entre régie et forfait est 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 contrepartie, 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 infl uencer les réalisations.

95

Conduite de projets informatiques offshore

Le fait de disposer d’une grande liberté d’action, d’un contrôle fin des équipes et de coûts par collaborateur raisonnables permet de mettre en œuvre les meilleures pratiques et de les expérimenter sur des projets réels. Il s’agit là de bien plus qu’une simple gestion de projet. C’est une expérience personnelle, où les managers du client peuvent donner la pleine mesure de leurs capacités. En tenant compte des retours d’expérience qui constituent la matière essentielle de cet ouvrage, les managers expérimentés pourront tirer un grand plaisir de leurs accomplissements en offshore, dont ils ne manqueront pas de réclamer la paternité.

96

Chapitre 5

Choisir le projet à externaliser en offshore Ce chapitre traite des différents types de projets informatiques susceptibles d’être externalisé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 conviennent pas à l’outsourcing. Bien choisir le projet que l’on compte confier à un prestataire offshore et lui affecter l’organisation qui lui convient sont donc des conditions essentielles, surtout si l’on fait ses premiers pas et que tout soit à construire. La difficulté à réaliser un projet varie de façon parfois inattendue. On peut facilement se tromper 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 et non du prestataire. Les facteurs qui influencent significativement le succès ou l’échec d’un projet en offshore sont en définitive assez peu nombreux. L’expérience montre que même les éléments qui pourraient paraître évidents aux chefs de projet expérimentés se pré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 des projets confiés à une équipe en offshore et aux précautions à prendre pour en garantir le succès.

Les éléments structurants des projets en offshore Le prestataire en offshore s’attend légitimement à recevoir de son client les éléments nécessaires à la réussite d’un développement, à commencer par des spécifications exhaustives. 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 prestataire souhaite en outre que le client soit réactif et attentif aux besoins et difficultés exprimés par l’équipe distante. Le succès d’un projet de développement est toujours fortement couplé à la qualité de sa gestion (gestion du référentiel et du changement, processus itératif, gestion de la qualité, de la motivation, etc.).

97

Conduite de projets informatiques offshore

Les éléments récapitulés dans les sections qui suivent permettent de définir plusieurs types de projets et de les classer suivant la facilité à les confier à un prestataire offshore.

La documentation fonctionnelle Le premier élément pour juger de l’éligibilité d’un projet à l’outsourcing en offshore est la capacité du client à définir totalement le contenu de l’application. Plusieurs approches sont 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 sorte que 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 pour créer la documentation fonctionnelle du produit à développer. Ces sources ne sont bien sûr pas équivalentes.

Figure 5.1. Formalisation des spécifications

Le tableau 5.1 récapitule les différences majeures entre les sources d’informations dont on peut disposer pour définir exhaustivement le produit. Tableau 5.1. Avantages et inconvénients des sources des spécifications Source des spécifications Spécifications complètes fournies par le client dès le début du projet

Avantage

Inconvénient

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.

98

Chapitre 5 – Choisir le projet à externaliser en offshore

Tableau 5.1. Avantages et inconvénients des sources des spécifications(suite) Source des spécifications

Avantage

Inconvénient

Spécifications fournies par morceaux par le client au cours du projet

– Le client prend la pleine responsabilité 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’architecture 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 application 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’information 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.

On doit être capable de fournir à l’équipe en offshore une documentation aussi complète que possible afin de lui permettre de travailler efficacement. Pour atteindre un niveau de qualité des spécifications suffisant, il est nécessaire d’analyser ces dernières afin de détecter incohérences, imprécisions et aspects oubliés. Si le produit est nouveau, le premier jet des spécifications sera certainement très éloigné des spécifications complètes finales. Dans tous les cas, le travail de finalisation est important. Le reverse-engineering présente un avantage important puisqu’on dispose d’un produit fonctionnellement complet que l’on peut analyser en profondeur en cas de besoin. Les ajouts 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 nombreux ouvrages. Une tendance récente, considérée comme la plus efficace, de description des

99

Conduite de projets informatiques offshore

fonctionnalités consiste à les exprimer sous forme de cas d’utilisation (use cases). Ceux-ci décrivent les fonctionnalités selon les actions que réalisent les utilisateurs avec leur vocabulaire habituel. Cette description linéaire est aisée à lire et à comprendre. L’aspect visuel est séparé de l’aspect fonctionnel, permettant ainsi de traiter les sujets relatifs à l’interface utilisateur séparément. Des méthodologies telles que RUP (Rational Unified Process) et XP (eXtreme Programming) mettent en avant ces principes de spécification. Les cas d’utilisation sont complé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 plus des 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 s fonctionnalité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ésentation exhaustive et structurée du produit à réaliser. Le plus souvent, l’équipe en offshore essaiera d’utiliser une formalisation des spécifications sous la forme de cas d’utilisation selon une approche de type RUP ou XP.

Avec l’offshore, les spécifications prennent une importance prépondérante. La communication sur l’objectif fonctionnel du projet doit être parfaitement formalisée, ne serait-ce que parce 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 essentiel sur la base duquel le prestataire s’engage à livrer le produit attendu. C’est aussi à partir d’elles qu’il peut estimer la charge de travail, les risques encourus par la réalisation du produit et, au finale, le coût du forfait. Toute modification des spécifications en cours de projet peut avoir d’importantes répercussions, car on devra renégocier non seulement le travail 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 a toujours l’impression que le prestataire présente exagérément un travail comme perdu et que ce dernier en profite parfois pour rattraper financièrement d’autres tâches qu’il a sous-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 modifications mineures à venir, qui sont ainsi couvertes par une marge élevée sur les modifications importantes. 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 les informaticiens, développeurs et testeurs. Toute modification apportée aux objectifs fonctionnels est immédiatement mise à jour dans les use cases. Ces derniers constituent de la sorte 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 leur exhaustivité conditionnent pour une grande part l’organisation du projet en offshore et par là même ses chances de succès.

100

Chapitre 5 – Choisir le projet à externaliser en offshore

Indépendance du projet à l’égard des influences externes Il 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 mainmise sur les parties principales du projet et sur le cœur technique de l’application. Dans d’autres cas, le client, qui travaille sur des réalisations importantes, répartit les développements 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éalisations locales ou de celles confiées à d’autres prestataires en offshore accroît la complexité de gestion et de distribution du projet. Les développements multisites sont particulièrement délicats. Pour les réussir, il faut parvenir à définir une architecture du produit qui structure des composants techniques et fonctionnels 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 les dépendances. Les développements réellement indépendants sont toutefois rares lorsque les équipes sont distribuées. Les couches techniques forment un lien de dépendance important entre tous les composants, tout particulièrement la gestion de l’accès aux données et la structuration de la base. Si des modifications sont apportées aux spécifications, il faut que les architectes globaux puissent en étudier l’impact et repèrent éventuellement les modifications des design patterns correspondants. Lorsqu’un projet est réalisé à la fois chez le client et chez un prestataire en offshore, il arrive bien souvent que les parties les moins importantes, les moins intéressantes ou les plus fastidieuses soient confiées à l’offshore. Les équipes locales gardent pour elles les parties les plus motivantes et les plus critiques. De ce fait, les parties confiées à l’offshore risquent de ne faire l’objet que d’un suivi distrait du gestionnaire de projet, ce qui rend la collaboration plus complexe. Les questions restent longtemps sans réponses, ou bien ces derniè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 de coordination des builds entre les équipes. Les interdépendances, même légères, sont difficiles à résoudre et ralentissent la stabilisation du développement. Même lorsqu’elles paraissent faibles, les dépendances existent toujours à partir du moment où le projet est éclaté sur plusieurs sites et portent leur lot de difficultés. L’utilisation 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érer et demandent une expertise approfondie de la gestion de projet en offshore et du bon usage d’un ré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 souhaite malgré tout répartir les développements, il convient de porter toute l’attention nécessaire à l’équipe distante en répondant à ses questions et en assurant une communication aussi fluide que possible.

101

Conduite de projets informatiques offshore

C’est d’autant plus nécessaire lorsque les tâches qui lui sont confiées sont d’une importance inférieure à celles réalisées localement, car cela conduit par une pente naturelle à des négligences.

Compréhension fonctionnelle Certains sujets fonctionnels sont faciles à comprendre, tandis que d’autres demandent une formation importante. Les spécifications n’étant jamais vraiment exhaustives, un important suivi fonctionnel des développements est nécessaire pour détecter au plus tôt les erreurs fonctionnelles. Si l’on parle d’un produit de facturation, d’e-commerce ou de gestion de stocks, on peut concevoir que les architectes et les informaticiens comprennent le contenu des spécifications 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ègles mé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 par l’é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 erreurs peuvent apparaître. Un glossaire est alors essentiel. On a tout intérêt à former certains collaborateurs en offshore au domaine métier pour leur donner les meilleures chances de comprendre les spécifi cations détaillées. Ces formations ne 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ées par des experts du métier a toutes les chances d’être mal compris. Il faut donner beaucoup de confiance aux équipes en offshore pour qu’elles osent poser les questions sur les sujets qui les bloquent ou dont elles ne sont pas sûres. Il ne faut surtout pas que ces questions soient prises pour un aveu de faiblesse ou que les collaborateurs distants, percevant l’agacement du client, essayent de deviner par eux-mêmes l’intention des spécifications sans consulter les responsables fonctionnels. Avec le temps et des échanges réguliers et constructifs, 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 plus difficile à 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 est de surcroît essentiel de donner confiance aux équipes afin qu’elles osent poser toutes les questions qui leur sont utiles.

La complexité technique Contrairement à ce que l’on pourrait penser au premier abord, la complexité technique d’un projet n’a pas beaucoup d’impact sur la difficulté à le gérer et sur ses chances de succès. Bien sûr, plus un projet est complexe techniquement ; plus il est difficile. Mais si la 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.

102

Chapitre 5 – Choisir le projet à externaliser en offshore

Lorsqu’on doit s’appuyer sur des briques logicielles importantes, comme un ERP (Enterprise Resource Planning), un logiciel de facturation ou des modules existant par ailleurs chez le client et qui sont stables durant le projet, on peut créer une équipe performante en formant le personnel sur ces sujets en offshore (ils peuvent même obtenir une certification de développeur, si elle existe). Loin d’être bloquants, ces sujets peuvent être sources 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éralement les challenges techniques et se montre heureux de faire des propositions parmi lesquelles le client pourra choisir. Il faut bien sûr lever ces incertitudes techniques au plus tôt dans le projet. Si l’on exige que la complexité technique d’un projet soit exclusivement résolue chez le client, le sujet devient plus délicat, surtout si le client est moins compétent que l’équipe en offshore sur les technologies concernées. Si l’équipe distante présente des solutions supérieures acceptables par le client, il est très motivant pour elle de voir sa solution acceptée. À l’inverse, travailler sur une base technique considérée à juste titre comme mauvaise est une source de démotivation à long terme.

Validation par le client La capacité à définir la façon dont on va valider les livrables est un atout considérable, qui donne de grandes chances de succès au projet confié à l’offshore. Le prestataire peut dès lors 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 bien sûr étendre ses tests de recette une fois le premier lot vérifié pour tester ce que personne n’a encore testé. Cette phase initiale permet de stabiliser les premiers livrables, d’en comprendre le niveau de finition et de limiter les échanges entre le client et le prestataire avant d’obtenir une version satisfaisante. Ces tests ne sont toutefois pas faciles à définir, car ils nécessitent une base de données représentative de tous les cas à traiter. Lorsqu’on travaille à la modernisation d’une application, on peut parfois récupérer la base existante pour les premiers tests en construisant un outil permettant de la convertir de l’ancien modèle au nouveau. Dans les autres cas, la base doit être construite à la main. Elle est alors le plus souvent petite et a peu de chance d’être aussi efficace. Tous les projets ne permettent donc pas à l’équipe distante de recetter le produit facilement. Lorsqu’il n’est pas possible de réaliser des tests efficacement en offshore, il arrive que les problè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 de son 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 accompagné d’une base de données convenable, on limite fortement les échanges qui ont habituellement lieu au moment des premières livraisons. La qualité livrée est immédiatement supérieure, et l’on parvient 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.

103

Conduite de projets informatiques offshore

Le premier projet Le premier projet que l’on mène avec une équipe en offshore est déterminant pour la collaboration future. Le client souhaite souvent commencer par un petit projet test. Son objectif 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 avec des é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 collaboration de se mettre en place et où l’on apprend à se connaître. On cherche surtout à comprendre la nature et les habitudes de la société avec laquelle on travaille. On découvre comment communiquer et gérer les problèmes et les personnalités.

Un petit projet de test Lorsqu’on choisit de réaliser un petit projet de test avec son partenaire, on souhaite avant tout tester son futur partenaire. On démarre le projet en mode forfait, avec une équipe et une date de livraison définies. Pour ne pas risquer d’être la cause de l’échec éventuel du test, le client choisit un projet aux spécifications simples ou faciles à définir. Le budget est limité, au cas où les choses tourneraient mal. La plupart du temps, le client a l’intention d’engager par la suite des projets plus importants pour lesquels il souhaitera appliquer des procédures strictes, en mode 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 de l’équipe que le client a choisie ou s’il doit faire travailler le double de personnes. Le projet doit 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 de méthodes. On met rarement en place un référentiel et pratiquement jamais sur un premier projet de test. Les méthodologies, même les plus élémentaires, ne sont pas vraiment appliquées. Le projet ne représentant guère plus de quelques mois/homme, la mé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 peut estimer qu’il a trouvé une équipe capable et motivée. En réalité, le fonctionnement au forfait a masqué au client le déroulement du projet, dont il ne sait presque rien. Il ne peut tirer aucune conclusion sur la capacité du prestataire à gérer une méthodologie ou même le changement puisque le projet est resté figé durant sa réalisation. Tout au plus, peut-il tirer 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 client lui donne l’impression que l’affaire est gagnée, mais il ne sait rien de la compétence de ce

104

Chapitre 5 – Choisir le projet à externaliser en offshore

dernier pour piloter des projets de grande ampleur. Il ignore tout des qualités humaines et 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 ou du client à gérer de grands projets en offshore. Il ne renseigne en rien sur les capacités de communication, organisationnelles ou méthodologiques des uns et des autres.

Un module périphérique Il n’est pas rare qu’un client teste son prestataire en offshore en lui confiant une réalisation réduite peu engageante sous la forme d’un module d’une application plus importante développée localement. Pour les équipes locales, le développement de ce module ne poserait aucun problème et pourrait être réalisé en quelques semaines ou mois. Le client est ainsi en droit de penser que si l’offshore ne fonctionne pas correctement, il pourra toujours se rabattre sur un développement local. De plus, il pourra comparer la productivité en offshore avec la productivité 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 de réussir. Toutes les conditions de l’échec sont en effet réunies : le projet n’est pas clairement défini ; il dépend d’éléments techniques bien connus des informaticiens d u client mais pas des équipes en offshore ; les modules centraux évoluent avec les développements. La seule chance d’aboutir pour le prestataire consiste à appliquer coûte que coûte des procédures assez strictes, notamment sur la définition du produit à créer et sur les interfaces avec les modules développés chez le client. S’il peut isoler son projet des autres réalisations, il aura éliminé les incertitudes sur ce qu’il doit effectivement réaliser. Il devra prendre 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 afin d’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 en offshore 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’on n’arrive pas à communiquer efficacement. Au finale, les conclusions sont si négatives qu’elles peuvent conduire à décider de cesser de travailler avec l’offshore, à la plus grande joie des informaticiens locaux. Non seulement ils ont éliminé un danger, mais ils se sentent confortés dans l’idée qu’ils sont irremplaçables, extrêmement productifs et qu’ils participent directement à la valeur de la société. Ces conclusions sont forcément erronées puisque c’est la nature même du projet qui est la cause de l’échec : on n’a pratiquement aucune information sur le prestataire en offshore ; on ne peut juger ni de la productivité des équipes, ni de la qualité des méthodes et du management ; le plus souvent, on a appliqué la moitié des procédures, celles qui concernent l’équipe offshore, sans traiter la partie censée échoir au client.

105

Conduite de projets informatiques offshore

EN RÉSUMÉ Module test d’un programme

Confier, en premier projet, la réalisation d’un module d’une application à une équipe offshore offre peu de chances de succès. Toutes les conditions sont en fait réunies pour échouer. Même si le projet aboutit, la productivité sera si pauvre que le client en conclura qu’il n’est pas intéressant de travailler en offshore. Ces projets ne peuvent réussir que s’ils sont traités avec la même attention qu’un projet majeur.

Un projet ambitieux comme premier projet Il 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 projet pour s’assurer qu’il se donne les meilleures chances de succès et choisit avec soin son prestataire offshore et son équipe. Il prend garde de ne pas se trouver dans une des situations les plus porteuses d’échec, même si le projet peut dépendre d’autres développements locaux. En un tel cas, il traite avec une extrême attention les points de dépendance et la communication. Pour gérer le projet, le client met immédiatement en place tous les éléments qu’il juge utiles. 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

106

Chapitre 5 – Choisir le projet à externaliser en offshore

Lorsque les premiers livrables sont reçus, on s’aperçoit de la distance qui sépare ce que le client souhaite de ce que le prestataire a construit, et toutes les causes menant à cette situation semblent insolubles. Une longue phase d’ajustement peut être nécessaire pour corriger les dysfonctionnements. Certains n’y parviennent jamais, et la satisfaction du client 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 les dysfonctionnements. L’expérience acquise sur ce type de projet permet de rétablir la situation 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, on parvient 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 une analyse précise du projet pour en tirer des conclusions sur les développements en offshore. EN RÉSUMÉ Vrai projet de test

Avec un projet test important confié à l’offshore, on observe pratiquement toujours la même évolution de la satisfaction du client. Au début, il est content, voire euphorique. La première livraison le ramène douloureusement sur terre. Comme les dysfonctionnements rencontrés pour obtenir un régime stable de travail peuvent être corrigés plus ou moins rapidement selon l’expérience, la satisfaction revient.

Typologie des projets pour l’offshore Suivant son type, un projet peut être plus ou moins difficile à outsourcer. La typologie des projets 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é à le recetter. On distingue plusieurs types de projets : • Les projets de reverse-engineering, qui permettent de cadrer les attentes du client et sont particulièrement favorables aux réalisations en offshore. • Les grands projets, en supposant qu’ils puissent être correctement spécifi és, qui permettent 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 des projets 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 elle se révélerait trop coûteuse par rapport aux réalisations du projet. • Les projets purement techniques, qui servent de socle technique à des développements fonctionnels qui restent chez le client.

Projet de reverse-engineering Les projets de reverse-engineering sont particulièrement favorables à l’offshore. Leur particularité est de confier à une équipe en offshore le développement d’une application existante, dont on estime les fonctionnalités satisfaisantes, afin de la moderniser ou de l’enrichir.

107

Conduite de projets informatiques offshore

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 certains cas, le code source n’est pas entièrement disponible ou est plus ancien que la version en production. On peut confier à l’équipe offshore l’analyse du produit (exécutable et code source) afin de créer des cas d’utilisation à partir de l’existant. De cette façon, les collaborateurs distants apprennent le domaine fonctionnel et créent des spécifications qui ont le niveau de détail et la formalisation souhaités. Le responsable fonctionnel peut alors ajouter ce qu’il souhaite aux spécifications pour prendre en compte des évolutions ou des fonctionnalité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 toutes les informations nécessaires et permet de trouver des réponses aux questions oubliées dans les spécifications. L’écriture de spécifications à partir d’un produit existant n’est pas pour autant chose facile. 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 sont contextuelles. L’équipe offshore peut définir tout cela d’après le code source, s’il est disponible, faute de quoi un expert fonctionnel doit s’en charger. L’aide d’un expert fonctionnel 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 de création des spécifications, qui permet de s’accorder. Sans spécifications complètes avant tout développement, le risque d’échec est important. La complétude des spécifications permet en outre de définir l’architecture du produit à réaliser. Si l’on ne dispose de spécifications que dans le cours du projet, chaque livraison peut remettre en cause l’architecture fonctionnelle. EN RÉSUMÉ Les projets de reverse-engineering

Les projets de reverse-engineering sont parmi les plus efficaces à confier en offshore. Les spécifications, fournies par le produit à réécrire et son code source, sont stables par essence, et presque toutes 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’offshore, surtout pour un projet de grande taille. Sur un petit projet, on a du mal à pleinement 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 à saisir l’intégralité du projet. Les procédures et la méthodologie sont incontournables pour assurer la gestion des projets importants. On doit synchroniser le travail de plusieurs équipes, revoir le contenu fonctionnel ou l’améliorer durant le développement, et il n’est pas impossible que certains changements majeurs, techniques ou fonctionnels, soient à prendre en compte. Si le grand projet s’appuie sur une méthodologie industrielle, la formalisation des spécifications est difficile à finaliser du fait de l’étendue de ce qui doit être spécifié et de la durée du projet, qui suppose que des événements viendront perturber le contenu ou

108

Chapitre 5 – Choisir le projet à externaliser en offshore

certains choix. La méthodologie permet le plus souvent de stabiliser les spécifications par morceaux, 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 dispose non seulement de processus bien définis et de livrables formalisés, mais encore d’une sé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 et de former les informaticiens sur les aspects fonctionnels et sur la méthode. La stricte application des procédures apporte un grand confort dans la gestion de projet et augmente significativement les chances de succès.

Projet lié à des développements chez le client Un tel projet est toujours délicat à mener, comme nous l’avons vu précédemment dans ce chapitre. Tout au long du projet, les développements des différentes équipes doivent se synchroniser. Les procédures, qui tiennent ici une place clé, n’ont pas toujours la rigueur nécessaire aux développements en offshore. Comme elles fonctionnent correctement pour les besoins locaux, le client ne perçoit pas le besoin de les améliorer. Pour l’offshore, ces procédures se révèlent incomplètes et floues, notamment quant à la gestion du référentiel et des changements. Comme expliqué précédemment, la partie du projet réalisée chez le client progresse, et personne ne se soucie vraiment du prestataire offshore, auquel une faible priorité est attribuée. Ce type de projet, qu’il soit le premier ou non, mène généralement à l’échec. Sur un projet important, la part confiée à l’offshore atteint rarement plus de 30 % des efforts de développement du projet global. Si l’économie de coûts de l’offshore est de 40 %, l’économie réelle générée pour le projet global ne dépasse guère 12 % et peut être légitimement considé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 moins exigeante pour les besoins locaux que pour les réalisations en offshore. La communication est difficile à assurer avec les équipes distantes, et si les tâches confiées à l’offshore sont d’une importance moindre que celles traitées en local, le projet offshore peut être marginalisé et mener à l’échec.

Petit projet Sur 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 sur un 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 donc fortement dépendants de la qualité et du travail des chefs de projet en offshore et chez le client.

109

Conduite de projets informatiques offshore

Figure 5.3. Efforts comparés de gestion des procédures et de réalisation d’un petit projet

La figure 5.4 illustre l’importance de certains rôles clés. Lorsque plusieurs chefs de projet doivent 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 changement. Pour les projets assez stables, on se satisfait d’un répertoire partagé pour distribuer l’information. On ne maintient pas la notion de version ni de baseline, qui lie les livrables d’une version. Le changement est géré par des échanges d’e-mails, des tableaux sous Excel se chargeant de maintenir les informations sur les modifi cations et les anomalies qui doivent être traitées. La simplicité de ce type de projet permet au chef de projet en offshore d’en saisir la totalité. Si le travail est tout de même réalisé en couches, en séparant couches techniques et fonctionnelles, ce sont souvent les mêmes personnes qui travaillent sur ces différents domaines. Le chef de projet du client a peu d’éléments pour suivre le projet. Il fait confiance au chef de projet en offshore et attend les livraisons pour juger du travail accompli. La gestion des petits projets est beaucoup plus difficile à assurer que celle des grands, nécessairement bien organisés et aux procédures strictement appliquées. Le résultat du projet repose sur les 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écessaire pour mettre en place des méthodes et procédures rigoureuses, on ne peut s’appuyer que sur les qualités personnelles des managers. Tout imprévu se traduit en un retard.

110

Importance du rôle

Chapitre 5 – Choisir le projet à externaliser en offshore

Figure 5.4. Importance respective des différents rôles clés

Projet de fondations techniques Certains clients confient aux équipes en offshore des projets exclusivement techniques, comme les fondations techniques d’une application. Les développements fonctionnels sont réalisés ailleurs en s’appuyant sur ce socle technique. Les fondations sont versionnées et gérées comme un produit du marché, dont on contrôle toutes les évolutions et qui est parfaitement adapté aux attentes des développeurs fonctionnels. Ces projets offrent l’avantage d’être assez faciles à spécifier entièrement. Les spécifications sont relativement stables, et les ajouts sont des services complémentaires également faciles à exprimer. Les équipes en offshore comprennent parfaitement les spécifications qui ne sont que techniques. La livraison est toujours accompagnée d’une documentation complète à destination des programmeurs. Ce type de projet demande beaucoup de rigueur pour garantir un service prenant en compte les anciennes versions des couches techniques (pas de dépréciation des fonctionnalités d’une version à une autre plus récente). Il est possible de modifier les couches techniques sans toucher aux évolutions fonctionnelles. Par exemple, sur un produit fonctionnellement figé, on peut améliorer les performances de certains services d’accès aux données et ajouter des traces ou d’autres améliorations sans toucher au code fonctionnel. Les développeurs doivent simplement être rigoureux dans les tests de fonctionnement de ces couches techniques. Des tests de performance et de charge peuvent être assurés de façon routinière.

111

Conduite de projets informatiques offshore

Ce type de projet est lié aux développements chez le client mais n’en dépend pas. Il est en cela très différent d’un développement modulaire, où le développeur appuie son travail sur des directives en perpétuel mouvement et où les spécifications sont incomplètes. Au contraire, ce projet peut être totalement isolé des autres développements, ce qui apporte une forte sérénité dans sa réalisation. La plupart des questions qui surgissent trouvent leurs réponses au sein de l’équipe distante. Ces projets permettent une pleine utilisation de l’offshore en explorant plusieurs options techniques afin de retenir la meilleure. Sans offshore, on ne consentirait pas à investir dans des explorations techniques, et l’on choisirait la solution qui semble la meilleure ou la 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 les spécifications techniques découlent évidemment de besoins fonctionnels ou de considérations sur l’utilisabilité du produit à réaliser. Les développeurs des fondations techniques peuvent ne pas connaître le domaine fonctionnel dans lequel leurs développements seront utilisés. Il est de plus possible que de mêmes fondations techniques soient utilisées dans des domaines fonctionnels différents. Le domaine technique est bien souvent un sujet sur lequel les développeurs en offshore sont tout particulièrement compétents. EN RÉSUMÉ Les projets de fondations techniques

Faciles à spécifier, stables et naturellement isolés, les développements de fondations techniques ou de bibliothèques mathématiques sont des candidats idéaux aux développements en offshore.

Tour d’horizon des types de projets Le tableau 5.1 donne une vue d’ensemble des projets que l’on peut confier à l’offshore et des critères qui permettent de comparer les efforts à fournir. Tableau 5.1. Types de projets offshore et efforts à fournir Facilité à le manager

Formation fonctionnelle

Pertinence comme premier projet

Importance des procédures

++

+

-

-/+

Petit module d’un projet plus important

-

++

-

++

++

-

Fondations techniques d’un développement fonctionnel

+

+

-/+

++

++

Grand projet indépendant

++

++

++

+

+

Type de projet

Petit projet indépendant

+

112

Emploi d’outils (référentiel, changement)

Chance de succès ++

Chapitre 5 – Choisir le projet à externaliser en offshore

Tableau 5.1. Types de projets offshore et efforts à fournir(suite) Facilité à le manager

Formation fonctionnelle

Pertinence comme premier projet

Importance des procédures

Reverseengineering d’un petit projet

+

+

+

+

Reverseengineering d’un projet important

++

+

++

++

Type de projet

Emploi d’outils (référentiel, changement)

Chance de succès ++

++

++

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 que l’on souhaite externaliser vers des équipes offshore et anticiper les difficultés. Le premier projet est particulièrement important, et il nécessite de se donner les meilleures chances de succès. Se préparer à éprouver ces difficultés est un atout clé pour les éviter ou les corriger. Quels que soient la taille et le type du projet, la source de dysfonctionnement la plus importante est 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 clairement le ton de la coopération. La prudence du client, qui cherche à confier un petit projet satellite, peut facilement mener à un échec des réalisations distantes. Comme le but de ce 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, font appel à de nombreuses qualités du prestataire. Au-delà des compétences techniques, il lui faut faire preuve de psychologie avec le client qui ne comprend pas  ou ne veut pas comprendre  les difficultés auxquelles font face les collaborateurs distants. Dans cette relation, les collaborateurs du client jouissent souvent d’une forme d’immunité. 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 le pouvoir 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 nature du projet influent grandement sur son succès ou son échec. La timidité mène tout naturellement à des résultats médiocres, et ses conclusions sont finalement peu utiles pour valider la possibilité de travailler avec un prestataire en offshore ou évaluer ses capacités.

113

Conduite de projets informatiques offshore

Paradoxalement, les clients qui semblent les plus hardis et qui se lancent directement dans un projet important en mettant en place les processus qui conviennent ont plus de chances de succès et travaillent plus sereinement. De même, ceux qui confient des projets plus critiques prêtent naturellement plus d’attention au prestataire, et le projet ne s’en porte que mieux.

114

Chapitre 6

Les risques de l’offshore Les sociétés qui envisagent de confier certaines de leurs réalisations en offshore associent presque toujours cette initiative à un risque important et mal maîtrisé. Il convient cependant de relativiser les risques attribués aux développements en offshore car nombre d’entre eux sont aussi élevés, voire davantage, lorsque les développements sont réalisés localement, au sein même de la société, à l’exemple du risque que des créations originales soient divulguées à la concurrence. De nombreux clients de l’offshore présupposent que certains sujets sont particulièrement exposés. Une crainte fort répandue est que le prestataire en offshore ne détourne le code qui lui est confié pour créer un produit concurrent ou le revendre. D’autres craintes concernent la sécurité des communications entre sites ou le montant des marges prélevées par le prestataire. Force est pourtant de constater que le plus grand risque qui menace un projet en offshore est que le client ne sache pas le gérer à distance. Nombreux sont en effet les projets que les clients se révèlent incapables de gérer, tout en reportant la responsabilité de l’échec sur leur prestataire. Pour ce dernier, le risque principal est que le client ne paye pas, et chaque 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é professionnelle de leurs sites Internet, de leurs nombreuses références et du grand nombre de personnels qu’ils emploient. Pour se prémunir des conséquences notamment juridiques de telles collaborations, il est courant de demander au prestataire de communiquer ses statuts, si possible traduits en anglais. 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é auquel on a affaire. Si l’on découvre que la société du prestataire est en fait une fi liale d’un éditeur de logiciel américain, on prendra soin de s’assurer que l’activité de développement que

115

Conduite de projets informatiques offshore

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 projet qu’on souhaite lui confier sur la stratégie de ce prestataire. On peut aussi légitimement redouter 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 juridiquement constituée. Les clients précédents n’ont peut-être pas pensé à vérifier son statut ou ne s’en sont pas préoccupés. Il vaut toujours mieux vérifier cette situation par soi-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 de la société en offshore et de les faire traduire avant de prendre sa décision. Il est important que le prestataire 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’amiable au lieu de laisser la situation se dégrader. Il peut être utile de prévoir une telle clause dans les contrats qui lient le client au prestataire, car ces médiateurs donnent généralement d’excellents résultats. En cas de litige, le client peut avoir un contrat-cadre avec un cabinet d’avocats, lui permettant de consommer un certain volume d’heures d’avocat (retainer). Cela rend le coût de gestion du litige pratiquement nul. Même s’il doit payer un cabinet d’avocats pour ses prestations, 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 pays distant qu’il connaît mal, aux tarifs très élevés en comparaison de ceux en vigueur dans son 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 important peut 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 à faire appliquer dans les pays de l’offshore, surtout s’il s’agit de sommes modiques ou de restitution 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ès intentés par les grands éditeurs pour la protection des licences ont porté peu de fruits. La faible volonté des juridictions des pays de l’offshore d’exécuter les condamnations est parfois amplifiée par la perception que la décision est injuste puisque le prestataire n’a pu défendre ses chances à armes égales. Pour éviter de telles situations, le client peut avoir intérêt à prendre un excellent avocat du pays de l’offshore. Les décisions de justice éventuelles sont alors beaucoup plus faciles à faire appliquer. Les coûts des avocats sont par ailleurs modiques dans certains pays d’offshore, et il est possible d’être correctement représenté.

116

Chapitre 6 – Les risques de l’offshore

Protection de la propriété intellectuelle La première préoccupation d’un chef d’entreprise ou d’un responsable du développement concerne la propriété intellectuelle qui est transférée en offshore et tout particulièrement les codes source. On associe assez naturellement la valeur d’un développement à son code 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 prestataire ou un de ses collaborateurs n’est pas sans fondement. Quand on voit comment les lois sur les copyrights sont ouvertement ignorées dans les pays de l’offshore, on a tout lieu de redouter que les produits du client soient détournés. Même si on ne sait pas exactement ce qui pourrait arriver au code source, on panique à l’idée de le retrouver sur un autre 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 rare qu’il se concrétise à des fins commerciales. Les prestataires en offshore opèrent dans des zones où, bien souvent, il n’existe pas de réel marché local du logiciel, rendant l’exploitation de tels détournements peu rentable et fortement risquée. Les produits de grande diffusion commercialisés sur Internet sont beaucoup plus exposés car la fraude peut être initialisée par une seule personne indélicate et mener à des profits certes faibles, mais rapidement acquis. C’est finalement en terme de réutilisation sur d’autres projets que le risque est le plus important, 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 source Il existe de fait un risque juridique sur la propriété du code source. Dans la plupart des pays, le payeur n’est pas nécessairement le propriétaire du code source, car c’est le créateur du code qui en est le propriétaire naturel. Certains prestataires en offshore mettent clairement en avant leur désir de construire des offres de produits à partir des réalisations qui leur sont confiées. Ils font valoir qu’ils sont les 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 un premier client. Celui-ci, payant pour un plein développement, peut accepter que le prestataire réutilise le cœur du développement pour construire d’autres solutions. Gagnant ainsi du temps, le prestataire reverse alors des droits au client pour avoir utilisé du code développé initialement pour lui. De tels arrangements ne peuvent se produire que si le prestataire agit en tant qu’utilisateur final ayant un besoin d’exploitation et qu’il n’envisage pas de revendre le logiciel. Par exemple, un client industriel qui met au point une gestion de stock s’appuyant sur un ERP du marché peut ne pas s’opposer à ce que son prestataire essaie de packager le produit et de le revendre, pour peu que le coût du projet s’en trouve diminué. Ce client n’étant pas un é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. Ils veulent avant tout utiliser les forces de production en offshore pour créer leurs produits

117

Conduite de projets informatiques offshore

dans les meilleures conditions possible. À leurs yeux, le prestataire ne doit avoir aucun droit 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éation intellectuelle. Comme nous le verrons au chapitre 9, consacré au contrat avec le partenaire, le contrat doit clairement préciser que la propriété intellectuelle de toutes les créations en offshore, incluant le code source et tous les éléments créés ou échangés au cours 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 de faire 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écessairement le propriétaire juridique de la création.

Rétention des sources en offshore La situation devient rapidement délicate lorsqu’un conflit se développe entre le client et le prestataire. Si les paiements ne sont pas effectués comme ils le devraient, le prestataire offshore commence le plus souvent par bloquer la livraison du code source, si c’est techniquement réalisable. Si le client n’a pas honoré ses factures par négligence ou du fait de difficultés passagères, l’effet de ce bras de levier est désastreux. Le client ressent toute la puissance de la rétention du code source, se sent pris en otage et perd rapidement confiance dans le prestataire. Quelle que soit la situation concrète, le prestataire n’a guère que deux moyens de pression sur 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 marque d’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 possession du prestataire s’il souhaite poursuivre la collaboration. Le fait d’avoir exprimé dans un contrat que le prestataire n’a aucun droit à exercer une rétention des livraisons n’est guère dissuasif dès lors que le prestataire considère que le client 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 prestataire va utiliser le produit qu’il garde en otage à son propre profit. Il s’agirait en ce cas non plus d’un moyen de pression, mais d’un acte délictueux, mettant potentiellement en danger l’activité de la société cliente. Ce risque n’est pas une vue de l’esprit, et il arrive que de petits prestataires qui n’ont pas été payés considèrent unilatéralement que le produit 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 pression sur son client en cas de conflit. Les protections contractuelles sont sans effet pour interdire au prestataire de retenir les livrables.

118

Chapitre 6 – Les risques de l’offshore

Faire appel à un médiateur est un signe fort de recherche de conciliation. Lorsqu’un client traite avec un représentant local de l’offshore  comme expliqué au chapitre 2, certains prestataires disposent d’un agent commercial dans le pays du client , ce dernier joue naturellement un rôle de médiateur, pour peu qu’il ne soit pas lui-même impliqué dans le 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 un ré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 du client. Dès lors, le prestataire ne peut exercer de chantage sur la production réalisée, et le blocage des livrables ne peut concerner que la production à venir, ce qui est beaucoup moins 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 comme une attitude agressive. Le prestataire se demande pourquoi son client le lui demande. Au mieux, il s’imagine que le client effectue une revue de code ou critique l’organisation des sources. Il suppose peut-être aussi que le client veut interrompre la collaboration et récupérer ce qui lui est dû avant de l’annoncer au prestataire. Si la demande de livraison du code source est faite en situation de conflit, il y a toutes les chances que le prestataire la prenne 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 recommandé d’organiser une gestion de référentiel obligeant le prestataire à y placer régulièrement tous les éléments de la production. Le référentiel est synchronisé en temps réel ou quotidiennement avec le référentiel chez le client, engendrant une livraison continue de la production. Le blocage des livraisons par le prestataire ne peut dès lors concerner que le futur, ce qui est moins contraignant pour le client.

Arrêt des prestations en situation de conflit Lorsque les prestations s’interrompent du fait d’un conflit, des règlements peuvent être dus 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 en ce cas qu’il est en droit de récupérer son dû sur les actifs dont il dispose, y compris le code source. De son côté, le client peut estimer avoir perdu beaucoup plus que la somme restant due au prestataire. L’absence des dernières livraisons et les retards sur la production peuvent représenter pour lui des montants très importants. Il peut même envisager de poursuivre le 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 de vendre le produit à leur compte ou à réutiliser le code source pour leurs propres développements. Le seul moyen pour un client d’empêcher un prestataire de le faire est de négocier avec lui, non seulement en raison de l’aléa judiciaire, mais parce que les décisions de justice ne sont pas toujours appliquées, d’autant plus dans les pays de l’offshore.

119

Conduite de projets informatiques offshore

EN RÉSUMÉ Une fin conflictuelle

Lorsque les prestations se terminent en situation de conflit et que des sommes restent dues au prestataire, ce dernier considère le plus souvent qu’il peut disposer à son gré du produit développé pour son client. Il est toujours préférable de privilégier la négociation plutôt que la rupture.

É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és concernant l’analyse de données d’une production pétrolière. Peu confiant par nature, il se méfie des prestataires en place et monte sa propre équipe dans un joint-venture. Il embauche pour cela un 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-Unis connaît des difficultés, et ses revenus se font erratiques. Sans visibilité, l’éditeur cesse ses paiements au joint-venture en offshore sans donner d’explications. Les mois passant, le manager de la structure offshore exige d’être payé. Après six mois sans paiement ni explications, le manager passe à l’action et entre en contact avec des clients de l’éditeur auxquels il explique sa situation, à son avantage bien sûr. Il explique qu’il est désormais propriétaire du produit et qu’il en assurera dorénavant la maintenance à 30 % du prix pratiqué par l’éditeur américain. Les clients contactent immédiatement l’éditeur américain. Ce dernier se veut rassurant, mais le mal est 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érir le produit à travers lui. L’éditeur américain menace de poursuivre son ancien manager et ceux qui se sont associés à lui, arguant du fait que les lois du pays de l’offshore sont intraitables quant au respect de la propriété intellectuelle. Essuyant un refus de la part de tous les clients contactés, le manager disparaît finalement, et les choses en restent là, fort heureusement pour l’éditeur américain. Ce dernier mettra cependant un temps considérable à redorer son blason, sans parvenir à rétablir tout à fait sa crédibilité.

Utilisation de bibliothèques de programmes Outre le risque de détournement de la propriété intellectuelle du code source, il convient de s’attacher à protéger ce dernier contre l’inclusion de sections de code qui seraient la proprié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 du temps ou parer au plus vite à leurs insuffisances, ils peuvent employer du code qu’ils pensent libre car provenant de projets Open Source aussi bien que du code source commercial. Ce risque est plus courant qu’il n’y paraît. Par exemple, un développeur qui travaille sur un domaine technique précis a de grandes chances de se voir confier des projets similaires. Très naturellement, parfois sans même penser à mal, il se peut qu’il réemploie du

120

Chapitre 6 – Les risques de l’offshore

code du projet précédent. Puisqu’il a un même problème à résoudre, il lui semble naturel d’appliquer une même solution. L’ennui est que ce code source ne lui appartient pas mais appartient 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 chances de découvrir la réutilisation du code. Le problème peut devenir sérieux si le premier client, propriétaire du code, a fait de ces couches techniques un atout concurrentiel qu’il protè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 produits sont 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 que la 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 utilise un tel code source et qu’il y ait un réel préjudice, il est hautement probable qu’une action en justice condamne ceux qui auraient bénéficié de la fraude, en l’occurrence le client, en même temps que le prestataire. De plus, si le prestataire ne peut honorer les dommages et intérêts exigés, ce qui est plus que probable puisque les sommes en jeu peuvent se révéler très élevées, le client seul solvable se retrouve seul tenu de dédommager la partie lésée. Pour avoir quelque efficacité, le contrat doit bien sûr interdire explicitement l’utilisation de code source externe sans l’accord explicite du client mais surtout s’accompagner d’un suivi régulier des développeurs, surtout dans les domaines techniques, car ils sont les plus tentés de réutiliser des programmes licenciés. Ajoutons que ces blocs logiciels sont assez 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 codes source qui sont soumis à des droits d’usage ou qui appartiennent à un tiers. Il est fortement recommandé d’assurer un suivi rigoureux de ces règles dans le cours des développements.

Fractionnement du code source Certains 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é. Cela limite 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 sur les fondations techniques des applications. Le plus souvent, on leur confie des projets pé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 choisissent parfois de contrôler les accès à chaque module du code par le biais d’un référentiel de façon que personne ne puisse disposer du code source complet. Rien n’empêche cependant les développeurs du prestataire de collationner le code de chaque module afin d’en reconstituer l’intégralité. Si l’intégration et le déploiement sont assurés en offshore, les personnes qui s’occupent de ces tâches ont nécessairement accès à l’ensemble des modules pour pouvoir les compiler et les déployer.

121

Conduite de projets informatiques offshore

La plupart des clients considèrent que la protection qu’apporte le fractionnement du code source est illusoire et préfèrent faire confiance au prestataire pour atteindre une productivité 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 ce qu’est une information confidentielle et indique le plus souvent que les mêmes protections doivent être portées à ces informations du client qu’aux informations confidentielles du prestataire. Bien souvent, cet accord est signé par le management du prestataire, et les collaborateurs distants n’en sont pas informés. Il peut être plus judicieux du point de vue psychologique de demander à chaque collaborateur travaillant pour le client de signer l’accord de confidentialité. Dans les pays de l’offshore où l’on ne signe que très peu de documents et où le contrat de travail lui-même n’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 concernant le 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 engagement personnel fort.

Les informations confidentielles Le prestataire en offshore a forcément accès à un ensemble assez vaste d’informations que le client souhaite protéger. Il peut s’agir de codes source (voir la section précédente), de spécifications ou d’informations sur le produit, ses anomalies ou ses faiblesses connues. Le client souhaite naturellement assurer la protection de ces informations, à commencer par le fait de ne pas les rendre accessibles à tous chez le prestataire offshore, en particulier aux visiteurs. Toutes les informations confidentielles, ou presque, sont rendues disponibles sous forme informatique. Il est important de savoir précisément où se trouvent ces informations et comment elles sont gérées, car, à défaut de protection, elles peuvent ê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 jointventure, les informations sont naturellement isolées. C’est d’ailleurs souvent l’une des raisons 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 prestataire, la première chose à faire est de mettre en place un référentiel. IBM Rational ClearCase, par exemple, est un excellent outil pour cela. Il possède notamment une option

122

Chapitre 6 – Les risques de l’offshore

multisite permettant de synchroniser les référentiels distants. Ses principaux concurrents sont Merant PVCS et Continuus. Le prestataire doit s’assurer que tous les éléments et informations sont placés dans le référentiel. Chaque élément du référentiel ayant ses propres règles d’accès édictant qui a le 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 en offshore et le client. Ces différents moyens de partage d’informations ne sont pas interchangeables. Les référentiels sur un LAN, par exemple, comme ceux que proposent Telelogic ou IBM Rational, offrent la meilleure sécurité, mais à un coût important.

Référentiel sur un LAN isolé

Sécurité

Référentiel sur le LAN du partenaire

Serveur de messagerie

Répertoires partagés

Coût

Figure 6.1. Solutions de partage d’information

Les gestionnaires de documentation tels que Microsoft SharePoint peuvent jouer un rôle assez similaire pour rassembler l’information et en protéger l’accès. Les gestionnaires de référentiels tels que ClearCase permettent toutefois de gérer plus efficacement les opérations relatives au développement. On y trouve notamment des fonctionnalités de gestion d’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 workflow des corrections d’anomalie et des demandes d’évolution.

123

Conduite de projets informatiques offshore

Les serveurs de messagerie Les serveurs de messagerie recueillent eux aussi des informations confidentielles par le biais des messages échangés. Avec des équipes importantes, il est intéressant d’isoler le serveur de messagerie chez le prestataire de sorte à le dédier à l’équipe. Le gain en confidentialité est important. Si l’on ne met pas en place un serveur de messagerie dédié, le serveur de messagerie commun contient des informations du prestataire, du client et d’autres clients, lesquelles se retrouvent dans les sauvegardes. Le client n’a alors aucun contrôle sur la localisation et la gestion de ces sauvegardes. De plus, les administrateurs du serveur chez le prestataire peuvent 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 prestataire peut exiger l’application de procédures strictes pour en assurer l’administration sans risque. Le serveur de messagerie peut aussi garder les traces de tous les messages reçus et envoyés pour analyse en cas de problème. Ces traces sont accessibles à un administrateur de serveur.

Isolement des équipes Lorsqu’un projet mobilise une équipe importante en offshore, le client peut demander au prestataire d’isoler cette équipe du reste de la société. L’isolement est naturel en cas de création de filiale ou de joint-venture en offshore. Dans les petites équipes, de moins de vingt personnes, l’isolement des équipes et du réseau peut toutefois se révéler trop coû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 partenaire en offshore puis isoler physiquement le lieu où travaillent les collaborateurs du projet. On doit 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ègles d’isolement et des audits pour vérifier que ces règles sont appliquées. De cette façon, le client peut exercer un contrôle fin sur la gestion des serveurs, les sauvegardes et les droits d’accès. Ces mesures peuvent toutefois se révéler insuffisantes. Les serveurs, par exemple, sont toujours physiquement accessibles par tous les collaborateurs en offshore. Une personne mal intentionnée pourrait trouver le moyen de les pénétrer afin de récupérer des informations. De plus, le client ignorant comment le réseau est géré, il ne peut être certain qu’un niveau 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 prestataire ne 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 sauve- garde, etc.) et

124

Chapitre 6 – Les risques de l’offshore

la bande passante sur Internet. De plus, le réseau passant sous sa responsabilité, il lui faut certainement embaucher des administrateurs pour le gérer en offshore.

É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 font partie de l’équipe du client, elle aussi clairement dédiée, pour gérer les soixante ordinateurs de l’équipe. Le réseau doit être parfaitement isolé, avec des équipements, un serveur de messagerie et une bande passante sur Internet également dédiés. Les règles sont strictes et clairement exprimées par écrit. Après quatre mois de travail avec ces équipes, on s’aperçoit que la synchronisation du référentiel entre 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 responsable de l’informatique interne du prestataire maintient de fait un rôle de supérieur hiérarchique envers les administrateurs qui travaillent dans l’équipe dédiée du client, laquelle lui demande souvent des conseils pour la configuration de certaines machines. Constatant l’énorme quantité de bande passante inutilisée la nuit, ce responsable a mis en place un système autorisant les utilisateurs du 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 nombre d’employés téléchargent toutes les nuits musiques, films et programmes et saturent la bande passante. Il ne reste pratiquement plus rien pour les usages professionnels du client qui souhaite réaliser ses synchronisations de nuit. Sans audit, il aurait été impossible de détecter ces dysfonctionnements et d’y remédier. Des sondes et des outils recherchant les vulnérabilités ont ensuite été utilisés régulièrement pour détecter ces accès non autorisés.

Le contrôle des accès Pour s’assurer que les informations sont correctement protégées, on peut organiser l’isolement des équipes en offshore. Elles travaillent en ce cas dans des salles séparées, accessibles uniquement aux membres de l’équipe du client. Pour être efficace, ce système nécessite que l’accès aux locaux soit contrôlé par des cartes personnelles, qui identifient chaque personne entrante et sortante et mémorisent les heures de passage aux portes. Même si toutes les personnes concernées disposent d’une carte personnelle d’accès dans les locaux, encore faut-il qu’elles ne fassent pas entrer d’autres personnes. Certains systèmes sophistiqués proposent des sas à une personne, qui garantissent des accès physiques individuels. D’autres contrôlent les sens entrée et sortie afin que seules les personnes qui sont effectivement sorties puissent entrer à nouveau, évitant de la sorte le prêt de cartes. Des caméras peuvent être ajoutées au système pour contrôler les entréessorties. Toutes ces règles d’accès ne sont toutefois pas faciles à appliquer, et l’on constate souvent, à 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

125

Conduite de projets informatiques offshore

suffisamment importante pour que le prestataire lui dédie un étage entier, naturellement isolé 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 importantes et qu’on recherche un niveau de sécurité ou de confidentialité élevé. En isolant les équipes et le matériel et en les dédiant à l’activité du client, on parvient à se démarquer des règles en vigueur chez le prestataire et à appliquer les procédures qui conviennent le mieux.

Les fuites chez des concurrents Les clients peuvent craindre que le prestataire fournisse des prestations à un concurrent et 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 parties du code source, des informations sur le plan produit, etc. Un collaborateur passant d’un client à un autre ou, pire, une personne travaillant à temps partiel sur deux projets différents du prestataire peut transmettre de telles informations à la concurrence, sans toujours s’apercevoir de leur valeur. Certains contrats essaient de se prémunir contre de tels risques. Une autre solution consiste bien sûr à créer une filiale ou un joint-venture en offshore afin de contrôler pleinement les activités de la société. Il est aussi possible d’identifier les autres clients du prestataire et d’interdire éventuellement à ce dernier de travailler avec certains d’entre eux (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 informations confidentielles lui parviennent peut se protéger par contrat. Il est de la sorte possible d’interdire au prestataire de traiter avec des concurrents figurant nommément dans le contrat. Cette interdiction perdure 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 peut craindre que certains candidats à un emploi chez un prestataire ne cherchent à faire valoir non seulement leurs capacités propres, mais aussi le code source et autres éléments qu’ils ont emportés d’un emploi précédent. Malheureusement, certaines sociétés ne rejettent pas systématiquement de telles propositions et se laissent tenter. Dans de nombreux pays, les programmeurs quittent la société qui les employait en emportant leur code source, voire le code source complet du projet sur lequel ils travaillaient. Ils n’ont pas nécessairement l’intention de le réutiliser, mais ils le conservent en souvenir de leur travail. Certains d’entre eux vont parfois plus loin et réutilisent sans le dire dans de nouveaux projets des portions de code déjà produites pour peu que les technologies employées le permettent. Inutile de préciser que ces pratiques ne sont pas spécifiques de l’offshore et qu’on les constate aussi dans nos pays, où elles sont tout aussi difficiles à contrôler.

126

Chapitre 6 – Les risques de l’offshore

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 confidentialité précisant quelles sont les informations confidentielles, ainsi que les règles les concernant et les risques encourus par l’employé qui ne les respecteraient pas. La gestion du référentiel permet ensuite de savoir si une personne a tenté de retirer l’ensemble du contenu 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 à chaque collaborateur de signer un accord de confidentialité qui engage sa responsabilité personnelle en cas réutilisation de ce code dans d’autres réalisations.

Protection de la méthode Certains 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 donnent un avantage concurrentiel. Il est essentiel pour eux que la valeur attribuée à la méthode soit perçue comme telle par le prestataire. Ces éléments sont particulièrement vulnérables en offshore. La confi dentialité des méthodes est 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’imaginent simplement 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 et d’ajouter les méthodes aux informations confidentielles clairement identifiées dans l’accord de confidentialité.

Augmentation brutale des coûts des prestations Un prestataire offshore peut souhaiter augmenter le tarif de ses prestations, par exemple lorsque les salaires des informaticiens connaissent une hausse brutale dans le pays. De telles situations résultent généralement de l’âpre concurrence que se livrent les prestataires ou d’une demande accrue liée à l’implantation de grandes sociétés étrangères. Il se peut aussi que l’inflation en dollars engendre une forte réduction du pouvoir d’achat. Le prestataire souhaite en ce cas ajuster ses tarifs pour retrouver la valeur de sa facturation en début de contrat. Certains contrats prévoient d’ailleurs d’indexer les prestations sur le taux d’inflation en dollars ou en euros. Quelles qu’en soient les raisons, il arrive que le prestataire exprime le besoin d’augmenter fortement 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 en dollars ou en euros. Faute de cela, le prestataire risque de ne plus retrouver sa marge dans les prestations fournies.

127

Conduite de projets informatiques offshore

Il n’est pas rare que le prestataire demande une réévaluation de ses tarifs parce qu’il a fait une proposition initiale trop basse afin d’obtenir le contrat. Il attend généralement un an avant de demander un tel ajustement et masque les véritables raisons du problème derriè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 prestataire peuvent aller du simple au double, voire davantage si la comparaison porte sur des prestations au forfait et en régie. Certains projets calculés au plus juste au commencement du contrat ne génèrent plus aucune marge. Le risque est alors que le prestataire se désintéresse des projets à faible marge et en retire les meilleurs de ses collaborateurs pour 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 par rapport à ceux pratiqués par son prestataire avec d’autres clients car il n’en aura que pour son argent. Pour accepter ces tarifs, le prestataire a dû recruter les candidats qui acceptaient les salaires les plus bas, les meilleurs profils et les plus stables ayant échu aux autres 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 à ceux appliqué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. Le personnel 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é s chez 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êtes afin de les ajuster. Le client aurait tort d’ignorer systématiquement ces requêtes, car certaines demandes d’ajustement peuvent être justifiées. C’est le cas, par exemple, lorsque le client a négocié des conditions spéciales pour couvrir une période financièrement difficile 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 la table et exiger l’ajustement, en menaçant de ne pas livrer les codes source et autres livrables, voire de dissoudre l’équipe. Le client porte alors sa part de responsabilité dans la crise. En ignorant les demandes du prestataire, il s’est exposé au risque de voir ce dernier préférer arrêter un partenariat qui ne lui apporte pas de marge. Il ne s’agit pas là vraiment d’un chantage.

Monter deux équipes en offshore Pour se prémunir de tout risque en offshore, il est envisageable de monter deux équipes chez 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âches sur l’autre, et ce, d’autant plus facilement que les règles de codage, de documentation et de 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 est beaucoup plus délicate, les problèmes de communication, de synchronisation et surtout

128

Chapitre 6 – Les risques de l’offshore

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 de monter deux équipes de taille comparable, qui collaborent au même projet. Les réalisations sont distribuées sur les équipes de façon à confi er à chacune un ensemble fonctionnel 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é pour construire le produit final. On atteint de la sorte plusieurs objectifs : on s’assure une solution de repli si l’un des prestataires venait à se révéler défaillant, et aucun des deux sites ne dispose de la totalité du produit, ce qui est un gage de sécurité. En revanche, les projets doivent être synchronisés entre les équipes, et les points de dépendance des réalisations doivent être gérés avec précision. Cette organisation ne manque pas de créer une concurrence entre les équipes, qui, bien gérée, peut se traduire par une augmentation de la productivité de chaque équipe. Elle peut à 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 équipe ou 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, beaucoup plus petite. L’essentiel des réalisations est donné à l’équipe principale, la seconde se voyant confier de petites réalisations indépendantes ou peu importantes. Il importe en ce cas de s’assurer que la petite équipe connaît le produit et les méthodes en vigueur. En cas de 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 sur l’é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 concurrence, car les réalisations des deux équipes sont directement comparables, et le travail de la meilleure équipe part en production, sanctionnant ainsi l’équipe perdante. Une épée de Damoclès pend sur l’équipe la moins performante, qui risque à tout moment de se voir dissoute sans que cela affecte le moins du monde les réalisations du client. Le gain en productivité 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 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.

Une équipe principale et une petite équipe de repli

Deux équipes effectuant les mêmes réalisations

Similaire à une équipe unique

Concurrence très forte en permanence et compétitivité accrue

129

Conduite de projets informatiques offshore

Tableau 6.1. Avantages et inconvénients de la création de plusieurs équipes en offshore(suite) 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 partagé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 équipes 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 application 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.

Impact sur les coûts

Les surcoûts sont surtout organisationnels (déplacements 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 offshore. Les déplacements sont également doublés.

Les paiements du client Nous avons déjà abordé certains effets de l’absence ou du retard de paiement des factures du prestataire par le client. Les réactions du prestataire sont, dans l’ordre, de bloquer les livrables, de menacer de dissoudre l’équipe, de dissoudre effectivement l’équipe et disposer du produit à sa convenance. Il est rare qu’il décide de poursuivre son client, sauf dans 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 pas payer son prestataire. Le conflit peut avoir pour origine des clauses contractuelles non respectées, une productivité anormalement basse ou encore un taux de démission ou de licenciement révélant un problème de management local. Il vaut alors mieux payer le prestataire partiellement de façon à exercer une pression forte mais raisonnable pour le contraindre à honorer ses engagements.

Les retards de paiement Comme expliqué au chapitre 3, le fait de payer en retard résulte le plus souvent en un retard de paiement de l’équipe offshore. La régularité des paiements est donc un des facteurs les plus appréciés des prestataires comme des collaborateurs. Un client qui fait de son mieux pour régler au plus tôt le prestataire est d’autant mieux valorisé et donc servi. De plus, la régularité des paiements peut venir compenser en grande partie une marge faible et faire en sorte que le client ne soit pas négligé.

130

Chapitre 6 – Les risques de l’offshore

Payer dans les temps n’est pas toujours chose facile. Si les éléments pour établir la facture sont un tant soit peu complexes  bien souvent, elles prennent en compte le nombre de jours travaillés par collaborateur, mais aussi les vacances, les heures supplémentaires et des éléments refacturés à prix coûtant , le prestataire peut facilement commettre des erreurs de facturation. Certaines erreurs sont difficiles à détecter. Par exemple, il se peut que l’on ait défini par contrat un nombre de jours de congé annuel minimal pour les collaborateurs et qu’aucun d’eux ne puisse être facturé sur l’année pour plus de jours que le maximum défini. Pour vérifier la facture, le client doit pointer pour chaque collaborateur le nombre de jours de congés qu’il a effectivement pris afin de vérifier qu’il n’est pas facturé au-delà de ce qui est prévu ou encore vérifier qu’un jour férié en offshore n’apparaît pas comme un jour travaillé. Les corrections de factures peuvent générer de nouvelles erreurs. Le temps s’écoule alors sans engager de paiement. Si un décideur est en vacances, en voyage ou simplement peu disponible, les allers-retours prennent parfois des semaines, pendant lesquelles les collaborateurs 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 risques d’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 prix d’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éismes majeurs. Les événements politiques qui ont marqué la fin du régime de Ceausescu en Roumanie ont à peine perturbé les prestations des équipes roumaines en offshore. Il en est allé de même en Ukraine, où les manifestations massives de contestation de l’élection pré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 des sociétés clientes refusent de se rendre sur place. Cela concerne de très nombreux pays, et mê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 situations à risques est le refus des chefs de projet locaux et autres collaborateurs de se rendre chez le prestataire.

Les licences des outils de développement Le risque juridique que fait peser l’emploi par le prestataire de logiciels sans licence est difficile à évaluer. Dans la plupart des pays de l’offshore, en effet, les droits d’utilisation

131

Conduite de projets informatiques offshore

des logiciels sont pour le moins équivoques, et l’on trouve des éditions complètes de Windows XP, Oracle Server ou Microsoft Exchange Server, par exemple, pour quelques dollars. Il ne s’agit pas pour autant de versions pirates, puisqu’elles comportent les timbres ou hologrammes attestant que des droits ont été versés au gouvernement sur la vente de ces marchandises. La crainte d’être poursuivi pour avoir bénéficié de licences illégales est loin d’être infondée. On peut s’en protéger en exigeant par contrat que les logiciels mis à la disposition du client soient acquis en pleine conformité avec les lois du pays. Le prestataire, et non le client, est tenu de s’assurer que cette clause est respectée. On peut aussi demander confirmation é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 sans licences soient vendus en toute légalité dans des magasins officiels et en perçoivent les taxes 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 prestataire utilise ont été acquises en toute légalité. Certaines licences en apparence légales peuvent 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’une simple vérification que les licences sont légalement acquises. Il n’en va pas de même si le réseau est dédié à un client, dans une filiale ou dans un joint-venture, par exemple. Le client 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’il s’assure de la légalité de toutes les licences. Il est cependant peu probable qu’une organisation quelconque dans un pays de l’offshore ait les moyens de contraindre un prestataire à se soumettre à un audit pour vérifier la lé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 le client gère son propre réseau dédié, c’est à lui de faire la preuve qu’il a acquis les licences des logiciels qu’il utilise.

Les licences apportées par le client Une difficulté symétrique concerne les licences des logiciels apportés par le client afin d’être utilisés en offshore. Dans ces pays, le marché parallèle des logiciels  qui est en fait le marché principal  est à l’affût de toutes les nouvelles versions des produits. Il y a donc un risque que la version apportée par le client devienne la souche de duplications illicites. Pour les logiciels de très grande diffusion, comme les systèmes d’exploitation, les suites bureautiques, la CAO ou l’édition de vidéos, les pirates trouvent très facilement les sources qui leur permettent de sortir les versions récentes sur les marchés parallèles en même temps voire avant leur sortie officielle. En revanche, certains logiciels professionnels

132

Chapitre 6 – Les risques de l’offshore

coûteux ne sont pas toujours disponibles rapidement sur ces marchés. Lorsqu’un client de l’offshore arrive avec un produit réputé rare, il se peut que celui-ci soit immédiatement copié pour être revendu à des structures qui se chargent de le dupliquer. Les moyens de lutte contre les experts du piratage que l’on trouve dans ces pays étant généralement inopé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 efforts raisonnables pour protéger les licences mises à sa disposition, d’autant plus si le produit dupliqué 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 exiger que le prestataire et les collaborateurs les protègent d’une diffusion frauduleuse.

Retrait des protections des logiciels Lorsqu’on apporte un produit logiciel en offshore, on est fréquemment surpris d’entendre les administrateurs réseau demander s’ils peuvent en déployer une version sans protection, beaucoup plus facile à gérer, quand ils ne le font pas de leur propre chef, sans même poser la question. Le paradoxe est que les limitations des verrouillages pénalisent ceux qui ont acquitté les licences alors que ceux qui utilisent ces mêmes produits piratés les déploient et les réinstallent comme ils le souhaitent. Les textes qui accompagnent les licences précisent souvent que l’on ne doit pas essayer de retirer les systèmes de protection. On a beau informer les services informatiques internes du prestataire qu’ils doivent déployer les licences conformément aux directives de l’éditeur, on constate bien souvent dans la réalité que les produits ont été déployés sans protection. Il suffit pour s’en convaincre de demander un redéploiement et de constater que celui-ci ne fait l’objet d’aucune question posée à l’éditeur, alors même que les méthodes de verrouillage employées sur ces logiciels demandent d’entrer des numéros fournis 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 3 pour 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 risques d’incompréhension des objectifs des réalisations en offshore, surtout si la société n’a pas l’intention de se séparer de ces équipes pour les délocaliser. En l’absence de communication, 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’utilisation de ressources en offshore, dans laquelle ils ne voient que la menace que les employé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 pourra mieux se placer face à ses concurrents, que l’intérêt des employés locaux pour leur travail s’en trouvera renforcé en leur permettant de se concentrer sur les tâches les plus créatives ou que cet apport à la capacité de production nécessitera davantage de ressources locales

133

Conduite de projets informatiques offshore

et résultera probablement en embauches, on n’évitera pas complètement les risques de rejet par les équipes locales. Une bonne communication interne peut réduire considérablement ces risques, surtout si elle est poursuivie dans le temps et non ponctuelle. Si la société fait la preuve que ses 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 en démontrant qu’elles n’auraient pu l’être autrement. EN RÉSUMÉ Inquiétudes du personnel local

Lorsqu’une société commence à travailler avec un prestataire en offshore, sa communication locale est indispensable pour réduire les inquiétudes du personnel. Une communication réussie met en avant les avantages que l’entreprise et ses employés en retireront.

Un changement de méthodologie et d’organisation du développement visant à intégrer une démarche industrielle peut susciter le malaise chez certains membres des équipes de développement. Comme expliqué précédemment, ce sont les profils polyvalents qui sont les plus inquiets, car une telle réorganisation réduit le plus souvent leur poste, auparavant transversal, à une fonction. L’expérience prouve toutefois que ces personnes démissionnent rarement, surtout si le management prend soin de leur confier des missions valorisantes. D’une façon générale, le passage à l’offshore s’effectue plutôt bien, après une période de crise inévitable mais rarement longue.

Conclusion La meilleure façon de limiter les risques de toute nature avec un prestataire en offshore est 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 permanence la marge du prestataire ou investit en audits pour vérifier que les directives sont appliquées, la relation de partenariat se détériore immanquablement. La contrainte devenant externe au prestataire, celui-ci porte moins d’attention à protéger les intérêts de son client. Lorsque le prestataire réalise que son partenariat est solide et fiable, il souhaite s’y investir à long terme, et les opérations se déroulent mieux. Les audits deviennent dès lors pratiquement inutiles, le prestataire défendant les intérêts du client en même temps que les siens.

134

PARTIE

2

Préparation des projets en offshore La première partie de l’ouvrage a introduit la culture de l’offshore et décrit le fonctionnement et les motivations des prestataires qu’on y rencontre. La présente partie aborde la préparation des projets en offshore, qui commence par le choix du projet à confier au prestataire. En association avec ce projet, le client doit aussi choisir un mode de fonctionnement convenant à la fois à ses préférences et à la nature du projet à réaliser. Une fois choisi le projet à réaliser en offshore, vient la question essentielle du choix du prestataire, qui découle pour l’essentiel des préférences du client et du type de projet à réaliser. C’est un choix déterminant, car selon la localisation, et donc la culture, du prestataire, certains modes de fonctionnement sont permis tandis que d’autres sont interdits. La mise au point du contrat qui lie le client et le prestataire constitue la dernière étape de cette phase préparatoire. C’est une étape cruciale, qui doit permettre de définir les détails de la coopération avec le prestataire concernant tout à la fois le fonctionnement quotidien, les éléments facturables, la gestion des 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 de réunir les conditions du succès. Trop permissif, il donne lieu à des dérives, que l’on ne parvient plus à contrôler. Le bon équilibre est difficile à atteindre, et l’on ne peut y parvenir que par une gestion précise de tous les éléments qui le constituent. Cette partie s’achève sur les grands principes qui président à la gestion de projet en offshore.

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 fonctionnement de l’offshore et de la mentalité des collaborateurs dans ces pays que du choix du projet et de l’organisation mise en place pour le mener à bien. Ce chapitre se concentre sur 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 de la société soutient le projet et en connaît les objectifs et les conditions. Si les orientations sont mouvantes, certaines décisions importantes peuvent être remises en question, mettant parfois en danger le projet dans sa totalité. Par exemple, si le management considère la sécurité sur le site en offshore comme une priorité, il peut s’inquiéter qu’un projet n’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 ses multiples 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 : choix du projet, du prestataire, des équipes et des collaborateurs en interne, communication auprès des autres équipes, outils de gestion de projet, sécurité, investissements, etc. Si le comité découvre les problèmes au fur et à mesure qu’ils se posent, les décisions peuvent être remises en question. Dans certaines sociétés, cette décision doit remonter jusqu’au conseil d’administration à titre de direction stratégique. Les enjeux stratégiques de 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’est pas traitée dans le présent chapitre, bien qu’elle relève au premier chef de l’évaluation du projet.

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 le succès des opérations en offshore. Il a de nombreuses raisons d’y être a priori opposé.

137

Conduite de projets informatiques offshore

Il peut percevoir cette initiative comme une perte de contrôle ou d’influence sur le développement et estimer qu’elle met en cause la qualité du travail passé. Il peut aussi s’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 situation d’échec. Si le responsable R&D est motivé par les réalisations plus que par les coûts, il est vraisemblable 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 clairement à réaliser plus et à garantir la flexibilité de ses ressources, même si l’opération comporte certains risques. Dans la plupart des cas, un responsable R&D gère l’utilisation d’un budget. Il réalise avec fiabilité certains développements en utilisant les ressources à sa disposition et cherche à obtenir la meilleure productivité localement. Il peut se montrer exigeant, demander plus de travail 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ètement différente. Le responsable R&D raisonne souvent en évolution par petits pas. L’acquis est rarement mis 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 nouvelle technologie 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 fonctionnement 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 en offshore 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 fait pas partie du comité de direction et que son avis ne soit connu qu’une fois la décision arrê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 des questions 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 Implication en offshore

Question

Importance

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

138

Chapitre 7 – Évaluer son projet pour l’offshore

Tableau 7.1. Questions stratégiques concernant l’offshore(suite) Catégorie Budget

Sécurité

Projet test

Management

Prestataire offshore

Méthodologie et procédures

Question

Importance

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

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

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

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

Quelle méthodologie veut-on mettre en œuvre ? La méthodologie locale peutelle ê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

139

Conduite de projets informatiques offshore

Tableau 7.1. Questions stratégiques concernant l’offshore(suite) Catégorie Formation et conseil

Outils de suivi de projet

Question

Importance

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

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

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 de communiquer en interne sur l’initiative de l’offshore. Celles-ci doivent être consignées par écrit et conservées avec une confidentialité raisonnable. Si l’on change d’avis sur certaines d’entre elles, les solutions devront probablement être revues ou remises en question. Un des points essentiels de ce questionnaire est de déterminer ce que représente l’initiative de l’offshore pour la société. Ces développements distribués se limiteront-ils à des dé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’on considère le prestataire comme une force d’appoint utilisée par période ou qu’il s’agit de construire un ensemble de ressources à utiliser pour la majorité des réalisations. Sans une définition globale des objectifs, il est très difficile de démarrer les opérations de préparation de l’offshore. Pour éviter de payer cher les premières expériences, il est utile de se faire accompagner par des personnes qui ont une réelle expérience de l’offshore. Les conseils de telles personnes 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 budget puisse 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 du prestataire en offshore, et l’on néglige la gestion de projet, les équipements, les déplacements, les formations, la communication, etc. À ce stade, il ne s’agit pas nécessairement de calculer tous les coûts mais d’avoir une idée générale des investissements et des coûts de fonctionnement de l’offshore. Si le budget est limité, les mêmes solutions ne seront pas les mêmes que si le projet est considéré comme stratégique, notamment pour la gestion du référentiel et de la sécurité. Pour chaque sujet, il est bon d’établir rapidement une limite haute et basse des investissements auxquels on souhaite consentir.

140

Chapitre 7 – Évaluer son projet pour l’offshore

Le tableau 7.2 récapitule les principaux sujets ayant un impact budgétaire significatif sur le projet offshore, au-delà des coûts directement liés aux réalisations. Tableau 7.2. Questions concernant les principaux postes budgétaires Catégorie Gestion de projet et formation

Question 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 ?

Prestataire offshore

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é ?

Dès que les décisions sont suffisamment définies, le budget est établi pour chaque mois afin de mieux en comprendre la répartition dans le temps. À cette étape, il s’agit surtout de vérifier que les décisions sont compatibles avec les moyens et les budgets.

141

Conduite de projets informatiques offshore

Sécurité La sécurité est un sujet critique au commencement du projet mais qui faiblit fortement dè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 attitude 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 les projets en offshore. Le tableau 7.3 récapitule les questions à se poser pour construire le niveau 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 Prestataire offshore

Référentiel

Authentification et communications

Contrat

Présence sur place

Question

Décision

Coût

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

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

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 communiquer entre le prestataire et le client ?

Sécurité

1

Faut-il concevoir un contrat contraignant pour assurer la sécurité ?

Sécurité

0

Veut-on mettre en place un engagement personnel de confidentialité ?

Sécurité

0

Veut-on assurer une présence sur place chez le prestataire ?

Sécurité

3

142

Chapitre 7 – Évaluer son projet pour l’offshore

Le projet de test Décider de démarrer avec un projet test revient souvent à ne pas décider réellement ce que l’on souhaite faire et à différer la décision de s’engager. Le projet démarre alors dans un environnement flou, et l’on ne construit pas vraiment la base des projets futurs. Si les choses ne sont pas gérées convenablement, il est possible que l’on ne tire pratiquement aucune 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 les conclusions que l’on souhaite en tirer et de mener le premier projet de façon à obtenir l’éclairage désiré. Par exemple, si l’on veut juger de la capacité du prestataire à appliquer une certaine méthodologie ou de la productivité de l’équipe, il faut mettre le prestataire en condition. De même, il faut que le projet reçoive un niveau d’attention suffisant de la part du client de l’offshore pour atteindre un succès raisonnable. Si le premier projet, qui est toujours plus 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’un premier projet. Il compare l’enseignement que l’on peut tirer d’un premier projet test à un projet futur au forfait et en régie. Tableau 7.4. Capacité d’évaluation des qualités du prestataire sur un premier projet test Évaluation pour un projet au forfait

Évaluation pour un projet en régie

Basse

Haute

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

Basse

Moyenne

Moyenne

Moyenne

Sujet à estimer sur un premier projet test Qualité de l’équipe en offshore Fiabilité du travail réalisé

Capacité à travailler de façon itérative Capacité à gérer efficacement les intégrations

143

Conduite de projets informatiques offshore

Tableau 7.4. Capacité d’évaluation des qualités du prestataire sur un premier projet test(suite) Évaluation pour un projet au forfait

Évaluation pour un projet en régie

Haute

Haute

Moyenne

Haute

Capacité à créer des cas d’utilisation pour les développements

Basse

Haute

Capacité à gérer efficacement le changement

Basse

Haute

Moyenne

Moyenne

Basse

Haute

Sujet à estimer sur un premier projet test Entente entre le client et le prestataire et bonne ambiance de travail Capacité à assimiler le domaine fonctionnel du client

Organisation et qualité des tests Le succès du premier projet laisse-t-il présager du succès des opérations futures ?

D’autres critères, particuliers pour chaque client, peuvent être évalués lors des premiers projets tests, comme la capacité à traiter des informations en français, la qualité des déploiements, etc.

Choix du projet de test Si l’on souhaite effectuer un test avec le prestataire offshore, il faut être en mesure d’en tirer les enseignements attendus. Dans la réalité, démarrer un projet de test au forfait pour 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égie avec des règles de fonctionnement strictes, afin de bien évaluer son équipe. Généralement, on choisit un petit projet assez facile à définir, avec des caractéristiques proches de celles qui font un bon projet au forfait. On y applique cependant les règles de fonctionneme nt d’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ération durant souvent entre quatre et six semaines. Il faut parvenir à valider le travail itératif et les iteration assessments. L’équipe doit comporter au moins quatre ou cinq développeurs pour 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’on souhaite utiliser par la suite. Si le prestataire n’en possède pas, il peut être judicieux de se 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 de la 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 test en leur suggérant des voies possibles.

144

Chapitre 7 – Évaluer son projet pour l’offshore

La taille du projet doit être compatible avec tous ces éléments. La nature fonctionnelle du projet de test ne doit pas être particulièrement bloquante par sa complexité ou sa dépendance avec d’autres applications. Il est bon que le projet soit aussi isolé que possible de toute dépendance externe, faute de quoi l’on ne jugerait plus vraiment de la capacité de l’offshore.

Démarrer avec un vrai projet important Lorsqu’on choisit de ne pas tester le prestataire en offshore mais de démarrer directement avec un vrai projet, ce que de nombreux clients choisissent lorsqu’ils souhaitent travailler 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 bien spécifié. Une réécriture d’un produit existant est toujours un bon choix pour un premier projet, 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, par exemple, qu’un débat soit toujours en cours sur le choix de Microsoft .Net ou de Java.

Définir les objectifs Il 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 projet et 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 point de 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 projet en offshore est primordial. Dans tous les cas, à l’exception des projets au forfait, il est pré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 à vingt développeurs, accompagnés de cinq à dix testeurs pour une application de gestion. Le chef de projet est aussi accompagné chez le client de mentors (architectes et experts méthodologiques) pour suivre les sujets techniques, fonctionnels et organisationnels. Le responsable fonctionnel est le responsable des spécifications. C’est lui qui valide les changements 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 de n’ê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 des réalisations en offshore chez le client. Ces rôles peuvent bien entendu être répartis sur plusieurs personnes.

145

Conduite de projets informatiques offshore

Tableau 7.5. Rôle du chef de projet chez le client Rôle Connaître l’équipe gérée

Description 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 responsables 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, communications, obligations du prestataire non respectées, etc.). Maintenir à jour son équipe sur la vie de l’entreprise, les priorités, etc.

146

Chapitre 7 – Évaluer son projet pour l’offshore

Le chef de projet doit sans doute se rendre en offshore entre une fois par mois et une fois par 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 personnes de 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 considèrent que les personnes en offshore sont a priori moins compétentes.

Placer un représentant du client chez le prestataire Une décision très importante dès avant le commencement des développements concerne la façon dont on souhaite gérer l’équipe en offshore. Naturellement, le client pense qu’il obtiendra un meilleur contrôle en plaçant une personne à lui en offshore. Comme nous l’avons vu, cette personne envoyée dans le pays de l’offshore ne peut se substituer au chef de projet chez le client. La fonction principale du chef de projet est de garantir la fluidité du travail en assurant une bonne communication entre le personnel en offshore et les personnes impliquées sur le projet chez le client. Il est en quelque sorte l’avocat du prestataire chez le client. Un repré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écurité. Elle vise à vérifier la façon dont les directives sont appliquées et à contrôler la discipline locale. Comme expliqué au chapitre 4, on recherche avant tout une relation de confiance et de transparence avec le prestataire. Tous les collaborateurs du client qui souhaitent travailler avec des équipes en offshore se tournent naturellement vers le chef de projet que le client a envoyé sur place. Les équipes en offshore se trouvent totalement masquées par celui-ci, qui est le seul point de contact des collaborateurs du client. Comme il n’y a plus de 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 pour mission de suivre les opérations et de prendre les décisions. Se sentant moins exposé, le prestataire propose moins volontiers de faire des efforts pour atteindre certains objectifs ou 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 chez les prestataires en offshore, sauf dans les filiales ou les joint-ventures. Par contre, il est toujours 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 de certains membres de l’équipe offshore chez le client, pour suivre une formation, par exemple, 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 que cette dernière soit bien choisie. Il convient d’éviter autant que possible l’effet d’écran sur les opérations en offshore. L’envoyé du client doit non pas s’impliquer directement dans la gestion de projet, mais se concentrer sur le suivi méthodologique et l’application des rè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ès quelques mois sur place, celui qui en a la charge risque de se sentir absorbé par l’équipe distante et d’en devenir un membre à part entière. Il doit donc rester vigilant et être capable en toutes circonstances de faire appliquer les procédures. Il doit en outre avoir

147

Conduite de projets informatiques offshore

une pratique affirmée des développements informatiques afin d’être à même de prendre des 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 de réduire la transparence recherchée. En cas de décision en ce sens, le choix de la personne pour ce poste doit être effectué avec soin afin d’éviter cet effet d’écran et d’être vraiment utile chez le prestataire.

Se faire accompagner pour démarrer l’offshore Certains consultants expérimentés sur l’offshore peuvent aider à monter les équipes qui conviennent. Beaucoup de ces consultants font partie de sociétés qui représentent ellesmê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 à disposition leur expertise afin de donner au client de meilleures chances de succès, dès ses premiè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 prestations offshore en aidant le client non seulement à estimer précisément le budget de ses opérations, mais aussi à faire les choix adéquats, que cela concerne le chef de projet, l’organisation ou le suivi de projet. Certains consultants peuvent intervenir dans la durée pour assurer le suivi d’un projet et corriger les procédures afin qu’elles s’adaptent à l’esprit du client et aux types de projets qu’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 en outre 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 œuvre est 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 avec suffisamment de soin pour pouvoir être exportés facilement. Les objectifs pour lesquels ils sont conçus se limitent le plus souvent à assurer une certaine formalisation de la production 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 recommande plutôt pour ma part d’utiliser les méthodologies éprouvées du marché, comme

148

Chapitre 7 – Évaluer son projet pour l’offshore

RUP (Rational Unified Process), XP (eXtreme Programming) et quelques autres, qui offrent l’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 avec l’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éthodologie 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 par un consultant expérimenté, qui aidera à se concentrer sur les éléments réellement importants. 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 disposer immédiatement d’une documentation complète et cohérente à adapter au projet et à la culture de l’entreprise.

On peut aussi choisir de ne pas utiliser de méthodologie formelle. On se concentre en ce cas sur certains éléments de reporting ou certains principes que l’on applique en dehors de tout cadre strict. On adopte en ce cas une attitude essentiellement réactive pour corriger chaque problème lorsqu’il se pose. Le choix de la méthodologie et des procédures est une décision essentielle. Elle influence directement le choix du prestataire et les premières actions à entreprendre lorsque l’équipe est créée. Certains prestataires ne sont pas suffisamment stricts pour travailler avec des méthodologies ou ne veulent appliquer d’autres procédures que les leurs.

Formation et conseil Avant de se lancer dans un projet en offshore, il est nécessaire d’évaluer les formations qui 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 envisagés avant le démarrage d’un projet. Tableau 7.6. Formations et conseil à l’offshore Domaine

Commentaire

Lieu

Formateur/consultant

Formation

Formation fonctionnelle sur le domaine traité. Des rappels peuvent être nécessaires par la suite.

Offshore

Responsable fonctionnel

Chefs de projet, développeurs, testeurs

Formations techniques dans le cas où l’on utilise des fondations techniques existantes.

Local ou offshore

Responsable technique

Équipe technique

149

Utilisateur

Conduite de projets informatiques offshore

Tableau 7.6. Formations et conseil à l’offshore(suite) Domaine

Commentaire

Lieu

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

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éthodologie

Local et offshore

Consultant extérieur

Sélection des équipes 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

Conseil

Formateur/consultant

Utilisateur

Cet accompagnement doit être défini avant de commencer à monter les équipes en offshore afin d’organiser au plus tôt les formations. Celles qui auront lieu chez le prestataire peuvent prendre du temps si un visa est nécessaire et si des supports de formation doivent être envoyés sur place.

Outils de suivi de projet Le choix des outils de suivi de projet est également à engager avant le commencement du projet. Pour les projets importants, ces outils conditionnent souvent le succès des opérations. Les deux outils les plus importants sont la gestion de référentiel et la gestion des anomalies et du changement. Les anomalies sont les points du développement qui ne sont pas conformes aux spécifications. Le changement correspond aux modifications des spécifications non conformes aux attentes des utilisateurs. Chez certains éditeurs, les outils de gestion des anomalies et du changement sont parfois sé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 pour passer d’une version à une autre. Chez IBM Rational, une option de ClearCase (gestion de

150

Chapitre 7 – Évaluer son projet pour l’offshore

la configuration) permet la synchronisation à travers plusieurs sites (ClearCase Multisite). Cette fonctionnalité est particulièrement utile pour assurer la réplication des informations. Ces outils représentent un investissement non négligeable. Certains modes d’utilisation permettent de réduire le coût des licences, mais au prix d’une perte de finesse des informations. Par exemple, au lieu de disposer de licences individuelles, on peut souscrire des licences 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 également très utiles. D’autres outils, comme ceux de gestion des exigences, permettent de suivre les exigences d’un produit, de garder les liens avec les livrables qui en découlent et de leur donner 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 ou partie de ces outils et de définir globalement le budget nécessaire. Si l’on n’utilise pas dé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 cherche pas encore à déterminer tous les détails de ces choix, mais on sait répondre aux questions les 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 ainsi que les conditions de sa réalisation. On a de surcroît un ordre de grandeur des dépenses et des sujets sur lesquels on investira pour travailler efficacement avec le prestataire. Le management de la société peut dès lors se prononcer en toute connaissance de cause sur la décision d’outsourcer le développement en offshore. Certaines questions posées dans ce chapitre sont primordiales pour jauger les chances de succès des développements en offshore. Si l’on n’est pas capable d’y répondre, cela donne une idée de l’embarras dans lequel les équipes chez le prestataire ou chez le client se trouveraient lors de la réalisation du projet. Par exemple, si l’achat d’un outil de gestion de référentiel est refusé alors que les objectifs de sécurité sont élevés, les chefs de projet se trouveraient à devoir atteindre des objectifs sans disposer des moyens nécessaires et déclareraient rapidement la mission impossible à réaliser. Une feuille Excel fournie en annexe reprend l’essentiel des questions posées dans ce chapitre afin d’évaluer le projet à réaliser. Ses entrées et pondérations peuvent être complétées ou modifiées en fonction des souhaits du client et de la réalité du projet.

151

Chapitre 8

Choisir le prestataire et les équipes offshore La proximité, la culture, la taille et le profil du prestataire déterminent directement le mode 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énements politiques et économiques du pays, et les membres de son personnel qui travaillent avec le 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 qui influencent ses décisions. Par exemple, si le pays a la réputation de ne pas respecter la propriété intellectuelle, le client mettra en place des règles de sécurité très strictes, et, s’il est réputé avoir un faible niveau d’éducation, il s’organisera pour concentrer les tâches complexes 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 prestataire et qu’il mise sur cette affinité personnelle, voire sur l’engagement du collaborateur, plutôt que sur un choix réfléchi. Parfois, le choix se porte sur l’Inde du fait de sa notoriété comme pays de l’offshore sans même envisager d’autres possibilités, de la mêm e façon que l’on choisit une marque sur sa réputation. Dans certains cas, le client recherche le prestataire ayant les meilleures compétences dans un domaine très précis. Il peut, par exemple, privilégier un prestataire qui fournit des développements à un éditeur de logiciels dont le client utilise les progiciels. Le fait d’avoir un interlocuteur qui connaît parfaitement les progiciels autour desquels il réalise des développements spécifiques offre probablement d’excellentes compétences. Dans d’autres cas, le client recherche des services ciblés, comme la création de scénarios de dessins animés accompagnant des jeux. Certains prestataires sont spécialisés dans des domaines fonctionnels pointus, comme les applications pour les opérateurs de télécommunications ou les développements relatifs 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 sur le pays et la ville du prestataire puis sur le prestataire lui-même et enfin sur la constitution des équipes. Cette dernière étape étant directement liée au choix du partenaire, la validation du partenariat tient compte également de la mise à disposition des premiers membres de l’équipe et de la façon de l’assembler.

153

Conduite de projets informatiques offshore

Critères de choix du prestataire en offshore Avant de choisir son prestataire, il importe de se poser les bonnes questions quant aux types 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 pour pouvoir choisir efficacement le prestataire. À ce stade, on liste les éléments à prendre en compte en prenant soin d’éviter toute idée pré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 Affinité pour certains pays

Commentaire 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 prestataire. 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.

154

Chapitre 8 – Choisir le prestataire et les équipes offshore

Le critère de la langue est évidemment déterminant si l’on choisit de travailler exclusivement en français ou dans une autre langue que l’anglais avec l’équipe offshore. Le choix du 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 ville du prestataire en moins de quatre heures et que l’on veuille au moins un vol par jour, le choix est évidemment plus limité. Si l’on souhaite de surcroît des communications pratiques, cela réduit le choix aux métropoles où l’on trouve des aéroports internationaux, les villes 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 le client 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’ensoleillement, 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 pays froids, 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 de l’offshore affichant, par exemple, souvent une préférence marquée pour ce pays, même si ses 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 fortement à un projet, voire le faire échouer. La mentalité du pays, les affinités culturelles éventuelles avec celui du client et la qualité des managers du prestataire sont les principaux facteurs de succès.

Décalage horaire et distance géographique Les 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’offshore et l’éloignement de l’Inde, de l’Asie et de l’Île Maurice. La notion de nearshore y apparaît avec évidence lorsque des clients européens travaillent avec des prestataires d’Europe de l’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 temps alors qu’on ne travaille pas chez le client. Avec sept heures de plus qu’en France, la Chine n’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 échange d’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 horaire avec la France limitent les communications interactives à quelques heures par jour.

155

Figure 8.1. Pays d’offshore et fuseaux horaires

Conduite de projets informatiques offshore

156

Chapitre 8 – Choisir le prestataire et les équipes offshore

Dans les pays d’Europe de l’Est et du Maghreb, au contraire, le décalage horaire varie entre 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 efficacement avec les États-Unis malgré un décalage horaire de douze heures. Ce décalage a toutefois fortement influencé les modes de fonctionnement avec ce pays des clients américains, qui choisissent presque toujours les développements au forfait. Dans ce mode, le prestataire prend plus pleinement la responsabilité des réalisations locales et n’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 un certain recouvrement avec le rythme de travail du client. Les prestataires d’Europe de l’Est commencent souvent leur journée à midi, par exemple, afin d’assurer un recouvrement maximal avec leurs clients. Pour les clients d’Europe de l’Ouest, un grand nombre de pays d’Europe de l’Est offrent d’excellentes conditions à environ trois heures de vol de Paris. Ils disposent de bonnes universités, d’un très grand nombre d’informaticiens très qualifiés et pratiquent des tarifs compétitifs, qui ne sont challengés que par certains pays d’Asie, comme le Vietnam, la Chine ou les Philippines. Les pays d’Europe centrale, tels que la Roumanie, la Pologne, la République tchèque, la Slovaquie et la Bosnie, pratiquent des tarifs significativement plus élevés, probablement du fait de leur rapprochement avec la Communauté économique européenne, lequel assure par ailleurs une plus grande sécurité pour la relation contractuelle, la stabilité politique et les lois en vigueur. Les pays du Maghreb et certains pays du Proche-Orient (Liban, Israël) offrent également des 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 de leur é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 attractive par rapport aux pays proches, même si cette destination hautement touristique a d’autres atouts à faire valoir. Le tableau 8.2 (au verso) recense les décalages horaires, distances, temps de vol, niveaux de coûts et langues de travail des principales destinations d’offshore. On peut y constater que de nombreux pays offrent une grande proximité avec la France. D’autres questions doivent évidemment être prises en compte, comme le service de transport aérien entre le pays du client et le site en offshore. La capitale est souvent beaucoup mieux desservie que les villes de province, qui nécessitent le plus souvent non seulement un changement d’avion, mais aussi d’aéroport, voire dans certains cas de se rendre sur place en train. La fréquence des vols est un autre élément discriminant pour juger de la facilité 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’Île Maurice, par exemple, est une destination touristique bien connue, qui éveillera toujours plus d’intérêt que Minsk ou Tallin. Favoriser l’aspect touristique peut toutefois se retourner contre le décideur chez le client. Pour peu que les réalisations en offshore connaissent des difficultés, il risque de se voir reprocher d’avoir fait le choix du soleil plutôt que de la productivité. À l’inverse, personne ne songera à critiquer le choix d’un pays froid, à l’attrait touristique limité, où le but des visites ne peut être que professionnel.

157

Conduite de projets informatiques offshore

Tableau 8.2. Pays d’offshore et décalage horaire avec Paris Décalage horaire**

Distance

Temps de vol *

Niveau de coût

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

Pays

Inde (Bangalore)

Langue de travail

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 pratiquées dans tous les pays et, lorsqu’elles sont appliquées, ne sont pas toujours déclenchées aux mêmes dates.

Si les sociétés américaines avaient eu la chance de disposer de pays d’offshore à trois heures de leurs centres de décision nationaux, on peut être certain qu’elles n’auraient pas hésité à leur confier leurs développements en offshore. Cette chance, nous l’avons en Europe 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 du prestataire. 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 mode régie. L’éloignement, qui rend le contrôle des équipes distantes plus difficile, favorise naturellement un fonctionnement au forfait.

La culture du pays Le choix du pays implique que l’on va vivre avec sa culture et ses habitudes. Il faut considérer ici la culture sous plusieurs aspects : quelle sera son influence sur la façon de travailler du prestataire, sur les collaborateurs du client qui se rendront sur place et sur les collaborateurs du prestataire que l’on invitera pour des formations ou des déploiements ?

158

Chapitre 8 – Choisir le prestataire et les équipes offshore

On s’intéressera d’abord à la facilité de compréhension réciproque des personnes qui doivent travailler ensemble et à l’efficacité que l’on peut imaginer en obtenir. Faute de cela, la distance culturelle a toute chance de jouer un rôle de frein à l’efficacité de la relation. La lisibilité des collaborateurs en offshore et la proximité culturelle avec eux sont des atouts évidents. Les collaborateurs du client ont généralement peu travaillé avec l’étranger, et les rares contacts professionnels qu’ils ont eus étaient certainement avec des Nord-Américains ou des Européens de pays limitrophes. Il est très improbable que tous 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 la France. Les Anglais trouvent pour leur part une affinité culturelle certaine avec l’Inde du fait de leur passé colonial dans ce pays. Si l’on a le choix, il vaut toujours mieux retenir des cultures proches.

Les déplacements en offshore Comme expliqué précédemment, la facilité à organiser les déplacements en offshore entre en ligne de compte dans les critères de choix du pays du prestataire. Il faut que les personnes appelées à se rendre sur place n’aient pas de problèmes particuliers pour accepter ces déplacements. Si la localisation du partenaire en offshore est agréable et ensoleillée, le collaborateur appréhendera sans doute ce voyage avec plaisir, surtout lors des premiers voyages, qui auront une dimension de découverte. La répétition des séjours devient cependant vite pesante 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 collaborateurs de se rendre chez le prestataire, surtout si l’on y constate une intolérance aux religions 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 des dé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égulièrement soumis à des menaces terroristes ou qui présentent un fort désordre social. Il est probable que durant les périodes où la sécurité est réduite, les chefs de projet refuseront de se rendre sur place. Même s’il est impossible de prédire comment les événements vont évoluer dans chaque pays, certaines destinations demeurent plus exposées que d’autres. Inviter les collaborateurs de l’offshore Il n’est pas inutile d’évaluer les conditions dans lesquelles un client peut inviter des membres 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éputation d’être des foyers de main-d’œuvre illégale. Les procédures pour faire venir ces collaborateurs 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 quelques mois, dans le pays du client. Par exemple, certains collaborateurs en offshore peuvent bénéficier dans leur pays d’une assistance permanente pour le ménage, la cuisine, etc., et se trouver perdus dans le pays du client sans cette assistance. Ce type

159

Conduite de projets informatiques offshore

d’habitude culturelle est évidemment impossible à généraliser, tant les modes de vie peuvent 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é, que ce soit pour des formations ou pour accompagner leurs livraisons. Les services de l’immigration veulent avant tout éviter que les informaticiens invités ne viennent remplacer des employés du client. Ils comprennent que certaines réalisations distantes doivent être accompagnées ou que des formations soient nécessaires lors de collaborations avec un partenaire distant. Ce qu’ils interdisent c’est que les sociétés qui emploient localement des collaborateurs de l’offshore payent des salaires sans commune mesure avec les usages locaux ou, pire encore, qu’elles facturent à leurs propres clients des services réalisés avec une maind’œuvre illégale.

La langue de travail Les clients français de l’offshore privilégient généralement les pays où l’on parle leur langue. Les seuls pays d’offshore vraiment francophones sont les pays du Maghreb et le Liban. Ailleurs, il est toujours possible de monter des équipes francophones, puisque le français est très répandu comme seconde langue vivante, mais ce critère de sélection limite 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édilection des jeunes ingénieurs. Il faut aussi considérer que le Maghreb, le Liban et la Roumanie sont des pays chers pour l’offshore en comparaison de certains pays d’Europe de l’Est. Le prix des prestations se situe le plus souvent autour de 3 000 euros par mois, voire davantage, alors que dans d’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 de travailler 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 un niveau 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’internationalisation, qui passe par l’adoption de l’anglais. L’offshore peut tout à fait s’inscrire dans cette tendance 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 langue peuvent ê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 incontournable chez le client. La plupart des pays de l’offshore utilisent l’anglais comme langue de travail principale. Le travail en anglais peut être tout à fait efficace, même lorsque les collaborateurs locaux ne le maîtrisent que de façon approximative. En choisissant l’anglais comme langue de travail, on peut travailler avec pratiquement tous les pays de l’offshore et obtenir ainsi des prestations aux meilleurs tarifs.

160

Chapitre 8 – Choisir le prestataire et les équipes offshore

Le système éducatif en offshore La qualité des universités et le nombre de diplômés sont essentiels pour choisir le pays où l’on souhaite trouver son prestataire. S’il est bien délicat de comparer des villes universitaires de pays différents, la taille et le dynamisme des universités techniques en offshore peuvent être mis en balance. On peut connaître le nombre de diplômés pour chaque université, repérer les équivalences avec des universités étrangères (qui sont rares), déterminer quelles sont les universités les plus désirables, etc. La réputation locale de certaines universités peut aussi donner une idée de leur qualité. On pourra confirmer cette estimation par l’évaluation des personnes rencontrées au cours des entretiens. Les villes, et parfois même les pays, qui ne possèdent pas une quantité suffisante de jeunes diplômés peuvent être incapables de fournir les ressources et compétences que l’on recherche. En contrepartie, on y trouve souvent la possibilité de constituer des équipes à des tarifs beaucoup plus bas. EN RÉSUMÉ Les villes universitaires

Il est fortement recommandé de travailler dans la capitale ou dans les grandes villes étudiantes où l’on a des chances de trouver de meilleures ressources en quantité suffisante. Les villes secondaires peuvent rapidement poser des problèmes d’embauche si l’on doit constituer des équipes rapidement.

L’offshore dans la durée Dans 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éduiront rapidement 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. Des pays tels que la Pologne, la République tchèque, la Hongrie et la Roumanie ont été considérés un peu rapidement comme des pays qui n’offriraient bientôt plus de réel intérêt pour l’offshore. Bien que plus chers que d’autres pays, ils ont tout de même préservé leur statut de pays d’offshore, et il est peu probable que cette situation change brutalement dans les années qui viennent. Les pays qui sont entrés ou qui vont entrer dans la Communauté économique européenne seront probablement plus rapidement en phase avec le reste de l’Europe occidentale, 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 de croissance é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 cabinets d’analyse de marché prévoient un triplement des salaires des informaticiens dans les années à venir, ce qui ne manquera pas d’être répercuté sur les tarifs des prestataires offshore. Il faut en tenir compte si l’on recherche un prestataire offshore stable.

Deux prestataires en offshore Dans certains cas, on peut vouloir monter deux équipes en offshore chez deux prestataires différents dans deux pays différents (voir le chapitre 7). Cela peut se révéler utile si l’un des pays vient à traverser une période de troubles.

161

Conduite de projets informatiques offshore

Pour basculer les projets d’un site sur l’autre, il faut utiliser une même méthodologie et de mêmes procédures sur les deux sites. Il faut en outre mettre en place des instruments méthodologiques 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 les voyages de l’une à l’autre. Par exemple, si l’on retient des pays d’Europe de l’Est, on peut choisir 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 prestataire de repli, recevant des tâches plus légères afin de le familiariser avec les procédures, la méthodologie et le formalisme retenus si le client devait décider de basculer le projet sur celui-ci. Cela permet de ne pas perdre en efficacité lors de la gestion de projet tout en préservant une solution de rechange immédiatement applicable. Certaines sociétés ont pour philosophie de ne pas donner la tierce maintenance applicative, ou TMA, au prestataire qui réalise la solution, afin de mieux garantir la qualité de la documentation et la maintenabilité du produit. On peut aussi appliquer ce principe en offshore en choisissant deux prestataires, l’un réalisant la création de la solution, l’autre la TMA. Durant la phase de réalisation, le prestataire devant assurer la TMA peut se trouver 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 pays avec 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 souhaite travailler, notamment au forfait ou en régie, car ce sujet doit être immédiatement abordé 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 moins structurée. L’effort de structuration de la sélection est cependant toujours préférable, car cela affiche clairement le professionnalisme du client.

La demande d’informations au prestataire offshore Quels que soient les objectifs du client, il est souhaitable de les exposer dans un document, 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é en préambule à l’accord de partenariat, afin de rappeler en cas de besoin les raisons de la sé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, comme la mise en place d’une méthode ou de règles de sécurité strictes ou encore l’isolement de l’équipe. Ce document doit être très synthétique et ne pas dépasser une vingtaine de pages. Certains prestataires peuvent se révéler incapables de respecter certaines directives du client ou ne pas souhaiter travailler ainsi. Il importe donc de recevoir des réponses écrites, qui évitent les interprétations.

162

Chapitre 8 – Choisir le prestataire et les équipes offshore

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 disposer 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.

163

Conduite de projets informatiques offshore

Tableau 8.3. Sujets traités dans le RFI envoyé au prestataire offshore(suite) Sujet

Commentaire

Management

Concerne le type de contrôle que l’on souhaite avoir sur l’équipe, notamment sur la rémuné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 confidentialité.

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.

Même dans le cas où l’on travaille avec un représentant local dans le pays du client, ce document est important. Il sera utilisé de la même façon par ce représentant pour choisir le prestataire. Si l’on n’a pas de raison de choisir a priori un partenaire plutôt qu’un autre, le RFI peut être envoyé à plusieurs partenaires choisis en aveugle sur Internet afin de recueillir rapidement des réponses et de se faire une première opinion. La façon de répondre est souvent significative, 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 professionnalisme du client.

Les principaux éléments de choix Certains points du cahier des charges sont plutôt administratifs et n’ont que peu d’influence sur le choix du prestataire, tandis que d’autres sont primordiaux. Ce sont ces derniers qui sont détaillés dans cette section. À partir des réponses écrites au RFI, on choisit quelques partenaires potentiels que l’on ira rencontrer sur place. Si la taille du projet ne justifie pas un déplacement, on peut organiser 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 les objectifs du client. Il est peu probable qu’une société de vingt personnes puisse efficacement monter une équipe de cinquante personnes. À l’inverse, on peut craindre de ne pas être suffisamment considéré si l’on crée une équipe de sept personnes dans une société comptant cinq mille employés et où la taille moyenne des équipes dépasse les cinquante personnes.

164

Chapitre 8 – Choisir le prestataire et les équipes offshore

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 chercheront à imposer leur mode de travail. D’autres se présentent comme des champions de la méthodologie, révélant une certaine rigidité. D’autres encore cherchent avant tout à satisfaire 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 sont non seulement que les opérations que l’on monte sur place se déroulent mal, mais aussi que le 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 sont prises 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éveloppements en offshore. Les autres activités peuvent être l’édition de logiciels ou des services pour des entreprises locales. La maturité du prestataire dans le domaine des développements logiciels offshore doit aussi être vérifiée. Le noyau central des collaborateurs du projet Il est toujours difficile pour le prestataire de présenter les premiers collaborateurs qui travailleront 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 ils jouent des rôles importants. Tout dépend en fait du nombre de collaborateurs que l’on souhaite rassembler à l’avenir chez le prestataire. Si l’on parle d’une équipe de quarante à soixante personnes, on peut s’attendre à être pris au sérieux et à recevoir des profils de candidats. En étudiant ces profils, le client peut tirer beaucoup d’informations sur le prestataire. S’il s’agit de monter une équipe de dix collaborateurs, il est vraisemblable que le prestataire présentera un seul chef de projet et que l’enseignement à en tirer sera assez limité. Le client cherchera ensuite à rencontrer de préférence les collaborateurs parmi les meilleurs du prestataire, qui travaillent avec lui depuis longtemps et qui sont imprégnés de la culture de la société. Il ne doit pas hésiter à leur poser beaucoup de questions sur cette dernière. Les réponses à ces questions seront parfois plus enrichissantes que celles au questionnaire adressé au prestataire. Les deux caractéristiques importantes pour évaluer la société sont la franchise et la capacité de synthèse des personnes rencontrées. La franchise des collaborateurs imprégnés de la culture du prestataire permet d’anticiper la transparence de la relation future. Elle est assez facilement détectable à l’ouverture d’esprit des réponses et à la volonté de ne pas 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 aux chefs de projet, car il existe une forte corrélation entre la profondeur des réponses des chefs de projet et l’autonomie qui leur est donnée. Les autres critères d’évaluation des profils sont évidemment leurs qualités relationnelles et techniques. Comme nous le verrons, l’évaluation du personnel en offshore est une

165

Conduite de projets informatiques offshore

tâche difficile, les repères habituels n’étant guère transposables. Par exemple, le CV qui est créé avec tant de soins dans les pays occidentaux est souvent assemblé quelques minutes avant l’entretien dans les pays d’offshore. Nous abordons ce sujet en détail au chapitre 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 est surtout important de comprendre comment les coûts sont découpés, ce qui est compris dans 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 partenariat donne de bien meilleurs résultats si le contrat est profitable aux deux parties. Ces coûts peuvent se situer dans la moyenne de ceux pratiqués localement. Plus l’équipe est importante, 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, car les 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 de malaise. On s’explique mal des écarts de 1 500 à plus de 3 000 euros par mois pour des services 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 prestataire 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.

166

Chapitre 8 – Choisir le prestataire et les équipes offshore

Tableau 8.4. Éléments des coûts des prestations offshore(suite) 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 fonctionnement 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 avantages, 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é.

Il faut être particulièrement vigilant à l’égard des coûts des prestations qui ne seraient pas maintenus dans le temps. La plupart des prestataires sont capables de casser les prix pour 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 et demie le salaire local d’un collaborateur. Avec ce ratio, le prestataire génère une faible marge, voire des opérations à prix coûtant. Il est préférable de viser des prestations à un coût supérieur à cette valeur. Si le collaborateur perçoit 600 dollars, le prestataire doit facturer 1 500 dollars pour ne pas être perdant. Pour générer 25 % de marge, il doit proposer une 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 pour la 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 collaborateurs travaillent emmitouflés dans de gros manteaux, près d’un chauffage individuel soufflant un air tiède. Si l’on compte constituer une équipe importante, mieux vaut exiger des locaux d’un niveau de confort élevé, à la plus grande joie des collaborateurs.

Les références du prestataire Les références du prestataire et son mode de travail avec ses clients réclament une attention particulière. Il ne faut pas hésiter à appeler certains de ces clients pour recueillir leur évaluation du prestataire.

167

Conduite de projets informatiques offshore

Le tableau 8.5 récapitule les principales questions à poser aux clients du prestataire concernant les références de ce dernier. 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 ?

Les références rapportées par ces clients se révéleront le plus souvent en accord avec ce que l’on constatera par la suite de soi-même.

Le contrat de partenariat Le choix du prestataire est officialisé par la signature de l’accord de partenariat (voir le chapitre 9). La présentation du contrat à signer est une étape délicate car les accords dont on a convenu oralement prennent une tout autre dimension une fois couchés sur le papier, surtout lorsque des pénalités sont applicables dans certains cas et qu’on ne les a pas évoquées en détail. Il n’est pas rare que le contrat mette très longtemps à être signé et que le travail commence 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 sur un projet de contrat jamais signé et pourtant appliqué comme s’il l’avait été.

Relations avec le partenaire Comme le terme partenariat l’indique, il est toujours préférable d’entretenir des relations telles 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 propositions nouvelles apparaissent pour résoudre les problèmes. Le prestataire veut autant que son client trouver les meilleures solutions pour un travail toujours plus efficace. Une confiance mutuelle, affirmée par le temps, est la meilleure garantie d’une collaboration efficace.

Constitution des équipes La constitution des équipes doit faire partie des premiers sujets abordés avec le prestataire. Le plus souvent, le client demande à rencontrer les premiers collaborateurs qui

168

Chapitre 8 – Choisir le prestataire et les équipes offshore

constitueront le noyau central. Lors de la signature du contrat, le prestataire offshore met immédiatement à disposition certaines personnes clés pour constituer l’équipe. On trouve généralement le responsable de l’équipe en offshore et des chefs de projet (une ou plusieurs 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 conscient de 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’il déshabille brutalement d’autres projets, il y a tout lieu de craindre qu’il ne fasse un jour de même avec le nouveau client. L’organigramme de l’équipe projet est très important pour cadrer les demandes faites au prestataire offshore. Sans cet organigramme, le prestataire a tendance à présenter les candidats immédiatement de façon à les facturer au plus tôt. La gestion de l’embauche des collaborateurs ainsi que leur validation doivent être prévues dès le commencement de façon à éviter les mauvaises surprises. Ces sujets sont abordés lors du choix du prestataire afin de valider son mode de recrutement et de gestion du personnel.

L’embauche des collaborateurs Il 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 les profils 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, cela peut se révéler une contrainte forte pour le prestataire, qu’il répercutera sur ses tarifs. Dans certains cas, on ne souhaite imposer l’anglais courant qu’aux chefs d’équipe. Cela limite grandement les promotions par la suite, et l’on est contraint de ne jamais s’adresser directement aux développeurs ou aux testeurs, même pour en valider les embauches. Certains prestataires, souhaitant assurer une constitution rapide des équipes, ne manqueront pas d’affirmer qu’il n’est pas nécessaire que tous les membres de l’équipe parlent anglais. Il est envisageable d’accepter des candidats qui ne parlent pas suffisamment bien la langue de travail pour autant qu’ils s’engagent à atteindre un niveau suffisant dans cette langue avant une date limite. Le prestataire peut alors organiser des cours d’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 qui parlent anglais et peuvent accéder à certains postes, et les autres, avec lesquels on ne peut communiquer directement, on se ferme certaines possibilités de management. Par exemple, on ne peut analyser les procédures qui ne fonctionnent pas bien, puisqu’on ne peut interroger tous les membres de l’équipe, ni les raisons des faibles performances. On ne peut pas davantage mettre en place des binômes pour chaque rôle afin d’assurer un remplacement éventuel, ni assurer la promotion des développeurs ou des testeurs de qualité, voire la simple communication sur la vie de la société. La traduction par un intermédiaire est dans tous ces cas insuffisante pour travailler efficacement.

169

Conduite de projets informatiques offshore

L’entretien d’embauche L’entretien d’embauche en offshore est souvent l’occasion d’un choc culturel. Dans certains pays, les CV n’existent pratiquement pas ou, s’ils existent, sont créés sans conviction quelques minutes avant l’entretien. Le prestataire liste les postes à pourvoir sur son site Internet. Les candidats qui répondent renseignent leur expérience professionnelle et technique. Parfois, ce formulaire est directement fourni en guise de CV, masquant ainsi toute 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 pantois quand il entend en réponse aux raisons des changements de poste d’un candidat qu’il n’était plus payé depuis quatre mois ou que les propriétaires de la société avaient disparu. Il est recommandé d’exiger du prestataire offshore qu’il réalise le premier niveau de sélection des candidats afin de valider leurs compétences techniques sur le sujet où ils devront travailler. Il ne faut pas hésiter à insister si l’on veut que le futur supérieur hiérarchique soit impliqué dans le recrutement. Faute de cela, il risque de voir arriver une recrue qui est 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 y constate parfois d’immenses différences culturelles. Lors des entretiens d’embauche, le prestataire se concentre généralement sur les compétences techniques du candidat et néglige les aspects comportementaux ou la motivation.

Certaines caractéristiques importantes des candidats ne sont pratiquement pas évaluées par les prestataires en offshore, qui s’intéressent surtout aux compétences techniques. Le client 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 fonctionnels qu’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’autres ne 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 aux ré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 client et en offshore. Le candidat n’a pas la même volonté de se vendre pour avoir le poste. Il se sait compétent et ne peut imaginer qu’on ne le choisisse pas. Certains candidats ne posent même aucune question sur le poste proposé. Lorsqu’on leur demande s’ils savent pour quel poste ils sont là, ils n’en ont aucune idée et sont avides d’informations.

La période d’essai Quel que soit le mode de recrutement, interne ou externe, on doit prévoir contractuellement avec le prestataire une période d’essai pour chaque nouveau collaborateur. Cette pé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 collaborateur en attendant qu’il fasse vraiment partie de l’équipe.

170

Chapitre 8 – Choisir le prestataire et les équipes offshore

Il ne faut pas oublier que l’on peut se séparer assez facilement d’un collaborateur selon les conditions contractuelles que l’on a définies. Cette période d’essai n’a donc pas la mê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ée avec 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 client puisse mieux les évaluer.

Au terme de la période d’essai, le client fait le point avec les personnes en contact avec le nouvel arrivant pour décider de le valider ou non. Comme il s’agit d’un accord avec le prestataire, on peut aussi demander que cette période soit reconduite.

Les formations Pour bien prévoir les formations, il faut anticiper la date à laquelle les membres des équipes commenceront à être efficaces. Bien évidemment, les formations fonctionnelles peuvent être assurées en interne si le nombre de personnes présentes dans l’équipe est suffisamment important. Au début, le client forme directement les premiers chefs de projet, architectes et testeurs sur les sujets fonctionnels. Si les développements s’appuient sur des fondations techniques comportant certaines approches de programmation, une période d’apprentissage technique importante est nécessaire avant que le nouvel arrivant puisse être réellement efficace. Les formations externes sur des technologies de progiciels sont également à prévoir en détail. Il peut être nécessaire d’obtenir des certifications, de faire venir des formateurs et de trouver des développeurs expérimentés sur des sujets précis. L’organisation de ces formations peut se révéler difficile et coûteuse. Il faut donc prévoir les moyens de contraindre le prestataire à respecter ses engagements.

Conclusion Le choix du prestataire est une décision clé clairement identifiée par toutes les sociétés qui s’engagent dans des développements en offshore. La comparaison des prestataires est complexe, et il est facile de se tromper, du fait de la distance géographique et culturelle. Ce chapitre a dégagé un ensemble de questions permettant de mieux choisir son prestataire 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 du client afin de démarrer la coopération naissante sur des bases solides et de partager un objectif 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 assombrir 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 projet participative, seule à même de rendre tous les participants au projet responsables de son succès. C’est le sujet du chapitre 9.

171

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 prestataire en offshore dans le cadre d’un fonctionnement en régie. Les sociétés qui gèrent des projets au forfait y trouveront également des informations utiles, comme la protection 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 le travail au quotidien du prestataire. Ce dernier prend seul la responsabilité de livrer le produit 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 contrats en régie est également abordée. L’annexe de l’ouvrage reprend sous forme de check-list tous les points traités dans ce chapitre.

Considérations générales sur le contrat Le contrat est utilisé presque quotidiennement pour régler des affaires courantes chez un prestataire, et l’on n’y recourt pas uniquement en cas de conflit. Depuis la gestion des congés jusqu’à la qualité des locaux en passant par les responsabilités des deux parties et 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 du client. Nous ne nous étendons pas sur les clauses que l’on retrouve dans tous les contrats et nous 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 le type de contrat que l’on signe avec lui. Comme expliqué aux chapitres 2 et 4, les projets au 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 pleinement parti des avantages du forfait en offshore. Les projets au forfait rendent les opérations opaques puisque le prestataire se voit confi er la pleine responsabilité de la gestion du projet, assortie de pénalités lorsque les engagements

173

Conduite de projets informatiques offshore

ne sont pas tenus. Le client ne se permet de contrôler les opérations chez le prestataire que 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 de leurs effets. Même si l’on souhaite de part et d’autre travailler au forfait, le client peut réaliser qu’il n’aura pas son produit dans les temps s’il n’intervient pas de façon énergique pour rétablir un fonctionnement normal. On introduit alors une forme d’ingérence du client dans le 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 le forfait.

Validation du contrat Le contrat est le plus souvent rédigé en anglais afin d’être bien compris du prestataire. Le tribunal compétent est spécifié comme celui où le client est domicilié, car c’est toujours plus sûr en cas de conflit. Les avocats du client sont parfois partiellement compétents pour revoir et valider de tels contrats, qui peuvent exiger une connaissance des lois du pays du prestataire offshore pour en assurer la validité, notamment lorsque des moyens sont prévus pour contraindre le prestataire à appliquer certaines dispositions. Les avocats réellement compétents sur ces sujets internationaux sont peu nombreux. Plusieurs points généraux sont à vérifier en priorité dans le contrat de partenariat avec le prestataire. Il faut vérifier en premier lieu que le client ne se rend pas coupable de marchandage ou de prêt illicite de main-d’œuvre. Si le client cherche à obtenir un contrô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 leur société et non du client. Il faut en outre vérifier que les employés du prestataire ne peuvent se faire reconnaître comme des employés du client du fait de certaines dispositions du contrat. De telles dispositions peuvent être un rattachement hiérarchique, même déguisé, à un collaborateur du client, des directives du client qui primeraient sur celles du prestataire, la mise en place de processus client, comme les demandes de congés, susceptibles de prouver un emploi déguisé. Le prestataire prend évidemment garde de vérifier la situation juridique de son partenaire de sorte que l’utilisation de ressources en offshore n’apparaisse pas comme de l’emploi déguisé. Lorsque des collaborateurs du prestataire sont appelés à se rendre régulièrement chez le client pour y travailler, par exemple, ils peuvent tenter de se faire reconnaître comme ses employés de fait. Avec le mode régie, il importe de ne pas s’exposer à des lois qui exigeraient que du personnel en régie employé sur de mêmes postes pendant une durée dépassant un certain 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. Traditionnellement, une société reçoit dans ses locaux le personnel placé en régie qui est managé par ses cadres. Le personnel en offshore étant distant, on ne peut théoriquement parler de régie, qui suppose le placement sur site. À défaut d’un meilleur terme, on parle aujourd’hui couramment de régie pour les projets facturés au temps consommé, par

174

Chapitre 9 – Le contrat avec le prestataire offshore

opposition au forfait, quel que soit le lieu où se trouve le personnel en régie, et quelle que soit l’organisation hiérarchique. L’anglais utilise l’expression time and material, qui est plus juste. Les avocats sauront trouver les meilleures façons d’éviter cet écueil en spécifiant une définition du mode régie dans le contrat.

Le préambule Comme dans tout contrat, on peut placer en préambule certains éléments qui, sans faire vraiment partie du corps du contrat, y jouent tout de même un rôle. Par exemple, on peut exprimer pourquoi on a choisi ce prestataire et la nature des opérations que l’on souhaite mener localement. On peut y inclure tout ou partie de la proposition de services, la réponse au RFI ou une lettre d’intention signée entre les parties. Ces documents peuvent mentionner 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 peut y faire référence et démontrer au partenaire que ses engagements ne sont plus pleinement tenus ou que la société a évolué au point de changer de nature.

Utilisation ultérieure du contrat Certaines clauses du contrat peuvent être utiles à de nombreux intervenants sur les projets. Cela concerne notamment les jours travaillés, les vacances, les embauches, les préavis, les heures supplémentaires et même les moyens de pression que le client peut exercer sur le prestataire. Chez le prestataire, les chefs de projet doivent connaître ces dispositions 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 à une question précise surgissant dans le déroulement du projet. Mieux vaut donc concevoir la forme du contrat de sorte à en extraire facilement certaines parties pour les communiquer aux personnes intéressées, en conservant d’autres parties confidentielles, financières ou hors de propos.

La propriété intellectuelle La protection de la propriété intellectuelle des réalisations en offshore est l’une des conditions essentielles pour que le client travaille efficacement et sereinement avec le prestataire. Il s’agit non seulement de s’assurer que la réalisation est la propriété du client et qu’elle est correctement protégée, mais aussi que le prestataire n’introduit pas d’éléments qui appartiendraient à un tiers et dont l’exploitation pourrait impliquer l’achat de licences ou serait interdite. La première précaution à prendre est, bien sûr, de protéger la propriété intellectuelle de la production outsourcée. Les règles relatives à la propriété intellectuelle peuvent varier d’un pays à un autre. En l’absence de mention spéciale, la propriété intellectuelle est généralement attribuée au créateur et rarement au client payeur. Il faut donc préciser dans le contrat que toute la production du prestataire au cours du projet est octroyée de façon pleine et entière au client donneur d’ordres, qu’elle soit réalisée par les employés officiellement salariés ou par tous les autres intervenants que le prestataire pourrait utiliser, que ce soit dans les locaux du prestataire ou en dehors.

175

Conduite de projets informatiques offshore

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 également prendre 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 et technique, les codes source, les plans de test, les architectures physiques des platesformes matérielles, ainsi que tous les messages et documents échangés pour répondre aux 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 est la propriété intellectuelle du client. Il se concentre surtout sur la propriété des spécifications fonctionnelles et du code développé par le prestataire.

Une bonne pratique consiste à exiger que tous les documents créés en offshore portent la mention Copyright NomSocClient 2006, All Rights Reserved. Cette mention a plusieurs avantages. Elle marque de façon certaine la propriété de chaque élément et assure que toutes les personnes travaillant pour le prestataire savent de façon évidente que la production est la propriété intellectuelle du client.

Réutilisation d’éléments appartenant au prestataire Dans certains cas, le prestataire peut avoir déjà développé des fonctions ou des services dont le client pourrait bénéficier. Il peut s’agir de la réutilisation d’éléments de méthode ou de procédure, de services techniques ou encore de modules fonctionnels standards susceptibles d’apporter un gain de temps, comme la gestion de commandes et de stocks sur les sites de commerce électronique. Ces éléments peuvent être vendus par le prestataire. Ce dernier peut aussi en conserver la 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 dans les réalisations dont le prestataire est propriétaire sont cédés gratuitement pour une libre utilisation commerciale dans le contexte de cette réalisation, sauf dans les cas où ils feraient l’objet d’une négociation séparée. Il est en effet essentiel de se protéger d’un prestataire 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 une telle clause, le prestataire reste le propriétaire des éléments qu’il a fournis et en accorde une 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 les appliquer à tous ses projets. De son côté, le client peut souhaiter étendre ses propres méthodes à l’offshore au lieu de celles de son prestataire. Certains prestataires font de leurs procédures un avantage concurrentiel et obtiennent des certifications ISO 900X et

176

Chapitre 9 – Le contrat avec le prestataire offshore

CMM. Le contrat doit clairement prévoir comment le projet doit être organisé du point de vue de la méthodologie et si cette dernière doit elle-même être protégée.

Protection d’éléments appartenant au client Le client peut disposer de composants techniques ou fonctionnels réutilisables. Le contrat 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éthodologie, laquelle participe, selon lui, à la valeur de la société et contribue à lui donner un avantage concurrentiel. Le prestataire, qui assure assez naturellement la protection des codes source, peut ne pas se rendre compte qu’une méthode doit aussi être protégée. Il faut en ce cas prendre soin de noter explicitement dans le contrat que celle-ci est et reste la 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 tiers Il convient d’identifier tous les éléments qui ne relèvent pas de la pleine propriété du client dans le produit réalisé en offshore. Avant de les inclure dans le produit, il faut que le client possède une licence d’utilisation accordée par son propriétaire ou en connaisse les conditions d’acquisition ou d’exploitation. Ces licences, regroupées sous forme de liste, incluent celles accordées par le prestataire et celles de tiers. Les contraintes relatives à ces composants sont clairement mentionnées, qu’il s’agisse de licences perpétuelles sur paiement unique, de licences gratuites (freeware), de licences Open Source, de licences dont le coût est calculé par utilisateur ou par processeur, ou de contraintes 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éfinit les procédures à suivre pour soumettre la demande d’utilisation de ceux-ci et la façon dont le client les accepte ou les rejette. Il est essentiel de faire porter la responsabilité du non-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 être retirés, le travail qui en résulte est à la charge du prestataire.

Réutilisation de code personnel Comme expliqué précédemment dans l’ouvrage, les développeurs, tout particulièrement en offshore, ont la fâcheuse tendance à réutiliser du code qu’ils ont téléchargé sur Internet ou 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éliorent certaines 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 sur un projet. Seules une bonne communication du client et du prestataire et une discipline personnelle de chaque développeur sont à même d’assurer la transparence des droits sur le code. Le contrat doit indiquer expressément que tout code extérieur qui serait utilisé dans le cadre du projet doit être formellement validé par le client, sur la base d’informations complètes sur l’origine de ce code. Le contrat peut désigner une personne ou un rôle responsable pour effectuer ces validations.

177

Conduite de projets informatiques offshore

Protection contre la concurrence Il est légitime de redouter que le prestataire ne signe un contrat de prestations offshore avec un concurrent du client. Dans un tel cas, les collaborateurs du prestataire seraient amenés à parler avec d’autres équipes et à comparer méthodes, fonctionnalités, solutions technologiques et plans stratégiques. Cela ne manquerait pas d’arriver aux oreilles des dé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 ce dernier, 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 volontaires 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 avec lesquelles le prestataire ne serait pas autorisé à travailler ou définir précisément les domaines interdits. Dans les deux cas, on ne peut envisager une telle approche que si les exclusions sont précises. Par exemple, un domaine qui serait identifié comme le trading d’instruments de Foreign Exchange sur Internet pourrait figurer au contrat, mais pas « le commerce électronique sur Internet », trop général. Le prestataire accepte plus volontiers ce type de clause si le volume d’affaires avec le client est important et si le domaine d’exclusivité est suffi samment réduit. La clause peut indiquer un volume d’affaires minimal. Si le volume d’affaires reste en deçà de cette valeur, le prestataire peut demander une compensation pour garantir cette exclusivité. On peut aussi prévoir que si le prestataire souhaite travailler avec une société explicitement listée dans le contrat, il demande au client de confirmer que l’interdiction s’applique bien. En effet, certaines sociétés importantes estimées concurrentes peuvent confier 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 scrupuleusement les règles relatives à la propriété intellectuelle et à la confidentialité des informations. Si le prestataire ou le client se rend compte du non-respect de celles-ci, il doit en informer immédiatement l’autre partie. Le prestataire est censé prendre les sanctions qui conviennent pour punir l’employé qui ne respecterait pas ces règles. Si le collaborateur a sciemment transgressé les règles avec l’intention de nuire ou d’en tirer profit, ne serait-ce que pour se faire valoir auprès d’un autre employeur potentiel, le contrat doit contraindre le prestataire à le licencier sans préavis pour faute grave. Au besoin, il devra engager des poursuites contre lui. Il est très important que les collaborateurs comprennent la réalité de la propriété intellectuelle.

178

Chapitre 9 – Le contrat avec le prestataire offshore

Les services du prestataire offshore Cette section traite des aspects contractuels relatifs à la fourniture des services de base et des services complémentaires. La réalité concrète du partenariat en offshore est la fourniture de services de prestations humaines. La mention des services de base, consistant à mettre à disposition du client des collaborateurs, ne suffit généralement pas et doit s’accompagner de la fourniture de services complémentaires, tels que matériel, bande passante Internet, administration de réseau, supervision de la sécurité, etc., essentiels au fonctionnement du partenariat. Ces services peuvent être facturés séparément ou être inclus dans le coût de mise à disposition des ressources humaines.

La langue de travail Le contrat définit la langue de travail qui sert à communiquer entre les équipes du client et celles du prestataire, incluant la documentation du projet. Les collaborateurs du prestataire parlent bien sûr entre eux dans leur langue natale. On peut imposer que tous les échanges écrits (messages et messages instantanés) utilisent la langue de travail. Une telle mesure risque toutefois d’être peu populaire et de réduire quelque peu la productivité. Une autre solution consiste à imposer que les décisions ou toute information utile résultant d’une telle communication soient résumées dans la langue de travail et transmise aux personnes concernées. Le client peut disposer de documents dans sa langue locale, qui n’est pas nécessairement la langue de travail, qu’il souhaite communiquer au prestataire comme des éléments de documentation du projet. Il peut s’agir d’un manuel utilisateur ou de spécifications. Si le client prévoit de fournir souvent au prestataire des documents dans sa langue locale, il peut demander que le prestataire s’organise en conséquence et inclut un ou plusieurs traducteurs 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 questions des développeurs et architectes, notamment si la traduction n’est pas claire ou si elle semble incorrecte.

Prestations de base et services complémentaires D’une manière générale, il n’est pas raisonnable de complexifier à outrance la facturation ni la supervision du prestataire en offshore. Il est préférable de forfaitiser le maximum de services complémentaires dans les prestations humaines, à condition de veiller que le forfait 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 effectivement rendus et s’ils sont suffisants et adaptés pour travailler efficacement avec l’offshore. Par exemple, si la bande passante sur Internet est incluse, le prestataire fournit-il le 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 ?

179

Conduite de projets informatiques offshore

Si l’on décide de ne pas inclure ces services additionnels dans les facturations forfaitaires par 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 travail administratif 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 de leurs coûts élevés ou de leur forte dépendance aux souhaits de la société cliente et doivent être facturés séparément. Par exemple, le prestataire ne fournira probablement pas les suites logicielles, assorties de contrats de maintenance, nécessaires au développement dès lors qu’il s’agit de produits coûteux. Le prestataire ne voudra probablement pas non plus inclure les serveurs de test des réalisations en offshore, surtout si la plate-forme consiste 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 les tests en offshore. Certains services peuvent être naturellement inclus dans les prestations offshore ou refacturés au client, comme l’administration du réseau, qui est toujours incluse dans les prestations des petites équipes, mais pas nécessairement dans celles des équipes plus importantes. Dans tous les cas, il convient de bien comprendre ce qu’incluent les prestations de services en offshore. Ces services inclus expliquent en grande partie les différences importantes que l’on constate entre les salaires effectivement versés par le prestataire aux collaborateurs et le prix par collaborateur facturé au client.

Devise de facturation et risque de change La devise utilisée dans les opérations commerciales avec l’offshore est majoritairement le dollar, même lorsqu’on traite avec les pays de l’Europe de l’Est. Certains prestataires montrent cependant une préférence pour l’euro, motivée par la perte de valeur du dollar par rapport à l’euro. Le dollar est souvent considéré comme la seconde monnaie nationale dans les pays de l’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/vente très faible avec la monnaie locale, rendant particulièrement fl uide la conversion entre le dollar et la monnaie locale dans les deux sens. Le split avec l’euro est généralement beaucoup plus 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 le jour. Même si la loi l’interdit fréquemment, on peut payer en dollar dans presque tous les commerces, surtout lorsque les sommes sont importantes. Les salaires sont presque toujours définis en dollars, ce qui permet, dans une certaine mesure, de se protéger de l’inflation. Les négociations avec le prestataire sur le montant des services ont donc toutes les chances d’ê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ées sur le dollar, ce qui ne représente qu’une faible partie du montant de la facturation mensuelle. Lorsque le prestataire dispose de montants en monnaie locale à refacturer en dollars ou en euros, le contrat définit la façon de choisir le taux de change pour établir les factures.

180

Chapitre 9 – Le contrat avec le prestataire offshore

Il précise la source du taux de change et la date à laquelle on fixe le choix de façon à lever toute 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 soient facturées à un prix qui ne laisse qu’une faible marge au prestataire, celui-ci risque de perdre 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 un dollar, et que le taux de change évolue à 1 euro pour 0,7 dollar, le prestataire, qui paye ses employés et ses fournisseurs en dollars, ne perçoit plus que 1 400 dollars, au risque d’une prestation à perte. Une telle situation n’est pas forcément à l’avantage du client. Si la situation perdure, ce dernier constatera probablement une perte de productivité des prestations, voire le départ des meilleurs membres de l’équipe et leur remplacement par des collaborateurs qui acceptent des salaires plus faibles.

L’unité de facturation des prestations de base Les prestations de base correspondent à la mise à disposition des ressources humaines, avec parfois un certain lot de services complémentaires inclus dans ces prestations. En règle générale, ce poste correspond à 75 à 100 % de la facture totale du prestataire offshore. L’unité de facturation des prestations, qui peut être le mois, le jour ou l’heure, a une influence importante sur la façon dont le prestataire en offshore utilisera ses collaborateurs. Chacune de ces unités présente des avantages et des inconvénients. Nous verrons que 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 en régie. Pour les prestations au forfait, l’unité de mesure importe peu, le calcul de la proposition 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éricains ou britanniques. Son principal inconvénient est que les journées de travail facturées dépassent souvent largement les huit heures. Même avec un nombre fixe de collaborateurs, on ne peut savoir exactement ce que le prestataire facture en fin de mois car le nombre d’heures travaillées varie grandement. De plus, ce mode de facturation pousse le prestataire à facturer mécaniquement toutes les heures travaillées. Pour effectuer sa facturation, le prestataire met en place un reporting détaillé par jour et par personne. Si le client exige d’être livré dans les temps, cela peut être compris comme une demande d’heures supplémentaires et se traduire par une hausse significative des montants facturés. On constate parfois qu’une équipe travaille douze heures par jour et que le montant des factures augmente de 50 % par rapport à ce que l’on avait anticipé. Si le collaborateur est lui-même rémunéré à l’heure, ce mode de facturation pousse à la surconsommation puisqu’il peut augmenter ses revenus en travaillant davantage. Il est toujours possible de limiter contractuellement le nombre d’heures travaillées chaque 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

181

Conduite de projets informatiques offshore

heures facturables. Si le contrat prévoit huit heures, le prestataire s’arrangera pour dé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. Comment peut-il exiger de rattraper un retard, par exemple, s’il refuse que le prestataire fasse des heures supplémentaires ? Le prestataire peut accepter d’assurer des heures supplémentaires sans les facturer s’il se sait responsable du retard. Autrement, il n’a aucune raison de 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 toutes les heures supplémentaires, ce qui peut augmenter significativement les montants des factures mensuelles. À l’inverse, le prestataire limite strictement les heures travaillées à ce qui est convenu contractuellement, interdisant tout travail supplémentaire volontaire des collaborateurs. Dans les deux cas, le client est perdant.

Facturation à la journée La facturation à la journée consiste à facturer chaque journée travaillée par chaque collaborateur selon le montant prévu au contrat. Le contrat définit un nombre d’heures nominal par journée, le plus souvent entre sept et dix heures, et comment les heures et les journées supplémentaires sont comptabilisées. Les heures supplémentaires ne peuvent ê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 retrouve son mode de fonctionnement habituel en local avec ses cadres, dont certains travaillent longtemps 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 pas immédiatement utilisé pour calculer les heures supplémentaires. Lorsque des efforts supplémentaires doivent être consentis, ils le sont généralement sur la 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 en offshore ou de chaque collaborateur. Il peut arriver que le prestataire demande à son client l’autorisation de facturer un jour de vacance un collaborateur en compensation d’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 le week-end. Le contrat doit donc déterminer la façon dont les heures supplémentaires sont facturées, notamment si les tarifs sont identiques quel que soit le jour ou s’ils sont plus importants 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, sans facturation d’heures supplémentaires. C’est un mode de facturation efficace, qui est recommandé dans les contrats avec les prestataires offshore.

182

Chapitre 9 – Le contrat avec le prestataire offshore

Facturation au mois La facturation au mois correspond à facturer pour chaque mois travaillé une somme définie contractuellement pour chaque collaborateur. Si un collaborateur ne travaille pas tous les jours du mois, les jours non travaillés sont le plus souvent déduits au prorata des jours ouvrés. Avec ce mode de facturation, le prix de la journée travaillée varie selon le nombre de jours ouvrés dans le mois. Le suivi budgétaire est assez aisé, puisque les budgets et les facturations sont 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émentaires 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 de la journée varie selon le nombre de jours ouvrés dans le mois.

Les heures supplémentaires Dans tous les cas, la façon de gérer les heures supplémentaires doit être clairement dé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. De même que les salariés locaux du client sont prêts à rester plus tard pour achever des tâches importantes, il est important que les collaborateurs distants soient motivés pour faire d’eux-mêmes ces efforts supplémentaires. On essaie le plus souvent de limiter le recours aux heures supplémentaires et de favoriser les rattrapages de façon à ne pas dépasser les budgets arrêtés. On peut établir comme principe que le client ne paie pas d’heures supplémentaires, quitte à y déroger en cas d’extrême nécessité. Les deux méthodes de facturation des heures supplémentaires les plus usitées sont la facturation au prorata des horaires facturés pour un travail normal et la facturation selon un barème prédéfini. La facturation au prorata est la plus simple. On applique les mêmes tarifs aux heures supplé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’appuie toujours 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 selon une grille donnant le taux horaire de chaque période, par exemple une fois et demie le tarif horaire du collaborateur. L’organisation des heures supplémentaires est particulièrement critique lorsqu’on travaille avec des équipes à fort décalage horaire et que l’on a l’intention d’organiser des réunions téléphoniques à des heures confortables pour le donneur d’ordres, c’est-à-dire en dehors des heures de travail du prestataire. Par ailleurs, si l’on utilise des ressources en offshore pour l’administration de plates-formes, il est très commun d’organiser le déploiement d’applications en dehors des heures ouvrées, la nuit et le week-end. Il est important de s’assurer en ce cas que l’on pourra faire travailler les collaborateurs durant ces périodes.

183

Conduite de projets informatiques offshore

Absences et congés Le client n’est facturé que pour les journées et les heures effectivement travaillées par les collaborateurs. 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 le collaborateur ne doive pas être payé pour autant, notamment s’il est en congés payés. Le prestataire peut très bien avoir l’obligation légale de payer un certain nombre de jours de congé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, si un collaborateur part une semaine en vacances et travaille cinq samedis en rattrapage, il se retrouve avec 260 jours travaillés dans l’année. Ce type d’organisation n’est pas efficace, car la personne qui travaille seule ne peut pas toujours être aussi performante que lorsqu’elle peut interagir avec ses collègues. De plus, son absence a pu retarder certaines tâches. Accepter une forte flexibilité favorise la tendance de certains collaborateurs à prendre un second emploi. Ils peuvent se libérer des jours entiers pour leur second poste lorsqu’ils en ont besoin, sans perdre la moindre part de la rémunération de leur premier emploi. Il est 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 pour rattraper les absences exceptionnelles de quelques heures le jour même ou les jours suivants. Le client peut contraindre les collaborateurs en offshore à prendre chaque année un nombre de jours de congé précisé contractuellement, de façon à définir clairement le budget des équipes offshore sur l’année. Les rapports de suivi d’activité permettent de tracer le nombre de jours restant à prendre. Il est bon de prévoir une répartition dans l’année de ces congés de façon à ne pas risquer de voir tous les collaborateurs disparaître en même temps. Les congés et les absences n’étant pas facturés, le prestataire doit rendre compte précisé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 par tous les moyens possibles. Dans son pays, les congés payés sont d’environ 20 jours par an. Le prestataire pratique une différenciation entre les salaires officiels et les salaires réels, les salaires officiels dépassant rarement 50 dollars, et les salaires réels se situant autour de 500 dollars. Le client principal du prestataire exige que les collaborateurs prennent effectivement leurs 20 jours de congés. Le management du prestataire paye depuis longtemps les congés sur la base du salaire réel. Du fait de ses difficultés croissantes, il décide de changer le mode de rémunération des congés et de ne payer que les salaires officiels. Sa décision se révélant très impopulaire, il la justifie en se targuant de la clause contractuelle avec son client principal qui stipule que les absences et congés ne sont pas facturés.

184

Chapitre 9 – Le contrat avec le prestataire offshore

Le mécontentement est si fort que plusieurs personnes menacent de démissionner. L’affaire vient aux oreilles du client, qui se voit contraint d’intervenir auprès du prestataire pour éviter le départ de collaborateurs. 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és payés sur la base des salaires réels de tous les collaborateurs travaillant avec lui.

Les sous-projets au forfait Un projet en régie n’interdit en rien de demander de traiter des sous-ensembles du projet au forfait. Cette pratique peu courante lorsque la relation en régie fonctionne de façon satisfaisante peut se révéler utile lorsque le client estime que la productivité du prestataire est trop faible. Le contrat peut prévoir que certains contrats au forfait puissent être exécutés sur la base de documents contractuels précisant les tâches à exécuter, même si le cadre général de la relation est la régie. Le personnel dédié à ces projets au forfait sera exclu de la facturation en régie pendant toute la durée où le projet au forfait est exécuté, jusqu’à validation de 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 au forfait. Une itération demandant souvent entre quatre et six semaines, elle peut être maintenue raisonnablement stable durant son exécution, et le prestataire peut s’engager sur des délais. Les changements éventuels sont reportés sur l’itération suivante. Les procédures et modes de fonctionnement imposés par le client sont bien connus du prestataire, 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 calcul d’une pénalité en fonction des retards constatés. On est alors certain que le prestataire considérera ses engagements sur l’itération avec sérieux et fera tous les efforts nécessaires pour tenir ses objectifs. Le contrat peut définir que les itérations peuvent être forfaitisées et préciser les règles de dé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, il convient d’abord d’atteindre un niveau de fonctionnement stable selon l’approche méthodologique du client. Les premières itérations sont souvent loin d’atteindre les objectifs. On apprend à connaître les hommes, on met en place une méthode, et les tâ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 sont suffisamment stables. Tant que ces conditions ne sont pas réalisées, on peut extraire des parties stables des premières itérations et leur appliquer un fonctionnement au forfait.

Facturation des collaborateurs Lorsqu’on n’a pas encore travaillé avec l’offshore, on peut être tenté de mettre en place un mode de facturation qui attribue un montant propre à chaque collaborateur, sur la base de ses compétences ou du salaire qu’il perçoit. En offshore, ce mode de facturation par individu est assez délicat à gérer.

185

Conduite de projets informatiques offshore

L’expérience et la compétence sont des éléments subjectifs, dont l’appréciation varie au cours du projet. Si le client applique ce type de facturation par personne au début du projet, 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 les talents qui se sont révélés et, ce qui est plus important à ses yeux, pour baisser les tarifs des 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 et génèrent des tensions inutiles. Il y a peu à gagner à remettre en question continuellement des tarifs par personne, les sommes en jeu étant globalement faibles puisque augmentations et réductions finissent par s’équilibrer. Il y a en revanche beaucoup à perdre, les divergences d’appréciation sur le personnel entre le client et le prestataire risquant de perpé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 une somme unique pour tous les profils ou par grande catégorie de personnel. Cette approche de la facturation est la plus efficace, et elle permet de conserver un bon esprit de partenariat entre le prestataire et son client.

L’expérience montre qu’il vaut mieux traiter la tarification du personnel globalement en définissant une somme unique pour tous les collaborateurs, éventuellement par grande catégorie, par exemple standard et expert, sans entrer dans le détail de l’expérience et de la compétence de chacun. Cette approche est d’ailleurs le mode de tarification le plus commun des prestataires en offshore. Si l’on emploie des équipes très importantes, on peut affiner cette facturation en définissant des catégories de collaborateurs et de compétences particulières. Par exemple, on peut adopter le découpage de facturation proposé au tableau 9.1, qui permet d’ajuster en continu 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

186

Chapitre 9 – Le contrat avec le prestataire offshore

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 des règles contractuelles revues tous les six mois. Le tableau 9.2 donne une idée de ce type de distribution. 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

Quel que soit le mode de tarification utilisé, les montants facturés par collaborateur doivent 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 collaborateurs doivent être clairement définis. Certains de ces services sont évidents, comme le lieu de travail, le mobilier courant, l’électricité, le nettoyage des locaux, la gestion administrative de l’équipe et de la paye, etc. Tant que l’équipe est restreinte, le prestataire peut fournir ces services sans engager de dépenses supplémentaires. Pour les grosses équipes, le prestataire doit investir, et il est difficile d’identifier la taille seuil à partir de laquelle les ressources lui coûtent vraiment. Les prestataires qui travaillent avec une équipe importante comprennent vite que la gestion administrative de l’équipe va leur prend beaucoup de temps. Une ou plusieurs personnes doivent suivre à plein temps les absences, les congés, la facturation, les services refacturables, les embauches, etc. Bien souvent, le prestataire tente de facturer ce personnel comme faisant partie de l’équipe du client. Il revient à ce dernier de décider si 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.3 récapitule les services susceptibles d’être exclus des prestations par personne. 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 prestations 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.

187

Conduite de projets informatiques offshore

Tableau 9.3. Services pouvant être exclus des prestations par personne(suite) 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écessaire 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.

Lorsque des services ne sont plus intégrés, ils doivent être gérés comme des services complé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 collaborateurs ou le montant facturé atteint certains seuils (voir tableau 9.4). Cette méthode de réduction est assez efficace et ne prête pas à confusion, par opposition aux calculs sur le nombre de collaborateurs. 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

Par exemple, une facture de main-d’œuvre de 80 000 dollars donnera lieu aux remises suivantes : • 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), soit 250 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. Par exemple, les calculs de remise s’appuyant sur le nombre des collaborateurs sont souvent

188

Chapitre 9 – Le contrat avec le prestataire offshore

difficiles à appliquer car il faut s’entendre sur la façon de compter les ressources et la remise.

Les formations générales Les formations générales du personnel ne sont généralement pas facturées au client, sauf accord 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 les formations qui conviennent pour rendre les collaborateurs pleinement opérationnels sur les 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’il s’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’autres progiciels de forte diffusion du marché est une formation standard ? Selon le projet et les compétences demandées, il est recommandé de lister les compétences générales et celles qui seront réputées spécifiques du projet. Parfois, le prestataire proposera de placer un nouveau collaborateur dans l’équipe sans le facturer durant un ou deux mois à titre de formation. Ce mode de formation par immersion ralentit le travail du personnel en place, mais le stagiaire produit rapidement un travail 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 progiciels du marché dans leurs développements ne peuvent s’attendre à ce que le prestataire dispose de candidats connaissant ces produits ou même qu’il puisse les trouver facilement. Certains de ces progiciels sont relatifs à un marché vertical, à une activité donnée ou sont assez confidentiellement utilisés. Le client doit alors prendre en charge la formation du personnel à ces technologies ou s’entendre contractuellement avec le prestataire pour que les formations soient à sa charge. Dans la mesure du possible, les formations sont données en offshore, en envoyant un formateur sur place. Quand cela n’est pas possible, il peut être nécessaire d’organiser les formations chez un prestataire agréé en local. Cela peut soulever des difficultés si, par exemple, le client est en France et que les organismes de formation locaux ne proposent que 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 administrative exige 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 de l’offshore ou dans un pays proche afin d’assurer ces prestations chez le prestataire ou dans un pays ne posant pas de problèmes. Le contrat note clairement les formations qui sont sous la responsabilité du prestataire et celles qui sont refacturées ou assurées par le client.

189

Conduite de projets informatiques offshore

Les services complémentaires Les services complémentaires peuvent être la source de dépenses importantes, qui viennent s’ajouter aux prestations de base. Il est recommandé de négocier précisément les niveaux de service attendus et la partie qui les prend financièrement en charge. Certains services exigent des précautions particulières, comme la mise à disposition des licences logicielles chez le prestataire. Les services complémentaires peuvent être forfaitisés et s’ajouter au coût du personnel ou refacturés au réel. Lors de la négociation du contrat, il est recommandé de s’entendre sur un tarif par personne sans services complémentaires. On listera tous les services forfaitisés, et on négociera le coût de chacun d’entre eux. Ces coûts seront ajoutés au tarif de 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 une relation avec un prestataire en offshore. Certains services sont intégrés aux prestations humaines tandis que d’autres sont régularisés sur présentation des frais réels. Le tableau indique les points qui requièrent une attention particulière lorsque le service est inclus dans les prestations et lorsqu’il est facturé séparément. Sans être exhaustive, cette liste donne 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 disponibilité.

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 platesformes 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 communication téléphonique

Les frais de communication standards sont généralement inclus dans les prestations. Les communications téléphoniques 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.

190

Chapitre 9 – Le contrat avec le prestataire offshore

Tableau 9.5. Services complémentaires aux prestations humaines(suite) Service

Inclus dans les prestations

Non inclus dans les prestations

Frais de recrutement

Les frais de recrutement ne sont généralement 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 prestataire dispose naturellement d’un tel système.

Les installations peuvent être refacturé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.

Le client doit prévoir un budget pour les services complémentaires. Il doit également pré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 pour le 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é sous la forme d’un surcoût du tarif de base. Cette forfaitisation suppose que le prestataire

191

Conduite de projets informatiques offshore

s’engage sur un niveau de service minimal défini contractuellement. Par exemple, la bande passante sur Internet est clairement définie et mesurée afin d’évaluer si le prestataire 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 serveurs de fichiers, les postes de travail des informaticiens, les frais de téléphone et la bande passante Internet. Si le client a des exigences particulières, ces prestations sont facturées indé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’on paye, par exemple, 60 dollars par mois pour le poste de travail du collaborateur, 50 dollars pour Internet, etc. Une telle approche permet de conserver le détail des services rendus sans 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 annuellement ou sur demande d’une des deux parties. La forfaitisation est souvent accompagnée de certaines obligations pour le client. Par exemple, il s’engage à maintenir une équipe d’au moins quinze personnes durant un an de façon à couvrir l’achat des postes de travail par le prestataire.

Les licences logicielles standards Le client n’a généralement pas la volonté de gérer les licences logicielles chez son prestataire en offshore. Il lui faut cependant se protéger des poursuites susceptibles d’être engagées contre lui si une organisation vient à découvrir que le prestataire emploie des logiciels sans licence. Il est fortement recommandé d’exiger par contrat que les logiciels mis à la disposition du client par le prestataire soient acquis selon les dispositions légales du pays du prestataire. Le contrôle de la légalité des acquisitions des licences est de la responsabilité du prestataire et non du client. Déjà difficile à réaliser dans la propre société du client, un tel contrô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ées dans sa société sont légalement acquises selon les lois en vigueur dans son pays. Le client doit 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ère fois qu’il travaille avec l’offshore, qui peut se révéler très coûteux. Le client se rend vite compte qu’il dépend en fait des règles de sécurité en place chez le prestataire, sur lesquelles 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 chez le prestataire. Si l’on souhaite un niveau de sécurité réellement élevé, il convient d’isoler la majeure partie de l’équipe et de ses ressources et d’en prendre le contrôle en totalité. Le service de 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 les coûts et la structuration de la facturation.

192

Chapitre 9 – Le contrat avec le prestataire offshore

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 refacturés à ce dernier, on peut considérer que le matériel appartient au client, même si, légalement, la question est beaucoup plus complexe. Il est recommandé de prévoir des clauses qui donnent au client un certain contrôle de ces matériels, notamment en fin de contrat, 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 facturation. Il est illusoire d’envisager l’expédition de ce matériel chez le client. Les règles douanières et le coût du transport rendent ces transferts peu intéressants. Cela vaut d’ailleurs dans l’autre sens, pour l’achat du matériel. Il est important de suivre la vie du matériel en offshore. On peut demander au prestataire de transmettre une liste de tout le matériel (roster) acquis par le client avec les informations qui 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’elle est mise à jour régulièrement. Le prestataire s’engage à protéger les licences de tous les logiciels qui ont été mis à sa disposition par le client. Cette protection vise notamment la communication de ces logiciels à un tiers qui les reproduirait pour les placer sur le marché du logiciel dans le pays de l’offshore. Cette clause contractuelle doit être claire et être accompagnée d’un devoir d’information aux collaborateurs en offshore. Assurance-vol et incendie Le matériel mis à la disposition du prestataire doit être couvert par une assurance-vol et incendie souscrite par le prestataire. Le client peut exiger une copie du contrat d’assurance pour en vérifier l’existence. Le plus souvent, il s’agit du contrat couvrant tous les biens et locaux du prestataire. Il n’est cependant 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 espaces de travail à l’accueil des visiteurs ou pour organiser des réunions. Si l’on veut être certain de disposer de ces salles, il faut les prévoir contractuellement. Le prestataire peut demander au client une participation financière, qui est généralement forfaitisée. Appartement en offshore Si des visites des représentants du client sont régulièrement effectuées chez le prestataire, on peut se demander si l’hôtel est la meilleure solution. Dans certains pays, les hôtels de qualité sont coûteux et offrent un service médiocre. On peut préférer demander au prestataire de louer un appartement sur place à l’année, permettant éventuellement d’y conserver certaines affaires personnelles. Ce type de prestation est pratiquement toujours refacturé au client.

193

Conduite de projets informatiques offshore

Qualité du cadre de travail On peut demander au partenaire de garantir un cadre de travail propre et confortable pour l’équipe dédiée au client. Le niveau de qualité demandé peut être supérieur aux conditions 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 lieu pour autant d’exiger des conditions très au-dessus de celles que l’on trouve dans les meilleures sociétés du pays. Si des travaux sont nécessaires ou si les coûts sont importants, le prestataire ne manquera pas d’augmenter ses tarifs pour couvrir les dépenses. À l’inverse, si le partenaire n’assure pas les engagements définis contractuellement, on peut 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-elle s’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 de pression efficace lorsque le prestataire manque clairement à ses engagements.

Gestion des factures La facturation des prestations est toujours un sujet délicat. L’établissement des factures est 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 un suivi 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épenses importantes. On trouve fréquemment des erreurs dans les factures sur des montants relatifs assez faibles. Bien souvent, le prestataire est de bonne foi. Si le client exige des factures exactes et réclame des ajustements successifs, ces derniers risquent de retarder ses paiements et de perturber le déroulement des prestations.

Les termes de paiement Les sociétés occidentales sont habituées à négocier des termes de paiement qui leur sont favorables. 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

194

Chapitre 9 – Le contrat avec le prestataire offshore

après leur date d’émission. Les prestataires en offshore ne sont pas coutumiers de ces termes 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 que de tels termes existent. S’ils sont peu méticuleux, ils risquent de ne pas aborder le sujet et 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 paiement des factures recommandé est à réception ou à trente jours au maximum. Ces termes de 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 un certain seuil. Par expérience, si l’équipe atteint plus de trente collaborateurs, les factures comportent presque toujours des erreurs de quelques pour cent du montant de leur montant. Les échanges pour corriger les factures sont souvent longs. Si certaines demandes de correction sont justifiées, d’autres relèvent d’erreurs d’appréciation du client. Par exemple, une personne absente une journée, alors que cette journée est facturée, peut avoir effectué un rattrapage, ou bien cette absence peut venir en compensation d’heures supplémentaires. Un prestataire qui n’a pas de réserves importantes de trésorerie peut ne pas régler les pleins salaires de ses collaborateurs tant qu’il ne reçoit pas son paiement. Il est toujours préférable que le client paie promptement ses factures pour maintenir la motivation des collaborateurs et ne pas repousser les meilleurs profils. On peut prévoir, par exemple, que la facture du prestataire soit envoyée par e-mail avant le 10 du mois pour les services du mois précédent et que le paiement soit effectué avant le 20. Un tel arrangement permet aux collaborateurs de connaître la date de paiement de leurs 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 est recommandé, car il permet d’éliminer totalement les retards de paiement dus aux rectifications de factures. Si le client fait de réels efforts pour payer rapidement le prestataire, ce dernier doit être clairement contraint de payer l’équipe dans les temps. Il peut être utile de mentionner dans le contrat que l’on a défini des dates limites pour la présentation de la facture, les paiements et le versement des salaires. Le contrat peut aussi prévoir que les collaborateurs soient payés dans les temps même si le client paye son prestataire en retard. On peut exprimer une limite à cet engagement du prestataire 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 plus d’une semaine, par exemple.

195

Conduite de projets informatiques offshore

Figure 9.1. Processus de paiement des factures du prestataire

Paiements partiels des factures Lorsque le client constate que les services prévus au contrat ne sont pas assurés correctement, il peut vouloir forcer le prestataire à respecter ses engagements ou à améliorer son service. Les manquements du prestataire peuvent être très divers, comme un contrôle d’accès qui n’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 de prévoir les moyens d’exercer une pression forte, mais raisonnable, sur le prestataire pour le contraindre à agir. Certains engagements peuvent être accompagnés de pénalités s’ils ne sont pas respectés, par exemple.

196

Chapitre 9 – Le contrat avec le prestataire offshore

Après plusieurs échanges de messages sans effet, le client voudra le plus souvent forcer le prestataire à respecter ses engagements. L’arrêt du paiement des factures n’est pas une bonne solution, car elle engendre des situations de tension, qui peuvent nuire à la poursuite du partenariat. Pour que la pression soit efficace, il faut à la fois que le prestataire soit puni et que les salaires des collaborateurs soient protégés, faute de quoi on effectue la pression avant tout sur soi-même. Un bon compromis consiste à prévoir dans le contrat que le paiement d’une partie de la facture est retenu jusqu’à la correction du problème constaté. Cette partie ne sera restituée en totalité que si certaines conditions sont vérifiées, comme le paiement régulier des collaborateurs et de certains services, tels que les abonnements à Internet.

Pénalité de retard de paiement du client De 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édiat de la facture par virement ou encore une pénalité pour retard de paiement à appliquer sur la facture suivante selon un barème défini. Parfois, bonus et pénalités s’appliquent selon la date du paiement (un bonus en cas de paiement rapide et une pénalité en cas de retard). La pénalité de retard peut être perçue par le client comme un droit à payer en retard et comme une obligation pour le prestataire à honorer ses engagements à l’égard des collaborateurs, 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 de l’équipe. Au lieu de chercher à les éviter, mieux vaut s’entendre clairement sur un fonctionnement. Il est clair que les prestataires en offshore ont de faibles réserves de trésorerie. Si le paiement de la facture n’est plus directement lié au versement des salaires des collaborateurs, la négociation sur les termes de paiement et les pénalités de retard devient plus facile, comme avec n’importe quel fournisseur.

Rétention de paiement et suspension de service Dans le cas où le prestataire ne tiendrait pas ses engagements, le client peut souhaiter disposer du droit de suspendre ses paiements. Celui-ci se donnera ce droit même si cela n’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 pour retard de paiement. On peut, par exemple, limiter la suspension de service aux cas où les retards de paiement dé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 prestataire pourra suspendre la fourniture du service. On précisera alors que les sommes restent dues par le client.

Les augmentations de tarif Les 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 pour conserver une marge proche de celle qu’il a négociée au début du partenariat. Le client

197

Conduite de projets informatiques offshore

souhaite aussi que son équipe reçoive un niveau de salaire en accord avec ceux pratiqués localement et que celui-ci soit régulièrement réévalué pour rester équilibré avec le marché. Les salaires étant souvent exprimés en dollars, ils se trouvent parfois fortement dévalués lorsque le taux d’inflation en dollars en offshore est important, surtout lorsque le dollar perd régulièrement de sa valeur par rapport aux autres grandes devises (euro, yen et livre anglaise). Il n’y a pas de raison de refuser que les tarifs du prestataire soient revus à la hausse pour permettre aux collaborateurs de son équipe de maintenir leur pouvoir d’achat. Pour autant, 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 partiellement utile. À défaut d’une meilleure méthode, on peut la retenir, mais en l’ajustant sur un mélange de taux d’inflation en dollars et en euros afin d’éviter les effets d’une forte dévaluation d’une des deux monnaies. Si le taux d’inflation est une bonne base de calcul, il n’est pas toujours représentatif de l’augmentation des salaires moyens des informaticiens dans le pays de l’offshore, qui est parfois bien plus importante que l’inflation. Comme il n’existe pas d’indicateur fiable sur ce sujet, le client a tout intérêt à rester ouvert à des ajustements complémentaires s’ils sont correctement justifiés par le partenaire. Le client jugera comme bon lui semble de la décision à adopter.

Gestion des équipes Les possibilités de management des équipes par le client sont plus ou moins intrusives et peuvent fortement influencer la collaboration avec le prestataire. La flexibilité des équipes dont le client souhaite disposer peut aussi poser des problèmes complexes 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 dans le contrat de partenariat.

Précautions quant au statut des collaborateurs Comme expliqué précédemment, il est important de se protéger contre d’éventuelles actions en justice visant à démontrer que les collaborateurs du prestataire sont des employé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çoivent directement leurs ordres du client et que le prestataire n’a aucun rôle hiérarchique réel. Pour éviter cela, le contrat doit clairement spécifier que les collaborateurs en offshore ne sont pas des employés du client et qu’ils ne peuvent faire valoir ce statut. Il faut également faire attention à certaines clauses. Par exemple, il faut éviter de demander que le client contrôle les salaires des collaborateurs du prestataire ou qu’il les manage directement.

198

Chapitre 9 – Le contrat avec le prestataire offshore

Mieux vaut exposer que les directives du client sont communiquées au prestataire afin d’être appliquées par son management. De même, certaines lois imposent que l’emploi de personnel en régie à un même poste soit limité à une durée maximale, au-delà de laquelle le personnel concerné doit être embauché par le client. Il est important de considérer que le terme « régie » est abusif dans le cas de l’offshore puisqu’il s’oppose simplement au mode forfait. En réalité, il ne s’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 donc d’une prestation de services réalisée par le prestataire dans ses locaux, selon les directives du client. Si le client choisit d’envoyer un de ses employés chez le prestataire pour assurer le management de l’équipe, il est essentiel de faire viser le contrat par un avocat pour s’assurer que cela ne pourra être interprété dans le sens d’un statut d’employeur du client. Ce risque 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 prestataire Certains prestataires emploient des collaborateurs sans pour autant les embaucher officiellement. Cette situation peut être dangereuse à plusieurs titres, comme expliqué au chapitre 3. Le contrat doit prévoir que tous les collaborateurs travaillant pour le client soient 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 engagements 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 luimême et par le client. Le NDA expose les accords de confidentialité, en insistant sur la définition des informations confidentielles et sur la propriété intellectuelle afin d’en protéger la communication et d’interdire l’introduction de code source qui appartiendrait à des tiers. Il précise en outre que le personnel n’est pas autorisé à communiquer à des tiers les logiciels mis à sa disposition par le client en vue d’une distribution dans le pays de l’offshore. Il insiste enfin sur les clauses qui subsistent après le terme du contrat d’embauche, notamment la confidentialité des informations. Dans le cas où un collaborateur quitte le projet, qu’il reste chez le prestataire ou non, il est recommandé de lui transmettre une copie de ce document pour lui rappeler les engagements qu’il a signés et qui survivent à son départ du projet.

Constitution des équipes Il 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 la place 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

199

Conduite de projets informatiques offshore

d’une langue de travail (anglais ou français), ces dernières doivent être clairement exprimées dans le contrat, avec le niveau attendu lorsqu’il est possible de le définir. Elles peuvent toutefois rendre les recrutements plus difficiles et avoir une influence sur les niveaux de prix pratiqués, et donc sur le tarif des collaborateurs. Pour chaque poste, les caractéristiques que devront présenter les candidats sont également consignées. Le contrat doit exprimer comment les candidats seront recrutés, c’est-à-dire si le client déléguera totalement le processus de validation au prestataire ou s’il y sera intégré. Il est recommandé que le client valide les candidats sélectionnés afi n que l’équipe soit construite avec des personnalités avec lesquelles il aime travailler. Ce processus peut être sommairement présenté en annexe du contrat. Le niveau de validation des candidats présentés au client doit être défini afin de s’assurer que, du point de vue du prestataire, chaque candidat remplit les caractéristiques demandées. Lors de l’entretien avec le client, un document pourra résumer les avis des personnes ayant rencontré le candidat et son CV. Le prestataire peut proposer de combler par 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 fortement recommandé qu’il en explique les raisons. Sans règles strictes du processus de recrutement, le prestataire peut avoir tendance à présenter tous les candidats qui envoient leurs CV, surtout si le client a déjà refusé plusieurs candidats et que le prestataire 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 avec succès mais qui n’ont pas encore été validés par le client. Si le client se rend très souvent en offshore, on peut demander à ces candidats d’attendre sa prochaine visite. Dans la majorité des cas, le prestataire pourra vouloir retenir le candidat. Certains prestataires acceptent de prendre le candidat dans leur équipe gratuitement jusqu’à sa validation par le 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 soit difficile de s’en séparer par la suite, comme dans de nombreux pays occidentaux, mais pour tenter de combler certaines de ses lacunes, comme la maîtrise de l’anglais. Cela permet d’enfoncer le clou sur certaines caractéristiques que l’on souhaite vraiment voir respecter.

Flexibilité des équipes La flexibilité des équipes est l’avantage le plus important que recherche le client qui travaille 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 un préavis court et raisonnable, le plus souvent un mois, sans avoir à motiver sa décision. Le client 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 inappropriée, le client peut demander leur retrait de l’équipe immédiatement en motivant sa décision.

200

Chapitre 9 – Le contrat avec le prestataire offshore

Les collaborateurs qui sont retirés de l’équipe du client ne sont pas nécessairement licenciés par le prestataire. Ce dernier peut les affecter à d’autres projets, leur demander d’attendre le prochain contrat ou les licencier. Les contraintes relatives aux recrutements peuvent être définies dans le contrat. Le prestataire ayant tout intérêt à trouver les candidats très rapidement, il n’est toutefois pas indispensable de prévoir de contraintes à ce sujet. Les règles de réduction des effectifs peuvent être très dures pour le prestataire, qui peut se retrouver avec des locaux vides, des postes de travail non amortis ou de nombreux employé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, il peut demander qu’on ne réduise pas les équipes de plus de sept personnes ou 15 % du nombre d’employés en place chaque mois. Les réductions graduelles ne sont cependant pas particulièrement recommandées, car elles entretiennent dans l’équipe du prestataire un climat de méfiance mois après mois.

Retrait de ressources à l’initiative du prestataire Le prestataire peut souhaiter retirer des ressources de l’équipe du client et les remplacer par 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-être l’impression de stagner, d’avoir des difficultés avec son client qui ne reconnaît pas ses capacités ou encore de s’entendre mal avec ses collègues. Les conditions de sortie d’un collaborateur à son initiative ou à celle du prestataire doivent être définies et ne sont pas nécessairement symétriques des conditions de sortie d’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 notification du client est d’un mois. • La possibilité de refuser le départ du collaborateur, par exemple si l’on estime qu’il est utile à 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 les deux personnes sont présentes ensemble sur le projet durant la période de transition. Embauche de collaborateurs par le client Le client peut souhaiter embaucher localement certains collaborateurs du prestataire en offshore. Ce genre d’initiative est excellent pour le moral de tous les collaborateurs, qui y verront 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 équipes Lorsqu’on constitue une équipe assez importante, de plus de vingt personnes, on peut demander qu’elle soit physiquement isolée du reste des collaborateurs du prestataire.

201

Conduite de projets informatiques offshore

Les salles de travail ne sont alors autorisées qu’au personnel travaillant pour le client. Le contrat doit prévoir les règles d’accès à ces salles, notamment pour les visiteurs et les personnes 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 des ressources humaines.

Le montant des salaires On peut demander contractuellement que le prestataire verse des salaires à ses collaborateurs dans la moyenne haute de ce qui est pratiqué dans son pays par les prestataires offshore. Même s’il n’est pas si facile d’établir cette moyenne, tant les données sont subjectives 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 en offshore, car cela pourrait s’apparenter à une reconnaissance d’embauche. Le client souhaite avant tout que la valeur d’un collaborateur soit correctement corrélée avec son salaire, surtout pour les collaborateurs dont il est modérément satisfait. Il souhaite en outre que les salaires de chaque collaborateur soient le plus proportionnels possible à la satisfaction qu’ils procurent. On peut espérer que le prestataire reste ouvert à une relation de confiance et qu’il accepte de discuter des rémunérations de ses équipes. Il est néanmoins peu probable qu’il laisse son client définir les salaires de ses collaborateurs. Après tout, il sait sans doute mieux adresser ce sujet que son client.

Promotions et réorganisations Le client peut demander à organiser son équipe comme il le souhaite pour l’adapter au mieux à ses ambitions et à son mode de travail. Les réorganisations doivent être discutées ouvertement avec le management du prestataire 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 collaborateurs. Le client est toujours tenté de ne conserver que les meilleures ressources, qui sont 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 automatiquement 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érable que le client s’assure contractuellement d’avoir le dernier mot sur ce sujet, même s’il a tout intérêt à traiter ces réorganisations en bonne entente avec le management du prestataire. En tout état de cause, il n’est pas souhaitable que le client se voie imposer des personnes dont il ne veuille pas à des postes clés ou qu’il ne puisse engager la réorganisation qu’il désire.

Les employés à temps partiel La motivation d’utiliser des employés à temps partiel peut provenir du client, qui n’a pas besoin de certaines ressources à temps complet, ou du prestataire, qui ne souhaite pas

202

Chapitre 9 – Le contrat avec le prestataire offshore

allouer une de ses ressources rares sur un unique projet. Ces profils à temps partiel sont généralement de haut niveau et peuvent avoir un point de vue de valeur lors des réunions de management. Il est recommandé de fixer contractuellement les périodes où ces personnes à temps partiel travaillent pour le client de façon à s’assurer que l’on peut facilement organiser des réunions avec eux. On vérifiera notamment que toutes les personnes à temps partiel pourront être présentes simultanément pour organiser des réunions de direction de projet.

Les doubles emplois des collaborateurs Comme expliqué précédemment, certains collaborateurs peuvent avoir l’habitude de cumuler des emplois. Cette pratique pouvant être très pénalisante pour le client, il est important 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éellement que 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 de projet en offshore et sur une bonne entente entre le client et le prestataire. Les choses sont très différentes lorsqu’on travaille sur un projet important, qui doit être structuré et organisé. Dans les projets au forfait en offshore, les aspects procéduraux sont entièrement à la charge du prestataire, lequel met en place la méthodologie qu’il maîtrise bien. Le plus souvent, celle-ci est présentée au client et fait partie des motivations du choix du prestataire. Le client n’a pas de raison de s’immiscer dans les procédures ou le fonctionnement interne du projet si le projet progresse correctement. Le client ne s’intéresse au fonctionnement interne du projet que lorsque le prestataire se montre incapable de tenir ses engagements. Les projets en régie, au contraire, sont gérés par le client selon la méthodologie qu’il a choisie. Celle-ci se fond le plus souvent avec ses propres méthodes internes en tenant compte des particularités de la gestion de projet en offshore. Dans les sections qui suivent, nous nous concentrons surtout sur les aspects contractuels relatifs aux méthodes et procédures des projets en régie permettant au client de contrôler la gestion du projet.

Imposer ses procédures au prestataire Tous les prestataires ne sont pas prêts à adopter les procédures que leur présentent leurs clients. Certains travaillent essentiellement au forfait et ne souhaitent pas que le client s’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 sur ce sujet ne peuvent qu’engendrer moins de rigueur et moins de contrôle. Le contrat doit donc prévoir que le client puisse mettre en place la méthodologie qu’il souhaite.

203

Conduite de projets informatiques offshore

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 configurables. Ces outils pouvant se révéler très coûteux, le contrat doit définir qui du client ou du prestataire fournit les licences correspondantes. Dans certains cas, le prestataire en dispose déjà et peut simplement acquérir des licences complémentaires. Le déploiement de ces outils exige souvent des machines dédiées et une bande passante importante pour assurer les synchronisations entre les référentiels.

Les rapports de suivi Les procédures qui sont mises en place par le client visent généralement, en plus d’une organisation rigoureuse du projet, à obtenir une meilleure transparence de la progression des tâches de développement. Certains rapports fournis au client par le prestataire peuvent ê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, ces rapports 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 pourrait demander au prestataire et inclure dans le contrat la fourniture des informations permettant d’effectuer un suivi fin du travail. Le mieux est de communiquer un modèle des documents de suivi pour valider que le prestataire puisse fournir toutes les informations demandées.

Le suivi de projet au forfait Si le prestataire travaille au forfait, il est théoriquement entièrement responsable du succès du projet. Le client ne doit pas s’interdire pour autant de contrôler la progression du projet et de s’assurer que les engagements du prestataire sont remplis dans les temps et avec la qualité requise. Si le projet progresse de façon impeccable, le client n’a aucune raison d’intervenir chez le prestataire, ses interventions pouvant engendrer des perturbations sur le projet ou même des retards. Si les livraisons intermédiaires sont en retard ou d’une qualité insuffisante, le client peut se trouver en difficulté, et les pénalités sont pour lui une bien maigre compensation. Le projet peut être critique et lié à d’autres projets dont il est une pièce essentielle. La pénalité pour retard que le prestataire doit payer ne compense pas, de beaucoup, le préjudice et 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 livrer dans 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 des ressources supplémentaires sur le projet. Trop souvent oubliés, les trois points suivants devraient être mentionnés dans tout contrat de projet au forfait : • Disposer d’une transparence totale du projet en cours de réalisation par le biais d’audits ou de n’importe quelle communication régulière d’éléments de suivi du projet. Par exemple, le client peut souhaiter analyser certains codes source pour

204

Chapitre 9 – Le contrat avec le prestataire offshore

s’assurer du respect des standards ou suivre les anomalies détectées. On peut demander que le prestataire dispose de moyens automatisés pour assurer la transparence, 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 des personnes pour la gestion du projet. Le statut des pénalités est à prévoir dans le cas où le prestataire perd le contrôle de son projet. Une pénalité fixe pourrait couvrir en partie les efforts supplémentaires auxquels le client est contraint. En effet, le client qui veut sauver son projet doit parfois assurer lui-même la gestion du projet. On peut imaginer un débrayage du projet du forfait en mode régie, si le client le souhaite et est capable d’assumer ce rôle. • En cas d’impossibilité à rétablir une saine gestion de projet, le client peut prévoir une livraison en l’état de la totalité du projet pour le confier à un autre prestataire ou le reprendre lui-même. Les conditions financières doivent en ce cas être précisées pour déterminer quand le client peut déclarer l’arrêt du projet chez le prestataire et les compensations à envisager. D’autres clauses sont bien sûr à prévoir. Les contrats au forfait n’offrant pas beaucoup de spécificités en offshore, ils ne sont pas détaillés dans l’ouvrage, qui se concentre sur les projets en régie.

Communication et références Lors de ses démarches commerciales et marketing, le prestataire souhaite démontrer ses capacité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 à trouver d’autres affaires, ne serait-ce qu’en servant de référence. Le client n’a pas pour autant envie de trouver des articles de presse faisant état de certaines de ses réalisations en offshore. Si le client est une société de services, par exemple, il peut craindre que ses clients ne lui demandent une tarification réduite, puisque les coûts de développement en offshore sont connus pour être faibles. Quant aux éditeurs, ils peuvent craindre que l’image qui découle de l’utilisation des ressources en offshore n’incite à douter de leur solidité ou de la qualité de leurs réalisations. Beaucoup d’autres raisons peuvent justifier que les clients ne souhaitent pas que leur partenariat avec un prestataire en offshore soit communiqué publiquement. Il convient donc de placer dans le contrat les règles que l’on souhaite voir respecter par le prestataire lors de ses communications, que ce soit sur son site Internet, lors de prospections, au cours de communications publicitaires ou encore lors d’échanges directs avec un prospect qualifié. Voici quelques options possibles : • Toute communication à la presse ou à un média de communication de masse (périodique, quotidien, télévision, site Internet, publipostage, mailing de masse) doit être avalisée par le client, qui pourra choisir d’interdire la publication de toute information à son sujet.

205

Conduite de projets informatiques offshore

• 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 mentionner le nom du client. On peut ajouter au besoin des conditions restrictives, comme interdire de présenter l’architecture technique de la solution développée. Le client peut demander une validation des textes de ces communications. Trop souvent, des communications incontrôlées donnent lieu à des communications erronées, parfois dévastatrices.

ÉTUDE DE CAS Un prestataire bavard Un éditeur de logiciel développe un produit dont une version spécifique est exploitée par une banque qui met ce service à la disposition de ses clients d’entreprise. Le produit est développé en offshore. Un journaliste, faisant un article sur l’offshore, parle à l’un des responsables marketing du prestataire offshore. En l’absence de règles, et puisque l’éditeur est très peu connu, contrairement à la banque qui exploite le service, le responsable marketing omet de mentionner l’éditeur et explique que 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 de mettre un terme à ses relations avec l’éditeur. Elle exige en outre des dommages et intérêts pour cette communication abusive qui nuit à son image.

On peut prévoir des pénalités importantes en cas de non-respect de ces clauses. Autrement, le prestataire calculateur se dira que l’effet positif qu’il peut tirer de cette communication 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 pris l’initiative et le plus souvent pour les deux parties. Il est important de décrire les engagement s des deux parties lors de cette période délicate. Le client comme le prestataire peuvent chercher à rompre le contrat. Dans tous les cas, il faut terminer proprement le partenariat et donc à la fois les services fournis par le prestataire et les obligations de paiement du client. Il faut aussi prévoir la restitution de toutes les informations propriétaires et confidentielles. Le prestataire peut demander que le client 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 aux collaborateurs 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 à respecter pour 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.

206

Chapitre 9 – Le contrat avec le prestataire offshore

Les biens achetés au réel, comme le matériel et les serveurs, peuvent être revendus (le prix de la revente venant en déduction des factures dues par le client), être envoyés au client ou abandonnés au prestataire. Le matériel prêté par le client lui est retourné à ses frais lorsque c’est possible. Les services récurrents qui sont refacturés au réel et peuvent faire partie d’un abonnement avec une durée minimale doivent être traités contractuellement. Par exemple, si le projet 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 souhaite de démarrer d’autres services sur les mêmes bases.

Protéger la propriété intellectuelle au-delà du partenariat Quelle que soit la raison de la fin du contrat de partenariat, que ce soit un différend ou une fin prévue des prestations, il faut s’assurer que les clauses sur la protection de la propriété intellectuelle lui survivent. Si on le juge nécessaire, on peut donner à chacun des collaborateurs un document leur signifiant que les informations confidentielles qui leur ont été communiquées sont toujours protégées par les accords sur la protection de la propriété intellectuelle et par les accords de confidentialité, pendant une durée spécifiée au contrat. On peut demander que ce document soit signé, mais on ne peut contraindre les collaborateurs à le faire. De fait, 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 que des 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é ou détruit, sans intention de nuire. Beaucoup de chefs de projet aiment aussi à conserver les trophées de leurs missions et à disposer d’une sauvegarde complète qui leur sert d’aidemémoire sur certains sujets.

Arbitrage et médiation Si des conflits sérieux éclatent entre le prestataire et son client, il est bon de prévoir le recours à la médiation ou à un arbitrage. Ce sont des procédures formelles, avec des arbitres ou 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 le conflit 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 fait sentir. Il est recommandé de demander à l’avocat qui valide le contrat d’y inclure une clause de médiation avant de faire appel à la justice.

207

Conduite de projets informatiques offshore

Conclusion Le contrat est un sujet délicat, dans lequel le client cherche à définir clairement l’étendue de son contrôle sur les équipes que met à sa disposition le prestataire et souhaite à la fois se garantir des moyens d’action et responsabiliser le prestataire. La plupart des thèmes contractuels participent à la définition d’un bon équilibre entre le prestataire 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 les moyens. 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 parfois l’objectif de livraison final. À l’inverse, un contrat trop permissif laisse le client sans moyens 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. Certaines d’entre elles seraient impossibles en France, par exemple, comme le NDA signé par chaque 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.

208

PARTIE

3

Gestion des projets en offshore Cette partie traite de la réalisation des projets en offshore. Nous supposons ici que le client a bien compris les mécanismes majeurs de l’offshore, que le projet a été soigneusement choisi et que le contrat qui le lie au prestataire est conçu de telle sorte à lui donner un contrôle suffisant sur le déroulement des opérations. Nous supposons également que le client a choisi de travailler essentiellement selon un mode régie, qui permet de profiter pleinement de tous les avantages de l’offshore. Un grand nombre des remarques qui parsèment les chapitres qui suivent pourraient s’appliquer à des projets réalisés localement au lieu de l’offshore et porteraient probablement aussi pleinement leurs fruits. Ces bonnes pratiques, qui apportent gain de productivité et confort dans la gestion des projets locaux, deviennent des garanties de succès lorsqu’on travaille avec une équipe distante. Nous insistons particulièrement sur la gestion des ressources humaines et l’organisation hiérarchique, qui permet d’obtenir une forte adhésion des équipes au projet. Une bonne organisation des hommes est toujours beaucoup plus efficace que la mise en place d’une méthodologie stricte. Lorsque des hommes aux responsabilités clairement définies veulent faire aboutir un projet et mettent leur énergie en commun pour y parvenir, ils parviennent à contourner les défauts des procédures pour aboutir à un fonctionnement efficace. La méthodologie est en revanche essentielle pour définir les éléments produits par les différents intervenants, définir les workflows les plus importants et assurer une bonne compréhension de l’état du projet selon des indicateurs objectifs partagés entre les intervenants. L’approche itérative, qui est trop souvent mal comprise, assure une saine pression sur les équipes et permet de juger la progression du projet sur les réalisations et non pas sur des estimations humaines. Elle apporte en outre une unité des éléments créés dans les

Conduite de projets informatiques offshore

équipes. La planification, une tâche toujours délicate, est elle-même mieux définie par l’approche itérative. La qualité des réalisations en offshore est parfois mise en question. Nous portons une attention particulière à montrer comment la contrôler pour atteindre des niveaux de finition satisfaisants à toutes les étapes. Le déploiement sur des plates-formes en architecture n-tiers à plusieurs serveurs, avec des 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 du programme 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 est généralement confiée à du personnel local alors que l’offshore peut apporter plus de flexibilité pour la supervision et la haute disponibilité de la plate-forme.

210

Chapitre 10

Les points clés de la gestion de projet en offshore Ce chapitre traite essentiellement du commencement de la relation de partenariat avec le prestataire en offshore, un moment à la fois excitant et délicat de la vie du projet. Les sujets abordés peuvent aussi s’appliquer à un projet en cours que l’on souhaite réorganiser. Si les principes énoncés valent pour les projets locaux comme pour les projets en offshore, 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ère des projets en offshore. Une bonne organisation des hommes et des principes méthodologiques affirmés sont les meilleures garanties de succès.

La satisfaction du client Les participants au projet chez le prestataire et le client sont impatients de démarrer le projet encore exempt de défaut et de déception, et chacun se persuade que cette fois le projet se déroulera sans anicroche. Chez le client, le budget attribué est convenable. On y a prévu les dépenses pour les effectifs, le matériel et les voyages. Le prestataire affiche luimême un excellent état d’esprit et désire très bien faire. Armé de l’expérience de tous les problèmes rencontrés dans le passé, il pense pouvoir les éviter et atteindre un fort niveau de satisfaction du client. Les différences culturelles sont alors perçues comme intéressantes et enrichissantes intellectuellement. On va apprendre à travailler avec une équipe que l’on ne connaît pas encore, mais qui a déjà démontré son expertise. De part et d’autre, on veut montrer ce dont 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 laisser des traces durables. Chez le prestataire, c’est un moment de tension, car le moindre accrochage 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.

211

Conduite de projets informatiques offshore

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ésente certaines personnes qui ne conviennent pas du tout, ce qui inquiète le client ; certains chefs de projet sont de fortes têtes ; les locaux de travail sont décevants ; etc. Les motifs d’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 plus souvent lors d’un premier projet en offshore. On y voit que le crédit que l’on accorde d’emblée vacille dès que le travail commence. La déception est généralement immense lors des premières livraisons pour ensuite remonter vers un niveau de satisfaction en rapport avec les attentes de l’équipe de management du client. Le retour à une satisfaction acceptable dépend de l’expérience des personnes impliquées pour trouver rapidement des solutions aux sujets d’insatisfaction.

Figure 10.1. Satisfaction du client sur le premier projet

Lors du démarrage du projet, on découvre comment l’équipe distante accepte et applique les procédures. Ce sont encore des sujets complexes. Ce chapitre traite de cette phase difficile, où le travail réalisé est beaucoup moins important que la façon dont on met en place les équipes et de bonnes pratiques de gestion de projet, tout en sachant qu’on n’est pas en contact quotidien avec les équipes distantes. Cet éloignement exige rigueur et organisation pour faire en sorte que le projet trouve par lui-même les meilleurs chemins lorsque les procédures font défaut. Pour atteindre les meilleures chances de réussite et éviter quantité de pièges, le manager du 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 rencontre nombre de managers qui expliquent fort bien ce qu’il faut faire et agissent à l’opposé.

212

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

Garder une vision claire des objectifs de management Le travail avec l’offshore a rapidement tendance à devenir touffu et confus. Des questions de tous ordres surgissent, et de nombreux domaines organisationnels qui se règlent d’eux-mêmes localement demandent en offshore une intervention du client. Il est très facile de se laisser absorber par les problèmes secondaires portés sur le devant de la scè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 ce dernier 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 heures supplémentaires, les matériels et les services additionnels les plus importants, mais certaines clauses sont en cours de relecture et d’amendement. Les tensions qui surviennent pendant cette période peuvent suspendre la signature du contrat et amplifier les attitudes 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 le projet. Il peut lui arriver de changer d’avis, de se tromper et de se raviser. Ces changements se produisent tout le long du projet, qu’il s’agisse d’adaptation à des conditions de marché qui ont changé, de technologies qui ont évolué ou encore de recherche d’une meilleure productivité. Certains de ces changements peuvent viser à se protéger de faiblesses du prestataire ou au contraire à profiter de certains points forts que l’on ne soupçonnait pas avant de commencer. Dans tous les cas, il convient de s’assurer que les décisions sont toujours contrôlées par le 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 prestataires en offshore savent que c’est un moment où ils peuvent assez facilement imposer leur point de vue. Dans ce brouhaha de décisions de tous ordres, où les sujets importants sont mêlés aux secondaires, il est essentiel que le manager du client conserve des objectifs organisationnels clairs et qu’il les considère comme un fil directeur pour toutes les décisions qu’il prend. Cette recommandation s’applique tout autant à la phase de démarrage du projet qu’à 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 techniques

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.

213

Conduite de projets informatiques offshore

Tableau 10.1. Objectifs clés du projet(suite) Objectif

Commentaire

Mise en place des méthodes essentielles

À tout moment dans le projet, des processus doivent couvrir les nouvelles activité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éthodologiques

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écessaire, 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’utilisation 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écification 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’application.

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 pleinement utilisées. L’utilisation partielle de celles-ci mène à des suivis de progression approximatifs, et donc à de mauvaises décisions.

214

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

Tableau 10.1. Objectifs clés du projet(suite) Objectif

Commentaire

Recherche de la qualité à tous les niveaux des réalisations, 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ériodique. 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 compilations et déploiements

L’automatisation du déploiement est essentielle pour assurer la fiabilité de la solution sur les plates-formes.

Les objectifs clés présentés dans ce tableau ne sont bien sûr pas exhaustifs. Chaque projet ayant ses spécificités, on trouvera des sujets particuliers à traiter ou d’autres qui prendront une importance plus appuyée. Les objectifs listés ici, à peu près dans l’ordre où on les rencontre, conviennent cependant à nombre de projets. Ces objectifs sont essentiellement organisationnels. Les chefs de projet en offshore peuvent se sentir pressés par des objectifs opérationnels, comme la livraison d’analyses ou de programmes, qu’ils jugent plus importants. Ils ont souvent l’impression que les tâches organisationnelles sont secondaires et qu’ils sont surtout jugés sur les tâches opérationnelles et sur le respect de leurs engagements sur les livrables. Pour que ces tâches organisationnelles progressent correctement, il faut qu’elles soient clairement identifiées comme des objectifs sur lesquels on jugera aussi les qualités des collaborateurs. On rencontre souvent des organisations où l’on attribue des priorités aux tâches à réaliser et où les tâches organisationnelles reçoivent une priorité moyenne et ne sont jamais réalisées. Pour mettre en place les procédures qui conviennent, il est essentiel de 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 de mettre 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 concentrer sur certains objectifs organisationnels clairs qui structurent le projet et apportent productivité et transparence, ainsi qu’un suivi plus aisé du projet. En concurrence avec des objectifs directement opérationnels, les tâches organisationnelles sont souvent délaissées par les chefs de projet. Il importe de s’assurer qu’elles sont bien intégrées dans leurs objectifs et de leur faire comprendre qu’ils seront aussi jugés sur leur volonté à appliquer méthodes et procédures.

215

Conduite de projets informatiques offshore

Transparence de la communication La communication est rarement naturelle entre deux sites distants et requiert toujours un effort important et volontaire. On ne se rend pas toujours compte de la quantité d’information qui est échangée entre les membres d’une équipe locale et son management autour de la machine à café, au cours de déjeuners ou simplement lors de rencontres fortuites dans les couloirs. On prend la pleine mesure de l’importance de ces échanges informels lorsqu’on les perd en travaillant avec une équipe distante. Les collaborateurs, qu’ils soient locaux ou distants, n’aiment afficher ni leurs faiblesses ni leurs échecs. Ils essaient de les masquer et de les corriger avant que leur hiérarchie s’en aperçoive et ne les reconnaissent que lorsqu’ils ne peuvent plus les cacher. Si cette attitude 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 possible les 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’en trouve grandement simplifié. L’équipe distante ne peut être transparente que si le client se montre juste et tolérant. Lorsque l’équipe distante, en essayant d’appliquer les recommandations de transparence du client, fait état de problèmes, qu’il s’agisse d’un retard que l’on anticipe, de personnel insuffisamment formé ou du départ inopiné d’un membre clé de l’équipe, il est primordial que le client réagisse. Il travaille alors avec le prestataire pour trouver des solutions. Il n’est pas question de chercher systématiquement les coupables éventuels à punir. Les reproches seraient compris comme une forte réprimande. Dès lors, les managers du prestataire n’essaieraient plus de faire part de leurs difficultés et pré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écoulent 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 tout celle du management de l’offshore ou du client qui n’a pas su placer la bonne personne au bon endroit et qui a donné au collaborateur des tâches au-dessus de ses capacités. Le punir pour ne pas avoir atteint ses objectifs et le laisser à son poste sans changement est illogique. La punition n’a de sens qu’en cas de négligence ou d’une volonté manifeste de mal faire. Si les managers de l’équipe distante connaissent certains problèmes mais les cachent 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 informations nécessaires pour décider comment le corriger. Il se peut que le problème n’en soit pas vraiment un et qu’il découle simplement de modifications des priorités du client. Le client 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éplacer certaines fonctionnalités vers une release ultérieure. Le client doit alors repréciser les engagements 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 fonctionnement, comme ajuster les effectifs ou redéfinir les contenus des versions. Lorsque le prestataire cache un problème en essayant de le résoudre par lui-même, il restreint rapidement le spectre des actions correctives à appliquer.

216

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

La transparence crée un état d’esprit qui conditionne la façon de collaborer entre le prestataire et le client. Sans elle, le client suppose que le prestataire cherche à lui cacher de nombreux problèmes et passe son temps à tenter de les découvrir. De son côté, le prestataire pense avant tout à éviter les réprimandes et dissimule tout ce qui peut en occasionner. On connaît aussi ces attitudes de suspicion et de dissimulation avec les équipes locales, mais la distance avec le site de production rend les défauts de communication beaucoup plus difficiles à gérer. EN RÉSUMÉ Communication transparente

Une communication transparente entre le prestataire et le client découle d’un niveau de confiance fort et d’un véritable esprit de partenariat. Le prestataire fait état de ses difficultés au plus tôt pour rechercher avec le client les meilleures solutions. De son côté, le client se montre tolérant et constructif pour traiter les sources des problèmes. La confiance qui va de pair avec cette communication transparente rend le travail beaucoup plus productif, réactif et constructif, donnant à l’équipe distante 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 un impact sur le succès du projet. Pour une bonne gestion des risques, tous les membr es du projet doivent s’exprimer sur le sujet, qui ne doit pas devenir un domaine réservé du management. Les personnes directement impliquées sur certaines tâches perçoivent mieux les risques importants. 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 chaque risque identifié et d’adresser les plus importants avec l’attention qu’ils méritent afin de trouver 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 qui doivent être fortement utilisées par les développeurs fonctionnels dès l’itération suivante, il peut savoir longtemps à l’avance que celles-ci ne seront probablement pas suffisamment stables pour que le code fonctionnel s’appuie sur elles. S’il se fait entendre suffisamment 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 les mentionne. Ainsi, un développeur peut s’inquiéter de la difficulté à construire l’équipe de test ou de la capacité à tester la production. Chaque tâche de développement peut être associée à un risque. Lorsqu’on traite pour la première fois une solution technique, on n’est pas certain de respecter une exigence de performance avec une technologie donnée, ou encore on s’inquiète de la qualité de l’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. Cela permet de fiabiliser les projections en éliminant les facteurs d’incertitude mais aussi de

217

Conduite de projets informatiques offshore

trouver des solutions de remplacement si un problème apparaît comme bloquant. Le risque est 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. Les risques sont traités selon leur importance fonctionnelle afin que le risk manager puisse définir des priorité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 correctives possibles 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 le risque se confirme ou disparaît. Le rôle de risk manager peut exister sur tous les types de projets, quelle qu’en soit la taille. Sur les petits projets, ce rôle peut ne consommer que quelques heures par mois, alors qu’il peut représenter une charge de travail importante sur d’autres projets. Pour être efficace, il convient de classer les risques pour ne se concentrer que sur ceux qui sont réellement importants. On peut appliquer avec succès une mesure des risques en multipliant 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 assez juste en les comparant entre eux. Les pondérations sont discutées lors des réunions de management de sorte que l’importance 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 est vivante. Les mesures sont revues périodiquement et ajustées en fonction de l’évolution de 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 des maillons les plus faibles. Les collaborateurs ne se concentrent pas toujours suffisamment sur la qualité de leur production, surtout s’ils savent que leurs défauts seront détectés et corrigés par la suite. La livraison personnelle peut facilement devenir le but unique, indépendamment de la qualité du livrable, que l’on considère comme corrigible par la suite. Cette attitude est encore renforcée si des primes ne sont accordées qu’en fonction de la mise à disposition du livrable personnel, sans se soucier de leur qualité. Cette attitude est particulièrement amplifiée avec les équipes distantes. On se rend moins facilement compte à distance que des développeurs livrent précipitamment des programmes que l’équipe de test peut à peine compiler. Ils estiment que la livraison de leur production dans les délais est ce qui sera facilement remarqué, alors même que la qualité du livrable est toujours plus discutable.

218

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

Il en va de même des aspects procéduraux, qui sont souvent mal appliqués chez le prestataire, car difficiles à cerner. Comme les procédures sont aussi mal respectées localement chez le client lui-même, les équipes distantes s’imaginent volontiers qu’elles n’ont pas à s’en soucier davantage. Il faut être intransigeant sur le respect des procédures en offshore, qui doivent être prises en compte au même titre que la mise à disposition du livrable. La tolérance que l’on constate en local sur les processus s’explique par le fait que l’on mesure mieux le contexte et les efforts nécessaires pour parvenir à l’objectif souhaité lorsqu’on voit les hommes et les efforts fournis. La communication est aussi plus fluide, et les inquiétudes sont plus facilement levées. À l’offshore, au contraire, où l’on ne voit pas les équipes qui réalisent le travail sans respecter les procédures, on est prompt à imaginer un immense laisseraller 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 peut que le temps de développement pour une première livraison approximative soit de vingt jours 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. Lorsque le testeur affirme avoir exécuté son scénario de test avec attention, si l’on sait que la volonté 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 personne ne sait vraiment comment considérer une livraison lorsque son état de qualité est inacceptable. Le respect de la qualité devrait être motivé par tous les moyens possibles, en rejetant simplement les livrables qui ne respectent par les engagements de qualité et en motivant par des primes le respect de la qualité. Par exemple, la faible quantité d’anomalies détecté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’agit non seulement de prévoir un livrable à une date donnée mais aussi de s’assurer que le livrable ne sera considéré comme livré que s’il atteint un certain niveau de qualité. Si tous les 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 titre que 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 des plannings.

Procédures utiles Lorsqu’on met en place un cadre procédural, il apparaît que les domaines que couvrent des approches structurées, comme RUP ou XP, sont beaucoup plus vastes que ce dont on

219

Conduite de projets informatiques offshore

a réellement besoin. Comme toutes ces procédures et documents ont une utilité plus ou moins 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 et les ressources à allouer au projet. Ce point peut souvent être un casse-tête à gérer. Si l’on connaît ce que l’on souhaite créer, on ne sait pas toujours le définir précisément ni si l’on est prêt à garantir des moyens pour sa réalisation. Personne ne souhaite vraiment s’engager sur 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 pourront être réduites en cours de projet, le contenu sera peut-être modifié et d’autres événements viendront sans doute perturber le cours du projet. Dans tous les cas, le responsable du projet s’adaptera pour faire fonctionner le projet au mieux, que ce document décrivant le 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 essentiellement le résultat de la mise en place des seules procédures réellement utiles aux yeux de tous. La complexité provient le plus souvent de l’incompréhension des collaborateurs ou de la poursuite d’informations inexistantes ou sur lesquelles personne ne souhaite s’engager. Les collaborateurs en offshore comprennent que l’on a besoin de workflow et d’éléments de suivi mais acceptent mal que les procédures soient approximatives ou inutiles. Il convient alors de repérer toutes les procédures et normes qui sont réellement nécessaires et de les mettre en place en prenant soin de former le personnel non seulement sur les procédures elles-mêmes, mais aussi sur le plan qualité complet en en expliquant l’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 exprimer des remarques, et ces dernières doivent être prises en compte pour assurer l’amélioration et l’efficacité des procédures. Les procédures seront alors fermement respectées, et l’on pourra 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 doivent les appliquer. On évitera de mettre en place des procédures ou normes dont l’utilité pratique est discutable, même si elles sont intellectuellement utiles. Les procédures doivent être en constante adaptation 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èle se définit par opposition au modèle en waterfall, ou en V, qui ne permet pas de détecter suffisamment 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. Il s’appuie sur un découpage du projet en tranches de temps, souvent fixées par avance et d’une durée définie, dans lesquelles on distribue les tâches du projet de façon à éliminer

220

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

le plus tôt possible les incertitudes et les risques. On définit ainsi une feuille de route pour 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 des tâches accomplies lors des itérations varie selon la phase du projet. Lors des premières itérations, les activités relatives à la modélisation sont plus importantes, pour ensuite laisser plus de place à l’implémentation et aux tests dans les itérations suivantes. Toutes les 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 du projet.

Figure 10.2. Contenu des itérations

Pour conduire efficacement une approche itérative, il convient de mettre en place une gestion stricte des exigences que l’on souhaite trouver dans le produit final. La grande majorité des exigences correspond à des features fonctionnelles, mais on peut également y 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 typiquement l’importance de l’exigence, le risque qui y est associé, sa stabilité (risque-t-on de 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, par exemple, à lever en priorité les risques et les incertitudes sur les faisabilités, les exigences les plus importantes et celles qui sont les plus complexes. Cette séquence est utilisée pour ordonner le séquencement des réalisations.

221

Conduite de projets informatiques offshore

Défini grossièrement à partir de la gestion des exigences en début de projet, le contenu de chaque itération est détaillé peu de temps avant son commencement. Cela permet d’être en phase avec les événements récents susceptibles de rendre certains objectifs inatteignables 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, de test, 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 progression du projet en fonction d’éléments tangibles et non d’informations invérifiables fournies par les chefs de projet. En l’absence de processus itératif, on est contraint de mesurer la progression d’un projet en interrogeant les team leaders, qui gèrent les petites équipes de quelques personnes. Même s’ils sont au cœur du projet, leur avis n’est pas pour autant qualifié. 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 était prévu. Il faut que l’itération soit suffisamment longue pour permettre un réel accomplissement des équipes et suffisamment courte pour disposer de plusieurs itérations sur le projet afin de mettre en place les actions correctives nécessaires. L’expérience montre que des itérations de l’ordre de quatre à six semaines conviennent assez bien aux projets d’environ un an. Le contenu de l’itération est stable puisqu’il concerne une durée assez courte, qui connaît peu de changements. Ceux-ci seront certainement planifiés sur les itérations suivantes en respectant la stabilité de l’itération en cours. Les objectifs qui ne sont pas atteints sont alors de la responsabilité de l’équipe en charge de la réalisation. Cette dernière ne peut dès lors expliquer les retards par des événements extérieurs, comme des changements d’orientation ou des décisions qui ont eu des effets plus profonds qu’on ne l’avait anticipé, le contenu de l’itération étant stable. Les retards sont le plus souvent dus à des erreurs d’appréciation ou d’anticipation. Par la suite, l’équipe fera plus attention à bien estimer les charges afin d’être capables de tenir leurs engagements, apportant ainsi plus de 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 la communication, notamment lorsque des questions restent longtemps sans réponses, ou les 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 des actions correctives. À la fin de chaque itération, on tire les conclusions qui conviennent. Elles permettent de mettre à 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és fonctionnelles 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 affectent les itérations suivantes. L’itération qui suit directement celle qui se termine est pratiquement entièrement définie par les tâches qui sont déjà engagées et ne peut être fortement

222

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

modifiée. Les conclusions de l’itération 2, par exemple, commencent à avoir une réelle influence sur les itérations 4 et suivantes.

Itération 1

Itération 2

Itération 3

Itération 4

Itération 5

Terminée

En cours

Prochaine itération

Future

Future

Archivée

Planning validé

Planning en construction

Ebauche de planning

Planning précis

Flexibilité du contenu des itérations

Instant présent

Figure 10.3. Stabilité du contenu des itérations

Le contenu de l’itération suivante est défini avant la fin de l’itération et ajusté jusqu’à la fin 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 sontils pas atteints ? Quelles actions peuvent être engagées pour rattraper ce retard au cours 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 les procédures ? Quels ajustements sont nécessaires ? • Le planning des itérations du projet est-il compatible avec l’expérience que l’on a acquise ? 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 des objectifs à 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 pour expliquer que l’objectif est pratiquement atteint et que les causes ne viennent pas de l’équipe mais de l’extérieur. • On détecte les problèmes beaucoup plus rapidement que dans les cycles en waterfall car on 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érience montre qu’à partir de 30 ou 50 % du projet, les itérations sont très fiables et permettent d’anticiper précisément la progression du projet.

223

Conduite de projets informatiques offshore

• On favorise le travail en équipe puisque les objectifs à atteindre peuvent être multidisciplinaires. Par exemple, un objectif de livraison testée signifie que le produit est livré et pleinement testé. Le développeur qui sait être jugé sur cet objectif va certainement 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 ces objectifs 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 incontournable dès lors qu’on travaille en offshore. Il permet tout à la fois de mesurer la réalité de la progression du projet, de conserver une productivité optimale de tous les membres des équipes et de construire des planifications plus sûres, qui s’appuient sur une expérience objective. De plus, il favorise 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 pas demander de capacités de management aux team leaders. Ces derniers doivent être capables d’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 que les problèmes rencontrés en offshore trouvent une réponse sur place, qu’il s’agisse de sujets techniques, d’informatique interne, fonctionnels, architecturaux ou de procédure. Certains responsables en offshore peuvent solliciter leurs correspondants chez le client 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 production personnelle. Celle-ci contribue à un objectif d’équipe qui vise à livrer un exécutable de qualité convenable aux utilisateurs. Chaque collaborateur doit comprendre que ses livrables personnels ne sont importants que dans la mesure où ils contribuent au livrable final. Il doit accompagner sa production pour s’assurer de son bon usage dans la 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 testeur peut travailler sur sa production dans les meilleures conditions afin de fournir un livrable de qualité à l’utilisateur. • Tous les collaborateurs sont pairs. Les développeurs ne sont pas supérieurs aux testeurs 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 de l’attentisme et de la passivité. L’absence d’action doit être sanctionnée et non une initiative malencontreuse.

224

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

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 le contrôle des décisions. Ce type d’approche déresponsabilise les équipes en offshore et tend à réduire significativement la productivité. À partir de petites équipes, aux domaines de responsabilité circonscrits, il convient au contraire de confier des responsabilités à chaque membre de l’équipe, qui doit se sentir capable 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’attribution temporaire de une ou deux personnes provenant d’autres équipes pour terminer certaines tâches. La validation finale sera sans doute confirmée par le client, qui jugera de la pertinence 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 pour qu’elle soit distribuée dans les équipes. Si des managers refusent de déléguer leurs responsabilités, les effets positifs de la responsabilisation des équipes en offshore sont perdus.

Gestion des tâches clés Lorsque des tâches clés ne sont pas bien assurées en offshore, il faut en contraindre la gestion avec toute l’attention voulue. Un premier moyen pour cela est de les inscrire dans les objectifs des itérations et de leur attribuer 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 les tâ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 comme objectifs clairs des itérations et dédier une personne à leur gestion. C’est tout l’avantage des faibles coû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ées dans ce chapitre pour la gestion des projets en offshore. On peut penser que ces remarques s’appliquent de la même façon à tous les projets informatiques, ce qui est vrai en règle

225

Conduite de projets informatiques offshore

générale. Dans le cas des réalisations en offshore, ces sujets prennent toutefois une importance accrue. Bien que difficile à mettre en œuvre, l’approche itérative ne présente que des avantages en offshore. Elle cadre au plus juste le travail des collaborateurs, maintient une pression continue et permet de clairement identifier les responsabilités. La responsabilisation de l’offshore est non moins capitale pour atteindre le meilleur niveau de qualité et de productivité. Trop souvent, le client cherche à imposer sa mainmise sur les équipes distantes et à transformer le prestataire en une sorte d’usine de codage, qui ne doit surtout pas prendre de décisions, ce qui ne peut que le déresponsabiliser. À défaut de prendre pleinement en compte ces questions clés, il reste sans doute possible de réussir ses projets en offshore, mais sans atteindre le meilleur des capacités du prestataire. Les qualités personnelles viennent parfois compenser une méthodologie inadaptée. En appliquant les recommandations de ce chapitre, il est possible d’optimiser les chances de succès du projet.

226

Chapitre 11

Gestion des ressources humaines Les hommes sont essentiels à la réussite du projet et au succès des opérations. Nous avons déjà traité de leurs motivations, ainsi que des procédures d’embauche et de sélection. Ce chapitre aborde l’organisation des ressources humaines, qui contribue plus fortement au succès du projet que l’industrialisation des développements, cette dernière ne pouvant donner sa pleine puissance que si l’organisation humaine est performante. L’organigramme cible définissant le profil de chaque poste à pourvoir permet de structurer 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 manquent jamais de modifier le projet initial. Quelques règles importantes permettent de monter des équipes qui fonctionnent efficacement dans tous les environnements et savent s’adapter aux conditions changeantes que l’on rencontre toujours en cours de projet. Même les défaillances des procédures et des workflows trouvent naturellement des solutions lorsque l’organisation des hommes et 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 nombreux 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 management des hommes et l’initiative personnelle sont rarement mis en avant, et les managers ne se soucient guère de détecter le potentiel de chacun afi n de l’exploiter. On favorise au contraire trop souvent le travail silencieux, qui, à la longue, devient le fossoyeur des ambitions. 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 rares et de qualité, tout autant de jeunes ambitieux sans grande envergure, qui s’imaginent un peu vite que le monde les attend. Si ces profi ls existent aussi dans le pays du client, en offshore, on rêve plus volontiers à des carrières sans limite, à l’exemple de quelques réussites spectaculaires.

227

Conduite de projets informatiques offshore

Le management est une qualité si rare dans les pays de l’offshore que l’on se trouve souvent 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 quelques personnes, dont le management (middle management) est simple à assurer et permet de saisir tous les aspects de la production. Les vrais postes de manager, gérant plus d’une dizaine de personnes, sont réservés à un très petit groupe de collaborateurs, qui doit être choisi avec soin. Les recruteurs peuvent faire de nombreuses erreurs dans la sélection des managers, aveuglés par l’assurance de quelques candidats. Pourtant, certaines personnes ont tellement peu 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, mais de 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 est celui d’un manager d’équipe fraîchement nommé affirmant que le choix de Java comme environnement de développement ne plaisait pas à certains développeurs et décidant que 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 ne surtout pas rater les vrais talents autour desquels la bâtir. L’offshore offre à qui sait les voir de nombreux profils inhabituels de qualité. Pour les accueillir, il faut parfois ajuster l’organigramme cible. Ces profils vont d’excellents techniciens à des personnes dont on perçoit une recherche de la qualité alliée à une forte capacité de travail en passant par ceux 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. Il aurait répondu qu’il suffisait de mesurer deux traits de caractère : la paresse ou l’activité et l’intelligence ou la sottise. Cela lui permettait de répartir les hommes en catégories et en rôles. Les paresseux passifs constituaient l’essentiel de l’infanterie, car, disait l’empereur, on en trouve une quantité effroyable. Les actifs intelligents fournissaient ses officiers de campagne, car ils pouvaient déployer une énergie colossale pour parvenir à faire exécuter à l’infanterie les manœuvres que l’on souhaitait. Les paresseux intelligents devenaient généraux, car ils trouvaient toujours la meilleure façon d’atteindre un objectif, 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 et sots ? Ceux-là, je les fusille. »

228

Chapitre 11 – Gestion des ressources humaines

Distribution des responsabilités La distribution des responsabilités est certainement l’une des clés du succès des opérations en offshore. La distribution des rôles sur les hommes et la gestion des ressources humaines ne sont pratiquement jamais abordées dans les méthodologies telles que RUP et XP. En revanche, Microsoft propose un cadre de travail avec MSF (Microsoft Solutions Framework), qui traite essentiellement de la gestion des hommes et de la mise en place de flux simples (www.microsoft.com/msf), notamment à travers leur modèle d’équipe (team model). De nombreux principes de MSF complètent harmonieusement les recommandations de RUP et XP. Les sections qui suivent exposent certains principes assez proches de la démarche du framework MSF.

Petites équipes Le premier principe de gestion des ressources humaines en offshore est de construire de petites équipes soudées, dans lesquelles les personnes s’assistent mutuellement pour atteindre 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 travail d’équipe (développeurs, testeurs, architectes, mentors) est l’objectif commun, les objectifs individuels ne faisant que contribuer à cet objectif commun. Pour que ce modèle fonctionne, les règles suivantes doivent être respectées au sein de l’équipe : • La qualité des productions individuelles comme des livrables de l’équipe est la préoccupation de tous. • Chaque membre de l’équipe communique de façon transparente avec les autres comme vers l’extérieur, tout particulièrement si des réalisations externes dépendent de 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’investissement d’une responsabilité personnelle. Chacun des membres de l’équipe est en contact quotidien 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 participent intégralement à leurs réalisations en fournissant tous les services dont elles ont besoin 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 équipe Il convient de définir clairement les rôles à remplir dans chaque équipe, sachant que certains d’entre eux seront assurés par une personne à temps partiel et d’autres par quatre ou cinq personnes à temps plein. Le tableau 11.1 récapitule l’ensemble de ces rôles. La colonne Client indique si l’on trouve ce rôle chez le client, la colonne Offshore si le rôle peut être assuré en offshore, et

229

Conduite de projets informatiques offshore

la colonne Partagé/dédié si le rôle est pleinement intégré à une équipe à temps complet ou 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égocie 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 équipes 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’utilisateur 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é

230

Chapitre 11 – Gestion des ressources humaines

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énaturer la 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 être partagés entre plusieurs équipes. Tableau 11.2. Cumul des rôles Chef de marché Chef de marché

Chef de produit

Développement

Testeur

Déploiement

Exploitation

Éducation

Oui

Peu souhaité

Peu souhaité

Peu souhaité

Peu souhaité

Oui

Peu souhaité

Oui

Peu souhaité

Peu souhaité

Oui

Non

Oui

Peu souhaité

Peu souhaité

Oui

Oui

Oui

Oui

Peu souhaité

Chef de produit

Oui

Développement

Peu souhaité

Peu souhaité

Testeur

Peu souhaité

Oui

Non

Déploiement

Peu souhaité

Peu souhaité

Oui

Oui

Exploitation

Peu souhaité

Peu souhaité

Peu souhaité

Oui

Oui

Oui

Oui

Peu souhaité

Oui

Peu souhaité

Éducation

Peu souhaité Peu souhaité

Dans chaque équipe, on trouve certains rôles chez le client et d’autres chez le prestataire en offshore. Le plus souvent, les rôles de chef de marché et de chef de produit sont assurés par le client, qui définit le produit à réaliser. Le chef de produit assure aussi un rô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 fonctionnement des livrables, ceux-ci ayant été testés par l’équipe de test le plus souvent située chez le prestataire. Certains mentors définissent chez le client les grandes lignes à respecter, comme les choix technologiques et les lignes architecturales du produit. En offshore, on trouve chez le prestataire les rôles qui correspondent à la majorité de la masse de travail à réaliser, notamment les rôles de développement, test et déploiement, ainsi que la plupart des mentors (architecte, responsable procédures, expert technique, etc.).

231

Conduite de projets informatiques offshore

Certains rôles se trouvent tout autant en offshore que chez le client, selon les préférences de ce dernier, comme les équipes d’exploitation, qui supervisent et administrent les plates-formes matérielles, et les équipes d’éducation, qui produisent les manuels utilisateur et d’autres documents marketing en plusieurs langues. Certains prestataires offshore sont 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é dans les équipes du prestataire (développement, test, mentors), sous la supervision du chef de projet qui se trouve chez le client. Parfois, certains sujets remontent jusqu’aux mentors du 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 de produit 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 produit partage 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ôle La responsabilité de la réalisation des engagements d’une équipe est partagée de façon indivise entre tous ses membres. Dans le même temps, chacun est comptable et responsable de ses engagements personnels. En appliquant ce principe à une équipe, les différents collaborateurs ne peuvent rejeter une faute sur leurs collègues puisque cela n’a aucune importance et que personne ne cherche de coupable individuel. C’est l’équipe dans son intégralité qui atteint ou manque son objectif. Une livraison défectueuse est de la responsabilité de tous. L’équipe doit donc s’entraider pour atteindre ses objectifs, chacun pouvant agir au-delà de son strict domaine de responsabilité. Si chaque membre de l’équipe a ses responsabilités propres, il n’en communique pas moins avec les autres sur les problèmes rencontrés sur ses livrables personnels, les autres membres aidant tout naturellement les collaborateurs en difficulté en vue de tenir l’objectif accepté. C’est une équipe de pairs. Aucun membre n’en prend la direction, et le succès est considéré comme celui de tous. Le chef de projet chez le client, qui gère plusieurs équipes, joue auprès d’elles un rôle de conseil, parfois d’arbitre, et, si le besoin s’en fait sentir, de manager afin de prendre les décisions qui s’imposent. Il peut ainsi rappeler à l’ordre certaines équipes qui ne respectent pas les règles de fonctionnement, intervenir auprès de certains membres, notamment chez le client, afin qu’ils assurent correctement leurs rôles ou encore démanteler des équipes qui fonctionnent mal.

Donner le pouvoir de décision aux collaborateurs Pour qu’une équipe soit réellement motivée, il faut qu’elle soit capable de s’engager d’elle-même sur ses livrables, dans le cadre précis de ce que l’on attend d’elle. Elle négocie et accepte collégialement après ajustements les objectifs qui lui sont proposés.

232

Chapitre 11 – Gestion des ressources humaines

Il est inutile de lui imposer des objectifs qu’elle sait ne pouvoir atteindre. Cela serait à la fois contre-productif et démotivant et nourrirait un fort sentiment d’injustice. Si l’équipe assume formellement son engagement de livraison, l’atteinte des objectifs devient l’affaire personnelle de chacun de ses membres. Pour que cela fonctionne, tous les membres de l’équipe doivent évidemment faire part de leurs difficultés à atteindre les objectifs personnels dès qu’ils en ont connaissance afin de rechercher ensemble des solutions, à la fois au sein de l’équipe et avec le chef de projet chez le client, qui peut apporter un éclairage utile. La pleine responsabilisation de l’équipe sur ses objectifs n’a de sens que si elle s’accompagne du pouvoir de décider, dans certaines limites. L’équipe doit pouvoir décider de tout ce qui lui semble utile pour atteindre les objectifs. Si les décisions ne concernent que l’é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 cette liberté de décision, dans la mesure du possible. S’il n’est pas d’accord avec certaines décisions, il peut jouer un rôle de conseil. La contrepartie du pouvoir de décision est la transparence de la communication. Le chef de produit veille à ne pas punir les porteurs de mauvaises nouvelles ni à rechercher à tout prix les responsables. Au contraire, il se concentre sur l’analyse des causes et sur les moyens de les éviter dans le futur. Une attitude punitive a pour effet, comme nous l’avons vu à 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 de ses objectifs et peut décider des actions à mener pour les atteindre. Le chef de projet du client joue un rôle de conseil et d’arbitre.

Favoriser les initiatives Le climat de travail doit permettre aux collaborateurs de s’exprimer et de poursuivre certaines de leurs initiatives. En cas de crise ou de dysfonctionnements récurrents, il est probable que certains collaborateurs auront d’excellentes idées pour améliorer l’organisation 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èmes relève directement des managers. Moins en contact avec le quotidien des tâches réalisées que leurs collaborateurs, ils ne perçoivent pas toujours clairement les causes initiales des problèmes qu’ils voient apparaître trop tard, lorsque le mal a pris racine. La plupart des décisions correctives des managers interviennent sur les effets et non sur les causes initiales, qui leur restent inconnues. Il est important de ne pas laisser une trop forte hiérarchie s’installer, où seuls les managers d’un certain niveau seraient entendus. À tous les niveaux, on peut remarquer des dysfonctionnements susceptibles d’être facilement corrigés. Tous les collaborateurs doivent pouvoir 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 sont utilisées chez le prestataire, on peut récompenser les initiatives qui sont effectivement mises en œuvre.

233

Conduite de projets informatiques offshore

De même, les initiatives des managers doivent être appréciées. Il vaut mieux qu’un manager 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 initiatives

Il est important de montrer à chaque collaborateur que l’on en espère non seulement un travail de qualité, 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 centraux Les équipes décrites précédemment gèrent le plus souvent des développements techniques ou fonctionnels. Elles doivent pour cela s’appuyer sur des services centraux de plusieurs natures : • Les architectes techniques et fonctionnels, qui maintiennent une vision globale de l’architecture du produit. • Les chefs de projet, qui synchronisent le travail des équipes afin d’assurer l’harmonie des intégrations et des décisions interéquipes. • Les mentors, qui mettent en place certaines recommandations et règles et en suivent l’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 des personnes à ces rôles, on garantit en outre que certaines des tâches organisationnelles sont 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’identifier les restructurations nécessaires de l’architecture de l’application en vue d’en accroître l’efficacité. Ils peuvent également participer à la mesure de l’impact des changements 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 de contrôle. Le mentor sur le langage de programmation, par exemple, peut à la fois définir comment utiliser le langage (règles de nommage, interdiction d’utiliser certaines mé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 de données (persistance et gestion du modèle de données), aux middlewares et autres outils inté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 à temps partiel, en étant eux-mêmes mentors d’autres sujets ou bien développeurs/testeurs dans une équipe. Le choix de l’organisation des mentorats dépend du poids que l’on souhaite donner à chacun des domaines. Si l’on veut que les procédures et méthodes soient bien appliquées, on peut dédier un mentor à ces tâches, auquel on confiera un pouvoir fort afin de contraindre 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 permanente ou seulement pendant quelques mois, le temps que tous les membres des équipes

234

Chapitre 11 – Gestion des ressources humaines

comprennent l’importance des règles et les appliquent naturellement. Le mentor peut ensuite passer à temps partiel sur ce sujet.

Communication avec le client Un des avantages des petites équipes est qu’elles permettent d’organiser des communications directes avec les personnes impliquées chez le client, ce qui n’est pas l’attitude la plus naturelle en offshore. Le manager du prestataire préfère le plus souvent centraliser la communication avec le client de façon à contrôler les informations échangées. Ce contrô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 informations, les informations ont de grandes chances d’être déformées, édulcorées ou même fausses, non par malveillance, mais par manque d’implication ou simplement par incompré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 en direction des correspondants chez le client, qui détiennent le plus souvent les rôles de chef de produit et de chef de projet (voir figure 11.1). Le client met ainsi en interface directe avec l’équipe en offshore un chef de produit capable de répondre aux questions fonctionnelles (spécifications, éclaircissements, priorités, etc.), un chef de projet qui suit le travail de plusieurs équipes et en assure la synchronisation et quelques mentors qui traitent de questions d’architecture générale, de procédures, de choix technologiques, d’outils de développement, etc. Toutes les questions susceptibles de se poser en offshore peuvent de la sorte trouver réponse. Client

Offshore

Equipe fonctionnelle 1 Chef de produit

Equipe fonctionnelle 2 Responsable de projet

Equipe technique 1 Architecte technique

Mentor 1

Mentor 2

Figure 11.1. Communication directe entre le client et l’offshore

235

Conduite de projets informatiques offshore

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 des personnes responsables. EN RÉSUMÉ Communication directe avec le client

Pour disposer d’une excellente communication entre l’équipe offshore et le client, il convient de mettre en place une communication directe entre les personnes qui rencontrent effectivement les problèmes en offshore et les personnes capables d’y répondre chez le client. La centralisation hiérarchique en offshore induit toujours une part d’opacité et de déformation qui est nuisible à l’efficacité des échanges.

Communications défectueuses Parfois, la personne qui est censée fournir les réponses aux questions de l’équipe en offshore se laisse déborder, ne répond plus aux messages ou le fait trop rapidement, engendrant erreurs et omissions. Quelle qu’en soit la raison, une communication défectueuse empêche l’équipe en offshore de travailler correctement et risque de la conduire à ne pouvoir tenir ses objectifs. Certes, l’équipe tentera tout de même de réaliser ces objectifs, fera preuve d’initiative et cherchera d’elle-même les bonnes réponses, mais, en cas d’échec, il faudra reconnaître que la cause ne lui incombe pas. Ajoutons que le prestataire offshore se trouve toujours en situation difficile lorsqu’un représentant du client ne montre aucun empressement à répondre aux questions, car il ne peut se permettre de critiquer ouvertement 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 des mesures 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 de réponse imposé, une typologie des questions (complément d’informations fonctionnelles ou techniques, cohérence fonctionnelle, etc.) et réponses (compléments aux spécifications, exceptions, question sans objet, etc.). Certains outils de gestion du changement proposent des workflows pour gérer ce type d’échange et permettent de construire des indicateurs efficaces. EN RÉSUMÉ Suivi des communications client/prestataire

Afin d’éviter que des questions importantes restent trop longtemps sans réponses, au risque de retarder les livraisons et de déstabiliser la production, on prendra soin de suivre les échanges entre le 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éral Les questions d’ordre général, qui ne relèvent pas directement de la réalisation du projet informatique, restent souvent cantonnées dans un vide procédural. Ces questions n’ont pas de propriétaire clair, et l’on observe que les personnes capables d’y répondre ne sont pas 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 correctement ou bien on recommande d’acheter un autre serveur pour modifier certaines organisations

236

Chapitre 11 – Gestion des ressources humaines

et les rendre plus efficaces ou encore on souhaite augmenter la bande passante dédiée afin d’assurer des synchronisations plus efficaces. Le problème se complique si le suivi des questions directement liées aux développements est géré par l’outil de gestion du changement, car ces questions générales n’y trouvent 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, faute de 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 nommant un propriétaire pour chacune d’elles. L’annexe de l’ouvrage fournit un modèle d’un tel document 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 pas directement partie du processus de production. De plus, elles ne trouvent pas toujours naturellement un responsable, et les outils de communication qui se concentrent sur la production les couvrent mal. Souvent essentielles à la bonne marche du travail, ces questions doivent être suivies avec attention. Si le suivi n’est pas assuré par les outils en place, il faut créer un document de suivi dé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 place des procédures strictes, car elles seraient exagérément coûteuses par rapport au volume des 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 projet chez 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’a pas trouvé le chef de projet qui convient, dans lequel on aura toute confiance et qui s’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épend alors fortement des capacités du chef de projet en offshore, ainsi que de sa motivation et de sa capacité à communiquer efficacement. Mieux vaut ne démarrer un petit projet en offshore que si l’on dispose d’un chef de projet donnant toute satisfaction.

Les primes La rémunération est souvent directement utilisée par les managers en offshore pour motiver les personnels. L’efficacité de ces primes est pourtant loin d’être démontrée,

237

Conduite de projets informatiques offshore

surtout pour les développeurs et plus généralement les collaborateurs techniques. Ces derniers 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’être dé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 des effets 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 toujours l’équité.

Primes démotivantes La plupart des primes octroyées dans les entreprises sont des primes de motivation sur des objectifs personnels. Bien souvent, afin de ne pas organiser des entretiens trop rapprochés pour analyser la réalisation des objectifs, ces primes sont attribuées tous les six mois ou, pire, annuellement. Cela signifie que les objectifs sont le plus souvent définis six mois ou un an à l’avance. Avec une telle anticipation, les objectifs ne correspondent bien 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 la majorité des cas, cette livraison est perturbée par d’autres événements, qui en retardent la sortie, ou certaines fonctionnalités, qui sont abandonnées ou remises à plus tard. Le retard n’est donc pas nécessairement le signe d’un travail médiocre. De plus, la prime ne prend pas en compte la bonne volonté ni l’efficacité du collaborateur dans ces situations mouvantes. 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. Comme elle 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é de réaliser dans le même temps de nombreuses autres tâches considérées comme plus urgentes et qu’elle les ait assurées avec célérité et qualité, la suppression de la prime apparaît comme manifestement injuste. Un effet pervers se déclenche, et la prochaine fois qu’on lui demandera de réaliser des tâches urgentes, elle préférera assurer d’abord celles qui 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 la personnalité d’un collaborateur. Par exemple, si l’on s’aperçoit qu’un collaborateur est plutô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 peut faire 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’est au management de s’adapter à la personnalité de ses employés en définissant des postes où ils donneront le meilleur d’eux-mêmes. L’expérience prouve que ce type de prime mène à de longues périodes de troubles.

238

Chapitre 11 – Gestion des ressources humaines

EN RÉSUMÉ Prime de démotivation

Les populations techniques sont souvent motivées par leur travail et font de leur mieux. Une prime mal conçue, qui ne serait pas attribuée à certains collaborateurs alors qu’ils sont en droit d’estimer la mériter, entraîne immanquablement une forte démotivation, dont la durée dépend du caractère de chacun. Les primes sont rarement des sources de motivation en elles-mêmes pour les collaborateurs techniques, qui trouvent les sources de leur motivation dans l’intérêt pour leur travail ainsi que dans la reconnaissance de leurs pairs.

Primes collectives On peut définir des primes collectives sur la réalisation des objectifs des itérations. Une somme est alors à répartir entre les membres de l’équipe selon une règle bien définie et acceptée comme juste par tous, sachant que certaines personnes travaillent dans plusieurs é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 le plus souvent de trois à six semaines, il y a de grandes chances que les objectifs demeurent inchangés. Si des priorités supérieures doivent prendre la main, le management en tient compte 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 est perçu comme la sanction d’un mauvais travail et que cela entraîne des répercussions négatives si c’est injustifié. À l’inverse, accorder une pleine prime à une équipe qui n’a pas l’impression de la mériter a des effets négatifs sur sa motivation. Cela lui donne l’impression que l’on place la barre moins 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 pas atteint et que le travail dans l’équipe n’a pas été correct, tout particulièrement si des membres de l’équipe ont géré leurs objectifs de façon personnelle en perdant l’esprit d’équipe et en ignorant les problèmes qu’ont rencontrés les autres membres. La nonattribution de la prime joue alors un rôle de rappel à l’ordre. Lorsqu’une équipe fonctionne correctement, elle doit toucher ces primes collectives régulièrement. Cela s’apparente à une augmentation de salaire, si ce n’est que des dysfonctionnements 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 du client.

Primes pour travail exceptionnel Une autre façon d’accorder des primes, qui semble inique au premier abord mais est finalement assez juste, consiste à faire choisir par un collège de managers leurs bénéficiaires pour 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éfi nis à l’avance et qu’ils s’appuient sur une appréciation qualitative du travail, ce que l’on cherche généralement à éviter. Cette prime est aussi intrinsèquement juste puisqu’elle juge de la capacité de certains membres des équipes à réagir à des situations de crise, précisément imprévisibles.

239

Conduite de projets informatiques offshore

Pour éviter l’effet de surprise associé à cette prime, on peut insérer dans les séances de débriefing des objectifs d’itération des nominations motivées pour cette prime, chaque manager pouvant proposer une ou plusieurs personnes pour la recevoir. Les nominés, qui doivent être peu nombreux, peuvent être des individus ou des équipes. Un collège de managers 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. Par exemple, une équipe propose une citation en expliquant qu’une personne a travaillé jusqu’à 21 heures durant toute une semaine. Certains managers s’insurgent en expliquant que 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 pas d’effets pervers. De plus, elle permet de démontrer aux informaticiens, qui se plaignent volontiers de ne pas voir leur travail reconnu, que le management sait apprécier leur valeur. Il n’y a généralement pas de déception à se voir refuser une prime puisqu’elle n’est pas due par avance. Enfin, elle montre l’exemple à ceux qui hésitent à faire des efforts et qui voient leurs collègues récompensés. Cette prime concerne une à deux personnes sur vingt chaque mois, et son montant individuel ne dépasse guère 200 à 500 dollars. Pour bien fonctionner, elle doit conserver son caractère exceptionnel. La plupart des itérations n’occasionnent pas de prime, et seules les 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énements se sont produits, sont généralement bien accueillies et génèrent une motivation naturelle.

Les malus En offshore, il est courant d’attribuer des malus. Par exemple, on peut indiquer qu’à partir du mois suivant, le salaire d’un collaborateur sera réduit si son niveau d’anglais n’atteint pas 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 montre pas toutes les qualités requises. On lui demande alors de se mettre à niveau rapidement en 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 tient pas 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 importants pour assurer le succès d’un projet en offshore. Avec une bonne vision de ce qui doit être réalisé et une bonne répartition des rôles et des responsabilités, on parvient à obtenir une productivité honorable et une capacité naturelle à s’ajuster aux changements.

240

Chapitre 11 – Gestion des ressources humaines

Certains estiment que le cadre méthodologique suffit à assurer le contrôle et la productivité d’un projet et placent la méthode avant la gestion des hommes. Chaque nouveau collaborateur doit embrasser la méthode en place, et l’on s’imagine qu’il s’épanouira dans ce cadre. À l’opposé de cette approche, l’expérience recommande de miser avant tout sur les hommes et d’adapter l’organisation, si certains profils le méritent, afin de permettre aux talents exceptionnels de s’exprimer pleinement. La motivation des équipes est le meilleur gage de productivité. Cette motivation va de pair avec une relation de confiance mutuelle, qu’il faut parfois un peu forcer au commencement 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 ses accomplissements 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 la vision et la rigueur nécessaires aux projets, en complément d’une bonne gestion des ressources humaines.

241

Chapitre 12

Processus et méthode

La gestion d’une équipe informatique à distance demande bien évidemment plus de rigueur que celle d’une équipe locale. Pour que cette approche puisse être appliquée simplement, il faut l’accompagner d’un outillage approprié pour organiser, contraindre et suivre le travail réalisé à distance. La mise en place d’un processus de développement structuré est souvent intimidante. On se 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’est pas à la portée de tous. Les guides qui accompagnent ces méthodologies ne sont réellement 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 elles prévoient tous les cas de figure et sont d’une lourdeur excessive. Les méthodologies formelles sont assez nombreuses. La plupart des grands éditeurs de logiciels ont créé la leur, et certains l’incluent dans leurs offres de produits ou la vendent en la mettant plus ou moins en avant. Les deux approches méthodologiques qui se détachent assez nettement sont le RUP (Rational Unified Process) d’IBM (www-306.ibm.com/ software/awdtools/rup/) et XP (eXtreme Programming) (www.extremeprogramming.org/). Microsoft propose avec MSF (Microsoft Solutions Framework) son propre cadre de travail, qui complète sur de nombreux sujets les approches du RUP ou de XP en insistant davantage sur la gestion des hommes et les flux de travail que sur la structuration des processus et documents (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 appliquent 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 la qualité des hommes, leurs interactions, leur management et leur motivation.

243

Conduite de projets informatiques offshore

Plus le projet est important, plus la méthodologie est indispensable, car il faut harmoniser 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édures industrielles prennent un poids exagérément important par rapport aux tâches de production, et l’on privilégie des procédures légères. Les qualités humaines font toute la différence dans ces projets légers. Les méthodes essaient de prendre en compte toutes les étapes d’un projet, depuis les premiers moments, quand le projet prend forme, jusqu’aux évolutions et corrections du produit final en exploitation et à la préparation du projet suivant. La mise en place d’une méthodologie est souvent dépersonnalisante. Elle vise à structurer les échanges et la traçabilité et à centraliser les responsabilités. La plupart des outils mé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écouvrent leurs tâches dans ces outils méthodologiques, assorties de dates de livraison, ont l’impression de n’être que des exécutants, qui ne décident de rien. Il est donc important de respecter les motivations, engagements, initiatives personnelles et responsabilités que 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 est important de ne demander aux collaborateurs d’engager leur pleine responsabilité que s’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 de tâches sur lesquelles il ne s’est pas engagé personnellement ou pour lesquelles il n’a pas de possibilité d’agir se désintéresse de ses objectifs. Si certains outils méthodologiques peuvent mener à des effets négatifs sur la gestion des ressources humaines, ces mêmes outils utilisés correctement peuvent aider à structurer l’organisation des workflows et l’utilisation du référentiel tout en conservant les motivations et responsabilités des collaborateurs. Procédures et outils méthodologiques n’ont de sens que pour accompagner les collaborateurs dans la structuration de leur travail et dans les échanges d’informations. On doit donc 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 les collaborateurs à des rôles d’exécutants. La motivation et l’engagement des collaborateurs sont essentiels pour garantir le succès et la qualité des réalisations. Il faut donc veiller à conserver ces valeurs 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ôle assure un certain nombre de tâches ciblées. Le nom des rôles est souvent trompeur, car certains d’entre eux correspondent à des postes (par exemple, développeur), tandis que d’autres se rapprochent d’une activité (par exemple, test designer), qui doit être assurée. Les rôles peuvent être très précis, comme test reviewer, même si cela ne correspond pas à un poste à temps plein.

244

Chapitre 12 – Processus et méthode

Les collaborateurs qui ont peu d’expérience des descriptions des rôles dans les méthodologies 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 et le test designer que le testeur. C’est un piège qu’il faut éviter dès le commencement. Les rôles présentés dans les méthodes ne correspondent pas nécessairement à un poste. Il s’agit plutôt de fonctions consistant à effectuer certaines tâches et à prendre la responsabilité de certains livrables. Par ailleurs, les méthodologies n’expliquent pas comment déterminer l’attribution des rôles aux postes ni si certains rôles peuvent être cumulés par une même personne sans être dénaturés. Le chapitre 11 montre comment construire des équipes efficaces. Sur les postes identifié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 erreurs des débuts de l’informatique, quand l’analyste concevait le programme et le pupitreur entrait le code. Il est peu motivant pour un développeur de recevoir un modèle de design entièrement conçu par une personne qui ne codera pas et de se contenter de réaliser un code, bien souvent en critiquant le travail fait en amont. De même, l’analyste qui conçoit ses modèles d’analyse sans coder une seule fonction ne peut travailler ses modèles avec le 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 des collaborateurs s’associent à des rôles choisis pour leur aspect valorisant et intéressant correspondant plus ou moins à leur rôle courant. Les rôles des méthodologies ne sont pas des postes, et un poste 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 transparents les workflows, les livraisons et la progression du projet. Ce chapitre ne prétend pas aider à choisir la méthodologie ou les outils qui doivent être utilisés pour travailler avec des équipes en offshore. Il propose simplement un tour d’horizon des fonctionnalités les plus utiles pour les projets en offshore parmi celles offertes par la plupart de ces outils de développement. En tout premier lieu, il importe de choisir une méthodologie qui utilise une approche itérative et qui est correctement accompagnée de l’outillage permettant d’en appliquer, voire d’en forcer les principes essentiels.

La méthode La méthode peut se présenter sous la forme d’un produit packagé et versionné, pour les méthodologies qui sont gérées comme des produits, tel le RUP, ou sous forme d’archive compressée à télécharger sur Internet. Qu’elle soit livrée sur un CD ou disponible sur le Web, elle doit être adaptée aux besoins du projet.

245

Conduite de projets informatiques offshore

La solution la plus simple pour installer la méthode consiste à créer un intranet à partir du 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 que celles que l’on rencontre dans un projet réel. Certains flux, comités ou documents peuvent n’avoir qu’une utilité réduite dans le cadre d’un projet. Il faut donc adapter le cadre méthodologique afin de ne déployer que les éléments utiles, tout en respectant les principes de base. La méthodologie elle-même doit être mise en place de façon itérative et permettre de revenir sur des éléments dont la définition ne serait pas pleinement efficace et que les collaborateurs voudraient améliorer.

Le référentiel Le 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 bien des textes, contenant des informations générales sur le projet, que des documents méthodologiques, des codes source, des scripts, des plans de test, etc. On peut y placer les différents jeux de données de test, ainsi que tous les outils qui permettent de reconstituer 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. On peut ainsi retourner à des versions antérieures et savoir qui a effectué des modifications et quand. C’est tout particulièrement sur la gestion du code source que l’on trouve les mécanismes les plus évolués. Le référentiel peut être lié aux autres outils qui sont mentionnés dans la suite du chapitre et qui permettent de gérer des informations sur le changement, maintenant ainsi non seulement les différentes versions des éléments mais les changements opérés sur ceux-ci. De cette façon, l’utilisateur extrait un code source du référentiel pour effectuer un ou des changements (correction d’anomalie, évolution fonctionnelle, nouvelle fonctionnalité, etc.) qui sont demandés dans l’outil de gestion du changement et 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 modifications 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 sont situées dans des parties différentes du code. Il peut tout aussi bien demander au programmeur de résoudre les recouvrements de modifications. Pour créer une version d’un produit, on identifie des baselines, qui sont un ensemble d’é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’interface 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 la nouvelle 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

246

Chapitre 12 – Processus et méthode

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 un chemin 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, par exemple. Les anomalies seront appliquées au stream de livraison jusqu’à obtenir une stabilité suffisante. Par ailleurs, sur le stream de développement, de nouvelles fonctionnalités sont ajoutées, qui n’apparaissent pas dans le stream de livraison. Les anomalies corrigées dans le stream de livraison doivent être également corrigées dans le stream de développement. La figure 12.1 illustre un stream créé pour validation, sur lequel on doit corriger les anomalies 1 et 3. Les nouveaux développements et les autres corrections d’anomalies ne sont pas réalisés sur le stream de développement, lequel est conservé aussi stable que possible de façon à pouvoir en établir le niveau de qualité. S’il devait continuellement être en évolution, on ne pourrait estimer son niveau de qualité.

Figure 12.1. Gestion des streams

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 ensemble important de fonctionnalités, voire s’accompagne de couches techniques retravaillées.

247

Conduite de projets informatiques offshore

• Version spécifique : ajouts fonctionnels pour un client spécifique donnant lieu à une dé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 la version en production. Cet exemple montre qu’on peut entreprendre quatre séries de modifications en parallèle sur les mêmes codes source, avec des objectifs de livraison client qui varient entre quelques heures (Hot Fix) et plusieurs mois, voire plus d’un an, dans le cas du travail sur une nouvelle version majeure. Le référentiel sait gérer ces streams différents et, dans une certaine mesure, assister à la fusion des actions d’un stream sur l’autre, comme reporter la 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éplication totale ou partielle des éléments. Lorsqu’on travaille avec un prestataire distant, on peut répliquer, en temps réel ou périodiquement, toutes les informations relatives à leurs développements. Tous les éléments placés dans le référentiel se retrouvent immédiatement chez le client et réciproquement, tandis que les éléments qui ne sont pas synchronisés restent locaux. Le référentiel est au cœur de l’outillage méthodologique. C’est l’outil sur lequel tous les autres s’appuient. Il est donc à choisir avec beaucoup de soins.

Gestion du changement L’outil de suivi du changement  on sépare parfois la gestion des anomalies et cell e des évolutions ou nouvelles fonctionnalités  assure plusieurs rôles, notamment les suivants : • Il permet de suivre précisément toutes les détections d’anomalies ou demandes de changement 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 le défaut signalé est bien une anomalie et si elle n’est pas déjà répertoriée. Une fois qualifiée, l’anomalie suit un chemin qui permet de lui associer les informations nécessaires 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 des flux très différents selon la nature de la requête. Par exemple, une anomalie technique suit un chemin différent d’une demande d’évolution fonctionnelle. Ces flux doivent être configurés par le client pour s’adapter au mieux à son organisation et à la répartition des rôles dans la société. Cet outil est généralement fortement couplé au référentiel, car toutes les demandes de changement donneront probablement lieu à des interventions sur les codes source. On souhaitera suivre ces modifications avec les versionnements des éléments dans le référentiel.

248

Chapitre 12 – Processus et méthode

L’outil de gestion du changement est indispensable lorsqu’on travaille en offshore. Il permet notamment d’éviter que le client et le prestataire s’attendent mutuellement et que des requêtes de changement se perdent. Il évite aussi les erreurs de communication sur les niveaux de priorité des requêtes. Les petits projets ne nécessitent pas toujours de tels outils, parfois lourds et coûteux. Il est en ce cas nécessaire de les remplacer par des procédures strictement appliquées afin de communiquer 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 gestion du changement. Ils garantissent un suivi rigoureux de la production et de toutes les requêtes échangées entre 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 changement fournissent un grand nombre de mesures des développements en cours. 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 anomalies 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

Gestion des exigences Les outils de gestion des exigences permettent de suivre toutes les exigences fonctionnelles 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ée de travail pour la réaliser, le risque lié à cette exigence ou tout autre élément que l’on souhaite utiliser pour les qualifier.

249

Conduite de projets informatiques offshore

Ces attributs sont utilisés pour déterminer le contenu de chaque itération. Les décisions sont prises non plus en lisant le contenu de chaque exigence mais en travaillant directement sur ses attributs. Lors des premières itérations, on choisit le plus souvent d’éliminer toutes les incertitudes techniques et les risques les plus forts de façon à rendre les itérations suivantes 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 complexes et à faible risque. Les fonctionnalités portant une part de risques sont reportées à une version ultérieure, si c’est possible. Les outils proposant une gestion des exigences maintiennent le plus souvent un lien entre l’exigence et tous les autres éléments qui en découlent, permettant de garder une cartographie des réalisations. Certains outils permettent aussi de gérer les workflows de modification des exigences. Les exigences peuvent aussi être gérées sous forme de tableau de type Excel. On perd alors les mécanismes de liens entre une exigence et les éléments dérivés, mais ce n’est pas 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 les priorités selon lesquelles on construit un produit. Les attributs permettent, par exemple, d’éliminer les risques et de réaliser les tâches complexes le plus tôt possible dans le projet de façon à pouvoir envisager d’autres approches tant qu’il en est temps. Les engagements sur les itérations deviennent de plus en plus fiables au fur et à mesure de la progression du projet puisque les sources d’incertitude sont progressivement éliminées.

La gestion des exigences est une tâche continue. Les attributs que l’on pose au début d’un projet changent au fur et à mesure des réalisations. Il est possible, par exemple, que toute une série de fonctionnalités présentent un fort risque dû à une incertitude technique commune. Une fois cette incertitude levée, le risque doit être mis à jour pour toutes les fonctionnalités qui en dépendent. À l’inverse, de nouvelles difficultés ou de nouveaux risques 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’utilisateur la réclame explicitement. La gestion des exigences est ainsi un document vivant, qui doit être mis à jour régulièrement, au moins à chaque itération, puisque c’est une des sources 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, document, fichier, etc.) et sa circulation entre les personnes qui le traitent et décident de le faire changer d’état. La plupart des outils de gestion du changement et des exigences incluent 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 (anomalies et évolutions) est primordiale. Ces informations sont échangées en permanence entre les sites, et certaines informations peuvent être critiques. Si un seul workflow doit être défini sur un projet, ce doit être celui-ci.

250

Chapitre 12 – Processus et méthode

Les workflows formalisés permettent de gérer des indicateurs de suivi et de mieux comprendre les dysfonctionnements éventuels. Ils prennent une grande importance lors des développements en offshore en permettant de contrôler finement certains flux chez le 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 dans les 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 certaines actions pour attribuer un nouvel état au livrable.

Gestion des tests La gestion des tests est aussi un élément important de l’outillage méthodologique. Le tableau 12.2 recense les fonctions d’un certain nombre d’outils de test. 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.

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 conserver l’é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 pas utiliser 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 source du référentiel. On est alors certain de disposer de l’exacte représentation du code source placé dans le référentiel et qu’aucun autre élément n’est nécessaire à la création de l’exécutable. On teste de fait aussi les procédures d’extraction des sources, de compilation et de déploiement.

251

Conduite de projets informatiques offshore

Gestion de la documentation Certaines suites méthodologiques disposent d’outils de construction des dossiers de documentation du projet à partir d’une grande quantité d’informations. Ces outils sont peu utiles dans le cours des réalisations des projets informatiques. Ils sont 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 parviennent pas à les mettre en place efficacement. Elles apparaissent comme un mur infranchissable et sont de ce fait reléguées au rang des créations intellectuelles qui ne sont pas ré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éthodologies sont 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’une mé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 de mener 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 de nombreuses 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’installe pour une nouvelle équipe, comme une équipe que l’on crée en offshore, on peut choisir de l’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 en spécialisant les rôles et en leur retirant certaines responsabilités. Les collaborateurs se focalisent tout naturellement sur ce qu’ils vont perdre plutôt que sur les avantages de la nouvelle organisation. Comme l’organisation existante est le résultat d’années d’ajustements 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 en offshore de celui sur les équipes locales. On peut traiter les deux projets en parallèle et de façon indépendante, si possible décalée dans le temps. Il est beaucoup plus facile de mettre en place une méthodologie industrielle sur un projet distant, où l’on conçoit immédiatement l’utilité des procédures à mettre en œuvre, que sur une équipe locale qui fonctionne raisonnablement bien et qui sera certainement réticente à changer de mode de travail.

252

Chapitre 12 – Processus et méthode

Se concentrer sur l’essentiel Un autre piège classique lorsqu’on déploie une méthodologie est de vouloir la mettre intégralement en œuvre. Les méthodologies industrielles cherchent à couvrir toutes les situations 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 recommandations sont prévues dans la méthodologie et décider si l’on doit couvrir tels et tels points ou 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 pas toujours utiles et qui peuvent être difficiles à rédiger. Par exemple, un des documents initiaux prévoit de lister les ressources allouées au projet alors que le budget peut ne pas être si clair. Les managers ont peut-être prévu certaines réserves pour couvrir des retards et des dysfonctionnements, par exemple, et ne souhaitent pas en faire état. La personne qui chercherait à tout prix à obtenir ces chiffres se heurterait à un refus du management. Les responsables financiers pourraient alors s’élever contre la méthode, la jugeant trop intrusive. Il convient donc de comprendre les éléments essentiels de la méthodologie, d’en respecter 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 le cadre du projet. Il peut aussi y avoir des informations impossibles à obtenir, ne serait-ce que le budget réel du projet. Ce sont les objectifs forts, centrés sur les éléments structurants de la méthodologie et auxquels 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. Les autres éléments doivent être considérés comme optionnels et d’une priorité faible. Ils ne seront mis en 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 absolument respecter 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, si possible 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’un build permettant de valider la réalité de la progression du projet.

Favoriser la motivation La gestion des ressources humaines et ses principes motivants visant productivité et qualité ne doivent pas être oubliés lors de la mise en place des procédures. Il est commun de 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’une méthodologie réduit les responsabilités et dépersonnalise les rôles. Plus les hommes

253

Conduite de projets informatiques offshore

reçoivent de directives contraignantes, moins ils se sentent responsables de leur production, et plus la productivité baisse. Il faut veiller à ce que la motivation de chacun ne soit pas atteinte par la mise en place d’une méthodologie industrielle. Il faut certes faire entrer chaque collaborateur dans un rôle structuré avec les responsabilités qui y sont attachées, mais les procédures doivent avant tout permettre aux hommes de travailler plus efficacement et d’éviter les malentendus et les 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 les hommes. Gérer les équipes de développement comme des exécutants qui reçoivent des ordres de développement selon un outil de workflow, sans engagement personnel sur les réalisations et sans créativité, est dévalorisant et ne peut qu’entraîner une réduction de la 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 univoque l’é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 au plus près de chacun des livrables dont ils sont responsables afin que le succès ou l’échec de chaque livraison 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 pour s’adapter à la façon de travailler que l’on souhaite mettre en place et aux procédures que l’on veut utiliser. Il ne s’agit pas de considérer que ces outils doivent imposer aux collaborateurs leur façon de travailler. Par exemple, le principe itératif est rarement directement intégré dans les outils. De nombreux workflows sont organisés autour des itérations dans la méthode, comme la construction du contenu des développements de chaque itération qui découle d’une analyse globale du réalisé, ainsi que de l’expérience et des tâches restant à réaliser. Si l’on trouve effectivement des outils pour gérer ces informations, l’organisation en itération doit être mise en place par ceux qui s’occupent de la méthodologie et qui définiront les guidelines 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 proposent les méthodologies est déroutant de prime abord. Il est recommandé de ne mettre en place que 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’on veut faire respecter. Adopter une méthodologie ne signifie pas en accepter tous les aspects. La plupart des fonctionnalités qu’elle propose sont modifiables sans pour autant distordre la méthodologie. Par exemple, RUP recommande de mettre en place un comité pour gérer les demandes de changement. Ce comité (change control board) est censé réunir toutes les personnes concernées par les changements. Cette recommandation est généralement très utile puisqu’elle

254

Chapitre 12 – Processus et méthode

permet que toutes les parties soient informées et s’expriment. Elle suppose cependant une organisation lourde, puisque les personnes concernées sont nombreuses et que les réunions ont toute chance de s’éterniser. Il est souvent préférable de nommer une personne pour gérer les modifications fonctionnelles et une autre pour les modifications techniques. Selon la nature des changements, ces responsables s’organisent et lancent les consultations qui conviennent auprès des personnes réellement concernées afin de les associer aux évolutions. Seules les décisions majeures, 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 trouve toutefois 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 la gestion 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 mis en œ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 chef de projet peut faire l’erreur de se concentrer sur la gestion du planning, au détriment de tous les autres aspects. Il croit pouvoir piloter toutes les opérations en offshore à travers celui-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 principes méthodologiques essentiels. Le tableau 12.3 indique plusieurs niveaux de planification permettant de gérer le développement du projet. Tableau 12.3. Niveaux de planification Planification

Fonction

Utilisation

Release plan

Distribue les fonctions sur les différentes livraisons 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éveloppement

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.

255

Conduite de projets informatiques offshore

Tableau 12.3. Niveaux de planification(suite) 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éveloppements.

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.

Tous ces plannings sont revus et corrigés après chaque itération pour tenir compte de l’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 en cours 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 le dé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 planning détaillé sont pris en compte dans le plan des itérations afi n de parvenir à plus de précision dans les plannings suivants.

Gestion des corrections et des nouveaux développements Les équipes de développement doivent réaliser de nouveaux développements (nouvelles fonctionnalités, corrections majeures planifiées ou évolutions majeures). Elles sont également sollicitées pour des corrections d’anomalies, dont certaines doivent être prises en compte au plus tôt. Ces demandes de correction doivent être gérées convenablement pour ne pas perturber les engagements en cours des équipes. De nombreux ouvrages recommandent de créer une équipe dédiée aux corrections d’anomalies afin de séparer les développeurs qui travaillent sur celles-ci et ceux qui travaillent sur les nouvelles fonctionnalités. L’avantage majeur de cette approche est d’isoler l’équipe travaillant sur les nouvelles réalisations et de garantir ainsi la progression stable et planifiée du projet, avec des équipes qui ne seront pas perturbées par les demandes urgentes de correction, qui interrompent les tâches en cours et retardent les livraisons. Son autre effet bénéfique est de limiter et contrôler mécaniquement la quantité de travail que l’on peut investir dans les corrections d’anomalies en fonction du nombre de personnes qui y sont dédiées. On évite ainsi que les développeurs décident des priorités entre les tâches de développement planifiées et celles relatives à des corrections urgentes.

256

Chapitre 12 – Processus et méthode

On peut opposer trois inconvénients majeurs à cette approche : • Difficulté à garder motivés les développeurs qui passent leur temps à corriger des anomalies. • Difficulté à convaincre les développeurs qui travaillent sur les nouveaux développements à viser la meilleure qualité, alors qu’ils savent qu’ils ne corrigeront pas les anomalies qu’ils ont créées. • Difficultés engendrées par les multiples fusions de codes source écrits par des développeurs différents pour gérer les corrections d’anomalies et les nouveaux développements. À l’opposé, l’avantage majeur d’une équipe dédiée aux corrections d’anomalies est l’assurance de la bonne maintenabilité des codes source puisqu’ils sont pris en main par d’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éveloppements est d’allouer une proportion du temps d’une équipe aux corrections en interdisant que les développeurs ne dépassent cette allocation. Le pourcentage de temps alloué aux corrections est déterminé pour chaque équipe et pour chaque itération selon le niveau d’effort que l’on souhaite fournir sur ces tâches. En mode de maintenance d’une application qui continue à évoluer normalement, on peut allouer 20 % du temps d’une équipe à corriger les anomalies et les 80 % restants aux nouvelles 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 corrections. Elle est alors la plus efficace pour déterminer la cause de l’anomalie et ne pas la reproduire sur les nouveaux développements. • On peut choisir le moment qui convient pour réaliser ces corrections de façon à ne pas avoir à 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 nouveaux dé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 de construire certains indicateurs. EN RÉSUMÉ Corrections et nouveaux développements

Pour pouvoir planifier les nouveaux développements et la quantité d’anomalies qui peuvent être corrigées, il est important d’isoler le temps réservé aux corrections d’anomalies de celui dédié aux nouveaux 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’occupant que des nouvelles réalisations. La seconde solution consiste à allouer à chaque équipe de développement une répartition du temps à passer aux corrections des anomalies et aux nouveaux développements et à s’assurer que ces proportions sont respectées.

257

Conduite de projets informatiques offshore

Release, Service Pack, patch et Hot Fix Il 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 recetter et de le stabiliser, et plus il faut de temps pour le livrer. En revanche, une correction simple, bien circonscrite et apparemment sans danger, peut faire l’objet d’une correction rapide, 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 du besoin 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 changent. 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 technologiquement proches des versions majeures. Les différences 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 quelques 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

258

Chapitre 12 – Processus et méthode

Tableau 12.4. Livraisons et risques(suite) Livrable Hot Fix

Besoin

Préparation

Description

Livrer une correction bien isolée pour corriger une anomalie critique 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 pleinement 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 effectuée sur le site de production.

Risque Élevé

La méthodologie doit prévoir les différents types de release et avertir les participants au projet des risques pris sur les urgences fortes et les coûts relatifs souvent élevés, qui peuvent 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, multipliant d’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 recours aux 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 que l’urgence des requêtes soit respectée comme il convient, en tenant compte des risques et des coûts de chaque action. Les différents streams doivent pouvoir être créés et gérés par le référentiel pour limiter les risques et apporter la flexibilité et la réactivité souhaitées.

Le release plan Le release plan est assez proche de la gestion des exigences. On peut le représenter sous forme de tableau listant toutes les features que l’on souhaite réaliser, avec les dates prévues de livraison aux utilisateurs, ou sous forme de planning, afin de mieux juger de l’étalement dans le temps des livraisons. Le tableau de release plan donné en annexe permet de suivre toutes les exigences et de les attribuer à chaque release. On y trouve également une estimation de la charge de chaque fonctionnalité permettant d’estimer globalement le nombre de jours de codage alloué à chaque release, qui sera à comparer au nombre de jours disponibles que l’on anticipe de façon à estimer grossièrement la faisabilité du plan. On s’entendra sur ce que représente cette charge. Le plus simple est de mesurer la charge de codage et de définir des règles permettant d’y ajouter une charge d’analyse (architecture), de test ou d’autres interventions de mentors, ces charges dépendant de la nature de l’intervention (évolution ou 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 projet mais sont parfois créés au moment où l’on en a besoin. Il est important de suivre la disponibilité des spécifications détaillées pour s’assurer que les équipes sont capables de commencer à 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ées sont toujours valides, en tenant compte de l’expérience acquise au cours des itérations et des changements de priorité éventuels des clients.

259

Conduite de projets informatiques offshore

Plan de développement et charge des itérations Le plan de développement consiste à distribuer le release plan par itération. On ne cherche toujours pas à donner le détail des tâches ni à définir les personnes qui travailleront sur chacune d’elles, mais on se concentre sur la charge de travail. On introduit pour cela certaines dépendances des grands blocs de développement. Par exemple, s’il faut que certaines fonctionnalités techniques soient disponibles pour que les développeurs fonctionnels commencent à les utiliser, on s’arrange pour s’assurer de leurs ré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 pour de 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éveloppements dans le projet æ les premières itérations n’auront probablement pas de charge affecté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 des itérations afin d’affiner au mieux les plans d’itération. Le client peut aussi utiliser des règles pour ajouter des quantités de travail et représenter les risques. Par exemple, on attribue 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 de vérifier plus finement que dans le release plan le réalisme du planning. Ce document fournit 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 plannings, 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écisions et événements sur les livraisons. On peut prendre des décisions en collaboration avec les équipes distantes en restant concentré sur l’itération en cours. On ne perd donc pas la vision globale du plan des livraisons, qui représente l’engagement envers les utilisateurs. Le processus itératif est bien appliqué et se gère assez naturellement par la structuration des plannings.

Figure 12.2. Les planifications

260

Chapitre 12 – Processus et méthode

Le planning détaillé de l’itération Le 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étaillent les attributions de chaque personne. Ce planning est dans la directe continuation du planning de l’itération précédente. La gestion du planning d’une équipe en offshore est particulièrement importante. Moyen essentiel 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 du projet, chaque fonctionnalité étant regroupée dans la phase. Dans la réalité, mieux vaut organiser 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 phase d’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ées sont bien souvent fournies juste avant le développement de certaines tâches prévues tard dans le cours du développement. • Il est préférable de confier aux responsables d’équipe la définition du détail du planning des tâches dont ils sont responsables. Chacun d’eux maîtrise le planning complet de son équipe en tenant éventuellement compte de points de synchronisation avec les autres é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 au tableau 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 exemple, il est pratique de nommer les tâches relatives à une requête de changement par un libellé qui commence par l’identifiant de celui-ci.

Définir les chefs d’équipe responsables de leurs plannings

Chaque responsable d’équipe construit son planning détaillé, qui correspond à ses engagements sur l’itération. Ce planning est construit conjointement 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épendances 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.

261

Conduite de projets informatiques offshore

Tableau 12.5. Règles de construction du planning(suite) 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 corrections 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.

Le modèle de planning fourni en annexe reprend ces recommandations. Tous les aspects du modèle ne sont pas présentés ici, notamment la gestion des priorités des tâches, les synchronisations entre itérations, etc. Comme expliqué précédemment, les engagements des équipes et des hommes concernent avant tout des réalisations livrables, recettables et utilisables, plutôt que des livrables personnels représentant des états intermédiaires. Le planning doit de même s’organiser autour des livrables d’équipe, dont on suit la date de livraison. On laisse ainsi une grande latitude aux équipes pour organiser leurs livrables intermédiaires. Il est recommandé de mettre à jour les pourcentages d’avancement du projet régulièrement au cours de l’itération, par exemple toutes les semaines. Cela permet de mieux comprendre le détail des causes de retard dans une itération. Le chef de projet estime les pourcentages d’avancement de chaque fonctionnalité. Le planning doit être perçu non comme un outil permettant d’identifier le coupable d’un retard mais comme une aide pour comprendre les problèmes qui se posent afin d’éviter qu’ils se reproduisent. Les causes les plus classiques de retard sont les erreurs d’estimation de charge, les retards de livraison d’autres équipes dont on dépend, des directives du client demandant de 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’une attention soutenue du chef de projet du client.

262

Chapitre 12 – Processus et méthode

Analyse de l’itération terminée Le processus itératif révèle toute sa puissance si l’on prend soin de réaliser des iteration assessments (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 recommandé d’utiliser un document par équipe. Le chef de projet du client assemble les iteration assessments provenant des équipes et en contrôle la cohérence. Par exemple, si une équipe est en retard du fait d’une livraison tardive d’une autre équipe, cet événement doit se retrouver dans l’assessment de l’équipe en faute. Certaines raisons peuvent expliquer des retards, sur lesquelles on peut intervenir efficacement. Par exemple, si le client livre les spécifications tardivement, il est certainement possible 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 dysfonctionnements de l’itération. Selon les résultats constatés, le chef de projet peut reconsidérer tous les éléments du projet : • Les procédures ont-elles été mises en défaut ? Certaines procédures sont-elles manquantes 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 tardives aux questions ? Y a-t-il eu des changements de priorité au cours de l’itération ? Cela aurait-il pu être évité ? • Le plan de développement doit-il être revu ? Le plan de charge doit-il être ajusté ? Les performances constatées doivent-elles influencer les plannings ? Quelle est la profondeur des ajustements ? Le release plan peut-il être maintenu ? Y a-t-il des impacts sur les coûts ? • Le matériel et l’environnement de travail sont-ils adaptés ? Les moyens matériels sontils la cause de certains problèmes ? • A-t-on bien pris en compte les enseignements de cette itération pour définir l’itération suivante (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ère de la réalité et de la qualité des livrables recettables. Les estimations d’un chef de projet sur l’avancement de son travail sont hautement douteuses. Par exemple, un chef de projet peu expérimenté aura beaucoup de mal à savoir s’il a atteint 80 % de progression. Dans de nombreux cas, on s’aperçoit qu’il a à peine atteint la moitié de sa tâche, malgré son estimation. Cela peut être dû à une sous-estimation de

263

Conduite de projets informatiques offshore

l’effort nécessaire pour finaliser une tâche. Seuls les livrables recettables, c’est-à-dire que l’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 échanges formels, 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é du travail accompli, ils peuvent être tentés de cacher leurs retards et leurs problèmes en espérant les résoudre avant que le problème apparaisse au grand jour et cause des difficultés. C’est aussi l’une des raisons pour lesquelles le client doit utiliser les informations sur les problèmes pour aider les équipes à les résoudre et non pour rechercher et punir les coupables.

ÉTUDE DE CAS Une dure journée Une anecdote exprime très bien la situation que rencontrent la plupart des managers de développements informatiques, tout particulièrement en offshore. Une livraison importante est prévue pour le 30 du mois. Le manager explique aux chefs de projet l’importance de la livraison pour cette date, et tous se mettent au travail. Le 5 du mois, le manager fait le tour des chefs de projet, qui répondent l’un après l’autre que ce sera prêt dans les temps. Le 15 et le 20, le message est identique. Le 25, ils annoncent que ce sera dur. Le 29, ils font savoir que 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’il fallait 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…

Le seul moyen pour les participants au projet de se rendre compte de l’avancement réel du projet est de le prouver par la réalité de la progression. L’intégration des réalisations en continu permet de vérifier que les développements s’intègrent correctement, et les tests vérifient la qualité des livrables.

Intégration continue et périodique Comme expliqué à la section précédente, l’intégration est le seul moyen de s’assurer de la progression des tâches de développement. Le code réalisé est compilé et intégré à une version en cours de construction afin de donner lieu à des tests unitaires ou fonctionnels et 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 de dé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 pas consommer une main-d’œuvre de test exagérée. Ces tests automatisés peuvent être exécutés de nuit, après une intégration et un déploiement eux-mêmes automatisés. Au matin, on analyse les sujets qui n’ont pas bien fonctionné pour éventuellement les

264

Chapitre 12 – Processus et méthode

corriger. Sans une telle automatisation, mieux vaut viser une intégration hebdomadaire ou 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é et les comparer aux engagements de livraison. • La pression est maintenue de façon continue sur les équipes de développement, qui ne peuvent masquer leurs problèmes de production en espérant se rattraper par la suite. • Les problèmes d’intégration entre les productions des différentes équipes sont détectés immédiatement si les modules livrés ne s’intègrent pas bien avec le reste de l’application. • Si des tests automatisés sont mis en place, chaque intégration est testée, et les régressions sont immédiatement détectées, rendant ainsi leurs corrections plus aisées puisqu’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 également de vérifier le bon fonctionnement des procédures en place, notamment sur la gestion du référentiel. L’avantage le plus important est bien sûr de confronter la livraison avec la réalité et la validation de la qualité du livrable. On n’a même plus à demander aux chefs de projet si la fonctionnalité 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 naturellement 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 atteint que si l’on a réussi à mettre en œuvre un ensemble de procédures. Pour parvenir à mettre en 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 streams soient correctement gérés. Cela nécessite généralement une gestion efficace de tout le cycle 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 un ordre cohérent. • Une automatisation des déploiements et des tests sans laquelle l’intégration continue n’a qu’un intérêt réduit. La recherche de l’automatisation des tests est particulièrement importante lorsqu’on gère des 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 le déploiement sur la plate-forme cible. Une fois le déploiement réalisé, on peut engager les tests 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’application de procédures strictes et permet de suivre exactement la progression du projet quant à la réalité des livraisons.

265

Conduite de projets informatiques offshore

Les tests unitaires Les tests unitaires sont considérés comme une étape essentielle pour parvenir à un bon niveau de qualité de la production. Le développeur teste les fonctionnalités élémentaires d’un programme indépendamment de la façon dont il a été codé afin d’en valider le fonctionnement. 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 de test. Pour les réduire dès les premières livraisons des exécutables, il convient de s’assurer que les exécutables livrés aux équipes de test sont d’un niveau de qualité suffisant pour ne pas recéler de dysfonctionnements. Pour cela, le développeur prend en charge le premier niveau de tests unitaires afin de vérifier que les exécutables implémentent les fonctionnalités décrites dans les cas d’utilisation. La plupart des développeurs n’aiment guère tester leurs réalisations et transmettent trop rapidement 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 rencontrant des anomalies bloquantes, qui doivent être documentées et retournées aux développeurs. Si les anomalies sont trop nombreuses, il est rapidement impossible d’anticiper la date à laquelle l’exécutable sera suffisamment stable. Les équipes de test s’impatientent, perdent du temps à rédiger des change requests, et une tension en résulte souvent entre les testeurs et les développeurs. Si, au contraire, la livraison est tout de suite d’un niveau de qualité suffi sant, l’équipe de test ne trouve que des anomalies mineures, quelques anomalies majeures et dans de rares cas des anomalies bloquantes. Les scénarios des tests unitaires peuvent être définis par les équipes de test, qui demanderont que ceux-ci soient en premier lieu réalisés par les équipes de développement ou par les chefs de produit qui les associent directement aux cas d’utilisation. On peut décider de formaliser le jeu de données utilisé lors de ces tests afin qu’il soit représentatif de tous les cas fonctionnels possibles. Le résultat des tests unitaires est livré aux équipes de test avec l’exécutable de façon à garantir un certain niveau de qualité.

Automatisation des rapports de suivi De la même façon que l’on peut automatiser les tests, il est souhaitable d’automatiser les rapports de suivi des développements afin d’éliminer toute interprétation humaine dans l’appréciation de l’avancement du projet. On cherche alors à s’appuyer autant que possible sur les sources d’information dont on dispose. Si l’on a pu mettre en place le référentiel, la gestion du changement, un processus avec des procédures strictes, un planning représentant réellement la progression du projet et des résultats de test fiables, on dispose de l’essentiel des informations dont on a besoin pour construire des rapports de suivi. Les procédures doivent être organisées de sorte à obtenir ces informations régulièrement et à donner une vision fiable et objective de l’avancement du projet. Si nécessaire, un détail précis de certains sujets qui ne fonctionnent pas correctement permet de choisir les meilleures actions correctives.

266

Chapitre 12 – Processus et méthode

Conclusion La mise en place d’une méthodologie pour l’offshore se résume à certains principes essentiels, sur lesquels il importe de se concentrer. À l’inverse, il ne faut pas se laisser dépasser par le grand nombre de procédures et documents qui sont d’une importance ré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 motivation et de productivité. Mieux vaut disposer d’une équipe motivée et organisée, avec des rôles bien définis, plutôt que de procédures censées organiser tous les aspects du projet. Les procédures doivent venir en support de l’organisation humaine pour la rendre 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 dispose en permanence d’objectifs à court terme permettant de vérifier la progression du projet sur des livrables tangibles. • On utilise des outils pour organiser et appliquer strictement les workflows autour de la gestion du référentiel et du changement. On dispose ainsi de mesures de la qualité des livrables et de moyens de travailler en équipe efficacement. • On cherche à mobiliser toutes les équipes sur la qualité des livrables individuels et d’équipe. La qualité des livrables à tous les niveaux est le garant d’un meilleur travail d’é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.

267

Chapitre 13

Gestion des tests et de la qualité Lorsqu’on travaille avec une équipe en offshore, on doit naturellement prévoir d’y placer une équipe pour assurer les tests. L’objectif est d’améliorer la communication avec l’équipe de développement et de réduire le coût de ces tâches dévoreuses de temps. La qualité de la production du code doit être vérifiée et contrôlée par les membres de l’équipe de test, qui fonctionnent de pair avec les développeurs. Ils vérifient notamment les aspects fonctionnels et techniques du code (performances, sécurité et respect des rè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 anomalies d’un produit. On pourrait aussi définir son rôle comme consistant à déterminer l’état de qualité d’un livrable ou d’un produit complet de façon objective et continue. Il s’agit ici de mesurer le risque que l’on prend à livrer un produit. Cela implique tout autant d’identifier les anomalies connues que d’estimer la qualité des parties du produit sur lesquelles 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 risques introduits par les zones d’ombre que de suivre les anomalies déjà détectées à travers un workflow. On commence par tester le comportement fonctionnel. Le produit livré correspond-il aux fonctionnalités décrites dans les documents de spécification ? On s’intéresse ensuite au respect 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ète enfin des exigences techniques, notamment des performances et de l’architecture, et de la consommation des ressources (processeur et mémoire). La sécurité est toujours considérée comme une préoccupation importante si l’application est 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 niveau de sécurité soit suffisant, sans vraiment définir ce que cela signifie. L’équipe de test doit cependant 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 évolutions et asseoir le contrôle sur le produit. Il arrive que certaines procédures soient érigées

269

Conduite de projets informatiques offshore

en règles incontournables, comme de refuser de tester des programmes qui ne vérifient pas certaines règles. Pour disposer d’une vision juste de l’état de qualité d’un produit, l’équipe de test doit disposer de nombreuses informations. Elle doit aussi gérer son temps de façon à comprendre précisément où se trouvent les gisements d’incertitudes sur la qualité et à trouver les meilleures façons d’en avoir une vision claire. De plus, l’équipe de test doit en permanence être tenue au courant des attentes du client afin de concentrer ses actions sur les domaines 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 anomalies sur 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 de fonctionnalités pour commencer les tests est un leurre, qui cherche souvent à masquer une finition insuffisante des premières livraisons, et donc probablement un retard. Les tests 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’équipe de test. Leur fonction est de vérifier le fonctionnement de chaque élément d’une fonction selon sa description dans les spécifications détaillées. Pour que le développeur puisse communiquer 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és entre les équipes de test et de développement. Le développeur accompagne ses productions jusqu’à un point où leur fonctionnement est correct à ses yeux. Pour y parvenir, il doit vérifier lui-même par des tests unitaires que sa réalisation respecte les spécifications détaillées. Il est inutile que les livrables soient échangés plusieurs fois entre les équipes de développement et de test avant de parvenir à couvrir les fonctionnements de base décrits dans les cas d’utilisation. Ces échanges répétés entraînent une perte importante de productivité et des tensions entre les équipes de développement et de test. Les plannings dérapent, et les équipes de développement voient leur production renvoyée pour correction un grand nombre de fois. Ces échanges créent de surcroît des tensions entre les collaborateurs, qui voient leurs plannings glisser et réalisent qu’ils ne pourront tenir leurs engagements. L’équipe de développement doit effectuer elle-même les tests unitaires visant à vérifier que le produit qui sera livré aux équipes de test correspond aux fonctionnalités attendues. Pour ce faire, elle dispose de cahiers de test unitaire comportant des jeux de données stables et adaptés, précisant la nature des tests qui doivent être réalisés. Le développeur ne considère sa production livrable aux tests que si elle a passé avec succès les tests unitaires. Le fait de les réaliser lui-même lui permet de corriger rapidement les dysfonctionnements. L’équipe de test qui reçoit un livrable s’attend à un niveau de qualité assez élevé. Il faut que le développeur soit réellement motivé pour livrer la meilleure qualité qu’il peut

270

Chapitre 13 – Gestion des tests et de la qualité

atteindre. Certaines équipes en offshore donnent des bonus aux développeurs selon le faible 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 la qualité 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és et leurs résultats. La première tâche du testeur est d’exécuter les tests unitaires sur sa plate-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 luimême les tests localement, la formalisation des tests unitaires qui était déjà fortement souhaitable, 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’un niveau de qualité minimal des éléments livrés par les développeurs aux testeurs. Les développeurs assurent 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 ou par 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 équipes de développement.

Les tests fonctionnels Les tests fonctionnels ne peuvent être correctement réalisés que si l’on dispose de spécifications détaillées, complètes et à jour. Les modifications des spécifications et les ajouts doivent 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’aide d’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 équipes en offshore d’élaborer en s’appuyant sur les spécifications ou les règles de l’IHM. On essaie 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 se produire ?). 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’avancement du produit est entièrement testé afin d’évaluer sa qualité. On peut aussi essayer de viser une 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. À chaque build, le testeur cherche à savoir quel est l’état de qualité de chaque fonction, puisqu’elle est potentiellement modifiée.

271

Conduite de projets informatiques offshore

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 toutefois pouvoir en être certain. Il se peut que cette fonction fasse appel à d’autres services, qui ont eux été modifiés ou qui contiennent depuis peu des anomalies. On peut aussi avoir fait une correction mineure, théoriquement bénigne et parfaitement circonscrite, qui engendre des anomalies majeures inattendues dans d’autres parties du produit. Il se peut encore 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èrement. Plus les tests sont anciens, et moins les résultats obtenus lors de ces tests sont fiables quant au dernier build. Le test d’une fonction est long et répétitif, et il est pratiquement impossible de réaliser manuellement tous les tests à chaque intégration, surtout si celles-ci ont lieu très fréquemment. Il faut recourir aux tests automatisés pour qualifier les builds quotidiens ou bihebdomadaires.

Les tests minimaux, ou MAT Il est recommandé de séparer les tests fonctionnels en deux niveaux de test, les tests profonds, qui correspondent à des tests complets de toutes les fonctionnalités, et les tests rapides, ou MAT (Minimal Acceptance Test), qui couvrent succinctement une série de 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 en deux heures. S’ils sont automatisés, on peut aller plus loin dans leur exécution que s’ils sont réalisés manuellement. Les MAT n’étant pas exhaustifs, ils ne peuvent garantir pleinement le fonctionnement du produit. Ils se concentrent sur les scénarios d’utilisation les plus importants et les plus utilisés par les clients. Ces tests légers peuvent être réalisés rapidement lorsqu’on souhaite 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 les modules et tous les aspects techniques de l’application. Au moins une utilisation de tous les composants est testée, ainsi qu’au moins un accès à tous les outils de middleware, de faç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 fonctionne correctement et qu’on n’a pas le temps de le tester totalement. On utilise le MAT pour valider que le livrable reçu par l’équipe de test fonctionne, par exemple quand on doit livrer 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, et donc tous les fichiers, tous les éléments du middleware et tous les types d’interactions avec l’extérieur. Les MAT sont une série de tests très importants, que l’on a tout intérêt à automatiser afin d’en augmenter l’étendue. Ils doivent être exécutés le plus souvent possible, parfois sur une même version mais sur des plates-formes différentes. Ils peuvent alors faire office de tests de validation de déploiement et servir de référence tout au long du travail avec l’équipe distante.

272

Chapitre 13 – Gestion des tests et de la qualité

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 un plan de test complet. Ces tests très longs ne peuvent être effectués sur tous les builds. Ils ne conviennent donc pas lorsqu’on doit livrer une version rapidement. Les tests minimaux, ou MAT (Minimal Acceptance Test), couvrent succinctement tout le produit, en tentant de se concentrer sur les scénarios les plus importants. Les MAT sont généralement automatisé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 une plate-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 de l’état de qualité et de stabilité d’une livraison. Cet aperçu est toutefois peu profond, et il ne permet pas de juger de l’état du produit ni de sa progression dans le temps vers un produit stable, utilisable et de qualité. Pour suivre l’état de qualité, on peut utiliser un tableau, dit Acceptance Sheet, permettant de suivre le résultat et l’ancienneté des tests pour chaque fonctionnalité (feature). On visualise de la sorte sur un même document les résultats des tests les plus récents et l’état de connaissance que l’on a des campagnes de tests plus anciennes. Un modèle de tableau de ce type est fourni en annexe. Le tableau 13.1 indique les principes de fonctionnement de l’Acceptance Sheet . Tableau 13.1. Exemple d’Acceptance Sheet Fonctionnalité

Campagne de test 12

Fonctionnalité 1

Bogue mineur CR0034, CR0035

Fonctionnalité 2

OK

Fonctionnalité 3

OK

Fonctionnalité 4

Bogue majeur CR008

Campagne de test 13

Campagne de test 14

Campagne de test 15

Bogue mineur CR0034

Campagne de test 16 OK

Bogue majeur CR0056

OK

Bogue mineur CR0087

OK

Le tableau montre que l’on ne connaît de façon sûre que l’état de la fonctionnalité 1, les autres fonctionnalités n’ayant pas été testées sur la dernière campagne de test. On ne sait pas 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 de qualité, puisque les informations remontent à la campagne de test précédente. L’état de chaque colonne peut bien sûr être codé par des couleurs représentant visuellement l’état

273

Conduite de projets informatiques offshore

de qualité. Lorsqu’une anomalie est identifiée, on place son code dans la case qui la repré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 passe du vert au jaune ou au rouge), du risque que l’on prend en ne retestant pas une fonctionnalité d’après l’ancienneté du dernier test passé avec succès, et l’on dispose du détail des anomalies connues sur chaque fonctionnalité. Si le produit est destiné à plusieurs plates-formes de déploiement, par exemple, si l’on a une portabilité sur plusieurs systèmes d’exploitation ou plusieurs bases de données, on peut prévoir d’effectuer une rotation des plates-formes de test et de noter la plate-forme utilisée pour les tests pour chaque campagne de test. Ce tableau est particulièrement utile pour les développements en offshore car il permet de connaître la stabilité d’un produit en cours de construction. Cela évite que les équipes de validation ne travaillent sur des fonctionnalités dont les anomalies sont connues. Il permet également de donner des priorités de réalisation aux tests. Il sert alors d’outil de dé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 quotidiennement, 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’information fournie par les équipes sur la progression du développement.

Les tests fonctionnels transversaux Les procédures décrites précédemment cloisonnent fortement les tests par fonction et par module, toute l’organisation étant structurée par composant. De son côté, l’utilisateur s’intéresse avant tout à des tests métier, qui sont transversaux et suivent son cheminement à 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, la mise à jour d’une information doit être reprise dans un tableau synthétique faisant partie d’un autre module. Le cloisonnement par module peut faire que l’on ne teste jamais ces croisements de mises à jour. Les tests transversaux visent à combler ces défaillances. Ils sont souvent organisés sous forme de scénarios métier, dans lesquels on accompagne les actions 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écurrente de problèmes avec l’offshore lorsqu’on met en place une méthodologie industrielle pour la première fois. On a alors tendance à se concentrer sur des tests très structurés, et l’on en oublie la vision d’ensemble. Lorsqu’on met un produit testé par fonction entre les mains d’un utilisateur final, des anomalies 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 rapidement, surtout si l’on a affirmé que le produit était bien testé, fort des nombreux tests cloisonnés effectués. Comme les tests par module et par fonction, les tests transversaux doivent être assurés et 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

274

Chapitre 13 – Gestion des tests et de la qualité

sollicités pour donner une réalité métier à ces tests. Lorsque les utilisateurs fi nals rencontrent de nouvelles anomalies, ces cas de test sont ajoutés aux tests transversaux. Les tests transversaux sont structurés et documentés. Ils sont en outre reproductibles.

Les tests intuitifs Les tests intuitifs sont des tests qui ne sont pas formalisés. On y fait ce que l’on veut pour détecter des anomalies selon son intuition ou son expérience. Les tests formalisés ne peuvent en effet tout prévoir. Par exemple, il est possible que l’on ne prévoie pas de tester formellement la couleur du fond d’écran, bien qu’elle soit définie dans la charte graphique du projet. Une erreur sur la couleur de l’écran est pourtant immédiatement visible de tout utilisateur. C’est un des défauts que l’on attribue très souvent aux équipes en offshore. On dit qu’elles suivent les procédures à la lettre mais ratent les erreurs les plus flagrantes, sous prétexte qu’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ù ils créent le plus souvent des anomalies et peut les rechercher directement. Bien sûr, ces tests ne sont pas reproductibles et ne sont pas documentés, mais ils sont d’une remarquable efficacité. Il est recommandé d’allouer un certain temps sur chaque itération pour ces tests intuitifs.

Enrichissement des tests Lorsque des anomalies sont détectées par les utilisateurs, il est important de comprendre où se trouve la faille dans les processus de test et de la combler, dans la mesure du possible, 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 en dehors d’elles leur soient transmises et qu’elles soient considérées non comme des fautes 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 ne peuvent améliorer les processus de test. Du côté du client, on pensera que les testeurs ne sont pas très efficaces puisqu’ils travaillent en dehors de la réalité. Il faut donc toujours communiquer aux équipes en offshore le niveau de satisfaction des utilisateurs. Cette communication n’est jamais naturelle. Il est du ressort du chef de projet du client de faire comprendre 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 se plaint 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 est facile de mettre en place un retour d’information sur la satisfaction des clients et sur la vie du produit. Les retours positifs sont de surcroît des sources de motivation. Quant aux retours 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 utilisateurs et propose des moyens d’y remédier. Elle se trouve plus impliquée dans la vie du projet, et il y a tout lieu d’espérer que la recherche de la qualité s’en trouve renforcée.

275

Conduite de projets informatiques offshore

EN RÉSUMÉ Satisfaction des utilisateurs et motivation

Les équipes en offshore doivent être informées du niveau de satisfaction des utilisateurs finals. Une différence de perception de ce niveau devient vite intolérable. Une bonne connaissance de la satisfaction des utilisateurs peut être une source de motivation et de concentration sur les sujets les plus importants pour ces derniers.

Les tests techniques Les tests techniques n’attirent vraiment l’attention que lorsque le projet va mal ou que les performances ne sont pas au rendez-vous. On en trouve une grande variété, depuis les tests de performance jusqu’aux tests de charge, en passant par les tests des services techniques. 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 automatisation. On pourra ainsi détecter les régressions sur les temps de réponse et identifier la modification qui en est la cause. Bien souvent, l’équipe qui s’occupe des services techniques jouit d’une situation particulière. Sa production n’est pas directement testée par les équipes de test puisque ces dernières ne peuvent aisément tester des bibliothèques de fonctions sans interface utilisateur. Cette production est cependant recettable et testable, et il n’y a pas de raison que les services techniques ne soient pas testés comme les autres. Le testeur représente ici le client 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 en condition, consistant à appliquer la nouvelle version des services techniques aux réalisations fonctionnelles existantes. L’équipe de test technique peut vérifier ce fonctionnement sans que les équipes chargées des développements fonctionnels soient affectées par les périodes de stabilisation. Les nouveaux services techniques sont livrés après que les développements fonctionnels ont été vérifiés. Bien souvent, une production défaillante de services techniques peut retarder des livraisons, alors que les équipes fonctionnelles n’y sont pour rien. Pour que les équipes chargé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’occasion de se déresponsabiliser. Si l’on parvient à isoler les livraisons des services techniques, 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 les lignes de code exécutées lors des séquences de test. Ces produits ne sont malheureusement pas disponibles pour tous les langages de programmation.

276

Chapitre 13 – Gestion des tests et de la qualité

Lorsqu’on peut les utiliser, ils se révèlent très utiles pour repérer des pans entiers du code source qui n’auraient pas été testés. On peut dès lors revoir les scénarios de test ou estimer les tests partiels suffisants. Ce type d’outil permet d’éliminer une forte incertitude sur les anomalies cachées dans le produit. Si l’on connaît précisément les portions de code testées régulièrement, et surtout les fonctions qui ne font pas encore l’objet de tests structurés, on peut estimer assez justement le risque que l’on prend en considérant l’application comme testée. On ne connaît certes pas la quantité d’anomalies qui persistent, mais on a une bonne idée du risque 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 savoir pré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 tests lorsque le produit est terminé environ aux trois quarts. Cela permet de décider des actions correctives à engager en ayant encore le temps de les réaliser. Vis-à-vis du client comme des utilisateurs finals, il est particulièrement valorisant de pouvoir quantifier la quantité de lignes de code testées de façon automatisée, à la fois régulièrement et occasionnellement. Cela n’excuse sans doute pas d’éventuelles anomalies majeures 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 des activités délicates. Les plates-formes chez le client sont souvent différentes de celles qu’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écuter le MAT, ou une version réduite du MAT, de façon automatisée. Une exécution sans erreur du 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 naturellement comme étant chargées de limiter les risques d’insatisfaction. Avec des équipes de test en offshore, les utilisateurs se montrent toutefois moins tolérants aux erreurs qu’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 utilisateurs dans l’équipe en offshore. De ce point de vue, elles sont les plus importantes. Elles doivent en être conscientes, et l’importance de leur rôle doit être reconnue de tous les autres collaborateurs. Les développeurs ont parfois l’impression qu’une hiérarchie par la compétence s’établit naturellement. Donner une grande valeur aux tests bouscule cette hiérarchie et affirme le rôle des testeurs.

277

Conduite de projets informatiques offshore

Lorsque les équipes de test se mettent dans la peau de l’utilisateur final, elles doivent mesurer 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 parfaitement testées car l’utilisateur ne tolère aucun défaut. Les mauvais alignements, les lenteurs d’exécution, les fautes d’orthographe, etc., lui sont insupportables. Il est en revanche beaucoup plus tolérant à l’égard des fonctionnalités qu’il utilise rarement et qui peuvent comporter certaines anomalies, même plus graves, pour peu qu’elles ne créent pas de gêne importante. Les testeurs doivent donc prendre de l’altitude par rapport aux procé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 des utilisateurs. S’ils peuvent comprendre qu’un cas ne fonctionne pas, ils considèrent comme de la pure négligence qu’une anomalie apparaisse sur des fonctionnalités qui donnaient satisfaction auparavant. La mesure du risque ne peut être juste que si l’on essaie de l’estimer tel qu’il est perçu par le client. Les équipes de test pourraient passer un temps infini pour assurer qu’un produit ne contient pas d’anomalies et se comporte comme on le souhaite. Il convient donc de vérifier régulièrement que le temps passé à contrôler un produit est rentable. Une telle estimation est toutefois délicate. Plus le temps passe, plus les anomalies sont difficiles à 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 les anomalies le plus importantes. Le moment arrive ensuite où l’on préfère mettre le produit en 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é au coû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ées cachées dans le produit. On prend les décisions par rapport au nombre d’anomalies répertoriées et à la difficulté à détecter de nouvelles anomalies. C’est pour éviter que cette dernière mesure ne soit faussée que l’on recommande d’exécuter des tests intuitifs en dehors de toute procédure. Cela permet de ne pas appliquer les mêmes scénarios de test mécaniquement, car ceux-ci découvrent de moins en moins d’anomalies lors des builds successifs jusqu’à ne détecter que les anomalies de régression lorsque tous les scénarios ont é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 surtout par rapport à la satisfaction des utilisateurs. Les équipes de test sont les plus proches représentants du client et des utilisateurs chez le prestataire. Il est important qu’elles essaient de mesurer en permanence le risque en se mettant à la place de l’utilisateur et en estimant son niveau de satisfaction. Elles doivent se faire les avocats des utilisateurs. Les décisions doivent être prises en visant la satisfaction des utilisateurs finals afin de déterminer comment équilibrer les tests pour limiter au mieux le risque d’insatisfaction. On détermine ainsi le pourcentage des tests structurés (scénarios de test réalisés régulièrement), automatisés, techniques et intuitifs. L’équipe de test doit être une force de proposition pour optimiser le risque, tant auprès du client que des autres équipes chez le prestataire.

278

Chapitre 13 – Gestion des tests et de la qualité

Figure 13.1. Coûts et efforts de détection d’anomalies

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, et elles sont tenues pour responsables de nombreux maux dont elles ne portent pourtant qu’une responsabilité limitée. Toute anomalie qui serait détectée après leur travail est considérée comme inacceptable. En réalité, les testeurs assurent avant tout des tâches planifiées et documentées, dont on peut juger la bonne ou mauvaise réalisation de façon assez simple. C’est leur première mission, mais il ne faut surtout pas qu’ils s’arrêtent là. Ils doivent représenter le client et l’utilisateur du produit chez le prestataire et faire tout leur possible pour limiter les risques sur le produit et accroître la satisfaction des utilisateurs. Le travail des équipes de test est extrêmement difficile, car elles sont les coupables désignés de tous les maux, ou presque. Comme elles assurent les dernières tâches avant livraison, elles sont toujours pressées par le client pour terminer leurs tâches de test au plus vite. C’est d’autant plus difficile que, bien souvent, elles ont reçu les livrables en retard de la 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

279

Conduite de projets informatiques offshore

avant l’utilisateur, même si cette anomalie ne fait pas partie des scénarios de test habituels. Les équipes de test ont un travail beaucoup moins créatif et motivant que la plupart des autres équipes en offshore. Leur travail est répétitif, et il est difficile de leur conserver une forte motivation. Les équipes de test doivent s’aligner en permanence sur les attentes du client, ce qui leur demande un effort d’écoute continu, que les autres équipes n’ont pas besoin d’effectuer dans de telles proportions. C’est d’autant moins facile qu’il s’agit d’une écoute à distance du client pour comprendre sa façon de réaliser la recette et les sujets qui lui tiennent le plus à cœur. Les équipes de test sont bien les meilleurs représentants du client chez le prestataire et doivent être reconnues comme tels, si l’on souhaite rendre leur rôle plus motivant et influent. Une équipe valorisée et bien organisée apporte un confort important dans la livraison des exécutables et permet de stabiliser beaucoup plus tôt les livrables en leur faisant atteindre 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 beaucoup plus simple, et l’on évite de nombreux heurts. La satisfaction est au rendez-vous, chez le client comme chez le prestataire.

280

Chapitre 14

Intégration et déploiement Lorsqu’on travaille avec des équipes en offshore, on se concentre avant tout sur les équipes de développement. Les équipes de test sont parfois oubliées, surtout si l’on ne fait pas la différence entre test et recette et qu’on place cette dernière chez le client, et il est rare que l’on pense aux équipes d’intégration et de déploiement. Les premières livraisons au client sont alors des casse-tête souvent cités en exemple des diffi cultés à travailler avec l’offshore. Les produits qui sont aujourd’hui développés en offshore ne se transportent pas aussi facilement qu’on le croit. Le temps des exécutables aisément transportables a pratiquement disparu. Les déploiements actuels sont multiserveurs. Ils demandent une compilation sur la plate-forme cible et s’accompagnent du déploiement et de la configuration de toute 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 finalisés et dont les procédures d’installation sont encore inexistantes ou tout juste émergentes. Ce qui fonctionne en offshore ne fonctionne pas nécessairement localement. Si l’on n’a pas prévu de créer une équipe d’intégration et de déploiement et que le produit nécessite une gestion de plate-forme avancée, on peut être certain que le déploiement de la solution sera perçu comme un problème. Ce problème s’envenime rapidement pour peu que le client s’agace de ne pouvoir appréhender le produit que ses chefs de projet en offshore 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, on peut 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 leurs responsabilités pour assurer la supervision et l’administration des plates-formes, venant ainsi 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. On y trouve bien sûr les systèmes d’exploitation, la base de données, mais aussi le

281

Conduite de projets informatiques offshore

middleware (serveurs EJB, servlets, etc.) et, éventuellement, les progiciels fonctionnels sur lesquels s’appuie l’application. Ces produits demandent une gestion souvent assez lourde pour suivre leur configuration, assurer les optimisations, étudier les mises à jour des versions et préparer les migrations vers une nouvelle version de certains composants. L’équipe ID a pour responsabilité de configurer les couches techniques. Elle doit pour cela connaître précisément le fonctionnement interne de l’application afin de déterminer les services qui doivent être ouverts sur les serveurs. Par exemple, en maintenant la liste de tous les protocoles utilisés entre les composants et les serveurs, elle peut filtrer efficacement les échanges entre les serveurs en n’autorisant que les flux utiles, en améliorant du 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’assemblage des builds et de déploiement vers les différentes plates-formes cibles. Elle analyse les demandes 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 des serveurs sous Windows, puisse être déployée sur une plate-forme sous Linux ou si l’on souhaite 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 choisira d’activer ou non. L’équipe ID s’assure de produire les notices de déploiement et de maintenance des applications, surtout lorsque l’hébergement est assuré par un tiers, qui est responsable d’un certain niveau de service et qui assure lui-même toutes les tâches de déploiement. Elle peut 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 une supervision plus fine. Assurer un service de supervision des plates-formes de production vingt-quatre heures sur vingt-quatre et sept jours sur sept n’est pas toujours facile et exige au moins cinq collaborateurs. Les équipes ID offshore peuvent assurer un tel service, parfois avec une flexibilité 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 des réalisations offshore. Elle joue un rôle charnière au moment de la livraison et peut fournir une quantité de travail importante pour accompagner la solution une fois déployée, allégeant d’autant le travail des équipes du client. EN RÉSUMÉ L’équipe ID

Une é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 solution déployée et recettable sur une plate-forme supervisée. L’offshore apporte à cette discipline fortement consommatrice de ressources de précieux avantages en terme de coûts et de flexibilité pour achever les travaux de construction de la solution.

282

Chapitre 14 – Intégration et déploiement

Fondations techniques et procédures On peut décomposer en couches les éléments techniques sur lesquels s’appuie l’application, 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 possibilité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 optimisation des systèmes d’exploitation et du middleware

Évolutions très fréquentes lors des premiers déploiements et peu d’évolutions une fois le système stable

– Étude des évolutions du produit – Recommandations pour faire un produit plus propre, par exemple en limitant 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

283

Conduite de projets informatiques offshore

En identifiant les différentes couches techniques utilisées par le projet, on peut en industrialiser la gestion par couche et éviter qu’elles deviennent des sources de dysfonctionnement 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 être gérées selon des procédures similaires à celles des évolutions fonctionnelles. Toute demande de changement des fondations techniques doit suivre un workfl ow, à l’image des demandes d’é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’on attende le moment adéquat afin d’en limiter les effets. Par exemple, si l’on gère une application de comptabilité, on peut éviter de mettre à jour une plate-forme vers la fin de l’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ésoudre lorsqu’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 pour gérer ces différentes fondations techniques. Sans cadre procédural, ces dernières diffèrent rapidement de celles du client, engendrant des différences de comportement du fait de la différence de versions ou de configurations d’éléments techniques. Chacune des couches techniques 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 partenaire. Après quelques tentatives d’assistance par téléphone et messagerie, le client demande à certains collaborateurs en offshore de venir chez lui pour l’aider. Une fois chez le client, ils forment des spécialistes pour assurer les déploiements ultérieurs. Ces spécialistes chez le client sont toutefois souvent occupés à d’autres tâches, comme le support technique pour les utilisateurs, ou assurent des déploiements d’autres applications ou d’autres tâches. Ils ne sont donc pas aussi performants que les collaborateurs du prestataire pour l’application développée en offshore. Les migrations techniques majeures ou le support de nouvelles technologies sont des décisions importantes, qui impliquent de nombreux intervenants. Les raisons de ces évolutions sont multiples. Les utilisateurs peuvent vouloir utiliser des technologies plus récentes, par exemple pour combler certains trous de sécurité ou apporter un gain de performance, ou souhaiter installer des corrections d’anomalies gênantes. Certains utilisateurs peuvent demander avec force que leur fournisseur leur donne une version compatible avec leurs choix stratégiques. Ces choix peuvent concerner des technologies qui ne sont pas supportées par l’application. Par exemple, l’utilisateur peut demander que la base de données soit Microsoft SQL Server, alors que seul Oracle Server est supporté et que le travail technique peut être trop limité pour supporter cet autre serveur de données. La quantité de test à réaliser sur chaque version doit être considérée avec attention, car c’est un coût récurrent inévitable. Les équipes de test et celles d’intégration et de déploiement peuvent évaluer les tâches à réaliser. Si le client le décide, les tests peuvent être dimensionnés de sorte à assurer également ces tâches. Pour les applications complexes, le déploiement de l’application peut donner lieu à des anomalies qui ne sont dues qu’à des différences entre les plates-formes de test et de production. Lorsqu’on parle de déploiement de plates-formes multiserveur, aux configurations fortement sécurisées et qui gèrent de façon très étroite les services et les protocoles utiles, il est indispensable de mettre en place des procédures de déploiement

284

Chapitre 14 – Intégration et déploiement

strictes permettant de créer des plates-formes identiques. Les anomalies que l’on c onstate sur une plate-forme doivent pouvoir être constatées sur les autres, ou, si les platesformes 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 à la culture de l’entreprise. En tout état de cause, on peut s’attendre à ce qu’elles ne soient stables 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 de gestion de celles-ci crée une forte instabilité lors des livraisons des exécutables et génère une frustration importante chez le client. Les fondations techniques devraient être gérées comme le sont les fonctionnalités, c’est-à-dire par version. 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é des spécialistes. Cela vaut d’autant plus si le produit doit d’abord être déployé alors qu’il est encore 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 souvent déployer les livraisons par lui-même, sans toujours réaliser le mécontentement que cela suscite. Il y investit un temps considérable, pour finalement ne parvenir à déployer l’application 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 se reproduisent pas chez le prestataire, parfois du fait de différences de déploiement. Il résulte des tensions inutiles et une perte de confiance. Le client peut même penser que le prestataire lui cache la réalité de la situation. Le versionnement des fondations techniques permet de vérifier la conformité des platesformes et de réduire les risques liés à ces dernières. Il est toujours bon de responsabiliser les équipes en offshore sur toutes les phases du projet, y compris le déploiement sur la plate-forme client. On recommande généralement que la première livraison chez le client soit effectuée par un collaborateur du prestataire qui se rend chez le client et lui explique en détail le contenu technique de l’application. Le prestataire se trouve ainsi pleinement responsabilisé sur la qualité du déploiement. Il n’y a plus de fracture entre la production chez le prestataire et le déploiement chez le client, 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 les plates-formes du client, complétant de la sorte le travail de construction de la solution par un déploiement prêt à être recetté. Il est possible de s’assurer que les plates-formes en offshore et chez le client se comportent de la même façon et que les anomalies soient aisément réplicables.

285

Conduite de projets informatiques offshore

Les tests chez le client Certaines applications peuvent nécessiter des déploiements complexes. Dans les architectures 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èdent au service par Internet, jusqu’aux serveurs d’applications, qui détiennent la logique applicative, aux serveurs LDAP, qui gèrent les utilisateurs et leurs droits, et aux serveurs de données, sans oublier les importations et exportations depuis et vers d’autres applications sur la plate-forme (comptabilité, etc.). On trouve en outre des pare-feu et des équilibreurs de charge, qui peuvent encore complexifier la solution. Pour de telles platesformes, l’automatisation des déploiements est indispensable. La qualité des déploiements est difficile à vérifier. Une fois les exécutables installés sur les différents serveurs et les serveurs configurés comme il semble convenir, il faut encore en vérifier le fonctionnement. Dans tous les cas, il faut être capable de recetter rapidement le déploiement sur la plate-forme. La fenêtre disponible pour assurer ces déploiements est souvent étroite, puisqu’ils nécessitent que le service aux utilisateurs soit suspendu. Le test sur la plate-forme du client est d’autant plus difficile que la plate-forme est fortement sé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 sont déployés comme prévu sur les différents serveurs. On peut ensuite exécuter un scénario fonctionnel de test qui a été automatisé par l’équipe de test, une sorte de MAT réduit et bien conçu en guise de test de validation de la plate-forme. Ce scénario peut avoir un objectif technique en activant au moins une fois tous les exécutables sur tous les serveurs. Il s’assure ainsi que les exécutables sont en place et qu’ils communiquent entre eux. L’équipe en offshore peut s’assurer de la sorte que la plate-forme ne présente pas de dysfonctionnement immédiatement détectable. Ces tests essentiels pour assurer le fonctionnement du produit ne sont toutefois que très partiels. S’il y a plusieurs serveurs d’applications, on ne peut être certain que tous les serveurs sont correctement déployés. On ne connaît pas non plus l’état de sécurité de la plateforme æ 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 prendre beaucoup de temps. C’est pourquoi l’on emploie souvent une plate-forme de préproduction pour vérifier pendant une phase de test avant déploiement en production que les scripts 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 exhaustive. Les équipes offshore peuvent aider à réaliser ces recettes en fournissant des tests automatisés validant 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é.

286

Chapitre 14 – Intégration et déploiement

Supervision des plates-formes Si l’on cherche à disposer d’applications qui assurent un service sur des plages horaires importantes, 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 supervision de la plate-forme. On conserve en ce cas une équipe chez le client afin d’assurer le pilotage 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 la plate-forme, incluant toutes les actions à entreprendre pour résoudre chaque type d’anomalie, les règles de gestion de déploiement d’une nouvelle version, d’un patch ou d’un Hot Fix, les façons de recetter un déploiement ou une plate-forme (recettes logicielle et matérielle), etc. Un planning de supervision est défini pour les superviseurs, certains d’entre eux étant chez le prestataire et d’autres chez le client. Selon le niveau de service demandé, le superviseur peut soit rester à proximité d’un point d’accès durant toute sa garde, soit avoir accès à un ordinateur dans un temps donné. En cas d’incident sur la plate-forme, il est appelé (automatiquement ou manuellement) par l’hébergeur qui a détecté l’incident. Le superviseur suit alors les recommandations, en adaptant les solutions au cas précis rencontré. Lorsqu’on a besoin d’assurer un service en 24/7, l’organisation de la supervision devient rapidement un casse-tête, qui ne peut être résolu qu’en désignant un nombre suffisant de superviseurs. 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 plateforme 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. Les ressources 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 les questions complexes, nécessitant un investissement, ou encore pour les initiatives présentant un risque sur le service à fournir. Par exemple, le décisionnaire peut prendre la décision d’ajouter un serveur ou de modifier la configuration des serveurs afin d’obtenir un meilleur niveau de sécurité. C’est alors que l’utilisation de l’offshore se révèle particulièrement confortable en permettant de viser un taux de service élevé grâce à du personnel de haut niveau assurant la supervision des plates-formes. EN RÉSUMÉ Équipes offshore et supervision

Une équipe en offshore peut efficacement assurer la supervision de plates-formes de production et apporter un confort appréciable, tant pour la flexibilité, la couverture horaire et l’efficacité des services. Elle peut compléter efficacement une équipe locale en lui donnant les moyens de travailler efficacement. On prendra cependant soin de s’assurer que la sécurité mise en place sur les moyens de communication convient à la nature des services fournis par la plate-forme de production.

287

Conduite de projets informatiques offshore

Préparation des livrables Il existe plusieurs phases de préparation des livrables, dont la première consiste à extraire du référentiel tous les artefacts (éléments) correspondant à la version que l’on souhaite créer selon une baseline, pour peu que le référentiel soit géré correctement. On porte alors une 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érentiel donne sa pleine mesure pour isoler une version, y inclure la correction d’une anomalie isolée sur la version en production, préparer un Service Pack ou encore créer une version majeure. L’extraction de tous les éléments compatibles à assembler peut être effectuée à l’aide d’une procédure automatisée. L’étape suivante de préparation des livrables consiste en la compilation des sources extraits du référentiel, éventuellement pour chacune des plates-formes cibles. La compilation peut également être automatisée. On trouve ensuite les procédures de déploiement, le plus souvent configurables par un fichier 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-forme pour en assurer le bon fonctionnement ou vérifier que certaines règles de sécurité sont toujours correctement appliquées. Si le projet est suffisamment important, il convient de s’assurer que ces procédures sont gérées de façon industrielle et automatisée. L’automatisation permet de réaliser des déploiements rapides, sûrs et réplicables. On dispose ainsi d’une plate-forme de préproduction 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 travail de construction de la solution en offshore. L’équipe offshore peut préparer les scripts automatisant l’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. Lorsque c’est le cas, ils sont la source d’importants dysfonctionnements de l’accompagnement des livrables chez le client et sur les plates-formes. Le plus souvent, le client se concentre sur la création du produit et néglige les tests. Il ne traite les procédures de déploiement que si des problè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 du projet. Les projets complexes, multitiers et visant une compatibilité avec plusieurs familles technologiques, doivent être gérés avec beaucoup de soin. Même si les choix

288

Chapitre 14 – Intégration et déploiement

technologiques peuvent avoir un impact majeur sur le développement (choix des technologies, structuration de l’architecture, organisation des tests, etc.), on peut mettre en place 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 appliquées, les symptômes sont généralement les suivants : la plate-forme client se comporte différemment de celle du prestataire, les corrections d’anomalies ne sont pas isolées, on a des difficultés à stabiliser les livraisons sur les plates-formes, qui prennent un temps exagé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 et prendre en charge ces tâches administratives de gestion et de supervision des platesformes. 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.

289

Chapitre 15

Suivi de l’équipe offshore Les chapitres précédents ont posé les bases des procédures qui permettent d’organiser le processus de développement et de rassembler les informations de suivi du projet. Le présent chapitre aborde plus en détail le suivi de projet et propose plusieurs modèles utilisables dans des projets en offshore. Le suivi de l’équipe en offshore est évidemment un des facteurs clés de réussite des projets distants. Nous l’avons déjà abordé au chapitre 11 en insistant sur l’importance du reporting. Nous traitons surtout ici des documents les plus importants qui facilitent ce suivi 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 être ré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èrement sous la responsabilité du prestataire, lequel n’a aucune raison de communiquer plus d’information que nécessaire sur l’avancement du projet. Il s’est engagé à effectuer 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, le client n’a pas les moyens d’agir pour corriger les dysfonctionnements ni même d’étudier plus en profondeur la gestion du projet. • Mettre en place de procédures. La mise en place de procédures permet d’obtenir des informations 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 client en offshore pour gérer l’équipe distante et assurer une meilleure communication. Nous avons vu que la personne qui arrive chez le prestataire assure bien sa mission dans les premiers 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’il emploie une méthode itérative et que les points essentiels de la méthodologie sont

291

Conduite de projets informatiques offshore

raisonnablement implémentés pour permettre de communiquer les informations importantes. Rappelons que la méthodologie et le suivi des opérations doivent avant tout s’appuyer sur une bonne organisation des équipes et des responsabilités et que l’objectif de l’équipe est de fournir des livrables utilisateur et non pas uniquement des livrables personnels. 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éfauts majeurs 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 on ne 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êmes organisées. Lorsqu’un projet est bien géré, il est beaucoup plus facile de mettre en place des sondes objectives, dont la signification est entendue par tous de la même façon. On peut 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énements que l’on observe ont la même signification pour tous. Certaines mesures ne conviennent pas, sont ambiguës ou, pire, poussent à des comportements qui ne sont pas dans l’intérêt du projet. Par exemple, sachant que le client observe certains indicateurs, le prestataire peut vouloir en favoriser la bonne tenue. Une erreur fréquente consiste à construire un indicateur pour mesurer la qualité d’une équipe de développement à tenir ses engagements de livraison du 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, en sortie de test, avec un niveau de qualité minimal ou, si l’on veut absolument un événement plus proche des développements, la fin d’une recette unitaire vérifiée par l’équipe de test. Faute de cela, la livraison en sortie de développement sera peut-être réalisée dans les temps, mais avec un niveau de qualité tellement variable que l’on ne pourra pas en déduire de façon certaine une date d’intégration. C’est pourtant cette date, à laquelle le code 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 modules en cours de création. Cette estimation est proposée au jugé par les développeurs, alors qu’ils ne sont pas certains eux-mêmes de la valeur qu’ils communiquent. On constate parfois que des taux d’avancement régressent, comme si le développeur défaisait ce qu’il avait réalisé la veille. Des modifications des couches techniques nécessitent en fait de retravailler des couches fonctionnelles, et la prise en compte de ce travail mène à une estimation plus défavorable du temps restant, ce qui explique la régression apparente.

292

Chapitre 15 – Suivi de l’équipe offshore

Certains indicateurs en apparence simples fournissent ainsi des valeurs souvent trompeuses. En réalité, la plupart des mesures sont ambiguës et ne concordent pas avec ce qu’elles sont censées représenter. La raison à cela est qu’elles sont entachées d’une part d’interprétation. Les livrables, que l’on parle de programmes, de documents ou de formations, doivent être correctement définis pour qu’il n’y ait pas d’ambiguïté sur le niveau de qualité, qui est toujours difficile à définir, ni sur le travail encore nécessaire pour en disposer dans un état utilisable. La mesure elle-même, si elle est subjective, doit être définie clairement entre les participants. Par exemple, si l’on parle d’un niveau d’avancement du développement d’une fonctionnalité jusqu’à la livraison en production d’une fonction recettée, on peut dé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 atteint selon l’avancement du codage et des tests d’une fonction. Une autre erreur commune consiste à s’appuyer sur des mesures qui ne signifient pas la même chose chez le client et chez le prestataire. La collecte des informations se fait assez facilement 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 de chaque tâche et que certaines tâches montrent un retard significatif, le chef de projet du client qui suit la progression de ces tâches blâme l’équipe en retard. Pourtant, cette dernière n’a fait que respecter les nouvelles directives du client en corrigeant une fonctionnalité 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’est plus 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 infime de la situation en offshore. Lorsqu’un de ces managers demande à l’équipe en offshore d’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 de mesure 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’équipe distante 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 raisons qui 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’une période déjà ancienne, soit très éloigné de l’ordonnancement et de l’estimation réels des tâches. Les reproches que l’on adresse alors sont injustifiés et démontrent l’incapacité du client à suivre le projet. De très nombreux exemples de ce type démontrent que l’on ne peut suivre un projet sur la base de quelques indicateurs. La réalité ne peut être réellement perçue qu’en prenant en compte toutes les informations et en utilisant les bons indicateurs pour suivre au mieux 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 est toujours nécessaire pour se rendre compte de la situation réelle.

293

Conduite de projets informatiques offshore

Selon la phase du projet et les problèmes rencontrés en offshore, les indicateurs les plus importants pour comprendre la situation ne sont pas forcément les mêmes. On se concentre parfois sur les performances humaines et l’organisation des équipes, tandis qu’à d’autres moments ce sont les procédures qui sont au cœur de l’attention et que plus tard on s’attachera à la qualité de la production. Pour chaque préoccupation, le client choisit les indicateurs qui l’aident à mieux comprendre la situation et son évolution. Si ces indicateurs ont été peu utilisés, il faut les ajuster afin de s’assurer qu’ils ont la même signification pour ceux qui mesurent et ceux qui sont mesurés. Le client ne doit pas hésiter à ajouter certains indicateurs pour mieux suivre le détail d’une situation délicate, quitte à les abandonner une fois la situation résolue. Il ne doit pas non plus hésiter à remettre en question certains indicateurs trompeurs pour les remplacer 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étectent pas toujours des problèmes réels, pourtant connus de tous. Ils doivent donc être confrontés à la réalité pour s’assurer de l’information que l’on en tire. Il faut également s’assurer que les problèmes courants 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 être utilisés comme seule source d’information pour suivre efficacement un projet. Les mesures doivent avoir 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 suivre précisément les prestations de l’équipe en offshore. Aussi sophistiqués soient-ils, les indicateurs et mesures que l’on met en place ne sauraient rendre compte de toutes les situations. Certains processus peuvent être finement et efficacement suivis par une série d’indicateurs, tandis que des paramètres tels que la motivation des équipes ou une perte de productivité sont pratiquement impossibles à rapporter. Des indicateurs peuvent être considérés comme les effets d’une démotivation sans pour autant permettre de détecter les causes des dysfonctionnements. Pour mesurer pleinement ces sujets généralement complexes, il faut se rendre régulièrement chez le prestataire en offshore. Comme expliqué précédemment, les visites chez le prestataire doivent être ouvertes afin de construire et maintenir un esprit collaboratif. Il est beaucoup plus facile de détecter les dysfonctionnements les plus importants avec l’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 mettre en place, lorsque c’est possible, certains indicateurs spécifiques afin de suivre l’amélioration du dysfonctionnement de façon systématique, sur la base de sources d’information existantes ou créées spécialement pour suivre ce sujet.

294

Chapitre 15 – Suivi de l’équipe offshore

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 insatisfactions 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 actions correctives et des indicateurs de suivi lorsque c’est possible. Présentation de l’analyse qui est faite des indicateurs sur les sujets délicats et prise en compte des commentaires 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 et amélioration de ces procédures. Ces entretiens peuvent être personnels ou s’élargir à des groupes de personnes. Il est fortement recommandé d’organiser les réunions avec toutes les personnes concernées et de 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éveloppement est industrialisé, plus il est facile d’obtenir des mesures objectives et d’en automatiser la collecte. On peut s’appuyer sur les sources décrites au tableau 15.1 (les sources 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 livraison 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ération suivante

– Connaissance précise du contenu des réalisations à court terme et des objectifs de chacun – Essentiellement utile au jugement des réalisations personnelles

295

Conduite de projets informatiques offshore

Tableau 15.1. Sources des documents de suivi(suite) Source

Type d’information

Utilisation

Organigramme

Organisation hiérarchique et des responsabilités des collaborateurs

Distribution des quantités de travail disponibles, 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 workflows

– 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 constaté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écution/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 acceptable sur le développement (volumes)

Autres tests et informations 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 indicateurs physiques en offshore

Comportement des collaborateurs 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.)

296

Chapitre 15 – Suivi de l’équipe offshore

Tableau 15.1. Sources des documents de suivi(suite) Source

Type d’information

Utilisation

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ériodiques 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 constatés en offshore avec les coûts estimés chez le client

– Mesure de l’économie – Prise en compte des éléments d’inefficacité

Cette liste de sources d’indicateurs n’est pas exhaustive. De nombreux autres indicateurs peuvent 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 être confronté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 pour obtenir 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 documents les plus importants qui permettent de juger assez efficacement du travail en offshore et de sa progression.

Définition des objectifs Le document de vision permet de définir un objectif commun à toutes les équipes, afin que tous travaillent dans le même but. C’est cet objectif qui donne le sentiment d’appartenance à un projet, à une aventure. L’objectif définit le contenu du projet à réaliser pour une date donnée, avec des exigences de qualité et de stabilité. Il prévoit une évolution du contenu du projet afin de l’adapter en cours de réalisation aux contraintes fonctionnelles et techniques.

297

Conduite de projets informatiques offshore

La vision est exprimée par écrit afin d’être stable dans le temps, malgré les crises et les tensions. Faute de cela, elle pourrait évoluer en même temps que le projet, et les participants 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 technologies employées, les utilisateurs, etc. Il sert de socle pour concevoir le plan des itérations afin de répartir grossièrement les livrables de chaque itération, définissant ainsi le plan de progression du projet pour livrer en temps et en heure.

L’itération Le 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épendances entre 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 point de livraison régulier. Il permet de planifier l’itération suivante et de prendre en compte, si né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’on tire les conclusions les plus déterminantes. Toutes les conclusions s’appuient sur des livrables 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, permettant de 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 de travail à réaliser. On peut aussi juger de l’impact des éléments extérieurs qui sont venus perturber le déroulement de l’itération, que l’on parle de la réalisation de risques, de blocages dus à des failles dans les procédures ou des effets des changements de priorités ou des modifications du produit. Il peut être bon de construire des métriques sur ces éléments extérieurs et de les présenter aux personnes intéressées, notamment si certains retards sont dus à l’absence de réactivité du client, un cas très courant. On peut ainsi démontrer objectivement les effets de certains changements de spécifications ou d’absence de décisions sur le processus de développement. Par exemple, si un chef de produit ne répond pas aux questions des développeurs ou si des changements trop fréquents sont apportés aux spécifications, on peut en mesurer l’impact sur le développement et en étudier l’évolution dans le temps. Cette information peut être en partie croisée avec les modifications apportées aux cas d’utilisation et aux exigences qui sont conservées dans le référentiel. Les documents liés aux itérations permettent de suivre globalement l’avancement du projet et de communiquer aux intéressés les mises à jour des dates clés.

298

Chapitre 15 – Suivi de l’équipe offshore

EN RÉSUMÉ Gestion par itération

La gestion par itération permet de suivre périodiquement la progression d’un projet en constatant la disponibilité des livrables et en évaluant leur niveau de qualité. Elle donne le pouls du projet et confronte la capacité des équipes au réalisme des plannings.

Les plannings Les 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érations afin de prendre en compte l’expérience acquise. Il est directement lié au planning de charge, qui définit les ressources que l’on compte allouer à chaque itération à venir. Ces deux documents, mis à jour lors des résultats des itérations terminées, permettent de déterminer la façon de tenir l’objectif commun (ajouter du personnel si c’est possible et que cela ait un impact positif, retirer des fonctionnalités au produit pour le faire tenir dans le temps disponible et les reporter sur une version ultérieure, accepter de retarder la date de livraison, etc.). Ces plannings très généraux permettent de mesurer la progression globale du projet. Ce sont des documents directement utilisables par les managers et les utilisateurs qui ne souhaitent 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ération. Il permet de détecter régulièrement les problèmes rencontrés et de juger de la performance des individus travaillant sur le projet. Il est utilisé pour comprendre l’impact réel des événements extérieurs à l’équipe en offshore qui peuvent justifier les retards de livraison ou l’impossibilité d’atteindre les objectifs de l’itération. Ces plannings, le plus souvent suivis chaque semaine, permettent de descendre à un niveau de détail très fin et d’attribuer les responsabilités des manquements aux personnes qui les ont effectivement commis. 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émontrer l’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 sont plus utiles que pour gérer et comprendre le contenu d’une itération. La vision globale du projet est donnée par le plan de développement et le plan de charge, lesquels ont l’itération pour granularité. EN RÉSUMÉ Gestion des plannings par itération

En gérant des plannings avec l’itération comme unité de temps, on peut ajuster efficacement les hypothèses de charge et de priorité à partir des retours d’expérience des itérations. Seuls les plannings 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écifications 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.

299

Conduite de projets informatiques offshore

C’est une mesure qui vient compléter les informations sur l’avancement du projet en teintant les 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, qui peut 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 fonctionnalité ou par niveau de gravité et leur évolution dans le temps. C’est une mesure assez juste 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 (depuis la détection jusqu’à la correction) en vue de repérer les points de blocage. On peut ainsi mesurer par période de temps, par décisionnaire et par module le temps pendant lequel une anomalie reste en attente de traitement. On peut aussi repérer où agir pour accélérer le traitement de ces anomalies. On a trop tendance à accuser les équipes de développement alors que l’essentiel du temps s’écoule dans l’attente de la qualification de l’anomalie et de l’attribution de son niveau de gravité. La gestion des anomalies permet de vérifier que les dates promises de correction sont respecté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 divers outils, 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’évolutions fonctionnelles. • 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éveloppées et livrées sont plus coûteuses que les modifications réalisées avant que les développements ne commencent. Pour mesurer l’impact d’une demande de modification fonctionnelle, 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 plus souvent une charge de travail à chaque demande de changement qui permet d’en mesurer l’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 informations, comme l’origine de la demande de changement, et envisager comment on aurait pu l’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 apparaître une mauvaise conception du produit ou des erreurs fonctionnelles. Les données des outils de gestion du changement sont généralement gérées dans une base de

300

Chapitre 15 – Suivi de l’équipe offshore

données, qui, comme pour la gestion des anomalies, peut être exploitée par des applications telles 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 tel qu’il est vu par l’équipe de test. Elle rassemble des informations sur toutes les anomalies et demandes de changement connues sur le produit ainsi que le dernier résultat connu des tests de chaque fonctionnalité. Si l’on présente les résultats d’une campagne de tests sur une colonne, on peut suivre l’évolution de la qualité en comparant les colonnes. Une fonctionnalité testée positivement il y a longtemps peut être considérée comme probablement correcte, tout en sachant que plus le dernier test est ancien sur un code qui n’a théoriquement pas changé, moins on est certain de l’état de qualité réel de la fonctionnalité. Cette feuille, décrite au chapitre 13, présente de façon partagée la vision de l’équipe de test 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 ne sont pas toutes détectées, loin de là, mais les régressions majeures, comme celles qui résulteraient d’un module manquant, le sont. On essaie généralement d’automatiser les tests des Minimal Acceptance Sheets afin de valider rapidement la livraison d’une correction urgente devant être déployée aussitôt que possible. 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 feuille Excel), d’où l’on peut construire les rapports sur les performances et leur évolution dans le temps. Cette information peut être rapportée dans l’Acceptance Sheet, avec les résultats des tests fonctionnels. On peut ainsi surveiller dans le temps que les contraintes de performance 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 et devant être effectuée dans un environnement étroitement surveillé pour que les conclusions soient significatives. Bien que complexes, les tests de profiling (analyse du comportement de chaque composant de l’application) permettent d’optimiser les charges de chaque serveur des architectures multitiers. La collecte des informations est délicate, car il faut éviter de perturber les mesures avec des événements annexes. Les outils de profiling produisent rapidement un volume 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.

301

Conduite de projets informatiques offshore

Respect des procédures Des audits réguliers peuvent être pratiqués pour s’assurer de l’adhésion aux procédures et normes en vigueur. Selon le projet, on se concentre sur les éléments les plus importants (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 les aspects fonctionnels sont reportées immédiatement dans les documents de spécifications (cas d’utilisation) et, si nécessaire, dans l’architecture du produit. C’est un point important, qui permet de s’assurer que les tests effectués correspondent aux intentions de développement. • Respect des règles de codage. Vérification des règles de codage, souvent en utilisant des outils permettant de repérer la plupart des dérogations aux règles, notamment l’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és du projet, comme les tests unitaires, la prise en compte des tests, les règles d’écriture des cas d’utilisation, le respect des interfaces avec des produits ou des équipes extérieurs, etc. La liste des risques La liste des risques permet d’anticiper les risques susceptibles d’avoir un impact sur le projet. Construite de façon collaborative, cette liste peut aussi donner une vision de la perception de certaines personnes ou équipes. Certains risques proposés sont réels et indiscutables, tandis que d’autres démontrent une crainte plus qu’une réalité et permettent 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 les exécutables. Le suivi des anomalies et des demandes d’évolution peut être synthétisé dans un document 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 que l’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 du projet mais permet de comprendre sur quoi les équipes ont passé du temps (par fonctionnalité et par activité). C’est un reporting essentiellement manuel, par lequel les collaborateurs rapportent périodiquement le détail de leur activité selon un formulaire et des règles définis par le client. Ces informations sont parfois croisées avec les autres sources d’information afin d’en assurer la cohérence. Certaines règles de constitution sont déterminantes, car elles définissent la façon dont on va pouvoir utiliser le rapport.

302

Chapitre 15 – Suivi de l’équipe offshore

La périodicité permet de rendre compte d’une façon plus ou moins fidèle de ce qui s’est effectivement 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ésente une quantité de travail significative sur une semaine. Le rapport hebdomadaire constitue un 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, qui seront effectivement facturées, ou comptabilise-t-on les heures supplémentaires non facturées ? Les heures supplémentaires facturées sont évidemment prises en compte, mais les heures additionnelles, durant lesquelles les collaborateurs ont travaillé de leur propre 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 ce temps passé. Il se peut aussi que certains employés en fassent état pour demander des ajustements de leur salaire. La granularité temporelle des tâches a un impact important sur la lecture des rapports d’activité. Une granularité d’une heure offre une grande finesse pour des tâches relativement 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 les tâches correspondant à la stabilisation des livrables (corrections, évolutions mineures, optimisations) et de les séparer des tâches relatives à de nouveaux développements. On peut de la sorte mesurer la nature des efforts. Ce rapport peut être utilisé comme source d’information pour l’amortissement des frais de recherche et développement lorsqu’on travaille sur les règles de comptabilité américaines, qui sont employées par la plupart des sociétés d’envergure multinationa le. On doit alors amortir toutes les dépenses de R&D qui surviennent après les spécifications et les études de faisabilité. On détermine ensuite, selon les activités, celles qui se situent avant et après ces activités seuil. Si l’on utilise d’autres règles, on peut faire en sorte que les rapports d’activité identifient clairement les tâches amortissables et celles qui ne le sont pas. EN RÉSUMÉ Le rapport d’activité

Le rapport d’activité permet de construire des analyses précises du fonctionnement de l’équipe offshore. Le chef de projet peut calculer précisément le coût de certaines activités, ainsi que la productivité 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 de recherche et développement des tâches amortissables, si on le souhaite.

Les documents organisationnels Les documents organisationnels concernent essentiellement la structure des équipes et les procédures en place, notamment le suivi des décisions qui concernent des sujets organisationnels.

303

Conduite de projets informatiques offshore

L’organigramme définit en permanence les dépendances hiérarchiques, l’appartenance de 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 les collaborateurs, et l’on peut oublier qui ils sont et les confondre. Comme les collaborateurs du client ont moins l’habitude des noms étrangers, la mémorisation est moins aisée et la confusion fréquente. Il est bon de prévoir un organigramme contenant les photos de chaque 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 remaniements multiples qui surviennent en cours de projet. La méthodologie doit être aussi bien documentée que possible si l’on veut que tous les collaborateurs l’appliquent sans confusion. La méthodologie en elle-même ne fournit pas directement d’indicateur permettant de déterminer dans quelle mesure elle est bien appliquée. Le respect de la méthodologie provient essentiellement d’audits ciblés sur des domaines particuliers. Le document de suivi des décisions concerne généralement des sujets en marge du cycle de développement. On y trouve certaines décisions qui relèvent des engagements contractuels, comme la mise à disposition de salles climatisées. C’est un des seuls documents qui permette de suivre et de mesurer l’empressement du prestataire à appliquer les clauses du contrat. À ce titre, c’est un excellent indicateur de la mesure de l’attitude du 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 attentivement. Elle se vérifie essentiellement à partir du contrat (pour appliquer les tarifs qui conviennent à chaque personne), des documents indiquant la présence de chaque collaborateur durant la période étudiée et d’autres éléments facturés (matériels, abonnements, services, etc.). Les documents administratifs doivent permettre de construire un tableau des congés et absences 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 pour constater 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é, notamment avec des cartes d’accès, on dispose de toutes les informations sur les entrées-sorties permettant de contrôler le temps passé dans les locaux (mais pas nécessairement le temps passé à travailler). C’est parfois un indicateur intéressant dans les périodes de

304

Chapitre 15 – Suivi de l’équipe offshore

démotivation des équipes ou après des événements difficiles, comme la réduction brutale des effectifs d’une équipe. EN RÉSUMÉ Les documents administratifs

Les opérations chez le prestataire offshore sont cadrées par des documents administratifs qui permettent de vérifier les éléments intervenant dans la facturation, de définir les règles de fonctionnement administratif et de suivre la gestion des ressources humaines, notamment les vacances et les absences. Ces documents permettent de repérer les événements qui méritent une attention soutenue.

Mesure des économies On peut mesurer les économies réalisées grâce à l’offshore ou, si la gestion de l’offshore est désastreuse, leur surcoût. Un document rassemble les calculs de rentabilité des opérations en offshore. Les hypothèses servant aux calculs visent à ne jamais exagérer la profitabilité 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é des opé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 changements des spécifications, lesquels peuvent indiquer qu’une réflexion plus approfondie avant les développements pourrait apporter une économie significative. Un exemple de tableau de calcul de ces économies est donné en annexe. L’expérience montre qu’un tel tableau se complexifie rapidement si l’on souhaite obtenir des mesures plus précises sur des sujets qui intéressent directement le management. Par exemple, on peut essayer de mesurer des activités de correction d’anomalie, de typer les services pour en extraire certaines tâches réputées non productives, comme l’informatique interne, ou bien 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 économies et de mesurer leur évolution. Ce document permet aussi de communiquer efficacement sur ce sujet et d’éviter les rumeurs.

Automatisation des documents Il est recommandé autant que possible de créer l’essentiel des documents de suivi de façon automatisée. Nous avons décrit dans le cours de l’ouvrage la plupart des sources objectives d’information disponibles. Certaines sources sont alimentées par l’utilisation des outils de développement (référentiel, gestion du changement), tandis que d’autres sont nourries par des comptes-rendus manuels (activités, progression dans le planning

305

Conduite de projets informatiques offshore

d’itération, iteration assessment) de façon périodique. On trouve également des informations sur 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é de construire un tableau de bord permettant de rassembler l’accès à toutes ces informations et de construire automatiquement les rapports les plus usités. Certains outils de gestion de projet permettent de construire de tels tableaux de bord. Il est aussi possible de les construire 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 informations les plus couramment utilisées sont présentées sous une forme pratique, correspondant à une utilisation confortable. Les autres informations, que l’on utilise moins souvent, 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çue pour être exploitée par une application de type Access ou Excel afin de construire les tableaux recherchés et fournir des présentations graphiques ou des alertes. On dispose ainsi 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 des outils 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 automatiques sont agrégées avec des mesures dont la source requiert une intervention humaine (gestion des 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çon automatisée afin de pouvoir disposer de la vue souhaitée et de définir les déclencheurs d’alerte qui permettent 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, peuvent en ralentir la progression. Le client presse l’équipe distante à rattraper le retard qu’elle aura presque toujours accumulé et valorise avant tout la rapidité de développement. Bien souvent, les procédures relatives à la sécurité sont oubliées, tant par l’équipe distante que 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 convient de mettre en place les indicateurs adéquats, lorsque c’est possible, pour en vérifier l’application. C’est d’autant plus important lorsque le client presse le prestataire d’accroître toujours plus la productivité et semble se désintéresser de ces règles, alors qu’il les considère par ailleurs comme essentielles. Par exemple, si un accord de confidentialité doit être signé par chaque collaborateur, on peut construire un indicateur signalant le pourcentage d’accords signés par rapport au nombre de collaborateurs, cet indicateur devant être à 100 lorsque la procédure est respectée. Si l’on souhaite que le réseau soit isolé du réseau local du prestataire, on

306

Chapitre 15 – Suivi de l’équipe offshore

demande à la personne responsable d’exécuter certaines procédures de scan de ports, de lancement de listeners, etc. Périodiquement, un audit par échantillonnage peut être effectué pour s’assurer du respect des 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 offshore pour être ignorée une fois que le projet a démarré. Il convient de mettre en place des indicateurs de bonne 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. Bien entendu, les phases de mise en place d’une équipe nécessitent de se déplacer plus souvent 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 indicateurs de progression et de suivi du projet, puis on les améliore à chaque itération afin qu’ils soient toujours plus représentatifs. Le client se concentre pour sa part sur les sujets fonctionnant moins bien ou sur les disciplines qui émergent en fonction de l’avancement du projet, comme le déploiement. Vers la fin du projet, on se préoccupe surtout de la stabilisation du projet et de la vision de son état de qualité. Dans tous les cas, les visites sur place permettent de se rendre compte de la validité des indicateurs et de la situation réelle chez le prestataire. Lorsqu’une différence trop importante 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’on souhaite en faire. Au commencement, on ne mesure que les processus de base, puis on y ajoute 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 certains indicateurs, qui prennent une importance prédominante, masquant la réalité de la progression du projet pour en grossir certains aspects et en ignorer d’autres. Les indicateurs sont mis à jour régulièrement. Les conclusions partagées par les intéressés et un suivi sur le terrain permettent de disposer d’une perception efficace de la santé du projet.

307

PARTIE

4

Annexe Modèles et exemples Cette 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 et pouvant jouer le rôle d’aide-mémoire. Ces listes ne sont pas exhaustives et peuvent ê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 servir de source d’inspiration pour créer ou améliorer les documents que le lecteur peut 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éralement extraits d’outils permettant de traiter les informations qu’ils contiennent d’une façon structurée. L’introduction de chaque document rappelle le chapitre qui y fait référence. Le lecteur 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 permettent d’évaluer la nature du projet offshore et d’en estimer la difficulté. Le contenu détaillé des questions et l’impact des réponses sur les opérations en offshore sont exposés dans ce chapitre.

Conduite de projets informatiques offshore

Tableau 1. Évaluation du projet en offshore Importance de répondre à cette question

Domaine

Sujet à traiter

Décisions pour utiliser l’offshore

Quelles sont les raisons qui poussent la société à soustraiter en offshore ?

3

Implication en offshore

Quels seront les projets confiés en offshore ?

3

Quel pourcentage de développements sera probablement réalisé en offshore dans le long terme ?

3

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

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

Veut-on réaliser un projet test ou souhaite-t-on démarrer sur un projet réel ?

3

Quels enseignements espère-t-on du projet test ?

3

Quel serait le projet test ?

2

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 manager 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

Budget

Sécurité

Essai

Management

310

Réponse

Annexe - Modèles et exemples

Tableau 1. Évaluation du projet en offshore(suite) Domaine

Prestataire offshore

Méthodologie et procédures

Formation et conseil

Outils de suivi de projet

Sujet à traiter

Importance de répondre à cette question

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

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 ?

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 collaborateurs en offshore sur les aspects fonctionnels, organisationnels et techniques ?

2

Quel accompagnement choisit-on pour faire correctement 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

311

Réponse

Conduite de projets informatiques offshore

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 facturation mensuelle. Le nombre de jours ouvrés du mois est rappelé afin de lever toute ambiguïté, particulièrement lors d’une étude future. Le pourcentage correspond à l’allocation du collaborateur sur le projet. Tableau 2. Facturation des ressources humaines sur une base mensuelle Personnel

Date

Jours travaillés

Travail supplémentaire

Tarif mensuel de base (en dollar)

Pourcentage

Facturation

Position

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

Nom

1

#

Catégorie

20 jours ouvrés dans le mois

6 7

Le tableau 3 fait partie du rapport accompagnant la facturation. Il permet de suivre les mouvements du personnel, notamment les validations des embauches.

312

Annexe - Modèles et exemples

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 base

Pourcentage d’allocation

Date de départ

Position

Coût de base

Pourcentage d’allocation

date

Developer

$2 200

100 %

Nouvelle position

Commentaire

Départs Nom BULGAKOV, Vitaly

Validation de période d’essai Nom BURAK, Igor

Date de validation date

Position Technical Tester (Test Team)

Changement de poste Nom VALAKHANOVICH, Alexandra

Date d’effet date

Position précédente Developer

Development Team Leader

Promotion

Le tableau 4 permet de suivre les heures supplémentaires effectuées par les collaborateurs en offshore. Il détaille notamment les heures supplémentaires approuvées et garde trace des raisons qui ont motivé cette décision.

313

Conduite de projets informatiques offshore

Tableau 4. Heures supplémentaires Heures/jours supplémentaires

Février 2004

Date

Jours travaillés supplémentaires

SIGOV, Alexey

Date 1

0,5

RBO

Urgent deployment of bug fix

BULGAKOV, Vitaly

Date 2

0,5

NOT Approved

Not requested by management

Nom

Approuvé par

Commentaire

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 prestations en offshore. Ces sujets sont traités en détail au chapitre 9. Le tableau récapitule les options que le client peut retenir pour définir le contrat. Le client peut aussi préférer traiter certains de ces points en dehors du cadre contractuel. 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

314

Annexe - Modèles et exemples

Tableau 5. Options du contrat avec le prestataire(suite) 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é.

315

Conduite de projets informatiques offshore

Tableau 5. Options du contrat avec le prestataire(suite) 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écessaire 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

316

Annexe - Modèles et exemples

Tableau 5. Options du contrat avec le prestataire(suite) 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.

Suivi des risques Le tableau 6 donne un exemple de feuille de suivi des risques, un sujet abordé en détail au chapitre 10. Le tableau associe à chaque risque un responsable, qui a pour tâche de suivre 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 correctives permettant d’éliminer ou de réduire la portée du risque. Chaque action peut être validée ou rejetée par le management, ce dont on garde trace pour une éventuelle analyse ultérieure.

317

Période de réalisation du risque

Responsable

Date de détection

Domaine

ID

39 Tech 10/01/ VBA Court 2005 terme

IGR, PGA, VBR 7

Personnes/ équipes impliquées Niveau de risque

Tableau 6. Suivi des risques État courant

Niveau de risque

Probabilité de réalisation 33 % 2,31 En attente de validation par VBA

Description Les services de développement de l’interface homemachine qui devait être fournie par l’équipe technique doivent vérifier que les choix techniques sont réalistes, ce qui n’est pas sûr à ce jour.

Effets anticipés Si des problèmes sont rencontrés et s’ils mènent à choisir d’autres technologies, on peut anticiper un retard de deux mois.

Plan de repli Nous pouvons choisir de revenir à l’ancienne version des outils IHM.

Propriétaire des actions correctives

Actions correctives

Correction ID

318

39-2 Réaliser en paralIBA lèle deux approches différentes visant à atteindre le même objectif. Le choix final sera fait lorsqu’on aura la visibilité suffisante.

39-1 Construire un test SMA de faisabilité pour analyser les performances et estimer la réalité du risque

État de l’action

Date de fin 10/03/2005

Rejeté par le NA management

En attente de validation par VBA

Conduite de projets informatiques offshore

Domaine

ID

40 RH

Période de réalisation du risque

Responsable

Date de détection

15/01/ PLA Moyen 2005 terme

4

Personnes/ équipes impliquées Niveau de risque

ALL

Niveau de risque

90 % 3,6

Probabilité de réalisation

Tableau 6. Suivi des risques(suite) État courant La correction 40-1 est appliquée.

Description Au moins 40 % des développeurs et des testeurs seront probablement absents en août, juste avant la date d’une release majeure.

Effets anticipés Comme le planning est serré, on peut s’attendre à des problèmes de qualité ou de retard. L’absence de certains testeurs rendra le produit particulièrement difficile à valider.

Propriétaire des actions correctives

Actions correctives

Correction ID

Plan de repli

319

40-2 Gonfler les équipes NGI avant août de façon à conserver une pleine capacité de production en août

Travail sur 40-1 Anticiper les dates NGI le contenu de vacances et des itéraannoncer que les tions pour vacances ne cette peuvent être prises période et en août. calcul des délais. Le scope fonctionnel de la release risque d’être réduit.

État de l’action

Date de fin 01/03/2005

Rejeté par le NA management

À tenter

Annexe - Modèles et exemples

Conduite de projets informatiques offshore

Suivi des décisions en offshore Le tableau 7 illustre le suivi des décisions prises en offshore afin d’éviter qu’elles ne soient pas traitées. Ce sujet est traité au chapitre 11.

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 date serveur et mettre à jour les procédures de déploiement

EBO

Définir un budget pour cette dépense non budgétisée et le faire valider par la direction financière

11

PROC

date

SMA

AVG

Définition d’une nouvelle procédure pour la demande de vacances

Une nouvelle date procédure doit être créée.

ELY

Une trame de la date procédure est proposée pour validation par le client.

date

FLI

Le processus date complet est proposé pour validation.

ID

Date de fin

IMA

État

Description

date

Date de l’action

Importance

IT

Actions proposées

Responsable

10

Domaine

Date de soumission

Responsable de l’action

Tableau 7. Décisions générales et suivi des décisions

date

Gestion des exigences Le tableau 8 présente la façon dont on peut définir certains attributs pour chaque exigence afin d’établir les priorités de réalisation ou le suivi de chacune d’elles. La gestion des exigences est souvent traitée dans un outil dédié permettant d’y associer un workflow et une traçabilité entre divers éléments. Ce tableau est mentionné aux chapitres 11 et 12. Il comporte des informations sur la planification, qui, ajoutées à la charge estimée, permettent de construire un planning par

320

Annexe - Modèles et exemples

itération (charge, prédécesseur, démarrage itération, itération cible, release). L’information sur l’avancement (état d’avancement) de la réalisation de l’exigence permet de communiquer sur son état de disponibilité. Un marquage, par exemple, par des couleurs peut identifier si l’avancement est conforme à la planification ou en retard. Enfin, certains attributs, comme la priorité, le risque, la charge (complexité) et la stabilité, permettent de dé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 les informations les plus récentes.

18936237266 M1 M1- Détruire DA- un 01 compte

Destruc6.1 6.1 V1.12 MOYEN 15/01/ ANALYSE 7 tion d’un 2006 compte et mise à jour des tables liées

Prédécesseur

Stabilité du besoin

Risque technique

Charge

État d’avancement

Disponibilité des specs

Priorité

Release

Itération cible

Démarrage itération

Description

Nom

Code

Module

ID

Tableau 8. Gestion des exigences

FAIBLE

HAUTE Socle technique SC v1.11

18936237267 M3 M3- Contrôle Contrôle 6.2 6.3 V1.12 HAUTE CT- de saisie de saisie 06 de la de la foncfonction tion F122 F122

22/02/ DEV 2006 50 %

4

FAIBLE

HAUTE Socle technique SC v1.11

18936237268 M2 M2- Contrôle Contrôle 6.2 6.3 V1.11 HAUTE CT- de saisie de saisie 04 de la de la foncfonction tion F128 F128

18/01/ TEST 2006

9

FAIBLE

HAUTE Socle technique SC v1.11

Iteration assessment Le tableau 9 illustre la façon dont les résultats d’une itération peuvent être consignés dans le rapport d’iteration assessment. Ce sujet est abordé au chapitre 12. Les effets des ré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.).

321

Fin d’itération

Itération de début

Description

322

Réalisation des exigences 123, 128 et 132

6B 6B 11.1 MEDIUM 26/01/2006 50 %

6A 6B 11.1 MEDIUM 18/01/2006 80 %

Release

Réalisation complète du UC 12 de gestion des nouveaux clients

26/01/2006 100 %

Date de livraison

6B 6B 11.1 HAUTE

% de réalisation en fin d’itération

Traitement du change request CR1287

Priorité

Objectifs Effet du retard

Raisons du retard Les use cases spéciLivraison non fiant l’exigence 132 ont effectuée été livrés en retard, ce qui a mécaniquement induit un retard sur les développements.

Dépends de la livraison Livraison non de la nouvelle version effectuée des services techniques qui ont été livrés avec retard. La réalisation n’est pas en retard autrement.

Assessment Action corrective Meilleure planification des exigences. Notifier le chef de produit VBA de l’effet de ces retards

Rattraper le retard sur l’itération suivante

Commentaire du client Le chef de produit est tombé malade, et personne n’a averti les équipes des retards induits. Chaque chef de produit doit avoir un « backup ».

Commentaire

L’équipe n’a pas été tenue au courant du retard pourtant prévisible de la livraison des services techniques.

Commentaire du prestataire

Tableau 9. Exemple d’iteration assessment

Conduite de projets informatiques offshore

Description

323

Réalisation complète de l’exigence 156

Livraison de la nouvelle version des services techniques

Itération de début

Release

Fin d’itération

6A 11.1 HAUTE

Date de livraison 15/01/2006 90 %

% de réalisation en fin d’itération

6B 6B 11.1 MEDIUM 23/01/2006 90 %

5F

Priorité

Objectifs Raisons du retard

Retards sur toutes les équipes fonctionnelles

Effet du retard

Les tests ne sont pas Livraison non terminés du fait d’allo- stabilisée cations supplémentaires sur la validation des services techniques.

Des bogues ont été découverts, qui ont rendu impossible l’exploitation de ces services techniques par les équipes fonctionnelles.

Assessment Action corrective Prévoir une période plus importante entre la fin du développement et l’exploitation par les autres équipes

Prévoir une période plus importante entre la fin du développement et l’exploitation par les autres équipes

Commentaire Commentaire du prestataire

Tableau 9. Exemple d’iteration assessment(suite)

Annexe - Modèles et exemples

Commentaire du client

Conduite de projets informatiques offshore

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 construit dans 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 Microsoft Project permettent d’ordonner les tâches selon leur priorité. Le modèle note clairement les livrables externes, dont certaines tâches de l’équipe dépendent, et isole les tâches de correction et d’évolution de features des tâches réalisant de nouveaux développements afin de 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 collaborateurs prévoient le temps nécessaire à leur création et ne considèrent pas que la livraison d’un exécutable est le seul objectif. Les livrables dont d’autres équipes dépendent sont spécifié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 de disposer de tous les types de tâches. Les collaborateurs devraient mesurer une utilisation des ressources de 100 % une fois le planning finalisé. Ces plannings peuvent être consolidés, mais c’est en définitive peu utile. Les chefs de projet préfèrent suivre la progression du travail par équipe. On peut créer des macrofonctions ou de petits programmes permettant de reporter dynamiquement les jalons de dépendance d’un planning sur les plannings dépendants. Lorsqu’un chef d’équipe modifie 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. On peut remarquer l’état de qualité de chaque feature pour chaque build. Chaque colonne repré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 ou moins importante).

324

Tableau 10. Planning détaillé d’une itération

Annexe - Modèles et exemples

325

Tableau 11. Exemple d’Acceptance Sheet

Conduite de projets informatiques offshore

326

Annexe - Modèles et exemples

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 projet en 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 critique qu’elles auraient été définies d’une façon favorable à l’offshore. Les « coûts totaux constatés en offshore » doivent inclure toutes les dépenses annexes, y compris les déplacements 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 fait de changements tardifs des spécifications », de façon à faire prendre conscience aux utilisateurs des coûts induits par ceux-ci.

327

Projet

120 000

320 000

Projet B

Total

328

25 000

32 000

65 000

122 000

12 000

8 000

20 000

142 000

Module C-1

Module C-2

Module C-3

Total projet C

Module D-1

Module D-2

Total projet D

Coût total du travail de réalisation

Réalisations courantes

200 000

Coût total constaté en offshore

Projet A

Projets terminés

Nombre de jours de travail pour l’offshore 1 420

200

80

120

1 220

650

320

250

1 200

2 000

Estimation du nombre de jours de réalisation chez le client 1 345

195

75

120

1 150

630

300

220

1 000

1 500

Coût réalisation chez le client 366 818

53 182

20 455

32 727

313 636

171 818

81 818

60 000

681 818

272 727

409 091

Économie réalisée 224 818

33 182

12 455

20 727

191 636

106 818

49 818

35 000

361 818

152 727

209 091

39 %

38 %

39 %

37 %

39 %

38 %

39 %

42 %

44 %

49 %

Ratio d’économie

Tableau 12. Modèle de calcul des économies réalisées en offshore (en euro) Jours perdus du fait de changements tardifs des spécifications 10

0

63

0

10

220

100

120

Proportion des changements 13 %

0%

10 %

0%

5%

10 %

8%

Coûts des changements tardifs 1 067

0

6 500

0

1 136

28 000

12 000

16 000

Conduite de projets informatiques offshore

Commentaire

329 6 000

7 000

Coût moyen gestion de projet client

182 000

Total

Coût moyen du mois/ homme client

12 000

Autres frais client (voyages, etc.)

Valeurs et hypothèses

28 000

Suivi de projet chez le client

1 500

80

1 345 366 818 184 818 50 %

Tableau 12. Modèle de calcul des économies réalisées en offshore (en euro)(suite)

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

83

Jours perdus du fait de changements tardifs des spécifications

Proportion des changements

8 703

Coûts des changements tardifs

Commentaire

Annexe - Modèles et exemples

Index confidentialité 122, 178 conseil à l’offshore 148-149 contrat 173 communication et références 205 considérations générales 173 de partenariat 168 devise de facturation et risque de change 180 gestion des équipes 198 des factures 194 mode de fonctionnement 85 propriété intellectuelle 175 régie 92 rupture du 206 services du prestataire 179 termes de paiement 194 transparence des forfaits 92 coûts 16, 40, 166 augmentation brutale 127 comparaison des 16 d'une filiale en offshore 82 d’un collaborateur de l’offshore invité 77 définition du budget 140 des prestations 166 et productivité 41 joint-venture 87 marge 86 mesure des 53 vacances 76

A Acceptance Sheet 273, 301 Asie 38

B Bangalore 43 BrainBench 33, 43, 160 budget 140

C change 180 chef de projet 14, 61 chez le client 146 et petits projets 237 choisir le projet à externaliser 97 communication 205, 216 avec le client 235 sur les projets offshore 65 comparaison d’une filiale et d’un prestataire offshore 82 des partenariats 87 des sources des spécifications 98 du choix des ressources 25 compétitivité 10 complexité technique 102 conditions de travail 75

331

Conduite de projets informatiques offshore

locale 56, 64 modes de gestion 88 noyau central 165 offshore (suivi) 291 profils 227 qualité de l’ 20 risques sociaux 133 rôles 22, 60, 230 salaires 53, 60 Europe de l’Est 38 évaluer son projet pour l’offshore 137 externalisation 64

D décalage horaire 89, 155 délocalisation 7 déplacements en offshore 44, 159 déploiement 63, 281 chez le client 285 tests de 277 développement 52 nearshore 29 offshore 29 offsite 29 onsite 26 différences culturelles 26, 33, 78, 158 documentation 59 documents administratifs 304 automatisation 305 fonctionnels 98 organisationnels 303

F facturation 181 des collaborateurs 185 retards de paiement 130 filiale 81 flexibilité des équipes 17 fonctionnement de l’offshore 79 fondations techniques 111, 283 forfait 25, 80, 90 dangers 91 définition 10 sous-projets 185 suivi de projet 204 formalisation des spécifications 98 formation 149, 171, 189 langue de travail 33

E éducation 42 éloignement des équipes 30 émigration 73 équipe choix de l’ 153 choix du manager 145 constitution 168, 199 cumul de postes 52 de recette 63 doublement de l’ 161 éloignement 30 embauche des collaborateurs 169 flexibilité 200 formation 171 gestion d’ 17 invitation 77 isolement 201

G géants de l’offshore 45 gestion de la qualité 269 de projet 209 communication 216 méthode itérative 220 objectifs de management 213

332

Index

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

invitation 77, 159 isolement des équipes 124 itération 220, 298 analyse 263 planning détaillé 261 release plan 260

J joint-venture 87

L label qualité 86 langue de travail 31, 160 licences 131, 192 litiges 116 livrables (préparation des) 288

M Maghreb 38 management 84 manager 145 marge du prestataire 86 MAT (Minimal Acceptance Test) 272 mentalités 35 mentor 145, 230, 234 mesure des coûts 53 méthode 21, 148, 243 analyse de l’itération 263 automatisation des rapports de suivi 266 documentation 59 efforts de gestion 110 favoriser la motivation 253 gestion de la documentation 252 de versions 258 des corrections 256

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

333

Conduite de projets informatiques offshore

outsourcing avantages 15 principes 5

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 Microsoft MSF (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

P paiements du client 130 pays de l’offshore 37 personnel en régie 28 perte d’emploi 14 planning 255, 299 premier projet 104 prestataire 44 au forfait 80 choix du 153 demande d’informations 162 questions à se poser 154 collaborateurs 51 communication avec le client 235 contrat 168, 173 culture du pays 158 décalage horaire 155 devise de facturation et risque de change 180 évaluation du 143 importance de la localisation 89 joint-venture 15 langue de travail 160, 179 leaders locaux 47 litige 116 localisation 155 marges 86 modes de fonctionnement 85 références 167 services 179 complémentaires 190 visites au 294 primes 60, 237 procédures 148, 283 processus de développement 243 productivité 42

N nearshore 25

O offsite 11, 25 onsite 11, 25 organigramme 304 outils de suivi de projet 150

334

Index

profils 227 projet ambitieux 106 de fondations techniques 111 de reverse-engineering 107 de test 104, 143 module périphérique 105 outils de suivi 150 petit 109 préparation 135 typologie 107, 112 propriété intellectuelle 117, 120, 175, 207

ressources humaines 227 rétention des sources 118 reverse-engineering 99, 107 RFI (Request For Information) 162 risque 115 politique 131 social 133 sur les livraisons 258 tests et mesure du 277 rôle 229 attribution 22 spécialisé 60 RUP (Rational Unified Process) 21, 31, 100, 149, 243

Q S qualité 21, 218, 299 des ressources 20 gestion de la 269 questions stratégiques 138

salaires 38, 60, 68, 202 sécurité 122, 142, 192, 306 des locaux 77 serveur de messagerie 124 sous-projet au forfait 185 spécifications 98 stabilité politique 44 suivi de l’équipe offshore 291 de projet 291 iteration assessment 298 mesure des économies 305 plannings 299 qualité 299 rapport d’activité 302 documents de 295 supervision des plates-formes 287 système éducatif 160

R rapport d’activité 302 de suivi 204 Rational 21, 123 ClearCase 122, 150 recette 63 références 205 référentiel 101, 122, 150, 246 gestion des streams 247 régie 25, 92 coût 28 définition 10 forfaitée 94 partage des responsabilités 93 release plan 259 reporting 292 responsable fonctionnel 62

T Telelogic 123 termes de paiement 194

335

Conduite de projets informatiques offshore

terminologie 9, 10

U

tests 21 automatisation 22

universités 21, 42

chez le client 286

V

couverture des 276 de déploiement 277

vacances 76 validation 103 vocabulaire 13

enrichissement des 275 et mesure du risque 277 fonctionnels 271 transversaux 274

W

fonctions des outils 251 gestion des 251, 269

workflow 21, 245, 250

intuitifs 275 MAT (Minimal Acceptance Test) 272

X

techniques 276 unitaires 266, 270

XP (eXtreme Programming) 21, 31, 100, 149, 243

travail en offshore 67

336