1. Introduction

Depuis deux décennies, l’offre est la même et l’arithmétique paraît irrésistible. Un ingénieur en Inde coûte une fraction de ce que coûte un ingénieur en Europe occidentale ou aux États-Unis, l’offre de main-d’œuvre y est abondante et bien formée, et l’anglais en est la langue de travail ; une entreprise qui y transfère son travail logiciel devrait donc, sur le papier, faire le même travail pour bien moins cher. Une grande quantité de travail a migré pour ce raisonnement exact, et l’Inde a bâti sur lui une industrie des services informatiques de rang mondial. Et pourtant les résultats, d’une entreprise à l’autre, sont étonnamment inégaux : certaines organisations obtiennent de l’Inde d’excellents logiciels pendant des années, tandis que d’autres récoltent une facture qui grimpe, une qualité de livraison qui baisse et un flot de défauts que les salaires économisés ne couvrent jamais tout à fait, jusqu’à ce qu’elles déclarent l’externalisation un échec et rapatrient le travail, pour souvent conclure que le problème était l’Inde. Ce n’était pas l’Inde.

Le problème est que les entreprises externalisent la mauvaise chose. L’intuition derrière l’externalisation est que le développement logiciel est de l’exécution, une quantité de travail mesurable en heures-personnes et achetable là où les heures-personnes sont les moins chères ; sur cette intuition, une entreprise remet une spécification et un effectif, puis attend la production. Mais le développement logiciel n’est pas principalement de l’exécution ; il est la résolution d’un millier de petites ambiguïtés, chacune exigeant de savoir ce que le métier voulait réellement dire, comment cette partie est censée s’insérer dans le tout, et ce que « terminé » signifie vraiment ici, et cette connaissance réside là où se trouve le métier, non là où sont les claviers. Lorsqu’une entreprise externalise l’exécution, elle externalise à son insu ces décisions aussi, vers les personnes les plus éloignées du contexte nécessaire pour les prendre correctement, et le résultat est un travail localement plausible et globalement faux, découvert tardivement, à travers un décalage de douze heures, et corrigé lentement. L’arbitrage sur le coût du travail est réel ; la coordination et la reprise qu’il déclenche, mal gérées, sont plus grandes encore.

Cet article porte sur le modèle opérationnel qui corrige l’erreur en ne la commettant pas, et ce modèle a un nom que nous emploierons tout du long : le centre de commande onshore. L’idée est de séparer, délibérément et structurellement, les deux choses qu’une externalisation naïve confond. L’une est l’exécution, la construction, qui peut et doit véritablement monter en charge là où le talent est abondant et abordable, en Inde. L’autre est la commande : décider quoi construire et dans quel ordre, détenir l’architecture et les interfaces entre les parties, transformer ce que le métier veut vaguement en une spécification assez précise pour être construite au loin sans conversation, et juger si ce qui revient est correct. La commande est réduite, composée de cadres supérieurs et coûteuse, et elle reste onshore, auprès du métier dont elle existe pour porter l’intention. La thèse est que le succès d’un programme d’externalisation est déterminé presque entièrement par l’existence et la qualité de cette couche de commande, et presque pas par la capacité brute de l’équipe offshore, qui est généralement bonne ; et que les entreprises échouent en sous-investissant dans la commande précisément parce que la commande est la partie coûteuse et onshore que l’externalisation était censée éliminer.

La contribution est un argument et un petit modèle, non un étalonnage. La section 2 confronte la thèse au bilan de l’externalisation et de l’ingénierie logicielle mondialisée. La section 3 diagnostique le véritable échec : externaliser la responsabilité plutôt que la seule exécution. La section 4 décrit le centre de commande et ce qu’il détient. La section 5 propose un modèle de l’endroit où la ligne entre commande et livraison devrait passer, reposant sur la charge de contexte et la complétude de spécification. La section 6 traite de l’horloge, et de la façon dont le follow-the-sun devient un levier plutôt qu’une latence. La section 7 en déduit le ratio de commande optimal. La section 8 retrace un cas construit ; les sections 9 à 12 en tirent les conséquences, répondent aux objections, énoncent les limites et concluent. La question, tout du long, est la suivante : que doit garder une entreprise au pays, et en quelle quantité, pour que le travail qu’elle envoie en Inde revienne juste ?

