Rapport d'audit · Projet A

Comment lire ce rapport

À corriger avant tout

Un problème qui expose dès maintenant votre application ou vos utilisateurs.

Corrigez-le avant d'ouvrir l'application à de nouveaux utilisateurs, idéalement cette semaine.

À corriger ou à surveiller

Un point faible qui n'est pas urgent, mais qui peut le devenir avec le temps ou le trafic.

Planifiez la correction dans les prochaines semaines, ou mettez en place la surveillance proposée.

Ce qui tient

Une bonne pratique déjà en place, que l'audit a vérifiée.

Rien à faire, sinon la conserver lors des prochaines modifications.

L’essentiel en une page

4 À corriger avant tout

17 À corriger ou à surveiller

6 Ce qui tient

Puis-je ouvrir mon application à de nouveaux utilisateurs ?

Pas en l'état. Le site fonctionne et repose sur de bonnes bases : connexion chiffrée, pare-feu actif, formulaires protégés contre les envois en masse. Mais deux problèmes l'exposent dès aujourd'hui, et le site est déjà en ligne.

Une fois les deux points rouges de sécurité corrigés, ce qui demande quelques heures avec les prompts fournis, vous pouvez continuer à accueillir des visiteurs sereinement. La partie accessibilité et RGPD ajoute deux points rouges, plus simples : le formulaire de contact inutilisable au lecteur d'écran en cas d'erreur, et la police de caractères chargée chez Google. Les points orange se planifient ensuite, sans urgence.

Par où commencer

A-01
Le framework du site a une faille critique connue
Une faille publique, recherchée automatiquement par des robots. Une simple mise à jour suffit.
A-02
La clé du service d'e-mails est visible par tous les visiteurs
N'importe qui peut envoyer des e-mails en votre nom. Il faut changer la clé, pas seulement la déplacer.
A-04
Aucune limite de taille sur les messages du formulaire de contact
Le moyen le plus simple de faire grimper votre facture et de noyer vos vrais prospects.
ACC-01
Le bouton d'envoi du formulaire reste grisé sans dire pourquoi, et les erreurs ne sont pas lues
Le formulaire est le seul moyen de vous contacter : une personne aveugle qui fait une erreur ne peut pas envoyer sa demande.

Comment l’audit a été mené

L'audit combine la lecture du code par un développeur et quatre outils professionnels, utilisés par les équipes de sécurité des grandes entreprises. Les outils repèrent vite ce qui est connu ; la lecture humaine trie leurs résultats, écarte les fausses alertes et trouve ce qu'ils ne savent pas voir.

Les tests sur le site en marche ont été faits sur une version de test, jamais sur le site de production, et sans rien casser.

Analyse des dépendances

Liste tous les composants utilisés par le site et les compare aux bases de failles publiques. Repère aussi les clés secrètes oubliées dans le code.

Analyse du code

Relit le code ligne par ligne à la recherche de bugs, de failles et de code fragile, comme le ferait un relecteur très rigoureux.

Test du site en marche

Visite le site comme un internaute, puis examine les réponses du serveur : protections du navigateur, cookies, informations qui fuient.

Recherche de failles connues

Essaie plusieurs milliers de tests ciblés sur des failles et des erreurs de configuration connues, comme le font les robots des attaquants.

Ce que l’audit a trouvé

À corriger avant tout 2

À corriger avant tout A-01 · Composants et dépendances

Le framework du site a une faille critique connue

Ce que c’est: Votre site repose sur Next.js, le framework qui construit les pages. La version installée (15.5.19) contient plusieurs failles publiées, dont deux qui permettent, dans certaines conditions, d'exécuter du code sur le serveur sans être connecté. Elles passent par l'outil qui redimensionne les images du site.
Pourquoi c’est important: Ce type de faille est recherché automatiquement par des robots dès qu'elle est publiée. Si elle est exploitable sur votre configuration, un inconnu peut prendre la main sur le serveur qui affiche votre site : modifier les pages, lire les variables secrètes, ou se servir du serveur pour attaquer d'autres sites.
Comment corriger: Mettre à jour Next.js vers la version 15.5.28 ou plus récente, puis redéployer. La correction ne change pas votre code : c'est une mise à jour de composant.
Comment vérifier: Relancer l'analyse des dépendances : la faille ne doit plus apparaître. Vérifier ensuite que le site et le générateur fonctionnent comme avant.

À corriger avant tout A-02 · Secrets et accès

La clé du service d'e-mails est visible par tous les visiteurs

Ce que c’est: Le site envoie les messages du formulaire de contact grâce à un service d'e-mails, avec une clé secrète. Cette clé a été déclarée comme « publique » dans la configuration : elle est donc incluse dans le code que chaque navigateur télécharge, et n'importe qui peut la lire en quelques clics.
Pourquoi c’est important: Avec cette clé, un inconnu peut envoyer des e-mails au nom de votre domaine : de faux messages très crédibles à vos clients, des campagnes d'hameçonnage, ou du spam qui fera bloquer votre domaine par les messageries. C'est aussi vous qui payez chaque envoi.
Comment corriger: Désactiver immédiatement la clé dans le tableau de bord du service d'e-mails et en créer une nouvelle. La déclarer ensuite comme variable privée, utilisée uniquement côté serveur, jamais dans le code envoyé au navigateur.
Comment vérifier: Chercher la nouvelle clé dans le code du site tel que le navigateur le reçoit : elle ne doit apparaître nulle part. Vérifier que l'ancienne clé est bien refusée par le service.

À corriger ou à surveiller 11

À corriger ou à surveiller A-03 · Composants et dépendances

Une quinzaine d'autres composants sont à mettre à jour

