Le coût d'opportunité du temps d'un ingénieur : faire soi-même ou acheter tout prêt

La décision de développer soi-même ou d'acheter un produit prêt à l'emploi fait souvent l'objet d'un débat fondé sur une comparaison erronée dès le départ : d'un côté, la facture mensuelle des services ; de l'autre, zéro, car le développement en interne « ne coûte que le temps de l'équipe ». Or, ce temps est justement le poste le plus coûteux du bilan. Il n’apparaît nulle part, tout simplement parce que personne ne l’facture.

Cet article tente de réaliser une chose simple : attribuer une valeur à cette période, élaborer un modèle sur cinq ans avec des hypothèses clairement énoncées, puis voir ce que les chiffres révèlent. Tout modèle comporte des erreurs, mais un modèle erroné que l'on peut identifier vaut mieux qu'une intuition erronée impossible à vérifier.

Tout d'abord, combien coûte une heure de travail d'un ingénieur ?

Ce n’est pas le salaire divisé par le nombre d’heures. Le coût réel d’une heure de travail d’un ingénieur comprend le salaire, les cotisations sociales, le matériel, le poste de travail, les logiciels, le recrutement, la gestion — et surtout, le temps non consacré à l’écriture de code : réunions, entretiens, congés, lecture de documents, attente de révision. La conversion habituelle correspond à 1,5 à 2 fois le salaire brut, divisé par le nombre d’heures réellement travaillées et non par le nombre d’heures de présence.

Les chiffres varient selon les endroits, et je ne vais pas me risquer à deviner à votre place. À partir de là, tout est calculé en heures d'ingénieur. Il vous suffit de multiplier ce chiffre par votre tarif horaire à la dernière étape.

Un plan quinquennal

Supposons qu’il existe un système pour lequel l’estimation initiale est de « deux semaines » — soit 80 heures. Comparons-le à un service prêt à l’emploi qui effectue la même tâche. Voici les hypothèses :

Le chiffre de 360 heures n’a pas été inventé de toutes pièces pour discréditer l’option du développement en interne ; nous le décomposerons en différents postes dans la suite. Quant aux 72 heures de maintenance par an, elles représentent 20 % de l’effort initial — un pourcentage courant pour les logiciels internes encore en service.

Le seuil de rentabilité, et dans quelle mesure est-il sensible ?

L'écart entre les deux courbes est de 496 heures sur 60 mois, soit environ 8 heures d'ingénierie par mois. Il s'agit du seuil de rentabilité : tout service coûtant moins de 8 heures d'ingénierie par mois revient moins cher que de le réaliser soi-même, selon les hypothèses ci-dessus.

Avec la plupart des outils d'infrastructure courants, 8 heures d'ingénierie par mois constituent une allocation généreuse. C'est pourquoi l'idée selon laquelle « il est plus économique de développer soi-même » est si souvent erronée.

Mais un modèle n’est fiable que si l’on sait où il présente des failles. Essayons de modifier chacune des hypothèses :

La dernière ligne est la plus importante. Le modèle ci-dessus repose sur l'hypothèse d'un loyer fixe. De nombreux services sont facturés en fonction de la consommation, et le prix que vous signez la première année n'est pas forcément celui que vous paierez la quatrième année.

Pourquoi « deux semaines » correspondent-elles à 360 heures ?

L'estimation « deux semaines suffisent » s'avère presque toujours exacte pour une version fonctionnelle : une version de démonstration, qui suit correctement le flux, avec des données propres. Ce n'est pas faux — mais cela répond à une autre question que celle que vous posez.

La différence réside dans tout ce dont personne ne parle lors de la réunion d’estimation : les données erronées, les utilisateurs qui cliquent deux fois sur un bouton, les personnes malveillantes qui tentent d’abuser du système, la gestion des droits d’accès, les journaux de bord permettant de déterminer ce qui s’est passé à trois heures du matin, et la documentation nécessaire pour qu’une deuxième personne ose s’y attaquer. Aucun de ces éléments n’est passionnant, et c’est précisément pour cette raison qu’aucun n’a été pris en compte dans l’estimation.