2. Contexte

2.1 Le bilan de l’externalisation

L’externalisation et la délocalisation de l’informatique comptent parmi les plus vastes littératures empiriques des systèmes d’information, et leur verdict n’est pas que l’externalisation ne paie pas, mais que son rendement dépend de la manière dont elle est gérée. Lacity, Khan et Willcocks (2009), passant en revue deux décennies d’études, constatent que ce sont les capacités du client et du fournisseur, la conception des contrats et la gestion de la relation, plutôt que les seuls écarts de salaire, qui expliquent l’écart entre engagements réussis et engagements ratés. Carmel et Tjia (2005) ont livré le récit praticien de l’approvisionnement auprès d’une main-d’œuvre mondiale et catalogué les façons dont la distance érode l’arbitrage ; Sahay, Nicholson et Krishna (2003) ont donné l’ouvrage de référence sur le développement logiciel de part et d’autre de la frontière indienne, et Oshri, Kotlarsky et Willcocks (2007) ont retracé la manière dont un grand prestataire indien a organisé un modèle de livraison mondial autour d’une expertise dispersée. Rottman et Lacity (2006) ont distillé des pratiques éprouvées et constaté que les entreprises qui réussissaient investissaient massivement dans le travail onshore de spécification, de coordination et de gouvernance, le travail même que cet article appelle commande. Le constat constant est que l’économie est brute, non nette, et que ce qui sépare les deux est un effort de gestion qui reste largement au pays.

2.2 Pourquoi la distance coûte cher

Une seconde littérature, sur le développement logiciel réparti à l’échelle mondiale, en explique le mécanisme. Herbsleb et Mockus (2003), dans l’étude la plus centrale pour cet article, ont montré empiriquement que les éléments de travail nécessitant des personnes sur plusieurs sites prenaient nettement plus de temps à achever que des éléments comparables sur un seul site, et ont imputé ce délai au coût et à la latence de la communication qu’exige la coordination entre sites. Ramasubbu et Balan (2007), étudiant des projets répartis entre l’Inde et les États-Unis, ont mesuré la même pénalité directement dans la performance des projets. Olson et Olson (2000) ont énoncé le résultat général sous le titre « la distance compte » : le travail en un même lieu bénéficie d’une communication rapide, riche et informelle que le travail distribué perd, et qu’aucun outillage ne restaure pleinement. Kraut et Streeter (1995) avaient déjà montré à quel point le développement logiciel relève de la coordination plutôt que du codage, et Brooks (1975) avait bien plus tôt donné la raison pour laquelle ajouter des personnes à un travail distribué peut le ralentir : les chemins de communication croissent plus vite que les personnes. La leçon n’est pas que le développement distribué ne peut fonctionner, mais que chaque frontière qu’un travail doit franchir a un prix, et que ce prix se paie en temps et en défauts.

2.3 La loi de Conway et l’architecture de la frontière

L’idée la plus profonde sur laquelle s’appuie cet article est celle de Conway (1968) : la structure d’un système finit par refléter la structure de communication de l’organisation qui le construit. Son corollaire pour l’externalisation est exact et sous-exploité. Si l’offshore et l’onshore sont deux groupes qui communiquent faiblement, alors le logiciel sera le plus net lorsque la frontière entre eux suivra une véritable couture architecturale, un module doté d’une interface définie, et sera le plus tourmenté là où un unique bloc de travail fortement couplé est scindé en travers du fossé. Herbsleb et Grinter (1999) l’ont confirmé directement, constatant que le développement distribué réussit lorsque l’architecture est assez modulaire pour que chaque site détienne une partie et que les interfaces entre les parties soient explicites, et peine lorsqu’elle ne l’est pas. Parnas (1972) a donné la discipline de conception, le masquage de l’information, qui rend de tels modules possibles. La conséquence pratique, développée à la section 4, est que détenir l’architecture n’est pas l’une des tâches du centre de commande parmi d’autres ; c’est la tâche qui rend toutes les autres possibles, parce qu’elle décide où tombe la frontière coûteuse.

