J’ai "pratiqué" le développeur Indien pendant plusieurs années. J’ai même fait deux déplacements professionnels en Inde (Chennaï) pour "former/suivre/coordonner" les équipes de développements attachées aux projets de l’entreprise dans laquelle je travaillais à l’époque. J’en retire une expérience à la fois riche et paradoxale.

D’une manière générale les développeurs que j’ai rencontrés étaient humainement agréables, motivés, ne rechignaient jamais à la tâche et cumulaient les heures. Cela dit j’ai pu constater plusieurs choses qui m’ont fait douter de la pertinence de l’off-chore. Je vous les sert en vrac en notant au passage que cela ne concerne que ceux avec lesquels j’ai travaillé :
– ils réinventaient la roue : lorsqu’une nouvelle fonctionnalité devait être développée, ou qu’un travail leur était confié, ils ne cherchaient pas s’il existait de solutions pouvant être utilisées à moindre frais. Surtout dans le développement de composants.
– ils se bornaient strictement aux specs : en gros c’était les specs, juste les specs et rien que les specs. Je veux bien comprendre que celles-ci soient l’unique support sur lequel se fonder lorsqu’on est dans un contexte de développement distant mais… un email ou un coup de téléphone pour balayer les doutes et les zones d’ombre (voir la petite histoire ci-dessous) reste assez efficace.
– il fallait se méfier des évidences : ce qui est évident pour nous ne l’est pas forcément pour eux.
– ils testaient très peu leur travail : plus d’une fois le code fourni ne compilait même pas, c’est quand même très limite comme travail.
– ils factorisaient peu leur code : d’où un effet de copier-collé allourdissant le code et augmentant le temps de maintenance.
– ils étaient incapables de te dire qu’ils n’avaient pas compris : il fallait lourdement insister, voire leur demander de répéter certains points des explications pour s’assurer qu’ils avaient bien acquis la problématique.
– ils tenaient mal les délais : et en plus, si on n’était pas derrière presque constamment pour suivre l’avancée des travaux, on n’apprenait que tardivement qu’il y avait du retard.
– il y avait un turn-over interne assez édifiant : oui on a beaucoup parlé du turn-over entre entreprises, mais en interne ça arrive aussi souvent. D’un mois sur l’autre on était pas sûr d’avoir strictement la même équipe et il fallait recommencer à former les "nouveaux" que l’on découvrait sans prévenir.

Pour la petite histoire, j’ai un jour confié le développement d’une IHM sous Delphi 7 à une équipe de développeurs Indiens. Il s’agissait d’une simple fenêtre pour une nouvelle fonctionnalité à intégrer dans l’application. J’avais pas mal peaufinné les specs techniques, allant jusqu’à détailler chaque écran, chaque click, chaque event, les enchaînements, la navigation et le reste. Mais j’avais oublié une chose…

Le jour de la livraison j’ai constaté que l’IHM avait bel et bien été développée selon la spec. Un point de détail attira néanmoins mon attention. Dans l’angle supérieur droit de la fenêtre les icônes bien connus de Réduction/Aggrandissement/Sortie avaient disparu. Interrogeant le chef d’équipe à ce sujet celui-ci me répondit que les écrans présentés dans la specs n’avaient pas ces icônes qu’ils les avaient retirés et qu’en plus ils avaient galéré pour ce faire (qui parle de coûts cachés et de délais non tenus ?).

Eeeeeh oui, après de nombreuses heures à pondre une spec technique très détaillée pour qu’ils aient tout en main j’avais oublié de mettre ces trois petits éléments qui sont "évidents" pour beaucoup… Mea culpa, mea maxima culpa, j’en suis tombé de ma chaise (virtuellement seulement).

Bref, tout ceci pour dire que lorsqu’on se lance dans l’off-shore avec l’Inde il faut être très très prudent.

Cordialement

Et même pour les règles simples, en pratique, il faut se donner les moyens de vérifier. Une fois qu’on a laissé partir tous les bons qui va le faire ? Et en admettant qu’on arrive à en garder quelques-uns, combien de vrais bons se satisferaient d’un tel boulot dans la durée ? Et comment donc resteraient-ils bons en faisant cela ?

Tant qu’on n’aura pas compris que la réalisation d’un logiciel correspond à la conception de tout autre élément industriel, on manquera le point essentiel !

Sur le commentaire d’Eric, j’observe aussi le fonctionnement possible dans des cas de liens familiaux ou connexions très particuliers, mais cela relève donc de l’exception, et pas d’un modèle qu’on peut généraliser et appliquer. Je partage le fait que la dimension humaine est très importante ("Software is people" disent les américains) mais ce n’est pas forcément réellement un pur art. Il y a un mix de créativité et d’approche scientifique industrielle. Mais la conclusion reste cette dépendance à l’humain, le processus de création devant être permanent, et étant fortement "tué" par la distance et l’absence de lien avec les utilisateurs.

Si ton equipe de developpement est en Chine (et ils ont d’excellents developpeurs) et que tu peux aussi utiliser les demandes du marche Chinois pour definir les problemes a resoudre, tu peux beneficier d’un double effet: ils te font parvenir de nouveaux besoins, et ils restent en controle de leur "short feedback loop" entre demandes et fonctionnalites.

C’est ce que j’observais depuis ILOG et depuis IBM maintenant.

J’ai souvent repete que le bon logiciel vient de bons problemes et de bons developpeurs. Le truc interessant c’est que maintenant on trouve les deux en Chine. Pour les bons problemes, l’Inde est moins interessante.

Commentaires?