Un tableur de 200 lignes
bloque votre signature.
Le contrat est négocié, le client est convaincu, et la sécurité envoie son questionnaire. Chiffrement, gestion des accès, sauvegardes, sous-traitants, réponse à incident. Vous savez que votre produit est correct, mais vous ne savez pas le prouver — et vous ne voulez pas cocher des cases au hasard.
Pourquoi ces questionnaires se multiplient.
Les grandes organisations sont tenues de maîtriser la sécurité de leur chaîne de fournisseurs. Quand elles achètent un logiciel, elles héritent d'une partie de son risque : si votre application est compromise, leurs données le sont aussi. Le questionnaire est l'instrument par lequel elles transfèrent une part de cette responsabilité — contractuellement.
Ce mouvement s'amplifie avec les obligations réglementaires qui pèsent sur les grands comptes, notamment en matière de sécurité de la chaîne d'approvisionnement. Résultat : des entreprises qui ne sont soumises à aucune obligation directe reçoivent des exigences par ricochet, via une clause contractuelle. Voir notre point factuel sur NIS 2.
L'erreur qui coûte cher : répondre oui partout
La tentation est compréhensible : le contrat est en jeu, et chaque « non » ressemble à un motif de refus. C'est pourtant l'approche la plus risquée, pour trois raisons.
- Vos réponses vous engagent. Le questionnaire est souvent annexé au contrat. Affirmer une mesure inexistante, c'est créer un manquement contractuel activable le jour d'un incident — au pire moment.
- Les équipes sécurité lisent des dizaines de questionnaires. Un formulaire sans aucune réserve est un signal d'alerte, pas un gage de sérieux. Les questions de contrôle croisées font ressortir les incohérences.
- La preuve est de plus en plus demandée. Rapport d'audit, politique d'accès, preuve de restauration de sauvegarde : ce qui n'était qu'une déclaration devient vérifiable.
Un « non, prévu pour le deuxième trimestre » passe presque toujours. Un « oui » démenti six mois plus tard par un incident ne passe jamais.
Ce qui est réellement demandé, et comment y répondre
Contrôle des accès
- Qui peut accéder aux données de production, et comment cet accès est-il retiré au départ d'une personne ?
- L'authentification à plusieurs facteurs est-elle en place sur les comptes d'administration ?
- Existe-t-il des comptes partagés — la réponse honnête est souvent oui, et elle se corrige vite.
Protection des données
- Chiffrement en transit et au repos : ce qui est réellement chiffré, et ce qui ne l'est pas.
- Localisation des données et liste des sous-traitants qui y accèdent.
- Durées de conservation et procédure de suppression sur demande.
Développement et vulnérabilités
- Comment une vulnérabilité dans une dépendance est-elle détectée puis corrigée, et en combien de temps ?
- Le code est-il relu avant d'aller en production ?
- Quand a eu lieu le dernier audit de sécurité, et par qui ?
Continuité et incidents
- Les sauvegardes existent-elles, et ont-elles déjà été restaurées pour de vrai ?
- Sous quel délai vous engagez-vous à notifier un incident au client ?
- Qui est joignable, et par quel canal, en cas de problème un dimanche ?
Ce qu'Avisers apporte — et ce qui reste de votre côté
L'audit établit l'état technique réel de votre application : ce qui est vrai, ce qui ne l'est pas encore, et ce qui peut être corrigé rapidement. Vous disposez alors d'éléments factuels pour répondre, plus un rapport d'audit indépendant et daté — qui est précisément le type de preuve que réclament les équipes sécurité.
En revanche, Avisers ne remplit pas le questionnaire à votre place : ces réponses vous engagent contractuellement, elles doivent rester les vôtres. Notre rôle est de faire en sorte que chacune soit vérifiable.
Le périmètre technique correspond à l'audit de code et de sécurité. Si votre application a été construite avec des outils d'IA, voir l'audit sécurité Lovable et Supabase.
Questionnaire de sécurité — questions fréquentes
Que faire si je ne peux pas répondre oui à une question ?
Répondre non, en indiquant ce qui est prévu et à quelle échéance. Un service achats ou une équipe sécurité lit des dizaines de questionnaires : les réponses uniformément positives éveillent la méfiance, alors qu'un non assorti d'un plan daté est perçu comme un signe de maîtrise. Cocher une case qu'on ne peut pas justifier crée en revanche un engagement contractuel que l'on ne tiendra pas.
Faut-il être certifié ISO 27001 pour répondre ?
Non dans la majorité des cas. La certification simplifie l'échange parce qu'elle répond d'un coup à de nombreuses questions, mais elle n'est presque jamais une condition absolue pour un fournisseur de petite taille. Ce qui est attendu est une réponse honnête, documentée et cohérente avec la réalité technique. Voir notre page sur ISO 27001.
Le client peut-il demander une preuve de ce qu'on affirme ?
Oui, et c'est de plus en plus fréquent : rapport d'audit récent, politique de gestion des accès, preuve de sauvegardes testées, ou description du processus de correction des vulnérabilités. C'est à ce moment que les réponses données sans fondement deviennent un problème.
Combien de temps faut-il pour traiter un questionnaire ?
Le remplissage lui-même prend quelques heures. Ce qui prend du temps, c'est de vérifier que ce que l'on s'apprête à écrire est vrai, et de corriger les points qui ne le sont pas encore. C'est cette partie qui détermine le délai réel.
Avisers remplit-il le questionnaire à ma place ?
Non : les réponses vous engagent contractuellement, elles doivent donc être les vôtres. Avisers établit l'état technique réel de votre application et vous fournit les éléments factuels correspondants, afin que chaque réponse soit vérifiable. La rédaction finale et l'engagement restent de votre côté.
Une signature bloquée
par un questionnaire ?
30 minutes pour regarder les questions qui coincent et déterminer ce qui peut être corrigé avant votre échéance.
→ Demander un devis