Le logiciel ne meurt pas, il évolue

• Avec l’IA, la génération de code devient moins coûteuse, ce qui fait tomber le fossé défensif du « nous avons construit la fonctionnalité en premier », et les logiciels qui n’ont fait qu’empiler des fonctionnalités voient leur valeur réévaluée en temps réel (repriced)
• Désormais, la défense ne vient plus de la vitesse de livraison des fonctionnalités, mais de workflows à très haute précision, données propriétaires et systèmes d’enregistrement profonds ; le niveau requis pour être reconnu comme une « vraie entreprise » augmente aussi
• Les affirmations du type « j’ai vibe codé un CRM avec Claude pendant le week-end » ignorent la différence entre générer du code et exploiter un service critique ; les entreprises n’achètent pas du code, elles achètent de la confiance (trust)
• Les agents ne remplacent pas les applications ; ils sont plutôt imbriqués à l’intérieur des applications verticales, et ce sont les applications qui possèdent le modèle de données, les autorisations et la traçabilité d’audit, restant au cœur de la vente et du renouvellement
• La récente disparition de 285 milliards de dollars de capitalisation boursière dans les logiciels legacy a relancé la thèse de la fin du SaaS, mais la demande en IA reste un marché fondé sur des revenus réels, toujours supérieur à l’offre

---

Le débat sur la bulle pose la mauvaise question

• Si l’on considère l’IA dans son ensemble, il ne s’agit pas d’une bulle. La demande continue de dépasser l’offre, au point que certaines entreprises du portefeuille ne peuvent même pas accepter tous leurs clients faute de capacité de calcul
  • Cette demande ne se résume pas à un nombre d’utilisateurs ; elle est liée à des dizaines de milliards de dollars de revenus réels, et une bulle ne se manifeste pas sous cette forme
• En revanche, s’il y a un endroit où l’idée d’une bulle paraît crédible, c’est dans la robotique humanoïde, où les capitaux affluent vers des valorisations de late stage
  • On voit des backflips et des chorégraphies, mais il n’existe toujours pas de robot accomplissant un travail à valeur économique réelle
  • Les LLM ont fonctionné grâce au corpus d’apprentissage de l’Internet ouvert, mais la robotique ne dispose pas d’un corpus de données équivalent,
    ce qui en fait toujours un problème de recherche avec des sources de données d’entraînement mal définies (et le calendrier de la recherche ne correspond pas à celui du capital-risque)
• Autrement dit, la réponse à la question de la « bulle IA » varie selon le domaine ; de même, pour le logiciel (SaaS), il ne faut pas conclure trop vite qu’il est « mort », mais examiner chaque affirmation séparément

4 arguments sur la mort du logiciel (du pire au meilleur)

• #4 : tout le monde va vibe coder son propre logiciel

  • L’argument : « pourquoi payer Salesforce alors qu’on peut simplement vibe coder un CRM soi-même avec Claude pendant le week-end ? »
  • Générer une base de code et exploiter un service critique sont deux choses totalement différentes
    • Si la personne qui a vibe codé s’en va, la maintenance de la base de code devient un problème
    • La génération de code ne résout pas les questions de conformité SOC2 ni de contrôle des hallucinations
    • Elle ne résout pas non plus les intégrations SQL écrites en 1998 ni la responsabilité d’uptime quand le tableau de bord tombe à 4 heures du matin
  • Les entreprises achètent de la confiance, pas du code ; l’IA a facilité l’équivalence du code, mais l’équivalence de la confiance reste difficile à obtenir

