Remplacer un SaaS par l'IA : la fin de l'abonnement par défaut
Faut-il remplacer un SaaS par un logiciel sur mesure développé avec l'IA ? Coût complet, agents, propriété et réversibilité : le calcul pour une PME belge.
Votre logiciel vous coûte tous les mois. Il fait trop de choses, sauf exactement ce dont votre entreprise a besoin. Avec l'IA, le redévelopper devient une option à examiner sérieusement, mais encore faut-il comparer un service qui tourne avec autre chose qu'une belle démonstration.
J'ai publié une formule volontairement brutale : « L'IA a tué le SaaS ». La décision derrière cette phrase était réelle : remplacer mes usages de HubSpot par un CRM interne, pensé pour être utilisé par des agents. La formule mérite maintenant une explication plus précise que celle d'un post.
Ce qui est fragilisé, c'est l'abonnement par défaut. Pas l'existence de tous les logiciels en ligne.
Voici ce qui change, ce qui reste coûteux et comment arbitrer entre acheter un autre outil et développer son logiciel sur mesure avec l'IA.
La fin du SaaS ? Il faut regarder autre chose que le cours de Bourse
Un SaaS est un logiciel fourni comme un service, généralement accessible en ligne contre un abonnement. L'entreprise achète un accès, des fonctionnalités et une exploitation prise en charge. Elle n'achète généralement pas le code source du produit.
Ce modèle reste parfaitement défendable. Personne n'a intérêt à reconstruire chaque outil utilisé dans sa société.
Dans mon post du 3 septembre 2026, je citais les baisses boursières d'éditeurs de logiciels. Mais une baisse du cours ne mesure ni le nombre de clients partis ni le coût de remplacement de leur système. Elle peut refléter des anticipations sur la croissance, les marges ou la concurrence. Elle ne suffit pas à prouver que le produit est devenu inutile, encore moins que l'IA explique seule le mouvement.
Un contrepoint concret : dans ses résultats publiés le 27 mai 2026, Salesforce annonçait un chiffre d'affaires trimestriel de 11,1 milliards de dollars, en hausse de 13 % sur un an. Ce chiffre inclut la contribution d'Informatica, précisée dans le communiqué. Il ne raconte pas une disparition de l'activité.
La thèse utile pour un dirigeant est ailleurs. Un abonnement doit désormais se justifier face à une alternative plus crédible : un outil limité à ses besoins, dont il peut organiser la maîtrise. C'est ce déplacement du calcul économique qui mérite l'attention.
Le rapport Build vs. Buy de Retool, publié le 17 février 2026, donne un signal concret : 35 % des répondants disent avoir déjà remplacé au moins un outil SaaS par un développement spécifique, et 78 % prévoient de construire davantage de leurs propres outils en 2026.
La nuance compte : l'enquête a été menée fin 2025 auprès de 817 personnes qui construisent des outils, dont des clients de Retool. Ce n'est pas un échantillon représentatif de toutes les entreprises, encore moins des PME belges. L'éditeur vend lui-même une plateforme de développement. Ces réponses déclaratives montrent un mouvement dans cette population ; elles ne prouvent ni un remplacement intégral des produits ni la rentabilité de chaque projet. Et les intentions pour 2026 ne sont pas des résultats acquis.
1. L'IA change le coût de fabrication, pas le coût de tout le service
Refaire ce que vous utilisez n'est pas recopier tout le produit
Un CRM généraliste doit satisfaire des entreprises très différentes. Il accumule des modules, des options et des réglages. Votre équipe n'en utilise qu'une partie, parfois avec des fichiers à côté pour gérer ce qui manque.
Le projet intéressant consiste à isoler cette partie utile. Les contacts, les opportunités, les prochaines actions et quelques règles métier peuvent former un système cohérent. Reproduire toute la plateforme de l'éditeur, avec son écosystème, ses intégrations et ses années de cas particuliers, est un autre chantier.
L'IA peut aider à écrire du code, préparer des tests, documenter et explorer des solutions. Le gain dépend du périmètre, de l'existant et de la qualité du contrôle. Une interface convaincante obtenue rapidement ne prouve pas qu'une migration complète sera rapide.
La bonne question est donc : « De quelles fonctions avons-nous réellement besoin ? » Pas : « Peut-on refaire Salesforce ? »
Le cas du redéveloppement d'un CRM illustre bien cette distinction : la reprise de l'historique, les droits d'accès et les règles de suivi comptent autant que l'écran des opportunités.
Le travail continue après la première version
Quelqu'un doit comprendre les exceptions. Nettoyer les données. Reconstituer les relations entre les dossiers. Vérifier les exports. Former l'équipe. Puis faire fonctionner l'ensemble quand une connexion tombe ou qu'une règle métier change.
À cela s'ajoutent l'hébergement, les sauvegardes, la surveillance, les mises à jour, le support et les évolutions. Si le logiciel utilise un modèle d'IA, sa consommation et son évaluation font aussi partie du coût.
Ces postes ne disparaissent pas parce que le code a été généré plus vite. Ils passent de la facture d'un éditeur à votre organisation et à vos prestataires.
Dire « mon CRM ne m'a rien coûté » efface mon propre temps, le cadrage et la maintenance. Ce n'est pas une comparaison honnête pour une PME qui doit mobiliser son équipe ou acheter cette compétence. L'article sur le coût d'un projet IA dans une PME détaille ces postes souvent oubliés.
La qualité non plus n'est pas automatique. Le Secure Software Development Framework du NIST, version 1.1 publiée en février 2022, décrit des pratiques à intégrer au cycle de développement pour réduire les vulnérabilités et traiter leurs causes. Générer du code ne remplace pas ce travail. Les permissions, les tests de restauration et la gestion des incidents restent des sujets concrets.
2. La dépendance devient un choix à rendre visible
Le SaaS peut être confortable jusqu'au jour où l'entreprise veut en sortir.
Elle découvre alors que récupérer des lignes dans un fichier ne suffit pas. Il faut les pièces jointes, l'historique des échanges, les liens entre les objets, les règles et parfois des journaux d'activité. Une exportation disponible dans un menu n'est pas encore une migration réussie.
Il faut toutefois éviter un raccourci : utiliser un SaaS ne signifie pas automatiquement perdre ses droits sur ses données. Les contrats et les possibilités techniques varient. Ce qu'il faut examiner, c'est la capacité réelle à récupérer et réutiliser l'information, dans des conditions connues.
Le sur-mesure peut améliorer cette maîtrise. Il peut aussi déplacer la dépendance vers une personne qui connaît seule le système.
La propriété se vérifie dans les droits et dans les accès
« Le logiciel vous appartient » mérite des précisions écrites. Quels droits sur les développements spécifiques ? Quelles licences sur les composants tiers ? Qui contrôle les comptes d'hébergement, le dépôt de code et les sauvegardes ? Qui peut autoriser un autre prestataire à reprendre ?
La possession d'une archive de code n'apporte pas grand-chose si personne ne sait la déployer. Et le fait de payer un développement ne règle pas, à lui seul, toutes les questions de droits. Ces points se cadrent au contrat avec le conseil compétent.
La réversibilité se teste
Un dispositif reprenable comprend au minimum :
- Le code et son historique accessibles à l'entreprise.
- Une description des données et des règles métier.
- Des procédures de déploiement, de sauvegarde et de restauration.
- Une liste des services externes, des licences et des coûts récurrents.
- Une procédure de transmission des accès, sans secrets dans la documentation.
- Des conditions de sortie précisant l'assistance et ce qu'elle coûte.
Le test le plus parlant consiste à faire relire cet ensemble par une autre personne compétente. Peut-elle comprendre le fonctionnement et préparer une reprise sans dépendre de l'auteur initial ?
La promesse sérieuse est une dépendance maîtrisée et réversible. Le « zéro dépendance » oublie au passage le cloud, les bibliothèques, les modèles et les gens qui interviennent.
3. Les agents déplacent la valeur de l'interface vers l'action
La troisième raison de repenser un logiciel n'est pas son prix. C'est son utilisateur.
Un outil conçu pour des humains organise le travail autour d'écrans : ouvrir une fiche, modifier un champ, choisir un statut, retrouver la prochaine relance. Un agent peut recevoir un objectif et effectuer certaines de ces opérations par des accès programmatiques, si le système les expose et les autorise.
Dans mon CRM interne, l'intention était précisément de confier ces manipulations aux agents. Ce retour d'expérience, décrit dans le post de septembre, porte sur mes usages. Il ne prouve pas qu'une équipe commerciale entière devrait abandonner son interface.
Un logiciel pensé pour des agents doit surtout rendre ses actions compréhensibles et contrôlables : rechercher un contact, proposer une mise à jour, enregistrer une interaction. Chaque action doit avoir des droits explicites, des conditions d'exécution et une trace.
Une action qui engage l'entreprise peut exiger une validation humaine. Un résultat ambigu doit pouvoir être revu. Et une personne doit toujours disposer d'un moyen de comprendre ce qui s'est passé.
L'interface ne devient donc pas forcément inutile. Elle peut devenir le poste de supervision : voir les exceptions, corriger, valider, reprendre la main. Notre article sur la différence entre chatbot, agent IA et automatisation explique pourquoi ces fonctions ne demandent pas toutes le même outil.
Surtout, un SaaS existant peut déjà disposer de bonnes API et accueillir des agents. Dans ce cas, le compléter peut être beaucoup plus raisonnable que le remplacer. La capacité à automatiser est un critère d'architecture, pas une preuve que tout doit être développé en interne.
Pour une PME belge, commencer par la périphérie
Le bon premier candidat est un périmètre compréhensible, limité et mesurable. Un planning particulier. Un portail de suivi. Un circuit de validation. Un reporting qui impose trop de manipulations. Un CRM simple dont les règles tiennent dans une description claire.
L'intérêt augmente quand l'outil actuel oblige l'équipe à multiplier les contournements ou quand le coût des licences grandit sans valeur supplémentaire correspondante. Encore faut-il vérifier que le problème vient du produit, et non d'un mauvais paramétrage ou d'un processus devenu inutile.
À l'inverse, reconstruire la paie, la comptabilité ou le cœur d'un ERP est rarement un premier test raisonnable. Le produit comprend des règles réglementaires, des contrôles et des dépendances qui dépassent largement les écrans visibles. Refaire une page de facture ne revient pas à reprendre toute une chaîne de facturation.
Pour ces systèmes, une extension ou une couche d'automatisation peut apporter l'essentiel du gain tout en conservant le socle éprouvé. Un logiciel libre adapté peut aussi constituer une voie intermédiaire, avec ses propres coûts d'intégration et d'exploitation.
Enfin, héberger soi-même ne règle pas automatiquement la protection des données. Pour une PME belge, il faut identifier les données traitées, les accès, les sous-traitants et les flux, puis faire vérifier le cadre applicable. La checklist RGPD et IA dans une PME belge, datée du 8 septembre 2026, aide à poser ces questions. Une localisation européenne ne répond pas à tout.
Racheter un SaaS ou redévelopper : comparer les options réelles
Sortir d'un outil ne conduit pas obligatoirement au sur-mesure. Un autre SaaS peut mieux correspondre au besoin, un paramétrage peut suffire et une partie du processus peut simplement disparaître.
Voici une grille de départ, pas une règle universelle.
| Option | Quand l'examiner | Ce qu'il faut vérifier |
|---|---|---|
| Garder et mieux configurer | Le produit convient, mais l'usage est mal organisé | Fonctions inutilisées, règles devenues obsolètes, licences réellement nécessaires |
| Acheter un autre SaaS | Le besoin est standard et un produit le couvre mieux | Coût de migration, limites de l'offre, intégrations et conditions de sortie |
| Compléter l'existant | Le socle fonctionne, mais une étape spécifique bloque | Accès aux données, stabilité des interfaces et responsabilité en cas d'incident |
| Redévelopper le périmètre utile | Le besoin est spécifique et les alternatives imposent trop de compromis | Coût complet, continuité de service, maintenance et reprise par un tiers |
Le calcul doit porter sur la même durée
Comparer une année d'abonnement au seul prix de construction mélange deux choses différentes. Choisissez un horizon commun, par exemple 3 ans, puis détaillez les postes des deux côtés.
Pour le SaaS : licences, options, intégrations, paramétrage, administration interne, formation et coût de sortie. Pour le sur-mesure : cadrage, construction, migration, période de coexistence, formation, exploitation, corrections, évolutions et sortie. Le temps de votre équipe compte dans les deux cas.
Le gain attendu peut inclure du temps récupéré ou moins d'erreurs. Il faut alors le mesurer sur le processus réel. Des heures libérées ne deviennent pas mécaniquement une économie de trésorerie : elles peuvent surtout permettre de servir davantage de clients ou de réduire un retard.
Le délai de retour théorique correspond à l'investissement initial supplémentaire divisé par l'économie récurrente nette attendue, si celle-ci est positive. Cette estimation reste fragile si les besoins changent ou si le coût de maintenance est sous-estimé. Elle doit donc être accompagnée d'un scénario moins favorable.
Si le projet ne tient financièrement qu'en supprimant la ligne maintenance, il ne tient pas.
Le pilote qui permet vraiment de décider
Un pilote utile ne cherche pas à impressionner avec toutes les fonctions du futur logiciel. Il cherche à réduire les inconnues qui pourraient faire échouer la décision.
Le périmètre doit inclure un parcours métier complet, des données représentatives et des exceptions. Pas seulement le cas idéal. Il faut notamment vérifier les droits, les doublons, les dossiers incomplets et la reprise après une erreur.
La migration mérite son propre essai. Reprendre un échantillon permet de voir ce que l'export oublie, ce qui doit être nettoyé et ce qui nécessite une décision humaine. L'ancien système reste disponible selon un plan de coexistence défini avant la bascule.
Les critères de réussite s'écrivent avant de construire : travail réellement retiré à l'équipe, erreurs acceptables, opérations encore manuelles, coût d'exploitation et conditions de retour en arrière. Le support après livraison doit avoir un responsable identifié.
À la fin, trois conclusions sont légitimes : poursuivre le redéveloppement, réduire son périmètre ou conserver le logiciel actuel. Un pilote qui évite une mauvaise migration a aussi produit de la valeur.
Ce que le SaaS doit désormais justifier
Les logiciels dont la valeur tient à des données difficiles à reproduire, à un réseau d'utilisateurs, à une expertise réglementaire ou à une exploitation exigeante gardent de solides arguments. Un abonnement peu coûteux peut également rester imbattable face au temps nécessaire pour le remplacer.
Les éditeurs peuvent eux-mêmes intégrer l'IA, améliorer leurs interfaces programmatiques et adapter leur offre. Rien n'oblige le marché à se diviser entre des SaaS condamnés et du sur-mesure gagnant partout.
En revanche, payer indéfiniment un outil mal adapté au seul motif que « développer serait forcément trop cher » devient une hypothèse à vérifier. L'IA rend cette vérification plus intéressante. Elle ne dispense ni du calcul ni de l'organisation.
La fin du SaaS comme choix unique est une idée plus utile que la fin du SaaS tout court. Le bon logiciel est celui dont l'entreprise comprend la valeur, assume le coût complet et peut préparer la sortie.