Cahier des charges SaaS : faire chiffrer le même produit

Un cahier des charges SaaS utile ne commence ni par une architecture, ni par une liste d’écrans. Il fixe le produit que l’entreprise achète : qui crée l’organisation cliente, qui peut agir, quel parcours justifie l’abonnement, quels droits naissent de l’offre et ce qui se passe en cas d’échec. Il précise aussi comment les données sont récupérées à la sortie. Pour chaque règle, il nomme un responsable, une preuve de réception et une exclusion.

Le document est comparable lorsque chaque candidat peut reprendre les mêmes situations initiales, produire les mêmes résultats attendus et déclarer séparément ses hypothèses. Une inconnue structurante reste écrite STOP ou À décider. Un prix ou une fonction bien détaillée ailleurs ne la compense pas.

Écrivez d’abord une histoire courte : une organisation cliente part d’un état initial, une personne autorisée accomplit le premier parcours et obtient le résultat vendu. Nommez le déclencheur, les données nécessaires, le début, la fin et les cas où ce résultat ne doit pas être promis. Cette histoire devient le fil rouge des rôles, de l’abonnement, de l’exploitation et de la recette.

Les neuf réponses minimales avant une consultation

1. Quelle entreprise achète et qui peut engager la décision ?
2. Qui utilise le produit et dans quelle organisation cliente ?
3. Quel événement déclenche le premier parcours ?
4. Quel résultat observable met fin à ce parcours ?
5. Quelles données entrent, changent et sortent ?
6. Quels rôles peuvent agir, sur quels objets et dans quelle portée ?
7. Quel droit d’usage l’offre ouvre-t-elle ou retire-t-elle ?
8. Que voit le client lorsque le parcours ou l’abonnement échoue ?
9. Quelle preuve permettra d’accepter ou de refuser la livraison ?

Si une réponse manque, indiquez l’inconnue, son responsable et la date ou la condition de décision. Ne laissez pas « à voir avec le prestataire » sans effet explicite : selon le sujet, cela peut changer le produit, la charge d’exploitation, le contrat et le prix.

Le développement se compare d’abord à l’option la plus simple

Avant de consulter des développeurs, rejouez le même résultat avec une fonction déjà payée, une configuration légère, un processus manuel maîtrisé et l’option de ne pas développer. Comparez les mêmes préconditions, données, refus, preuves et responsabilités. Si une option plus simple couvre le résultat sans déplacer un risque inacceptable, gardez-la : un cahier des charges n’est pas une raison de commander du code.

Un SaaS B2B ne gère pas seulement des comptes individuels. Il doit savoir à quelle entreprise appartiennent les utilisateurs, les données, les droits d’usage et la facturation. Le cahier des charges doit donc décrire la création de l’organisation, son premier propriétaire, ses administrateurs, le transfert de responsabilité, la suspension, la fermeture et la séparation avec les autres organisations.

Chaque changement d’état mérite sa propre règle

Utilisez au moins deux organisations fictives dans les cas de réception. Un test qui montre seulement qu’une personne autorisée voit ses données ne prouve pas que la même requête est refusée dans l’organisation voisine. Cette séparation est une règle produit ; la manière technique de l’obtenir reste à expliquer par le prestataire.

Le cycle de l’organisation fixe le périmètre. Les rôles peuvent alors être testés sur des actions permises et des refus attendus.

« Gestion des rôles » est une fonction, pas une exigence vérifiable. Décrivez qui peut lire, créer, modifier, valider, exporter ou supprimer quel objet et dans quel périmètre — organisation, dossier ou donnée concernée. Ajoutez un cas autorisé, un cas refusé et le comportement attendu après retrait du droit.

Le guide sécurité de la CNIL relie les habilitations aux besoins d’accès, à leur validation et à la suppression des permissions devenues inutiles. Le référentiel OWASP ASVS 5.0.0 permet de versionner les contrôles retenus :

• v5.0.0-8.1.1 pour documenter les règles fonctionnelles ;
• v5.0.0-8.2.2 pour les restrictions sur les données ;
• v5.0.0-8.3.1 pour les vérifications côté service ;
• v5.0.0-8.3.2 pour l’effet immédiat d’un changement d’autorisation ou ses mesures compensatoires ;
• v5.0.0-8.4.1 pour les opérations entre organisations ;
• v5.0.0-7.4.2 pour terminer les sessions d’un compte désactivé ou supprimé.