• #3 : des agents comme Claude ou ChatGPT vont avaler les applications d’entreprise

  • C’est un meilleur argument que le vibe coding, mais il reste difficile d’y croire pour des workflows où le coût de l’erreur est élevé
  • Les systèmes fondés sur des LLM sont non déterministes et vulnérables aux hallucinations
    • Un bug logiciel classique est reproductible, alors qu’un échec d’agent ressemble à un test instable qui réussit à 98 %, puis échoue au moment décisif
  • Ils conviennent bien à des tâches à faible risque comme les brouillons d’e-mails, les résumés de documents ou les textes marketing
    • Mais si un agent oublie un champ obligatoire ou enregistre un mauvais montant de contrat et fait perdre une transaction à six chiffres, il faut à nouveau un système imposant des règles
  • Les équipes qui tentent des workflows purement agentiques finissent par reconstruire des couches de validation, étapes d’approbation, mécanismes de rollback et logs d’audit
    • Une fois tout cela ajouté, on a en pratique reconstruit une application SaaS autour de l’agent
    • Le résultat n’est donc pas le remplacement de l’application, mais plutôt l’imbrication d’un agent à l’intérieur d’une application verticale
    • Le modèle de données, les autorisations, la traçabilité d’audit et la relation client restent la propriété de l’application, et c’est cette enveloppe qui continue d’être vendue, supportée et renouvelée
  • Si la fiabilité des modèles s’améliore, cela deviendra plus intéressant, mais nous n’en sommes pas encore là

• #2 : la disparition de la tarification au siège va faire s’effondrer le modèle SaaS

  • Le SaaS traditionnel repose sur trois couches — données, logique métier et UI — auxquelles vient maintenant s’ajouter une quatrième, la couche agentique (agentic layer)
    • Si l’on vendait auparavant 50 sièges à des humains, mais que deux agents accomplissent désormais le travail sans UI, cela pose un problème de pouvoir de fixation des prix
  • Si les agents réalisent davantage de travail et que le client obtient plus de valeur, il ne s’agit pas d’un problème existentiel mais d’un problème de pricing et de packaging
    • Les éditeurs qui conçoivent un pricing aligné sur la valeur (price to value), via des modèles fondés sur les tokens, la performance ou l’usage hybride, survivront
    • Ceux qui s’accrochent au prix par siège s’effondreront à mesure que leurs clients automatiseront ces sièges
  • Une tarification purement fondée sur la performance est difficile à appliquer proprement à toutes les catégories ; il est donc probable que des modèles hybrides (usage + performance) dominent dans les prochaines années (comme l’indique explicitement le texte original)

• #1 : le code devient moins cher, donc le fossé défensif des fonctionnalités s’effondre

  • C’est l’argument pris le plus au sérieux
  • Le fossé défensif de SAP, ServiceNow et Salesforce était constitué, pendant des décennies, de ressources d’ingénierie accumulées
    • Toutes les fonctionnalités, intégrations et capacités de reporting étaient absorbées dans une base de code qu’une startup pouvait difficilement rattraper, mais l’IA compresse désormais drastiquement ce calendrier
  • Si votre produit n’est qu’une couche de workflow et que votre défense reposait sur « nous l’avons construit en premier », vous êtes en danger
    • La business intelligence et la génération de contenus créatifs sont aujourd’hui parmi les domaines aux fossés défensifs les plus faibles, précisément parce que les LLM excellent déjà dans ces tâches

Où se situe désormais le fossé défensif

• Trois éléments de défense

  • Des workflows à très haute précision, avec un budget d’erreur proche de zéro : infrastructure financière, santé, conformité réglementaire, etc.
    • Le vibe coding ne résiste ni à un audit HIPAA ni à des écarts de rapprochement comptable ; le coût même de l’erreur devient le fossé défensif
  • Des boucles de feedback sur des données propriétaires : le produit s’améliore de façon significative avec l’usage client, et la concurrence ne peut pas le copier à partir du même foundation model
    • L’actif, ce n’est pas le modèle, c’est la donnée
  • Des systèmes d’enregistrement profonds (systems of record) : intégrés aux opérations legacy, ils possèdent la source de vérité et créent des coûts de changement élevés
    • Ces entreprises ne doivent pas éviter l’IA, mais l’adopter pleinement, car la couche agentique augmente encore la valeur de leurs données

État actuel de la stack IA : où investir, où ne pas investir

• Dire « j’investis dans l’IA » n’est guère plus différenciant aujourd’hui que dire « j’investis dans le logiciel » en 2012
• Il existe quatre couches, et elles ne justifient pas la même allocation de capital

