Comment les consultants en IA cadrent le remplacement d'un SaaS en interne

Tout consultant digne de ce nom cadre le remplacement d'un SaaS en interne de la même façon : en séparant chaque outil entre les parties visibles et celles qui doivent être exactes à chaque fois. Un SaaS (un logiciel loué au mois) est principalement composé d'écrans, de flux de travail et de rapports reposant sur un noyau plus restreint de données de référence. L'IA a rendu la première moitié très peu coûteuse à reconstruire. C'est sur la seconde moitié que les projets de remplacement échouent, et un bon cadrage sert précisément à mesurer la part réelle de votre abonnement qui s'y trouve.

Voici comment se structure pas à pas le cadrage du remplacement d'un SaaS en interne, et la question essentielle qui détermine l'essentiel des choix. (Les noms de fournisseurs et les chiffres d'enquêtes ci-dessous sont exacts au moment de la publication ; considérez-les comme un état des lieux à un instant T.)

Que contient réellement le cadrage d'un remplacement de SaaS ?

Un inventaire des tâches, et non une liste de fonctionnalités. Le consultant répertorie chaque tâche effectuée par l'outil, les personnes qui l'utilisent, et les conséquences d'un résultat erroné. Les chaînes d'approbation, les tableaux de bord et les formulaires vont dans une colonne. Les mouvements d'argent, les comptages de stock, la fiscalité et les dossiers des employés vont dans une autre. Le livrable est cette cartographie, assortie d'un niveau de risque par tâche et de la liste de tous les systèmes auxquels l'outil est discrètement connecté.

La question d'évaluation est le cœur du problème : si ce résultat était faux, comment le sauriez-vous et combien cela coûterait-il ? Un tableau de bord périmé se repère d'un coup d'œil et ne coûte rien. Un total de versement erroné se découvre au moment des déclarations fiscales et coûte très cher.

Pourquoi diviser le produit en deux couches ?

Parce que l'IA a effondré le coût d'une couche tout en laissant l'autre intacte. La couche d'interface (formulaires, tableaux de bord, outils internes, flux d'approbation) se reconstruit désormais rapidement ; les modèles actuels génèrent des applications web fonctionnelles en quelques heures, ce que nous avons constaté lorsque nous avons demandé si GPT-5.6 pouvait créer un POS fonctionnel. La couche d'infrastructure est différente : traitement des paiements, conformité PCI (les règles de sécurité des cartes imposées par les processeurs), gestion des stocks en accès simultané (deux caisses vendant la dernière unité en même temps) et rapports de rapprochement (des totaux qui correspondent à vos dépôts bancaires). Cette couche n'est pas difficile parce que le code est long. Elle est difficile parce qu'un résultat « presque correct » n'y a aucune valeur, et prouver l'exactitude coûte plus cher que générer le code.

Des modèles plus performants ne suppriment pas non plus cette contrainte. Le goulot d'étranglement réside dans la vérification et la responsabilité, pas dans la génération de code ; un cadrage honnête chiffre donc la vérification. La génération est la démonstration. La vérification est la facture.

Qu'a réellement prouvé le remplacement de SaaS chez Klarna ?

L'histoire la plus médiatisée sur le thème « nous avons remplacé notre SaaS par l'IA » est en réalité une leçon de cadrage. Fin 2024, le PDG de Klarna a annoncé que l'entreprise abandonnait Salesforce et Workday dans le cadre d'une refonte axée sur l'IA, et les médias ont titré que l'IA remplaçait purement et simplement le SaaS. Les analyses ultérieures ont révélé une réalité plus restreinte : Klarna a migré ses RH vers un autre fournisseur et a couvert ses besoins en CRM grâce à un mélange d'outils alternatifs et d'intégrations internes, sur lesquels a été ajoutée une couche d'IA¹. Une banque agréée gérant l'un des programmes d'IA les plus agressifs de la fintech a conservé ses systèmes de référence (la source d'autorité de ses données d'entreprise) sur des plateformes éprouvées et a reconstruit uniquement les contours.

Ce n'était pas un manque d'audace. C'était le résultat d'un cadrage réussi.

Quels chiffres justifient un projet de remplacement ?

Éliminer le gaspillage d'abord, développer ensuite. L'indice SaaS Management 2026 de Zylo, fondé sur plus de 40 millions de licences gérées, établit la dépense SaaS médiane à 9 455 $ par employé et par an, révèle que 36 % des licences en moyenne restent inutilisées, et montre que les unités opérationnelles contrôlent 81 % des dépenses SaaS tandis que l'IT n'en gère directement que 15 %². Un consultant évalue votre environnement logiciel par rapport à ces chiffres avant de proposer quoi que ce soit : annuler les accès inutilisés, consolider les outils redondants, puis seulement sélectionner les candidats à une reconstruction.

Les outils retenus partagent le même profil : un coût récurrent élevé, des tâches situées principalement au niveau de l'interface et un impact réduit en cas de panne. Le projet est approuvé lorsque le coût de l'abonnement augmente plus vite que le coût de développement et de maintenance, et que chaque tâche nécessitant une exactitude absolue peut rester sur une infrastructure exploitée par un tiers.

Quelle est la position d'un POS dans ce cadrage ?

À l'extrémité la plus exigeante du spectre. Un point de vente ressemble à un projet d'interface, une grille de boutons et un panier, ce qui amène les propriétaires à penser qu'il se cadre comme un tableau de bord. La réalité est inverse. L'écran de paiement ne représente qu'une infime partie du produit ; le reste concerne les paiements, le matériel certifié pour la lecture de cartes, les stocks gérés en temps réel sur plusieurs caisses, les règles fiscales et les rapports de fin de journée avec rapprochement. Quand un POS se trompe, il se trompe sur l'argent, au quotidien.

Les consultants cadrent donc la reconstruction d'un POS comme Klarna a cadré son grand livre : interface personnalisée, infrastructure éprouvée. Une telle séparation nécessitait autrefois une équipe de développeurs. C'est aujourd'hui une catégorie de produits à part entière : Build de Final transforme une consigne en langage naturel en un flux de paiement que vous pouvez prévisualiser et déployer, et vous pouvez connecter votre propre IA via MCP pour développer sur cette même infrastructure commerciale. Les paiements, les stocks, les rapports et le matériel restent sur la couche déjà vérifiée.

Comment devez-vous cadrer le remplacement d'un SaaS en interne ?

Divisez chaque outil en deux couches, évaluez chaque tâche selon le coût d'un résultat erroné non détecté, et chiffrez la vérification plutôt que le code. Reconstruisez librement les interfaces et les flux de travail ; laissez les systèmes de référence sur une infrastructure maintenue par des tiers. Avant de reconstruire un outil en interne, posez-vous cette question : si son résultat était faux, dans combien de temps m'en rendrais-je compte ? Si la réponse est « pas immédiatement », cette tâche doit rester sur des rails éprouvés.

Et si vous souhaitez reconstruire la partie commerciale de votre environnement, commencez par évaluer objectivement ce que les modèles actuels peuvent et ne peuvent pas créer seuls : Claude vs ChatGPT vs Gemini sur la création d'un POS réel, ou les deux approches sans code détaillées dans comment utiliser Gemini 3.6 Flash pour créer un POS personnalisé.