Ce que c’est: En plus de Next.js, l'analyse a relevé 68 failles publiées dans 14 autres composants, dont 1 critique et 35 hautes. Les plus nombreuses concernent axios (32 failles), qui sert à appeler d'autres services, et basic-ftp (5 failles, dont la critique).
Pourquoi c’est important: Beaucoup de ces composants sont utilisés indirectement, par d'autres composants, et toutes les failles ne sont pas exploitables sur votre site. Mais elles s'accumulent : plus on attend, plus la mise à jour est longue et risquée.
Comment corriger: Mettre à jour les composants concernés vers leurs versions corrigées, par petits lots, en testant le site entre chaque lot. Commencer par basic-ftp et axios.
Comment vérifier: Relancer l'analyse des dépendances : le nombre de failles hautes et critiques doit tomber à zéro, ou se limiter à celles qui n'ont pas encore de correctif.

À corriger ou à surveiller A-04 · Code de l'application

Aucune limite de taille sur les messages du formulaire de contact

Ce que c’est: Le formulaire de contact accepte des messages de n'importe quelle longueur, puis les envoie par e-mail via un service payant à l'usage.
Pourquoi c’est important: Un robot peut envoyer des messages très longs, en continu. Votre boîte de réception se remplit, la facture du service d'e-mails grimpe, et les vrais messages de vos prospects se perdent dans la masse.
Comment corriger: Limiter la taille du message côté serveur (par exemple 5 000 caractères), refuser les messages vides ou trop courts, et garder la limite de fréquence déjà en place sur ce formulaire.
Comment vérifier: Envoyer un message trop long sur une version de test : il doit être refusé avec un message clair, sans qu'aucun e-mail ne parte.

À corriger ou à surveiller A-05 · Code de l'application

Un texte piégé peut ralentir le serveur du formulaire de contact

Ce que c’est: Pour vérifier ce que les visiteurs écrivent, le code utilise des « expressions régulières », des règles de recherche dans un texte. L'une d'elles, côté serveur, est écrite de telle façon qu'un texte construit exprès peut la faire calculer très longtemps. Huit autres règles du même type existent, mais dans le navigateur ou sur les articles de votre blog, que vous seul rédigez.
Pourquoi c’est important: Quelques envois bien choisis suffisent à occuper le serveur et à ralentir, voire bloquer, le formulaire pour tout le monde. C'est une forme de déni de service, qui ne demande ni compte ni outil particulier.
Comment corriger: Réécrire la règle concernée sous une forme simple et sans retours en arrière, ou la remplacer par une vérification sans expression régulière. Limiter aussi la longueur du texte avant de le vérifier.
Comment vérifier: Soumettre un texte très long et très répétitif sur une version de test : la réponse doit rester immédiate. Relancer l'analyse du code : l'alerte doit disparaître.

À corriger ou à surveiller A-06 · Configuration du site et du serveur

La protection contre les scripts malveillants n'est qu'en observation

Ce que c’est: Le site déclare une « politique de sécurité du contenu » (CSP) : une liste de ce que le navigateur a le droit de charger et d'exécuter. Elle est configurée en mode observation : le navigateur signale les écarts, mais ne bloque rien. Elle autorise en plus des scripts écrits directement dans les pages.
Pourquoi c’est important: C'est le filet de sécurité qui empêche un script injecté de s'exécuter si une faille passe un jour inaperçue. En mode observation, ce filet n'existe pas encore.
Comment corriger: Passer la politique en mode actif, une fois vérifié qu'elle ne bloque rien de légitime. À terme, retirer l'autorisation des scripts écrits dans les pages, au profit de scripts identifiés.
Comment vérifier: Dans les outils de développement du navigateur, l'en-tête Content-Security-Policy doit apparaître (et non plus Content-Security-Policy-Report-Only), sans erreur dans la console sur les pages principales.

À corriger ou à surveiller A-07 · Code de l'application

Une valeur saisie dans le générateur est renvoyée dans la page

Ce que c’est: Sur la page du générateur, une valeur passée dans l'adresse de la page est réécrite telle quelle dans le code de la page. L'outil de test l'a signalé comme une injection de script possible, sans la confirmer.
Pourquoi c’est important: Si cette valeur n'est pas nettoyée, un lien piégé pourrait faire exécuter du code dans le navigateur de la personne qui clique, avec l'apparence de votre site. Ici, le risque semble faible, car la valeur semble limitée à un choix (« oui » ou « non »), mais cela demande une vérification humaine.
Comment corriger: N'accepter que les valeurs attendues pour ce paramètre, et ignorer toute autre valeur. Cela supprime le risque, quelle que soit la façon dont la valeur est affichée.
Comment vérifier: Ouvrir la page avec une valeur inattendue dans l'adresse : elle ne doit pas apparaître dans le code de la page.

À corriger ou à surveiller A-08 · Code de l'application

Une erreur du générateur peut passer inaperçue

Ce que c’est: Dans le code qui génère les documents, une opération lancée en arrière-plan n'est pas surveillée : si elle échoue, personne n'en est informé.
Pourquoi c’est important: Le jour où cette opération échoue, l'erreur disparaît silencieusement. Vos utilisateurs peuvent recevoir un résultat incomplet sans que vous le sachiez, et le problème devient très difficile à retrouver.
Comment corriger: Attendre la fin de cette opération ou gérer explicitement son échec, en enregistrant l'erreur dans les journaux du site.
Comment vérifier: Relancer l'analyse du code : l'alerte doit disparaître. En cas d'erreur simulée, un message doit apparaître dans les journaux.

À corriger ou à surveiller A-09 · Configuration du site et du serveur

Les règles anti-attaques du pare-feu ne bloquent rien

Ce que c’est: L'hébergeur propose un pare-feu avec des règles toutes prêtes contre les attaques courantes (injections, scripts malveillants…). Elles sont activées, mais en mode « journal » : elles notent les attaques sans les arrêter.
Pourquoi c’est important: C'est une seconde ligne de défense gratuite, qui arrête beaucoup d'attaques automatiques avant qu'elles n'atteignent votre code. En mode journal, elle ne vous protège pas.
Comment corriger: Consulter le journal du pare-feu sur quelques jours pour vérifier qu'aucune visite légitime n'est concernée, puis passer les règles en mode blocage.
Comment vérifier: Dans le tableau de bord de l'hébergeur, les règles doivent indiquer « Deny » (bloquer) et non « Log » (noter).

