A l'occasion d'un ou plusieurs projets, vous avez eu recours à une équipe de développeurs offshore. Quels enseignements tirez-vous de cette expérience ? Participez
Développement de la couche IHM d'une plate-forme pour téléphone portable. Patrice Vanzini, Le Mans
Patrice Vanzini
Pour quel(s) type(s) de chantier avez-vous eu recours à l'offshore ? Fin 2005, la société qui m'employait a décidé de remplacer son ancienne plate-forme logicielle pour téléphones mobiles (gsm / gprs /edge). Toutes l'équipe software a donc du faire face à une feuille blanche pour démarrer toutes les phases du développement. Un projet très ambitieux donc. A ce moment là, on m'a confié la direction du développement de la partie mmi (Man Machine Interface). Le choix a été de faire appel à un prestataire indien avec qui je travaillais déjà depuis quelques années sur de "petits" projets. Le travail en amont pour préparer ce développement délocalisé a été conséquent car les couches logiciels (framework graphique, api de téléphonie, etc... ) sur lesquelles devaient reposer la mmi était également en cours de développement. Une grande rigueur de nos architectes a donc été indispensable afin de designer le logiciel dans son ensemble et de le découper en plusieurs versions incrémentales en tenant compte des contraintes de chacune des couches logicielles. Une fois ce découpage fait, j'ai pu lancer avec le sous-traitant l'étude du planning et la définition des différents livrables (25 au total) tout en ce mettant d'accord sur les charges de travail associées. Cette étude conjointe du cahier des charges, du planning, des couts, des délais, etc... Était l'étape indispensable afin d'aboutir à la mise en place d'un forfait avec le sous-traitant (engagement sur le résultat avec un cout fixe pour résumé). La phase de réalisation du projet a donc pu démarré et l'équipe du sous-traitant est montée de 10 personnes au démarrage à 60 personnes au sommet de l'activité. La phase de développement pure à durée 7 mois. Une centaine de composants/modules développés, autant de documentation de design et autant de rapports de tests. Je me suis entouré d'un comité de pilotage pour gérer tout cela (des membres de mon équipe local que j'ai sélectionné en fonction des compétences requises). Indispensable.
Quels sont les avantages et inconvénient de l'externalisation lointaine ? Les avantages sont multiples. En dehors du cout qui est très compétitif, le premier avantage que je vois est la disponibilité de nombreux ingénieurs très compétents et à même de couvrir tous les besoins d'un projet aussi complexe que celui là (architecture, plan de test, développement,... ). D'autre part, cette disponibilité sur le marché permet également d'enviseager de fort ramp-up en terme de ressources sur des délais relativement court. Ce ramp-up ne peut se faire de façon controlée que par le travail préparatif fait en amont par moi-meme et mon équipe. Essayez de lancer une équipe de 60 personnes sans avoir préparé chaque étape du projet, et, que se soit en local dans votre entreprise ou en délocalisé, le résultat sera un échec. L'organisation cmm niveau 5 de nombreux prestataires indiens garantie également ce passage en douceur. Chaque nouvel individu incorporant l'équipe connait immédiatement sa "place" et le role qu'il doit occuper dans le projet. C'est très appréciable et cela permet une formation au "fil de l'eau" des nouveaux arrivant très efficace. Le dernier avantage et pas des moindre, c'est l'enthousiasme de chaque collaborateur indien pour le projet. L'implication est totale et si il faut finir le boulot le week-end pour atteindre un milestone, c'est fait sans difficulté et "avec le sourire". Dure d'imaginer cela en France... Il m'est bien sur, à moi meme arriver de travailler le week-end à Mumbai pour accompagner l'équipe dans son effort lors d'importantes livraisons; -)
Le plus gros inconvénient, et celui qui m'a posé le plus de problème, est l'acceptation du code par les développeurs de mon équipe. Les remarques du genre: "c'est vraiment du code de cochon" quand une ligne de code défectueuse était détecté parmi 10 000 lignes... Ce code développé de façon lointaine était la base des futures développements de ma société et devait donc revenir dans les mains des développeurs de mon équipe pour en assurer l'évolution et la maintenance. Chaque développeur n'apprécie que son propre code et a du mal à mettre les mains dans le code de quelqu'un d'autre... De plus, le développeurs français reste "fière" et a tendance à sous-estimer les compétences de développeurs indiens... Surtout quand il s'agit de développeurs très expérimentés comme ceux qui composaient mon équipe. Les autres inconvénients sont bien sur le pilotage qui demande une forte implication de la part de la société ou équipe qui fait appel à un sous-traitant lointain sur ce genre de projet. Il faut mettre en place de nombreux "garde-fous" et apporter un support conséquent aux phases de design et de développement. De nombreux déplacement sont à prévoir et sont indispensable afin de créer une synergie entre les deux équipes.
Quels conseils donneriez-vous à des décideurs souhaitant se lancer dans une entreprise équivalente ? Un projet d'externalisation de développements logiciels ne se prend pas à la légère. Il ne suffit pas de dire que l'on dispose d'un cahier des charges pour lancer le projet. Un e-mail et c'est fini jusqu'à réception ! Ca ne marchera pas. Chaque erreur dans la préparation (cahier des charges, planning, plan de tests, environnement de développement,... ) sera lourde de conséquences. Sur un gros projet (350 h/mois) comme celui que l'on a mené, chaque hésitation, chaque "petit" problème dans l'environnement de développement,... Peut bloquer le prestataire une journée! Et une journée à 60 personnes, cela coute cher. Et le risque est que les développeurs prennent des initiatives pour contourner le problème et de retrouver en bout de projet avec un nombre incalculable de "petit" problèmes qui seront resté enfouis par manque de réactivité du donneur d'ordre. Un tel résultat entrainera une baisse considérable de la qualité des livrables et une mise au point lourde et douloureuse... Donc, la 1ère chose est de s'assurer que l'on met bien, en interne, les moyens nécessaire à la réussite du projet. La seconde est de donner des objectifs réalistes aux prestataires. J'ai déjà entendu ce genre de raisonnement: "Ils ont une équipe de 60, le temps d'exécution peut être diviser par 60. Et si il n'y arrivent pas, ils ont qu'à mettre plus de monde sur le pont" Grave erreur de nouveau, ne donnons pas des délais de réalisation qu'on ne serait même pas capable de tenir en interne avec le même effectif ! Surtout que de nombreuses compagnies indiennes vont répondre qu'elles peuvent le faire pour décrocher le contrat. A partir de la, vous avez tout faux et le projet sera un échec (le délai sera surement tenu mais la qualité ne sera pas au rendez-vous) et préparez vous à communiquer a votre dg un retard d'une semaine toutes les semaines sur la livraison finale... Pour moi, la cause principale des échecs connus lors de l'externalisation d'un projet est principalement du fait du client qui sous-estime la tâche de préparation et de suivi de son projet. Ceci étant dit, de nombreux succès attendent les décideurs qui intégrerons cette contrainte dans leurs projets d'externalisation ! Les qualités humaines et techniques des ingénieurs indiens sont excellentes et ne demandent qu'a être utilisées de façon rationnelles. Dans, l'intérêt des deux parties...
Développement de la couche IHM d'une plate-forme pour téléphone portable. 
Accueil
