Questionnaire de sécurité pour créateur de sites : 50 questions à poser aux fournisseurs

Un questionnaire de sécurité écrit pour les créateurs de sites et les plateformes web, pas pour le SaaS générique : cloisonnement entre sites clients, contrôle de la publication, domaines et DNS orphelins, scripts tiers, données des formulaires, fonctionnalités d'IA, e-mails envoyés en votre nom, journaux, incidents et sortie. Avec ce à quoi ressemble une bonne réponse, comment pondérer les preuves, et nos propres réponses lorsqu'elles sont vraies.

La plupart des questionnaires de sécurité ont été écrits pour des logiciels qui stockent vos données : paie, CRM, gestion de tickets. Une plateforme web est un tout autre animal. Sa fonction principale est de publier des contenus sur tout Internet en votre nom, souvent sur des domaines qui vous appartiennent, souvent modifiés par des personnes extérieures à votre organisation, et de plus en plus avec une IA qui écrit le premier jet. Les risques qui comptent portent sur qui peut mettre quoi sous les yeux du public, et sur ce que la plateforme fait des données que les visiteurs saisissent dans vos formulaires. Ce questionnaire couvre ces risques. Utilisez-le en complément de votre questionnaire habituel, pas à sa place.

Commencez par les questionnaires standard, puis ajoutez celui-ci

Plusieurs questionnaires gratuits ou largement utilisés existent déjà, et un fournisseur sérieux aura répondu à au moins l'un d'eux :

CAIQ de la Cloud Security Alliance : un tableur oui/non associé à sa Cloud Controls Matrix. La version actuelle est la v4.1. C'est une auto-évaluation, pas une certification.
HECVAT d'EDUCAUSE, utilisé dans tout l'enseignement supérieur. La version 4 a fusionné les anciennes versions complète, allégée et sur site en un seul fichier, et ajouté des questions sur la confidentialité et l'IA. EDUCAUSE le met gratuitement à la disposition des établissements d'enseignement supérieur et des fournisseurs qui leur vendent.
OWASP ASVS, l'Application Security Verification Standard. C'est une liste d'exigences plutôt qu'un questionnaire ; la version 5.0.0 a été publiée le 30 mai 2025. Utile pour demander comment le fournisseur vérifie sa propre application.

Aucun d'eux ne demande ce qui se passe quand le sous-compte d'un client publie une page sur votre domaine sans approbation, ou quand un domaine que vous avez abandonné pointe encore vers le fournisseur. Les questions ci-dessous le font. Elles sont numérotées pour que vous puissiez y faire référence dans un contrat ou une grille de notation.

Décidez du niveau d'exigence avant d'envoyer quoi que ce soit

Cinquante questions pour un site vitrine font perdre une semaine à tout le monde ; cinq pour un site qui reçoit des demandes liées à la santé relèvent de la négligence. Choisissez les sections selon ce que les sites contiendront réellement :

Ce que feront les sites	Sections à envoyer
Informations publiques uniquement, sans formulaires ni connexions	A, C, D, E, J, K
Formulaires de contact ou de demande	Ajoutez F et H
Des tiers (clients, franchisés, services) modifient leurs propres sites	Ajoutez B et I
L'IA génère ou modifie des contenus	Ajoutez G
Les formulaires collectent des données sensibles (santé, finances, informations sur des enfants)	Toutes les sections, plus votre questionnaire standard complet et une analyse juridique pour savoir si la plateforme devrait détenir ces données

Le questionnaire

Sous chaque section, une note sur ce à quoi ressemble une bonne réponse. Copiez les questions ; gardez les notes pour la personne qui évaluera les réponses.

A. Cloisonnement entre sites et entre clients

Nos sites et nos données sont-ils séparés logiquement de ceux des autres clients sur l'infrastructure partagée ? Comment ce cloisonnement est-il appliqué : dans l'application, dans la base de données, ou les deux ?
Si nous gérons plusieurs comptes clients ou de services sous notre organisation, l'un d'eux peut-il voir ou modifier les sites, envois de formulaires ou réglages d'un autre ?
Votre équipe support peut-elle voir ou modifier nos sites ? Dans quelles conditions, et cet accès est-il enregistré ?
Les sites publiés partagent-ils un domaine ou des cookies avec l'application d'édition ?

