Le SaaS va-t-il vraiment mourir avec les agents IA ?
Tu as probablement vu les mêmes posts que moi. Le genre de punchline qui claque: “Le SaaS est mort”, “tout va devenir custom”, “t’as un problème, tu le prompts, tu l’as”. Et souvent, ça s’appuie sur un exemple qui parle à tout le monde: un besoin très concret, un tour sur Google, des abonnements à 30-80 euros par mois, puis la révélation: “j’ai vibe codé le truc en une soirée, fini”.
Ce qui rend le débat piquant, c’est que ce n’est pas juste de la théorie. On l’a vécu. Quand tu peux sortir un scraper, un connecteur, un petit outil d’enrichissement ou un automate de workflow en un prompt bien guidé, tu ne regardes plus certains SaaS de la même façon. Et ça, c’est nouveau.
Mais de là à dire que “le business du SaaS va mourir”, il y a un pas. Et ce pas, il faut le comprendre, parce que derrière la provocation il y a une vraie info: la valeur bouge. Pas dans le sens “plus de logiciels”, mais dans le sens “plus de résultats, moins d’interface”. Et si tu veux construire un business IA qui dure, ton job c’est de te placer là où la valeur se recapture.
Dans cet article, je te propose une lecture simple: ce qui est en train de se faire compresser, ce qui va rester, puis des directions de business très concrètes dans un monde plus agentique.
Pourquoi ce discours explose maintenant
Il y a trois ingrédients qui expliquent l’effet “wahou” et donc la vague de posts.
Le premier, c’est que le code est devenu bon marché. Pas gratuit, pas magique, mais beaucoup plus accessible. Avant, même un petit outil demandait du temps, une compétence, une stack, de la friction. Aujourd’hui, tu peux partir d’une description en langage naturel, obtenir une base solide, itérer, tester, et arriver à un truc utilisable très vite. Résultat: l’écart entre “j’ai un besoin” et “j’ai un outil qui tourne” s’est effondré.
Le second, c’est la montée des agents. Un SaaS classique te donne un endroit où cliquer. Un agent te promet autre chose: tu dis l’objectif, il enchaîne des étapes, il appelle des outils, il te demande une validation si besoin, puis il exécute. La promesse n’est plus “voici une fonctionnalité”, c’est “voici une action réalisée”. Forcément, ça remet en cause une partie des produits qui se contentaient d’emballer des opérations répétitives.
Le troisième, c’est que pas mal de SaaS étaient, soyons honnêtes, des features. Pas tous. Mais une partie du marché s’est construite sur des briques assez simples vendues en abonnement. Quand cette brique devient générable et customisable facilement, la pression arrive d’un coup, et les posts “le SaaS va mourir” sont une façon un peu brutale de décrire cette pression.
Donc oui, il y a un vrai changement. Mais il faut faire attention à un piège: confondre “je peux le faire une fois” avec “je peux en faire un produit”.
Le point que les posts oublient: un script qui marche n’est pas un produit
Quand tu vibe codes un outil, tu obtiens souvent un résultat satisfaisant pour toi, dans ton contexte, maintenant. Et ça peut déjà valoir énormément. Mais un produit, surtout en B2B, c’est un autre animal.
Un produit, ça doit marcher:
- sur la durée
- avec des utilisateurs différents
- avec des environnements différents
- malgré les exceptions
- malgré les changements externes
Un exemple simple: un scraper. Aujourd’hui, tu extrais un profil, tu enrichis ton CRM, nickel. Demain, la page change, un captcha apparaît, les limites se durcissent, l’auth bouge. Ton script, lui, ne proteste pas. Il casse. Et si c’est toi qui l’utilises, tu le répares et tu passes à autre chose. Si tu le vends, tu te retrouves avec du support, des clients bloqués, des promesses implicites, et un risque légal ou contractuel.
Même chose pour un “agent” qui agit dans des outils sensibles. Tant que tu es seul, c’est fun. Dès que tu mets ça dans une entreprise, tu as besoin de permissions claires, de logs, d’approbations, de limites. Sinon, ça devient un générateur d’incidents.
Donc, la question n’est pas “est-ce que je peux le coder”. La question, c’est “est-ce que je peux le rendre fiable, répétable, vendable”. Et la réponse n’est pas la même.
Alors, est-ce que le SaaS meurt ? Non. Mais une partie du SaaS se fait compresser
Le SaaS ne va pas disparaitre comme concept. Le monde ne va pas basculer du jour au lendemain vers “tout est un prompt” et plus personne ne paie d’abonnements. Par contre, certains types de SaaS vont souffrir beaucoup plus que d’autres.
Ce qui se fait compresser en premier, c’est le SaaS qui coche ces cases:
Tu payes un abonnement pour une fonctionnalité isolée, avec une faible profondeur de workflow. L’outil apporte peu de différenciation, et tu pourrais le remplacer par un script ou une automation custom si tu y mets un peu d’énergie. Le pricing est souvent par utilisateur, ce qui rend la comparaison douloureuse: “Pourquoi je paierais 10 sièges si je peux juste automatiser l’action ?”
À l’inverse, il y a des SaaS qui tiennent très bien, même dans un monde agentique. Ceux qui:
- ont des intégrations profondes et pénibles à reproduire
- gèrent de la conformité (audit, traçabilité)
- servent des cas d’usage critiques (facturation, paie, sécurité)
- possèdent une distribution massive (écosystème, marketplace, marque)
- accumulent des données et du retour terrain dans un vertical
Ce que l’IA change, c’est la façon dont ces SaaS vont packager la valeur. Plus d’automatisation, plus de “jobs-to-be-done”, moins de clics. Mais pas zéro SaaS.
Le shift réel, c’est la migration de la valeur: moins dans l’interface, plus dans l’exécution, la fiabilité et la gouvernance.
Le “monde agentique”: ce qui est réaliste et ce qui est fantasmé
Un agent, dans la vraie vie, c’est un système qui prend une intention, la décompose en étapes, puis agit. Pour que ça marche bien, il faut trois choses: des outils fiables (API, connecteurs), des données accessibles, et un cadre de décision (quoi faire, quand demander validation, quand s’arrêter).
Le fantasme, c’est l’agent qui fait tout, tout seul, sans supervision, dans n’importe quel environnement. Ce fantasme marche en démo. La réalité, c’est qu’un agent performant est souvent très cadré. Il est bon parce qu’il est spécialisé, parce qu’il suit un playbook, parce qu’il a des garde-fous.
C’est d’ailleurs une bonne nouvelle pour toi si tu cherches un business: plus le monde devient agentique, plus les entreprises ont besoin de spécialistes capables de cadrer ces agents, de les brancher aux outils, de les monitorer, et de garantir que ça ne part pas en vrille.
En clair: l’agentique ne tue pas le besoin de produits. Il déplace la valeur vers “l’opérateur + l’infrastructure + la confiance”.
Ok, si le SaaS “feature + abonnement” se fait manger, quoi construire à la place ?
Je te propose de voir ça comme 6 grandes familles. Tu peux en choisir une selon ton profil (solo, agence, startup, côté tech ou côté métier). L’idée n’est pas de “suivre une mode”, c’est de te placer là où les scripts custom ne suffisent pas.
1) Vendre un résultat: Service-as-a-Software (ou outcome business)
C’est la direction la plus simple à comprendre et, souvent, la plus rentable au début.
Au lieu de vendre un outil qui permet de faire X, tu vends X directement. Tu ne vends pas “un SaaS de prospection”. Tu vends “des rendez-vous qualifiés”. Tu ne vends pas “un enrichisseur de CRM”. Tu vends “une base enrichie propre chaque semaine”. Tu ne vends pas “un outil de relance”. Tu vends “le recouvrement accéléré”.
Dans ce modèle, l’IA est ton moteur de production. Elle te permet de scaler ce qui était une prestation manuelle. Mais ton client s’en fiche de tes prompts. Il veut un outcome, un reporting, et une fiabilité.
Pourquoi ça marche bien dans un monde agentique ? Parce que même si ton client pourrait, en théorie, coder un script, il ne veut pas gérer l’exécution, les exceptions, la maintenance, et la responsabilité. Il préfère payer quelqu’un pour que ça tourne.
Ce modèle se marie très bien avec un pricing hybride: un setup (pour brancher les outils, cadrer les règles, sécuriser) puis un forfait au résultat ou à la volumétrie. Et surtout, ça te sort de la comparaison directe “abonnement vs je le code”. Tu n’es plus un logiciel, tu es une machine à résultats.
2) L’implémentation agentique pour PME: le “forward-deployed” pragmatique
La plupart des entreprises n’ont pas envie de devenir des boîtes de dev. Elles ont des outils existants, des process bancals, des données pas très propres, et un quotidien chargé. Elles veulent “un truc qui marche”, pas “un repo Git”.
Il y a donc une opportunité énorme pour des offres d’implémentation agentique. Concrètement, tu arrives, tu cartographies un workflow (ex: traitement des demandes inbound), tu identifies les points de décision, tu connectes les outils (mail, CRM, calendrier, support), tu poses des règles de validation, et tu livres une version opérationnelle.
Ce business ressemble à du conseil au début, mais il peut devenir très productisé. Tu crées des templates de workflows, des packs d’intégrations par secteur, des dashboards, des checklists de sécurité. Et au fil du temps, tu peux extraire un produit si tu vois un pattern récurrent.
C’est un chemin très réaliste si tu veux démarrer vite avec peu de capital, tout en construisant une base de connaissance solide.
3) L’orchestration et les intégrations: la colonne vertébrale du monde agentique
Quand tout devient “custom”, le vrai problème n’est pas de générer du code. Le vrai problème, c’est de faire parler correctement les systèmes entre eux. Et de gérer la complexité du réel: retries, erreurs, timeouts, doublons, permissions, logs, escalades.
Les business autour de l’orchestration sont moins sexy sur Twitter, mais ils sont incroyablement importants. Si tu crées une couche qui rend les workflows agentiques robustes, tu deviens central.
Un exemple concret: une entreprise veut un agent qui lit des emails, crée des tickets, met à jour le CRM, et notifie Slack. Sur le papier, facile. En pratique, il faut gérer les cas limites: email incomplet, client déjà existant, bug API, permissions insuffisantes, ticket déjà ouvert, pièces jointes lourdes, délais de réponse. L’orchestration, c’est ce qui empêche le chaos.
Si tu aimes la technique, c’est une direction forte. Et si tu préfères le métier, tu peux la jouer en vertical: “orchestration pour X secteur”, avec les connecteurs déjà prêts.
4) La sécurité, la gouvernance, l’audit: le marché qui grossit dans l’ombre
Plus tu donnes du pouvoir à des agents, plus les risques augmentent. Et les boîtes le sentent. Un agent qui peut envoyer des emails, modifier un CRM, déclencher une facture, ou toucher à des données sensibles, ça demande des garanties.
Il y a donc un marché en train de naître autour de:
- la gestion des permissions (qui a le droit de quoi)
- l’approbation humaine sur les actions critiques
- les logs d’actions et la traçabilité
- la détection d’anomalies (comportement inattendu d’un agent)
- la protection contre les manipulations (prompt injection, exfiltration)
Ce n’est pas forcément le business le plus simple à lancer en solo, mais il peut aussi exister en version “PME-friendly”: un audit + un kit de gouvernance + un monitoring mensuel. Et si tu arrives à devenir la référence “agents sous contrôle”, tu crées une confiance très défendable.
5) Le vertical AI: profondeur de workflow et avantage métier
Si tu veux construire un produit plus classique, mais adapté au monde agentique, le vertical est une stratégie très forte.
L’erreur fréquente, c’est de faire “un agent générique pour [secteur]”. Ça se copie vite et ça ne résout pas la complexité métier. Un bon vertical, c’est un système complet: documents types, règles, exceptions, validations, intégrations spécifiques, et un langage métier bien compris.
Prenons un exemple simple: la pré-compta pour PME. Ce n’est pas juste “extraire des champs d’une facture”. C’est aussi gérer les catégories, les exceptions, les justificatifs, la TVA, les rapprochements, les fournisseurs connus, les doublons, les workflows de validation, et la relation avec l’expert-comptable. Si tu encapsules ça, tu deviens plus qu’un outil. Tu deviens un bout du métier.
Dans un monde où le code est accessible, ton avantage vient de ton expertise, de ton intégration au quotidien, et de la confiance opérationnelle.
6) Les “pelles et pioches” pour builders, mais version niche
Il y a aussi un business autour de ceux qui construisent. Les devs, les ops, les no-code/low-code, les fondateurs qui veulent ship vite. Mais attention: les outils généralistes sont un terrain de guerre. La meilleure approche, c’est la niche.
Au lieu de faire “un IDE agentique de plus”, tu peux faire “un pack de déploiement + monitoring pour agents qui touchent à Salesforce”, ou “un kit d’évaluation pour agents support”, ou “une librairie de connecteurs ultra propre pour un vertical”. La niche te donne une distribution plus ciblée et une vraie différenciation.
L’histoire du scraper: comment passer de l’outil perso à un business (sans te cramer)
Revenons à ton exemple, parce qu’il est parfait: “j’avais besoin d’un scraper X qui enrichit mon CRM, j’ai vu des SaaS chers, je l’ai codé en one shot”.
Ce que tu as fait est rationnel. Et c’est précisément pour ça que certains SaaS vont souffrir. Mais si tu veux transformer ce type de besoin en business, il faut changer de perspective.
En perso, tu acceptes que ça casse parfois. En business, tu dois réduire cette fragilité. Et ça change tout.
Tu dois te poser des questions du genre: Est-ce que ma source est stable ? Est-ce que je peux utiliser des API officielles ? Est-ce que je respecte les conditions d’utilisation ? Est-ce que mon client est ok avec ce niveau de risque ? Est-ce que j’ai un plan B si la source change ?
Et surtout, tu dois ajouter une couche de valeur autour de l’extraction brute. Parce que sinon, tu seras remplacé par le prochain prompt.
La valeur “vendable” peut être, par exemple, la qualité des données (déduplication, normalisation), un scoring, une fusion multi-sources, un traitement des exceptions, et une intégration clean au CRM avec des logs et un suivi. En gros: tu vends la fiabilité, pas juste la donnée.
Si tu fais ça, tu n’es plus “un scraper”. Tu es “un pipeline d’enrichissement fiable”. Et ça, c’est beaucoup plus défendable.
Le pricing: pourquoi “par siège” va se faire bousculer
Un des points les plus importants dans ce shift, c’est le pricing. Le monde agentique pousse naturellement vers des modèles orientés valeur, parce que l’utilisateur humain n’est plus toujours celui qui fait l’action.
Quand un agent traite 200 tickets, qui est “l’utilisateur” ? Le support ? Le manager ? L’agent lui-même ? Le pricing par siège devient bizarre.
C’est pour ça que tu vas voir de plus en plus de:
- pricing à la tâche (par ticket, par facture, par lead)
- pricing à l’outcome (par rendez-vous tenu, par montant recouvré)
- bundles (un forfait pour un workflow complet)
- modèles hybrides (setup + abonnement + variable)
Si tu cherches un business, c’est une excellente nouvelle. Ça te donne un levier simple: ne vends pas un outil, vends un résultat mesurable. Et structure ton prix autour de ce résultat.
Comment trouver une idée qui tient debout (sans partir dans tous les sens)
Quand on lit les posts “tout devient custom”, on peut vite se sentir coincé. Genre: “Si tout le monde peut tout coder, qu’est-ce que je vends ?”
La réponse est assez simple, mais pas toujours agréable: tu vends ce qui reste dur même avec l’IA.
Un bon filtre, c’est de chercher un besoin qui est: Répétitif, mesurable, et relié à un workflow réel. Pas un petit gadget. Un truc qui revient toutes les semaines, qui a un impact business clair, et qui nécessite d’accéder à des outils et des données.
Ensuite, tu vérifies deux choses: Est-ce que tu contrôles l’exécution (accès, permissions, données) ? Et est-ce que tu as un edge (expertise métier, canal de distribution, crédibilité, capacité d’intégration) ?
Si la réponse est oui, tu peux construire une offre solide. Même si techniquement, quelqu’un pourrait le coder. Parce qu’en pratique, personne n’a le temps, l’envie, et la rigueur opérationnelle pour le faire bien.
Des directions de business IA concrètes, racontées comme des offres (pas comme des features)
Pour rendre ça plus tangible, voilà quelques directions typiques, décrites comme de vraies offres.
Imagine une offre “qualification inbound + rendez-vous”. Tu branches la boîte mail, tu détectes les demandes, tu poses deux ou trois questions si besoin, tu qualifies, tu proposes un créneau, tu crées la fiche dans le CRM, et tu envoies un récap. L’agent fait le gros du boulot, mais il y a un cadre: règles de qualification, ton de communication, exceptions, escalade vers un humain. Tu vends une promesse simple: un certain nombre de rendez-vous tenus, avec un reporting. Ce n’est pas “un outil”, c’est une machine de conversion.
Ou une offre “recouvrement intelligent”. La plupart des PME ont des factures qui traînent, et la relance est faite tard, ou jamais, ou mal. Tu peux construire un système qui relance avec tact, suit les promesses de paiement, escalade quand il faut, et alerte l’équipe. Tu vends une réduction du DSO, ou un montant recouvré. Là encore, c’est un outcome. Et l’IA te permet d’adapter le message, de suivre, de faire les tâches répétitives.
Autre direction: “support niveau 1”. Beaucoup d’équipes support passent leur temps à répondre à des questions répétitives, chercher dans la doc, et escalader. Un agent bien cadré peut traiter une grosse partie, avec une validation sur les cas sensibles, et un log complet. Tu vends un temps de réponse réduit, une baisse du backlog, et une meilleure satisfaction. Et tu te places là où le client n’a pas envie de bricoler un script maison qui répond à côté.
Tu peux décliner ces offres dans des verticals très précis. La mécanique reste la même: outcome, workflow, intégration, gouvernance.
Un plan de lancement réaliste: commencer en service, puis productiser
Si tu veux te lancer maintenant, le chemin le plus solide (et le moins fantasme) ressemble souvent à ça.
Tu commences par une offre simple, très ciblée. Tu la fais tourner chez 2 ou 3 clients. Tu observes les exceptions, les cas limites, les détails qui font que “ça marche vraiment”. Tu construis un playbook. Tu ajoutes du monitoring. Tu rends ça robuste. Et seulement après, tu vois ce qui peut devenir un produit.
Ce chemin est puissant parce qu’il te donne:
- une compréhension réelle du terrain
- des références clients
- un pricing basé sur la valeur
- des patterns concrets à productiser
Et surtout, ça te sort du piège “je construis une app et j’espère que les gens viendront”. Dans un monde où les outils se copient vite, la distribution et la confiance deviennent centrales. Le service t’aide à les construire.
La vraie conclusion: le SaaS ne meurt pas, il migre vers l’exécution et la confiance
Si on enlève les slogans, voilà ce qui se passe.
Oui, une partie du SaaS va se faire grignoter, surtout les produits faibles en profondeur et faciles à remplacer. Oui, le custom devient plus accessible. Oui, les agents vont absorber une partie des usages.
Mais non, le besoin de logiciels fiables ne disparaît pas. Au contraire. Plus tu automatises, plus tu as besoin de contrôle, de qualité, d’audit, de garde-fous, et d’intégrations robustes.
Donc si tu veux construire un business IA, vise ce qui reste dur:
- livrer un résultat mesurable
- l’intégrer au réel
- gérer les exceptions
- maintenir dans le temps
- gagner la confiance
C’est là que la valeur va se concentrer.
Et au fond, c’est plutôt une bonne nouvelle. Parce que ça veut dire qu’il y a de la place pour des business très concrets, très opérationnels, pas juste des “apps cool”. Des business qui prennent un problème chiant, le rendent automatique, et le font tourner proprement.