Depuis longtemps, il est établi que la mesure des résultats du développement logiciel ne peut pas se réduire à une unité de temps passé de type mois-homme. En 1975 déjà, le ‘mythe du mois-homme’ est devenu un livre célèbre qui expliquait ce point de différentes manières, en évoquant par exemple que l’ajout de ressources à un projet logiciel en retard ne faisait qu’accentuer celui-ci. Le livre a été édité de nouveau en 1995, confirmation de sa pertinence mais aussi une preuve que la nécessité d’expliquer cela à des personnes extérieures au logiciel reste complètement d’actualité 20 ans après. Je n’ai pas de doutes sur le fait qu’il faille encore répéter le message en 2015, dans la mesure où la production de logiciels reste une discipline largement méconnue des décideurs.

L’émergence de l’off-shore

Pourtant, depuis l’émergence du modèle off-shore dans les années 90, l’accent mis sur le taux horaire des développeurs a atteint un sommet avec peu de voix dans l’industrie du logiciel pour défier ces nouveaux modèles de production de logiciels.

Le raisonnement est aussi simple que le suivant : la majeure partie des coûts de développement correspond au salaire des développeurs dans la mesure où c’est une activité chronophage, ce qui est vrai. Donc, en allant vers des pays où le temps est moins coûteux, cela coûtera moins cher au final. On néglige ainsi totalement l’importance de la méthodologie, en particulier le processus d’interaction entre les développeurs et les utilisateurs ou la gestion produit, les compétences ou encore l’outillage mais qui s’en soucie ?

Lors, le développement des méthodes de réduction des coûts combiné au pouvoir donné aux départements des achats, à leur méthode basique de comparaison et à l’absence d’une métrique pertinente pour mesurer la production de logiciel (au-delà du seul mois-homme) a fait de ce raisonnement la tendance générale de l’industrie. C’est ce qui nous a menés à ce que j’appelle le “syndrome du mythe du mois-homme indien”, les développeurs indiens ayant des salaires moins élevés que leurs équivalents des pays occidentaux, même si cela tend à s’ajuster.

Malgré la prise de conscience de nombreux échecs sur le terrain (vous pouvez lire cet article de 2004 à titre d’exemple tout en notant la prudence du titre), la tendance s’est poursuivie jusqu’à ce jour. Dans une certaine mesure, les compétences et une partie de la méthodologie de production se sont bien sûr améliorées dans les pays off-shore mais le point le plus important relatif à l’interaction avec les utilisateurs demeure.

20% d’économie “lorsque ça marche”

En tant que Président de la commission R&D de l’ AFDEL (Association Française des Editeurs de Logiciels), j’ai eu la chance d’animer une session de partage d’expériences à propos de l’off-shore. Avec les responsables de différents départements de R&D, nous n’avons pas seulement évoqué les nombreux échecs. Le point qui m’a le plus frappé est que les projets réussis parlent d’une économie de 20% à la fin incluant tous les coûts cachés nécessaires pour le faire fonctionner. Il a également été évoqué la nécessité d’une montée en puissance de 2 ans pour en faire un succès.

Fait intéressant, j’ai trouvé cet article du CIO magazine qui confirme cette observation faite dès 2003 ! Cet article a le mérite de lister une partie des coûts ainsi que d’expliquer cette réalité d’une “économie de20% dans les cas les plus favorables« .

La compréhension de la dure réalité de l’off-shore devrait être sans surprise, à l’image du commentaire de cet article que j’affectionne :

Il est très difficile pour les utilisateurs et les informaticiens qui résident dans le même pays de travailler sur les contraintes qu’exige le logiciel et de mener à bien un projet. En fait, certaines statistiques disent que 80% des projets ne parviennent pas à atteindre leurs objectifs. Dès lors, imaginez déplacer l’équipe technique à des milliers de km avec un horaire de travail à l’opposé de leurs utilisateurs finaux, une autre langue maternelle, une culture et des mœurs radicalement différents. Avec le sarcasme dont je suis capable, je dois dire que rien de tout cela semble intuitivement augmenter les chances de succès mais présente “l’avantage” d’être réellement bon marché.