Bonne réponse : précise sur le mécanisme (par exemple, des règles d'accès au niveau des lignes dans la base de données en plus des contrôles dans l'application), et honnête sur le fait que l'accès du support existe avec des limites, plutôt que de prétendre que personne ne peut jamais rien voir.

B. Comptes, rôles et départs de personnel

Quels rôles existent, et que peut faire chacun ? Merci d'envoyer la liste plutôt que de la décrire.
Pouvons-nous restreindre ce que chaque client ou sous-compte est autorisé à faire (publier, connecter un domaine, ajouter des scripts, voir le code) ?
Quelles méthodes de connexion sont prises en charge pour notre personnel et pour nos clients ? L'authentification multifacteur est-elle disponible, et pouvons-nous l'imposer ?
Quand quelqu'un s'en va, en combien de temps son accès est-il supprimé, et la suppression s'applique-t-elle à tous les sites à la fois ?
Les sessions sont-elles fermées quand un mot de passe est changé ou un compte supprimé ?

Bonne réponse : une liste courte et fixe de rôles que vous pouvez vérifier lors d'une démo. Méfiez-vous des « droits entièrement personnalisables » que personne ne peut vous montrer.

C. Le circuit de publication

Qui peut mettre une modification en ligne sur Internet ? Pouvons-nous exiger une approbation avant la publication d'un site ou d'une modification ?
Existe-t-il un historique de qui a publié quoi et quand ?
Pouvons-nous revenir à une version précédente d'un site, et jusqu'à quand ?
Un sous-compte peut-il publier sur un domaine qui nous appartient sans notre intervention ?
Qu'est-ce qui empêche quelqu'un de publier une page qui usurpe l'identité d'une autre organisation, ou un formulaire de connexion qui collecte des mots de passe ?

Bonne réponse : décrit le contrôle réel, limites comprises. « Approbation unique par le propriétaire du compte » est une très bonne réponse si elle est vraie ; des « circuits de validation configurables à plusieurs niveaux » doivent être démontrés, pas acceptés sur parole.

D. Domaines, certificats et DNS

Comment vérifiez-vous que des domaines personnalisés nous appartiennent avant d'y rattacher un site ?
Comment les certificats TLS sont-ils émis et renouvelés, et que se passe-t-il si le renouvellement échoue ?
Quand nous retirons un domaine ou fermons un site, qu'advient-il des enregistrements DNS qui pointent encore vers vous ? Quelqu'un d'autre pourrait-il revendiquer ce domaine sur votre plateforme ?
Au nom de qui le domaine est-il enregistré quand vous l'enregistrez pour nous ?

Bonne réponse : la question 17 est celle à laquelle la plupart des fournisseurs n'ont pas réfléchi. Un domaine qui pointe encore vers une plateforme après la disparition du site peut être récupéré par un autre client de cette plateforme si celle-ci ne vérifie pas la propriété. Vous voulez entendre comment la propriété est revérifiée, pas seulement qu'elle est vérifiée une fois.

E. Scripts et intégrations tiers

Qui peut ajouter des scripts, des balises de suivi ou des widgets intégrés à un site ? Pouvons-nous le restreindre par compte ?
La plateforme ajoute-t-elle elle-même des scripts tiers aux sites publiés ? Lesquels, et pouvons-nous les retirer ?
Prenez-vous en charge une Content Security Policy sur les sites publiés, et pouvons-nous définir la nôtre ?
Si un script tiers est compromis sur un site, pourrait-il affecter d'autres sites de notre organisation ?

Bonne réponse : une liste. Les scripts ajoutés par la plateforme sur votre site public sont autant votre problème d'accessibilité, de confidentialité et de performance que le leur.

F. Formulaires et données envoyées par les visiteurs