3. Le véritable échec : externaliser la responsabilité

L’échec caractéristique de l’externalisation n’est pas une frappe lente ; c’est un travail achevé avec assurance et discrètement faux. On transmet une exigence complète dans la tête de l’émetteur et ambiguë sur le papier, parce que l’émetteur partage avec le métier un contexte que le destinataire n’a pas. L’ingénieur offshore, compétent et de bonne volonté, résout l’ambiguïté de la seule manière possible depuis douze fuseaux horaires : en devinant, raisonnablement, et en construisant. On découvre que la supposition était fausse à la recette, s’il y a recette, ou en production, s’il n’y en a pas, et la correction franchit le fossé deux fois, une fois pour expliquer et une fois pour vérifier, chaque passage étant un jour perdu à cause de l’horloge. Multipliez cela par chaque ambiguïté d’un système réel et l’arbitrage s’évanouit, non parce que quiconque a agi avec incompétence, mais parce que les décisions qui exigeaient du contexte ont été prises là où il n’y en avait aucun.

Ce qui s’est produit, dans le langage de cet article, c’est que l’entreprise a externalisé la responsabilité alors qu’elle entendait n’externaliser que l’exécution. La responsabilité d’un logiciel est l’autorité accumulée de résoudre correctement ses ambiguïtés : savoir ce que le métier voulait dire, décider comment la partie sert le tout, dire ce qu’est le « correct ». Cette autorité est inséparable du contexte, et le contexte est local. L’exécution, la construction d’une chose une fois ses ambiguïtés résolues, n’est pas liée au contexte et voyage bien. L’erreur est de traiter les deux comme un seul colis et de les expédier ensemble ; le remède est de les séparer, de garder la responsabilité onshore là où vit son contexte, et de n’envoyer offshore que l’exécution, ses ambiguïtés déjà résolues en spécification. Tout ce qui suit est une élaboration de la manière de faire cette séparation, et de l’endroit où la faire.

4. Le centre de commande

Le centre de commande onshore est le foyer organisationnel de la responsabilité qui ne doit pas voyager. Il est délibérément réduit et délibérément composé de cadres supérieurs, parce que son effet de levier vient de la qualité de quelques décisions plutôt que de la quantité de production, et il se tient auprès du métier, non auprès des claviers. La figure 1 dessine le modèle et le tableau 3 répartit le travail. Le centre de commande détient cinq choses, et la discipline du modèle veut qu’il les détienne toutes les cinq et ne cherche à en détenir aucune autre.

De l’intention à la spécification. Le premier produit du centre de commande n’est pas du logiciel mais de la spécification : la traduction de ce que le métier veut vaguement en un exposé assez précis pour être construit par quelqu’un qui ne peut pas se pencher pour demander. C’est le travail qui résout l’ambiguïté là où se trouve le contexte, afin qu’aucune n’ait à être résolue là où il n’est pas, et c’est l’activité au plus fort effet de levier de tout le modèle, car chaque ambiguïté laissée dans une spécification se paie plus tard au coût plein d’un aller-retour à travers le fossé.

Architecture et interfaces. Par la loi de Conway, le logiciel se fracturera le long des coutures de communication de l’organisation ; le centre de commande détient donc l’architecture précisément pour choisir où tombent ces coutures : il décompose le système en modules dotés d’interfaces explicites afin que chaque pod offshore détienne une partie qu’il peut construire avec peu de dépendances transfrontalières. Bien tracer la frontière est ce qui convertit la distance d’un impôt payé à chaque interaction en un impôt payé seulement à quelques interfaces bien définies.

Priorisation. Ce qui se construit en premier relève d’un jugement métier, non d’un jugement de livraison, et cela demeure au centre de commande, qui tient le backlog unique et son ordre. Disperser la priorisation vers l’équipe offshore, ou vers plusieurs parties prenantes à la fois, réintroduit à travers le fossé exactement la coordination que le modèle existe pour contenir.

