Le métier que personne ne facture

Un dirigeant nous a décrit son projet au printemps dernier : une application mobile, un site public, un back-office, un budget autour de trois cent mille euros. On lui avait expliqué qu’il lui fallait une agence de stratégie, un studio de design, une société de développement, un hébergeur, et une assistance à maîtrise d’ouvrage pour coordonner les quatre autres. Cinq contrats pour un seul produit.

Sa question n’était pas de savoir si c’était cher. C’était de savoir si c’était normal.

Nous sommes très mal placés pour y répondre. Synograph prend les projets de bout en bout, ce qui nous donne un intérêt commercial direct à ce que la réponse soit « un seul prestataire ». C’est exactement pour cette raison que ce qui suit n’avance aucun de nos arguments. Nous n’utilisons que les chiffres des autres.

Ce qui a déjà été écrit sur la question

Beaucoup de choses, et presque uniquement par des gens qui vendent la réponse.

Du côté anglophone, la littérature tient dans une série d’articles d’agences intitulés « prestataire unique ou prestataires multiples », qui concluent tous dans le sens du métier de celui qui les publie. Les arguments sont symétriques et connus : un interlocuteur unique simplifie la communication, plusieurs prestataires donnent accès au meilleur de chaque spécialité. Aucun de ces textes ne produit la moindre donnée.

En France, la réponse dominante est plus curieuse. Devant un projet éclaté entre plusieurs fournisseurs, l’usage veut qu’on ajoute une assistance à maîtrise d’ouvrage chargée de les coordonner. La solution au problème des cinq acteurs est donc un sixième acteur. Cette réponse est parfois la bonne, et nous dirons plus bas dans quels cas ; elle est rarement présentée comme ce qu’elle est, c’est-à-dire une couche de plus.

Il existe pourtant des données sérieuses sur cette question précise. Elles ne sont pas publiées par des agences, mais dans deux disciplines que les décideurs ne lisent pas : l’économie de l’externalisation et l’économie des projets.

Le seuil existe, et quelqu’un l’a mesuré

Ravi Bapna, Alok Gupta, Gautam Ray et Shweta Singh ont analysé 49 057 contrats d’externalisation informatique conclus entre 1989 et 2014, d’une taille moyenne de 58 millions de dollars. C’est, à notre connaissance, le seul travail empirique à grande échelle sur le choix entre un prestataire et plusieurs. Il en sort trois résultats qu’un décideur devrait connaître.

Le premier est une courbe, pas une règle. Plus un contrat couvre de services différents, plus le recours à plusieurs fournisseurs devient probable, mais seulement jusqu’à cinq services environ. Au-delà, les coûts de coordination dépassent le gain de spécialisation, et le prestataire unique redevient le choix rationnel. Le seuil existe donc, et il est plus bas que l’intuition ne le suggère.

Le deuxième résultat est le plus important, et c’est celui qu’aucun article d’agence ne mentionne. Ce qui décide n’est pas la taille du projet, c’est la capacité du client. Répartir le travail entre plusieurs fournisseurs suppose de savoir spécifier ce qu’on attend de chacun, contrôler ce qu’ils livrent, coordonner leurs calendriers et intégrer leurs livrables. Les auteurs appellent cela les capacités d’externalisation du client. Quand elles existent, le client joue lui-même le rôle d’intégrateur et tire un vrai bénéfice de la spécialisation. Quand elles n’existent pas, la même décision produit l’effet inverse.

Le troisième résultat est une sanction. Sur 1 588 contrats dont l’issue est connue, un mauvais alignement entre la situation et le choix de sourcing prédit l’échec du contrat : annulation ou renégociation. Ce choix n’est pas une préférence d’organisation, il est matériel.

Une réserve s’impose, et nous préférons la poser nous-mêmes. Ces contrats pèsent 58 millions de dollars en moyenne, le vôtre en pèse trois cent mille. Le mécanisme se transpose, le seuil chiffré non. Et s’il se déplace, c’est probablement vers le bas : une entreprise de taille moyenne a moins de capacité d’intégration qu’un grand groupe, pas plus.

Ce que vous achetez en divisant

Un projet confié à n prestataires contient n(n-1)/2 paires susceptibles d’avoir à se parler. Ce n’est pas une étude, c’est de l’arithmétique.

prestataires   paires à tenir
     2               1
     3               3
     4               6
     5              10