Une méthode approximative mais qui fonctionne : multiplier l'estimation initiale par trois. Ce n'est pas que l'ingénieur ait mal estimé, mais que la question a été systématiquement mal comprise.

Les quatre postes du modèle ci-dessus ne sont pas pris en compte

Coût d'opportunité. Neuf mois passés à développer soi-même, ce sont neuf mois pendant lesquels cette fonctionnalité n'est pas encore disponible. Si ce que vous développez empêche de générer des revenus, le coût réel n'est pas de 360 heures, mais de 360 heures plus neuf mois de revenus perdus.

Coûts liés à la coordination. Le code écrit en interne doit être revu, nécessite une personne de veille, implique une présence aux réunions d'architecture et requiert que quelqu'un se souvienne de son existence lors des mises à jour de la bibliothèque. Ces coûts augmentent en fonction du nombre de personnes dans l'équipe et non du nombre de lignes de code.

Sécurité et conformité. Un système d’authentification développé en interne est un système que vous devez sécuriser vous-même. Si votre travail est soumis à une norme quelconque, c’est également à vous qu’il revient d’en prouver la conformité.

Coûts de sortie. Cet élément concerne les deux camps et est souvent le plus négligé. Combien coûte l'abandon d'un service clé en main ? Combien coûte l'abandon d'un système développé en interne et profondément intégré à dix autres systèmes ? Cette question est si importante qu'elle mérite de constituer un axe à part entière.

Cadre de décision : deux axes, et non un seul

On conseille souvent de se demander : « Est-ce que c’est cela qui incite les clients à nous choisir ? ». C’est une bonne question, mais elle ne représente qu’une partie de la réponse. L’autre partie : si, dans trois ans, cette décision s’avère erronée, combien coûtera-t-il de revenir en arrière ?

La zone la plus dangereuse est le coin supérieur droit : des éléments qui ne font pas de différence, mais qui vous enferment dans un carcan. Paiement, authentification, base de données. On est très tenté de céder à la tentation en se disant « ce n’est pas le cœur du système », puis, trois ans plus tard, on se rend compte que la moitié du système utilise le langage de ce fournisseur et qu’on ne peut plus s’en débarrasser. Dans ce cas, l’achat reste souvent le bon choix — mais il faut intercaler sa propre couche d’interface dès le départ, tant que cela ne coûte pas cher.

Quand « acheter tout prêt » est une mauvaise décision

Quatre types d'échecs courants, classés par ordre de fréquence :

• Les prix changent lorsque vous êtes bien établi. Vous ne négociez plus en position de force, celle de quelqu’un qui peut partir.
• L'échelle inverse le calcul. Le modèle tarifaire du service est conçu pour un utilisateur moyen. Au-delà de ce seuil, vous payez pour une commodité dont vous n'avez plus besoin.
• Le fournisseur change d’orientation ou disparaît. Le produit est racheté, abandonné ou réorienté vers une autre clientèle.
• Ce dont vous avez besoin s’éloigne progressivement de ce qu’ils vendent. Vous finissez alors par écrire du code pour contourner le produit — et vous perdez ainsi l’avantage initial.

Quand on le fait soi-même correctement, même si ce n'est pas le cœur

Deux exemples publics, tous deux d'une ampleur telle que le calcul s'inverse.

Entre 2015 et 2016, Dropbox a transféré la majeure partie des données de ses utilisateurs d’Amazon S3 vers son infrastructure interne. Son dossier d’introduction en bourse fait état d’économies d’environ 75 millions de dollars au cours des deux années suivantes. Le stockage n’est pas la raison pour laquelle les clients choisissent Dropbox, mais à cette échelle, une différence de quelques pour cent par téraoctet représente un montant supérieur au coût de la constitution d’une équipe.