À corriger ou à surveiller A-10 · Configuration du site et du serveur

N'importe quel site peut lire les réponses de votre site

Ce que c’est: Le serveur répond avec un réglage (Access-Control-Allow-Origin: *) qui autorise n'importe quel autre site à lire ses réponses depuis le navigateur d'un visiteur.
Pourquoi c’est important: Pour des pages publiques, c'est sans conséquence. Mais si ce réglage s'applique un jour à des pages qui renvoient des informations personnelles, un site malveillant pourrait les lire à l'insu du visiteur.
Comment corriger: Réserver ce réglage aux contenus qui en ont vraiment besoin (polices, images partagées), et ne jamais l'appliquer aux routes du serveur.
Comment vérifier: Vérifier les en-têtes des routes du serveur : Access-Control-Allow-Origin doit être absent, ou limité à vos propres domaines.

À corriger ou à surveiller A-11 · Configuration du site et du serveur

Trois protections du navigateur ne sont pas activées

Ce que c’est: Trois réglages de sécurité, envoyés par le serveur au navigateur, sont absents : Permissions-Policy (accès à la caméra, au micro, à la position), Cross-Origin-Opener-Policy et Cross-Origin-Embedder-Policy (isolation de votre site par rapport aux autres onglets).
Pourquoi c’est important: Chacun ferme une porte que vous n'utilisez pas. Leur absence n'est pas une faille en soi, mais ils limitent les dégâts si une autre faille est trouvée.
Comment corriger: Ajouter ces en-têtes dans la configuration du site, en commençant par Permissions-Policy, qui ne risque rien de casser.
Comment vérifier: Les en-têtes doivent apparaître dans les réponses du site, et les pages principales doivent fonctionner normalement.

À corriger ou à surveiller A-12 · Qualité et maintenance

Aucun test automatisé ne protège le site contre les régressions

Ce que c’est: Le projet ne contient aucun test automatisé : rien ne vérifie, à chaque modification, que le formulaire de contact ou le générateur fonctionnent encore.
Pourquoi c’est important: Chaque nouvelle demande à votre IA peut casser une fonctionnalité existante sans que personne ne s'en aperçoive. C'est souvent ce qui donne l'impression que l'IA « tourne en rond ».
Comment corriger: Ajouter quelques tests sur les parcours qui comptent le plus : l'envoi du formulaire de contact et la génération d'un document. Pas besoin de tout tester pour gagner beaucoup en sérénité.
Comment vérifier: Une commande de test doit exister, passer au vert, et échouer si l'on casse volontairement le formulaire.

À corriger ou à surveiller A-13 · Qualité et maintenance

Quelques petits défauts de code à nettoyer

Ce que c’est: L'analyse du code a relevé deux points mineurs : une fonction qui porte le même nom qu'un élément réservé du langage, et une propriété de style placée là où elle n'a pas d'effet. Elle a aussi signalé un nombre aléatoire « non sécurisé » : vérification faite, il sert seulement à espacer les nouvelles tentatives d'envoi d'e-mail. C'est une fausse alerte, et il n'y a rien à corriger.
Pourquoi c’est important: Pris un par un, ces points ne sont pas graves. Mais ils rendent le code plus difficile à relire, pour vous comme pour votre IA.
Comment corriger: Les corriger en une fois, lors d'une session de nettoyage, sans toucher au reste du code.
Comment vérifier: Relancer l'analyse du code : les deux alertes doivent disparaître. L'alerte sur le nombre aléatoire peut être marquée comme « faux positif » dans l'outil.

Ce qui tient 4

Ce qui tient A-14 · Configuration du site et du serveur

Les formulaires sensibles sont protégés contre les envois en masse

Ce que c’est: Le formulaire de contact et le générateur de documents n'acceptent qu'un nombre limité de demandes par minute et par visiteur. Au-delà, les demandes sont refusées.
Pourquoi c’est important: C'est ce qui empêche un robot d'utiliser vos formulaires pour envoyer du spam ou faire exploser vos coûts. Beaucoup d'applications construites avec l'IA n'ont pas cette protection.
Comment corriger: Rien à corriger.
Comment vérifier: À conserver lors des prochaines modifications : si vous ajoutez un nouveau formulaire, demandez la même protection.

Ce qui tient A-15 · Configuration du site et du serveur

Le pare-feu de l'hébergeur bloque les robots d'analyse

Ce que c’est: Pendant l'audit, notre outil de recherche de failles a été repéré et bloqué par le pare-feu de l'hébergeur au bout de quelques minutes. Nous avons dû refaire ce test sur une copie locale du site.
Pourquoi c’est important: Les robots des attaquants utilisent les mêmes techniques : ils sont donc freinés de la même façon. C'est une bonne nouvelle, à une nuance près, expliquée dans la section « Ce que les outils ne voient pas ».
Comment corriger: Rien à corriger.
Comment vérifier: Garder cette protection activée, et ne pas la désactiver « pour tester » sans la réactiver ensuite.

Ce qui tient A-16 · Configuration du site et du serveur

La connexion est chiffrée et les protections de base sont en place

Ce que c’est: Le site n'accepte que des connexions chiffrées (TLS 1.2 et 1.3) et impose le chiffrement aux navigateurs (Strict-Transport-Security). Il empêche aussi qu'on l'affiche à l'intérieur d'un autre site (X-Frame-Options) et que le navigateur devine le type des fichiers (X-Content-Type-Options).
Pourquoi c’est important: Ces réglages protègent vos visiteurs contre l'interception de leurs données et contre les faux sites qui imitent le vôtre. Ils sont souvent oubliés.
Comment corriger: Rien à corriger.
Comment vérifier: À conserver si vous changez d'hébergeur ou de configuration.

Ce qui tient A-17 · Qualité et maintenance

