Ce que veut vraiment dire externalisation informatique
L'externalisation informatique, c'est payer une société extérieure pour faire un travail technique que vos propres salariés feraient autrement. C'est toute la définition, et seule, elle ne sert pas à grand-chose.
Elle recouvre des dispositifs qui n'ont presque rien en commun. Une banque qui paie un prestataire pour patcher ses serveurs externalise. Une société produit qui ajoute trois développeurs à une équipe existante externalise. Un distributeur qui remet un cahier des charges signé et récupère une application neuf mois plus tard externalise. Ces trois contrats diffèrent sur le prix, sur qui décide, sur qui est en faute, et sur ce qui se passe quand le besoin change. Un seul mot pour les trois, c'est ainsi qu'un acheteur signe pour un dispositif en attendant l'autre.
Autant le dire tout de suite : nous vendons ce service. Lisez la section sur les cas où il ne faut pas externaliser avant de peser quoi que ce soit ici.
Les cinq choses que le mot recouvre
La régie. Vous ajoutez des ingénieurs nommés à votre équipe. Ils travaillent à vos horaires, dans vos dépôts, sous votre lead technique, sur les tickets de votre board. Vous gardez la feuille de route, les standards et le bouton de merge. Le prestataire porte le recrutement, la paie et le risque d'intercontrat. C'est ce que la plupart des acheteurs européens ont en tête, et c'est le dispositif qui transfère le moins de responsabilité des cinq. Si la mauvaise chose est construite, c'est vous qui l'avez construite. Nous vendons ça sous le nom de régie informatique : de la capacité élastique, pas un décideur.
L'équipe dédiée. Des ingénieurs qui travaillent uniquement sur votre produit, mais comme une unité, avec son lead et son exigence. Vous donnez la direction, vous ne gérez pas les individus. Ça ressemble à de la régie sur la facture et ça se comporte comme un petit département externalisé, ce qui en fait le plus mal compris des cinq.
Le forfait. Vous décrivez le résultat, vous convenez d'un périmètre et d'un prix, et le prestataire livre. Prix ferme, une date, parfois des pénalités. La responsabilité de la livraison change réellement de main. L'intérêt de lire le cahier des charges dans le sens le moins coûteux à construire aussi.
L'infogérance. Le prestataire fait tourner quelque chose en continu au lieu de le construire une fois. Infrastructure, cloud, supervision, patching, support, sauvegarde et restauration. Vous achetez un taux de disponibilité et un délai de prise en charge, pas une fonctionnalité. C'est le seul modèle où le prestataire a intérêt à ce que ce soit ennuyeux. Nous faisons ça sous le nom d'infogérance.
Le BPO. Une fonction métier plutôt que technique. Support client, traitement de dossiers, facturation. C'est compté comme de l'externalisation informatique parce que le travail passe par vos systèmes, mais les modes de défaillance sont assez différents pour ne pas le planifier avec les autres.
L'essentiel de la confusion à l'achat vient de deux parties qui emploient un seul mot pour deux de ces dispositifs à la fois. Un côté dit externalisation en pensant à des renforts sous son propre lead technique, l'autre entend nous prenons le besoin et nous revenons quand c'est construit, et le désaccord apparaît au troisième mois. Faites dire à la salle duquel des cinq vous parlez. Ça prend une phrase et ça économise un trimestre.
Pourquoi les entreprises le font vraiment
Quatre raisons reviennent, et elles ne sont pas également honnêtes.
La capacité. Plus de travail que de gens, et recruter prend des mois. C'est la vraie raison la plus fréquente et celle qui résiste le mieux à l'examen. Un CDI est un engagement pluriannuel en face d'un besoin de huit mois.
La vitesse. Recruter un ingénieur senior en Europe de l'Ouest est lent et sans garantie au bout. L'externalisation comprime ça en quelques semaines.
Des compétences que vous ne pouvez pas recruter. Quelqu'un qui a mené une migration Kubernetes, construit une intégration de paiement sous DSP2, ou fait de l'ingénierie de données à un volume que votre équipe n'a jamais vu, pour quatre mois et pas pour toujours.
Le coût. C'est la raison qui figure dans le business case et celle qui prédit le plus mal la satisfaction. Les écarts entre régions sont réels, mais le coût par jour n'est pas le coût de la livraison. Un ingénieur moins cher à qui il faut expliquer le besoin deux fois, dans un fuseau où la deuxième explication arrive demain, peut coûter plus cher par fonctionnalité livrée qu'un ingénieur cher assis dans votre après-midi. Le tarif journalier est visible, le coût d'une boucle de décision lente ne l'est pas, et c'est l'invisible qui décide de la satisfaction.
Ce qui dérape, un : le processus parallèle
Le meilleur indicateur d'un contrat raté, c'est un second processus qui tourne à côté du vôtre.
Ça commence raisonnablement. Le prestataire a son outillage, propose son board, travaille dans son dépôt et livrera dans le vôtre à la fin. Il a sa définition du fini, écrite et sensée, pas tout à fait la même que la vôtre. Personne ne proteste, chaque décision se défend isolément.
Puis le travail avance. Deux boards, donc deux vérités sur ce qui est en cours. Deux dépôts, donc l'intégration devient un jalon au lieu d'un fait quotidien. Deux définitions du fini, donc le leur est une fonctionnalité qui passe leurs tests et le vôtre est une fonctionnalité en production.
L'échec arrive à la fin et il a toujours la même tête. Le prestataire a terminé, rien ne marche dans votre environnement, et personne ne ment : les deux camps ont respecté leur propre définition du mot. L'effort d'intégration que personne n'avait budgété est sur le chemin critique, et la discussion sur qui le paie commence.
Le remède n'a rien de séduisant et ne coûte rien. Un seul board. Votre dépôt. Vos standards de revue. Votre définition du fini. Si un prestataire hésite quand vous demandez si ses ingénieurs commiteront dans votre dépôt selon votre processus de revue, vous venez d'apprendre la chose la plus utile qu'un rendez-vous commercial puisse vous apprendre. Un processus parallèle dans le même immeuble échoue pareil : la localisation n'est pas la variable.
Ce qui dérape, deux : le piège du cahier des charges
Le second échec appartient au forfait, et il est structurel plutôt que la faute de quelqu'un. Vous écrivez un cahier des charges détaillé, relu, signé. Le prestataire le chiffre et construit précisément ce qui est écrit. Des mois plus tard vous recevez exactement ce que vous avez demandé, et c'est faux, parce qu'un besoin logiciel est rarement entièrement connu au départ. Il se précise pendant qu'on construit. Ce n'est pas un échec de vos analystes, c'est la nature du travail.
Les intérêts se retournent alors. Chaque modification devient un avenant avec un chiffre au bout. Le prestataire ne fait pas de difficultés : il a chiffré un prix ferme contre un périmètre ferme et il a raison de défendre sa marge. Mais vous avez construit une relation dans laquelle apprendre quelque chose sur votre propre produit est une dépense. Le geste rationnel devient d'arrêter d'apprendre et d'accepter la mauvaise version pour éviter la facture. C'est ça, le piège : il sanctionne exactement le comportement qui fait les bons logiciels.
Le forfait fonctionne quand le périmètre est réellement connaissable à l'avance : une migration avec une entrée et une sortie définies, la refonte d'écrans qui marchent déjà. Vous achetez de la certitude et le prestataire peut chiffrer le risque honnêtement. Il fonctionne mal dès que vous construisez quelque chose que personne n'a construit avant. Là, achetez du temps et de la compétence, gardez un cahier des charges souple et gardez la décision. Vous paierez les changements dans les deux cas, et en régie vous les payez sans négociation accrochée à chacun.
Qui porte le risque, et qui décide
Les modèles se distinguent sur deux axes qui bougent ensemble. En régie, vous prenez toutes les décisions et vous portez tout le risque, et la seule vraie garantie du prestataire, c'est qu'une personne qualifiée arrive et soit remplacée à ses frais si elle ne convient pas. Au forfait, le prestataire porte le risque de livraison et prend en échange l'autorité sur la manière de construire, donc piloter ce travail au jour le jour revient à payer une prime de risque pour un contrôle que vous avez gardé. L'infogérance est le cas à part : le risque y est continu au lieu d'être accroché à une livraison, et on y surveille la frontière entre ce qui est dans le service et ce qui est un projet facturable.
N'achetez donc jamais un dispositif où la responsabilité et l'autorité sont à deux endroits différents. Soit vous décidez et vous assumez le résultat, soit ils décident et ils l'assument. Tout contrat qui sépare les deux finit dans la même réunion.
Comment choisir
Commencez par une question. Le besoin est-il connu, ou se précisera-t-il pendant la construction ?
S'il est réellement connu, le forfait vous est ouvert, et c'est le seul modèle qui donne une certitude de prix. S'il se précisera en avançant, ce qui est le cas de la plupart du travail produit, achetez de la capacité et gardez la décision : de la régie si vous avez un lead technique avec de la marge pour encadrer plus de monde, une équipe dédiée si vous préférez acheter le lead aussi. Une société sans leadership technique interne qui achète de la régie pure, c'est la manière la plus discrète de rater ce contrat. Si le travail est de l'exploitation continue et pas de la construction, c'est de l'infogérance, et vous comparez des délais de prise en charge plutôt que des tarifs journaliers.
Posez ensuite la seconde question. Quelle part du travail est du débit contre une spécification stable, et quelle part est des décisions par jour ? Le débit voyage bien à travers les fuseaux. Les décisions, non. L'Inde est à quatre heures et demie d'avance sur l'heure d'Europe centrale en hiver, donc une journée de travail indienne standard recouvre une journée européenne d'environ neuf heures à quatorze heures. Pour du travail spécifié, c'est très bien et l'avantage de coût est réel. Quand quelqu'un a besoin d'une réponse à quinze heures pour continuer, c'est un impôt quotidien. C'est tout l'argument de l'externalisation informatique en nearshore, et il vaut ce que vaut votre fréquence de décision.
Quand il ne faut pas externaliser du tout
Si le travail est votre différenciateur central et que la connaissance doit rester dans votre société, l'externaliser est en général une erreur, et je préfère le dire franchement plutôt que de vous vendre quelque chose que vous regretterez.
Le test n'est pas de savoir si le travail est technique. Le test, c'est ce qui se passe si le prestataire s'en va. Si un concurrent pouvait engager les mêmes prestataires et obtenir un système comparable, ce système n'est pas votre avantage et c'est une chose sensée à externaliser. Si ce qui vous rend bon est la compréhension accumulée dans ce code, chaque décision prise en dehors de votre société est une connaissance qui part le jour où un ingénieur change de compte.
En pratique : le moteur de tarification, la logique d'appariement, la chose pour laquelle vos clients vous paient, gardez-les à l'intérieur. Le back-office, les intégrations, l'infrastructure, la deuxième application mobile, externalisez sans hésiter. Presque personne ne regrette d'avoir externalisé la périphérie. Beaucoup regrettent d'avoir externalisé le centre.
Un autre cas où la réponse est non. Si personne en interne n'a à la fois l'autorité et le temps de piloter le travail, ne commencez pas : l'externalisation ne fabrique pas de leadership technique, elle en consomme.
Où nous nous situons
Nous sommes du côté de l'offre, donc lisez ceci comme intéressé. Nous faisons de la régie et des équipes dédiées pour des sociétés européennes, avec de l'ingénierie depuis Rabat et Casablanca en UTC+1, soit la même journée de travail que Bruxelles, Paris et Amsterdam, et une contractualisation par notre entité belge, en euros, sous droit belge. Nous ne prenons pas de forfait sur un besoin encore en train de se former, pour la raison décrite plus haut. Et si ce que vous voulez externaliser est ce que votre société sait bien faire, le conseil de la section précédente est celui que vous obtiendrez de nous au téléphone.