Make or buy : pourquoi développer son logiciel en interne coûte plus cher qu'il n'y paraît

Le débat « faut-il construire ou acheter » n'est pas nouveau, mais il revient à chaque cycle technologique avec les mêmes arguments et, souvent, la même erreur de calcul : traiter le développement interne comme une dépense ponctuelle, et l'achat d'un logiciel comme un abonnement récurrent qui s'accumule dans le temps. En réalité, les deux sont récurrents — seul l'un des deux apparaît clairement sur une facture.

Le mythe du logiciel interne « gratuit »

Un logiciel construit en interne n'a jamais un coût nul, même quand il ne figure sur aucune ligne budgétaire dédiée. Il mobilise du temps d'ingénieur qui aurait pu aller ailleurs, un budget de maintenance qui grossit avec chaque nouvelle fonctionnalité, et une charge de sécurité (mises à jour de dépendances, correctifs de vulnérabilités) qu'un éditeur SaaS mutualise sur des centaines de clients quand une seule entreprise la porte pour elle-même. Le développement interne d'un outil de gestion de dépenses, par exemple, ressemble à un projet fini. En réalité, c'est un produit qu'il faut maintenir indéfiniment, avec une seule équipe qui absorbe seule tout le coût de possession.

La dette technique que personne ne budgète

Le vrai risque du logiciel maison n'apparaît pas à sa mise en production, mais deux ou trois ans plus tard, quand l'ingénieur qui l'a construit a quitté l'entreprise et que plus personne ne comprend entièrement comment il fonctionne. L'outil continue de tourner, mais chaque modification devient plus lente et plus risquée, jusqu'à ce qu'il finisse traité comme une boîte noire qu'on préfère ne plus toucher. Un éditeur logiciel, lui, a une équipe dédiée dont c'est le métier à plein temps — la continuité ne dépend pas d'une seule personne.

Le coût d'opportunité, le plus difficile à voir

Chaque semaine passée par une équipe d'ingénierie à construire un outil interne de reporting, de suivi de dépenses ou de gestion de contrats est une semaine qui n'est pas passée sur le produit qui génère réellement du revenu. Ce coût ne remonte jamais dans un tableau de dépenses logicielles — il n'apparaît nulle part, précisément parce qu'il ne s'agit pas d'une dépense mais d'un renoncement. C'est souvent l'argument le plus solide en faveur de l'achat : une entreprise qui n'est pas éditeur de logiciels a rarement intérêt à en devenir un, même pour un seul usage interne.

L'IA accélère les éditeurs plus vite qu'elle n'accélère le développement interne

Les assistants de code IA rendent effectivement plus rapide la construction d'un outil interne — mais ils accélèrent tout autant, sinon davantage, les éditeurs SaaS, qui amortissent ce même gain de productivité sur des centaines ou des milliers de clients à la fois, plutôt que sur un seul usage interne. Gartner prévoit que 40% des applications d'entreprise intégreront des agents IA spécialisés par tâche d'ici 2026, contre moins de 5% en 2025 — un rythme d'innovation qu'une équipe interne, déjà occupée à faire tourner le produit principal de l'entreprise, ne peut structurellement pas répliquer sur un outil secondaire.

Une compétition plus dure entre éditeurs, donc de meilleurs prix pour les acheteurs

McKinsey observe que l'adoption d'agents IA en entreprise s'accélère nettement, et Gartner documente déjà comment les architectures multi-agents deviennent un axe de différenciation concurrentielle entre éditeurs. Ce mouvement joue en faveur de l'acheteur, pas contre lui : plus les éditeurs se différencient par l'IA plutôt que par le verrouillage contractuel, plus il devient facile de comparer, de renégocier ou de changer de fournisseur en cours de route — une option qu'un logiciel interne, par définition, n'offre jamais.

Acheter, mais garder le contrôle

Le vrai risque du « buy » n'est pas le modèle en lui-même, c'est de perdre la visibilité sur ce qui a été acheté au fil du temps : les mêmes entreprises qui choisissent d'acheter plutôt que de construire sont aussi celles qui accumulent le plus rapidement des dizaines d'outils SaaS sans vue d'ensemble. La bonne question n'est donc pas « faut-il acheter », mais « comment acheter sans perdre le contrôle » — un problème de visibilité, pas un argument en faveur du développement interne.