• 1. Hardware

  • La capacité de calcul reste la contrainte principale (binding constraint) de ce cycle
  • Des entreprises comme Neolabs attendent encore des bons de commande (PO) qui auraient dû être traités il y a plusieurs mois
  • La demande est réelle, mais l’offre est bloquée, et les gagnants sont pour la plupart des sociétés cotées ou déjà à grande échelle — un investissement seed ne change pas l’issue

• 2. Modèles

  • Les frontier models ne constituent pas une activité de venture, mais une activité capital intensive en capex
  • Le coût pour les entraîner correctement équivaut au PIB d’un petit pays, et OpenAI, Anthropic et Google jouent déjà cette partie
  • Une startup de modèles qui attaque frontalement choisit le mauvais combat
  • Seules quelques entreprises comme Sciforium, qui visent une autre forme via une nouvelle architecture, de nouvelles méthodes d’entraînement/inférence ou un nouveau cadrage du problème, attirent l’investissement
    • Si l’approche consiste à déborder latéralement (outflanking) les acteurs en place d’une manière qu’ils ne pourraient suivre qu’en cannibalisant leur cœur d’activité, alors cela devient intéressant

• 3. Infrastructure

  • C’est là que l’IA remet en question de façon intéressante les hypothèses du SaaS traditionnel
  • Le SaaS classique était orienté lecture (read-heavy) : on stockait une ligne une fois pour la consulter des millions de fois
    • Les workloads IA inversent cela : pipelines d’entraînement, mémoire d’agents, vector stores et harnesses d’évaluation sont orientés écriture et mise à jour (write-heavy), et manipulent des formes de données pour lesquelles les systèmes legacy n’ont pas été conçus
  • Les investissements sont actifs des deux côtés
    • La couche data elle-même : PlanetScale, Greybeam — reconstruction des primitives de base de données OLTP et OLAP pour ce type de workload
    • La couche de génération de données : Preference Model, Moody Pines, Terac — fournir les données nettoyées, structurées et labellisées qui deviennent le vrai goulot d’étranglement une fois le problème du calcul résolu

• 4. Applications

  • C’est là que se concentre actuellement la majeure partie du capital, car c’est la couche où la valeur atteint les acheteurs réels
  • L’IA ouvre un surface area massif sur des workflows auparavant inaccessibles : codage médical, optimisation du fret, revue juridique, sales motion, opérations cliniques, etc.
  • La concurrence y est intense et la pression sur les prix forte, mais c’est le propre d’une couche où la demande est importante
  • Les gagnants seront ceux qui combinent des workflows IA natifs avec au moins l’un des trois éléments suivants : environnement à haute précision, boucle de données propriétaire ou système d’enregistrement profond

Pour ceux qui créent une entreprise sur ce marché

• Le hardware et les modèles sont pratiquement fermés aux nouveaux entrants sans avantage structurel
• L’infrastructure reste grande ouverte si vous avez intégré le fait que « les workloads IA ne sont pas des workloads SaaS auxquels on a simplement greffé un chatbot »
• Les applications sont le segment le plus volumineux, mais aussi celui où le niveau de base monte le plus vite

• Recommandations pour les étapes seed et série A

  • Cessez d’affirmer que votre fossé défensif est « nous lançons vite » — c’est désormais une condition de base
  • Montrez quelles données accumulées par vous seul personne d’autre ne peut obtenir
  • Mettez en avant quels workflows absorbés par vous seul le client ne peut pas extraire librement
  • Dans les environnements où l’erreur entraîne de lourdes pertes, mettez en avant la précision offerte par votre système
  • Si votre fonctionnalité se trouve coincée entre deux grandes applications, sachez que vous êtes dans une dead zone
• Le logiciel ne meurt pas, mais les logiciels utilitaires hypertrophiés voient leur valeur réévaluée en temps réel (repriced), et les remplacer est bien plus difficile qu’un projet bricolé le week-end avec une API de modèle — le niveau attendu d’une vraie entreprise augmente