Le code est globalement bien organisé

Ce que c’est: L'analyse du code donne la meilleure note de maintenabilité (A), avec peu de code dupliqué (6 %).
Pourquoi c’est important: Un code bien rangé coûte moins cher à faire évoluer, et votre IA s'y retrouve mieux : elle lit moins, se trompe moins, et consomme moins de crédits.
Comment corriger: Rien à corriger.
Comment vérifier: Conserver ce niveau en demandant à votre IA de réutiliser l'existant plutôt que de dupliquer du code.

Accessibilité et RGPD

Accessibilité

Peut-on utiliser le site sans souris, avec un lecteur d'écran, avec une vue faible ou en zoomant fortement ? Cible : WCAG 2.2 niveau AA, avec les repères du RGAA, la version française de ces règles.

En grande partie. Un point bloque le formulaire de contact pour les personnes aveugles ; le reste gêne sans bloquer.

À corriger avant tout 1

À corriger avant tout ACC-01 · Formulaires

Le bouton d'envoi du formulaire reste grisé sans dire pourquoi, et les erreurs ne sont pas lues

Ce que c’est: Le bouton « Envoyer » est désactivé tant que tous les champs ne sont pas valides. Un bouton désactivé ne reçoit pas le focus clavier et n'explique rien. Les messages d'erreur apparaissent sous les champs, en rouge, mais ne sont ni reliés au champ concerné, ni annoncés.
Pourquoi c’est important: Une personne aveugle qui a mal saisi son e-mail ne trouve pas le bouton d'envoi, ou l'entend « indisponible », sans aucune explication. Elle ne peut pas vous contacter.
Comment corriger: Laisser le bouton d'envoi toujours actif. Au clic, si un champ est invalide, afficher les erreurs, les relier à leur champ et placer le focus sur le premier champ en erreur.
Comment vérifier: Avec VoiceOver (Cmd + F5 sur Mac), saisir un e-mail incomplet puis appuyer sur Envoyer : le focus doit revenir sur l'e-mail et l'erreur doit être lue.

À corriger ou à surveiller 3

À corriger ou à surveiller ACC-02 · Couleurs

Plusieurs textes gris sont trop pâles pour être lus confortablement

Ce que c’est: Le gris des légendes, des notes et du pied de page n'atteint que 3,9:1 sur le fond de page, pour un minimum de 4,5:1 en petit texte. Le texte d'exemple des champs du formulaire est autour de 3:1.
Pourquoi c’est important: Les personnes malvoyantes, les personnes âgées, et tout le monde sur un téléphone en plein soleil lisent ces textes difficilement.
Comment corriger: Remplacer ce gris par un gris plus foncé du thème, qui atteint au moins 4,5:1, et foncer le texte d'exemple des champs.
Comment vérifier: Mesurer chaque texte modifié avec un vérificateur de contraste (par exemple WebAIM Contrast Checker) : au moins 4,5:1 sur son fond réel.

À corriger ou à surveiller ACC-03 · Navigation au clavier

Dans le menu mobile ouvert, le focus clavier s'échappe derrière le menu

Ce que c’est: Le menu mobile couvre tout l'écran. Après son dernier lien, la touche Tab continue vers les liens de la page cachée derrière, et la touche Échap ne ferme pas le menu.
Pourquoi c’est important: Les personnes malvoyantes qui zooment à 200 % sur ordinateur voient le menu mobile : elles perdent leur position sur des éléments invisibles.
Comment corriger: Quand le menu est ouvert, rendre le reste de la page inactif (attribut inert) et fermer le menu avec Échap, en rendant le focus au bouton du menu.
Comment vérifier: Zoomer à 200 %, ouvrir le menu avec Entrée, tabuler au-delà du dernier lien puis appuyer sur Échap : le focus doit rester dans le menu, puis revenir au bouton.

À corriger ou à surveiller ACC-04 · Formulaires

Le formulaire ne dit pas quels champs sont obligatoires, et ne se remplit pas automatiquement

Ce que c’est: Rien n'indique à l'écran quels champs sont obligatoires. Les champs nom et e-mail n'indiquent pas non plus au navigateur ce qu'ils attendent : il ne peut pas proposer de les remplir.
Pourquoi c’est important: Tout le monde découvre les champs obligatoires par l'erreur. Les personnes qui ont des difficultés motrices doivent tout taper à la main.
Comment corriger: Ajouter la mention « Tous les champs sont obligatoires », et les attributs autocomplete="name" et autocomplete="email".
Comment vérifier: Cliquer dans le champ nom : le navigateur doit proposer le nom enregistré.

Ce qui tient 1

Ce qui tient ACC-05 · Structure

La structure des pages est propre

Ce que c’est: Langue déclarée, titres de page distincts, un seul titre principal par page, zones en-tête, navigation, contenu et pied de page en place, images décrites.
Pourquoi c’est important: Un lecteur d'écran lit chaque page avec le bon accent, et une personne aveugle peut sauter directement d'une partie à l'autre.
Comment corriger: Rien à corriger.
Comment vérifier: Conserver ces repères sur les prochaines pages.

RGPD

Que fait le site des données de ses visiteurs, à qui les transmet-il, et la politique de confidentialité le dit-elle honnêtement ?

Oui, sous conditions. Le site ne piste pas ses visiteurs. Un point est à corriger vite (la police chargée chez Google), les autres demandent surtout de compléter la politique de confidentialité.

À corriger avant tout 1

À corriger avant tout RGPD-01 · Prestataires

Chaque visite envoie l'adresse IP du visiteur à Google, sans le dire

