Lorsque Bain a annoncé qu'il utilisait le « vibecoding » dans le cadre de ses due diligences, cela a soulevé des questions sur la manière dont le modèle de conseil classique comprend réellement les entreprises de logiciels. Le logiciel est par nature itératif, et le simple fait de pouvoir construire un premier prototype ne dit pas grand-chose des fondamentaux techniques et/ou commerciaux sous-jacents.
Le test décisif
Avant de critiquer quoi que ce soit, commençons par un exemple et essayons nous-mêmes. Nous le ferons pour une entreprise facile à comprendre, qui ne dépend pas d'effets de réseau pour réussir. Dans notre cas, ce sera Ramp. En utilisant Lovable avec le prompt : « Crée une application de notes de frais où je peux téléverser une photo, l'IA reconnaît le montant et le type, et l'enregistre dans une base de données. » Après 5 minutes, voici ce qu'elle a produit.
J'ai été impressionné par la qualité du résultat. Il fait exactement ce que j'ai demandé, mais il manque encore beaucoup de fonctionnalités, que je pourrais sans doute ajouter avec un peu d'effort. Le fait est que Ramp, en tant qu'entreprise, est parfaitement placée pour comprendre et construire ces fonctionnalités. Vous pouvez copier leur ensemble de fonctionnalités le plus simple, mais eux peuvent continuer à monter en puissance avec des intégrations, des cartes de crédit virtuelles, leurs propres bots d'IA, et ainsi de suite. Alors oui, vous pourriez construire une version plus simple de Ramp, mais une parité complète des fonctionnalités exigerait beaucoup de ressources pour finir au mieux comme un suiveur rapide. La vraie innovation resterait du côté de Ramp, et en règle générale, les suiveurs rapides l'emportent rarement. Dans ce qui suit, j'expliquerai pourquoi cette dernière idée de Bain n'est peut-être pas la plus avisée.
Rien de nouveau sous le soleil
Cloner un logiciel n'a rien de nouveau. Les développeurs le font depuis longtemps, parfois pour apprendre et parfois dans le cadre d'un entretien, et il existe des milliers de vidéos YouTube montrant comment construire un clone fonctionnel d'Instagram en moins de trois heures. Alors pourquoi personne n'a-t-il jamais vraiment réussi à en lancer un avec succès ? Les effets de réseau y sont pour beaucoup, bien sûr, mais la raison plus profonde est qu'Instagram est bien plus qu'un front-end et un back-end reliés par HTTP. Il fait tourner toute une infrastructure capable de servir des milliards d'utilisateurs en même temps. Il possède l'un des meilleurs moteurs de recommandation jamais conçus, le genre qui garde les gens des heures devant l'écran. Et il monnaie tous ces utilisateurs via une plateforme publicitaire qui fonctionne vraiment. Même si vous aviez d'une manière ou d'une autre un milliard d'utilisateurs, faire tourner cette entreprise demanderait des milliers d'ingénieurs, de data scientists et de gestionnaires de comptes. Ce n'est pas quelque chose que l'on copie avec Lovable.
Et ce ne sont pas seulement les start-ups qui se heurtent à cela. Même les plus grandes entreprises peinent. En 2023, Meta elle-même a tenté de copier X avec Threads, et au début ça a marché : la fonctionnalité est devenue une énorme plateforme presque du jour au lendemain. Mais cela n'a pas duré. En 2026, la plupart des gens ont oublié que Threads existe, et Meta est passée au déploiement de fonctionnalités d'IA dans l'ensemble de ses produits. Même avec les effets de réseau et une sérieuse capacité d'ingénierie derrière, ils n'ont pas réussi à l'ancrer. Les produits sont bien plus que ce à quoi ils ressemblent en surface.
Construire à l'échelle
Construire à l'échelle comporte deux volets : construire les bonnes choses, et bien les construire. Le premier relève de la gestion de produit : savoir quelles fonctionnalités vos utilisateurs veulent réellement. Les acteurs en place ont l'avantage ici, car ils reçoivent un retour constant et connaissent leur métier sur le bout des doigts. Ils se font disrupter quand ils cessent de se soucier du premier volet pour n'optimiser que le second.
Pour le second volet, il est utile de regarder une entreprise qui a vraiment atteint une échelle immense : Discord. Au cours de la dernière décennie, ils ont migré leur base de données non pas une mais deux fois, d'abord de MongoDB vers Cassandra puis de Cassandra vers ScyllaDB, passant au passage de milliards de messages à des billions. MongoDB était parfait pour aller vite au début (ils ont construit Discord en seulement deux mois en 2015, sans aucun vibecoding), mais ils ont fini par le dépasser. Heureusement, ils avaient anticipé précisément cela dès le départ, si bien que le moment venu, la transition s'est faite relativement en douceur. Six ans plus tard, ils ont recommencé pour arriver à Scylla, une migration qu'ils avaient d'ailleurs déjà nommée dans le billet d'origine sur Cassandra. L'idée, c'est que des échelles différentes appellent des technologies différentes avec des compromis différents, et qu'on n'y arrive qu'avec une vraie planification, bien avant que l'échelle ne soit réellement là.
Quand vous vibecodez un clone rapide, vous ne faites ni l'un ni l'autre. Votre feuille de route se résume à « copier X ». Vous ne vous demandez jamais ce qui compte vraiment pour les clients, et vous ne pensez pas non plus à l'échelle, puisque de toute façon vous n'avez pas encore d'utilisateurs. Votre structure n'est pas conçue pour cela, donc chaque nouvelle fonctionnalité se transforme en le genre de migration qui glace même les meilleurs ingénieurs.
Les bons produits relient les deux volets de l'échelle grâce à une structure qui rend facile de construire les bonnes choses de la bonne manière. Quand Discord veut une nouvelle fonctionnalité, ils peuvent la cadrer, la construire et exécuter les migrations. Ils avancent vite sans trop casser.
L'avocat du diable
Jouons l'avocat du diable et affirmons que certains logiciels n'ont pas besoin d'être conçus pour des milliards d'utilisateurs ou des milliers d'organisations. Prenons Slack par exemple, la plateforme de messagerie détenue par Salesforce. Elle est utilisée par de nombreuses organisations et doit tenir compte de cette échelle dans ses choix d'ingénierie. Les organisations pourraient à la place construire une alternative plus petite, juste pour elles-mêmes. C'est parfaitement faisable (ou du moins c'est ce que vous croyez) et constituerait en effet une menace sérieuse pour Slack.
Énumérons ce qui leur manquerait alors :
Disponibilité sur toutes les plateformes
Intégration avec Google, Zoom, Microsoft…
Le SSO ; même si cela pourrait être implémenté
La conformité SOC2, ISO27001
La garantie de ne pas laisser fuiter les données de conversation
…
Beaucoup de ces points pourraient être résolus avec de l'effort d'ingénierie. Mais cela revient à une vieille question produit : est-ce que ça rend la bière meilleure ? Autrement dit : est-ce que le client y tient vraiment ? Le client se moque que vous fassiez tourner votre propre Slack, même si cela pourrait alléger la facture SaaS. Certaines organisations essaieront, mais elles seront une minorité. Les PME n'ont pas l'expertise, et les grandes entreprises ne peuvent pas absorber le changement (et devraient gérer une montée en charge vers 100 000 utilisateurs, voir plus haut).
Vous ne me croyez pas ? En 2024, Klarna a tenté exactement cela. En tant qu'entreprise de logiciels, elle en avait certainement la capacité. Un an plus tard, elle avait fait marche arrière sur certaines de ces décisions. Être son propre et unique client signifie que vous ne bénéficiez jamais de ce que tous les autres ont appris.
Le logiciel est difficile (à comprendre)
Le logiciel est difficile à comprendre parce qu'un logiciel complexe ressemble trompeusement à un logiciel simple. Les principes semblent les mêmes, le code que vous écrivez semble le même, et l'architecture peut sembler la même aussi. Les parties difficiles sont tout simplement invisibles de l'extérieur.
Ce n'est pas la première fois qu'un grand cabinet de conseil s'attire des critiques en affichant des opinions tranchées sur l'IA. La dernière fois, c'était McKinsey (et soyons justes, mon « alma mater » BCG a eu ses propres ratures). Dans ce que je considère comme l'un des textes les plus faibles sur le logiciel que j'aie lus, ils soutenaient qu'on peut mesurer la productivité des développeurs en combinant une série de métriques. Aujourd'hui, ils y ajouteraient probablement la consommation de tokens. Mais les meilleurs développeurs sont ceux qui font l'effort de simplifier les choses et de réduire la dette technique, pas ceux qui écrivent simplement le plus de code. Un logiciel doit durer longtemps, et la productivité n'est pas la même chose que la qualité. Les métriques magiques n'existent pas, et quelle que soit la métrique que vous choisissez, elle finira par pousser les gens vers le mauvais comportement (voir aussi la loi de Goodhart). Les réactions sur YouTube en disaient long. Une fois de plus, cela montre que le logiciel est difficile.
Rester pertinent à l'ère de l'IA
Cela va bien sûr plus loin que Bain qui vibecode une petite application. Les organisations de conseil peinent à trouver où elles apportent encore de la valeur à leurs clients. Les modèles de pointe deviennent meilleurs, non seulement en logiciel, mais aussi pour faire des slides et conseiller sur des transactions et des modèles d'affaires. Pour Bain en particulier, dont la due diligence a été l'un des points forts, il est devenu difficile de rivaliser. L'IA peut parcourir des millions de sources et même mener des entretiens, pour une fraction du coût. Dans un récent article du FT, beaucoup de ces cabinets de conseil ont indiqué la fin du modèle actuel, le responsable de l'IA chez McKinsey allant jusqu'à dire : « La nature même du conseil . . . doit bien sûr changer. »
Je ne pense pas pour autant que ces entreprises perdront leur valeur. Elles sont au contraire parfaitement placées pour être des conseillers : comprendre là où l'IA peut fonctionner pour les entreprises, et être une force critique qui pousse les organisations à bien utiliser ces outils. Ce mouvement de Bain n'est pas cela. Il révèle une lacune de compréhension qui mérite d'être prise au sérieux.