Cahier des charges SaaS : écrire les exigences avant de comparer les prix

Vous devez écrire le document qui servira à faire chiffrer votre logiciel, ou vous venez de recevoir des devis qui ne se ressemblent pas. Les deux situations tiennent au même point : un cahier des charges SaaS n’est utile que si deux sociétés qui le lisent chiffrent la même liste de postes. Tant que ce n’est pas le cas, la différence de prix entre leurs réponses ne mesure rien.

Ce guide part d’un exemple construit pour la démonstration : trois devis à 34 000, 58 000 et 129 000 € hors taxes (HT) pour le même document de quatorze pages. Aucun de ces montants ne vient d’un dossier client ni d’un relevé de marché. Le décompte de la section 02 isole un poste, tenu dans une phrase de dix mots page 6, qui vaut 44 000 € HT.

Vous y trouverez la relecture à faire sur votre propre document, la façon d’écrire une exigence qu’on ne peut pas lire de deux façons, les huit états d’abonnement à trancher et la grille de dépouillement à joindre aux candidats.

Le tableau ci-dessous range les trois réponses sur une même liste de sept postes — la réunion de ce que chacune nomme — et laisse écrit non chiffré partout où une société n’a rien mis. Les montants sont choisis pour ce guide : ils ne viennent d’aucun relevé de marché, et le plus élevé des trois totaux sort de la bande que notre propre grille publie. Refaites la colonne avec vos devis réels — la méthode ne dépend pas des nombres.

Ce que la colonne A ne dit pas encore

Quatre postes sur sept ne portent aucun montant chez la société A : la reprise des dossiers, l’abonnement, la saisie sans réseau et l’hébergement. La reprise, l’abonnement et l’hébergement devront être payés à quelqu’un, tôt ou tard ; la saisie sans réseau, elle, attend un arbitrage que personne n’a encore rendu. On ne devine pas le prix de ce qu’un devis n’a pas chiffré : on lui renvoie les quatre lignes, et on range ses montants à leur retour.

Un seul poste porte l’essentiel de l’écart

La saisie sur le terrain sans réseau vaut 44 000 € HT chez la société C, et n’apparaît ni chez A ni chez B. Les trois totaux vont de 34 000 à 129 000 € HT, soit 3,8 pour 1 : un rapport calculé sur trois listes de postes différentes. Seules B et C deviennent comparables une fois cette ligne retirée, puisqu’elle est la seule qui manque à B, quand quatre lignes manquent à A. Sur ce couple B et C, l’écart annoncé vaut 129 000 contre 58 000 € HT, soit 2,2 pour 1 ; la saisie sans réseau retirée, la société C tombe à 85 000 € HT et l’écart devient 1,5 pour 1. Il subsiste 27 000 € entre deux propositions qui portent enfin sur le même produit, et la phrase non tranchée pèse 1,6 fois cette somme.

Cette phrase tient sur une ligne, page 6 : « Les inspecteurs doivent pouvoir saisir leur rapport depuis le terrain. » Les sociétés A et B ont lu « un écran qui s’affiche correctement sur téléphone », compris dans les onze écrans. La société C a lu « une application qui fonctionne dans un local technique sans réseau, avec synchronisation ensuite ». Les deux lectures se défendent. L’une coûte 44 000 € HT, soit 34 % du devis le plus élevé.

Ce que notre propre grille situe, et ce qu’elle ne compare pas

Le repère qui suit est le nôtre, relevé sur notre grille publique le 30 août 2026, et non une observation du marché : nous vendons ce type de projet. Elle situe un premier SaaS de trois à cinq écrans à 15 000 € HT, et un produit standard de dix à quinze écrans entre 30 000 et 60 000 € HT. Deux réserves. Cette seconde bande est libellée « 10–15 écrans + IA », quand le portail de l’exemple ne comporte aucune fonction d’intelligence artificielle : la comparaison ne porte pas sur les mêmes fonctions. Et les montants de l’exemple ont été choisis pour la démonstration : le total C de 129 000 € HT vaut plus du double de sa borne haute, et ramené à 85 000 € il reste 25 000 € au-dessus. Ces montants restent des repères publics et indicatifs ; seul un devis signé fixe un prix ferme.

Une exigence est testable quand vous savez écrire son échec. Si personne ne peut dire quelle tentative doit être refusée, personne ne saura recevoir la fonction, et le jour de la livraison se réglera à la discussion.

