Questionnaire sécurité fournisseur : ce que le site et le DNS répondent avant
le fournisseur

Le 22 mars 2022, le groupe Lapsus$ publie des captures d'écran d'une console d'administration Okta. L'intrusion, elle, remonte au mois de janvier : elle n'a pas visé Okta, mais Sitel, le prestataire à qui Okta avait confié une partie de son support client. Sitel fait analyser l'incident, le rapport de la société de forensique est achevé le 10 mars, et Okta n'en reçoit un résumé que le 17. Deux mois entre l'intrusion chez le sous-traitant et le moment où le donneur d'ordre a de quoi la qualifier. Okta annonce d'abord jusqu'à 366 clients potentiellement concernés, puis conclut, rapport complet en main, que deux l'ont réellement été. Personne ne doute que le contrat contenait une clause de notification d'incident, ni que Sitel avait rempli, quelque part, un questionnaire de sécurité fournisseur.

C'est le procès qu'on peut faire à l'exercice : un questionnaire de sécurité fournisseur produit un document, pas une garantie. Il n'est pas inutile pour autant, il structure la relation et fixe des engagements opposables. Mais entre le tableur renvoyé par le fournisseur et la réalité de ce qu'il expose sur Internet, il y a un écart que personne ne mesure jamais, alors qu'une partie de cet écart est publique et se constate sans rien demander à personne.

Ce qu'un questionnaire sécurité fournisseur couvre réellement

Les formats varient, du tableur maison de trente lignes aux référentiels normalisés comme le Consensus Assessments Initiative Questionnaire de la Cloud Security Alliance ou le SIG de Shared Assessments, qui dépassent allègrement les deux cents questions. Le fond, lui, tourne toujours autour des mêmes sept domaines.

L'organisation. Existe-t-il un responsable sécurité identifié, une politique de sécurité écrite et approuvée, une analyse de risques tenue à jour, un plan de continuité testé ? On cherche à savoir si la sécurité a un propriétaire, ou si elle est le passe-temps de l'administrateur système entre deux tickets.

L'hébergement et la localisation des données. Où tournent les machines, chez quel opérateur, sous quelle juridiction, avec quelles garanties de transfert hors Union européenne. C'est la partie où un acheteur mal informé confond le siège social du fournisseur avec l'emplacement physique de ses serveurs. Les deux n'ont rien à voir.

Le chiffrement. Données au repos, données en transit, gestion des clés. La question est presque toujours posée en oui/non, ce qui garantit une réponse en oui. Un fournisseur peut cocher "chiffrement en transit" en toute bonne foi tout en acceptant encore TLS 1.0 sur un vieux portail d'extranet.

La gestion des accès. Authentification multifacteur, revue périodique des habilitations, séparation des environnements, comptes d'administration, procédure de départ d'un salarié. C'est le domaine où les réponses sont les plus flatteuses et les écarts les plus fréquents, parce que le MFA "généralisé" oublie systématiquement deux ou trois accès techniques, ceux que fait remonter une vérification de la couverture MFA.

La sous-traitance en cascade. Le point le plus important et le plus mal traité. Votre fournisseur a lui-même des fournisseurs : hébergeur, CDN, prestataire de support, éditeur de la brique d'authentification, société de maintenance qui garde un accès distant. La chaîne descend plus loin qu'on ne l'imagine, et chaque maillon hérite d'une part de vos données. C'est le scénario Okta au mot près, et c'est aussi ce qui a rendu la vague MOVEit de 2023 si vaste : la BBC, British Airways et Boots n'utilisaient pas le logiciel de transfert de fichiers vulnérable, leur prestataire de paie Zellis, lui, l'utilisait.

La notification d'incident. Sous quel délai le fournisseur prévient, à partir de quel événement, avec quel niveau de détail, et à qui. La clause type dit "sans délai injustifié". Le calendrier Okta montre ce que cette formule vaut quand l'incident se produit deux étages plus bas dans la chaîne.

La réversibilité. Que se passe-t-il à la fin du contrat : format d'export des données, délai de mise à disposition, preuve de suppression, sort des sauvegardes, durée de conservation résiduelle. La question est posée dans un questionnaire sur trois, et c'est celle qui coûte le plus cher quand on découvre la réponse au moment de partir.

Le défaut de conception : personne ne vérifie

