Ne jamais coder la réglementation en dur
Le moteur d'évaluation traite le CRA comme un jeu de règles paramétrable plutôt que comme une logique fixée dans le code, pour pouvoir accueillir un second cadre réglementaire sans réécriture.
Startup / SaaS · 2026
CraftSec
Cartographier ce qu'il y a dans un produit, avant que le régulateur ne le demande.
- Rôle
- Fondateur, conception produit, développement full-stack et prospection commerciale
- Durée
- 2026 - en cours
- Équipe
- Solo
- État
- MVP en finalisation
Stack
Next.jsTypeScriptPostgreSQLDrizzleTailwind CSS
MVP
Statut
CRA
Cadre réglementaire
Solo
Équipe
2026
Année
Le problème — 01
À partir du 11 septembre 2026, le Cyber Resilience Act impose aux fabricants européens de déclarer sous 24 heures toute vulnérabilité activement exploitée. Beaucoup ne savent pas aujourd'hui quels produits embarquent quel composant.
CraftSec est né d'une analyse structurée d'une trentaine d'idées de produits, menée durant l'été 2026 pour trouver une opportunité exécutable seul, sans levée de fonds. Le Cyber Resilience Act s'est imposé parce qu'il transforme une obligation vague en échéance datée : le 11 septembre 2026 pour le signalement, le 11 décembre 2027 pour le reste.
La cible retenue est la PME industrielle qui fabrique un produit connecté — automatismes, IoT, électronique embarquée — sans équipe ni budget dédiés à la conformité produit, contrairement aux grands comptes déjà équipés d'outils coûteux.
Le projet démarre volontairement petit : une analyse gratuite et sans compte, pensée comme un point d'entrée vers la conversation avec les équipes qualité et R&D concernées, avant toute fonctionnalité de suivi continu.
L'approche — 02
Comment le projet a pris forme.
- 01
Cadrage avant code
Définition du profil client, des critères d'exclusion et d'une thèse testable avant la première ligne de code, pour éviter de construire sur une hypothèse non vérifiée.
- 02
MVP d'analyse SBOM
Dépôt d'un fichier CycloneDX ou SPDX, extraction des composants, corrélation avec les vulnérabilités connues et restitution en quelques secondes, sans compte ni engagement.
- 03
Mise en marché ciblée
Domaine, positionnement et premiers contacts construits en parallèle du produit plutôt qu'après, pour valider l'intérêt avant d'investir dans les fonctionnalités suivantes.
Un fabricant a 24 heures pour déclarer une faille activement exploitée; encore faut-il savoir quel produit est concerné.
Défis & décisions — 03
Là où les choix comptent vraiment.
Traiter le SBOM comme une donnée sensible
Un SBOM révèle l'architecture complète d'un produit commercial. URL de résultat non devinable, suppression automatique, hébergement européen : la confidentialité est une condition d'usage, pas une option.
Réduire le périmètre pour tenir le calendrier
Générateur de documentation, intégrations CI et portail fournisseurs ont été explicitement écartés du lancement pour livrer l'analyse SBOM avant l'échéance réglementaire.
Résultat — 04
Ce que le projet a produit.
L'analyse de SBOM est fonctionnelle : dépôt d'un fichier CycloneDX ou SPDX, extraction des composants et restitution des vulnérabilités connues avec leur sévérité. Le site est en ligne sur craftsec.eu, en amont de la mise en marché prévue autour du 11 septembre 2026.
Ce que j'en retiens — 05
Les leçons qui restent.
- 01
Une hypothèse commerciale se teste par la conversation, pas par le code — les deux premières semaines ont porté sur la prospection, pas sur l'interface.
- 02
Un faux positif coûte plus cher qu'une fonctionnalité manquante : mieux vaut afficher « à investiguer » qu'une certitude non vérifiée.
- 03
La confidentialité d'un fichier déposé par un inconnu n'est pas un détail de sécurité, c'est la condition pour qu'il accepte de le déposer.
Projet suivant
TakeSeat
Startup / SaaS
Et après
Travaillons ensemble.
Un projet, une opportunité de stage ou simplement l'envie d'échanger ? Ma boîte de réception est ouverte.
Démarrer une conversation