Introduction

La démonstration est souvent faite en direct : un associé ouvre un assistant de code, génère en vingt minutes un prototype de tableau de suivi, et la salle est conquise. Le devis mental est bouclé : un développeur, un LLM et l'affaire est faite.

La démonstration est vraie. Le devis est faux. Car ce que le prototype de vingt minutes ne montre pas, c'est tout ce qui sépare un prototype d'un logiciel en production dans une société de gestion : l'administration de l'application, la gestion des droits, la sécurité, les sauvegardes, la conformité, la transformation d'un besoin flou en spécification puis en développement testé, la roadmap qui ne s'arrête jamais parce que le métier ne s'arrête jamais. 

La recherche en génie logiciel le dit depuis quarante ans : la maintenance et l'évolution représentent, selon les études classiques, de 40 à 80% du coût total d'un logiciel sur son cycle de vie, bien davantage que son développement initial [1]. Les LLM ont divisé le coût de la première version. Ils n'ont pas divisé le coût des cinq années suivantes.

Cette fiche se joue en deux temps : d'abord les comptes, aujourd'hui, chiffres à l'appui. Ensuite la projection à deux ans, là où la réponse se complique, et où la vraie question n'est plus celle qu'on croit.

Première partie : les comptes d'aujourd'hui

Faisons les comptes

Prenons une société de gestion de taille moyenne, 15 à 30 personnes, qui décide de construire en interne son outil de gestion (CRM participations, reporting, suivi).

Modélisons honnêtement ce que « make » coûte, en salaires chargés France 2026 et en hypothèses volontairement prudentes.

En face, l'abonnement à une solution spécialisée du marché, à périmètre comparable : non pas un simple CRM, mais la plateforme complète que le développeur était censé construire, CRM, reporting, portails, données :

Et arrêtons-nous sur la symétrie, car elle vaut toutes les démonstrations : la licence coûte le prix du développeur, 80 k€. À budget égal, le make vous donne une personne ; le buy vous donne un produit complet, une équipe entière, une roadmap qui avance sans vous, la sécurité éprouvée et quelqu'un qui en répond. Le surcoût du make, lui, se loge dans tout le reste du tableau : le stagiaire, l'audit, les outils, le temps métier, la reprise de code. 

Au total, près du double sur cinq ans, avec des hypothèses qui font pourtant la part belle au « make » : un seul développeur (aucun projet sérieux ne tient longtemps à un), pas de dérapage de planning, pas de refonte technique en cours de route, et un unique départ en cinq ans. 

Chaque ligne de ce tableau est ajustable, et je vous encourage à refaire le calcul avec vos chiffres ; l'expérience montre que les ajustements vont rarement dans le sens du « make ».

Les trois lignes que le devis mental oublie toujours

Le temps métier. C'est la ligne la plus sous-estimée du tableau, et souvent la plus grosse en réalité. Un outil interne n'avance que si le métier explique, arbitre, teste et re-teste. Chaque heure qu'un associé ou une CFO passe à préciser une règle de calcul ou à valider une maquette est une heure prise sur les deals, les LPs, les participations. C'est le risque de défocus : le vrai coût du « make » ne se lit pas dans le budget, il se lit dans l'agenda des personnes les mieux payées de la société.

Le facteur bus, version private equity. Votre développeur, devenu au fil des mois le seul humain à comprendre le code, reçoit un jour une offre du GP d'en face. Il part avec le seul cerveau qui sait pourquoi la ligne 4 218 ne doit surtout pas être modifiée. La reprise d'un code par un nouveau venu coûte cher, quand elle est possible ; parfois, elle se termine en réécriture. Le stagiaire, lui, était brillant, mais il est reparti en septembre.

L'expertise de conception. Un éditeur spécialisé n'apporte pas que du code : il apporte un produit façonné par des dizaines de clients du même métier, qui ont déjà rencontré vos problèmes avant vous, les cas limites réglementaires, les montées de version, la sécurité éprouvée, le RGPD outillé. En interne, chaque leçon se paie une fois de plus, en direct, sur vos données. Et rappelons le chiffre du MIT sur les projets d'IA générative internes : 95% des pilotes ne produisent aucun impact mesurable sur le compte de résultat [2]. Construire son outil avec un LLM, c'est cumuler les deux paris.