Reprenons la phrase de la page 6. Voici ce qu’elle devient une fois écrite pour qu’un devis puisse l’isoler et la chiffrer seule.

EXIGENCE R-14 — Saisir un rapport sans réseau

Situation initiale : un inspecteur connecté, affecté au dossier 2 481
de l’organisation Bailleur Nord, dans un local technique sans réseau
mobile ni Wi-Fi.

Action : il ouvre le dossier, renseigne douze champs, joint trois photos,
valide.

Résultat attendu : le rapport est conservé sur l’appareil. Dès le retour
du réseau, il apparaît côté serveur avec ses trois photos, au plus tard
quatre heures après la validation.

Refus attendu : un inspecteur non affecté au dossier 2 481 ne peut pas
l’ouvrir, avec ou sans réseau.

Preuve de réception : mode avion activé, saisie complète, mode avion
coupé, capture du rapport côté serveur avec ses trois photos.

Hors de cette exigence : la consultation sans réseau des rapports des
autres dossiers.

Décision encore ouverte : deux inspecteurs modifient le même rapport sans
réseau, lequel gagne ? Tranché par Sonia avant le 15 septembre.
Chiffrer les deux branches séparément.

Sept blocs au lieu d’une ligne, et aucun ne nomme une technologie : ni le langage, ni la base de données, ni le mécanisme de synchronisation. Chaque société reste libre de sa solution, et aucune ne peut plus se tromper de produit. Le seul ajout coûteux, l’arbitrage sur le conflit d’écriture, est déclaré ouvert et sera chiffré deux fois.

La mesure à faire sur votre propre document

Exportez votre cahier des charges en texte, puis comptez les mots qui repoussent une décision. Cette commande fonctionne dans un terminal macOS ou Linux, et sous Windows depuis le sous-système Linux :

grep -onEi 'etc\.|notamment|le cas échéant|si nécessaire|si besoin|idéalement|ergonomique|intuitif|convivial|performant|moderne|standard du marché|à définir avec' cahier-des-charges.txt

Chaque ligne renvoyée porte son numéro et devient une entrée de votre liste de travail : soit une exigence écrite comme ci-dessus, soit une décision déclarée ouverte, avec son nom et sa date. Nous ne publions aucun seuil pour cette densité, et en inventer un serait pire que de s’en passer. Le repère utile reste interne à votre texte : relancez la commande après réécriture, puis reprenez une par une les occurrences qui subsistent. Chacune est soit une décision que personne n’a voulu prendre, soit un mot que vous gardez sciemment : écrivez lequel.

Les deux exigences qu’un adjectif ne remplace jamais

« Interface accessible » ne se reçoit pas. Les règles WCAG 2.2, recommandation du W3C datée du 12 décembre 2024, ajoutent neuf critères à la version précédente, dont six aux niveaux A et AA, et déclarent obsolète l’ancien critère 4.1.1. Le critère 2.5.8 fixe par exemple la taille minimale d’une cible tactile à 24 × 24 pixels CSS, vérifiable sur une maquette. Écrivez les critères que vous retenez, le parcours concerné et la personne qui les contrôle.

« Application sécurisée » non plus. Le référentiel OWASP ASVS, version 5.0.0 publiée le 30 mai 2025, compte 345 exigences réparties en dix-sept chapitres, comptées sur le fichier officiel de la version figée. Vous en choisissez quelques-unes, vous les citez avec leur numéro de version, et vous dites lesquelles seront testées et par qui. Le socle de sécurité à exiger avant la mise en service détaille ce tri, et le plan de recette d’une application métier donne la forme des scénarios à rejouer.

Un cahier des charges qui s’arrête à « l’accès s’ouvre à la souscription et se ferme à la résiliation » décrit deux états. La documentation publique de Stripe en décrit huit. Les six autres sont laissées à l’appréciation de la personne qui code, et trois d’entre elles décrivent une situation où le paiement n’a pas abouti sans que l’accès se ferme de lui-même : incomplete, past_due et unpaid.

Ces huit lignes viennent de la documentation Stripe, consultée le 30 août 2026 et citée ici comme repère de dénombrement : que vous reteniez Stripe, un prélèvement SEPA ou une facturation manuelle, les mêmes huit situations existeront, sous d’autres noms. Trois décisions par état, cela fait vingt-quatre lignes à écrire — exactement le travail qu’un devis chiffre différemment selon qu’il l’a vu ou non.

