Un CTO m'a appelée en panique un vendredi 18h. Un grand compte EU venait d'envoyer un SIG Lite de 270 questions. Réponse attendue lundi midi pour passer en comité d'achat le mercredi. Pas de SOC 2, pas de RSSI, pas de knowledge base. Juste un Notion mal rangé et un Confluence Atlassian qui datait.
On a livré 270 réponses sourcées le lundi matin à 11h. Le deal a été signé. Ce qui suit, c'est la méthode qu'on a appliquée — et qu'on reproduit sur à peu près une mission par mois chez WeeSec depuis fin 2025.
Pourquoi ces questionnaires bloquent les deals
Quand un grand compte demande un questionnaire sécurité, il y a trois choses qui se jouent en parallèle :
- L'achat est presque acté côté métier. Le questionnaire arrive après la démo, après le POC, après la négo de prix. Vous êtes shortlisté.
- L'équipe sécu de l'acheteur a un délai court. Souvent 5 à 10 jours ouvrés. Si vous mettez 3 semaines, vous sortez de la fenêtre du comité d'achat suivant.
- La qualité des réponses signale votre maturité. Une réponse vague ("Nous suivons les meilleures pratiques") coûte plus de questions de relance. Trois aller-retours et le deal glisse au trimestre suivant.
Donc le bon réflexe, c'est pas de remplir vite. C'est de remplir carré, sourcé, et une seule fois.
Les trois formats que vous allez croiser
SIG Lite et SIG Core (Shared Assessments)
Format Excel standardisé par Shared Assessments, très utilisé US et de plus en plus EU. SIG Lite = ~270 questions. SIG Core = ~1500+. Si on vous envoie le Core directement, c'est rare et c'est un signal très fort (régulé, banque, santé).
CAIQ (Cloud Security Alliance)
Format pour SaaS cloud. ~260 questions Y/N + justification. Utilisé par les clients qui ont une équipe sécu mature.
Questionnaire propriétaire
Un Excel maison de 80 à 400 questions. Très variable en qualité. Souvent un copier-coller de questions sans contexte. C'est paradoxalement le plus dur — les questions sont mal formulées, vous devez reformuler.
Le workflow 5 jours, jour par jour
Jour 1 (vendredi soir / samedi matin) — Triage et knowledge base
Première chose : lire la totalité du questionnaire. Pas répondre. Lire. Classer chaque question dans une de ces 4 catégories :
- A — Réponse évidente, preuve existante. (~40% des questions)
- B — Réponse à formuler, preuve existante mais à retrouver. (~30%)
- C — Réponse vraie mais pas encore implémentée carré. (~20%) → ces questions vont demander une honnêteté graduée.
- D — On ne fait pas du tout, ou pas sûr. (~10%)
En parallèle, ouvrir un Google Doc partagé qui devient votre knowledge base de réponses réutilisables. Chaque réponse rédigée une fois sera réutilisable pour les 20 questionnaires suivants.
Jour 2 — Répondre aux A et B
Sur les A et B, vous foncez. Le piège : ne pas écrire de réponses creuses. Format gagnant :
- Position factuelle (1-2 phrases).
- Référence à un artefact : politique, ticket, screenshot, contrat fournisseur.
- Si applicable, périmètre : "sur l'environnement prod, oui ; sur le sandbox de dev, non, parce que..."
L'honnêteté graduée fait gagner du temps. Une équipe sécu qui lit "oui partiellement, voici le plan pour finir d'ici T3" vous accordera plus de crédit qu'un "oui" qu'elle suspecte vague.
Jour 3 — Traiter les C avec preuve de trajectoire
Sur les questions C, vous écrivez :
- Ce qui est en place aujourd'hui (même partiel).
- Le plan documenté (ticket, roadmap, date cible).
- L'owner (un nom, une fonction).
Si vous n'avez pas de plan, vous en faites un en 30 minutes avec un ticket Linear ou Jira daté. C'est sincère parce que vous allez réellement l'exécuter.
Jour 4 — Traiter les D avec une stratégie de "compensating control"
Sur les D — ce que vous ne faites pas — deux options :
- "Non, voici pourquoi cette mesure n'est pas pertinente dans notre contexte" (justifier par votre architecture).
- "Non, mais nous compensons par X, Y, Z" (un contrôle compensatoire).
Mentir sur un D, c'est ce qui plante les deals 6 mois plus tard quand un audit creuse. Ça vaut jamais le coup.
Jour 5 — Relecture par un œil externe
Idéalement quelqu'un qui n'a pas écrit les réponses. Un cofondateur tech, un RSSI externalisé, un freelance sécu. Objectif : repérer les incohérences entre questions (vous avez dit "toutes les données sont chiffrées au repos" question 47, puis "nous n'utilisons pas de KMS" question 122).
Renvoyer le questionnaire avant 11h le matin du jour 5. Pas le soir. L'équipe sécu de l'acheteur a besoin de la journée pour le lire.
Les pièges qu'on voit le plus
Le copier-coller de la doc technique
Tentation : prendre votre architecture diagram et le coller en bloc. L'équipe sécu n'a pas le temps. Elle veut des réponses précises à des questions précises.
Le mensonge poli
"Nous prévoyons d'obtenir SOC 2 Type II d'ici 6 mois" alors que vous n'avez pas commencé. Si l'acheteur revient dans 6 mois, vous êtes mort. Préférez : "Nous avons engagé le scoping SOC 2 Type II et visons une obtention en T2 2027. À date, voici les contrôles déjà en place..."
La non-différenciation environnements
Beaucoup de questions distinguent prod / staging / dev / sandbox. Une réponse globale type "oui partout" est souvent fausse. Différencier vous protège.
Ignorer le contexte EU
Si l'acheteur est EU, ajouter spontanément : localisation des données, sous-processeurs (avec liste), DPA, base légale RGPD, transferts hors EU et garanties. Souvent ce n'est pas dans le questionnaire US-centric et c'est ce qui bloque côté DPO de l'acheteur.
La knowledge base qui rentabilise tout ce travail
Si vous ne devez retenir qu'une chose : votre knowledge base de réponses sourcées est un actif commercial. Sur les 5 prochains questionnaires, vous allez réutiliser 60 à 80% des réponses. Le 6ème ne vous coûtera plus que 2 jours au lieu de 5.
Structure minimale qui marche :
- Un Notion / Confluence avec un page par grand chapitre (gouvernance, RH, infra, dev, incident, fournisseurs, données).
- Chaque réponse a un owner et une date de dernière revue.
- Une revue trimestrielle pour rafraîchir (un PR refusé en commun avec l'équipe sécu).
Quand sous-traiter et quand garder en interne
Garder en interne : la knowledge base, les réponses C et D (qui demandent du jugement), les questions architecture.
Sous-traiter raisonnablement : la rédaction des A et B sur un format standardisé (SIG, CAIQ), la relecture cohérence, le formatage Excel propre. Un freelance ou un RSSI externalisé fait ça en 2-3 jours et vous libère pour rester sur le produit.
Le contre-exemple instructif
Une scale-up que j'ai croisée fin 2025 avait répondu à 5 questionnaires d'affilée sans construire de knowledge base. À chaque fois, on recommençait de zéro. La 6ème fois, le CTO m'a appelée parce que ça avait monopolisé 3 personnes pendant 8 jours. Coût caché de cette non-systématisation : à peu près 18-20 jours-homme par trimestre sur des deals enterprise.
Construire une knowledge base prend 3 jours dédiés. Elle vous fait gagner 4 à 5 jours sur chaque questionnaire suivant. La rentabilité est atteinte au deuxième questionnaire.
Pour le contexte certification, voir ISO 27001 SaaS B2B et SOC 2 Type II. Pour structurer la gouvernance qui rend ces réponses crédibles, voir Premier mois d'un RSSI externalisé.