Où les envois de formulaires sont-ils stockés, et pendant combien de temps ?
Qui peut voir les envois : notre personnel, nos clients, votre personnel ?
Les envois peuvent-ils être transmis directement à nos propres systèmes au lieu d'être stockés chez vous ?
Pouvons-nous exporter et supprimer les envois nous-mêmes ?
De quelle protection contre le spam et les abus les formulaires disposent-ils, et implique-t-elle un autre tiers ?
Empêchez-vous ou déconseillez-vous la collecte de catégories de données sensibles dans des formulaires ordinaires ?

G. Fonctionnalités d'IA

Quel(s) fournisseur(s) d'IA traite(nt) nos instructions, nos contenus et nos fichiers téléversés ?
Nos contenus, ou les données de nos visiteurs, servent-ils à entraîner des modèles ? Indiquez-nous les conditions du fournisseur qui le précisent.
Les envois de formulaires ou d'autres données de visiteurs sont-ils parfois transmis au fournisseur d'IA ?
Des modifications faites par l'IA peuvent-elles être publiées sans qu'un humain les voie ? Pouvons-nous exiger une approbation ?
Pouvons-nous désactiver les fonctionnalités d'IA pour certains comptes ?

Bonne réponse : nomme le fournisseur et renvoie à ses conditions. « Notre IA propriétaire » sans modèle ni conditions nommés est une raison de reposer la question.

H. E-mails envoyés en notre nom

Quels e-mails la plateforme envoie-t-elle à nos clients ou utilisateurs, et depuis quelle adresse ?
Pouvons-nous envoyer depuis notre propre domaine ? Quels enregistrements DNS devons-nous ajouter, et couvrent-ils l'alignement SPF, DKIM et DMARC ?
Si nous ne configurons pas notre propre domaine, que verront les destinataires dans le champ « De » et où iront les réponses ?
Les e-mails de type marketing comportent-ils un lien de désinscription fonctionnel, et est-il appliqué automatiquement ?

I. Journaux et traces

Quelles actions sont enregistrées dans un journal d'audit, et qui peut le consulter ?
Combien de temps les journaux sont-ils conservés ? Pouvons-nous les exporter ?
Journalisez-vous les accès de votre propre personnel à nos données ?
Si nous recevons une demande d'accès aux documents publics ou une obligation de conservation légale, que pouvez-vous fournir, et en combien de temps ?

Bonne réponse : un vrai écran avec de vraies entrées, plus une durée de conservation par écrit. Si le fournisseur ne peut pas indiquer de durée de conservation, prévoyez d'exporter vous-même les journaux à intervalles réguliers.

J. Vulnérabilités et incidents

Comment les chercheurs vous signalent-ils une vulnérabilité ? Publiez-vous un fichier security.txt ?
Comment les vulnérabilités de votre plateforme et de ses dépendances sont-elles détectées, priorisées et corrigées ?
Commandez-vous des tests d'intrusion indépendants ? Pouvons-nous voir un résumé, sa date et son périmètre ?
Dans quel délai nous informerez-vous d'un incident touchant nos données, par quel canal, et ce délai figure-t-il dans le contrat ?
Qui sont vos sous-traitants, et comment nous informez-vous de leurs changements ?

Bonne réponse : un fichier security.txt est défini par la RFC 9116. Il se trouve à l'adresse /.well-known/security.txt et doit contenir au moins un champ Contact et un champ Expires : vous pouvez donc vérifier sa présence vous-même en dix secondes. Sur les délais en cas d'incident : si vous êtes responsable de traitement au sens du RGPD européen, le RGPD vous donne, en tant que responsable de traitement, 72 heures si possible pour notifier l'autorité, mais n'impose au sous-traitant que de vous prévenir « dans les meilleurs délais ». C'est pourquoi un nombre d'heures a sa place dans le contrat.

K. La sortie

Pouvons-nous exporter chaque site, code, médias et données de formulaires compris, sans votre aide ?
Qu'advient-il de nos sites, domaines et données le jour où le contrat prend fin, et trente jours plus tard ?
Confirmerez-vous la suppression par écrit ?
Un autre prestataire pourrait-il faire tourner les sites exportés sans votre plateforme ?