Un questionnaire de sécurité est une auto-évaluation. Le fournisseur rédige la copie et se note lui-même, dans un contexte où la mauvaise réponse coûte un contrat. L'incitation est claire, et elle ne pousse pas à la précision. Ce n'est même pas nécessairement de la mauvaise foi : la personne qui remplit le document est souvent commerciale ou juridique, elle recopie les réponses de la campagne précédente, et le décalage avec la réalité technique s'installe sans que quiconque mente sciemment.

Côté acheteur, le questionnaire revient rempli, il est classé, et il devient une pièce du dossier de conformité. La case cochée s'est transformée en preuve, exactement comme dans un outil GRC alimenté par ses propres déclarations. Le document produit alors une sensation de maîtrise qui décourage d'aller vérifier, alors qu'il n'a rien vérifié du tout. Un dossier fournisseur épais est parfois moins rassurant qu'un dossier mince accompagné de trois mesures externes.

Ce classement ne rend pas les niveaux bas inutiles. Une politique écrite et une clause de notification sont indispensables, ne serait-ce que pour avoir un recours. Leur valeur de preuve n'est pas la même, et empiler dix documents de niveau 0 ne fabrique jamais un niveau 3.

Ce que NIS2 impose sur la chaîne d'approvisionnement

La directive (UE) 2022/2555 a fait entrer le sujet dans le droit dur. Son article 21.2 (d) range la sécurité de la chaîne d'approvisionnement parmi les dix mesures minimales de gestion des risques, "y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs". L'article 21.3 va plus loin en précisant ce qu'il faut regarder : les vulnérabilités propres à chaque fournisseur direct, et la qualité globale de ses produits et de ses pratiques de cybersécurité, procédures de développement sécurisé comprises. Le cadre général de la directive est détaillé dans notre article sur la directive NIS2.

Le point central est celui de la responsabilité. NIS2 n'impose pas au fournisseur d'être conforme : elle impose à l'entité assujettie de gérer le risque que ce fournisseur lui fait porter. Externaliser un service n'externalise pas l'obligation, et l'article 20 place explicitement l'approbation et le suivi de ces mesures sur les organes de direction, qui peuvent en répondre. Dit autrement : le jour où un sous-traitant se fait vider, "il nous avait dit que c'était chiffré" ne sera pas une défense.

Le secteur financier a droit à un régime plus dur encore. Le règlement DORA consacre tout un volet aux prestataires tiers de services TIC : registre d'informations des contrats à l'article 28, clauses contractuelles obligatoires à l'article 30, et désignation par les autorités européennes de surveillance des prestataires jugés critiques, qui basculent alors sous supervision directe. On y revient dans le règlement DORA. La logique est la même que dans NIS2, en plus prescriptif : la dépendance à un tiers devient un objet réglementé en soi.

La portée réelle d'une certification jointe au dossier

La parade classique du fournisseur consiste à répondre au questionnaire en agrafant un certificat. C'est un vrai signal, un organisme tiers est passé et a regardé. Trois détails du document décident pourtant de ce qu'il vaut, et aucun ne figure sur la page de garde.

ISO/IEC 27001 : lisez le champ d'application

Un certificat ISO/IEC 27001 atteste qu'un système de management de la sécurité de l'information a été audité. Deux mentions comptent : le champ d'application, qui délimite ce qui a été audité, et la déclaration d'applicabilité, qui liste les mesures de l'annexe A retenues et, surtout, celles qui ont été écartées avec justification, ces mesures étant précisément celles que détaille ISO 27002 et ses 93 contrôles. Un périmètre peut se limiter à une entité juridique, à un site, à une ligne de service. Rien n'interdit qu'il laisse dehors la plateforme que vous achetez. La question à poser n'est donc pas "êtes-vous certifiés ?" mais "quel est le champ d'application exact du certificat, et le service qui traite nos données y figure-t-il ?".

Deuxième détail : la date. Le certificat porte un cycle de certification ISO 27001 de trois ans, avec des audits de surveillance intermédiaires. Un certificat en cours de validité ne dit rien de ce qui s'est passé le mois dernier, et la révision 2022 de la norme a rebattu l'annexe A, aujourd'hui organisée en 93 mesures réparties en quatre thèmes. Un document qui référence encore l'ancienne structure signale un dossier qui n'a pas été rouvert depuis longtemps.

SOC 2 : type I ou type II, et le carve-out