Recette et porte de qualité. Le centre de commande décide ce qu’est « terminé » et éprouve le travail retourné à cette aune, tenant une porte en laquelle le métier a confiance. C’est le pendant de la spécification : ayant défini la correction en amont, il la vérifie au retour, et parce qu’il est onshore et proche du métier, il peut juger de l’adéquation, non de la seule fonction.

Un unique responsable comptable. Enfin, le centre de commande est le lieu où la responsabilité comptable est indivise : un responsable unique qui répond devant le métier de ce qui est livré, et qui ne peut pas se décharger de l’autre côté du fossé. Une responsabilité comptable scindée en travers de la frontière est une responsabilité comptable disparue, et la restituer à un point unique onshore fait une bonne part de ce qui rend le modèle gouvernable.

5. Tracer la ligne

Si la commande reste onshore et que l’exécution part offshore, tout se joue sur l’endroit où l’on trace la ligne entre elles, tâche par tâche. Le modèle qui régit ce choix a deux axes. Le premier est la charge de contexte d’une tâche : la quantité de connaissance locale, tacite et propre au métier qu’exige sa résolution correcte, élevée pour une modification qui touche à une règle réglementaire subtile ou à un engagement client de longue date, faible pour un composant bien délimité au contrat clair. Le second est la complétude de spécification que le centre de commande peut lui apporter : dans quelle mesure ses ambiguïtés peuvent être résolues à l’avance, sur le papier, sans conversation. Une tâche peut être externalisée sans risque lorsque l’ambiguïté résiduelle qui atteint le pod offshore, sa charge de contexte nette de la complétude de spécification qui lui est appliquée, est faible. En notant $\kappa$ la charge de contexte et $s$ la complétude de spécification, toutes deux sur une échelle commune, le résidu est

et c’est $\alpha$, non la difficulté brute du travail, qui prédit la reprise. Le modèle a une lecture managériale tranchée, présentée au tableau 1. Une tâche à faible contexte s’externalise proprement quelle que soit sa difficulté technique. Une tâche à fort contexte n’est pas inapte à l’externalisation ; elle est inapte à l’externalisation non spécifiée, et le travail du centre de commande est d’élever $s$ jusqu’à ce que $\alpha$ soit assez faible pour être envoyé. Là où la charge de contexte est véritablement irréductible, là où la connaissance ne peut absolument pas être couchée sur le papier, la tâche reste onshore, et le reconnaître honnêtement fait partie de la discipline. Le mode de défaillance que nomme le modèle est la tâche à fort contexte expédiée avec une spécification de faible complétude : ambiguïté résiduelle maximale, résolue offshore par conjecture, à distance maximale.

6. L’horloge

Le décalage horaire entre une entreprise occidentale et l’Inde, quelque neuf à douze heures, est la caractéristique que les praticiens traitent le plus souvent comme un pur handicap et celle que le centre de commande peut convertir le plus proprement en atout. Laissé à l’abandon, le fossé est de la latence : une question posée à la fin de la journée offshore reçoit sa réponse à la fin de la journée onshore, et une seule clarification coûte un jour de calendrier quelle que soit sa substance, de sorte qu’une chaîne de clarifications coûte une semaine pour résoudre une heure de contenu réel. C’est le mécanisme par lequel une externalisation mal menée paraît lente même quand chacun travaille dur : le chemin critique passe par le fossé, et le fossé ajoute un jour par passage.

Bien menée, ce même fossé est une seconde équipe. Si le centre de commande transmet un travail dont les ambiguïtés sont déjà résolues, les pods offshore exécutent durant la nuit onshore et renvoient les résultats pour le matin onshore, et la journée que le métier passe à dormir est une journée de progrès plutôt qu’une journée d’attente. La différence entre les deux issues tient entièrement à l’ambiguïté résiduelle $\alpha$ de ce qui est transmis : une transmission avec $\alpha \approx 0$ n’exige aucun aller-retour et l’horloge est un gain pur ; une transmission pleine de questions non résolues retourne l’horloge contre vous, car chaque question est une journée entière. Une manière grossière de le voir est que l’accélération effective due à la seconde équipe est