Notre guide du plan de sortie d'un prestataire transforme ces questions en clauses contractuelles.

Pondérez les preuves, pas les adjectifs

Deux fournisseurs peuvent tous deux répondre « oui » à la question 10 et vouloir dire des choses très différentes. Notez chaque réponse selon la preuve la plus solide qui l'étaye :

Niveau	Preuve	Poids à accorder
0	Une affirmation sur une page marketing, ou un « oui » sans détail	Aucun tant qu'elle n'est pas étayée
1	Une réponse écrite précise du fournisseur	Un peu ; elle peut être opposée dans un contrat
2	De la documentation : politique, note d'architecture, article d'aide	Davantage, si elle est datée et précise
3	Montré en fonctionnement lors d'une démo en direct, à votre demande	Élevé pour les fonctionnalités ; en dit peu sur les processus internes
4	Un rapport ou certificat indépendant, en cours de validité, dont le périmètre couvre le produit que vous achetez	Le plus élevé pour les contrôles internes ; lisez le périmètre

Pour une plateforme web, le niveau 3 compte plus que les acheteurs ne le pensent. Approbation, rôles, vérification des domaines, export et journaux d'audit sont autant d'éléments que vous pouvez demander à voir en vingt minutes. Demandez.

Signaux d'alerte

Des certifications décrites comme « en cours », « alignées sur » ou « basées sur ». Une certification obtenue est obtenue ; le reste est un projet.
Un chiffre de disponibilité sur le site web que le contrat ne reprend pas.
Le refus de nommer les sous-traitants ou le fournisseur d'IA.
« Nous ne pouvons pas exporter le code, mais nous pouvons exporter vos contenus » alors que vous avez payé le design.
Une longue réponse à une question que vous n'avez pas posée, au lieu d'une réponse courte à celle que vous avez posée.

Les réponses de We.Inc, là où nous pouvons répondre

Nous préférons répondre honnêtement à moins de questions que vaguement à toutes. Voici les réponses que nous pouvons donner sur cette page, chacune liée à quelque chose que vous pouvez voir dans le produit. Pour tout le reste, interrogez-nous par écrit lors d'une démo et jugez la réponse selon les niveaux de preuve ci-dessus.

Question	Notre réponse
5. Rôles	Un petit ensemble fixe de rôles d'équipe (propriétaire, administrateur et membre). Nous ne proposons pas de rôles personnalisés.
6, 13. Restrictions par compte	Pour chaque compte client, vous choisissez s'il peut publier, connecter son propre domaine, voir le code, et utiliser le blog, la boutique, les formulaires et les réglages SEO. Un réglage par défaut à l'échelle de la marque s'applique, sauf si vous le modifiez.
10. Approbation avant publication	Oui : « la publication nécessite mon approbation » peut être le réglage par défaut pour tous les clients ou être défini client par client. Il s'agit d'une seule étape d'approbation par votre équipe, pas d'un circuit à plusieurs niveaux.
11, 38. Journal d'audit	Un journal d'audit des actions de l'organisation, indiquant la date, l'utilisateur, l'action, l'enregistrement concerné et les détails. Nous ne publions ni durée de conservation ni garantie d'inaltérabilité.
15. Domaines personnalisés	Votre portail et chaque site client peuvent fonctionner sur des domaines qui vous appartiennent.
35, 36. E-mails en votre nom	Les e-mails adressés à vos clients portent le nom de votre marque, votre logo et votre adresse de support pour les réponses. Tant que votre propre domaine d'envoi n'est pas vérifié, ils partent de notre adresse d'envoi ; une fois les enregistrements DNS ajoutés et vérifiés, ils partent de votre domaine.
47, 50. Export	Le code de chaque site peut être téléchargé en ZIP ou synchronisé avec un dépôt GitHub, et fonctionne sans notre plateforme.
Certifications (issues de votre questionnaire standard)	Nous ne revendiquons ni SOC 2, ni ISO 27001, ni certification similaire, et nous ne publions ni chiffre de disponibilité contractuel ni choix de région pour les données.
Accessibilité	Les sites sont créés et modifiés par IA. Votre équipe doit tester les pages publiées ; nous ne revendiquons la conformité à aucune norme d'accessibilité.

