La réponse honnête, c'est que le SaaS a sa place. Pour une fonction isolée, standardisée, sans interaction critique avec le reste de votre activité, c'est souvent le bon choix. Personne ne devrait écrire son propre client mail.

Mais quand on parle du cœur opérationnel d'une entreprise — la mémoire de vos clients, le suivi de vos affaires, les liens entre vos métiers — la question n'est plus « quel outil acheter ». Elle devient « quel niveau de souveraineté je veux sur mes opérations ». Et là, la réponse mérite un examen sérieux.

Ce qui suit est une grille de sept critères. Elle ne tranche pas pour vous. Elle vous donne les bons axes pour trancher vous-même, sans vous laisser hypnotiser par des démos commerciales ou par la peur du sur-mesure. Si après les sept critères le SaaS reste votre réponse, c'est qu'il l'était vraiment.

1. Souveraineté des données

La première question n'est pas technique, elle est juridique. À qui appartient le schéma de votre base ? Qui peut, demain matin, sortir un dump SQL complet de votre activité et le poser sur un autre serveur ?

Avec un SaaS, la réponse est presque toujours la même : vous avez accès à vos données par une API ou un export CSV, dans le format que l'éditeur veut bien vous donner, au rythme qu'il veut bien autoriser. Vous êtes locataire de votre propre mémoire.

Avec un Backoffice propriétaire, le schéma vous appartient. Les tables, les relations, les index, les fichiers — tout est sur un serveur que vous contrôlez, ou que vous pouvez à tout moment migrer. Un export complet est une commande de trois lignes, pas une demande de support.

Pour une PME suisse soumise à la LPD révisée, à des obligations sectorielles, ou simplement à une exigence de discrétion vis-à-vis de ses clients, cette différence n'est pas philosophique. Elle est opérationnelle.

2. Coût total sur dix ans

Le SaaS séduit par son ticket d'entrée : quelques dizaines de francs par utilisateur et par mois, pas d'investissement initial, on annule quand on veut. Sur la première année, c'est imbattable.

Sur dix ans, la courbe est moins flatteuse. Un SaaS facture linéairement, parfois plus que linéairement à mesure que votre équipe grandit et que vous changez de palier de licence. Cinq outils SaaS pour une PME de quarante personnes, c'est facilement quarante à soixante mille francs par an de licences récurrentes. Sur dix ans, vous avez payé un demi-million sans rien posséder.

Un Backoffice sur mesure suit une courbe en J : un investissement initial significatif, puis une maintenance évolutive bien plus légère. Le point d'équilibre se situe typiquement entre la troisième et la cinquième année. Au-delà, vous capitalisez. Le système devient un actif, pas une dépense.

3. Verrouillage et réversibilité

Sortir d'un SaaS, ce n'est jamais aussi simple que ce que la page de tarification laisse entendre. Les exports sont partiels. Les workflows ne s'exportent pas. Les automatisations sont propriétaires. Les historiques de modification, les fichiers attachés, les commentaires, les permissions — tout cela disparaît ou se dégrade.

Au bout de trois ans dans un outil, vos équipes ont construit une mémoire qui n'est plus dans les données, mais dans les conventions, les vues, les boards, les filtres. Migrer, c'est repartir presque à zéro.

Un système que vous possédez ne pose pas ce problème. Vous pouvez le faire évoluer, le réécrire par morceaux, en changer la couche frontale, migrer la base : à chaque étape, vous gardez la continuité parce que le schéma est à vous. La réversibilité n'est pas une option commerciale, c'est une propriété structurelle du système.

4. Adaptation au métier

Un SaaS est, par construction, un compromis entre les besoins de milliers de clients. Il fait quatre-vingts pour cent de ce que la moyenne attend, et ces quatre-vingts pour cent sont souvent excellents. Le problème, c'est les vingt restants.