En pratique, toutes ces paires ne se parlent pas. Le problème est que vous ne choisissez pas lesquelles, et que vous l’apprenez tard : le jour où le prestataire de paiement impose un comportement que la maquette n’avait pas prévu, ou celui où l’hébergeur découvre que l’application écrit dans un dossier qui n’existe pas chez lui.

Le coût réel n’est pourtant pas là. Il est dans la traduction. Chaque frontière contractuelle est un endroit où le problème d’un utilisateur est réécrit en livrable. Le studio de design livre des écrans conformes au cahier des charges de design. La société de développement livre des fonctionnalités conformes au cahier des charges de développement. Les deux sont en règle. Personne n’a signé pour que quelqu’un y arrive.

Qui tranche, et sur quoi

Yingying Ge

Je prends un exemple ordinaire, parce que c’est toujours sur des choses ordinaires que les projets se perdent.

Un écran de paiement. Le designer veut une seule page, parce que les gens abandonnent entre deux pages et qu’on l’a vu en test. Le développeur veut deux pages, parce que le prestataire de paiement impose une redirection et qu’une page unique obligerait à garder des données qu’il vaut mieux ne pas garder. Les deux ont raison. Ce désaccord n’a pas de solution théorique.

Dans une équipe, il se règle dans l’après-midi. Nous ne cherchons pas qui a raison, nous retournons voir. Notre règle est simple : un désaccord qui porte sur ce que font les gens se tranche en regardant des gens le faire, jamais en réunion. Si personne n’a d’observation récente, nous allons en chercher une. Cela prend deux jours, rarement davantage. Nous appelons cela l’arbitrage par l’observation, et c’est la seule autorité que nous reconnaissons à l’intérieur d’un projet : ni le titre, ni l’ancienneté, ni celui qui a parlé en dernier.

Entre deux contrats, le même désaccord ne se règle pas de cette façon. Il remonte. Il arrive chez le client, c’est-à-dire chez la personne qui a le moins d’information des trois, et qui doit arbitrer entre deux fournisseurs ayant chacun une raison contractuelle d’avoir raison. La décision se prend alors sur le rapport de force, sur le calendrier, ou sur la fatigue.

J’ai appris ce métier à Shanghai, dans des équipes où la question ne se posait pas, parce que la personne qui répondait aux messages des clients était assise dans la même pièce que celle qui écrivait le code. Ce n’est pas une affaire de culture. C’est une affaire de distance : le temps qu’une observation met à atteindre quelqu’un qui a le droit d’agir. Chaque contrat supplémentaire allonge ce temps, et il est plus facile de le mesurer que de le corriger.

Un coordinateur ne rachète pas le risque

L’idée d’ajouter un acteur dont le métier est de coordonner les autres paraît presque gratuite : elle ne change rien au travail, elle ajoute seulement du contrôle. Cette hypothèse a été testée ailleurs, sur un sujet voisin.

Les travaux de DORA sur les organisations de développement logiciel ont cherché à établir qu’une validation formelle et externe réduisait le taux d’échec des mises en production. Ils n’ont trouvé aucune preuve d’un tel lien. Pire : ces dispositifs ralentissent la livraison, ce qui conduit à livrer par lots plus gros et moins souvent, donc à augmenter le risque qu’ils étaient censés réduire.

Ce résultat ne dit pas qu’il ne faut pas contrôler. Il dit qu’un contrôle exercé par quelqu’un qui n’a pas fait le travail ne produit pas de sécurité, seulement un délai. Appliqué à la coordination de prestataires, cela donne une distinction utile : un coordinateur qui ne sait pas construire ne peut pas arbitrer un compromis technique, il peut seulement le transmettre. Et un compromis transmis revient au client.

Il y a pourtant des situations où une assistance indépendante est le bon choix, et elles sont identifiables. Quand plusieurs fournisseurs sont imposés et irréductibles, un ERP déjà en place, une banque, un système historique que personne ne remplacera, la coordination devient un métier à part entière et il vaut mieux la confier à quelqu’un qui n’est pas juge et partie. Ce qui ne marche pas, c’est d’utiliser ce rôle pour réparer après coup un découpage qu’on n’aurait pas dû faire.

Le risque est dans la queue, pas dans la moyenne

Reste la question qu’un décideur se pose vraiment : est-ce que tout cela change le résultat ?

Bent Flyvbjerg et ses coauteurs ont réuni 5 392 projets informatiques et examiné la distribution de leurs dépassements. Le rapport entre coût réel et coût estimé a une médiane de 1,0 et une moyenne de 1,8. Autrement dit : la moitié des projets tiennent à peu près leur budget, et la moyenne est presque au double. Tout l’écart est dans la queue.