Cette sélection ne vaut ni audit exhaustif, ni certification.

Si votre matrice devient volumineuse, conservez ici les règles critiques et renvoyez vers une annexe versionnée. Le guide sur les droits d’accès d’une application métier aide à construire cette matrice sans score compensatoire.

Une fois les droits décrits, chaque offre doit préciser ceux qu’elle ouvre, modifie ou retire.

Une offre commerciale ne doit pas rester un nom affiché sur une page de prix. Écrivez la table qui relie chaque offre aux droits d’usage : fonctions ouvertes, limites, rôles autorisés, consommation éventuelle et comportement lors d’un changement. Puis décrivez les états internes de l’abonnement et leur effet sur ces droits.

La table de décision à demander

La documentation officielle de Stripe illustre pourquoi un abonnement ne se réduit pas à « payé » ou « impayé » : des événements peuvent être traités plus tard et plusieurs états doivent être coordonnés avec l’accès au service. Cette documentation reste un exemple de fournisseur. Le cahier des charges ne choisit pas Stripe, ne copie pas ses statuts comme modèle universel et ne lui délègue pas la décision produit.

Les événements imparfaits font partie du test

• le même événement est reçu plusieurs fois ;
• deux événements arrivent dans un ordre différent ;
• une confirmation manque ou arrive après une action du client ;
• une correction manuelle remet l’état en cohérence ;
• un changement d’offre ne supprime pas silencieusement les données ;
• une résiliation déclenche le parcours de sortie décidé.

Un parcours nominal ne suffit pas à exploiter un SaaS. Pour chaque étape critique, demandez ce que voit le client, ce qui est conservé, qui reçoit l’alerte, qui peut corriger l’état, quelle action permet de reprendre et quelle trace restera. Une « gestion des erreurs » sans scénario ni responsable n’est pas réceptionnable.

Pour chaque échec, nommez qui le détecte, qui choisit le mode dégradé, qui peut remettre l’état en cohérence ou revenir en arrière et qui vérifie le résultat. Une dépendance indisponible ne doit ni ouvrir un droit par défaut, ni supprimer des données, ni laisser une correction sans auteur.

Pour des données personnelles, le guide sécurité de la CNIL recommande notamment de borner les accès de maintenance : intervention demandée, accès limité, traçabilité et fermeture. Écrivez cette exigence dans le contexte réel du produit. Ne déduisez pas d’un écran de journalisation une conformité générale au RGPD.

L’inventaire de données doit servir une décision

Pour chaque catégorie, notez la finalité produit, l’organisation à laquelle elle appartient, les rôles qui y accèdent, sa provenance, ses sorties, la règle de conservation à valider et le responsable. Gardez distincts les fichiers clients, les métadonnées, les journaux, les données de facturation et les données de support. Une durée inconnue reste « à décider » ; aucun chiffre ne doit la remplacer.

Lorsqu’un incident rend le service ou ses données indisponibles, le dossier précise ce qui sera restauré et comment le client pourra sortir.

« Sauvegardes incluses » ne précise ni ce qui est sauvegardé, ni ce qui peut être perdu, ni comment la restauration est vérifiée. Décrivez les données et configurations concernées, l’environnement de restauration, le contrôle d’intégrité, la personne qui observe le résultat et la décision prise en cas d’échec. Les objectifs chiffrés de perte et de reprise restent à décider selon les risques ; aucun seuil universel n’est fourni ici.

Le chapitre VI du règlement européen 2023/2854 encadre le changement de fournisseur pour les services qui entrent dans la définition des services de traitement de données. Ses articles 23 à 25 et ses définitions déterminent le champ, les données exportables et les actifs numériques concernés, avec des limites.

Il serait donc inexact d’écrire que tout abonnement appelé SaaS donne automatiquement le même droit d’export. Décrivez malgré tout la sortie nécessaire au client dans le produit et le contrat, puis faites qualifier l’application du Data Act au service concerné.