où $\eta$ mesure avec quelle netteté le travail peut être transmis et $\alpha$ est l’ambiguïté résiduelle de l’équation (1) ; à mesure que $\alpha\to 0$ l’horloge approche une véritable équipe supplémentaire, et à mesure que $\alpha$ croît le gain s’effondre puis s’inverse en l’impôt d’une journée par question. Le centre de commande gagne l’horloge en détenant la spécification et la définition de « terminé » qui rendent $\alpha$ petit, raison pour laquelle le follow-the-sun est une conséquence d’une bonne commande, et non une astuce d’ordonnancement que l’on pourrait acheter séparément.

7. Le ratio de commande

Combien de commande suffit ? La question a une vraie réponse, et ce n’est ni « le moins possible », l’instinct qui produit l’externalisation du jet par-dessus le mur, ni « le plus possible », qui reconstruit onshore le coût que l’externalisation était censée abandonner. Soit $r$ le ratio de commande, la capacité du centre de commande onshore en fraction de la capacité de livraison offshore qu’il gouverne. La commande coûte le taux onshore élevé $w_c$ par unité ; la livraison coûte le taux offshore bas $w_o$ par unité. La valeur de la commande est qu’elle abaisse l’ambiguïté résiduelle atteignant les pods et donc la reprise qu’ils doivent faire : plus de commande signifie plus de travail spécifié, revu et contrôlé avant et après son passage du fossé, et donc un multiplicateur de reprise plus bas sur le travail livré. Une forme utilisable de ce multiplicateur est

où $a$ fixe l’échelle de la reprise qu’entraînerait une absence totale de commande, déterminée par l’ambiguïté intrinsèque du travail, et $b$ mesure l’efficacité avec laquelle la commande se convertit en ambiguïté résolue. Le coût total de la livraison d’une unité de travail achevé, la commande plus la livraison reprise, est alors

somme d’un terme croissant, le coût de la commande, et d’un terme décroissant, la reprise que la commande évite ; elle possède donc un unique minimum intérieur. Poser $C'(r)=0$ donne le ratio de commande qui minimise le coût

qui est le résultat quantitatif central de l’article. Il dit trois choses sur lesquelles un gestionnaire peut agir. La quantité optimale de commande est positive : $r^\ast > 0$ dès que $w_o a b > w_c$, c’est-à-dire dès que la commande est tant soit peu efficace et l’ambiguïté tant soit peu réelle, de sorte que jeter le travail par-dessus le mur ($r = 0$) n’est jamais optimal. Elle est finie : au-delà de $r^\ast$, la commande coûte plus que la reprise qu’elle épargne, de sorte que tout garder onshore n’est pas optimal non plus. Et elle évolue dans le bon sens : $r^\ast$ croît avec l’ambiguïté du travail ($a$) et avec l’efficacité avec laquelle la commande la résout ($b$), et décroît à mesure que la commande onshore devient chère relativement à la livraison offshore ($w_c/w_o$), de sorte que les portefeuilles ambigus et à fort contexte justifient une couche de commande plus épaisse, et les portefeuilles simples et bien délimités une couche plus mince. La figure 2 trace $C(r)$ et les deux régimes de défaillance de part et d’autre de l’optimum.

8. Un cas construit

