Tour à tour vanté puis décrié, l’offshore n’en demeure pas moins une réalité bien ancrée dans le paysage informatique français. S’il s’agit rarement d’un long fleuve tranquille, les projets impliquant un éditeur offshore réclament peut-être plus que tout autre, anticipation, communication, et rigueur opérationnelle.

L’offshore représentait ainsi, en 2016, environ 8% du marché des services informatiques en France et concerne des prestations qui vont aujourd’hui bien au-delà des tâches de codage, de corrections de bugs et de migrations de données qui lui ont été longtemps réservées.

Les éditeurs offshore, majoritairement basés en Inde, au Maghreb et de plus en plus dans les pays d’Europe centrale et orientale (PECO) disposent aujourd’hui, en effet, d’une main-d’œuvre qualifiée et d’infrastructures financièrement stables et reconnues.

Celles-ci leur permettent de proposer non seulement les activités de construction d’un système d’information (développement, paramétrage, maîtrise d’œuvre) mais également les activités de maintenance applicative une fois la solution déployée.

Travailler avec un éditeur offshore : un projet comme un autre ?

Souvent, le choix d’un éditeur offshore est d’abord motivé par des critères financiers. Les propositions financières pour des logiciels développés en Inde sont, par exemple, environ 30% à 40 % inférieurs à ceux des marchés occidentaux. Les éditeurs offshore en répondant à la pénurie de main d’œuvre informatique en France, proposent des effectifs plus nombreux et plus flexibles, qui contribuent à des offres attractives en terme de délais et de coûts. Du moins sur le papier.

Car, dans la réalité, les choses s’avèrent souvent plus complexes ; d’abord du fait de l’éloignement géographique et du décalage horaire, qui sont difficiles à gérer en mode projet, ne serait-ce que pour organiser des réunions ou des ateliers de travail.

Ensuite, du fait de la barrière de la langue, ou de la façon dont le métier lui-même est appréhendé : car si l’anglais constitue, dans la majorité des cas, la langue de travail, des erreurs de compréhension ou d’interprétation, par exemple dans l’expression des besoins, peuvent conduire à des malentendus et avoir des incidences particulièrement néfastes sur le projet.

Enfin, la barrière culturelle ne doit pas être sous-estimée ; en s’appuyant sur le Modèle de Lewis, on constate que des pays comme l’Inde et la Turquie, où la recherche du compromis et le respect de la hiérarchie sont maîtres s’opposeront aux modèles anglo-saxons ancrés dans les faits et la prise de décision, ou encore aux modèles latins plus impulsifs et émotifs.

Copyright Richard Lewis Communications

Dans les faits, les pratiques projet, la gestion du temps et des ressources (plus de 25% de turnover dans le secteur de l’IT en Inde) la formalisation des échanges et des décisions varient d’une culture à une autre, et rendent le projet particulièrement complexe à piloter.

Mener un projet informatique avec un éditeur offshore peut, dans ces circonstances, se transformer rapidement en parcours du combattant ; d’autant que la situation est parfois davantage subie que choisie pour les équipes projet client, qui n’ont pas d’autres possibilité que de composer avec les contraintes qui leur sont imposées.

Mais qu’elles se rassurent : des solutions existent pour réduire les risques inhérents à un projet offshore et faire en sorte qu’il se déroule dans les meilleures conditions possibles.

Anticiper les difficultés et les coûts cachés

L’un des écueils les plus souvent rencontrés dans un projet offshore réside dans la sous-estimation des coûts cachés. Les entreprises sont ainsi souvent séduites par des offres a priori très compétitives, mais qui s’appuient souvent sur une analyse insuffisante des besoins et sur une sous-évaluation de la charge de travail avec, in fine, des répercussions sur les délais, les budgets et la réputation du projet.

Les entreprises doivent prendre conscience de ces coûts cachés et les anticiper autant que possible. Cela commence par prendre le temps d’étudier l’offre de l’éditeur point par point, en phase de sélection, pour pouvoir la challenger :

