Offshore what for ?

Le texte suivant est extrait du livre « Une Politique pour le Système d’Information – Descartes – Wittgenstein- (XLM) » publié par OCTO Technology :

Pour la DSI, l’off-shore consiste à sous-traiter des activités de build dans des pays à plus faible coût. Il s’agit donc d’un modèle de faire-faire tout à fait identique au mode d’achat de prestations au forfait en France. Un pur réflexe sécuritaire nous défend encore de sous-traiter massivement les activités d’hébergement du run [1], a priori pourtant plus simple à contractualiser. Nous nous en tenons donc pour l’instant aux fonctions de support (H24, multi-langue, etc).

Ce modèle de construction de SI peut s’appliquer à la zone rationalisée, mais assez mal, nous l’avons vu dans  » La Frontière « , dans les activités d’innovation, par essence in situ, car riches d’interactions orales rapides.


Les Indiens, les Roumains et les Biélorusses sont des gens brillants et surtout très motivés; quand on a faim et encore des rêves, il est plus facile de posséder une telle motivation. De plus, vu de la France, ils sont souvent en avance de phase en termes de savoir-faire grâce à des expériences sur des projets US, que nous reproduisons souvent deux ans plus tard sur le vieux continent (par exemple les projets ERP). Dans un processus en cascade, ils sont donc généralement plus performants que l’industriel français moyen. Heureusement, la cascade marche mal, l’alternative n’est donc pas encore vraiment avantageuse. Au-delà du prix, les clients qui décident d’une politique off-shore auraient préféré que cela réponde à leurs attentes et dans des délais raisonnables.

Cependant nombre d’entreprises d’ingénierie off-shore ont acquis la certification CMM5. Par ailleurs, de brillants architectes techniques ont fertilisé ces entreprises avec les meilleures pratiques d’ingénierie logicielle, dont l’incrémental et le test. Certains prestataires off-shore sont donc prêts à travailler en dehors de la cascade, mais les clients n’en achètent pas encore. Normal, on n’externalise que ce que l’on sait déjà faire.

L’off-shore représentait environ 2% du marché Français en 2005 [2] (10% aux Etats-Unis). Au rythme de croissance actuel, il s’agira probablement de 25% dans 5 ans… si cela ne s’accélère pas. Car le discours des organisations en faire-faire est à peu près le suivant : l’essentiel est de conserver le fonctionnel et l’architecture. Or ces fonctions localisées on-shore, seront rapidement soumises au dilemme de parler ou pas au code, c’est-à-dire soit participer directement à sa construction et à son test (modéliser, développer, écrire des cas de test, assembler..), soit agir par délégation, via des contrats essentiellement écrits (cahier des charges, spécifications..). Mais vivant géographiquement dans une communauté qui ne parle pas au code dans son immense majorité (managers, acheteurs, auditeurs, ..), ces personnes seront isolées, donc plus à l’aise là-bas, vers la communauté opérationnelle, qui rappelons-le est le plus souvent leur communauté d’origine. On peut donc penser que très rapidement les seuls à parler au code seront localisés off-shore.

C’est le danger d’une vision purement statique du phénomène qui voudrait que parce que nous possédons aujourd’hui de bons fonctionnels et de bons architectes, nous les conserverons demain en sous-traitant le reste. Mais sans base, pas d’élite. Sans programmeurs motivés, pas d’architectes géniaux capables de comprendre les effets non-linéaires, la complexité technique, l’entropie, les perversions du simplisme… Et petit à petit cette base disparaîtra, puisque nous n’en achèterons qu’en Inde.

Ce phénomène accélèrera la possibilité de désintermédiation de la DSI par des forces capables d’adresser l’utilisateur final en direct, et qui ne se gêneront pas pour le faire.

Nous suggérons donc d’éviter le recours à l’off-shore pour l’innovation. Désireux d’amplifier les démarches incrémental et test dans la zone rationalisée, le seul intérêt que nous voyons à l’off-shore est l’aiguillon qu’il représente pour les fournisseurs locaux. Si des fournisseurs off-shore proposent de l’incrémental et du test – obligatoirement avec du personnel on-shore – et pas vos fournisseurs habituels, il faut en acheter. Cependant, le concept même de l’off-shore est fondé sur la représentation de  » l’ouvrier du code « , que nous dénonçons violemment. Ce n’est donc pas une idée d’avenir, car le développement de logiciels de gestion, qui assistent des processus humains (flous, imparfaits et évolutifs avec le temps), n’est pas une activité industrielle (univoque, zéro défaut, répétée). Si vous êtes convaincu du contraire, remplacez immédiatement votre DSI par un Directeur des Achats Sikh.

[1] Mon compte en banque en Inde ?!

[2] Le Monde Informatique, 21 octobre 2005

4 commentaires sur “Offshore what for ?”

  • Merci pour cet article extrêmement instructif.
    Pour ma part, je pense qu'on peut facilement délocaliser la réalisation de composants logiciels sur spécifications techniques.
    Par contre, il faut effectivement des gens en France qui savent intégrer ces composants, les tester, éventuellement les corriger.
    Ce que je dis est vrai pour des architectures à bases de composants.

  • Excellent billet!
    Je rajouterait que l'off-shore me semble, de manière générale, aussi fondé sur l'idée d'optimiser de coût en prenant le pari d'une projection dans le futur des indicateur actuels..
    Je me demande si le manque de réactivité face aux changements et à la demande entre bien dans la balance lors d'une telle décision..
    A moins qu'un SI n'apporte pas de valeur? :-S

  • Pour nous qui sommes confrontés à ces décisions chez nos clients, tout tient effectivement dans la valorisation des logiciels, valorisation qui inclue la 'réactivité' que l'on a dessus (un site Web c'est bien, un site Web où l'on ajoute ou change une fonctionnalité en une semaine sans régression, c'est mieux), pour aller au-delà de la promesse miracle de diminution des coûts unitaires... Il faut être pédagogue avec les acheteurs en somme .. ;-)

  • Tres bonnes remarques mais je pense (voire j'affirme) juste que les DSI font de l'offshore pour reduire les couts et non pour ameliorer la qualité. Donc de leur point de vue, l'offshore est vu comme l'ouvrier du code et non comme l'ouvrier de la qualité. Par contre, je pense que le souci de qualité s'impose vite lorsque l'on externalise la production de code.

    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha