Offshoring/Backshoring, l’art de tourner en rond ?

Après avoir attisé les craintes les plus irrationnelles (certains n’ont pas hésité à comparer l’industrie informatique à l’industrie textile), le Offshore a quitté les unes des journaux du secteur. Il n’en reste pas moins que le phénomène mérite que l’on fasse le point sur le sujet. Cela est d’autant plus vrai que l’on entend de plus en plus parler de Backshoring, pratique consistant à rapatrier des tâches précédemment traitées en Offshore (développement de nouveaux projets, maintenance, support, …). Pour en savoir plus, voir l’opinion du CEO de Kana, un éditeur de logiciel qui, après avoir « Backshorisé » ses développements, prédit une généralisation de cette pratique.

Pour essayer de s’y retrouver dans ces courants/contre-courants, regardons quelles sont les attentes des décideurs informatiques vis-à-vis de l’Offshore et les constats réalisés après mise en pratique. Selon le Gartner, les attentes liées à l’Offshore se répartissent de la manière suivante :

OffChère ou pas ?

Si l’on regarde le seul tarif journalier d’un développeur, le différentiel est conséquent (on peut atteindre près de 70 % en fonction des pays par rapport à la France). Or, tout le monde sait qu’un projet nécessite des développeurs (et des bons !) mais que de nombreuses autres compétences sont indispensables. Si la motivation de mise en Offshore est le coût, il faut briser le miroir aux alouettes du tarif/j et prendre en compte :
– Le surcoût de l’équipe en France,
– Le fait que les structures Offshore produisent des évaluations de charges plus élevées dues à un formalisme plus lourd et à un mode d’organisation des projets très taylorisé. Nous avons notamment été amenés à auditer un projet pour lequel 40 développeurs ont travaillé en parallèle alors que la réalisation faite en France aurait fait intervenir moins de 10 développeurs de front.
– Les frais et temps de déplacement,
– Les surcoûts liés à une mauvaise répartition des tâches particulièrement consommatrices dans les phases de recette pour les maîtrises d’ouvrage.

Enfin, certains risques sont également à peser :
– Comment se prémunir d’une augmentation des tarifs dans des pays où la croissance est aux alentours de 10 % ? Récemmement, Henning Kagermann, CEO de SAP a annoncé sa volonté de quitter l’Inde pour cause d’augmentation des coûts trop importante.
– Comment assurer la réversibilité des prestations et éviter l’emprisonnement par le prestataire ? À ce titre, la rédaction d’un contrat Offshore avec un juriste expérimenté est fondamentale même si la mise en œuvre des clauses de réversibilité demeure complexe.
– Comment s’assurer que les architectures préconisées auront des coûts d’exploitation optimums ? Nous avons en effet constaté une tendance à avoir recours massif à des solutions éditeurs surdimensionnées et à ne pas toujours prendre en compte les contraintes de licences de déploiement dans les choix technologiques réalisés.

On constate donc que la dimension coût est complexe à évaluer. Si certains ont prouvé une réduction de leurs coûts de l’ordre de 20 %, cette analyse n’est pas faite sur la majorité des projets. C’est précisément lorsque ces analyses seront réalisées que le phénomène Backshoring s’enclenchera massivement ou pas.

Amélioration de la qualité

Les structures Offshore (surtout indiennes) ont compris la puissance du marketing. CMMI est donc devenu pour eux une arme redoutable pour vendre leur promesse de qualité. Pour avoir audité de nombreuses applications développées par des prestataires CMMI niveau 5, la seule chose dont on est certain, c’est que le logiciel a été développé en respectant des processus maîtrisés. Rien ne garantit que la documentation produite n’est pas obsolète à la fin du projet, que les processus ne sont pas ubuesques (des tests de charge menés par des utilisateurs réels alors qu’il existe des logiciels permettant de simuler une charge par exemple) …
La qualité est bien un sujet sur lequel le client ne peut pas déléguer le contrôle à un prestataire externe. Si l’on souhaite de la qualité, il faut s’impliquer. Quel que soit le label du fournisseur, le client doit valider les livrables que le prestataire soit local ou Offshore. Le seul avantage que l’on peut concéder au Offshore est que les process qualité de type tests, documentation, … sont plus économiquement accessibles. Au-delà de ça, on trouve des prestataires de qualité aussi bien localement qu’Offshore.

Le manque de compétences internes et l’accroissement de sa réactivité

Ces attentes sont particulièrement curieuses surtout lorsque l’on pense à l’Inde où les équipes sont éloignées, ne parlent pas la même langue, n’ont pas la même culture que nous, … Le seul argument de la disponibilité d’armées de développeurs n’est pas suffisante pour y croire. S’il y a bien un domaine où le Offshore est pénalisant, c’est bien sur le plan de la réactivité :
– Le formalisme est souvent très lourd.
– La manière de travailler des prestataires lointains a tendance à découper les projets en petites unités de travail. Si bien que peu de gens disposent d’une vision d’ensemble du projet et sont à même de prendre les bonnes décisions en cas de demande d’évolution.
– Le rapport à la hiérarchie étant fort, il est très difficile d’obtenir une réponse rapide par les gens qui savent.

Enfin, il faut bien se rendre compte que pour les mastodontes de l’Offshore (plusieurs dizaines de milliers de collaborateurs), nos « petits » projets européens n’occupant que quelques dizaines de collaborateurs sont une goutte d’eau. Il est évident qu’en cas d’arbitrage d’affectations (dans le cas de démission notamment), on peut s’attendre à quelques surprises.

Les bonnes pratiques pour avancer

Si l’on décide une délocalisation de certaines tâches, il faut avant tout s’assurer de l’adhésion des équipes locales. La conviction que la délocalisation est souhaitable doit être partagée et les rôles de chacune des équipes clarifiés. Une fois cette étape réalisée (triviale à écrire mais autrement complexe à concrétiser), il faut adopter un modèle Offshore adapté à son contexte.

Deux modèles se dégagent à nos yeux et doivent être étudiés en priorité :
– Le plus sécurisant est le recours à un prestataire local qui s’est équipé d’une structure Offshore ou Nearshore (idéalement, sous forme de filiale détenue par le prestataire). On bénéficie de tous les processus rodés par le prestataire entre ses deux structures et une gestion de la relation locale.
– Le plus impliquant consiste à monter sa propre structure en Offshore. Dans ce cas, le client final recrute ses propres collaborateurs. Cette stratégie peut être particulièrement utile notamment lorsque le client a des projets de développement de son business localement.

Dans ces deux cas, cette délocalisation doit s’accompagner d’un renforcement du rôle des architectes (urbanisation du SI, établissement de normes/cadres cohérents, processus de réception des développements, …) afin de pérenniser les investissements et assurer l’évolutivité de l’ensemble. Alors, les architectes seront de vrais « empêcheurs de tourner en rond » !