Payer moins cher quelque chose qui ne répond pas à votre besoin est à coup sûr une mauvaise dépense !

Probablement plus de 100% de coûts supplémentaires dans les autres cas

Revenons à l’expérience terrain, l’off-shore ‘en soi’ n’est pas la solution aux nombreux défis auxquels le développement logiciel a à faire face. C’est pourquoi nous observons de nombreux échecs sur le terrain où nous estimons que les coûts représentent aisément le double de ce qu’ils devraient être, non seulement à court terme mais sur le long terme également.

Ce n’est pas la question de savoir si les développeurs sont bons ou pas dans certaines zones géographiques (bien qu’il existe des zones avec plus ou moins de compétences) mais souvent la nature du développement logiciel qui rend difficile un travail réalisé à trop forte distance des utilisateurs.

Les méthodes agiles, dans la tendance sont assez intelligentes pour mettre l’accent sur la proximité du rôle de gestion du produit. Nous avons développé l’importance de l’alignement dans un livre blanc ‘La performances des équipes de développement’ que vous pouvez téléchargé ici

Si l’équipe est conséquente, vous pourriez avoir envie de vous retrouver du côté du spectre à 80% de coût grâce à l’économie d’échelle, cela constituant néanmoins un réel un défi. Mais nous avons vu aussi de nombreux clients faire marche arrière et embaucher des ressources locales.

Il existe également un grand tabou qui fait que beaucoup de projets en échec sur le terrain sont parfaitement justifiés par les équipes techniques, profitant de la difficulté des décideurs à se faire une vraie idée. Ce point est déjà courant dans cette industrie et se trouve bien sûr amplifié avec les complexités d’une équipe distante.

Au delà des coûts

Au delà des coûts, pousser trop loin l’off-shore a souvent pour conséquences :

• Des limites de compétences qui se traduisent par des solutions techniques non optimales,
• La perte de contrôle, car vous risquez de dépendre d’un partenaire externe dont les intérêts ne sont pas les mêmes que les vôtres,
• Une perte d’agilité, car il se peut qu’un simple besoin de modification d’une règle métier prenne des semaines,
• Des risques accrus de différentes natures en raison de la distance, de la langue, de la culture et parfois de risques légaux concernant la protection de la propriété intellectuelle.

En fin de compte, à trop externaliser vos développements, vous allez perdre les compétences, jusqu’à ne plus savoir évaluer si vous faites bien ou pas. On pourrait également mentionner l’enjeu citoyen dans son pays mais ce n’est même pas mon propos.

C’est pourquoi, même si peu de gens l’admettent publiquement, l’off-shore est souvent un échec au final comme en témoigne cet article, qui résume avec une pointe d’humour ce que vivent les clients après y avoir eu recours. Il en résulte une hypocrisie significative qui contraste avec les discussions d’experts lorsqu’ils confrontent leurs expériences en privé et individuellement.

Sérieusement, en tant que décideur éclairé, prendriez-vous le risque de perdre le contrôle de vos développements pour une hypothétique économie potentielle de 20% ?

Personnellement, je n’ai jamais songé une seule fois à l’externalisation de notre logiciel, par exemple, et ce n’est pas faute de recevoir de multiples sollicitations de l’ensemble de la planète, parfois fort bien articulées.

Ce n’est qu’avec la contribution des ingénieurs logiciels que vous pouvez faire la différence sur le marché à long terme dans la mesure où ils sont capables de faire des choix cruciaux.

Donc assurez-vous de garder au moins quelques compétences locales, faute de quoi vous prenez un risque élevé de perdre le contrôle à un moment ou un autre.

N’hésitez pas à partager vos commentaires