Ne mélangez pas trois objets : l’export des données de l’organisation cliente, la remise des livrables du projet et les droits d’exploitation sur le code. Si une cession de droits est négociée sous droit français, l’article L131-3 du Code de la propriété intellectuelle exige de distinguer les droits cédés et de délimiter leur exploitation. Le contrat applicable doit être relu au cas par cas.

Sauvegarde, restauration et sortie ne deviennent comparables que si leurs conditions de contrôle sont écrites. La même règle s’applique maintenant aux exigences non fonctionnelles.

Une exigence non fonctionnelle devient comparable lorsqu’elle indique le parcours concerné, les conditions, l’environnement, le seuil décidé, la méthode, la preuve et le propriétaire. Si le seuil manque, marquez-le « à décider » et demandez aux répondants d’expliquer l’effet de leurs hypothèses. N’utilisez pas une note globale : une bonne performance ne compense pas un défaut d’autorisation ou une restauration impossible.

Pour un parcours Web, le standard WCAG 2.2 fournit des critères directement transformables en cas de réception :

• 2.1.1 pour l’usage au clavier ;
• 2.4.7 pour le focus visible ;
• 3.3.1 pour l’identification textuelle des erreurs ;
• 3.3.2 pour les labels ou instructions ;
• 4.1.3 pour les messages de statut perceptibles.

Citer ces numéros ne prouve pas la conformité : le périmètre, les tests et les éventuels écarts doivent être examinés.

La réception se prépare avant le développement

• un identifiant stable relie chaque exigence à ses cas ;
• les données de test sont fictives, préparées et reproductibles ;
• les résultats attendus incluent les refus et les erreurs ;
• la preuve précise son auteur, sa date, son environnement et sa version ;
• les écarts restent visibles jusqu’au nouveau test après correction ou à une décision explicite ;
• la personne habilitée prononce l’acceptation, le refus ou les réserves.

Une fois chaque responsable et chaque preuve nommés, la trame de consultation peut être remplie sans inventer les choix manquants.

L’outil ci-dessous fonctionne dans votre navigateur. Il ne fait aucun appel réseau et n’enregistre pas vos réponses. Utilisez uniquement des formulations génériques : ne saisissez pas de données personnelles, de secrets, de conditions commerciales sensibles ou d’informations de sécurité. La sortie reste lisible, sélectionnable et copiable en Markdown ; aucun fichier XLS, XLSX ou CSV n’est proposé.

Le moteur présente 45 zones de texte : cinq champs séparés dans chacun des neuf blocs. Une décision vide ou marquée STOP, TBD, inconnue, à confirmer ou à décider bloque le document. Un responsable, une preuve ou une exclusion manquante exige une clarification.

Pour l’inconnue bloquante, un champ vide force un STOP. La déclaration explicite « Aucune identifiée » signifie qu’aucun blocage n’est déclaré ; toute autre formulation décrit un blocage et force elle aussi un STOP.

Aucun score ne compense ces défauts. L’outil ne vérifie pas la vérité de ce que vous écrivez.

# Cahier des charges SaaS — STOP — nom du produit à décider

> État : STOP — décision ou inconnue bloquante à traiter
> Document de travail généré localement. Il ne choisit ni architecture, ni prestataire de paiement, ni prix, ni délai, ni niveau de service contractuel (SLA), et ne vaut pas validation juridique, sécurité ou conformité.

## Règle de lecture

Chaque bloc distingue une décision, son responsable, la preuve attendue, ce qui est exclu et la déclaration d’une inconnue bloquante. Une déclaration vide ou différente de « Aucune identifiée » force un STOP. Une ligne STOP n’est compensée par aucun autre bloc.

## Inconnues bloquantes

- STOP — Identité du produit · Nom de travail
- STOP — Produit vendu et premier parcours · Décision
- STOP — Produit vendu et premier parcours · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Cycle de vie de l’organisation cliente · Décision
- STOP — Cycle de vie de l’organisation cliente · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Invitations, rôles, portées et révocation · Décision
- STOP — Invitations, rôles, portées et révocation · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Offres et droits d’usage · Décision
- STOP — Offres et droits d’usage · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Cycle de l’abonnement · Décision
- STOP — Cycle de l’abonnement · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Échecs, correction et exploitation · Décision
- STOP — Échecs, correction et exploitation · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Données, conservation et accès support · Décision
- STOP — Données, conservation et accès support · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Sauvegarde, restauration, résiliation et sortie · Décision
- STOP — Sauvegarde, restauration, résiliation et sortie · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP
- STOP — Exigences non fonctionnelles et réception · Décision
- STOP — Exigences non fonctionnelles et réception · Inconnue bloquante — Déclaration absente : écrivez « Aucune identifiée » ou décrivez le STOP

