Quand un livrable convaincant ne prouve plus rien

Selon le Financial Times, Bain utilise l’IA en due diligence, pour le compte de fonds de private equity, afin de reconstruire une partie du logiciel des entreprises visées. Le but est de mesurer en quelques jours ce qui, dans ce logiciel, est difficile à reproduire, sans chercher à en produire une copie utilisable.

Cette méthode a une portée plus large. L’IA produit aujourd’hui, à bas coût, des livrables qui paraissent solides, comme une analyse argumentée ou un client fictif qui répond avec nuance. Quand ces livrables deviennent faciles à produire, leur allure ne prouve plus rien. La seule question qui reste utile est de savoir si la recommandation a été testée, et ce que le test a donné.

Ce que Bain teste vraiment

Bain a déjà produit des centaines de ces prototypes, dans ce qu’il appelle des diligences « outside in ». La pratique a commencé en 2023 dans une équipe d’ingénieurs et s’est étendue aux équipes de conseil classiques. Le principe est de recréer le produit à partir de ce qu’il fait, sans accès au code source de la cible.

Le résultat varie selon la cible. Pour une entreprise de santé « AI-native », la reconstruction a suffi à convaincre l’investisseur que la technologie serait facile à rattraper, par un concurrent installé ou par un nouvel entrant. Pour un éditeur de logiciel spécialisé, la reconstruction a échoué : le produit reposait sur des workflows intégrés chez les clients, des coûts de changement élevés et des données difficiles à reconstituer, et l’IA représentait pour lui une opportunité plus qu’un risque. Rebecca Burack, responsable du private equity mondial chez Bain, résume l’usage du prototype : voir « si c’est le code lui-même qui est défendable, ou autre chose ».

Le moat se décompose

Une entreprise de logiciel est souvent présentée comme un bloc unique : code, produit, données, distribution, intégration chez le client, coûts de changement. Le prototype sépare ces éléments et montre lequel porte l’avantage. Si l’interface se recopie en trois jours, elle ne protège rien. Si la reconstruction échoue, c’est en général qu’elle bute sur un élément qu’une équipe extérieure ne peut pas recréer vite, comme des données propriétaires ou une intégration construite au fil des années.

Pour un investisseur, cela change l’analyse. Si le code se reconstruit vite, l’avantage de l’entreprise est ailleurs, ou il n’existe pas. Dans ce second cas, la valorisation doit être revue, puisqu’elle reposait sur une barrière technique absente.

Le marché reflète déjà ce doute. Selon KPMG, la valeur des opérations de private equity dans la tech, les médias et les télécoms a chuté de 69 % au premier trimestre 2026 par rapport au trimestre précédent. Ce recul tient à une incertitude générale sur la valeur du code, pas aux prototypes de Bain.

Un réflexe venu du code

Cette approche existe depuis longtemps ailleurs. La finance teste ses banques avec des scénarios adverses depuis 2008. L’ingénierie éprouve ses systèmes en provoquant des pannes. Netflix a formalisé cette idée avec Chaos Monkey, un outil qui coupe des serveurs au hasard, en production, pour vérifier que le service continue de fonctionner. Dans tous ces cas, un système est validé quand il survit à une tentative de le faire tomber.

Le développement logiciel assisté par IA a renforcé cette exigence. Un agent écrit du code plausible plus vite qu’on ne peut le relire, et il lui arrive d’affirmer que ses tests passent alors qu’ils échouent. Personne ne relit tout ce qu’il produit, donc la vérification passe par l’exécution : on lance le code et on compare le résultat à ce qui était attendu. Bain applique le même raisonnement en due diligence, avec les mêmes outils : reconstruire le logiciel sert à mesurer ce qu’il vaut.

Le problème ne concerne pas que le logiciel. L’IA produit vite un livrable crédible dans presque tous les domaines du conseil, de l’étude de marché au plan de conduite du changement. Comme pour le code, un livrable qui paraît solide ne prouve rien tant qu’on n’a pas cherché à le mettre en défaut.

Une analyse solide reste nécessaire, et l’expérience sectorielle garde sa valeur. Mais sur un dossier important, elle ne suffit plus. Le client peut demander quelle hypothèse critique a été testée, et ce que le test a montré.

La simulation peut aussi tromper

La même IA sert aussi à produire de fausses preuves. Elle génère des clients synthétiques qui répondent avec nuance et des organisations entières simulées. Les développeurs appellent l’équivalent, dans le code, le « test theater » : des tests générés qui passent sans rien vérifier. Une simulation n’est pas une preuve parce qu’elle est convaincante. Bain travaille sur ces clients synthétiques pour tester des propositions de valeur. Le risque est de confondre plausibilité et preuve. Une simulation fluide inspire une confiance qui n’est pas toujours justifiée.

Cette confusion existe depuis longtemps en finance. Les modèles comme Black-Scholes ou les simulations de Monte-Carlo calculent des résultats à l’intérieur de leurs hypothèses. Ils explorent parfois des scénarios extrêmes, mais ne testent pas la validité du modèle lui-même. En 2008, des modèles jugés fiables se sont révélés faux quand la réalité est sortie de leurs hypothèses. Explorer une distribution de scénarios n’est pas la même chose que chercher le point où un raisonnement casse.

Ce risque a un nom en finance, le model risk. La Réserve fédérale rappelle qu’un modèle mal conçu ou mal validé produit des pertes et de mauvaises décisions. La FDA impose, pour les modèles en pharmacologie, de les planifier, de les évaluer et de les documenter. La même exigence s’applique au conseil : quand une recommandation s’appuie sur une simulation, il faut préciser ce qu’elle couvre, ce qu’elle ignore, sur quelles données elle repose, ce qu’elle ne doit pas décider seule et ce qui l’invaliderait.

Ce que les dirigeants doivent demander

Pour un acheteur de conseil, cela change ce qu’il faut exiger. Aujourd’hui, une recommandation arrive avec ses risques en annexe et on la juge à sa cohérence. Sur une décision qui coûte cher, elle devrait arriver avec le compte rendu d’une tentative de la faire échouer. Quatre questions le vérifient : quelle hypothèse doit être vraie pour que la recommandation tienne, qu’a-t-on fait pour la mettre en défaut, qu’est-ce qui a cassé, et qu’est-ce que le test n’a pas pu couvrir.

Un livrable sans aucune faille apparente devrait rendre méfiant, car une recommandation testée sérieusement laisse des traces. C’est là que l’audit trail devient utile : il retrace comment la recommandation a été testée, où elle a tenu et où elle a cédé.

Le deck ne porte plus seul la preuve

Le deck ne va pas disparaître. Il reste le support de la décision. Mais quand l’IA permet de reconstruire ou de tester une recommandation, il ne suffit plus à la prouver, et un livrable bien présenté n’est plus un gage de solidité.

C’est l’effet principal de l’IA sur le conseil, plus que le gain de vitesse. Elle rend presque gratuite la production d’un livrable convaincant, ce qui retire sa valeur à l’ancienne preuve, l’analyse bien argumentée. Elle rend aussi le test accessible, ce qui donne du poids à la nouvelle, ce qu’une recommandation supporte quand on cherche à la casser. Le phénomène reste limité, quelques cabinets et beaucoup d’annonces. Sur une décision importante, la vraie question n’est plus ce qu’un cabinet recommande, mais ce qu’il a testé et ce qui a cassé.