Ce que c’est: Le site charge sa police de caractères par un lien direct vers les serveurs de Google, au lieu de l'outil intégré de Next.js qui l'héberge sur le site. Le navigateur de chaque visiteur transmet donc à Google son adresse IP et la page visitée. La politique de confidentialité ne cite pas Google.
Pourquoi c’est important: L'adresse IP est une donnée personnelle. Un tribunal allemand a déjà condamné un site pour ce cas précis (Munich, janvier 2022).
Comment corriger: Charger la police avec l'outil intégré de Next.js, qui la télécharge une fois pour toutes et la sert depuis votre site.
Comment vérifier: Ouvrir le site avec l'onglet Réseau des outils du navigateur : aucune requête ne doit partir vers fonts.googleapis.com ni fonts.gstatic.com.

À corriger ou à surveiller 3

À corriger ou à surveiller RGPD-02 · Information des visiteurs

La politique de confidentialité ne dit pas tout ce que fait le site

Ce que c’est: La politique ne cite ni l'hébergeur, ni le service d'e-mails qui transmet les messages du formulaire, ni les pays où ces prestataires traitent les données (les États-Unis).
Pourquoi c’est important: Une personne doit savoir, avant d'envoyer ses données, qui les reçoit et dans quel pays. Une politique incomplète est le premier point que regarde la CNIL en cas de plainte.
Comment corriger: Compléter la politique avec la liste des prestataires, leur rôle, leur pays, et la façon dont les transferts hors de l'Union sont encadrés.
Comment vérifier: Relire la politique : chaque prestataire qui reçoit des données doit y figurer, avec son pays.

À corriger ou à surveiller RGPD-03 · Conservation

Aucune durée de conservation n'est fixée pour les demandes de contact

Ce que c’est: Les messages du formulaire arrivent par e-mail et restent chez le service d'e-mails et dans votre boîte de réception, sans limite de temps. La politique ne dit pas combien de temps ils sont gardés.
Pourquoi c’est important: Le RGPD interdit de garder des données plus longtemps que nécessaire. Si un prospect demande l'effacement de ses données, il faut savoir où les trouver.
Comment corriger: Choisir une durée (par exemple 3 ans après le dernier contact), l'écrire dans la politique, et noter une routine annuelle de tri.
Comment vérifier: Une fois par an, la boîte de réception ne doit plus contenir de demande sans suite plus ancienne que la durée choisie.

À corriger ou à surveiller RGPD-04 · Transferts hors UE

Les données du formulaire sont traitées aux États-Unis par défaut

Ce que c’est: Le formulaire tourne chez l'hébergeur sans région choisie, donc aux États-Unis par défaut, alors que le site vise des visiteurs français.
Pourquoi c’est important: Un transfert hors de l'Union doit être encadré et annoncé. Faire tourner le formulaire en Europe réduit le sujet à un seul prestataire, le service d'e-mails.
Comment corriger: Choisir une région européenne (par exemple Paris) pour les fonctions du site, et vérifier les engagements des prestataires pour les transferts.
Comment vérifier: Dans le tableau de bord de l'hébergeur, la région des fonctions doit indiquer Paris (cdg1).

Ce qui tient 1

Ce qui tient RGPD-05 · Traceurs

Aucun cookie ni traceur publicitaire

Ce que c’est: Ni Google Analytics, ni pixel Meta, ni cookie publicitaire. Le formulaire ne demande que le nécessaire, et son contenu n'est pas écrit dans les journaux du serveur.
Pourquoi c’est important: Le site n'a pas besoin de bandeau cookies, et les visiteurs ne sont pas pistés.
Comment corriger: Rien à corriger.
Comment vérifier: Revérifier ce point avant d'ajouter tout outil de statistiques ou de publicité.

Ce que les outils ne voient pas

Un rapport « propre » ne prouve pas que le site est sûr

Lors de notre premier passage sur la version en ligne, l'outil de recherche de failles a rendu un rapport presque vide. En regardant les réponses reçues, nous avons compris pourquoi : le pare-feu de l'hébergeur lui renvoyait une page de blocage, et non votre site. L'outil avait en fait testé… la page de blocage.

C'est pour cela que nous vérifions toujours ce que les outils ont réellement vu, et que nous avons refait ce test sur une copie locale du site. Un rapport vide sans cette vérification ne vaut rien.

Les outils se trompent, dans les deux sens

Certaines alertes sont fausses : une règle de style signalée comme bug, par exemple, peut être parfaitement valide selon l'endroit où elle est écrite. À l'inverse, les outils manquent des failles réelles : la clé du service d'e-mails visible par tous (A-02) a été trouvée en lisant le code, pas par un outil.

Chaque constat de ce rapport a donc été relu et classé par un développeur, pas copié depuis un outil.

Les outils ne comprennent pas votre métier

Un outil sait reconnaître une faille connue. Il ne sait pas si un document généré contient les bonnes informations, ni si un visiteur peut obtenir ce qu'il ne devrait pas en enchaînant des étapes normales. Ces questions demandent de comprendre ce que fait votre site.

L'accessibilité et le RGPD ne se voient pas tout entiers dans le code

La partie accessibilité a été menée par la lecture du code : le parcours complet au clavier et l'écoute avec un lecteur d'écran restent à faire, et chaque constat indique comment le tester en deux minutes.

Côté RGPD, les contrats signés avec les prestataires et leurs réglages (région, durée de conservation) ne se lisent pas dans le code. Ce rapport n'est ni une certification d'accessibilité, ni un avis juridique.

Une version de test n'est pas la production

Les tests ont été menés sur une version de test et sur une copie locale, jamais sur votre site de production. Les réglages de l'hébergeur (pare-feu, en-têtes) peuvent différer entre les deux : pensez à vérifier que les corrections sont bien appliquées en production.

Petit glossaire