## Points à compléter

- À décider — Produit vendu et premier parcours · Responsable
- À décider — Produit vendu et premier parcours · Preuve de réception
- À décider — Produit vendu et premier parcours · Exclusion
- À décider — Cycle de vie de l’organisation cliente · Responsable
- À décider — Cycle de vie de l’organisation cliente · Preuve de réception
- À décider — Cycle de vie de l’organisation cliente · Exclusion
- À décider — Invitations, rôles, portées et révocation · Responsable
- À décider — Invitations, rôles, portées et révocation · Preuve de réception
- À décider — Invitations, rôles, portées et révocation · Exclusion
- À décider — Offres et droits d’usage · Responsable
- À décider — Offres et droits d’usage · Preuve de réception
- À décider — Offres et droits d’usage · Exclusion
- À décider — Cycle de l’abonnement · Responsable
- À décider — Cycle de l’abonnement · Preuve de réception
- À décider — Cycle de l’abonnement · Exclusion
- À décider — Échecs, correction et exploitation · Responsable
- À décider — Échecs, correction et exploitation · Preuve de réception
- À décider — Échecs, correction et exploitation · Exclusion
- À décider — Données, conservation et accès support · Responsable
- À décider — Données, conservation et accès support · Preuve de réception
- À décider — Données, conservation et accès support · Exclusion
- À décider — Sauvegarde, restauration, résiliation et sortie · Responsable
- À décider — Sauvegarde, restauration, résiliation et sortie · Preuve de réception
- À décider — Sauvegarde, restauration, résiliation et sortie · Exclusion
- À décider — Exigences non fonctionnelles et réception · Responsable
- À décider — Exigences non fonctionnelles et réception · Preuve de réception
- À décider — Exigences non fonctionnelles et réception · Exclusion

## 1. Produit vendu et premier parcours

**Décision** — STOP — À décider : Problème déjà validé, acheteur, utilisateur, résultat vendu, début et fin du premier parcours, après comparaison avec une fonction déjà payée ou une option plus simple.

**Responsable** — À décider : Personne qui tranche la promesse, le périmètre et les cas où il ne faut pas développer.

**Preuve de réception** — À décider : Scénario rejouable qui montre le résultat, ses préconditions et son résultat attendu, ainsi que l’écart décisif avec l’option plus simple.

**Exclusion** — À décider : Fonctions, segments, canaux ou résultats explicitement hors du premier périmètre.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur le problème validé, l’acheteur, le résultat vendu ou les frontières du premier parcours.

## 2. Cycle de vie de l’organisation cliente

**Décision** — STOP — À décider : Création, propriété, administration, changement de propriétaire, suspension et séparation entre organisations.

**Responsable** — À décider : Personne métier qui autorise la création, le transfert et la fermeture d’une organisation.

**Preuve de réception** — À décider : Cas de création et d’administration, plus un refus entre deux organisations fictives distinctes.

**Exclusion** — À décider : Choix d’architecture, de base de données, d’hébergeur ou de modèle d’isolation technique.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur la création, la propriété, l’administration, la suspension ou la séparation des organisations.

## 3. Invitations, rôles, portées et révocation

**Décision** — STOP — À décider : Invitation, acceptation, rôles, objets, actions, portées, changement, expiration, révocation et sessions déjà ouvertes.

**Responsable** — À décider : Personne qui valide les droits sensibles et personne qui applique ou revoit les changements.

**Preuve de réception** — À décider : Pour chaque règle critique : un cas autorisé, un cas refusé et un contrôle après révocation.

**Exclusion** — À décider : Matrice exhaustive ou modèle technique de droits lorsqu’ils relèvent d’un atelier dédié.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur une invitation, un rôle, une portée, un refus, une expiration ou une révocation.

## 4. Offres et droits d’usage

