Un SaaS n'est pas une application de gestion avec une page de connexion. C'est un produit où les données de chaque client doivent être hermétiquement séparées, où les rôles décident de tout, où l'abonnement conditionne les fonctions, et où une panne de connexion ne peut pas arrêter le travail de vos utilisateurs. Je construis ces quatre couches dès le départ, parce que les ajouter après coup revient à réécrire le produit.
Les signes qui reviennent le plus souvent
Vous vendez le même outil à plusieurs entreprises et chacune exige que ses données ne croisent jamais celles des autres.
Vos clients ne sont pas des utilisateurs isolés : un responsable et ses employés partagent le même compte parce que le produit n'a pas prévu les rôles.
Vous voulez facturer par palier, mais rien dans le code ne sait ce qu'un palier autorise.
Vos utilisateurs travaillent parfois sans connexion fiable et l'application les bloque.
Les livrables, pas les intentions
La séparation des données n'est pas un filtre dans le code de l'application, où un oubli suffit à tout exposer. Elle est posée dans la base elle-même, de sorte qu'une requête mal écrite ne puisse pas franchir la frontière.
Des rôles distincts avec une matrice de permissions explicite et testée, plutôt que des conditions dispersées dans les écrans.
Les limites et les fonctions de chaque palier, appliquées côté serveur. Un palier qui ne se vérifie que dans l'interface n'est pas un palier, c'est une suggestion.
L'application continue de fonctionner sans réseau et se resynchronise ensuite, avec une règle de résolution de conflit décidée à l'avance plutôt que subie.
Les chiffres qui décident (activité, retards, rentabilité par unité), calculés sur les données réelles et non sur un agrégat approximatif.
Quatre étapes, chacune avec sa sortie
Qui paie, qui utilise, ce qui distingue un palier du suivant. Ces trois réponses dessinent le modèle de données et la suite en découle.
Isolation, authentification, rôles et abonnements en premier. C'est la partie invisible que personne ne veut financer et qui décide pourtant de la solidité du produit.
Les fonctions qui font la valeur du produit, livrées les unes après les autres sur une version que vous pouvez montrer à vos premiers clients.
Déploiement, tests automatisés sur les parcours critiques, et suivi des usages réels pour savoir ce qui mérite la suite du budget.
Un projet livré, pas un argument
Un SaaS de gestion de flotte en production : 9 modules métier, 4 paliers d'abonnement, isolation par agence au niveau de la base et fonctionnement hors ligne complet.
Les réponses que je donne au téléphone
C'est la garantie que le client A ne peut jamais voir une ligne du client B, même par accident. Techniquement, je la pose dans la base de données avec des règles de sécurité au niveau des lignes : la base refuse elle-même de servir les données d'une autre organisation, indépendamment de ce que le code de l'application demande. Un filtre écrit uniquement dans l'application suffit à créer une fuite le jour où un développeur oublie une condition.
Cela dépend de vos utilisateurs. Pour des agences qui établissent un contrat au comptoir avec une connexion instable, oui : une application qui se bloque parce que le réseau tombe est abandonnée en quelques jours. Le vrai coût du hors ligne n'est pas l'affichage, c'est la règle de synchronisation, et il faut la décider avant d'écrire la première ligne.
Oui, et je commence par un audit honnête : ce qui tient, ce qui doit être repris, ce qui coûtera plus cher à réparer qu'à réécrire. Vous recevez ce constat avant de vous engager sur la suite.
Les paliers et leurs limites vivent dans le produit, l'encaissement dépend de votre marché : prestataire de paiement là où il est disponible, facturation hors application là où il ne l'est pas. Dans les deux cas, c'est le serveur qui décide de ce qu'un palier autorise.
Le socle (isolation, rôles, abonnements) et un premier module métier forment une version démontrable à des clients pilotes. C'est le jalon que je vise en premier, parce que c'est celui qui vous apprend si le produit se vend, avant que le budget parte dans des fonctions que personne ne réclamera.
Quand le tableur devient le système d'information de l'entreprise, chaque nouvelle activité ajoute un fichier, un classeur et une personne qui sait s'en servir. Je conçois et je livre le logiciel de gestion qui remplace cet empilement : un seul endroit où l'information entre, une seule version qui fait foi, et des règles métier qui empêchent les erreurs au lieu de les constater après coup.
Un catalogue qui ne sort pas sur les recherches de vos clients n'est qu'un PDF avec une adresse web. Je construis des sites où chaque fiche produit est une page à part entière, lisible par Google comme par un acheteur pressé, avec la structure technique qui décide du référencement : pages rapides, titres et descriptions uniques, données structurées, et version bilingue quand le marché l'exige.
Un projet abandonné en cours de route, un prestataire parti, une facture d'hébergement qui grossit sans raison claire : ce sont des situations ordinaires et elles se traitent. Je commence toujours par un audit qui dit la vérité, y compris quand elle est désagréable, puis je reprends, je migre ou je remplace, avec un chiffrage par étape plutôt qu'un grand soir.