Le cas est construit, non observé : ses chiffres sont illustratifs et cohérents entre eux, et il vise à montrer les grandeurs du modèle prenant des valeurs plausibles plutôt qu’à rapporter un résultat. Un groupe occidental mène le développement applicatif de ses systèmes de back-office et, il y a trois ans, en a externalisé l’essentiel auprès d’un prestataire en Inde sous forme de renfort d’effectif : il a conservé une poignée de chefs de projet onshore, rédigé les exigences dans la forme qui avait toujours été la sienne, et mesuré le succès à l’effectif transféré et au tarif journalier économisé. Sur le papier, il avait réduit de moitié le coût d’un développeur. En pratique, la livraison de bout en bout d’une fonctionnalité, de la demande à la modification de production acceptée, s’était allongée, le taux de fuite de défauts vers la production avait augmenté, et une part importante et croissante des heures de l’équipe offshore passait à reprendre des fonctionnalités construites sur une lecture raisonnable mais fausse d’une exigence ambiguë. L’économie était brute ; nette, elle était maigre et déclinante. Le tableau 2 donne la colonne « avant ».

Le groupe a ensuite reconstruit l’engagement autour d’un centre de commande. Il n’a ni changé de prestataire ni rapatrié le travail ; il a ajouté une couche onshore mince et composée de cadres supérieurs, quelques pour cent de l’effectif total, qui a pris en charge les cinq choses de la section 4 : elle a réécrit les exigences en spécifications assorties de critères d’acceptation explicites, redécoupé l’architecture pour que chaque pod offshore détienne un module derrière une interface définie, tenu un backlog unique et ordonné, et exploité une porte de recette avant que quoi que ce soit n’atteigne la production. L’équipe offshore et ses tarifs sont restés inchangés ; ce qui a changé, c’est l’ambiguïté résiduelle $\alpha$ qui l’atteignait. La reprise a chuté à mesure que les spécifications dissipaient la conjecture qui l’avait alimentée, le taux de fuite de défauts a baissé à mesure que la porte interceptait ce que le fossé masquait autrefois, et l’horloge est passée de la latence à une seconde équipe à mesure que les transmissions cessaient d’exiger des allers-retours. Le coût de la commande ajoutée fut une fraction de la reprise qu’elle a supprimée, ce qui est l’équation (5) en pratique : l’engagement tournait loin à gauche de $r^\ast$, et s’en rapprocher a abaissé le coût total alors même qu’il relevait le coût onshore. Le tableau 2 retrace le changement.

9. Ce qui change pour le modèle opérationnel

Adopter le centre de commande change ce en quoi une entreprise doit exceller, et le changement est inconfortable parce qu’il va à l’encontre de l’instinct qui a motivé l’externalisation. L’économie demeure réelle, mais elle n’est captée qu’en dépensant, onshore et à des taux de cadres supérieurs, sur la couche de commande que l’analyse de rentabilité naïve traitait comme un gaspillage à éliminer. Le tableau 3 expose la répartition du travail qu’exige le modèle. La ressource rare devient la poignée de personnes expérimentées capables de bien tenir l’intention, l’architecture et la recette, et la capacité d’externalisation d’une entreprise est bornée par le nombre de telles personnes dont elle dispose, non par le nombre d’ingénieurs offshore qu’elle peut embaucher. La mesure change aussi : l’effectif transféré et le tarif journalier économisé, les chiffres qui font bien paraître l’externalisation du jet par-dessus le mur, sont remplacés par le délai des fonctionnalités, la fuite de défauts et la part des heures offshore consacrées à la reprise, les chiffres qui révèlent si la commande fait son travail.

Il y a un second déplacement, dans l’endroit où siège la séniorité. L’externalisation du jet par-dessus le mur tend à envoyer offshore le travail intéressant et expérimenté avec le reste et à garder au pays une couche de coordination junior ; le modèle du centre de commande inverse cela, gardant la séniorité onshore là où est le contexte et laissant l’équipe offshore exceller à l’exécution sans qu’on lui demande de fournir un contexte qu’elle ne peut pas avoir. On y voit souvent, à tort, une défiance envers l’équipe offshore. C’est l’inverse : c’est l’arrangement qui permet à une équipe offshore compétente de faire son meilleur travail, en ne lui demandant pas de résoudre des ambiguïtés que personne à sa distance ne saurait bien résoudre, et en lui donnant des spécifications assez claires pour que sa compétence soit dépensée à construire plutôt qu’à deviner.

10. Objections et réponses