Cette queue n’est pas un accident d’échantillon. Elle suit une loi de puissance, et sur une partie de son domaine l’exposant est tel que ni la variance ni la moyenne ne sont définies. Les auteurs l’écrivent sans détour : la moyenne des dépassements de coût des projets informatiques n’existe pas. Les désastres ne sont pas des anomalies, ce sont les valeurs extrêmes d’une distribution parfaitement régulière.

Un travail plus récent des mêmes auteurs, mis en ligne en mai 2025 dans Project Management Journal, compare l’informatique à vingt-deux autres types de projets. Le verdict est net : la queue du risque informatique est plus épaisse que celle de n’importe quelle autre catégorie, ponts, tunnels et centrales compris. Les explications habituelles sont au nombre de quatre : immaturité, intangibilité, ambiguïté des objectifs, résistance des parties prenantes.

L’inférence qui suit est la nôtre et non la leur. Deux de ces quatre causes, l’intangibilité et l’ambiguïté des objectifs, sont exactement ce qu’une frontière contractuelle multiplie. Chaque contrat supplémentaire est un endroit où l’on réécrit noir sur blanc ce que l’on est en train de construire, souvent des mois plus tard, et souvent par des gens qui n’étaient pas dans la pièce le jour où cela s’est décidé.

Pour un acheteur, la conséquence est directe. Comparer trois devis, c’est comparer trois médianes. Ce qui détruit un projet se trouve dans la queue, et la queue ne figure sur aucun devis. Elle ne dépend pas du prix, mais d’une autre question : qui répond quand elle arrive.

Cinq questions avant de signer

Aucune ne présume de la réponse. Elles se posent aussi bien à nous qu’à cinq prestataires.

1. Qui intègre ? Faites nommer une personne, pas une société, et faites-la figurer au contrat. Si personne n’est nommé, l’intégrateur, c’est vous.
2. Que se passe-t-il quand le designer et le développeur ne sont pas d’accord ? Un prestataire qui répond « on en discute » n’a pas de méthode. Demandez la dernière fois que c’est arrivé, et comment cela s’est terminé.
3. Combien d’interfaces, et lesquelles ? Comptez les frontières, pas les fournisseurs. Une frontière propre et documentée par quelqu’un d’autre, un prestataire de paiement par exemple, ne coûte presque rien. Une frontière au milieu du produit coûte en permanence.
4. Que gardons-nous si nous arrêtons demain ? Le dépôt de code, l’infrastructure décrite en code, les comptes et les noms de domaine à votre nom, les procédures écrites pour quelqu’un qui n’était pas là.
5. Qui est appelé la nuit, et à quel numéro ? C’est la seule question dont la réponse ne peut pas être partagée entre cinq sociétés.

Le principe qui les résume tient en une ligne : découpez là où l’interface existe déjà et où quelqu’un d’autre la maintient, ne découpez pas le produit lui-même.

Ce que cette position nous coûte

Arnaud Beaussier

Elle a un prix, et le passer sous silence serait malhonnête.

Une équipe qui tient toute la chaîne ne peut pas être la meilleure sur chaque maillon. Nous n’aurons jamais le banc de test d’un laboratoire d’ergonomie spécialisé, ni la profondeur d’une société de mille développeurs sur une technologie précise. Il existe des projets pour lesquels nous sommes le mauvais choix, et nous préférons le dire avant de signer plutôt qu’au sixième mois.

Il y a aussi une contrepartie que nous devons au client, et elle est technique. Prendre toute la chaîne, c’est accepter de devenir un point de dépendance. La seule réponse honnête à cela est la réversibilité, et la réversibilité se construit, elle ne se promet pas : le dépôt de code est chez vous dès le premier jour, l’infrastructure est décrite en code plutôt que configurée à la main, les comptes et les noms de domaine sont à votre nom, les procédures d’exploitation sont écrites pour quelqu’un qui n’était pas là. Une équipe qu’on ne peut pas remplacer n’est pas un partenaire, c’est une dette.

Le bon indicateur n’est donc pas le nombre de prestataires sur votre projet. C’est le nombre de personnes qui doivent se mettre d’accord avant que quelqu’un puisse corriger quelque chose pour un utilisateur réel. Comptez-le avant de signer. C’est souvent ce chiffre-là qui décide de la suite.