La moitié des projets SaaS sur-mesure que je récupère en reprise étaient bien partis sur le papier. Ils ont déraillé entre le sprint 2 et le sprint 4, presque toujours pour la même raison : un cadrage bâclé. Pas un cadrage absent, un cadrage approximatif. Un atelier de deux heures, une note de synthèse, un devis, et puis on attaque. Quelques mois plus tard, le périmètre a triplé, le budget a doublé, et le porteur du projet ne sait plus pourquoi il a lancé l'affaire. Cet article décrit comment cadrer un projet SaaS sur-mesure (aussi appelé logiciel métier sur-mesure hébergé en mode SaaS) de manière structurée, en 4 à 6 semaines, avec des livrables solides qui tiennent la durée du projet.
Cadrer un projet SaaS : pourquoi c'est la phase la plus rentable
Le cadrage est la phase où vous coûte le moins cher de changer d'avis. Une fois le développement lancé, chaque révision de périmètre se paie en jours-homme. Pendant le cadrage, les arbitrages se font en heures d'atelier. Pourtant, beaucoup de porteurs cherchent à passer cette phase vite, comme si c'était de la perte de temps. C'est l'inverse : chaque jour bien investi au cadrage évite trois à cinq jours en cours de développement, d'expérience sur les projets que je livre depuis 2014.
Un cadrage rigoureux n'est pas un cahier des charges. C'est une démarche structurée qui produit plusieurs livrables complémentaires : une vision business chiffrée, une cartographie des utilisateurs, un périmètre MVP arbitré, des choix techniques posés, un planning de sprints et un devis tenable. Tout ça en 4 à 6 semaines, pas en 4 à 6 mois. Le format court force la discipline et empêche le projet de s'étaler avant même d'avoir commencé.
La recherche en gestion de projet de Harvard Business School documente régulièrement que les projets informatiques échouent rarement sur la technique. Ils échouent sur le manque de clarté initiale : objectifs flous, parties prenantes désalignées, périmètre incertain. Un cadrage propre traite exactement ces trois points.
Cadrage vs intuition : pourquoi la démarche structurée gagne
Beaucoup de porteurs de SaaS me disent : « J'ai déjà la vision claire, je sais ce que je veux. » Soit. Mais une vision en tête, c'est différent d'un document validé par cinq personnes qui doivent tirer dans le même sens pendant six mois. Le cadrage transforme l'intuition en référentiel commun. C'est ce référentiel qui permet au prestataire de chiffrer juste, au sponsor de défendre le budget, à la DSI de valider la stack, et au RSSI de valider la conformité.
Trois différences pratiques entre cadrage structuré et intuition seule. D'abord, le cadrage chiffre les objectifs : pas « beaucoup d'utilisateurs », mais « 200 tenants actifs à 18 mois avec un MRR de 15 000 € ». Ensuite, le cadrage nomme les parties prenantes : pas « le dirigeant validera », mais « le COPIL réunit M. X, Mme Y et Mme Z toutes les 3 semaines ». Enfin, le cadrage arbitre les compromis en amont : pas « on verra », mais « le SSO entreprise est reporté en V2, validé par le sponsor le jj/mm ». C'est cette précision qui fait la différence en production.
Les 6 phases du cadrage SaaS sur-mesure
Ma méthode tient en six phases, à étaler sur 4 à 6 semaines selon la complexité du projet. Chaque phase débouche sur un livrable concret et signé.
| Phase | Durée | Livrable produit | Atelier ou travail individuel |
|---|---|---|---|
| 1. Atelier objectifs business | 2 demi-journées | Note d'OKR adaptée SaaS, chiffrée | Atelier avec sponsor + comité direction |
| 2. Cartographie utilisateurs | 3 à 4 jours | Personas + parcours type + droits d'accès | Travail consultant, validation atelier |
| 3. Arbitrage MVP scope | 1 atelier + révision | Liste MoSCoW (Must, Should, Could, Won't) | Atelier collaboratif sponsor + métier |
| 4. Arbitrages techniques | 2 à 3 jours | Note d\'architecture (multi-tenant, hébergement, RGPD) | Travail consultant + validation DSI/RSSI |
| 5. Plan de sprints | 1 jour | Découpage en sprints d\'une à deux semaines | Travail consultant, validation sponsor |
| 6. Budget et devis | 1 à 2 jours | Devis ferme, planning, conditions contractuelles | Travail consultant + validation payeur |
Le total tient en 15 à 25 jours-homme côté prestataire, plus 3 à 5 demi-journées d'atelier côté client. C'est l'investissement qui transforme un projet en commande exécutable.
Phase 1 : atelier objectifs business avec OKR adaptés SaaS
Le SaaS est un business à mécaniques propres. On ne le cadre pas avec les mêmes indicateurs qu'un site vitrine ou qu'un logiciel installé. La méthode OKR (Objectives and Key Results), popularisée par Google, fournit un cadre adapté qu'on calibre sur les métriques SaaS classiques. Quatre indicateurs structurent le cadrage business d'un SaaS sur-mesure.
- MRR cible (revenu récurrent mensuel) à 6, 12 et 24 mois. C'est le nord de tout SaaS. Sans cible MRR chiffrée, le projet flotte.
- Tenants actifs attendus sur les mêmes horizons. Définition stricte : un tenant qui se connecte au moins une fois par mois et qui paie.
- Taux d\'attrition annuel acceptable. Pour un SaaS B2B sain, le benchmark Bessemer Cloud Index situe l'attrition saine sous les 10 à 15 % par an.
- NPS visé (Net Promoter Score) une fois le produit stabilisé. Un NPS sous 30 signale un produit fragile, au-dessus de 50 il devient un atout commercial.
Le format atelier : deux demi-journées espacées d'une semaine. La première pose les hypothèses, la seconde les valide après confrontation au business plan et au marché. Les chiffres sont arbitrés en cohérence avec le budget envisagé et les ressources commerciales disponibles. À la fin, on a une note OKR de 2 à 3 pages, signée par le sponsor.
Phase 2 : cartographie des utilisateurs et personas
Un SaaS n'est jamais mono-utilisateur. Au minimum, il sert trois populations distinctes : l'administrateur du tenant (qui paie et qui paramètre), l'utilisateur métier (qui utilise au quotidien), et le super-administrateur côté éditeur (qui maintient et qui supporte). Ne pas distinguer ces personas dès le cadrage produit une interface monolithique qu'il faut tout refondre dès le premier client multi-utilisateurs.
Chaque persona se décrit en 4 axes : ses besoins concrets, son parcours type sur le produit, ses contraintes (techniques, métier, réglementaires) et ses droits d'accès. Une demi-page suffit par persona, à condition qu'elle soit précise. La cartographie des utilisateurs s'accompagne d'un parcours type pour chaque persona : « depuis l'écran d'accueil, l'administrateur clique sur X, puis Y, puis Z ». Ce parcours alimente directement les maquettes de basse fidélité du sprint 1.
D'expérience, c'est la phase la plus instructive du cadrage. Beaucoup de porteurs découvrent à ce moment-là qu'ils confondaient « utilisateur » avec « toutes les personnes qui ouvriront l'application ». La cartographie clarifie tout : qui voit quoi, qui peut quoi, qui paie pour quoi.
Phase 3 : arbitrage du périmètre MVP avec la méthode MoSCoW
La méthode MoSCoW (Must, Should, Could, Won't) est l'outil le plus efficace que je connaisse pour arbitrer un périmètre SaaS. On classe chaque fonctionnalité candidate dans une des quatre catégories, et on tient cette discipline jusqu'au lancement.
| Catégorie | Définition | Exemple SaaS B2B |
|---|---|---|
| Must have | Sans cette fonctionnalité, le produit ne peut pas vivre commercialement | Authentification, multi-tenant minimal, parcours métier principal, facturation |
| Should have | Très souhaitable mais le produit peut sortir sans pour une V1 | Tableaux de bord d\'usage, exports CSV, support multi-langues |
| Could have | Améliore l\'expérience, peut être reporté en V2 sans douleur | SSO entreprise, API publique, thèmes personnalisés par tenant |
| Won\'t have | Hors scope pour cette version, à reposer dans 12-18 mois | Application mobile native, intégrations marketplace, IA générative |
La règle d'or : tout ce qui n'est pas Must reste fermé en MVP. Pas de négociation post-cadrage sans révision formelle du périmètre et du devis. Cette discipline est ingrate à tenir, mais c'est la seule qui empêche le projet de glisser. D'expérience sur les projets que j'accompagne, un arbitrage MoSCoW serré au cadrage divise par deux le risque de dépassement budgétaire.
Phase 4 : arbitrages techniques dès le cadrage
Les arbitrages techniques structurent le coût et la durée du projet. Les poser au cadrage évite les surprises en sprint 5. Quatre arbitrages sont systématiques sur un SaaS sur-mesure.
Choix de la stratégie multi-tenant
Trois stratégies possibles : table unique avec tenant_id, schéma par tenant, base par tenant. Chacune a son coût, sa complexité et son niveau d'isolation. Le choix se fait selon la volumétrie cible et la sensibilité des données. Je détaille les arbitrages dans mon article développer un SaaS multi-tenant en PHP. Ce choix est presque impossible à inverser après mise en production, donc il se fait au cadrage, pas en cours de route.
Hébergeur souverain ou hyperscaler
Pour un SaaS B2B français, l'hébergement souverain (Scaleway, OVH, Proxmox auto-hébergé) est la norme. Il garantit la conformité RGPD vis-à-vis du Cloud Act américain et donne un argument commercial direct face aux clients sensibles. Le choix précis dépend du budget, du niveau de support attendu et de la localisation des clients. Mon article comparatif sur les hébergeurs souverains pour SaaS B2B détaille les compromis.
Conformité RGPD : registre et clauses
Le RGPD n'est pas un sujet de fin de projet. La CNIL impose une conformité by design, donc dès le cadrage. À cette étape, on liste les catégories de données traitées, on évalue la sensibilité, on identifie les sous-traitants prévus, et on prépare le registre des traitements. Ces éléments figurent dans la note d'architecture et conditionnent les clauses contractuelles avec les clients finaux.
Stack technique : Symfony LTS par défaut
Sur un SaaS sur-mesure, je travaille par défaut en Symfony en version LTS, MariaDB (ou PostgreSQL selon les contraintes), Doctrine ORM, Twig avec Stimulus et Turbo côté front. Cette stack mainstream garantit un écosystème mature, une maintenance longue durée, et une reprise possible par un autre prestataire si nécessaire. Le porteur peut imposer une stack différente, mais chaque déviation se justifie par une contrainte client documentée.
Phases 5 et 6 : plan de sprints et budget tenable
Les deux dernières phases du cadrage produisent les livrables opérationnels : le plan de sprints et le devis. Ce sont les documents qui structurent l'exécution.
Plan de sprints : découpage en livraisons hebdomadaires
Je découpe les projets SaaS en sprints d'une à deux semaines, avec une démonstration en visio chaque vendredi de fin de sprint. La cadence courte force la priorisation, ferme les ambiguïtés vite, et évite le syndrome du tunnel. Le plan de sprints liste pour chaque sprint : les fonctionnalités livrées, les critères de recette, les dépendances bloquantes, le temps estimé. Il sert de référence à toutes les réunions de COPIL.
Budget et devis : pas de fourchette, un chiffrage tenable
Un devis flou tue la confiance. Sur un projet SaaS sur-mesure, je chiffre ligne à ligne, sprint par sprint, avec une marge d'aléa explicitée et chiffrée. Plutôt qu'une fourchette plaquée à l'aveugle, je construis un devis personnalisé après l'atelier de cadrage, qui détaille chaque ligne et permet au sponsor de défendre le budget devant son COPIL. La maintenance long terme (Composer, npm/yarn, OS) est incluse pendant 5 ans, parce qu'elle conditionne le vrai TCO du SaaS.
Calendrier idéal d'un cadrage en 4 à 6 semaines
Le format compressé 4 semaines convient à un projet bien défini avec un sponsor disponible. Le format 6 semaines est plus réaliste pour la majorité des projets, en particulier quand le périmètre nécessite des allers-retours avec plusieurs parties prenantes.
- Semaine 1 : atelier objectifs business, démarrage cartographie utilisateurs.
- Semaine 2 : finalisation cartographie utilisateurs, atelier MoSCoW.
- Semaine 3 : arbitrages techniques, note d'architecture.
- Semaine 4 : validation DSI/RSSI, plan de sprints.
- Semaine 5 : devis, planning, conditions contractuelles, COPIL de validation.
- Semaine 6 : ajustements finaux, signature du devis, lancement du sprint 1.
Sur les projets que j'accompagne en cadrage, le temps utile côté client tient entre 3 et 5 demi-journées d'atelier, plus quelques heures de validation des livrables intermédiaires. C'est tenable même pour un dirigeant TPE qui porte le projet en plus de son activité courante.
Les livrables produits par le cadrage
Un cadrage rigoureux produit six livrables, tous indispensables à la phase suivante. La note OKR donne les objectifs chiffrés. La cartographie utilisateurs liste les personas, parcours et droits. La liste MoSCoW arbitre le périmètre. La note d'architecture pose les choix techniques structurants. Le plan de sprints séquence l'exécution. Le devis et planning formalisent l'engagement contractuel.
Ces livrables ne sont pas des sous-produits. Ils servent pendant toute la durée du projet, et au-delà. Trois ans plus tard, quand un nouveau collaborateur arrive ou qu'un audit de sécurité est demandé, ils restent la référence partagée. Sur les projets que je maintiens en TMA, je consulte régulièrement les livrables de cadrage initial pour ne pas dériver du sens initial du produit.
Pour la structure détaillée du document final qui consolide ces livrables, voir mon exemple de cahier des charges SaaS sur-mesure avec template.
Cas réel : un cadrage SaaS de 5 semaines pour un éditeur B2B
Sur un projet d'éditeur SaaS de gestion documentaire pour cabinets de conseil, le porteur arrivait avec une idée mature et un budget cadré, mais sans formalisation. Première semaine, atelier objectifs business : nous avons posé un MRR cible de 12 000 € à 18 mois, 80 tenants actifs, attrition annuelle visée sous 10 %. Deuxième semaine, cartographie : trois personas (administrateur de cabinet, consultant, super-admin éditeur), trois parcours types détaillés. Troisième semaine, MoSCoW : 12 fonctionnalités en Must, 8 en Should, 15 en Could, 20 en Won't.
Quatrième semaine, arbitrages techniques : stratégie multi-tenant table unique avec tenant_id, hébergement Scaleway en France, conformité RGPD by design. Cinquième semaine, plan de sprints sur 14 semaines de développement et devis ferme. La mise en production a eu lieu à la 19e semaine cumulée (5 de cadrage + 14 de développement), avec 6 clients pilotes engagés. Trois ans plus tard, le SaaS sert une cinquantaine de cabinets et n'a jamais eu à refondre son architecture initiale.
La leçon : un cadrage de 5 semaines a fait gagner au porteur plusieurs mois de tâtonnements en cours de développement, et a permis à toutes les parties prenantes de défendre un budget cohérent. Ce cas est dans la moyenne de ce que je vois sur les projets bien cadrés.
Les erreurs fréquentes du cadrage SaaS
Erreur 1 : un cadrage bâclé en deux heures
Le piège le plus courant : un atelier de cadrage de deux heures, suivi d'une note de synthèse et d'un devis. Sur un SaaS sur-mesure, c'est insuffisant. Les arbitrages structurants ne se posent pas en deux heures de réunion. Conséquence : le périmètre dérive en cours de projet, le budget glisse, et le porteur perd la main sur sa propre vision. Le cadrage propre prend 4 à 6 semaines, ce n'est pas négociable.
Erreur 2 : viser un périmètre tout-en-un dès le MVP
Beaucoup de porteurs veulent tout, tout de suite : SSO, API publique, application mobile, multi-langues, intégrations CRM. Six mois plus tard, rien n'est en ligne et le budget a triplé. La règle MoSCoW est implacable : sur un MVP SaaS, les Must se comptent en dizaines, pas en centaines. Tout le reste attend une V2 qui sera priorisée selon les retours marché.
Erreur 3 : cadrer sans utilisateurs réels
Cadrer dans le vide produit un cahier des charges qui sonne bien mais qui ne tient pas au contact des premiers clients. La phase 2 (cartographie utilisateurs) doit s'appuyer sur des entretiens avec 5 à 10 utilisateurs cibles réels, pas sur des personas inventés au tableau blanc. Sur les projets que j'accompagne, je refuse de finaliser le cadrage sans ces entretiens.
Erreur 4 : oublier de nommer le payeur
Le sponsor exécutif n'est pas toujours le payeur. Sur un projet d'éditeur SaaS de gestion documentaire que j'ai accompagné, le dirigeant fondateur avait validé un devis ferme en atelier de cadrage. Trois mois plus tard, la DAF a découvert que le projet n'était pas inscrit au budget annuel et a refusé de régler la facture du sprint 4. Le développement s'est arrêté trois semaines. Depuis, j'exige que la section gouvernance du cadrage soit cosignée par le sponsor exécutif et le payeur identifié. Cette simple formalisation neutralise la majorité des incidents de trésorerie en cours de projet.
Démarrer le cadrage de votre projet SaaS sur-mesure
Cadrer un projet SaaS sur-mesure n'est pas une question de méthode magique. C'est une question de discipline et de rigueur. Les six phases que j'ai décrites tiennent en 4 à 6 semaines, produisent six livrables solides, et donnent au projet une base qui tient la durée du développement et au-delà. C'est le meilleur investissement que vous puissiez faire avant d'écrire la première ligne de code.
Si vous portez un projet de SaaS sur-mesure et que vous voulez cadrer proprement avant de lancer le développement, je propose un atelier de cadrage qui débouche sur les six livrables détaillés ci-dessus. Pour la trame du document final qui consolide ces livrables, mon exemple de cahier des charges SaaS sur-mesure fournit un template prêt à remplir. Si votre projet part d'une application existante à moderniser, ma page service sur la refonte SaaS legacy Symfony décrit la méthode progressive Strangler Pattern.
Comme tous mes accompagnements, le périmètre du cadrage est défini sur devis personnalisé après un échange initial gratuit de 30 minutes. Mon guide du développement de logiciel métier sur-mesure détaille les six étapes d'un projet, du cadrage à la maintenance long terme. Le formulaire de contact permet de réserver un créneau.