**Décision** — STOP — À décider : Offres vendues, droit ouvert ou retiré par chaque offre, quotas éventuels, passage à une autre offre et règles de consommation.

**Responsable** — À décider : Personne produit ou commerciale qui possède le catalogue et arbitre les droits d’usage.

**Preuve de réception** — À décider : Table de correspondance offre → droit → action autorisée/refusée, vérifiée sur une organisation fictive.

**Exclusion** — À décider : Prix, remise, fiscalité, comptabilité et conditions commerciales non décidées dans ce document produit.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur une offre, un droit d’usage, une limite, un quota ou un changement d’offre.

## 5. Cycle de l’abonnement

**Décision** — STOP — À décider : États internes, activation, renouvellement, changement, résiliation, fin et effet de chaque transition sur les droits.

**Responsable** — À décider : Personne qui tranche l’état produit et personne qui remet les événements de facturation en cohérence avec cet état.

**Preuve de réception** — À décider : Table événement → état interne → droit → message, avec événements répétés et reçus dans un ordre différent.

**Exclusion** — À décider : Prestataire de paiement, statuts propriétaires, prix, échéancier et délai commercial imposés dans le document.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur un état interne, un événement, son effet sur les droits ou la fin de l’abonnement.

## 6. Échecs, correction et exploitation

**Décision** — STOP — À décider : Paiement non abouti, action requise, événement manquant, doublon, tiers indisponible, correction, retour arrière, espace d’administration, support et incident.

**Responsable** — À décider : Personne qui détecte l’écart, responsable des opérations, personne qui contacte le client et personne habilitée à corriger, remettre l’état en cohérence ou revenir en arrière.

**Preuve de réception** — À décider : Cas de panne ou d’échec, dont un tiers indisponible, montrant détection, message, données préservées, reprise ou retour arrière, trace et état cohérent.

**Exclusion** — À décider : Promesse de support, disponibilité, délai de réponse ou geste commercial non validé contractuellement.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur un échec, une action de correction, une correction manuelle, l’espace d’administration, le support ou un incident.

## 7. Données, conservation et accès support

**Décision** — STOP — À décider : Catégories de données, finalités, accès, journalisation, conservation, correction et accès temporaire du support.

**Responsable** — À décider : Responsable métier des données, compétence protection des données et approbateur d’un accès support.

**Preuve de réception** — À décider : Inventaire, test de portée, ouverture puis fermeture de l’accès support et trace limitée aux informations nécessaires.

**Exclusion** — À décider : Qualification juridique, base légale, durée universelle ou déclaration de conformité produite automatiquement.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur une catégorie de données, une conservation, une trace, une correction ou un accès support.

## 8. Sauvegarde, restauration, résiliation et sortie

**Décision** — STOP — À décider : Données sauvegardées, restauration, fonctionnement dégradé, export, annulation, récupération, suppression et preuve de sortie.

**Responsable** — À décider : Personne qui accepte le risque de perte/reprise et personne qui valide l’export puis la suppression.

**Preuve de réception** — À décider : Restauration d’un jeu fictif, contrôle d’intégrité, export relu et test de refus après la suppression prévue.

**Exclusion** — À décider : Objectifs de reprise, niveau de service contractuel (SLA), délais, formats contractuels, droits sur le code et obligations légales non tranchés.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur une sauvegarde, une restauration, un export, une annulation, une récupération ou une suppression.

## 9. Exigences non fonctionnelles et réception

**Décision** — STOP — À décider : Conditions, volume de référence, scénario au volume doublé, seuils décidés, méthode, environnement et preuves pour accessibilité, performance, sécurité, mobile et exploitation.

**Responsable** — À décider : Propriétaire de chaque exigence, spécialiste chargé du contrôle et autorité humaine de réception.

**Preuve de réception** — À décider : Cas clavier, focus, erreur, mobile, clair/sombre, mesure au volume déclaré puis à son double, tests de refus et relevé d’écarts.

**Exclusion** — À décider : Certification, conformité déclarative, audit complet et acceptation automatique par l’outil.

**Inconnue bloquante** — STOP — déclaration requise : Décision encore ouverte sur un seuil, une méthode, un environnement, une preuve, un contrôle ou l’autorité de réception.