Un rapport SOC 2 de type I évalue la conception des contrôles à une date donnée. Un rapport de type II évalue leur fonctionnement effectif sur une période, généralement de trois à douze mois. La différence est considérable, et pourtant les deux se présentent sous le même nom dans une réponse de questionnaire. À vérifier ensuite : les critères couverts, puisque seule la sécurité est obligatoire et que disponibilité, confidentialité, intégrité de traitement et vie privée sont optionnelles ; puis la liste des exceptions relevées par l'auditeur, qui figure dans le rapport et que personne ne lit.

Reste le traitement des sous-traitants. Un rapport SOC 2 peut traiter les sous-traitants selon la méthode dite carve-out, qui les exclut du périmètre audité. Le rapport reste valable et honnête, il indique simplement que les contrôles de ces tiers n'ont pas été examinés. Vous tenez donc une attestation sur un fournisseur, avec un trou à l'endroit de la sous-traitance en cascade, c'est-à-dire à l'endroit du scénario Okta.

Ce qui se mesure de l'extérieur, sans rien demander

Une partie des réponses d'un questionnaire porte sur des faits publics. Pas publics au sens où quelqu'un les aurait publiés, publics au sens où un serveur les annonce à quiconque s'y connecte. Une version de TLS, une suite cryptographique, une date d'expiration de certificat, un en-tête de réponse, un nom de sous-domaine dans un journal de Certificate Transparency : ce sont des éléments que le fournisseur émet volontairement, en clair, vers tout Internet. Les observer ne demande aucune autorisation, et ne ressemble en rien à un test d'intrusion.

L'exercice n'a pas pour objet de prendre le fournisseur en défaut pour le plaisir. Une déclaration et une mesure qui se contredisent produisent une question précise, à laquelle on ne peut plus répondre par une case. "Vous déclarez chiffrer les flux, or ce point d'entrée accepte encore TLS 1.0 et sert un certificat expiré depuis onze jours : est-il dans le périmètre de votre politique ?" appelle soit une correction, soit l'aveu que l'actif avait été oublié. Les deux réponses valent plus que le questionnaire entier.

Ce que la mesure externe voit dépend directement de la qualité de l'inventaire qu'on sait construire, sujet à part entière traité dans la découverte d'actifs exposés, et qui constitue le socle de la gestion de la surface d'attaque externe. Sur le volet code tiers, elle recoupe ce qu'un SBOM documente de l'intérieur, avec une différence de nature : le SBOMinventorie ce que le fournisseur déclare compiler, la mesure externe constate ce qu'il sert réellement.

La mesure : ce que 704 organisations répondent sans qu'on leur demande

Pour savoir ce que cette lecture passive donne en vrai, je l'ai appliquée le 6 octobre 2026 à 704 organisations qui sont, chacune, le fournisseur ou le client de quelqu'un : les 119 sociétés du SBF 120 retenues, 65 universités, 488 communes de plus de 20 000 habitants et 32 CHU et CHR. Une requête vers la page d'accueil du site officiel, quelques requêtes DNS à la racine du domaine, rien d'autre. Cinq réponses de questionnaire en sortent sans que personne ait eu à les rédiger.

Chaque colonne répond à une question qu'on trouve dans presque tous les questionnaires. "Vos composants web sont-ils maintenus à jour ?" : la page d'accueil charge une bibliothèque JavaScript dans une version à vulnérabilité connue selon la base retire.js, lue dans l'URL ou le code du script (sans vérification d'exploitabilité), sur 7,3 % des pages du SBF 120 et 19,6 % des pages d'universités. "Réduisez-vous les informations techniques exposées ?" : une version de serveur ou de langage s'affiche dans les en-têtes HTTP de 37,5 % des pages d'universités. "Maîtrisez-vous le code tiers chargé par vos applications ?" : sur 1 177 balises de script chargées depuis un domaine tiers, tous panels confondus, 39 portent un attribut d'intégrité (3,3 %).

Les deux dernières colonnes parlent de vos sous-traitants de rang deux, ceux que le questionnaire demande de déclarer et qu'on oublie le plus. Un enregistrement SPF liste les services autorisés à envoyer des mails au nom du domaine ; les jetons de vérification du DNS listent les services SaaS auxquels le domaine a été rattaché, 8 en médiane au SBF 120. Si votre fournisseur déclare deux prestataires de messagerie et que son SPF en autorise six, vous avez votre question de relance.