Quand le « make » se justifie quand même

Soyons honnêtes, car il y a des cas légitimes : quand l'outil EST votre avantage compétitif cœur (un modèle propriétaire d'analyse qui fonde votre thèse d'investissement), quand aucun produit du marché ne couvre un besoin réellement singulier, ou quand votre taille justifie une vraie équipe d'ingénierie, avec plusieurs développeurs, un product manager et un budget assumé, pas un développeur solitaire et un stagiaire. Le « make » est un métier ; le problème n'est pas de le choisir, c'est de le choisir sans savoir que c'en est un.

Le moment où vous voyez les ficelles

À ce stade, vous aurez remarqué que l'auteur de ces lignes vend précisément des licences logicielles aux sociétés de gestion. C'est exact, et c'est même pour cela qu'il connaît si bien chaque ligne du tableau : ces coûts, l'administration, la sécurité, les audits, la roadmap, les montées de version, nous les payons, mutualisés sur l'ensemble de nos clients au lieu d'être supportés par un seul. 

C'est toute la thèse économique du logiciel spécialisé et elle n'a pas été abrogée par les LLM ; elle en sort même renforcée, car nous aussi développons plus vite qu'avant, au bénéfice de la même licence.

Alors la prochaine fois que le prototype de vingt minutes émerveille le comité, posez une seule question : qui le maintient dans cinq ans, et qu'aurez-vous fait de moins pendant ce temps ? Le tableau ci-dessus attend vos chiffres.

Seconde partie : et dans deux ans, le Make gagnera-t-il ?

Projetons-nous, car l'objection mérite d'être prise au sérieux. D'ici deux ans, toute la chaîne de valeur de la gestion se sera digitalisée : plus de flux traités, plus d'informations absorbées, plus de précision dans la sélection comme dans l'accompagnement. 

Tous les GPs seront « augmentés » par la data et l'IA, et cette augmentation deviendra une commodité, nécessaire mais plus suffisante. Dans ce monde, un GP n'a-t-il pas intérêt, au contraire de tout ce qui précède, à investir massivement dans son infrastructure et son SI ? Le Make ne finira-t-il pas par l'emporter ?

La frontière n'est pas fixe, elle monte

Première clé de lecture : la frontière Make/Buy n'a jamais été un dogme, c'est une ligne qui monte avec le niveau d'abstraction. Personne ne « make » plus son serveur mail ; tout le monde « makait » ses modèles Excel. 

La bonne question n'est donc jamais Make ou Buy dans l'absolu, mais : où passe la frontière pour mon fonds, aujourd'hui ? Et le paradoxe de la projection à deux ans, c'est qu'elle renforce la première partie sur son propre périmètre : si l'outillage data et IA devient une commodité, alors reconstruire une commodité est le pire investissement possible.

On ne crée pas d'avantage compétitif en refabriquant ce que tout le monde possède. La vieille maxime des directions des systèmes d'information n'a jamais été aussi vraie : make what makes you different, buy what makes you the same.

L'argument qui peut casser, et celui qui le remplace

Soyons honnêtes sur le point de fragilité : tout le tableau de la première partie repose sur le coût de la maintenance. Si, dans trois ou cinq ans, des agents autonomes maintiennent, corrigent et font évoluer le code sans intervention humaine, cet argument s'érode, et le Make redevient pensable. Deux réserves, cependant. 

La première est arithmétique : les éditeurs bénéficient exactement de la même révolution, et l'écart relatif, un coût mutualisé sur des dizaines de clients contre un coût supporté seul, persiste tant qu'il subsiste le moindre coût fixe. 

La seconde est plus profonde et propre à notre secteur : un métier régulé ne fera pas tourner son middle office sur du code auto-généré et mouvant. Il faudra toujours quelqu'un qui réponde du système : versions certifiées, auditabilité, chaîne de responsabilité. 