Le centre de commande ne fait qu’ajouter du coût onshore et éroder l’économie. Il ajoute du coût onshore et accroît l’économie nette, ce qui est tout l’objet de l’équation (5) : la plupart des engagements en échec se situent loin à gauche de $r^\ast$, là où un peu plus de commande supprime bien plus de reprise qu’elle ne coûte. Le centre de commande n’est pas une charge pesant sur l’économie ; il est le mécanisme qui convertit une économie brute en économie nette. Une entreprise véritablement déjà à $r^\ast$ ne devrait pas ajouter de commande ; presque aucune ne l’est.

S’il faut tout spécifier avec une telle précision, pourquoi ne pas simplement construire onshore ? Parce que la spécification et la construction ont des coûts très différents et des raretés très différentes. La spécification est une petite quantité de travail expérimenté et lié au contexte ; la construction est une grande quantité de travail qui n’est pas lié au contexte une fois spécifié. Le modèle envoie la grande quantité, peu coûteuse à localiser, là où elle est abordable, et ne garde au pays que la petite quantité liée au contexte. Réunir à nouveau les deux renonce précisément à l’arbitrage qui est réel.

L’outillage moderne et les appels vidéo ont rendu la distance sans importance. Ils l’ont rendue plus petite, non sans importance, et les preuves que la distance compte encore sont robustes (Olson & Olson, 2000 ; Herbsleb & Mockus, 2003). L’outillage abaisse le coût d’un passage ; il ne supprime pas le jour que l’horloge ajoute à un aller-retour, et ne restaure pas la communication informelle et ambiante que les équipes réunies en un même lieu emploient pour résoudre l’ambiguïté sans même s’en apercevoir. Le centre de commande est la réponse structurelle que l’outillage complète mais ne remplace pas.

Notre partenaire offshore est très compétent et peut tout prendre en charge. La compétence n’est pas le problème ; le contexte l’est. Une équipe offshore très compétente ne peut toujours pas résoudre une ambiguïté dont la résolution exige de savoir ce que le métier voulait dire, et le lui demander dresse sa compétence contre un problème que la distance rend insoluble. Le modèle garde la responsabilité onshore non parce que l’équipe offshore est faible, mais parce que la responsabilité est liée à un contexte qui est onshore.

11. Limites

Il s’agit d’un argument destiné aux praticiens, doté d’un modèle délibérément simple, et ses limites doivent être claires. Le modèle des sections 5 à 7 est illustratif : la forme de l’ambiguïté résiduelle de l’équation (1), le multiplicateur de reprise exponentiel de l’équation (3) et le ratio optimal unique de l’équation (5) sont des simplifications choisies pour la lisibilité, et les constantes $a$, $b$, $w_c$ et $w_o$ ne sont pas mesurées ici ; une entreprise peut les estimer à partir de ses propres données de reprise et de tarifs, et l’on s’attendrait à ce que la forme qualitative, un optimum intérieur qui se déplace avec l’ambiguïté et le coût relatif, subsiste même là où la forme exacte ne tient pas. L’argument se limite au travail dont les ambiguïtés peuvent, moyennant effort, être résolues en spécification ; un travail véritablement de type recherche, où nul ne sait encore ce qu’est le correct, s’accorde mal au modèle et devrait pour l’essentiel rester réuni en un même lieu. L’article s’appuie sur l’Inde parce que c’est là que se trouvent la profondeur de l’offre et l’échelle de la pratique, mais rien dans le modèle n’est propre à un pays ; il s’applique à toute séparation onshore–offshore à travers une distance et une horloge réelles. Et le modèle suppose une entreprise capable, ne serait-ce que de doter une couche de commande expérimentée ; une entreprise qui ne le peut pas devrait reconnaître honnêtement qu’elle n’est pas encore en mesure de bien externaliser, plutôt que d’externaliser mal et d’ériger le résultat en verdict sur l’Inde.

12. Conclusion