## Remise aux prestataires

Chaque répondant doit reprendre les décisions ci-dessus, signaler toute hypothèse ajoutée, décrire sa preuve, chiffrer séparément les variantes et laisser les exclusions hors du prix principal. Une réponse qui remplace une ligne STOP par un choix silencieux ne répond pas au même produit.

# Cahier des charges SaaS — DossierClair — exemple entièrement fictif

> État : Candidat à une relecture de consultation
> Document de travail généré localement. Il ne choisit ni architecture, ni prestataire de paiement, ni prix, ni délai, ni niveau de service contractuel (SLA), et ne vaut pas validation juridique, sécurité ou conformité.

## Règle de lecture

Chaque bloc distingue une décision, son responsable, la preuve attendue, ce qui est exclu et la déclaration d’une inconnue bloquante. Une déclaration vide ou différente de « Aucune identifiée » force un STOP. Une ligne STOP n’est compensée par aucun autre bloc.

## 1. Produit vendu et premier parcours

**Décision** — De petits cabinets de conseil ont déjà validé le besoin de suivre les pièces attendues avant une mission. La dirigeante achète le service. Claire, responsable de mission, crée Atelier Nord, invite Léa, ouvre un dossier, demande une pièce à un contact externe, fait qualifier la pièce puis clôt la demande. Le résultat vendu est un dossier qui montre le statut, le responsable et la prochaine action, sans promesse de gain chiffré. Dans ce scénario fictif, une annexe compare ce parcours à une fonction d’un outil déjà payé et à un processus manuel ; elle consigne les étapes et refus non couverts avant de retenir une consultation de développement.

**Responsable** — Le sponsor produit fictif tranche la promesse et le périmètre ; la responsable métier valide le parcours.

**Preuve de réception** — À partir d’une organisation vide et de données fictives, Claire accomplit le parcours complet et retrouve pour chaque pièce son statut, son responsable et la prochaine action attendue. Le même jeu fictif est rejoué avec les deux options plus simples et leurs écarts décisifs sont joints à la consultation.

**Exclusion** — Validation de marché, prospection, comptabilité du cabinet, signature électronique et mesure de productivité.

**Inconnue bloquante** — Aucune identifiée

## 2. Cycle de vie de l’organisation cliente

**Décision** — Une acheteuse crée Atelier Nord et en devient propriétaire. Elle peut nommer une administratrice et transférer la propriété après une validation distincte. Atelier Nord et Studio Rivage restent deux organisations séparées ; suspendre l’une ne modifie pas l’autre.

**Responsable** — La dirigeante de chaque organisation autorise la création, le transfert, la suspension et la fermeture.

**Preuve de réception** — Créer Atelier Nord et Studio Rivage, transférer la propriété d’Atelier Nord, puis vérifier qu’une action réalisée dans Atelier Nord ne modifie aucun objet de Studio Rivage.

**Exclusion** — Architecture d’isolation, fournisseur cloud, modèle de base de données et stratégie de déploiement.

**Inconnue bloquante** — Aucune identifiée

## 3. Invitations, rôles, portées et révocation

**Décision** — Les rôles sont propriétaire, administratrice, contributrice et contact externe. Les trois premiers restent bornés à leur organisation ; le contact externe voit seulement les demandes qui lui sont adressées. Une invitation indique rôle, organisation et personne invitante. Après retrait de l’adhésion de Léa à Atelier Nord, toute nouvelle requête vers Atelier Nord est refusée, y compris depuis une session déjà ouverte ; ses éventuels accès à une autre organisation ne sont pas modifiés. Si son compte entier est désactivé ou supprimé, toutes ses sessions actives sont terminées.

**Responsable** — La propriétaire valide les rôles sensibles ; une administratrice applique les invitations et retraits ; le sponsor produit possède la règle.

**Preuve de réception** — Tester une action autorisée de Léa dans Atelier Nord, une lecture refusée d’un dossier Studio Rivage, puis la même action Atelier Nord refusée après retrait de l’adhésion sur une session déjà ouverte. Tester séparément la fin de toutes les sessions si le compte entier est désactivé ou supprimé.

**Exclusion** — Matrice exhaustive de tous les champs et choix d’un modèle technique de contrôle d’accès.

