Blog

  • Et si tout le monde se trompait sur la mort du SaaS ?

    SaaS is dead ? Pas vraiment.

    En décembre 2024, Satya Nadella déclare sur le podcast BG2 : « SaaS is dead. » La phrase circule, les éditeurs s’inquiètent, les tribunes se multiplient. Mais la plupart passent à côté de ce qu’il dit vraiment.

    La thèse de Nadella n’est pas commerciale — elle est architecturale. Les applications métier sont des bases de données CRUD (Create, Read, Update, Delete) avec de la logique métier codée par-dessus. Cette logique va migrer vers une couche IA. Les agents interagiront directement avec les données brutes, sans interface humaine. Et quand l’utilisateur est un agent, l’interface n’a plus personne pour qui exister.

    Conclusion : le SaaS n’est pas mort. Son interface, si.

    La vraie compétition : pas SaaS contre SaaS, mais SaaS contre travail

    Pour chaque dollar dépensé en logiciel, six sont dépensés en services. Le budget outil est une fraction du budget travail dans presque toutes les industries. Le SaaS ne se bat pas contre d’autres SaaS : il se bat contre la main-d’œuvre qu’il était censé remplacer ou augmenter.

    Et dans ce combat, il a massivement échoué : les entreprises ont ajouté des outils sans réduire leurs effectifs de services. Les deux budgets ont grossi en parallèle. La rupture de l’IA n’est pas de rendre les outils plus intelligents — c’est de rendre possible la capture du budget travail directement, sans passer par l’outil.

    Copilot vs Autopilot : deux marchés, pas deux versions

    C’est ici qu’intervient la distinction la plus utile du moment :

    • Un copilot vend l’outil. Il s’adresse au professionnel qui fait le travail et le rend plus efficace.
    • Un autopilot vend le travail. Il s’adresse directement à celui qui achète le résultat et contourne le professionnel intermédiaire.

    Ce ne sont pas deux versions du même produit : ce sont deux marchés adressables de taille radicalement différente.

    Le moat du SaaS n’était pas la construction

    L’argument qu’on entend : construire coûtait cher, c’était un avantage, l’IA a supprimé ce coût, l’avantage disparaît. C’est incomplet.

    Le moat de Salesforce n’a jamais été qu’il était difficile de construire un CRM. C’était vingt ans de données clients et des milliers d’intégrations partenaires. Des coûts de migration qui rendent le remplacement douloureux même quand le concurrent est objectivement meilleur. Le vibe coding ne touche pas à ça.

    Mais attention au piège du data moat : si le prochain modèle de fondation absorbe le jugement dans un domaine, il commoditise aussi le moat durement acquis. La bitter lesson de Sutton s’applique dans les deux sens. Ce qui protège durablement, ce n’est pas la donnée brute — c’est la vérifiabilité du résultat couplée à la difficulté de reproduire le signal.

    Les chiffres qui ne mentent pas

    Pas besoin d’extrapoler, les données parlent d’elles-mêmes :

    • Le NRR médian des SaaS IA-natifs s’établissait à 48% fin 2025. Les plans sous 50 €/mois retenaient 32% de NRR, contre 85% pour les plans au-dessus de 250 €.
    • Le NRR médian du SaaS traditionnel a glissé de 105% en 2021 à 101% en 2024. Quatre points en trois ans.
    • Les outils de marketing et vente affichent un churn mensuel de 4,8 à 8,1%. Ces catégories horizontales sont sous pression maintenant.
    • 64% des entreprises du Fortune 500 ont des déploiements Copilot actifs, mais seulement 20 à 30% des sièges achetés sont effectivement utilisés chaque semaine. L’adoption PME ne dépasse pas 12%.

    Le constat est clair : les outils horizontaux sans données propriétaires ni effets réseau réels s’effondrent. Les PME sont les plus exposées (churn de 3 à 7% par mois), tandis que les grands comptes sont protégés par leurs contrats longs et leurs coûts de migration. Ces deux segments vivent dans des temporalités radicalement différentes.

    Le critère qu’on rate : la vérifiabilité

    L’analyse dominante distingue l’intelligence du jugement : les tâches purement intellectuelles sont automatisables aujourd’hui, les tâches de jugement le seront plus tard. C’est une grille utile, mais elle rate quelque chose.

    Ce qui fonctionne dans les autopilots, ce n’est pas uniquement le ratio d’intelligence dans la tâche. C’est la capacité à vérifier que le résultat est juste, à bas coût, après coup. Un NDA est vérifiable. Un code de facturation médicale est vérifiable. Des livres comptables qui réconcilient sont vérifiables. Là où vérifier coûte cher, ou là où l’évaluation est subjective, l’autopilot est dangereux — quel que soit le niveau d’intelligence requis.

    Ce qui résiste, ce qui s’effondre

    Les dépenses mondiales en SaaS dépasseront 500 milliards en 2028. Le secteur ne s’effondre pas. Ce qui s’effondre, c’est une catégorie précise :

    • 🔴 S’effondre : les outils horizontaux sans données propriétaires ni effets réseau réels, ceux dont la valeur principale était que les alternatives coûtaient plus cher à construire.
    • 🟢 Résiste : les données propriétaires non réplicables, la conformité réglementaire là où opérer sans agrément n’est pas une option, et les produits dont le résultat est vérifiable à bas coût après coup.

    Le contre-argument qu’on ne peut pas esquiver

    Andrej Karpathy estimait en octobre 2025 que les agents en production restent limités et que la transition prendra dix ans. Forrester maintient que la compliance, la scalabilité et la sécurité bloquent le remplacement dans la majorité des cas. Ils n’ont pas tort.

    Ce qui se passe n’est pas un remplacement brutal. C’est une érosion par le bas. Les outils qui auraient dû naître il y a deux ans ne se construisent plus. La pression s’exerce d’abord sur les nouveaux entrants. Mais dans cinq ans, le renouvellement naturel du marché sera beaucoup plus lent pour les éditeurs dont la proposition ne tient pas sans inertie client.

    Vendre le travail : la question qu’on n’aime pas poser

    Est-ce qu’un autopilot construit un business SaaS ou un business de services ? Vendre le travail, c’est hériter de la responsabilité du travail. Si le coût du modèle tend vers zéro, vous gardez le spread. Sinon, vous avez construit une boîte de BPO avec un meilleur coût variable. Ces deux entreprises n’ont pas le même multiple de valorisation.

    L’outsourcing est le point d’entrée le plus efficace pour un autopilot : quand une tâche est déjà externalisée, la substitution est un simple vendor swap. La ligne budgétaire existe, l’acheteur est habitué à payer pour un résultat. Remplacer des employés internes, c’est une réorganisation. Ces deux cycles de vente n’ont rien à voir.

    Le test qui compte vraiment

    Deux questions disent plus sur votre durabilité que n’importe quelle analyse concurrentielle :

    • Votre résultat est-il vérifiable après coup ?
    • Votre substitution se fait-elle par vendor swap ou par réorganisation ?

    Et le test Copilot : si Microsoft intègre demain votre cas d’usage dans Copilot, est-ce que votre client reste ? Pour un grand compte avec un contrat de trois ans et des intégrations profondes, vous avez probablement cinq à huit ans de marge. Pour une PME de quinze personnes sur M365 Business, la question est légitime aujourd’hui.

    Microsoft rate systématiquement les intégrations de niche. Copilot est performant pour résumer des réunions et trier des emails, beaucoup moins sur les cas d’usage verticaux qui demandent une calibration fine. Ce n’est pas un argument pour ne pas se poser la question — c’est un argument pour y répondre avec précision plutôt qu’avec une heuristique générale.

    Ce que tout ça nous apprend

    Le SaaS se débarrasse de tout ce qui n’était que de l’emballage. Ce qui reste en dessous, c’est soit de la valeur réelle, soit du temps compté.

    Le client n’a jamais voulu un CRM. Il voulait ne pas se faire surprendre. L’outil était le meilleur proxy disponible pour ce résultat, parce que produire le résultat directement coûtait trop cher. L’équation a changé, pas la demande.

    Pour les éditeurs SaaS — particulièrement dans la PME — la question n’est plus « mon code est-il bon ? » mais « est-ce que je vends un outil ou un résultat ? Et ce résultat, est-il vérifiable ? »

    Source : Article LinkedIn d’Adrien Bel (1er juillet 2026)

  • Et si tout le monde se trompait sur la mort du SaaS ?

    SaaS is dead ? Pas vraiment.

    En décembre 2024, Satya Nadella déclare sur le podcast BG2 : « SaaS is dead. » La phrase circule, les éditeurs s’inquiètent, les tribunes se multiplient. Mais la plupart passent à côté de ce qu’il dit vraiment.

    La thèse de Nadella n’est pas commerciale — elle est architecturale. Les applications métier sont des bases de données CRUD (Create, Read, Update, Delete) avec de la logique métier codée par-dessus. Cette logique va migrer vers une couche IA. Les agents interagiront directement avec les données brutes, sans interface humaine. Et quand l’utilisateur est un agent, l’interface n’a plus personne pour qui exister.

    Conclusion : le SaaS n’est pas mort. Son interface, si.

    La vraie compétition : pas SaaS contre SaaS, mais SaaS contre travail

    Pour chaque dollar dépensé en logiciel, six sont dépensés en services. Le budget outil est une fraction du budget travail dans presque toutes les industries. Le SaaS ne se bat pas contre d’autres SaaS : il se bat contre la main-d’œuvre qu’il était censé remplacer ou augmenter.

    Et dans ce combat, il a massivement échoué : les entreprises ont ajouté des outils sans réduire leurs effectifs de services. Les deux budgets ont grossi en parallèle. La rupture de l’IA n’est pas de rendre les outils plus intelligents — c’est de rendre possible la capture du budget travail directement, sans passer par l’outil.

    Copilot vs Autopilot : deux marchés, pas deux versions

    C’est ici qu’intervient la distinction la plus utile du moment :

    • Un copilot vend l’outil. Il s’adresse au professionnel qui fait le travail et le rend plus efficace.
    • Un autopilot vend le travail. Il s’adresse directement à celui qui achète le résultat et contourne le professionnel intermédiaire.

    Ce ne sont pas deux versions du même produit : ce sont deux marchés adressables de taille radicalement différente.

    Le moat du SaaS n’était pas la construction

    L’argument qu’on entend : construire coûtait cher, c’était un avantage, l’IA a supprimé ce coût, l’avantage disparaît. C’est incomplet.

    Le moat de Salesforce n’a jamais été qu’il était difficile de construire un CRM. C’était vingt ans de données clients et des milliers d’intégrations partenaires. Des coûts de migration qui rendent le remplacement douloureux même quand le concurrent est objectivement meilleur. Le vibe coding ne touche pas à ça.

    Mais attention au piège du data moat : si le prochain modèle de fondation absorbe le jugement dans un domaine, il commoditise aussi le moat durement acquis. La bitter lesson de Sutton s’applique dans les deux sens. Ce qui protège durablement, ce n’est pas la donnée brute — c’est la vérifiabilité du résultat couplée à la difficulté de reproduire le signal.

    Les chiffres qui ne mentent pas

    Pas besoin d’extrapoler, les données parlent d’elles-mêmes :

    • Le NRR médian des SaaS IA-natifs s’établissait à 48% fin 2025. Les plans sous 50 $/mois retenaient 32% de NRR, contre 85% pour les plans au-dessus de 250 $.
    • Le NRR médian du SaaS traditionnel a glissé de 105% en 2021 à 101% en 2024. Quatre points en trois ans.
    • Les outils de marketing et vente affichent un churn mensuel de 4,8 à 8,1%. Ces catégories horizontales sont sous pression maintenant.
    • 64% des entreprises du Fortune 500 ont des déploiements Copilot actifs, mais seulement 20 à 30% des sièges achetés sont effectivement utilisés chaque semaine. L’adoption PME ne dépasse pas 12%.

    Le constat est clair : les outils horizontaux sans données propriétaires ni effets réseau réels s’effondrent. Les PME sont les plus exposées (churn de 3 à 7% par mois), tandis que les grands comptes sont protégés par leurs contrats longs et leurs coûts de migration. Ces deux segments vivent dans des temporalités radicalement différentes.

    Le critère qu’on rate : la vérifiabilité

    L’analyse dominante distingue l’intelligence du jugement : les tâches purement intellectuelles sont automatisables aujourd’hui, les tâches de jugement le seront plus tard. C’est une grille utile, mais elle rate quelque chose.

    Ce qui fonctionne dans les autopilots, ce n’est pas uniquement le ratio d’intelligence dans la tâche. C’est la capacité à vérifier que le résultat est juste, à bas coût, après coup. Un NDA est vérifiable. Un code de facturation médicale est vérifiable. Des livres comptables qui réconcilient sont vérifiables. Là où vérifier coûte cher, ou là où l’évaluation est subjective, l’autopilot est dangereux — quel que soit le niveau d’intelligence requis.

    Ce qui résiste, ce qui s’effondre

    Les dépenses mondiales en SaaS dépasseront 500 milliards en 2028. Le secteur ne s’effondre pas. Ce qui s’effondre, c’est une catégorie précise :

    • 🔴 S’effondre : les outils horizontaux sans données propriétaires ni effets réseau réels, ceux dont la valeur principale était que les alternatives coûtaient plus cher à construire.
    • 🟢 Résiste : les données propriétaires non réplicables, la conformité réglementaire là où opérer sans agrément n’est pas une option, et les produits dont le résultat est vérifiable à bas coût après coup.

    Le contre-argument qu’on ne peut pas esquiver

    Andrej Karpathy estimait en octobre 2025 que les agents en production restent limités et que la transition prendra dix ans. Forrester maintient que la compliance, la scalabilité et la sécurité bloquent le remplacement dans la majorité des cas. Ils n’ont pas tort.

    Ce qui se passe n’est pas un remplacement brutal. C’est une érosion par le bas. Les outils qui auraient dû naître il y a deux ans ne se construisent plus. La pression s’exerce d’abord sur les nouveaux entrants. Mais dans cinq ans, le renouvellement naturel du marché sera beaucoup plus lent pour les éditeurs dont la proposition ne tient pas sans inertie client.

    Vendre le travail : la question qu’on n’aime pas poser

    Est-ce qu’un autopilot construit un business SaaS ou un business de services ? Vendre le travail, c’est hériter de la responsabilité du travail. Si le coût du modèle tend vers zéro, vous gardez le spread. Sinon, vous avez construit une boîte de BPO avec un meilleur coût variable. Ces deux entreprises n’ont pas le même multiple de valorisation.

    L’outsourcing est le point d’entrée le plus efficace pour un autopilot : quand une tâche est déjà externalisée, la substitution est un simple vendor swap. La ligne budgétaire existe, l’acheteur est habitué à payer pour un résultat. Remplacer des employés internes, c’est une réorganisation. Ces deux cycles de vente n’ont rien à voir.

    Le test qui compte vraiment

    Deux questions disent plus sur votre durabilité que n’importe quelle analyse concurrentielle :

    • Votre résultat est-il vérifiable après coup ?
    • Votre substitution se fait-elle par vendor swap ou par réorganisation ?

    Et le test Copilot : si Microsoft intègre demain votre cas d’usage dans Copilot, est-ce que votre client reste ? Pour un grand compte avec un contrat de trois ans et des intégrations profondes, vous avez probablement cinq à huit ans de marge. Pour une PME de quinze personnes sur M365 Business, la question est légitime aujourd’hui.

    Microsoft rate systématiquement les intégrations de niche. Copilot est performant pour résumer des réunions et trier des emails, beaucoup moins sur les cas d’usage verticaux qui demandent une calibration fine. Ce n’est pas un argument pour ne pas se poser la question — c’est un argument pour y répondre avec précision plutôt qu’avec une heuristique générale.

    Ce que tout ça nous apprend

    Le SaaS se débarrasse de tout ce qui n’était que de l’emballage. Ce qui reste en dessous, c’est soit de la valeur réelle, soit du temps compté.

    Le client n’a jamais voulu un CRM. Il voulait ne pas se faire surprendre. L’outil était le meilleur proxy disponible pour ce résultat, parce que produire le résultat directement coûtait trop cher. L’équation a changé, pas la demande.

    Pour les éditeurs SaaS — particulièrement dans la PME — la question n’est plus « mon code est-il bon ? » mais « est-ce que je vends un outil ou un résultat ? Et ce résultat, est-il vérifiable ? »

    Source : Article LinkedIn d’Adrien Bel (1er juillet 2026)

  • Le secret pour qu’un MVP réussisse : ce n’est pas le code

    Le code ne fait pas tout

    On l’entend souvent : un MVP, c’est avant tout une question de code propre, d’architecture élégante et de tests rigoureux. Et pourtant, après avoir accompagné plusieurs projets, un constat s’impose : le code est nécessaire, mais pas suffisant.

    La vraie question n’est pas « est-ce que mon code est bon ? » mais « est-ce que mon MVP va décoller ? ». Et la réponse dépend de bien autre chose que de la qualité technique.

    La règle des 3 mois

    Un MVP qui n’attire pas ses premiers clients dans les 3 mois suivant son lancement est condamné. Pas parce que le produit est mauvais, mais parce que sans validation marché rapide, on construit dans le vide. Chaque mois supplémentaire sans client, c’est du code écrit sur des hypothèses non vérifiées — donc du risque accumulé.

    Les 4 piliers d’un MVP qui réussit

    Avant d’écrire la moindre ligne de code, quatre éléments doivent être validés :

    1. Une cible précise

    « Les TPE » n’est pas une cible. « Les directeurs commerciaux de PME industrielles de 30 à 50 personnes », c’en est une. Plus la cible est étroite et descriptive, plus le message résonne. Vouloir s’adresser à tout le monde, c’est ne s’adresser à personne.

    2. Un canal d’acquisition testé

    « On fera du SEO » n’est pas un plan. « On a 50 prospects identifiés sur LinkedIn et un script de prise de contact qui marche », c’est un plan. La différence ? L’un est un vœu pieu, l’autre est une action concrète, mesurable et déjà en cours.

    3. Un pricing qui passe

    « On verra à 99€/mois » n’est pas une stratégie de prix. « On a testé à 79€, 99€ et 129€. À 99€, les gens disent oui », c’en est une. Le prix n’est pas une devinette : il se valide par des conversations réelles avec des prospects réels.

    4. Une vraie douleur

    « Ils gagneront du temps » n’est pas un problème. « Aujourd’hui ils passent 5 heures par semaine sur Excel et ils détestent ça », c’est un problème. Un MVP qui ne résout pas une douleur ressentie et exprimée ne trouvera pas d’acheteur — aussi bon soit-il techniquement.

    Le constat terrain : 50/50 vs 90/10

    Sur les projets observés, une tendance nette se dégage :

    • 🟢 MVP réussis : le fondateur passait 50% de son temps avec ses prospects et 50% à coder.
    • 🔴 MVP ratés : le fondateur passait 90% de son temps à coder et 10% (ou moins) avec ses prospects.

    Le message est clair : le temps passé à comprendre le marché n’est pas du temps perdu pour le produit — c’est exactement l’inverse. C’est ce qui garantit que ce que vous codez a une raison d’exister.

    Le rôle d’un bon développeur MVP

    Un bon développeur MVP ne se contente pas de coder. Son rôle est de forcer la validation des 4 points avant d’écrire la première ligne. C’est inconfortable, parfois énervant — mais c’est précisément ce qui sépare un MVP qui décolle d’un MVP qui meurt.

    Un développeur qui code sans poser ces questions vous rend un service immédiat, mais vous laisse avancer avec un risque que vous ignorez. Un développeur qui vous met au défi sur la cible, le canal, le prix et la douleur vous fait gagner des mois.

    Avant de coder, posez-vous la question

    Si vous avez un projet MVP en tête, avant d’ouvrir votre éditeur, demandez-vous :

    • Qui est ma cible, précisément ?
    • Ai-je un canal d’acquisition déjà testé ?
    • Ai-je validé un prix qui passe ?
    • Quelle douleur concrète est-ce que je résous ?

    Si vous hésitez sur l’une de ces réponses, ce n’est pas le moment de coder. C’est le moment d’aller parler à vos prospects.

    Source : Post LinkedIn de Redouan Tayaa