37signals a abandonné le cloud entre 2022 et 2023 et a annoncé des économies d’environ deux millions de dollars par an. L’entreprise a également précisé les conditions requises : une charge de travail relativement stable, une équipe d’exploitation réduite mais compétente, et aucune nécessité de s’adapter à des pics de demande soudains.

Le point commun n’est pas de « faire moins cher soi-même ». Le point commun, c’est que les deux ont envisagé l’option de l’achat tout prêt suffisamment longtemps pour savoir exactement ce dont ils avaient besoin, avant de se lancer dans la construction. C’est là le bon ordre des choses, et cela va à l’encontre de la manière dont la plupart des décisions de construire soi-même sont prises — c’est-à-dire construire d’abord, comprendre ensuite.

La troisième voie que la question binaire néglige

• Une solution open source que l'on gère soi-même. Ni à acheter, ni à développer. Maîtrisée et sans verrouillage, mais en contrepartie, il faut s'occuper soi-même de son fonctionnement. C'est souvent une case que l'on oublie dans le débat « acheter ou faire ».
• Acheter puis réemballer. Utiliser le service, mais en l’appelant uniquement via une interface personnalisée. Cela prend quelques jours supplémentaires au départ, et transforme le « coût de sortie » d’un projet en une semaine de travail.
• Acheter d’abord, développer ensuite. Utiliser ce qui existe jusqu’à ce que l’on comprenne clairement les besoins réels, puis décider s’il faut développer ou non. C’est exactement ce qu’ont fait Dropbox et 37signals.
• Construire une fine couche par-dessus une base achetée. La partie qui fait la différence est la vôtre, la partie ennuyeuse, on laisse les autres s’en charger.

La taille de l'équipe modifie le calcul

Pour une personne travaillant seule, le coût d'opportunité représente pratiquement la totalité : chaque heure consacrée aux systèmes annexes est une heure qui n'est pas consacrée au produit, et personne d'autre ne prend en charge la maintenance. Le seuil d'achat devrait être bien inférieur à ce que l'on pourrait croire.

Avec une équipe de quelques dizaines de personnes, les coûts liés à la coordination et le risque de départ des collaborateurs se font sentir : un système développé en interne et que seule une personne comprend constitue une dette dont l'échéance approche.

Dans une grande organisation, la taille commence à tout bouleverser — et ce n’est qu’à ce stade que la création d’une équipe dédiée au développement du système interne prend tout son sens.

Faites en sorte que cette décision puisse être réexaminée

La plupart des décisions d'achat ou de réalisation sont prises une fois pour toutes, sans que personne n'y jette un second regard, alors que toutes les hypothèses sur lesquelles elles reposent sont vouées à changer. Voici trois mesures peu coûteuses qui permettent de remédier à cela :

• Notez les hypothèses sur lesquelles repose votre décision : estimation du nombre d'heures, du prix de l'abonnement, de la durée de vie prévue. Un paragraphe suffit.
• Mesurez réellement le temps de maintenance. Si vous ne le faites pas, vous ne saurez jamais si ce chiffre de 20 % est valable ou non dans votre cas.
• Prévoyez un bilan au bout de 12 mois. Non pas pour changer quoi que ce soit, mais pour comparer vos hypothèses à la réalité — c’est la seule façon d’améliorer vos prochaines estimations.

En résumé

Le développement en interne n'est pas gratuit, il n'y a simplement pas de facture. Si l'on convertit cela en heures d'ingénierie et que l'on étend la période sur cinq ans, le coût de location permettant d'atteindre le seuil de rentabilité est souvent bien plus élevé qu'on ne le pense intuitivement — dans le modèle ci-dessus, il s'élève à environ 8 heures d'ingénierie par mois.

Mais ce chiffre importe moins que l’habitude qui l’a généré. Évaluez le temps, précisez vos hypothèses, ajoutez un axe des coûts de sortie à côté de celui des écarts, et fixez une date de réévaluation. La décision peut toujours s’avérer erronée — mais vous vous en rendrez compte, au lieu qu’elle ne vous coûte en silence pendant cinq ans.