L’externalisation du travail informatique vers l’Inde déçoit les entreprises qui externalisent la mauvaise chose : elles expédient la responsabilité en même temps que l’exécution, détachant le travail du contexte et du jugement qui le rendent correct, puis regardent la reprise et l’horloge engloutir l’économie qu’elles étaient venues chercher. Le remède n’est pas de rapatrier le travail, mais de le séparer correctement, en gardant onshore la commande mince et expérimentée qui doit rester auprès du métier, décider quoi construire, détenir l’architecture et les interfaces, transformer l’intention en spécification et tenir la recette, tandis que l’exécution monte en charge en Inde, où le talent est abondant et abordable. Où tracer la ligne est une question à laquelle répond l’ambiguïté résiduelle d’une tâche, et l’art du centre de commande est d’élever la spécification jusqu’à ce que cette ambiguïté soit assez faible pour franchir le fossé ; combien de commande conserver est une question dotée d’un véritable optimum, positif et fini, qui croît avec l’ambiguïté du travail et décroît à mesure que la commande devient chère. Menée ainsi, la distance cesse d’être un impôt et l’horloge de douze heures devient une seconde équipe, et l’arbitrage qui fut toujours réel est enfin préservé. Externalisez la construction ; commandez-la depuis le pays. Une entreprise qui se souvient laquelle des deux est liée au contexte, et laquelle ne l’est pas, peut maîtriser l’externalisation vers l’Inde ; une entreprise qui l’oublie continuera de conclure, à tort, que le problème était l’autre bout de la ligne.

Annexe A. Mettre en place un centre de commande

Les pratiques ci-dessous sont ce qui fait tenir en pratique la séparation de la section 4. Aucune n’est nouvelle ; c’est la discipline qui fait la valeur.

Références

Brooks, F. P. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley. ISBN 978-0-201-83595-3. (Original work published 1975.)

Carmel, E. (1999). Global software teams: Collaborating across borders and time zones. Prentice Hall. ISBN 978-0-13-924218-6.

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2), 22–29. https://doi.org/10.1109/52.914734

Carmel, E., & Tjia, P. (2005). Offshoring information technology: Sourcing and outsourcing to a global workforce. Cambridge University Press. ISBN 978-0-521-84355-4.

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

Herbsleb, J. D., & Grinter, R. E. (1999). Splitting the organization and integrating the code: Conway’s law revisited. In Proceedings of the 21st International Conference on Software Engineering (ICSE) (pp. 85–95). ACM. https://doi.org/10.1145/302405.302455

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481–494. https://doi.org/10.1109/TSE.2003.1205177

Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81. https://doi.org/10.1145/203330.203345

Krishna, S., Sahay, S., & Walsham, G. (2004). Managing cross-cultural issues in global software outsourcing. Communications of the ACM, 47(4), 62–66. https://doi.org/10.1145/975817.975818

Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. Journal of Strategic Information Systems, 18(3), 130–146. https://doi.org/10.1016/j.jsis.2009.06.002

Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys, 26(1), 87–119. https://doi.org/10.1145/174666.174668

Olson, G. M., & Olson, J. S. (2000). Distance matters. Human–Computer Interaction, 15(2–3), 139–178. https://doi.org/10.1207/S15327051HCI1523_4

Oshri, I., Kotlarsky, J., & Willcocks, L. P. (2007). Managing dispersed expertise in IT offshore outsourcing: Lessons from Tata Consultancy Services. MIS Quarterly Executive, 6(2), 53–65. https://aisel.aisnet.org/misqe/vol6/iss2/3/

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623

Ramasubbu, N., & Balan, R. K. (2007). Globally distributed software development project performance: An empirical analysis. In Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2007) (pp. 125–134). ACM. https://doi.org/10.1145/1287624.1287643

Rottman, J. W., & Lacity, M. C. (2006). Proven practices for effectively offshoring IT work. MIT Sloan Management Review, 47(3), 56–63. https://sloanreview.mit.edu/article/proven-practices-for-effectively-offshoring-it-work/

Sahay, S., Nicholson, B., & Krishna, S. (2003). Global IT outsourcing: Software development across borders. Cambridge University Press. ISBN 978-0-521-81604-5.