Cahier des charges SaaS : obtenir des devis réellement comparables
4 minutes de lecture environ
Un cahier des charges SaaS sert à rendre les décisions explicites avant de chiffrer le travail. Il doit permettre à plusieurs prestataires de comprendre le même problème, d’identifier les inconnues et de proposer un périmètre vérifiable. Une longue liste de fonctionnalités ne suffit pas.
Décrivez d’abord les parcours et les critères d’acceptation. Demandez ensuite un prix associé à des hypothèses, des exclusions et des livrables dont vous pourrez vérifier la conformité.
Dans cet article
Partir du service attendu
Présentez le public, la situation de départ et le résultat obtenu grâce au produit. Expliquez ce qui existe déjà et ce qui doit être remplacé. Un prestataire doit comprendre pourquoi une fonction est nécessaire avant de proposer son implémentation. Le SaaS décrit un mode de fourniture ; il ne définit pas à lui seul le métier du logiciel.
Choisissez quelques parcours représentatifs, comprenant un succès et une difficulté. Pour un import, décrivez la préparation du fichier, le contrôle, la correction et la reprise. Cette précision révèle des tâches invisibles dans une ligne intitulée simplement « import de données ».
Pour approfondir : OWASP — Application Security Verification Standard
Préciser les rôles et les objets manipulés
Listez les rôles : administrateur de l’organisation, gestionnaire, utilisateur invité, équipe de support. Indiquez pour chacun ce qu’il peut voir, modifier, exporter et supprimer. Le modèle multi-tenant exige de définir la séparation entre organisations ; les exceptions doivent être visibles dans le besoin.
Décrivez les principaux objets, leurs relations et leur historique. Un document peut appartenir à un dossier, avoir plusieurs versions et conserver une trace de validation. Précisez les volumes actuels et les hypothèses de croissance, sans les transformer en prévision certaine. Joignez des exemples fictifs représentatifs des formats réels.
Rendre les exigences non fonctionnelles testables
« Rapide » et « sécurisé » sont trop vagues pour accepter une livraison. Définissez des conditions de charge, les opérations sensibles et les comportements attendus en cas d’échec. OWASP ASVS fournit un référentiel de contrôles techniques ; sélectionnez ceux qui correspondent au périmètre et demandez les preuves convenues.
Décrivez aussi la disponibilité attendue, les sauvegardes, la restauration, la journalisation et les mises à jour. Si une API externe est indisponible, le système doit-il attendre, réessayer ou permettre une reprise manuelle ? Ces choix affectent directement architecture, coût et exploitation.
| Élément | À préciser | Preuve attendue |
|---|---|---|
| Parcours | Étapes, rôles et erreurs | Scénarios de recette |
| Intégration | Données et dépendances | Essai sur un format représentatif |
| Exploitation | Responsables et continuité | Procédure et exercice de reprise |
Cas pratique : deux devis qui ne parlent pas du même produit
Scénario fictif : deux prestataires chiffrent un portail de reporting. Le premier inclut un chargement manuel et un export simple. Le second prévoit une connexion automatique, des reprises sur erreur et un historique détaillé. Comparer uniquement leurs totaux ferait passer une différence de périmètre pour une différence de prix.
L’équipe reformule le parcours minimal et les options. Elle demande à chacun d’indiquer les hypothèses sur les données, les dépendances client et les éléments exclus. Les devis deviennent comparables sans imposer la même solution technique à tous.
Organiser la recette et les changements
Un critère d’acceptation associe une situation, une action et un résultat observable. Par exemple : un utilisateur d’une organisation ne peut pas télécharger le document d’une autre, même en connaissant son identifiant. La recette comprend les parcours métier et les cas d’erreur prévus, avec des données préparées.
Définissez qui tranche une ambiguïté et comment un changement est estimé. Un besoin nouveau ne doit pas se glisser silencieusement dans une livraison ; une correction d’un comportement convenu ne doit pas être automatiquement requalifiée en nouvelle fonction. Conservez décisions et versions du périmètre.
Préparer la remise et l’exploitation
Demandez les accès, dépôts, documents d’installation, procédures de sauvegarde et modalités de transfert. Précisez qui assure le support, dans quel cadre et à partir de quelle date. La propriété et les droits d’utilisation des composants doivent être examinés dans les documents contractuels adaptés.
Terminez le cahier des charges par les questions ouvertes. Certains sujets nécessitent une phase de cadrage ou un prototype avant engagement ferme. Identifier cette incertitude en amont produit un devis plus utile qu’un montant artificiellement définitif.
Votre plan d’action
- Décrire les parcours et leurs cas d’erreur.
- Fournir des exemples de données fictives.
- Écrire des critères d’acceptation vérifiables.
- Séparer socle, options et inconnues.
- Prévoir la remise et l’exploitation dès le devis.
Sources et références
Notions utiles dans le lexique
Startup & produit
Critère d’acceptation
Condition observable permettant de décider si un résultat satisfait le besoin défini.
Données & architecture
API
Interface définissant comment un logiciel peut demander des informations ou des actions à un autre composant.
Cloud & sécurité
Architecture multi-tenant
Architecture dans laquelle plusieurs clients utilisent des ressources partagées avec une séparation de leurs données et permissions.
Startup & produit
SaaS — logiciel en tant que service
Le SaaS est un mode de fourniture d’un logiciel accessible comme un service, généralement par Internet et avec un abonnement.
Transformez votre besoin en périmètre vérifiable.
Vous préparez un SaaS et souhaitez obtenir des devis comparables ? Contactez StartHub pour vous faire accompagner dans le cahier des charges, les critères de recette et le cadrage de l’exploitation.
Contacter StartHub