A-t-il bien compris les besoins ?
L’évaluation de la charge de travail et le planning proposé sont-ils réalistes ?
A-t-il pris en compte les coûts annexes, tels que les frais de déplacement et de formation des équipes, dont la courbe d’apprentissage peut être longue ?

Par ailleurs, tout doit être documenté de la manière la plus exhaustive possible, y compris le contrat, qu’il faut prendre le temps de lire scrupuleusement : prestations fournies, livrables attendus, responsabilités entre l’équipe projet et l’éditeur, etc. Il s’agit de vérifier que tout est conforme aux bonnes pratiques de gestion de projet, afin d’éviter de mauvaises surprises en cours de projet et à l’issue de la collaboration.

Enfin, il ne faut pas hésiter à augmenter la durée de la phase de conception du projet : en prenant le temps, d’une part, de décrire très précisément les besoins, de rédiger des spécifications explicites et détaillées et, d’autre part, dans la phase de cadrage de définir très clairement la méthode (cycle en V ou agile), la gouvernance et les outils du projet.

Un suivi rigoureux et documenté

Une fois lancé, un projet offshore nécessite un suivi des plus rigoureux. L’éloignement géographique ne favorise pas la communication entre les différentes équipes et peut vite conduire à une certaine opacité, au phénomène « boîte noire » où personne ne sait réellement qui fait quoi.

Il est donc primordial de mettre en œuvre des outils, des instances et des documents de suivi suffisamment contraignants pour permettre une gestion transparente du projet.

Cela passe concrètement par la mise en place d’outils collaboratifs tels qu’un fichier de suivi de la documentation et des développements en cours, un planning partagé, des conférences téléphoniques ou vidéo-conférences régulières (voire quotidiennes), des réunions sur site planifiées, des compte-rendus écrits réguliers, etc.

Une solution plus radicale encore mais sans doute plus rapidement efficace consistera à rapatrier les analystes de l’éditeur sur le site du client afin d’assurer la bonne compréhension des spécifications et faire le lien avec les équipes restées offshore.

Par ailleurs, pour éviter l’effet « tunnel » de la phase de développement (période pendant laquelle le client n’a plus de prise ni de vue sur les avancées du côté de l’éditeur intégrateur), il faut imposer des démonstrations fréquentes de la part de l’éditeur offshore, afin de s’assurer régulièrement que les développements sont bien conformes aux fonctionnalités attendues.

La phase de recette pourra également être renforcée pour vérifier que le produit livré est bien conforme aux spécifications fournies, dans les moindres détails. Avant de se lancer dans des tests utilisateurs, le chef de projet aura pris soin de vérifier l’existence et l’exhaustivité des tests de qualité et d’intégration réalisés par l’éditeur à l’issue des développements.

Et si ça se passe mal ?

Malgré toutes ces précautions, il peut arriver qu’un projet tourne mal ou tourne court : communication impossible avec les équipes offshore, livrables non conformes, explosion des budgets et du planning…

Pour pallier ces risques, il est important de prévoir des procédures de résolution, en faisant figurer des clauses de réversibilité ou de rupture anticipée dans le contrat, de tracer tous les échanges et de produire une documentation la plus exhaustive possible tout au long du projet, pouvant servir de levier contractuel en cas de litige et permettant en outre de ne pas avoir à tout réécrire avec un autre éditeur, le cas échéant.

Un projet offshore s’avère souvent complexe et fastidieux. Si anticipation, communication, rigueur et ténacité sont assurément des facteurs clés de succès, il peut s’avérer salutaire de faire appel à une assistance à maîtrise d’ouvrage rompue aux spécificités des projets offshore et capable d’apporter son savoir-faire en la matière.

Le consultant pourra ainsi apporter son regard expert sur l’offre de l’éditeur, le contrat, la méthode employée et ses éventuels ajustements et correctifs, et permettre ainsi de piloter le projet dans les meilleures conditions possibles.

Imprimer cet article