À l'ère des agents, la « responsabilité logicielle » devient le produit, exactement comme la responsabilité éditoriale est devenue, depuis l'article 50 de l'AI Act, la ligne de partage des contenus. Ce que vous achèterez demain à un éditeur, ce n'est plus du code, c'est quelqu'un qui en répond.

Buy the platform, make the last mile

Alors oui, le GP doit investir massivement dans son SI, mais pas au sens où la petite musique l'entend. L'actif à construire n'est pas le tuyau, c'est ce qui coule dedans et ce qui le pilote. Trois couches, précisément. Les données propriétaires d'abord : les données opérationnelles des participations sont un gisement que personne d'autre ne possède, et leur golden source vaut plus que n'importe quel développement. 

La doctrine ensuite : le fonds qui a documenté et codifié ses processus et ses règles d'investissement pourra les faire exécuter par des agents ; celui qui les garde dans la tête des associés, non. Les interfaces gouvernées enfin, type serveurs MCP, qui permettront à n'importe quel agent d'agir sur ces données de manière contrôlée, journalisée, auditable. 

Le futur probable n'est donc ni Make ni Buy : c'est "Buy the platform, make the last mile". La plateforme spécialisée s'achète ; la couche propriétaire du fonds, ses données, ses règles, ses skills d'agents, se construit par-dessus. C'est un investissement massif dans le SI, mais dans le capital data et process, pas dans la refabrication de plomberie.

Tokenisation : l'ère de la preuve, version 2

Viendra ensuite le chapitre blockchain : ancrer les KPIs, horodater les décisions et leurs justifications sous-jacentes sur des registres distribués, c'est étendre à la donnée de gestion elle-même la logique de provenance qui s'applique déjà aux contenus. 

Notons au passage que la blockchain est l'exemple ultime du Buy : personne ne forge sa propre chaîne, on se branche sur des standards mutualisés. Et là encore, l'avantage ira aux fonds dont les données sont déjà certifiées et structurées, prêtes à être tamponnées ; on ne tokenise pas un fichier Excel en quatre versions.

What's the next big move ?

Si tout le monde est augmenté, l'alpha de l'augmentation disparaît, et la différenciation reflue vers ce qui ne se commoditise pas. Trois candidats se dessinent. 

Le GP comme data company d'abord : sa valeur de franchise inclura son gisement de données privées accumulées et les modèles affinés dessus, ce que les LPs finiront par valoriser en due diligence.

Le passage de l'aide à la décision à l'exécution déléguée ensuite : des agents qui sourcent, surveillent les covenants, préparent les comités, et dont la valeur dépendra entièrement de la qualité de la doctrine codifiée qu'on leur fait appliquer, un système d'exploitation du jugement propre à chaque fonds. 

La distribution enfin : la tokenisation des parts ouvrira le non-coté à des tickets plus petits et fera de la transparence vérifiable en temps réel un argument de levée. Dans les trois scénarios, le gagnant n'est pas celui qui aura recodé son CRM. C'est celui qui aura capitalisé ses données et sa doctrine.

Verdict

Make or Buy est, au fond, un faux débat et la projection à deux ans ne l'inverse pas : elle le déplace. 

La commodité s'achète, aujourd'hui comme demain et demain plus encore. Ce qui se construit, c'est ce que vous êtes seul à posséder : vos données, vos processus, votre doctrine. 

La vraie question de votre prochain comité n'est donc pas « combien coûterait notre outil maison ? ». C'est : "que possédons-nous que personne ne peut acheter, et qu'avons-nous fait cette année pour que ça vaille plus cher ?".

Références

• [1] Robert L. Glass, « Facts and Fallacies of Software Engineering », Addison-Wesley, 2002, notamment le fait n°41 sur la part de la maintenance dans le coût de vie d'un logiciel (de 40 à 80% selon les études) : https://dl.acm.org/doi/book/10.5555/579853
• [2] « The GenAI Divide: State of AI in Business 2025 », MIT, projet NANDA ; synthèse par Fortune : https://finance.yahoo.com/news/mit-report-95-generative-ai-105412686.html

Si vous souhaitez en savoir plus sur les Bodic Apps ou sur les missions de conseil de Bodic : contact@bodic.eu