**Inconnue bloquante** — Aucune identifiée

## 4. Offres et droits d’usage

**Décision** — L’offre fictive Équipe ouvre la création de dossiers, les invitations internes, les contacts externes et l’export des dossiers de l’organisation. Un changement d’offre applique la table de droits versionnée sans supprimer silencieusement les données existantes.

**Responsable** — La responsable produit possède le catalogue ; la responsable commerciale valide ce qui est effectivement vendu.

**Preuve de réception** — Comparer la table offre–droits à l’interface et aux contrôles côté service, puis vérifier une action permise et une action refusée pour Atelier Nord.

**Exclusion** — Prix, remises, taxes, nombre de sièges, quotas et règles comptables.

**Inconnue bloquante** — Aucune identifiée

## 5. Cycle de l’abonnement

**Décision** — Les états produit sont à_activer, active, régularisation, résiliée et sortie_terminée. Chaque transition nomme son événement déclencheur et son effet sur les droits. Un événement de paiement répété ne crée ni deuxième organisation ni double droit d’usage. Ces états restent indépendants du vocabulaire d’un prestataire de paiement.

**Responsable** — La responsable produit tranche les états et leurs droits ; l’exploitation remet les événements externes en cohérence avec l’état interne.

**Preuve de réception** — Rejouer activation, renouvellement, changement et résiliation, puis recevoir deux fois le même événement et des événements dans un ordre différent sans produire un état contradictoire.

**Exclusion** — Choix du prestataire de paiement, statuts propriétaires, prix, calendrier de facturation et délai commercial.

**Inconnue bloquante** — Aucune identifiée

## 6. Échecs, correction et exploitation

**Décision** — Un paiement non abouti place Atelier Nord en régularisation, conserve ses données et présente à la propriétaire une action de correction. Une régularisation confirmée rétablit les droits sans recréer l’organisation. Si le service de paiement ou de notification fictif est indisponible, la transition reste en attente, l’écart devient visible et aucun droit n’est ouvert, retiré ou dupliqué silencieusement. L’espace d’administration montre l’état, la source et la dernière transition ; toute correction, mise en cohérence ou reprise manuelle est autorisée et tracée.

**Responsable** — La supervision détecte l’écart ; la responsable des opérations le traite et décide la reprise prévue ; la propriétaire du compte corrige le moyen de paiement ; le sponsor produit autorise les corrections manuelles et les retours arrière.

**Preuve de réception** — Simuler échec, action requise, événement manquant, doublon, tiers indisponible, correction et retour arrière ; contrôler la détection, le message, la conservation des données, l’absence de double droit, la trace et le retour à un état cohérent.

**Exclusion** — Niveau de service contractuel (SLA), disponibilité garantie, délai de réponse, nombre de relances et geste commercial.

**Inconnue bloquante** — Aucune identifiée

## 7. Données, conservation et accès support

**Décision** — Le produit traite organisation, adhésions, demandes de pièces, métadonnées de fichier, états, journal d’actions et données de facturation nécessaires. Le support n’accède pas par défaut aux pièces : Claire demande l’intervention, approuve son périmètre et l’accès est refermé à la fin. Le journal conserve auteur, date, action, objet et organisation sans copier le contenu de la pièce.

**Responsable** — La responsable métier possède les catégories de données ; la compétence protection des données qualifie le traitement ; Claire approuve l’accès support.

**Preuve de réception** — Relire l’inventaire, ouvrir un accès support borné à un dossier fictif, tracer l’intervention, fermer l’accès puis vérifier que la requête suivante est refusée.

**Exclusion** — Avis juridique, base légale finale, durée de conservation universelle et déclaration de conformité.

**Inconnue bloquante** — Aucune identifiée

## 8. Sauvegarde, restauration, résiliation et sortie

**Décision** — Les données nécessaires au service sont sauvegardées et restaurables. La résiliation empêche un nouveau renouvellement, ouvre le parcours de sortie prévu, produit un export documenté puis mène à sortie_terminée après validation de la suppression. L’export des données clientes reste séparé des livrables projet et des droits sur le code.

**Responsable** — Le sponsor accepte le risque de reprise ; l’exploitation réalise la restauration ; la propriétaire valide l’export et la suppression de son organisation.