Ce qu’il faut écrire même si vous changez de fournisseur

Les notifications de paiement n’arrivent ni dans l’ordre, ni une seule fois, ni forcément tout de suite. La documentation le dit explicitement, et chacun de ces faits produit une exigence.

• L’ordre n’est pas garanti. Votre produit doit rester juste si la confirmation de paiement arrive avant la création de l’abonnement. L’exigence : rejouer les deux ordres et obtenir le même état final.
• Le même événement peut arriver deux fois. Il se reconnaît à l’identifiant de l’objet et au type d’événement. L’exigence : le second passage ne change rien et ne crée aucun deuxième droit.
• Une notification perdue est réessayée jusqu’à trois jours en production, avec des délais croissants ; trois tentatives en quelques heures en environnement de test. L’exigence : un écran qui liste les événements non traités, et une reprise manuelle attribuée à quelqu’un.

Le mot « réversibilité » recouvre quatre objets qui n’obéissent pas aux mêmes règles. Deux d’entre eux sont adossés à un texte : vos données au règlement européen, le code source au code de la propriété intellectuelle. Les deux autres ne tiennent qu’à ce que votre contrat prévoit. Une clause unique ne les couvre donc pas.

Le règlement européen sur les données mérite une lecture précise, parce qu’il est souvent résumé en un droit d’export universel qui n’existe pas. Il vise les services de traitement de données, au sens de sa propre définition, et non tout abonnement qu’on appelle SaaS. Sur ce champ, il est net : applicable depuis le 12 septembre 2025, période transitoire maximale de 30 jours calendaires à l’article 25, frais de changement supprimés au 12 janvier 2027 à l’article 29. Ce délai ne part qu’au terme du préavis de changement, plafonné à deux mois par le même article. Ces 30 jours ne sont pas un plancher ferme : l’article prévoit aussi que, si ce délai est techniquement impossible à tenir, le fournisseur informe le client dans les 14 jours ouvrables, justifie l’impossibilité et propose une période alternative « qui ne peut excéder sept mois ». Écrivez donc dans le contrat la date que vous visez. Il ne dit rien du code source, rien des droits d’exploitation, rien de la documentation de déploiement.

Payer un développement ne vous en rend pas propriétaire

Cette clause se renégocie une fois le développement payé, c’est-à-dire au moment où vous avez le moins de prise. L’article L131-3 du code de la propriété intellectuelle demande que chacun des droits cédés fasse l’objet d’une mention distincte, et que l’étendue, la destination, le lieu et la durée de l’exploitation soient délimités. Une facture acquittée n’énumère aucun de ces éléments. Ce formalisme figure aux dispositions générales du code, et non parmi les articles qui visent le logiciel : raison de plus d’écrire la clause.

L’article L113-9, celui qui attribue à l’employeur les droits sur un logiciel, vise le salarié dans l’exercice de ses fonctions. Une société de développement extérieure n’est pas votre salariée : confondre les deux articles se paie le jour où votre équipe veut reprendre le produit ailleurs.

Les situations ci-dessous sont construites sur le dossier de Sonia, à partir des mécanismes décrits par les sources citées en bas de page. Leurs montants et leurs volumes sont ceux de l’exemple : ce ne sont pas des dossiers clients. Chacune vient d’une ligne qui manquait au cahier des charges.

La phrase à deux lectures : 44 000 € HT d’écart

Dix mots page 6, deux lectures défendables, un poste que deux sociétés sur trois n’ont pas chiffré. Si Sonia retient la société B sans avoir tranché, la saisie sans réseau reviendra en avenant, le jour où les inspecteurs se plaindront — et un avenant se négocie sans concurrent en face. Une sixième question, en section 02, aurait sorti le sujet.

L’abonnement câblé sur un seul événement : 11 accès ouverts, 16 390 € HT non facturés

Le document disait « l’accès s’ouvre à la souscription ». L’équipe a écouté l’événement de première souscription, et rien d’autre. Dix-huit mois plus tard, quarante-trois organisations sont abonnées ; onze d’entre elles, soit 26 %, ont vu leur prélèvement annuel échouer sans que rien ne se ferme. À 1 490 € HT l’abonnement, cela fait 16 390 € HT à rattraper, plus la conversation avec onze clients à qui l’on va demander de payer un service qu’ils utilisaient gratuitement. Les vingt-quatre lignes de la section 04 nomment cette situation avant la première ligne de code.