Si votre métier comporte des étapes inhabituelles — un workflow de validation à trois niveaux propre à votre secteur, un calcul de marge qui dépend de variables que personne d'autre n'utilise, une relation entre vos affaires et votre comptabilité qui ne ressemble à aucun CRM générique — vous allez passer votre temps à contorsionner votre opération pour qu'elle rentre dans l'outil.

Un Backoffice sur mesure inverse la logique. C'est l'outil qui épouse le métier, pas l'inverse. Pour une PME dont l'avantage concurrentiel tient précisément à ses méthodes particulières, cette différence se mesure en heures gagnées chaque semaine, et en frustrations évitées.

5. Continuité dans le temps

Un SaaS dépend d'une entreprise tierce. Cette entreprise peut être rachetée, pivoter, fermer, abandonner votre cas d'usage, monter ses prix de trente pour cent à la prochaine levée de fonds, ou simplement décider que votre marché n'est plus prioritaire.

Ce ne sont pas des hypothèses théoriques. Tout dirigeant un peu expérimenté a déjà vécu une migration forcée parce que l'éditeur historique a été racheté, ou parce que la nouvelle version a cassé une fonctionnalité critique. C'est un coût caché du SaaS qui n'apparaît jamais dans les comparatifs.

Un Backoffice propriétaire ne dépend que de vous, de votre serveur, et de la disponibilité de techniciens capables d'intervenir dessus. Les technologies utilisées — typiquement un stack standard, lisible, documenté — restent maintenables pendant des décennies. La continuité n'est pas une promesse commerciale. C'est une propriété du choix technologique.

6. Intégration avec l'existant

Votre activité ne tient pas dans un seul outil. Il y a la comptabilité, les comptes bancaires, le planning, la facturation, peut-être un ERP métier, peut-être un système de production audio, vidéo, industriel. Ces flux doivent se parler.

Avec un assemblage de SaaS, chaque intégration est un projet. Zapier au milieu, des webhooks fragiles, des duplications de données entre outils, des points de synchronisation qui cassent silencieusement. Chaque ajout d'un nouveau SaaS multiplie les connexions à maintenir.

Un Backoffice propriétaire devient naturellement le pivot. Les imports bancaires, les exports comptables, les API tierces — tout est centralisé dans un système où vous décidez de la logique d'intégration, où vous voyez les flux, où vous pouvez auditer ce qui passe et ce qui ne passe pas. Les SaaS qui restent autour deviennent des satellites, pas des dépendances.

7. Transmission

C'est le critère qu'on oublie le plus souvent, et qui finit par compter le plus. À qui passerez-vous votre système ?

À un successeur, le jour où vous vendrez ou transmettrez l'entreprise. À un autre fournisseur, si le développeur initial n'est plus disponible. À votre équipe interne, qui devra le faire évoluer dans dix ans.

Un assemblage de SaaS ne se transmet pas. Il se redécouvre par chaque nouvelle personne qui doit en comprendre les conventions, les hacks, les contournements accumulés au fil des années.

Un Backoffice conçu selon des axiomes clairs — schéma documenté, code lisible, dépendances minimales, technologies standard — se transmet. Un autre fournisseur peut reprendre le code. Un nouveau responsable opérationnel peut lire le schéma. La connaissance ne meurt pas avec la personne qui l'a construite. C'est précisément ce qui fait qu'un système peut survivre à son auteur.

Conclusion

Aucun de ces sept critères ne dit que le SaaS est mauvais. Beaucoup d'entreprises fonctionnent très bien avec un patchwork d'outils standard, et c'est tant mieux pour elles.

Mais ces sept critères disent une chose : le choix entre SaaS et Backoffice propriétaire n'est pas un choix de produit. C'est un choix de posture vis-à-vis de votre propre activité. Vous décidez quel niveau de contrôle, de pérennité, et de transmissibilité vous voulez sur ce qui constitue, concrètement, la mémoire opérationnelle de votre entreprise.

Si après cette grille vous trouvez encore que le SaaS reste la bonne réponse pour vous, c'est la bonne réponse. Elle aura simplement été réfléchie. C'est tout ce qu'on demande.