**Preuve de réception** — Restaurer un jeu fictif dans un environnement de test, contrôler son intégrité, relire l’export d’Atelier Nord, demander la suppression puis vérifier le refus d’accès prévu.

**Exclusion** — Objectifs chiffrés de perte et de reprise, niveau de service contractuel (SLA), durée contractuelle de récupération, format juridique de preuve et cession du code.

**Inconnue bloquante** — Aucune identifiée

## 9. Exigences non fonctionnelles et réception

**Décision** — Le parcours principal fonctionne au clavier avec focus visible, erreurs textuelles et messages de statut perceptibles. Il reste lisible à 320 px, en thèmes clair et sombre, sans perte de contenu. L’hypothèse de consultation entièrement fictive retient 20 organisations, 100 personnes internes et 2 000 dossiers, puis un second passage à 40 organisations, 200 personnes et 4 000 dossiers. La performance est mesurée sur un environnement et un jeu de données documentés contre le seuil fourni par le sponsor. Les contrôles d’organisation, de données et de révocation sont testés côté service.

**Responsable** — Le sponsor fournit les seuils ; les spécialistes accessibilité, performance et sécurité exécutent leurs contrôles ; la personne nommée dans les documents applicables prononce la réception.

**Preuve de réception** — Dossier de réception avec cas clavier, focus, erreur, mobile, clair/sombre, mesures au volume fictif déclaré puis à son double, variation de coût isolée, tests autorisés/refusés, écarts, nouveaux tests après correction et décision humaine signée.

**Exclusion** — Certification, déclaration de conformité, audit exhaustif et acceptation automatique par le générateur.

**Inconnue bloquante** — Aucune identifiée

## Remise aux prestataires

Chaque répondant doit reprendre les décisions ci-dessus, signaler toute hypothèse ajoutée, décrire sa preuve, chiffrer séparément les variantes et laisser les exclusions hors du prix principal. Une réponse qui remplace une ligne STOP par un choix silencieux ne répond pas au même produit.

Si le premier lot n’est pas encore délimité, commencez par le contrat de test du MVP SaaS. Il distingue les décisions indispensables, le travail manuel borné, les intégrations et les reports avant de demander un prix sur un périmètre encore ambigu.

Le coût complet garde le même périmètre

Le prix initial ne suffit pas à comparer les réponses. Demandez à chaque candidat d’isoler les mêmes familles, sans transformer une inconnue en zéro : ce qui est inclus, exclu, récurrent, facturé à l’usage ou laissé en variante doit rester visible.

Chaque répondant reçoit la même version figée

1. Attribuez un numéro et une date à la version de consultation.
2. Joignez les mêmes annexes et les mêmes données fictives.
3. Demandez une réponse pour chaque décision, preuve et exclusion.
4. Faites isoler les hypothèses ajoutées et les variantes de prix.
5. Centralisez les questions puis partagez les mêmes réponses à tous.
6. Comparez d’abord les écarts de produit, ensuite les modalités et le prix.

Si les réponses montrent encore plusieurs produits, réduisez le premier lot ou levez les STOP avant de choisir. Si le périmètre est comparable et que vous souhaitez confronter la trame à une réalisation, consultez notre accompagnement SaaS et applications métier, puis utilisez la page démarrer un projet en joignant une version sans données sensibles. Le répertoire des guides Hagnéré Code permet de retrouver les méthodes complémentaires.

Le même document devient l’entrée du calendrier. Pour comprendre combien de temps il faut pour développer un SaaS, reliez alors les tâches qui s’attendent, les capacités réellement disponibles et les inconnues qui interdisent encore une date.

Trois chapitres du cahier des charges méritent leur propre dossier, parce qu’ils sont les plus souvent sous-spécifiés. Les critères d’acceptation se construisent avec le plan de recette d’une application métier. Les exigences de protection se rédigent à partir des contrôles de sécurité d’une application métier. Et si le produit remplace un outil existant, la clause de bascule se prépare avec la migration sans interruption de service.

Un cahier des charges ne vaut enfin que par la façon dont les réponses sont comparées : le guide choisir un prestataire sur preuves décrit les pièces à exiger pour que deux devis portent réellement sur le même périmètre.