Framework: La boîte à outils sur laquelle votre site est construit (ici Next.js). Il gère l'affichage des pages, les adresses et le serveur.
Dépendance: Un composant écrit par d'autres et réutilisé par votre site. Un site moderne en utilise des centaines, souvent sans le savoir.
Faille publiée (CVE): Une faille découverte, documentée et rendue publique avec un numéro. Les attaquants la connaissent aussi : il faut mettre à jour vite.
Clé d'API: Un mot de passe qui permet à votre site d'utiliser un service extérieur (e-mails, paiement, IA). Elle doit rester sur le serveur.
Injection de script (XSS): Une attaque qui fait exécuter du code malveillant dans le navigateur d'un visiteur, en se faisant passer pour votre site.
CSP: La politique de sécurité du contenu : la liste de ce que le navigateur a le droit de charger et d'exécuter sur votre site.
CORS: Les règles qui disent quels autres sites peuvent lire les réponses de votre site depuis le navigateur d'un visiteur.
En-têtes de sécurité: Des consignes envoyées par le serveur au navigateur avec chaque page, pour activer des protections intégrées.
Déni de service: Une attaque qui ne vole rien, mais rend le site lent ou indisponible, en l'occupant ou en le saturant.
Pare-feu applicatif: Un filtre placé devant votre site, chez l'hébergeur, qui arrête les visites suspectes avant qu'elles n'atteignent votre code.
Limite de fréquence: Un nombre maximum de demandes par visiteur et par minute, au-delà duquel le site refuse de répondre.
Test automatisé: Un petit programme qui vérifie, à chaque modification, qu'une fonctionnalité marche toujours.
Lecteur d'écran: Logiciel qui lit la page à voix haute ou en braille (VoiceOver sur Apple, NVDA sur Windows), utilisé par les personnes aveugles.
Contraste: Écart de luminosité entre un texte et son fond, de 1:1 (invisible) à 21:1 (noir sur blanc). Il faut au moins 4,5:1 pour du texte courant.
WCAG et RGAA: Les règles internationales d'accessibilité du web, et leur version française. Le niveau AA est la cible habituelle.
Sous-traitant: Prestataire qui traite des données personnelles pour votre compte, comme l'hébergeur ou le service d'e-mails.

Annexe : les prompts à donner à votre IA

Chaque prompt se copie tel quel dans votre outil d’IA (Lovable, Cursor, Claude…). Donnez-les un par un, dans l’ordre, et vérifiez le résultat avant de passer au suivant.

P-01 Correction Lié au constat A-01

Mettre à jour Next.js

Mon projet utilise Next.js 15.5.19, qui a des failles de sécurité critiques publiées (exécution de code à distance via l'optimisation d'images).

1. Mets à jour next vers la dernière version 15.5.x (au minimum 15.5.28), ainsi que eslint-config-next si le projet l'utilise, avec le gestionnaire de paquets du projet.
2. Ne change aucun autre paquet et ne modifie pas le code de l'application.
3. Lance le build et corrige uniquement ce que la mise à jour casse, en m'expliquant chaque changement.
4. Termine par la liste des fichiers modifiés et la version installée.

N'effectue pas de mise à jour majeure (16.x) sans me demander.

P-02 Correction Lié au constat A-02

Rendre la clé du service d'e-mails privée

La clé de mon service d'e-mails est déclarée avec le préfixe NEXT_PUBLIC_, ce qui l'expose dans le code envoyé au navigateur. J'ai déjà désactivé l'ancienne clé et créé une nouvelle clé.

1. Renomme la variable sans le préfixe NEXT_PUBLIC_ partout où elle est utilisée, et dans .env.example.
2. Vérifie qu'elle n'est lue que dans du code serveur (routes API, Server Actions), jamais dans un composant client.
3. Vérifie que les fichiers .env* contenant des secrets sont bien ignorés par git.
4. Liste-moi les endroits modifiés, et dis-moi quelle variable je dois mettre à jour chez mon hébergeur.

N'écris jamais la valeur de la clé dans le code ni dans ta réponse.

P-03 Correction Lié au constat A-03

Mettre à jour les autres composants vulnérables

Mon projet a des dépendances avec des failles connues, notamment basic-ftp et axios.

1. Liste les dépendances vulnérables avec la commande d'audit du gestionnaire de paquets du projet.
2. Pour chacune, indique si c'est une dépendance directe ou indirecte, et la version corrigée.
3. Mets à jour par petits lots : d'abord basic-ftp et axios, puis le reste. Après chaque lot, lance le build et arrête-toi si quelque chose casse.
4. N'effectue aucune mise à jour majeure sans me demander.

Termine par un tableau : paquet, ancienne version, nouvelle version, failles corrigées.

P-04 Correction Lié au constat A-04

Limiter les messages du formulaire de contact

Dans la route API du formulaire de contact, ajoute une validation côté serveur du message :

- refuser un message vide ou de moins de 10 caractères ;
- refuser un message de plus de 5 000 caractères ;
- renvoyer une erreur 400 avec un message clair, sans envoyer d'e-mail.

Ajoute la même limite dans le formulaire côté navigateur pour prévenir l'utilisateur, mais garde la vérification serveur comme référence. Ne modifie pas la limite de fréquence existante. Ajoute un test pour chaque cas refusé et un test pour un message valide.

P-05 Correction Lié au constat A-05

Sécuriser l'expression régulière du formulaire de contact

Une expression régulière de la route API du formulaire de contact a une complexité super-linéaire : un texte construit exprès peut la faire calculer très longtemps (ReDoS).

1. Montre-moi l'expression concernée et explique en une phrase ce qu'elle vérifie.
2. Réécris-la pour qu'elle ne puisse pas revenir en arrière de façon excessive (pas de quantificateurs imbriqués, pas d'alternatives qui se recouvrent), ou remplace-la par une vérification plus simple.
3. Limite la longueur du texte avant de lui appliquer l'expression.
4. Ajoute un test avec un texte long et répétitif qui doit être traité en moins de 50 ms, et des tests qui prouvent que la vérification accepte et refuse les mêmes cas qu'avant.

Ne touche pas aux autres expressions régulières du projet dans cette tâche.

P-06 Correction Lié au constat A-06

Activer la politique de sécurité du contenu

Mon site envoie un en-tête Content-Security-Policy-Report-Only. Je veux la rendre active sans casser le site.

