Je suis Adrien CHAUMARAT, développeur Symfony depuis 2014. La moitié des appels que je reçois commencent par la même phrase : « J'ai un projet de SaaS, mais je ne sais pas comment formaliser le besoin. » La majorité des porteurs téléchargent un modèle générique de cahier des charges sur internet, le remplissent à 60 %, et s'aperçoivent à la première réponse de prestataire que les questions structurantes d'un SaaS sont absentes : hébergement souverain, RGPD, SLA, multi-tenant, scalabilité. Cet article corrige ce manque. Vous y trouverez la structure type que j'utilise en atelier de cadrage, un exemple anonymisé inspiré d'un éditeur SaaS B2B que j'accompagne, et un template téléchargeable calibré pour un projet SaaS sur-mesure de TPE ou PME.
Pourquoi un cahier des charges SaaS ne ressemble pas à un cahier des charges classique
Un cahier des charges de site vitrine ou de logiciel installé en local tient en quelques pages : périmètre fonctionnel, charte graphique, calendrier, budget cible. Un cahier des charges de SaaS sur-mesure, lui, doit couvrir des dimensions que les modèles génériques ignorent presque toujours : où sont hébergées les données, quelle disponibilité contractuelle, comment isoler les tenants entre eux, comment évoluer de 10 à 10 000 utilisateurs sans réécrire le cœur du produit.
La différence se mesure à la première mise en production. Un cahier des charges bâclé donne un produit qui fonctionne en démo et qui s'effondre dès qu'un client sérieux pose les questions RGPD. La CNIL rappelle dans sa documentation officielle que la conformité doit être pensée by design, donc dès la rédaction du cahier des charges, pas au moment de la mise en ligne. Et pour un SaaS, les enjeux d'RGPD SaaS et conformité conditionnent à la fois le choix d'hébergement, l'architecture multi-tenant et les clauses contractuelles avec vos clients finaux.
D'expérience, un cahier des charges SaaS bien rédigé fait gagner trois à six semaines sur un projet de quatre à six mois. Et il permet au prestataire de chiffrer juste, plutôt que de chiffrer large pour se couvrir.
Objectifs et indicateurs de succès : la section qui change tout
La spécificité la plus négligée d'un cahier des charges SaaS, c'est la dimension objectifs et indicateurs de succès. Un site vitrine se mesure en visites mensuelles ; un SaaS se mesure en revenu récurrent, en rétention et en activation utilisateur. Si votre document n'explicite pas ces métriques, le prestataire conçoit un produit fonctionnel mais aveugle, sans tableau de bord d'exploitation, sans télémétrie pertinente, sans levier pour piloter votre activité.
Concrètement, je recommande d'inscrire dans la section 3 du document au moins quatre indicateurs chiffrés : le MRR cible (revenu récurrent mensuel) à 6, 12 et 24 mois, le nombre de tenants actifs attendu sur ces mêmes horizons, le taux d'attrition annuel acceptable (généralement inférieur à 15 % pour un SaaS B2B sain selon les benchmarks Bessemer Cloud Index) et le NPS visé une fois le produit stabilisé. Ces quatre nombres conditionnent l'architecture : un SaaS visant 50 tenants à 24 mois n'a pas la même infrastructure ni le même modèle multi-tenant qu'un produit ciblant 5 000 comptes. Le devis qui en découle s'en trouve calibré au juste prix, et la recette finale dispose de critères objectifs et non émotionnels.
Parties prenantes et gouvernance projet : qui décide quoi
Un projet de SaaS sur-mesure ne dérape presque jamais sur la technique. Il dérape sur la gouvernance. Le sponsor exécutif n'est pas le payeur, le payeur n'est pas l'utilisateur, et l'utilisateur n'est pas celui qui valide la recette. Si ces rôles ne sont pas posés dans le cahier des charges, vous découvrez en cours de route que la DAF freine sur un budget que le dirigeant a déjà engagé, que la DSI exige une stack qui contredit le devis signé, ou que le RSSI bloque la mise en production pour une clause RGPD non anticipée. C'est la raison pour laquelle j'ai ajouté cette section : poser noir sur blanc la cartographie des décideurs évite la moitié des frictions sur un projet B2B.
Les rôles types d'un projet SaaS B2B
Sur un projet SaaS classique, je rencontre systématiquement huit rôles, parfois cumulés sur une même personne, parfois distribués sur huit interlocuteurs distincts. Le cahier des charges doit les nommer explicitement, avec un référent identifié pour chaque rôle.
| Rôle | Responsabilité | Décision portée |
|---|---|---|
| Sponsor exécutif | Décideur final, porte le budget et l'arbitrage politique | Lance, arrête, réoriente le projet |
| Maîtrise d'ouvrage (MOA) | Exprime le besoin métier, priorise les fonctionnalités | Valide les spécifications fonctionnelles |
| Maîtrise d'œuvre (MOE) | Le prestataire que vous avez retenu (ARDNTECH ou autre) | Conçoit, développe, livre la solution |
| Comité de pilotage (COPIL) | Arbitre les décisions structurantes, suit l'avancement | Tranche les compromis périmètre/coût/délai |
| Référent métier | Connaît le terrain, valide les fonctionnalités au fil de l'eau | Recette fonctionnelle de chaque lot livré |
| Référent technique (DSI) | Valide la stack, les intégrations, l'infrastructure cible | Architecture, hébergement, sécurité réseau |
| Payeur (DAF, comptabilité) | Émet les bons de commande, paie les factures | Trésorerie, échéancier, conditions de règlement |
| RSSI ou référent conformité | Vérifie RGPD, sécurité, audits, registre des traitements | Autorise ou non la mise en production |
Adaptation selon la taille de votre organisation
Ces huit rôles existent toujours, mais leur distribution change radicalement selon la taille de la structure. Sur une TPE, le dirigeant cumule souvent quatre à cinq rôles à lui seul : sponsor, MOA, payeur, référent métier et parfois même RSSI. C'est efficace mais risqué, parce que la fatigue décisionnelle finit par produire des arbitrages incohérents. Sur une PME de 20 à 100 personnes, on retrouve typiquement trois interlocuteurs côté client : le dirigeant sponsor, un référent métier (responsable opérationnel) et la DAF qui contrôle la trésorerie. Sur une ETI ou un groupe, chaque rôle a une personne dédiée, parfois redondée, et la gouvernance devient un sujet à part entière qui peut allonger les délais de décision de plusieurs semaines.
Le cahier des charges doit nommer le titulaire de chaque rôle, son temps disponible hebdomadaire pour le projet, et son délai de réponse engagé. Sans ces informations, le prestataire chiffre à l'aveugle et la phase de spécification s'enlise.
Cadence de gouvernance recommandée
Une gouvernance lisible repose sur trois instances complémentaires. Le COPIL se réunit toutes les deux à quatre semaines selon la phase du projet (bimensuel en phase de cadrage et de mise en production, mensuel en croisière), pour arbitrer les écarts de périmètre, de coût et de délai. Le point hebdomadaire MOA/MOE dure 30 à 45 minutes et traite l'opérationnel courant : avancement du sprint, blocages, priorisation du backlog. Enfin, une matrice RACI (responsible, accountable, consulted, informed) formalisée pour chaque décision critique évite les conflits d'autorité, en particulier sur les arbitrages sécurité, RGPD et financiers.
Cas vécu : sponsor et payeur désalignés, projet à l'arrêt
Sur un projet d'éditeur SaaS de gestion documentaire pour cabinets de conseil, le dirigeant fondateur portait le sponsor exécutif et avait validé un devis ferme en atelier de cadrage. Trois mois plus tard, la DAF a découvert que le projet n'avait pas été inscrit au budget annuel, et a refusé de régler la facture du sprint 4. Le développement s'est arrêté trois semaines, le temps de remonter en COPIL et d'obtenir une rallonge budgétaire. Le cahier des charges initial ne nommait pas la DAF, ne décrivait pas le circuit de bon de commande, et n'imposait pas la signature conjointe sponsor plus payeur en amont. Depuis, j'exige systématiquement que la section gouvernance du cahier des charges soit cosignée par le sponsor exécutif et le payeur identifié. Cette simple formalisation neutralise 90 % des incidents de trésorerie en cours de projet, et elle s'inscrit naturellement dans le cadrage MVP SaaS en 6 à 8 semaines que je propose en amont du développement.
Les 13 sections incontournables d'un cahier des charges SaaS
Voici la structure que j'utilise systématiquement en atelier de cadrage, et que reprend mon template ARDNTECH. Chaque section répond à une question précise du prestataire, et chaque question évite un malentendu à la livraison. Les sept premières sections cadrent le projet, sa gouvernance et son contexte ; les six dernières définissent le produit, son architecture et son exploitation, là où un modèle générique de cahier des charges échoue presque toujours.
| # | Section | Ce qu'elle décrit | Question à laquelle elle répond |
|---|---|---|---|
| 1 | Contexte et présentation entreprise | Métier, marché, équipe, historique du projet | Qui porte le projet et dans quel écosystème |
| 2 | Parties prenantes et gouvernance projet | Sponsor, COPIL, MOA/MOE, référents métier et technique, payeur, RSSI | Qui décide, qui valide, qui paie, qui opère |
| 3 | Objectifs et indicateurs de succès (KPI) | MRR cible, tenants actifs, attrition, NPS, jalons business | Comment on mesurera la réussite du SaaS |
| 4 | Personas et cible utilisateurs | Profils types, parcours, contraintes, droits d'accès | Pour qui le SaaS est conçu et comment chacun l'utilise |
| 5 | Expression du besoin (cas d'usage) | Parcours principaux, fonctionnalités prioritaires vs secondaires | Ce que le logiciel doit permettre de faire concrètement |
| 6 | Spécifications fonctionnelles détaillées | Modules, règles de gestion, écrans, workflows | Comment chaque fonctionnalité se comporte en détail |
| 7 | Contraintes techniques | Stack imposée ou suggérée, intégrations tierces, performance | Sur quoi le prestataire doit construire |
| 8 | Architecture et infrastructure | Multi-tenant, scalabilité, déploiement, environnements | Comment le produit est structuré et opéré |
| 9 | Sécurité, RGPD, conformité | Authentification, journalisation, durée de conservation, sous-traitants | Comment le SaaS protège les données et reste conforme |
| 10 | SLA, disponibilité, supervision | Taux de disponibilité, fenêtres de maintenance, délais d'intervention | Quel niveau d'engagement contractuel le prestataire prend |
| 11 | Maintenance, évolutions, pérennité | TMA, mises à jour de sécurité, réversibilité, transmission | Comment le SaaS vit après la mise en production |
| 12 | Planning, jalons, modalités de recette | Découpage en sprints, critères de validation, calendrier | Quand et comment chaque livrable est validé |
| 13 | Aspects contractuels | Propriété du code, garanties, réversibilité, portabilité des données | Qui détient quoi et comment on se sépare proprement |
Sur la section 5, l'expression du besoin SaaS, le réflexe est de lister des fonctionnalités. C'est insuffisant : il faut décrire des cas d'usage, en partant de l'utilisateur final. Par exemple, plutôt que « le SaaS doit permettre la facturation », écrivez « un comptable doit pouvoir générer une facture récurrente mensuelle, l'envoyer par email avec rappel automatique à J+7 et J+15, et exporter le journal en SEPA ». Cette granularité change le devis et la qualité du produit livré.
Pour la section 7 sur les contraintes techniques, je détaille les compromis d'architecture multi-tenant SaaS dans un autre article : c'est l'une des questions à arbitrer dès le cahier des charges, pas en cours de développement.
Les pièges qu'on évite avec un cahier des charges bien rédigé
Piège 1 : confondre cahier des charges et liste de fonctionnalités
Un cahier des charges qui se limite à une liste de fonctionnalités est inexploitable. Le prestataire ne sait pas pourquoi chaque fonctionnalité existe, donc il ne peut pas arbitrer entre deux implémentations possibles. Il chiffre au plus large, par sécurité. Conséquence : devis gonflés, parfois du simple au triple entre prestataires, et choix biaisé vers le moins-disant qui s'est trompé sur le périmètre.
Piège 2 : oublier les profils utilisateurs et les droits
Sur un SaaS B2B, il y a presque toujours trois profils minimum : administrateur de tenant, utilisateur métier, super-administrateur côté éditeur. Si le cahier des charges ne mentionne qu'un seul profil, le prestataire livre un produit mono-rôle qu'il faut entièrement refondre dès le premier client multi-utilisateurs. C'est une dette technique évitable à la rédaction.
Piège 3 : ne pas préciser le périmètre de la recette
Sans critères de recette explicites, la mise en production glisse de semaines. « Le bouton ne fait pas exactement ce que j'avais en tête » devient un débat sans fin. Mon parti-pris : chaque cas d'usage du cahier des charges devient un scénario de recette, avec une formulation type donné/quand/alors. Le prestataire sait ce qu'il doit livrer, le client sait ce qu'il doit valider.
Piège 4 : copier-coller un modèle générique sans spécificités SaaS
La plupart des modèles disponibles en ligne sont calqués sur des projets informatiques classiques des années 2010 : cahier des charges « logiciel », pas « SaaS ». Ils omettent l'hébergement, le multi-tenant, la facturation par abonnement, la conformité RGPD côté processeur, les SLA contractuels. Un prestataire SaaS sérieux vous repérera immédiatement comme un porteur sous-équipé, et adaptera son devis à la prudence.
Personas et cible utilisateurs : la section que tout le monde bâcle
Un SaaS n'est jamais un produit mono-utilisateur. Contrairement à un logiciel installé sur un poste de travail, un SaaS B2B sert au minimum deux populations distinctes : les clients finaux qui paient l'abonnement et leurs propres utilisateurs internes. Penser personas dès le cahier des charges, c'est imposer au prestataire de concevoir des écrans, des droits et des parcours différenciés, plutôt qu'une interface monolithique réservée à un seul profil.
Les trois personas types d'un SaaS B2B
Sur la quasi-totalité de mes projets SaaS B2B, je rencontre les mêmes trois personas structurants :
- L'administrateur de tenant : signataire du contrat, il gère les utilisateurs internes, paramètre les options, consulte les rapports d'usage, paie la facture. Il a besoin d'écrans de gestion riches et de tableaux de bord agrégés.
- L'utilisateur métier : il utilise le SaaS au quotidien dans son travail. Son besoin numéro un : un parcours rapide, fluide, sans paramétrage. Il accède à un sous-ensemble fonctionnel défini par l'administrateur.
- Le super-administrateur côté éditeur : c'est vous, ou votre équipe support. Il accède à tous les tenants pour de la maintenance, du support, de la facturation, de la modération. Cet espace est souvent oublié des cahiers des charges, ce qui force ensuite à le rajouter en urgence.
Comment décrire un persona dans le cahier des charges
Chaque persona doit être décrit selon quatre axes : ses besoins concrets, son parcours type sur le produit, ses contraintes (techniques, métier, réglementaires) et ses droits d'accès. Quelques lignes suffisent par persona, mais elles évitent que le prestataire confonde « utilisateur » avec « toutes les personnes qui ouvriront l'application ». Pour creuser la dimension produit, le cadrage MVP en 6 à 8 semaines détaille comment cartographier les personas avant le développement.
Cas vécu : des personas bâclés, une refonte à six mois
Sur un projet de SaaS d'aide à la décision pour cabinets de courtage en assurance, le cahier des charges initial évoquait « les courtiers » comme un bloc homogène. Au bout de quatre mois de développement, le premier client a rappelé que ses assistantes commerciales saisissaient les dossiers, tandis que les courtiers seniors les validaient et que la direction consultait des tableaux de bord. Trois personas, trois écrans, trois lots de droits : tout manquait. Résultat, six semaines de refonte non prévues, prises sur le budget de la phase 2. Un atelier persona d'une demi-journée en amont aurait évité ce dérapage.
Les spécificités SaaS que les templates génériques oublient
Voici les cinq points qui doivent figurer dans tout cahier des charges de SaaS sur-mesure, et qui sont absents de 90 % des modèles génériques que je vois passer.
| Point | Ce qu'il faut préciser | Pourquoi c'est structurant |
|---|---|---|
| Hébergement | Localisation géographique exigée (France, UE), prestataire souhaité ou interdit, contraintes de souveraineté | Conditionne le choix infra, le coût mensuel et la conformité RGPD vis-à-vis du Cloud Act américain |
| RGPD et conformité | Catégories de données traitées, durée de conservation, sous-traitants prévus, registre des traitements | La CNIL impose une conformité dès la conception, donc dès le cahier des charges |
| SLA et disponibilité | Taux de disponibilité cible, fenêtres de maintenance, délai d'intervention, escalade incident | Détermine l'architecture (redondance, monitoring), le coût d'exploitation et les clauses commerciales avec vos clients |
| Architecture multi-tenant | Modèle d'isolation souhaité, volumétrie cible par tenant, contraintes d'export et de portabilité | Choix structurant et coûteux à inverser après mise en production |
| Scalabilité | Volumétrie attendue à 6 mois, 2 ans, 5 ans ; pics d'usage prévus ; intégrations API tierces | Évite les architectures sous-dimensionnées ou sur-dimensionnées, oriente le choix de la stack |
Côté stack, le cahier des charges peut rester ouvert ou imposer des choix. Pour ma part, je travaille par défaut en Symfony en version LTS, MariaDB (ou PostgreSQL selon les contraintes), hébergement souverain Scaleway, OVH, Infomaniak ou Proxmox auto-hébergé. Un porteur de projet peut imposer cette stack, ou laisser le prestataire la proposer en justifiant. Les deux approches sont valides, l'essentiel est d'en parler explicitement.
Scalabilité : adapter l'architecture à la volumétrie réelle
La scalabilité est le sujet où je vois le plus d'erreurs de cadrage. Deux travers reviennent en boucle : sous-dimensionner pour économiser à court terme, ou sur-dimensionner par mimétisme des géants du cloud. Pour une TPE ou PME qui démarre, le piège du « tout serverless » coûte cher : facturation imprévisible, dépendance à un fournisseur unique, complexité d'observabilité disproportionnée par rapport aux 50 ou 100 tenants visés à deux ans. À l'inverse, partir sur une orchestration Kubernetes multi-cluster avant le premier client payant fait fondre le budget sans servir personne.
Mon parti-pris pragmatique : un couple Symfony en version LTS plus MariaDB sur un VPS souverain bien dimensionné absorbe sans difficulté plusieurs centaines de tenants actifs et plusieurs millions de requêtes mensuelles, avec un coût opérationnel maîtrisé et une maintenabilité réelle. La politique LTS publique de Symfony garantit trois ans de support sécurité par version, donc une stabilité long terme rare dans l'écosystème JavaScript. Le cahier des charges doit poser la volumétrie cible à 6, 24 et 60 mois, puis laisser le prestataire arbitrer l'architecture en conséquence. Pour aller plus loin, voir le guide du développement SaaS sur-mesure qui détaille mes choix d'infrastructure.
Maintenance, évolutions et pérennité : ce que personne ne formalise
Un SaaS n'est pas un livrable, c'est un service qui vit dans la durée. Pourtant, la plupart des cahiers des charges s'arrêtent à la recette de la version 1, comme si l'after-launch n'existait pas. C'est l'origine de la majorité des litiges que je vois entre éditeurs et prestataires : ce qui n'est pas formalisé devient négociable, et la négociation se fait toujours en défaveur du client une fois l'application en production.
TMA et plan de mises à jour de sécurité
La tierce maintenance applicative (TMA) recouvre trois volets distincts : la maintenance corrective (les bugs apparus en production), la maintenance évolutive (les nouvelles fonctionnalités), et la maintenance de sécurité (les mises à jour Composer, npm, OS). Le cahier des charges doit imposer un engagement chiffré sur ces trois volets : volume mensuel de jours-homme alloués, délai de prise en charge d'un correctif critique, fréquence des cycles de mise à jour de dépendances. Sans cet engagement, votre prestataire considérera ces tâches comme optionnelles, et vous découvrirez une vulnérabilité CVE non patchée au pire moment.
Réversibilité : export complet et accès au code source
La réversibilité est un droit que la CNIL rappelle dans son guide sur la portabilité, mais surtout c'est une assurance contre la dépendance à votre prestataire. Le cahier des charges doit exiger : un export complet des données dans un format documenté et réutilisable (SQL, CSV ou JSON selon les cas), un accès permanent au code source du SaaS sur un dépôt Git que vous contrôlez, et un inventaire à jour des dépendances et des comptes d'infrastructure. La règle que j'applique sur mes projets : tout le code écrit pour un client lui appartient et il y accède en lecture dès le premier commit.
Plan de transmission en cas de fin de contrat
Aucune relation prestataire ne dure éternellement. Le cahier des charges doit prévoir comment se déroule la séparation : durée de la phase de transmission (en général deux à trois mois), prestations incluses (documentation à jour, transfert vers le prestataire successeur, formation interne d'une équipe), et le cas extrême de l'escrow de code source confié à un tiers de confiance en cas de défaillance du prestataire. C'est aussi le moment d'évoquer la reprise de maintenance d'un SaaS existant : un cahier des charges qui anticipe la transmission rend la reprise par un nouveau prestataire en quelques semaines plutôt qu'en plusieurs mois.
Template gratuit : cahier des charges SaaS sur-mesure
Pour accélérer votre rédaction, j'ai préparé un template Word calibré pour un projet de SaaS sur-mesure de TPE ou PME. Il reprend les 13 sections, propose des questions guidées et des exemples de formulation pour chaque cas d'usage. Le format Word vous permet de remplir directement les sections et de l'adapter à votre charte interne. Télécharger le template gratuit (DOCX).
Cas concret : extrait anonymisé d'un cahier des charges SaaS B2B
Pour illustrer, voici un extrait anonymisé d'un cahier des charges que j'ai aidé à rédiger pour un éditeur SaaS B2B du secteur télécom. Le porteur partait d'un modèle générique inadapté, nous avons retravaillé la structure en deux ateliers de cadrage.
Extrait section 1 : contexte et objectifs
« L'éditeur commercialise un outil de réconciliation de factures télécom auprès de DAF de PME. Le marché cible représente environ 12 000 sociétés en France. L'objectif à 12 mois est d'atteindre 80 clients payants, avec un panier moyen mensuel cible et un taux d'attrition annuel inférieur à 15 %. Les indicateurs de succès sont le nombre de tenants actifs, le revenu récurrent mensuel et la durée moyenne d'analyse d'une facture (objectif : moins de 30 secondes contre 45 minutes en manuel). »
Extrait section 4 : contraintes techniques
« Le SaaS doit être hébergé exclusivement en France ou dans l'Union européenne, sur un prestataire non soumis au Cloud Act. L'architecture multi-tenant retenue est l'isolation logique par tenant_id sur base partagée, avec audit log par tenant. La volumétrie cible à 24 mois est de 200 tenants, jusqu'à 5 000 factures traitées par tenant et par mois, avec un pic en début de trimestre. L'authentification doit supporter SSO SAML pour les tenants supérieurs à 20 utilisateurs. »
Extrait section 6 : SLA et recette
« Taux de disponibilité cible : 99,5 % calculé mensuellement hors fenêtres de maintenance planifiées. Fenêtre de maintenance : dimanche 02h-06h CET, préavis 72h. Délai d'intervention sur incident bloquant : 4 heures ouvrées. Sauvegardes quotidiennes chiffrées, conservées 30 jours, restauration testée trimestriellement. Recette par lots de cas d'usage, formulation donné/quand/alors, recette finale conditionnée à la validation des 5 parcours utilisateurs critiques. »
Ces trois extraits, ramassés sur une page, suffisent à un prestataire sérieux pour produire un devis ferme et défendable. Sur ce projet, deux des trois prestataires consultés ont chiffré à moins de 10 % d'écart, signe que le cahier des charges était lisible et précis. Pour aller plus loin sur le choix sur-mesure vs solutions existantes, voir pourquoi développer un SaaS sur-mesure plutôt qu'utiliser une solution existante.
Aspects contractuels et propriété intellectuelle
La dernière section du cahier des charges traite du cadre contractuel. Elle est trop souvent renvoyée au contrat de prestation, alors qu'elle gagne à être posée dès l'amont : un prestataire qui refuse de s'engager sur ces clauses se révèle avant la signature, pas après six mois de développement.
Propriété du code source
La règle saine pour un SaaS sur-mesure : le code source livré appartient au client commanditaire dès la rédaction. Les bibliothèques open source intégrées conservent leur licence d'origine, et le prestataire peut conserver des composants génériques qu'il réutilise sur plusieurs projets (utilitaires internes par exemple), à condition qu'ils soient clairement identifiés. Tout le code spécifique au métier du client lui revient. Ce point doit être écrit noir sur blanc dans le cahier des charges, puis repris à l'identique dans le contrat.
Garanties contractuelles : SLA, support, délais
Trois engagements minimum à formaliser : le taux de disponibilité mensuel garanti (99,5 % couvre la plupart des SaaS B2B, 99,9 % devient pertinent au-delà de 500 tenants critiques), les délais d'intervention en cas d'incident classifiés par niveau de gravité (bloquant, majeur, mineur), et les pénalités contractuelles en cas de non-respect. Sans ces garanties chiffrées, le SLA reste un argument commercial sans portée juridique.
Réversibilité et portabilité des données (RGPD article 20)
La portabilité des données est un droit consacré par l'article 20 du RGPD : tout client doit pouvoir récupérer ses données dans un format structuré et lisible par machine, et les transférer à un autre prestataire sans entrave. Pour les détails et la jurisprudence, consultez la CNIL article 20 sur la portabilité. Au-delà du droit, c'est un signal de sérieux : un prestataire qui livre une fonctionnalité d'export complet, documentée et testée régulièrement, montre qu'il ne cherche pas à enfermer son client.
Anti-éviction du marché : continuité en cas de défaillance prestataire
Le scénario rare mais redoutable, c'est la disparition du prestataire : liquidation, accident, départ à la retraite sans repreneur. Le cahier des charges peut imposer une clause d'escrow, où le code source et la documentation à jour sont déposés chez un tiers de confiance, accessibles au client en cas de défaillance avérée. Plus simplement, exiger un dépôt Git client-side, accessible en lecture en permanence par le commanditaire, couvre 90 % des cas. La continuité de service ne s'improvise pas, elle se contractualise.
De la rédaction du cahier des charges au cadrage technique
Un cahier des charges, aussi bien rédigé soit-il, reste un document. La vraie valeur naît au moment du cadrage technique avec le prestataire : confronter les hypothèses, ajuster le périmètre, arbitrer les compromis. Sur mes projets, je propose un atelier de cadrage de deux à trois jours qui débouche sur un découpage en sprints, une stack arbitrée et un calendrier réaliste. C'est l'étape qui transforme un cahier des charges SaaS en projet exécutable. Pour une approche détaillée du format court, voir mon retour d'expérience sur le cadrage de MVP SaaS en 6 à 8 semaines.
Téléchargez le template ARDNTECH et passons à l'étape suivante
Le template cahier des charges SaaS sur-mesure (DOCX) est utilisable tel quel pour préparer votre consultation. Une fois rempli, je peux le relire avec vous lors d'un échange initial gratuit de 30 minutes, identifier les zones grises et chiffrer un atelier de cadrage. Comme tous mes accompagnements, le périmètre est défini sur devis personnalisé. Mon guide du développement SaaS sur-mesure détaille les six étapes d'un projet, du cadrage à la maintenance long terme, et le formulaire de contact permet de réserver un créneau.