Ces chiffres ne notent personne, et ce n'est pas leur rôle. Une page d'accueil n'est pas tout le périmètre d'un fournisseur, une version annoncée ancienne peut avoir été corrigée par la distribution sans changer de numéro, et seul le HTML statique est lu, ce qui fait des scripts tiers un minorant. Ce qu'ils montrent, c'est que la contrepartie observable existe pour une bonne part du questionnaire, qu'elle varie fortement d'un type d'organisation à l'autre, et qu'elle tient en quelques requêtes.

Les questions qui discriminent, et leur contrepartie observable

Une bonne question de questionnaire a une propriété simple : elle ne peut pas recevoir la même réponse d'un fournisseur sérieux et d'un fournisseur approximatif. "Chiffrez-vous les données ?" échoue à ce test, tout le monde répond oui. Une question qui demande un chiffre, une liste ou une date, elle, oblige à aller chercher l'information, et l'absence de réponse est déjà une réponse.

Cette dernière ligne montre la limite de l'exercice. La mesure externe ne voit que la surface exposée. Elle ne dira jamais si les sauvegardes sont restaurées régulièrement, si les habilitations sont revues, si le plan de continuité a été joué, si le développeur parti en mars a encore une clé SSH valide. Ces éléments-là ne se vérifient que par un audit sur place ou par des clauses contractuelles avec droit d'audit, et il faut assumer qu'on les prend sur parole le reste du temps.

TPRM : la gestion du risque tiers, au-delà du questionnaire

Le questionnaire n'est qu'une étape d'un ensemble plus large, la gestion des risques liés aux tiers, ou TPRM (third party risk management) : identifier ses fournisseurs, les classer par criticité, contractualiser, évaluer, puis surveiller dans la durée et organiser la sortie. Un programme qui se réduit à envoyer un formulaire une fois par an n'en couvre qu'un maillon. Trois réflexes le rendent tenable.

Le premier est de trier. Traiter tous les fournisseurs avec le même questionnaire de deux cents lignes est la meilleure façon de n'en évaluer aucun sérieusement. Le prestataire qui héberge la base clients et celui qui livre les corbeilles de fruits n'appellent pas le même effort. Le critère de tri n'est pas le montant du contrat mais l'accès : quelles données, quel niveau de privilège, quelle capacité à interrompre l'activité. Trois niveaux suffisent, et le niveau haut doit rester assez court pour être réévalué pour de vrai.

Le second est de désynchroniser les rythmes. Le questionnaire annuel garde du sens pour l'organisation, les contrats et les certifications, qui bougent lentement. La surface exposée, elle, change en jours : un sous-domaine part en production le mardi, un certificat expire le jeudi, un nouveau script tiers arrive sur le portail client le vendredi. Faire porter les deux par le même cycle annuel, c'est accepter d'être aveugle onze mois sur douze sur la partie qui bouge. La partie mesurable se surveille en continu, et la réévaluation complète se déclenche sur événement : incident public, rachat, changement d'hébergeur, apparition d'un sous-traitant non déclaré.

Le troisième est d'écrire ce qui se passe en cas d'écart. Un programme de gestion des risques liés aux tiers qui n'a jamais conduit à refuser un fournisseur, à imposer un délai de correction ou à activer une clause se réduit à une collection de fichiers. La question à se poser avant d'envoyer le premier questionnaire est simple : qu'est-ce qu'on fait si la réponse est mauvaise ? Si personne ne sait, le questionnaire ne sert qu'à documenter qu'on avait demandé.

Une compromission qui arrive par un tiers reste une attaque de la chaîne d'approvisionnement, qu'elle emprunte une dépendance logicielle ou un prestataire de support. Le questionnaire s'occupe du second cas et ignore complètement le premier : aucun formulaire ne vous dira quel paquet npm compromis s'exécute dans le navigateur de vos utilisateurs via le widget d'un fournisseur.

À retenir

Le questionnaire restera, il est utile et souvent obligatoire. Ce qui manque, à côté, c'est la seule contrepartie qu'un fournisseur ne peut pas rédiger lui-même : ce que ses serveurs racontent à Internet. C'est ce que fait le module sécurité de la chaîne d'approvisionnement de la plateforme EASM d'own2pwn : inventaire de la surface exposée, provenance des dépendances tierces chargées sur les pages, notation du risque et alerte au changement. Pour cadrer un périmètre ou discuter d'un cas précis, la page contact mène directement à un pentester.

Questions fréquentes sur le questionnaire sécurité fournisseur