Votre démonstration a convaincu. Le prospect parle déploiement, nombre d'utilisateurs et contrat annuel. Puis son équipe sécurité envoie un questionnaire de quinze pages : authentification, permissions, sauvegardes, sous-traitants, journalisation, plan de reprise. Votre roadmap produit vient de rencontrer la réalité d'un grand compte. Faut-il tout construire pour sauver la vente ? Non. Votre SaaS est prêt lorsqu'il sait traiter les risques précis du contrat et en apporter la preuve, pas lorsqu'il accumule toutes les cases du marché Enterprise.
Je me souviens de mon arrivée, en 2021, dans une scale-up qui livrait des solutions pour McDonald's, Disney, la SNCF ou Total. J'avais l'habitude des startups où une fonctionnalité pouvait partir en production en une journée. Là, chaque ligne était relue, testée et discutée par plusieurs développeurs. Une livraison qui m'aurait pris un jour pouvait demander une semaine.
Au début, cette lenteur me frustrait. Puis j'ai compris ce qui avait changé : pas la compétence de l'équipe, mais le coût d'une erreur. Des dizaines de milliers de personnes utilisaient ces produits au quotidien. Les clients achetaient une fonctionnalité, mais aussi la certitude que le service continuerait à fonctionner et que les incidents seraient maîtrisés.
Le même changement se produit quand votre SaaS B2B vise son premier grand compte. Les processus qui auraient étouffé votre MVP deviennent parfois nécessaires. Le piège consiste à les copier tous, sans relier chaque investissement au contrat que vous essayez réellement de signer.
Un grand compte achète votre maîtrise du risque
Dans une vente simple, une démonstration et quelques échanges peuvent suffire. Un grand compte implique souvent d'autres interlocuteurs : achats, sécurité, juridique, protection des données et équipe informatique. Chacun évalue une partie différente du risque. Votre utilisateur veut la fonctionnalité. Son entreprise veut savoir ce qui arrivera le jour où un salarié partira, où une donnée sera exposée ou lorsque votre service tombera en panne.
Cette différence explique pourquoi un produit apprécié peut rester bloqué avant la signature. Le prospect n'a pas nécessairement découvert un défaut. Il cherche à vérifier que votre entreprise peut tenir la promesse faite par le commercial. Une phrase comme « les données sont sécurisées » ne suffit plus. Il faut préciser qui y accède, comment les droits sont retirés et quelle trace reste après une action sensible.
La CNIL organise son guide de sécurité autour de sujets très concrets : authentification, habilitations, traçabilité, sauvegardes, gestion des incidents et analyse des risques. Ces thèmes ne sont pas réservés aux grands groupes. Ce qui change avec un contrat important, c'est le niveau de preuve attendu et la conséquence commerciale d'une réponse floue.
Vous n'avez donc pas besoin de devenir expert en cybersécurité pour vendre. Vous devez relier chaque question technique à une promesse compréhensible. Le SSO, ou connexion avec l'identité professionnelle du client, réduit les comptes isolés difficiles à fermer. Le MFA ajoute une seconde preuve lors de la connexion. Les rôles limitent ce que chaque utilisateur peut faire. Les journaux d'audit permettent de retrouver une action contestée.
Les guides d'« enterprise readiness » citent régulièrement SSO, gestion des comptes, rôles et audit logs. WorkOS en donne un exemple récent. Cette liste résume les attentes courantes, mais elle ne connaît ni votre prospect ni la valeur du contrat. Elle ne peut pas décider de votre roadmap.
Ce qui peut réellement faire perdre le contrat
Toutes les demandes n'ont pas le même poids. Une exigence est bloquante lorsque le client ne peut pas déroger à sa politique interne. Sans SSO, par exemple, son équipe informatique peut refuser l'ouverture du service. Une autre demande relève surtout de la preuve : vous réalisez déjà des sauvegardes, mais vous ne savez pas présenter leur fréquence, leur localisation ou le dernier test de restauration.
D'autres demandes restent négociables. Le client peut demander un rapport d'audit récent, mais accepter un audit planifié ou des mesures compensatoires pendant quelques mois. Certaines demandes sont simplement prématurées. Elles apparaissent dans le questionnaire standard alors qu'elles ne correspondent ni aux données confiées, ni au périmètre du déploiement. Les traiter immédiatement ferait payer à tous vos clients la complexité d'un seul prospect.
La sécurité doit rester proportionnée au risque. L'ANSSI recommande elle-même d'adapter l'authentification au contexte. Un service manipulant des informations sensibles ne fait pas face aux mêmes menaces qu'un outil secondaire. Le bon niveau dépend des données, des utilisateurs, des accès privilégiés et des conséquences d'une compromission.
Cette nuance évite deux erreurs opposées : promettre des contrôles que l'équipe ne sait pas tenir, ou les construire avant que le client les confirme comme indispensables.
Le développement n'est qu'une partie du coût. Une connexion SSO doit être supportée, des rôles détaillés modifient les tests et un journal d'audit doit rester exploitable. Chaque case cochée crée une obligation dans la durée.
Avant de promettre, demandez donc au prospect ce qui bloque formellement la validation. Qui porte cette exigence ? Existe-t-il une dérogation ? Quel niveau de preuve est attendu ? À quelle date ? Une discussion de trente minutes avec la sécurité ou les achats peut éviter un mois de développement fondé sur une mauvaise interprétation.
Transformer le questionnaire en roadmap commerciale
Un questionnaire de sécurité ne doit pas rester un document rempli en urgence par le fondateur. Traitez-le comme une source de décisions produit. Pour chaque demande, votre équipe doit formuler le risque couvert, l'état actuel, la preuve disponible, l'écart réel et la décision prise. Cette traduction transforme une succession d'acronymes en travail priorisable.
Si le client exige le SSO, le besoin business n'est pas « ajouter SAML ». Il veut centraliser les arrivées et les départs de ses collaborateurs. Votre réponse peut combiner une intégration technique, une procédure temporaire de révocation et une date de livraison. Partez de ce résultat pour choisir la solution.
Même logique pour la journalisation. Un grand compte ne demande pas des logs pour collectionner des fichiers. Il veut enquêter après une action sensible et attribuer cette action à la bonne personne. Le référentiel de l'ANSSI distingue notamment la journalisation des accès administrateurs et celle des événements de sécurité. Pour votre produit, commencez par les actions dont la contestation aurait un coût commercial : changement de droits, export, suppression ou modification d'une donnée critique.
Certaines réponses existent déjà sans nouveau code. Une liste des sous-traitants, un test de restauration ou une procédure d'incident peuvent débloquer une revue. Ces preuves réduisent l'incertitude du client et préparent le prochain questionnaire.
Les écarts restants entrent dans la roadmap selon leur effet sur la vente. Une exigence qui bloque un contrat qualifié passe devant une amélioration de confort. Une demande portée par un seul prospect reste isolée tant que sa valeur ne justifie pas son coût. Une capacité réclamée par plusieurs prospects devient probablement une brique de votre offre Enterprise.
Ce travail dépend directement des choix invisibles de l'architecture SaaS B2B. Les permissions, la séparation des données et la traçabilité se construisent plus facilement lorsqu'elles existent déjà comme concepts du produit. Si elles ont été ajoutées au cas par cas, un audit technique de la startup permet de mesurer l'écart avant de promettre une date.
Décider jusqu'où investir avant de signer
Le montant du contrat ne suffit pas pour décider. Comparez sa valeur probable au coût complet de la montée en gamme : développement, audit, documentation, support, maintenance et ralentissement des autres priorités. Ajoutez aussi la réutilisation. Une capacité demandée par ce prospect ouvrira-t-elle d'autres comptes similaires, ou restera-t-elle une exception coûteuse ?
Un prospect intéressé ne justifie pas le même investissement qu'un contrat conditionné par trois écarts identifiés. Plus le client avance dans ses validations, plus vous engagez de ressources : preuves existantes, chiffrage des écarts, validation du périmètre, puis développement.
N'essayez pas non plus de fabriquer une certification avec du code. Une norme ou un audit évalue aussi l'organisation, les responsabilités et les pratiques réelles. Acheter un outil ou ajouter une page de réglages ne remplace pas une politique appliquée. À l'inverse, l'absence d'un label précis ne signifie pas toujours que le contrat est perdu. Seul le client peut confirmer ce qui relève de son obligation et ce qui relève de sa préférence.
Votre décision finale doit tenir en une phrase : « Pour signer ce contrat, nous devons prouver ces éléments, corriger ces écarts avant telle date et nous n'investirons pas encore dans le reste. » Si personne ne peut écrire cette phrase, le sujet n'est pas prêt à entrer dans la roadmap.
Votre SaaS n'a pas besoin de devenir une forteresse. Rendez vos promesses vérifiables, puis investissez là où le risque menace réellement le revenu. C'est un travail de direction technique autant que de sécurité : protéger le contrat sans sacrifier le produit qui vous a permis de l'obtenir.
Un CTO part-time peut justement faire le lien entre le questionnaire, l'équipe technique et la décision commerciale. Son rôle n'est pas de cocher toutes les cases, mais de rendre le risque lisible et de défendre une roadmap que le client comme l'équipe peuvent comprendre.
Ce qu'il faut retenir
Un grand compte n'attend pas un produit sans risque. Il attend que vous sachiez identifier les risques qui le concernent, expliquer les contrôles existants et corriger les écarts qui bloquent réellement son achat. Le questionnaire de sécurité devient utile lorsqu'il produit des décisions, pas lorsqu'il produit une collection de réponses rassurantes.
Commencez par séparer les exigences bloquantes, les preuves déjà disponibles, les points négociables et les investissements prématurés. Vous protégerez mieux le contrat tout en évitant de convertir une opportunité commerciale en refonte incontrôlée de votre SaaS.
Questions fréquentes
Le SSO est-il obligatoire pour vendre à un grand compte ?
Pas systématiquement, mais il peut être imposé par la politique interne du client. Demandez s'il constitue un prérequis formel, s'il existe une dérogation temporaire et quel protocole son système d'identité accepte avant de chiffrer l'intégration.
Faut-il obtenir une certification avant le premier contrat Enterprise ?
Cela dépend du secteur, des données et des règles d'achat du client. Commencez par faire préciser le niveau de preuve attendu : questionnaire, audit indépendant, plan de remédiation ou certification. Ne présentez jamais une démarche en cours comme une certification acquise.
Qui doit répondre au questionnaire de sécurité ?
Le commercial ou le fondateur doit porter la relation, mais les réponses techniques doivent être validées par la personne responsable du produit et de l'infrastructure. Gardez ensuite une version datée, accompagnée des preuves, pour éviter des réponses contradictoires lors du prochain contrat.
Conclusion
Si un questionnaire de sécurité bloque votre prochain contrat, réservez un échange de 30 minutes pour transformer ses exigences en plan d'action priorisé.