Remplacer un abonnement SaaS par une application locale alimentée par modèle ouvert : un cas observé

Note refondue le 25 mai 2026. Article initialement publié en avril 2026 — refonte intégrale au registre Cabinet.

Pendant quinze ans, le modèle d'abonnement logiciel — Software as a Service — s'est imposé comme le choix par défaut pour à peu près toutes les fonctions support d'une entreprise. Comptabilité, gestion documentaire, signature électronique, gestion de relation client, suivi des notes de frais, classement des factures : chaque fonction a trouvé son éditeur, chaque abonnement a trouvé son budget annuel, et l'addition s'est stabilisée sur des montants substantiels pour la moindre PME suisse.

Cette stabilité reposait sur une hypothèse implicite : développer une alternative interne serait nécessairement plus coûteux que l'abonnement, plus long à mettre en œuvre, et de qualité inférieure à ce que produisent des équipes d'éditeurs spécialisés. Cette hypothèse est en train de céder. La conjonction des modèles génératifs ouverts qui peuvent désormais s'exécuter sur du matériel d'entreprise courant et des assistants de développement qui accélèrent significativement la production de code redéfinit l'arbitrage. Cette note documente un cas observé sur cette bascule.

Le cas : la gestion documentaire fiscale d'un cabinet d'une personne

Le cas étudié est volontairement minuscule. Un cabinet de conseil indépendant, opéré par une personne, qui produit chaque année plusieurs centaines de documents administratifs à classer pour les besoins comptables et fiscaux : factures fournisseurs en format PDF, justificatifs photographiés, attestations diverses, décisions d'impôts cantonales, quittances bancaires. Le besoin opérationnel est trivial. Classer ces documents au fil de l'eau, les retrouver rapidement lors du bouclement annuel, conserver la traçabilité nécessaire en cas de contrôle fiscal.

La réponse classique du marché à ce besoin est l'abonnement à une solution de gestion documentaire fiscale, dont les tarifs se situent dans une plage habituellement comprise entre quelques dizaines et plus d'une centaine de francs par mois selon les fonctionnalités. Pour un cabinet d'une personne, le coût annuel cumulé n'est pas négligeable rapporté au volume effectif. Plus structurant : ces solutions hébergent les documents chez l'éditeur, qui se trouve fréquemment soumis à un droit étranger — typiquement le droit américain — sur des données qui peuvent contenir des éléments financiers et personnels couverts par des obligations de confidentialité. Ces situations peuvent soulever des questions de droit applicable et d'accès extraterritorial aux données.

L'alternative observée a pris une forme différente. Une application locale, qui s'exécute sur l'ordinateur personnel de l'utilisateur, alimentée par un modèle de langage ouvert également exécuté en local, qui classe automatiquement les documents déposés dans son interface, les renomme selon une convention cohérente, les range dans une arborescence propre, et permet une recherche en langage naturel sur l'ensemble des documents archivés. L'application a été développée sur un temps court, par dialogue itératif avec un assistant de codage. Le modèle utilisé est ouvert et exécuté entièrement sur la machine de l'utilisateur, sans appel réseau pour les opérations de classement.

La mécanique du déploiement

Le détail technique de la mécanique éclaire les conditions de réplicabilité du cas. Le système s'articule autour de quatre composants identifiables.

Un modèle de langage ouvert exécuté en local — la famille des modèles ouverts atteignant désormais des performances utiles sur du matériel d'entreprise courant, à condition d'une mémoire suffisante. Ce composant est le moteur d'analyse qui extrait du document déposé les éléments structurés : type de document, date, montant, émetteur, catégorie fiscale. Aucune donnée ne sort du périmètre matériel de l'utilisateur pour cette analyse.

Une interface utilisateur légère qui permet de déposer un document — fichier PDF ou photo prise au téléphone — et de visualiser la classification proposée. Cette interface est développée dans un cadre Python standard, qui ne demande pas de compétence avancée en développement web.

Une base de données locale — typiquement SQLite — qui indexe les documents classés et leurs métadonnées pour une recherche rapide.

Un agent conversationnel local, lui aussi alimenté par le modèle ouvert, qui interroge la base et permet une recherche en langage naturel : « retrouve-moi les justificatifs de déduction pour le pilier 3a sur les trois dernières années », « y a-t-il un document manquant pour cette décision d'impôt ».

L'ensemble représente, en volume de code, quelques centaines de lignes — un ordre de grandeur qui aurait été inatteignable il y a deux ans sans une équipe de développement dédiée. Les assistants de codage actuels permettent de tenir ce volume de production par dialogue itératif avec le développeur, qui formule des intentions et corrige les itérations successives.

Ce que ce cas démontre, et ce qu'il ne démontre pas