La séparation entre clients jamais testée : 72 heures pour reconstituer qui a vu quoi

Le document exigeait que chaque bailleur ne voie que ses dossiers. Il ne demandait pas de le prouver. La recette a montré qu’une utilisatrice autorisée voyait bien ses rapports ; personne n’a vérifié qu’une autre se voyait refuser l’accès. Le jour où un rapport apparaît chez le mauvais bailleur, l’article 33 du RGPD impose une notification à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance — et non après la survenance — sauf si cette violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques. Ces 72 heures partent d’abord à établir qui a vu quoi parmi 12 000 dossiers et quarante-trois organisations — une reconstitution qui mobilise la responsable informatique et le délégué à la protection des données, et que rien n’a préparée. Le test qui l’aurait évitée s’écrit avant la mise en service : deux organisations fictives, une requête qui doit être refusée, le résultat attendu au plan de recette.

Les postes, les hypothèses et les preuves se regardent avant les prix. Joignez au cahier des charges une grille à cinq colonnes, la même pour tous, et demandez une ligne par exigence numérotée. Une réponse qui arrive sans cette grille se renvoie.

Quatre règles de consultation rendent cette grille exploitable.

1. Une version figée, datée et numérotée. Toute correction postérieure repart aux trois candidats avec un nouveau numéro, faute de quoi vous comparerez des réponses à des documents différents.
2. Les mêmes données fictives pour tous. Deux organisations, six rôles, une centaine de dossiers, qui serviront ensuite à recevoir.
3. Les questions centralisées. Une question posée par une société reçoit une réponse envoyée aux trois, le même jour.
4. Les écarts de produit avant les écarts de prix. Alignez les postes, repérez les non chiffrés, puis seulement regardez les totaux.

Sur le dossier de Sonia, ce dépouillement fait apparaître trois décisions, dont une seule est financière : trancher la saisie sans réseau, obtenir de la société A ses quatre postes manquants, demander à la société C ce qu’elle a vu de plus.

L’outil ci-dessous fonctionne dans votre navigateur. Il n’envoie rien, n’enregistre rien et ne produit aucun fichier : la sortie se copie en Markdown. Neuf blocs, cinq champs par bloc, quarante-cinq zones de texte. Chaque bloc sépare la décision, la personne qui la porte, la preuve attendue, ce qui est exclu et l’inconnue qui bloque.

Une décision laissée vide, ou remplie d’un mot d’attente, arrête le document. La trame emploie deux mots pour le dire : STOP marque une décision à prendre avant l’envoi, une ligne « à décider » marque une question qui peut partir aux candidats telle quelle, à condition qu’ils en chiffrent les deux branches. Aucun score ne compense un blocage, et l’outil ne vérifie jamais si ce que vous écrivez est vrai — seulement si une réponse manque à un endroit qui empêcherait deux sociétés de chiffrer la même chose.

# 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.

Un exemple rempli de bout en bout

Le document ci-dessous sort de la même trame, sur un cas entièrement fictif : DossierClair, un suivi de pièces pour de petits cabinets de conseil. Atelier Nord et Studio Rivage sont deux organisations inventées, comme les rôles, les états et les volumes de 20 puis 40 organisations qui servent à tester un doublement de charge. Rien là-dedans n’est un prix, un délai ni un engagement de service.

# 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.

Une fois la trame remplie et les trois réponses dépouillées, vous pouvez décrire votre projet à Hagnéré Code en joignant une version sans donnée sensible, ou lire comment nous travaillons sur la page SaaS et applications métier.

Transparence. Hagnéré Code développe des SaaS et des applications métier sur mesure, et fait partie des sociétés qu’un cahier des charges comme celui-ci met en concurrence : nous percevons des honoraires si vous nous retenez. Rien ici n’oblige à passer par nous — le décompte poste par poste, la mesure des mots flous, les huit états d’abonnement et la grille de dépouillement se refont avec vos propres documents, y compris pour nous écarter. Nos prix et les références citées ont été relevés le 30 août 2026, à revérifier tous les douze mois. Aucun coût, aucun délai et aucun résultat ne sont garantis par cette page : seul un devis signé engage.