Panneau d'équipe listant trois membres avec les badges Admin et Member et un formulaire pour inviter un nouveau membre par e-mail avec un rôle choisi — Les rôles d'équipe sur la marque de démonstration. Les personnes sont invitées par e-mail avec un rôle, et le formulaire indique ce que ce rôle permet (ici, un Designer ouvre et modifie le site de n'importe quel client mais n'a pas accès à la facturation).

Un compte client ouvert dans le gestionnaire de clients, avec des interrupteurs pour les réglages SEO et une option La publication nécessite mon approbation, plus des notes, des étiquettes et des commandes de pause ou de suppression — Des interrupteurs par client, dont l'approbation avant publication, et les commandes pour mettre en pause ou supprimer un client.

Tableau du journal d'audit avec deux entrées Updated client details, indiquant la date, l'identifiant de l'utilisateur, l'action, la fiche client concernée et les champs modifiés — Le journal d'audit avec deux vraies entrées issues de la modification d'un client. La colonne utilisateur affiche actuellement un identifiant de compte plutôt qu'un nom.

Panneau de code dans l'éditeur de site affichant l'arborescence du projet, un fichier source de composant et un bouton Download — Le panneau de code : chaque site est du vrai code qui peut être téléchargé.

Fenêtre d'export du projet avec des onglets GitHub, ZIP, Vercel et Domain, un champ de nom de dépôt et une option de dépôt privé — Exporter un site vers votre propre dépôt GitHub ou sous forme de fichier ZIP.

Envoyez-nous votre questionnaire, ou celui-ci, avant une démo de 30 minutes, et nous vous montrerons les éléments ci-dessus en direct pendant l'appel. Pour le processus d'achat dans son ensemble, consultez la liste de contrôle pour l'achat d'une plateforme web.

Sources

Dernière vérification le 2026-10-25.

Cloud Security Alliance, Cloud Controls Matrix and CAIQ v4.1.
EDUCAUSE, Higher Education Community Vendor Assessment Toolkit (HECVAT) et HECVAT 4: Better than Ever.
OWASP, Application Security Verification Standard (5.0.0, 30 mai 2025).
IETF, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure.
RGPD, article 33, notification d'une violation de données à caractère personnel.

Ce questionnaire fournit des informations générales, pas un conseil juridique ou de sécurité. Adaptez-le à vos propres obligations avec vos équipes sécurité et juridique.

Questions fréquentes

Ai-je besoin d'un questionnaire de sécurité distinct pour un créateur de sites ?

Utilisez votre questionnaire standard (CAIQ, HECVAT ou le vôtre) et ajoutez des questions propres aux sites web. Les questionnaires standard demandent rarement qui peut publier sur vos domaines, ce qu'il advient du DNS après la suppression d'un site, quels scripts la plateforme ajoute aux pages publiques, ou ce que les fonctionnalités d'IA font de vos contenus.

Quelle est la question de sécurité web la plus souvent oubliée ?

Ce qu'il advient des domaines qui pointent encore vers la plateforme après la fermeture d'un site. Si la plateforme ne revérifie pas la propriété, un autre client pourrait rattacher un site à ce domaine. Demandez comment la propriété est vérifiée puis revérifiée.

Comment noter les réponses des fournisseurs ?

Selon la preuve la plus solide derrière chaque réponse : une affirmation marketing ne compte pour rien, une réponse écrite un peu, une documentation davantage, une démonstration en direct beaucoup pour les fonctionnalités du produit, et un rapport indépendant en cours de validité au bon périmètre le plus pour les contrôles internes.

We.Inc détient-il des certifications de sécurité ?

Nous ne revendiquons ni SOC 2, ni ISO 27001, ni certification similaire. Nous pouvons montrer en direct lors d'une démo les rôles, les restrictions par client, l'approbation avant publication, le journal d'audit, les domaines personnalisés et l'export du code, et répondre par écrit au reste de votre questionnaire.