Le cas observé n'est pas une preuve générale que toute fonction logicielle peut être remplacée par une application locale. Il démontre une zone de bascule précise, qui mérite d'être identifiée pour ce qu'elle est.

La bascule fonctionne quand le besoin opérationnel est circonscrit, quand les données traitées doivent demeurer dans un périmètre contrôlé, quand l'effet de réseau d'une solution centralisée n'est pas la valeur principale — un outil de gestion documentaire personnel n'a pas de besoin de collaboration multi-utilisateurs ni de synchronisation entre des dizaines d'employés. Le cas étudié coche ces trois conditions.

La bascule ne fonctionne pas — ou pas encore — quand le besoin opérationnel implique des dizaines ou centaines d'utilisateurs en collaboration synchrone, quand les workflows reposent sur l'intégration avec des dizaines de services externes, quand la complexité fonctionnelle dépasse ce qu'un développeur unique peut tenir avec un assistant. Les éditeurs de logiciels d'entreprise gardent une valeur dans ces zones.

Entre les deux, il existe une zone substantielle d'outils logiciels que les PME suisses utilisent par abonnement, dont le besoin opérationnel est en réalité circonscrit, dont les données traitées gagneraient à demeurer dans un périmètre contrôlé, et dont la complexité fonctionnelle peut désormais être tenue par une équipe restreinte avec les outils disponibles. Cette zone se trouve en expansion observable.

Quatre questions à se poser avant le prochain renouvellement d'abonnement

Pour une PME suisse qui prépare son prochain cycle d'arbitrages logiciels, quatre questions se dégagent du cas observé.

L'outil d'abonnement utilisé fait-il exactement ce dont l'entreprise a besoin, ou l'entreprise s'est-elle adaptée aux limites de l'outil au fil des années ? La fonctionnalité utilisée représente-t-elle dix pour cent, vingt pour cent ou cinquante pour cent de ce qui est facturé ?

Les données traitées par cet outil peuvent-elles raisonnablement être confiées à un cloud tiers, au regard du cadre suisse de protection des données^[1] et des obligations de confidentialité du métier exercé ?

L'alternative sur mesure — application locale, modèle ouvert exécuté en local, code propriétaire de l'entreprise — est-elle effectivement hors de portée à l'échelle du besoin, ou ce jugement repose-t-il sur des hypothèses datant d'une époque où elle l'était effectivement ?

Le coût de sortie de l'abonnement — migration des données, requalification des collaborateurs, intégrations à refaire — est-il anticipé dans le coût total de possession actuel, ou s'agit-il d'une dette implicite que l'entreprise accumule à chaque renouvellement ?

Ces questions ne conduisent pas systématiquement à un remplacement de l'abonnement. Elles conduisent à un arbitrage informé, plutôt qu'à un renouvellement par habitude.

La portée du cas, au-delà du périmètre individuel

Le cas observé concerne une entité minuscule — un cabinet d'une personne, quelques centaines de documents par an, un usage strictement personnel. Sa portée pédagogique dépasse cependant son périmètre.

Ce qu'il démontre s'applique, à l'échelle, à des organisations beaucoup plus grandes qui empilent depuis quinze ans des dizaines d'abonnements sectoriels, chacun avec son tarif par utilisateur, ses hausses tarifaires annuelles, ses limites fonctionnelles contournées par des fichiers parallèles, ses données confiées à des hébergeurs soumis à un droit étranger. La logique qui rend l'alternative locale pertinente pour un cabinet de conseil indépendant rend l'alternative interne pertinente pour des PME et des structures plus importantes, sur certaines fonctions précises de leur arsenal logiciel.

Cette extension n'est pas une promesse universelle. Elle est une zone d'arbitrage qui mérite d'être qualifiée pour chaque organisation, dans son contexte propre, avec ses contraintes réelles. La note SaaS contre développement sur mesure en Suisse aborde cette question à une échelle plus large.

Ce que le cas observé exclut, en revanche, c'est l'argumentation selon laquelle l'alternative interne serait par principe impossible pour la PME suisse. Cette argumentation, qui avait sa pertinence pendant la décennie où les modèles génératifs étaient inaccessibles et où le coût du code restait prohibitif pour une fonction interne, ne tient plus. Le terrain s'est déplacé sous les hypothèses, et les arbitrages mériteraient d'être posés à neuf.

Sources

[1] Loi fédérale sur la protection des données (LPD), révision du 25 septembre 2020, entrée en vigueur le 1ᵉʳ septembre 2023. www.fedlex.admin.ch/eli/cc/2022/491/fr [↩]

Jérôme Deshaie est CEO de MCVA Consulting SA, cabinet suisse de conseil stratégique en intelligence artificielle, basé en Valais.