1. Montre-moi où cet en-tête est défini et la politique actuelle.
2. Liste ce qui serait bloqué si on l'activait tel quel (scripts, styles, images, polices, services externes).
3. Propose une politique active qui autorise uniquement ce dont le site a besoin. Si possible, remplace l'autorisation 'unsafe-inline' des scripts par des nonces, que Next.js sait générer.
4. Garde temporairement la version en observation en parallèle, pour repérer les oublis.

N'applique rien sans m'avoir montré la politique proposée.

P-07 Correction Lié au constat A-07

N'accepter que les valeurs prévues dans le générateur

Sur les pages du générateur de documents, des paramètres d'adresse (comme apport_nature) sont réutilisés dans la page.

1. Liste tous les paramètres d'adresse lus par ces pages.
2. Pour chacun, définis la liste exacte des valeurs autorisées, et ignore (valeur par défaut) toute autre valeur.
3. Vérifie qu'aucun de ces paramètres n'est inséré dans la page sans passer par l'affichage normal de React (pas de dangerouslySetInnerHTML, pas de construction de HTML à la main).
4. Ajoute un test : une valeur inattendue ne doit jamais apparaître dans la page.

P-08 Correction Lié au constat A-08

Ne plus laisser d'erreur silencieuse dans le générateur

Dans la route API du générateur, une promesse n'est ni attendue ni gérée (signalée par l'analyse du code).

1. Montre-moi la ligne concernée et ce que fait cette opération.
2. Si le résultat est nécessaire à la réponse, attends-la avec await. Sinon, ajoute un .catch qui enregistre l'erreur dans les journaux, avec assez de contexte pour la retrouver, mais sans données personnelles.
3. Vérifie s'il existe d'autres promesses non gérées dans les routes API, et liste-les sans les corriger.

P-09 Surveillance Lié au constat A-09

Passer les règles du pare-feu en mode blocage

À faire vous-même, dans le tableau de bord de votre hébergeur, pas avec l'IA :

1. Ouvrez la section « Firewall », puis les règles gérées (injections, scripts malveillants, exécution de code).
2. Consultez le journal des 7 derniers jours : vérifiez qu'aucune visite légitime n'a été notée.
3. Passez chaque règle de « Log » à « Deny ».
4. Pendant quelques jours, surveillez le journal et les messages de vos visiteurs, au cas où une page légitime serait bloquée.

P-10 Correction Lié au constat A-10

Restreindre l'accès des autres sites aux réponses

Mon site renvoie Access-Control-Allow-Origin: *.

1. Trouve d'où vient cet en-tête : configuration du framework, middleware, ou réglage par défaut de l'hébergeur.
2. Liste les routes concernées, en séparant les fichiers statiques des routes API.
3. Propose une configuration qui retire cet en-tête des routes API, ou le limite à mes propres domaines, et le garde seulement là où il est nécessaire.

Explique-moi l'impact avant de modifier quoi que ce soit.

P-11 Correction Lié au constat A-11

Ajouter les protections du navigateur manquantes

Ajoute ces en-têtes de sécurité à toutes les pages, dans la configuration existante des en-têtes du projet :

- Permissions-Policy: camera=(), microphone=(), geolocation=() ;
- Cross-Origin-Opener-Policy: same-origin.

Pour Cross-Origin-Embedder-Policy, n'ajoute rien : explique-moi d'abord ce qu'il risque de bloquer (images, polices ou scripts externes).

Ne modifie pas les en-têtes déjà présents.

P-12 Correction Lié au constat A-12

Ajouter les premiers tests automatisés

Mon projet n'a aucun test automatisé. Je veux protéger les deux parcours les plus importants.

1. Propose l'outil de test le plus simple pour ce projet, et installe-le.
2. Écris des tests pour la route API du formulaire de contact : message valide, message vide, message trop long. Remplace le vrai service d'e-mails par un faux, pour qu'aucun e-mail ne parte.
3. Écris un test pour la génération d'un document, avec des réponses types.
4. Ajoute un script test dans package.json.

Garde les tests courts et lisibles, et explique-moi comment les lancer.

P-13 Correction Lié au constat A-13

Nettoyer les petits défauts de code

L'analyse du code a relevé ces points mineurs. Corrige-les un par un, sans rien changer d'autre :

1. Dans app/error.tsx, la fonction s'appelle Error, comme l'objet global : renomme-la (par exemple ErrorPage).
2. Dans la feuille de style globale, la propriété font-display est utilisée hors d'un bloc @font-face, où elle n'a aucun effet : déplace-la ou retire-la.

Ne touche pas au Math.random() du délai entre deux tentatives d'envoi d'e-mail : il ne sert pas à la sécurité.

Termine par la liste des modifications.

P-14 Surveillance Lié au constat A-14

Garder la protection contre les envois en masse

À ajouter aux instructions permanentes de ton IA (fichier de règles du projet) :

« Toute nouvelle route API qui envoie un e-mail, appelle un service payant ou écrit des données doit avoir une limite de fréquence par visiteur, comme les routes de contact et de génération existantes. Si tu crées une telle route, ajoute cette limite et signale-le-moi. »

P-ACC-01 Correction Lié au constat ACC-01

Rendre le formulaire de contact compréhensible au lecteur d'écran

Dans le composant du formulaire de contact, le bouton d'envoi est désactivé tant que le formulaire est invalide, et les messages d'erreur ne sont pas reliés à leurs champs.

1. Retire la désactivation du bouton pendant la saisie ; garde-la seulement pendant l'envoi.
2. Donne un id à chaque message d'erreur et ajoute aria-describedby sur le champ correspondant, ainsi que aria-invalid="true" quand il est en erreur.
3. À l'envoi, si un champ est invalide : affiche toutes les erreurs, puis place le focus sur le premier champ invalide.
4. Vérifie qu'au clavier, Tab atteint toujours le bouton d'envoi, et que la validation côté serveur reste inchangée.
5. Ne change ni l'apparence ni le comportement du reste, et liste-moi les fichiers modifiés.

P-ACC-02 Correction Lié au constat ACC-02

