Quelques décennies après ses premières grandes vagues, l'externalisation des activités informatiques continue à être parée de toutes les vertus dans de nombreuses entreprises. Une petite histoire vécue du « Shark Tank » de la revue ComputerWorld me donne l'occasion d'essayer de restaurer un peu d'objectivité sur le sujet.
Voilà donc une organisation importante dans laquelle les projets confiés à la direction informatique interne sont systématiquement livrés avec des retards conséquents et dépassent allègrement leurs budgets initiaux. Un responsable décide alors de recourir à un prestataire délocalisé afin de réduire les coûts. Miracle ! Le logiciel attendu arrive en avance, il est de bonne qualité et la facture est inférieure aux prévisions. La démonstration suffit pour considérer l'approche comme la voie à suivre.
La logique est difficilement contestable : la preuve semble faite de l'efficacité supérieure des équipes externes, n'est-ce-pas ? En fait, non. La narrateur relate ainsi qu'une analyse des modes de travail éclaire la raison profonde des écarts observés. Quand ils confient leurs besoins au département informatique, les donneurs d'ordre ont l'habitude d'intervenir fréquemment en cours de réalisation, pour demander des changements ou des ajouts. À l'inverse, le contrat établi avec un tiers limite leur marge de manœuvre sur ce plan.
En synthèse, le gain de performance est dû non pas à une quelconque différence dans les compétences déployées mais ressort plutôt du niveau de rigueur variable dont font preuve les commanditaires lorsqu'ils expriment leurs attentes. Dans un cas, ils savent pertinemment qu'ils auront la possibilité de revenir sur leurs choix à tout moment, sans que, s'ils sont suffisamment « puissants », personne n'ose s'indigner de leur versatilité, tandis que, dans l'autre, ils admettent qu'ils n'auront pas autant de liberté d'action.
Cette situation, qui se retrouve dans toutes les grandes structures (souvent de manière cyclique : la mode passe puis elle revient avec la génération suivante de décideurs), devient ubuesque quand elle se combine avec une transition vers des méthodes agiles. Les débordements sur les projets internes prennent des proportions cataclysmiques car ce que retiennent les sponsors de cette évolution se résume à une promesse (qui est une erreur d'interprétation) : les spécifications peuvent changer à tout moment !
Le fossé de coûts et de délais avec les services externalisés se creuse alors toujours plus, puisque, de son côté, un partenaire cherche à maintenir la stabilité du cahier des charges sur lequel il s'est engagé, quelle que soit la méthodologie usitée. Hélas, les bénéfices espérés ne sont plus tout à fait au rendez-vous, ne serait-ce que parce que la proximité indispensable entre l'équipe logicielle et les utilisateurs ciblés n'est plus garantie. Il ne reste qu'un dilemme entre fausse agilité et projets incontrôlables.
Qu'on s'entende, le débat n'est pas ici de déterminer l'opportunité de recourir à des sociétés tierces, éventuellement à l'autre bout du monde, pour le développement d'applications. En revanche, il s'agit de savoir précisément quels sont les avantages et les inconvénients des différentes options en lice ainsi que les exigences et compromis associés, de manière à établir une stratégie en toute connaissance de cause. Rien n'est pire que de verser dans l'externalisation à outrance pour de mauvaises raisons.
Voilà donc une organisation importante dans laquelle les projets confiés à la direction informatique interne sont systématiquement livrés avec des retards conséquents et dépassent allègrement leurs budgets initiaux. Un responsable décide alors de recourir à un prestataire délocalisé afin de réduire les coûts. Miracle ! Le logiciel attendu arrive en avance, il est de bonne qualité et la facture est inférieure aux prévisions. La démonstration suffit pour considérer l'approche comme la voie à suivre.
La logique est difficilement contestable : la preuve semble faite de l'efficacité supérieure des équipes externes, n'est-ce-pas ? En fait, non. La narrateur relate ainsi qu'une analyse des modes de travail éclaire la raison profonde des écarts observés. Quand ils confient leurs besoins au département informatique, les donneurs d'ordre ont l'habitude d'intervenir fréquemment en cours de réalisation, pour demander des changements ou des ajouts. À l'inverse, le contrat établi avec un tiers limite leur marge de manœuvre sur ce plan.
En synthèse, le gain de performance est dû non pas à une quelconque différence dans les compétences déployées mais ressort plutôt du niveau de rigueur variable dont font preuve les commanditaires lorsqu'ils expriment leurs attentes. Dans un cas, ils savent pertinemment qu'ils auront la possibilité de revenir sur leurs choix à tout moment, sans que, s'ils sont suffisamment « puissants », personne n'ose s'indigner de leur versatilité, tandis que, dans l'autre, ils admettent qu'ils n'auront pas autant de liberté d'action.
Cette situation, qui se retrouve dans toutes les grandes structures (souvent de manière cyclique : la mode passe puis elle revient avec la génération suivante de décideurs), devient ubuesque quand elle se combine avec une transition vers des méthodes agiles. Les débordements sur les projets internes prennent des proportions cataclysmiques car ce que retiennent les sponsors de cette évolution se résume à une promesse (qui est une erreur d'interprétation) : les spécifications peuvent changer à tout moment !
Le fossé de coûts et de délais avec les services externalisés se creuse alors toujours plus, puisque, de son côté, un partenaire cherche à maintenir la stabilité du cahier des charges sur lequel il s'est engagé, quelle que soit la méthodologie usitée. Hélas, les bénéfices espérés ne sont plus tout à fait au rendez-vous, ne serait-ce que parce que la proximité indispensable entre l'équipe logicielle et les utilisateurs ciblés n'est plus garantie. Il ne reste qu'un dilemme entre fausse agilité et projets incontrôlables.
Qu'on s'entende, le débat n'est pas ici de déterminer l'opportunité de recourir à des sociétés tierces, éventuellement à l'autre bout du monde, pour le développement d'applications. En revanche, il s'agit de savoir précisément quels sont les avantages et les inconvénients des différentes options en lice ainsi que les exigences et compromis associés, de manière à établir une stratégie en toute connaissance de cause. Rien n'est pire que de verser dans l'externalisation à outrance pour de mauvaises raisons.
Aucun commentaire:
Enregistrer un commentaire
Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)