La délocalisation touche maintenant depuis quelques années les métiers de l’informatique et plus spécifiquement les métiers du développement. Il n’est donc peut-être pas inutile de regarder des expériences plus anciennes, notamment dans l’industrie, pour tenter de trouver des enseignements.

Avant de se lancer dans cette démarche, il faut cependant bien garder en tête la nature des activités de développement. Ces dernières, même si l’on parle communément de production de code, restent des activités d’ingénierie et non des activités de production. La transposition des expériences de délocalisation qui concernent essentiellement des activités de production est donc à mener avec circonspection.
D’une façon un peu caricaturale, on peut dire que dans l’industrie le niveau d’investissement est inversement proportionnel au coût de la main d’œuvre. La délocalisation permet donc de bénéficier de main d’œuvre moins chère et donc de mobiliser moins de capitaux pour produire au même coût que dans d’autres pays où la main d’œuvre est plus coûteuse. D’ailleurs, le niveau d’automatisation est calibré sur des hypothèses de coûts de main d’œuvre : si le succès d’un pays provoque un renchérissement de la main d’œuvre, les hypothèses de départ peuvent ne plus être vérifiées entraînant une nouvelle délocalisation vers des pays moins chers. Les pays de l’Europe de l’est ont été victimes de ce syndrome dans les années 90.

Pour revenir maintenant au monde du développement, la même analyse peut être menée : à productivité égale, même en tenant compte des coûts de frottements liés aux distances et aux différences de culture, la délocalisation est plus économique. Cependant, en regardant bien cette proposition, on peut travailler sur son hypothèse fondatrice qui tend à considérer la productivité comme égale entre des développements « on shore » et des développements « off shore ».
On retrouve ici la notion, abordée plus haut, de niveau d’investissement ou niveau d’outillage : comme pour une usine on peut plus ou moins industrialiser la production de code et améliorer la compétitivité des pôles de développement « on shore » par des outils de génération de code.
Le parallèle avec l’industrie n’est cependant pas possible complètement : la lourdeur des investissements nécessaires à l’automatisation d’une partie du développement d’une application n’a rien de commun avec les coûts des robots d’une chaîne de montage ! En revanche, comme dans l’industrie, cette apparition de l’automatisation a un impact sur les ressources. Moins de ressources plus qualifiées seront nécessaires pour mener à bien un projet.

L’utilisation des techniques de génération de code est donc une réponse à la menace que fait peser « l’off-shoring » sur les développeurs occidentaux. Ces techniques ne doivent pas être considérées comme des menaces sur le rôle du développeur mais comme une opportunité à la fois pour s’abstraire des tâches les plus rébarbatives du développement et également pour améliorer sa compétitivité face à des solutions off-shore. Libérée d’une partie des développements, l’équipe projet peut alors se concentrer sur la définition des fonctionnalités, la proximité avec les utilisateurs, bref sur tout ce qu’il est difficile de faire « off shore » !