Foncer les textes gris trop pâles

Plusieurs petits textes gris (légendes, notes, pied de page) et le texte d'exemple des champs n'atteignent pas 4,5:1 sur leur fond.

1. Repère toutes les classes de gris utilisées pour du texte de moins de 24 px.
2. Remplace-les par la nuance de gris du thème qui atteint au moins 4,5:1 sur le fond réel de chaque texte, et donne-moi le rapport obtenu.
3. Ajoute une règle pour le texte d'exemple des champs (::placeholder) avec une couleur qui atteint 4,5:1.
4. Ne change ni l'apparence ni le comportement du reste, et liste-moi les fichiers modifiés.

P-ACC-03 Correction Lié au constat ACC-03

Garder le focus dans le menu mobile ouvert

Quand le menu mobile est ouvert, la touche Tab sort du menu vers la page cachée derrière, et Échap ne ferme pas le menu.

1. À l'ouverture du menu, ajoute l'attribut inert au contenu principal et au pied de page ; retire-le à la fermeture.
2. Ferme le menu avec la touche Échap et rends le focus au bouton du menu.
3. Ajoute aria-expanded au bouton du menu, mis à jour à chaque ouverture et fermeture.
4. Vérifie au clavier, navigateur zoomé à 200 %, que Tab circule seulement dans le menu et la barre du haut.
5. Ne change ni l'apparence ni le comportement du reste, et liste-moi les fichiers modifiés.

P-ACC-04 Correction Lié au constat ACC-04

Signaler les champs obligatoires et activer le remplissage automatique

Le formulaire de contact n'indique pas ses champs obligatoires, et les champs nom et e-mail n'ont pas d'attribut autocomplete.

1. Affiche sous l'introduction du formulaire la mention « Tous les champs sont obligatoires. » (ou précise lesquels sont facultatifs).
2. Ajoute autocomplete="name" au champ nom et autocomplete="email" au champ e-mail.
3. Vérifie que le navigateur propose bien le nom et l'e-mail enregistrés.
4. Ne change ni l'apparence ni le comportement du reste, et liste-moi les fichiers modifiés.

P-RGPD-01 Correction Lié au constat RGPD-01

Servir la police depuis le site au lieu de Google Fonts

Mon site Next.js charge sa police par une balise <link> vers fonts.googleapis.com, ce qui transmet l'adresse IP des visiteurs à Google.

1. Remplace cette balise par next/font/google dans le layout principal : Next.js télécharge la police au build et la sert depuis mon propre site.
2. Garde les mêmes graisses et applique la police au même endroit qu'aujourd'hui.
3. Supprime toute balise preconnect vers fonts.googleapis.com ou fonts.gstatic.com.
4. Vérifie avec une recherche dans le projet qu'il ne reste aucun appel à googleapis ni à gstatic, puis que le build passe.
5. Ne modifie rien d'autre, et liste-moi les fichiers que tu as changés.

P-RGPD-02 Correction Lié au constat RGPD-02

Compléter la politique de confidentialité

Ma politique de confidentialité ne cite ni l'hébergeur, ni le service d'e-mails du formulaire, ni les pays où ils traitent les données.

1. Ajoute une section « Destinataires et sous-traitants » qui liste chaque prestataire recevant des données (hébergeur, service d'e-mails), son rôle et son pays.
2. Ajoute une section « Transferts hors Union européenne » qui explique comment ces transferts sont encadrés (cadre UE–États-Unis ou clauses contractuelles types), en laissant un repère « à confirmer » là où je dois vérifier.
3. Mets à jour la date de la politique.
4. Ne modifie rien d'autre, et liste-moi les fichiers que tu as changés.

P-RGPD-03 Surveillance Lié au constat RGPD-03

Fixer une durée de conservation des demandes

À faire à la main : choisissez une durée de conservation des demandes de contact (par exemple 3 ans après le dernier contact), puis, une fois par an, supprimez de votre boîte de réception et du service d'e-mails les demandes sans suite plus anciennes.

Prompt pour l'IA :
1. Ajoute dans la politique de confidentialité une section « Durée de conservation » avec la durée que je t'indique.
2. Crée un fichier docs/conservation-donnees.md qui décrit où se trouvent les demandes et la routine annuelle de suppression.
3. Ne modifie rien d'autre, et liste-moi les fichiers que tu as changés.

P-RGPD-04 Correction Lié au constat RGPD-04

Faire tourner le formulaire en Europe

Les fonctions de mon site Next.js tournent chez Vercel sans région choisie, donc aux États-Unis par défaut.

1. Ajoute "regions": ["cdg1"] (Paris) dans vercel.json, en gardant la configuration existante.
2. Vérifie que le build passe.
3. Ne modifie rien d'autre, et liste-moi les fichiers que tu as changés.

À faire à la main : vérifiez sur dataprivacyframework.gov que l'hébergeur et le service d'e-mails sont inscrits, et téléchargez leurs contrats de sous-traitance (DPA).

P-ACC-05 Règle permanente

Règle permanente : des écrans accessibles dès leur création

À chaque nouvel écran ou composant de ce site, respecte WCAG 2.2 niveau AA :
- texte d'au moins 4,5:1 sur son fond, bordures de champs et icônes utiles d'au moins 3:1 ;
- vrais éléments HTML (button, a, label, fieldset et legend) plutôt que des div avec des attributs ARIA ;
- chaque champ a un libellé relié, un autocomplete quand il s'agit d'une donnée personnelle, et ses erreurs reliées par aria-describedby ; ne désactive jamais un bouton d'envoi pour signaler une erreur ;
- tout message qui apparaît après une action passe par une zone role="status" ou role="alert" ;
- focus visible sur tous les fonds, et enfermé dans tout panneau qui couvre la page ;
- un seul h1, des titres sans saut de niveau, images utiles avec un alt qui décrit l'information ;
- aucune police, aucun script ni aucune image chargés depuis un autre site sans me le signaler.