9 December 20257 min de lecture
Construire ou acheter est l’un des plus vieux débats du logiciel, et il se tient généralement avec une colonne manquante. Construire signifie que vos propres ingénieurs l’écrivent. Acheter signifie que le produit d’un éditeur le fait. Externaliser n’est ni l’un ni l’autre : c’est du logiciel sur mesure qui vous appartient, réalisé par des personnes qui ne sont pas vos salariés, et son profil de risque diffère des deux autres.
L’omettre fausse le raisonnement dans une direction prévisible. Les équipes qui ne peuvent libérer aucune capacité interne concluent qu’elles doivent acheter, puis passent deux ans à tordre leur processus autour d’un produit qui convient presque. Les équipes déterminées à obtenir exactement ce qu’elles veulent concluent qu’elles doivent construire, puis attendent six mois un recrutement. La troisième colonne l’emporte souvent sur les deux, et elle figure rarement sur la diapositive.
Les trois options répondent à des questions différentes
Acheter répond à la question : ce problème est-il le même pour nous que pour tout le monde ? Construire répond à la question : notre version de ce problème est-elle la raison pour laquelle les clients nous choisissent ? Externaliser répond à la question : ce travail nous est-il spécifique sans être ce qui fait notre différence ?
Cette troisième catégorie est énorme et c’est d’elle que vient l’essentiel des déceptions face aux produits sur étagère. Un outil interne qui épouse votre modèle opérationnel. Une intégration entre deux systèmes que vous seul faites tourner ensemble. Une migration hors d’un produit qu’on vous a vendu dans l’urgence. Un portail pour un segment de clients aux besoins inhabituels. Rien de tout cela n’est différenciant. Tout cela est spécifique.
Achetez d’abord, et sincèrement
La position par défaut devrait être d’acheter, et le seuil pour s’en écarter devrait être élevé. Un produit mature a absorbé des années de cas limites auxquels vous n’avez pas pensé, sa maintenance est un problème de masse salariale pour quelqu’un d’autre, et il fonctionne le jour où vous le payez plutôt que le jour où quelqu’un l’a fini.
Les objections honnêtes à l’achat sont peu nombreuses. Le produit ne fait réellement pas la chose, et aucune configuration n’y parvient. Les conditions commerciales passent mal à l’échelle face à votre croissance. Les données doivent résider quelque part où l’éditeur refuse de les mettre, ce qui, pour des acheteurs européens ayant une position stricte sur le traitement des données, est une contrainte réelle et non théorique. Ou la capacité est le produit, auquel cas vous n’étiez de toute façon pas acheteur.
L’objection malhonnête est que « cela ne fonctionne pas comme nous travaillons ». Parfois c’est vrai et coûteux. Souvent cela signifie que le produit incarne un processus plus standard que le vôtre et que l’adopter serait une amélioration dont vous ne voulez pas. Cela mérite d’être nommé avant de consacrer une année d’ingénierie à l’éviter.
Construire en interne ou externaliser la construction
Une fois décidé qu’une chose doit être sur mesure, reste à savoir qui l’écrit, et cela dépend de deux points : la connaissance doit-elle se cumuler en interne, et le travail se poursuivra-t-il après la première version.
- Se cumule, et ne s’arrête jamais : construisez en interne. C’est le cœur du métier, et un salarié accumulant du contexte pendant des années est l’actif.
- Spécifique, et livré une seule fois pour l’essentiel : externalisez. Outillage interne, intégrations, migrations, portails. La connaissance qui compte est de la documentation, pas de l’intuition.
- Spécifique, continu, mais non différenciant : externalisez en pensant à la continuité. La régie avec les mêmes personnes nommées fonctionne mieux ici qu’une succession de projets.
- Incertain sur la catégorie : externalisez délibérément une première version, décidez avec quelque chose de réel sous les yeux, et gardez l’option de réinternaliser.
C’est la dernière ligne qu’on oublie. L’externalisation est un moyen peu coûteux de savoir si une compétence mérite un poste permanent. Recruter pour répondre à cette question coûte un cycle de recrutement et la carrière d’une personne, et y répondre de travers coûte cher à tout le monde.
Les coûts ont des formes différentes, pas seulement des tailles différentes
Comparer les trois sur le seul prix masque ce qui compte : le moment où l’argent est dépensé et ce qui se passe si vous arrêtez.
Acheter est un coût récurrent qui commence petit et croît avec votre usage, et qui s’arrête quand vous cessez de payer, en emportant la capacité avec lui. Construire en interne est un engagement fixe et lourd : recrutement, salaire, cotisations patronales, les mois pendant lesquels le poste reste ouvert, et une personne que vous ne pouvez pas réduire en un trimestre. L’externalisation se situe entre les deux : elle commence quand vous commencez, elle s’arrête sur préavis, et l’actif reste le vôtre.
Menez les trois sur le même horizon, au moins deux ans, et mettez sur la table ce que les gens omettent. Côté achat : la mise en œuvre, le travail d’intégration, la hausse de prix au renouvellement, et le coût du départ. Côté construction : le recrutement, les mois de vacance et l’encadrement. Côté externalisation : la montée en charge d’intégration avant que quiconque ne soit productif, et le temps interne consacré à diriger. Le classement change souvent une fois ces éléments intégrés, et c’est bien l’intérêt de l’exercice.
La réponse à laquelle vous aboutirez probablement
En pratique, la plupart des équipes font les trois, et la compétence utile est de tracer les frontières plutôt que de désigner un vainqueur. Achetez la commodité : identité, paiements, e-mail, analytics, la pile financière. Construisez ce qui explique qu’on vous choisisse. Externalisez la couche spécifique mais non différenciante qui relie les deux, car c’est là que se trouve réellement le volume de travail.
Des frontières tracées ainsi survivent aussi à la croissance. Lorsque la couche externalisée autour d’une compétence devient assez importante pour ne plus paraître périphérique, c’est le signal de la réinternaliser, et vous disposerez à la fois du système en fonctionnement et de la documentation sur laquelle recruter. C’est une bien meilleure position que de trancher dans l’abstrait.
Un ordre de décision qui fonctionne
Posez les questions dans cet ordre et la plupart des cas se règlent en un après-midi. Pouvons-nous l’acheter, honnêtement, y compris en adaptant notre processus ? Si non : est-ce là ce qui nous rend différents ? Si oui, recrutez et patientez. Si non : ce travail va-t-il continuer indéfiniment et se cumuler ? Si oui, prévoyez de l’internaliser à terme et externalisez-le maintenant dans cette perspective. Si non, externalisez-le, gardez le code et les comptes, et passez à quelque chose de plus important.
L’échec que cet ordre évite est le plus courant : une coûteuse construction interne de quelque chose que l’équipe aurait pu acheter, financée en renonçant au travail réellement différenciant, parce que la troisième colonne n’a jamais figuré sur la diapositive.