Exemple illustratif
L'état réel et honnête de cra-kit.com face au CRA — les mêmes 20 questions que celles posées dans le diagnostic détaillé, avec les réponses sans rien cacher ni verrouiller.
Exemple de rapport de conformité
1. Contexte technique
Recueilli après le clic « Je suis intéressé », en complément des 24 questions du diagnostic.
Hébergeur
Vercel (plan Hobby)
Langage / framework principal
Next.js (React), Node.js
Pipeline CI/CD existant
Aucun pipeline custom — déploiement automatique natif de Vercel sur chaque push GitHub
Base de données
Supabase (PostgreSQL)
Taille de l'équipe technique
Solo (1 personne)
2. Synthèse et priorités
Compte tenu du contexte ci-dessus (Vercel + Next.js + Supabase, équipe solo, pas de pipeline CI dédié), plusieurs points se règlent avec les outils déjà en place plutôt que par de nouveaux investissements. Deux priorités rapides restantes : activer Dependabot sur GitHub (a) — deux clics, aucune config ; et documenter la protection DDoS déjà fournie par Vercel (h) — aucun développement. Le point (v5) a été traité en conditions réelles pendant la rédaction de cet exemple — preuve concrète, pas juste une recommandation.
Ensuite : la suppression de données en self-service (m) est rapide à construire avec Supabase et Resend déjà intégrés (moins d'une heure estimée) ; le SBOM (v1) et le changelog (v4) sont mécaniques une fois la commande connue.
Les tests de sécurité réguliers (v3) et l'audit des points d'entrée (j) demandent surtout de fixer une routine — réaliste à 30 minutes par trimestre pour une équipe solo sur cette stack, pas un chantier lourd.
Prochaines étapes
- Traiter les 2 priorités rapides (a, h) avant tout — gain immédiat, effort minimal avec les outils déjà en place.
- Traiter (m), (v1), (v4), puis (v3), (j).
- Une fois les 7 points résolus ou justifiés : la déclaration UE de conformité (section 4) peut être signée.
3. Détail par exigence
12 exigences sur 20 couvertes à ce jour. Comme n'importe quel produit réel, cra-kit.com a encore des points ouverts — les voici, avec la mesure à prendre pour chacun.
Vulnérabilités connues
Aucun scan automatisé des dépendances en place.
→ Activer Dependabot directement sur le dépôt GitHub (Settings → Security → Dependabot alerts + security updates) — gratuit, ne nécessite pas de pipeline CI dédié, compatible avec le déploiement automatique Vercel déjà en place. En complément : ajouter npm audit --audit-level=high comme script prebuild dans package.json.
Configuration sécurisée par défaut
RLS Supabase : écriture publique seule, aucune lecture/modification possible par défaut.
Mises à jour de sécurité
SaaS pur, déploiement continu via Vercel/GitHub, aucune action requise côté utilisateur.
Contrôle d'accès
Pas de compte utilisateur exposé ; les données ne sont consultables que via le dashboard Supabase, protégé par authentification.
Confidentialité
HTTPS (Vercel) + chiffrement au repos (Supabase).
Intégrité
RLS interdit par défaut toute modification/suppression par la clé publique.
Minimisation
Seuls email + réponses explicites sont collectés.
Résilience DDoS
Protection limitée au défaut Vercel, non documentée spécifiquement.
→ Vercel Edge Network inclut une protection DDoS de base dès le plan Hobby — documenter ce point en citant vercel.com/docs/security. Le passage au plan Pro (à l'activation de Stripe) apporte des protections additionnelles. Pour une équipe solo, aucune action supplémentaire nécessaire à ce stade.
Impact sur d'autres systèmes
Application web simple, ne génère pas de trafic vers des tiers.
Points d'entrée inutiles
Aucun audit formel des routes/endpoints n'a été fait.
→ Avec Next.js App Router, lister les fichiers sous app/api/ et vérifier qu'aucune route de test/développement n'a été oubliée en production — un grep -r "app/api" dans le dépôt suffit pour un solo dev.
Limitation de l'exploitation
La clé publique ne peut qu'insérer — un vol de clé ne permettrait ni lecture ni modification des données existantes.
Journalisation
Logs Vercel (requêtes) + Supabase (accès base).
Suppression des données
Pas de self-service.
→ Avec Supabase déjà en place, une route app/api/delete-my-data/route.js utilisant supabaseAdmin.from('submissions').delete().eq('email', email), avec confirmation par email via Resend (déjà intégré) : moins d'une heure de développement, aucune nouvelle dépendance.
SBOM
Pas de nomenclature logicielle formalisée.
→ npm sbom --sbom-format=cyclonedx > sbom.json depuis le dossier du projet. Committer le fichier sous /docs/sbom.json à chaque déploiement majeur — l'historique Git suffit à tracer les évolutions.
Correction rapide
Déploiement continu, correctif en production en quelques minutes.
Tests de sécurité réguliers
Aucun test de sécurité récurrent formalisé à ce jour.
→ Routine trimestrielle réaliste pour une stack Vercel/Supabase solo : npm audit (couvert par Dependabot ci-dessus), revue manuelle des policies RLS Supabase (Table Editor → Policies), et test de la clé anon depuis un client externe. Environ 30 minutes, aucun outil payant nécessaire.
Gratuité et communication des correctifs
Produit actuellement gratuit, mais pas de changelog ni d'avis de sécurité publié pour expliquer un correctif à l'utilisateur si besoin.
→ Une page /changelog en Markdown, même structure que /guide déjà en place. Pour un SaaS en déploiement continu, ne documenter que les correctifs qui changent réellement quelque chose pour l'utilisateur.
Politique CVD
Politique publiée à cra-kit.com/securite.
Point de contact
contact@cra-kit.com, actif et surveillé.
Distribution sécurisée
Pipeline Vercel/GitHub, accès protégé par authentification de compte.
4. Déclaration UE de conformité
Un dossier de conformité contient en réalité deux documents distincts, chacun avec un rôle précis :
- La documentation technique — La preuve, exigence par exigence : ce que vous avez mis en place, ou pourquoi un point ne s'applique pas. C'est la section 3 ci-dessus.
- La déclaration UE de conformité — Un certificat court, 8 champs fixes définis par le règlement. Elle atteste que la documentation technique est complète et conforme — elle ne la répète pas. C'est la section ci-dessous.
La seconde s'appuie sur la première : on ne peut pas signer la déclaration tant que la documentation technique n'est pas complète.
Le dossier complet inclut aussi cette déclaration légale — et applique la même honnêteté : elle ne peut pas être signée tant que des points restent ouverts, même pour CRA Kit lui-même.
BROUILLON — NON VALIDE EN L'ÉTAT
7 points de la section 3 restent à traiter avant qu'une déclaration puisse être signée.
Produit
CRA Kit — wizard de diagnostic et de qualification au Cyber Resilience Act, application web (SaaS), version 1.0, accessible à https://cra-kit.com/wizard.
Fabricant
Voir mentions légales de cra-kit.com.
Attestation de responsabilité
La présente déclaration, une fois finalisée, sera établie sous la seule responsabilité du fabricant.
Objet de la déclaration
Application web accessible à https://cra-kit.com/wizard, permettant la qualification et l'évaluation de conformité au Cyber Resilience Act pour des produits logiciels tiers.
Conformité
Non conforme en l'état — 7 exigences restent non couvertes ou incertaines à ce jour (voir section 3).
Normes et spécifications appliquées
Aucune norme harmonisée disponible à ce jour (2026) pour cette catégorie de produit par défaut. Conformité démontrée par évaluation des risques et documentation technique (section 3 du présent dossier).
Organisme notifié
Sans objet — évaluation de la conformité par contrôle interne (module A), produit par défaut, aucun organisme tiers requis.
Informations complémentaires
Dossier généré à partir du diagnostic CRA Kit (cra-kit.com/wizard).
Et une fois signée ?
Signer ce document n'est pas une formalité isolée — et l'essentiel du travail est déjà fait dans les sections précédentes. Voici ce qu'il reste à votre charge, et ce que vous pouvez reprendre tel quel.
- Signature — Le fondement légal d'une déclaration n'est pas la conviction que « c'est bon », mais une documentation écrite par exigence : preuve de ce qui est en place, ou justification si le point ne s'applique pas (art. 13§3-4). La section 3 de ce document, déjà rédigée pour votre produit, remplit ce rôle — vous n'avez rien à rédiger de plus, seulement à confirmer que chaque action a bien été réalisée avant de dater et signer.
- Marquage CE — Pour un logiciel, il s'appose directement sur cette déclaration ou sur votre site — aucun support physique à produire (art. 30§1).
- Conservation, pas dépôt — Rien à envoyer à une administration. Vous conservez ce document et la documentation technique en interne, prêts à être produits sur demande d'une autorité de surveillance du marché, pendant au moins 10 ans (art. 13§13).
- Accessibilité — Une copie ou une version simplifiée doit être accessible à vos utilisateurs — republier la politique de sécurité fournie en section 5 sur votre propre site suffit à remplir une bonne partie de cette obligation (art. 13§20).
5. Politique de divulgation coordonnée des vulnérabilités
Le dossier complet inclut ce document, entièrement rédigé et prêt à publier — pas une simple recommandation, un vrai livrable fini. Nous l'avons utilisé tel quel pour créer la page ci-dessous.
Signaler une vulnérabilité
CRA Kit prend la sécurité au sérieux. Si vous pensez avoir découvert une vulnérabilité de sécurité sur cra-kit.com, merci de nous la signaler de façon responsable.
Comment nous contacter
Adresse dédiée : contact@cra-kit.com
Ce que nous demandons
- Ne pas divulguer publiquement avant correction
- Fournir assez d'informations pour reproduire le problème
- Agir de bonne foi, sans exploiter la vulnérabilité au-delà de ce qui est nécessaire pour la démontrer
Notre engagement
- Accusé de réception sous 5 jours ouvrés
- Évaluation et plan de correction communiqué sous 30 jours
- Aucune poursuite contre un chercheur de bonne foi respectant cette politique
Délai de divulgation coordonnée
Engagement à corriger ou convenir d'un calendrier sous 90 jours avant toute divulgation publique.
Ce texte, mot pour mot, est publié sur cra-kit.com/securite →
Voilà les 5 éléments que contient votre dossier si vous êtes dans une situation similaire : contexte, priorités, détail, déclaration, politique — pas seulement un diagnostic.
Et pour vous ?
Ceci est l'exemple de cra-kit.com. Voici ce que donnerait le vôtre.
150€
Dossier de conformité complet, généré à partir de vos réponses
Cet exemple est fourni à titre illustratif, sur la base de l'état réel de cra-kit.com au moment de sa publication, et ne constitue pas un avis juridique.
Retour à l'accueil