Viser CyFun Essential quand on est seul : partir de la menace, pas du tampon

Un SaaS qui stocke des données de valeur — identités, coordonnées, comptabilité, décisions de ses utilisateurs — est une cible. Pas parce qu'il est connu : parce que ces données se revendent, se rançonnent, ou servent à frauder. La taille de l'éditeur n'y change rien. Un attaquant ne regarde pas l'effectif de l'entreprise, il regarde ce qu'il peut en tirer.

C'est pour ça que j'ai fixé une cible volontairement haute aux deux briques de la méthode que je co-développe : Foyer, pour la façon de concevoir et de construire, et Sluis, pour la façon de déployer et d'exploiter. Tout SaaS qui en sort doit pouvoir s'aligner sur le niveau le plus exigeant du référentiel belge CyberFundamentals : le niveau Essential.

Voici pourquoi, comment je le découpe — et, c'est la partie dont on parle le moins, ce qu'un solopreneur peut et ne peut pas faire seul.

CyFun en deux minutes

CyberFundamentals (CyFun) est le référentiel du Centre pour la Cybersécurité Belgique (CCB). Sa version 2025 est construite sur le NIST Cybersecurity Framework 2.0 et sert à démontrer sa conformité à NIS2 ; elle coexiste avec la version 2023 jusqu'au 18 avril 2027.

Il est organisé en niveaux cumulatifs — Small, Basic, Important, Essential. Viser Essential, c'est satisfaire les trois derniers à la fois :

Deux notions à retenir :

• Les key measures sont celles que le CCB rend prioritaires parce qu'elles bloquent les attaques réelles les plus fréquentes. Elles doivent être en place quel que soit le résultat de votre analyse de risque.
• La conformité ne se mesure pas en cases cochées mais en maturité, sur 5. Il ne suffit pas de « faire » : il faut un processus écrit, approuvé, appliqué — et des preuves.

Pourquoi le niveau le plus exigeant, alors que rien ne m'y oblige

En principe, le niveau CyFun d'une organisation découle d'une analyse de risque nationale, et un solopreneur n'est généralement pas soumis à NIS2. Je vise Essential par choix, pour trois raisons.

Je pars de la menace. Quand on liste les attaques réalistes contre un SaaS riche en données, on tombe très vite sur des mesures qui ne figurent qu'aux niveaux Important et Essential : sauvegardes isolées et testées, journaux hors de portée d'un attaquant, accès à privilèges audités, flux sortants cartographiés. S'arrêter à Basic, c'est se protéger contre l'attaque opportuniste, pas contre celle qui vise vos données.

Une cible haute, construite une fois, sert à tous les projets. Si la conformité est portée par la méthode et par la plateforme de déploiement, chaque nouveau SaaS en hérite au lieu de tout redémontrer.

Le niveau est un langage commun. Dire « aligné CyFun Essential » à un client, un partenaire ou un auditeur, c'est parler un vocabulaire qu'il peut aller vérifier — au lieu d'un « on prend la sécurité au sérieux » invérifiable.

De la menace à la brique technique

Voici le raisonnement complet, attaque par attaque : les mesures CyFun 2025 qui la contrent, puis la brique qui les porte. Entre parenthèses, le niveau de la mesure (B = Basic, I = Important, E = Essential) et key quand c'est une key measure.

Le garde-fou de la dernière ligne

Automatiser le tri des alertes est tentant, en particulier avec un modèle de langage. Mais le contenu d'une alerte peut être écrit par l'attaquant : une alerte réseau contient le User-Agent et la requête de celui qui vous scanne. Confier ce texte à un agent qui dispose d'un shell, c'est ouvrir la porte à l'injection de prompt.

D'où la règle que j'applique :

• la collecte de preuves est faite par un script déterministe, en lecture seule ;
• le verdict est rédigé par un modèle qui n'a aucun outil ;
• la notification contient toujours les preuves brutes sous le verdict ;
• aucune remédiation ne découle automatiquement de ce verdict.

En une phrase : ce qui a des droits ne lit pas de texte libre ; ce qui lit du texte libre n'a aucun droit.

Trois couches, pour hériter au lieu de redémontrer

Les quelque 230 exigences se répartissent en trois couches, et chacune a son porteur :

• Plateforme, portée par Sluis : sauvegardes immuables et testées, journaux hors hôte, séparation entre production et test, pare-feu, accès à privilèges, supervision branchée.
• Application, portée par Foyer : MFA et gestion des identités dans le produit, développement sécurisé, vulnérabilités des dépendances, cartographie des flux de données.
• Organisation, portée par des documents : politiques, analyse de risque, plan de réponse aux incidents, gestion des fournisseurs, formation.

L'idée qui change tout : la conformité devient une barrière de déploiement. Avant chaque mise en ligne, la plateforme vérifie les contrôles exigés par le niveau que le projet déclare — sauvegarde hors site active, journaux expédiés, MFA du compte d'hébergement. Si un contrôle manque, la mise en ligne est refusée. Et chaque déploiement laisse une preuve datée des contrôles vérifiés, rattachée à son identifiant CyFun.

Pourquoi c'est décisif : la maturité 3/5 exige des preuves pour la plupart des activités. Une preuve produite automatiquement à chaque déploiement ne s'oublie pas. Une preuve qu'il faut penser à rassembler avant un audit, si.

Et en euros ? Côté infrastructure, la couche plateforme coûte étonnamment peu : chez un hébergeur européen, quelques dizaines d'euros par mois pour un petit SaaS — une seconde machine pour le test et la supervision, un stockage objet verrouillé dans une autre région, une plateforme de journaux, un gestionnaire de clés. Le vrai coût, c'est le temps : écrire les procédures, tester les restaurations, tenir les revues.

L'autoévaluation : mesurer avant de construire

Le CCB met à disposition un outil d'autoévaluation par niveau, sous forme de tableur. Pour chaque exigence, on note deux scores de 1 à 5 : la documentation (le processus est-il écrit, approuvé, revu ?) et la mise en œuvre (est-il appliqué, et avec quelles preuves ?).

Les niveaux vont de 1 (Initial, rien de formel) à 5 (Optimizing, amélioration continue mesurée). Le niveau 3, Defined, est le seuil qui compte : processus formel, approuvé, appliqué, des preuves pour la plupart des activités, moins de 10 % d'exceptions.

Pour Essential, trois seuils : chaque key measure (les 29) à 3/5 au moins, chaque catégorie à 3/5 au moins, une maturité globale d'au moins 2,5/5.

Comment je la conduis :

1. Honnêtement, avec une preuve par réponse. Un « oui » sans preuve vaut 1, pas 3. Le piège classique de l'autoévaluation, c'est de noter ce qu'on croit faire.
2. Basic d'abord, puisque le modèle est cumulatif : inutile de s'attaquer aux 91 exigences Essential tant qu'une key measure Basic est sous le seuil.
3. Les écarts deviennent le backlog. Chaque exigence sous le seuil devient une tâche, rattachée à sa couche — plateforme, application ou organisation.
4. Elle se refait. Une autoévaluation est une photo : elle se reprend après chaque évolution importante, et ses preuves datent.

Et une précision que je préfère écrire moi-même plutôt que de laisser un auditeur me la rappeler : une autoévaluation n'est pas une certification. Pour dire « conforme », il faut une évaluation par un organisme d'évaluation de la conformité. « Aligné » est ce que l'autoévaluation permet d'affirmer — à condition de l'avoir documentée.

Ce qu'un solopreneur ne peut pas faire seul

Environ 230 exigences, c'est un référentiel pensé pour des organisations qui ont des équipes. Certaines exigences supposent plusieurs personnes, et aucune automatisation ne remplace ça. Autant le dire :

• La séparation des tâches (PR.AA-05.6, dès Important). Celui qui demande un accès ne doit pas être celui qui l'accorde ; celui qui déploie ne doit pas être celui qui contrôle. Seul, on cumule tous les rôles. Ce qu'on peut faire : remplacer la seconde personne par des contrôles qu'on ne peut pas contourner soi-même — déploiement uniquement depuis un commit, barrière de conformité, journal d'audit expédié hors de sa propre portée — et faire revoir périodiquement par un tiers de confiance. C'est une mesure compensatoire, à documenter comme telle, qu'un évaluateur acceptera ou non.
• L'évaluation indépendante (ID.IM-03.7, Essential). Essential demande que des équipes indépendantes évaluent vos processus ; on ne peut pas être indépendant de soi-même. Ce qu'on peut faire : un audit externe ou un test d'intrusion ponctuel, budgété. Il n'y a pas d'autre option.
• L'approbation par la direction. Le niveau 3 exige des processus « formellement approuvés ». Seul, on s'approuve soi-même : signer et dater ses politiques reste une preuve, mais la valeur de contrôle d'une approbation sans regard extérieur est faible. Il faut le savoir.
• La sécurité physique. Zones critiques, détection incendie, contrôle d'accès aux locaux : un solopreneur n'a pas de datacenter. Ce qu'on peut faire : la déléguer à l'hébergeur et le prouver par ses certifications (ISO 27001 notamment), documentées dans la gestion des fournisseurs.
• L'audit des fournisseurs (GV.SC-07.3, Essential). Vous n'auditerez pas votre hébergeur. Ce qu'on peut faire : s'appuyer sur ses attestations (ISO 27001, rapports SOC 2 sur demande) et documenter l'acceptation du risque résiduel. C'est aussi ce qui oriente le choix de l'hébergeur : certaines qualifications — santé, cloud souverain — ne couvrent pas toutes les gammes de produits.
• La réponse 24 h/24. Personne ne peut être d'astreinte en permanence. L'objectif réaliste : qu'aucune alerte ne se perde, que chacune arrive avec de quoi décider vite, et que le plan de réponse aux incidents dise ce qui se passe quand on n'est pas disponible.
• Le poids de la documentation. C'est la vraie limite. La technique se construit une fois, et une plateforme bien conçue la fait hériter à chaque projet. La documentation, elle, doit être écrite, approuvée, revue et prouvée en continu — et c'est elle qui fait passer de 2 à 3 sur l'échelle de maturité. Le seul levier qui tienne pour un solopreneur : faire produire les preuves par les outils plutôt que les rédiger à la main.

En résumé : un solopreneur peut atteindre l'essentiel de la protection qu'apporte le niveau Essential, et s'en approcher en maturité. Mais certaines exigences supposent une organisation, et elles ne seront satisfaites que par des mesures compensatoires, des tiers, ou un jour un associé. Le dire n'est pas un aveu de faiblesse : c'est exactement ce qu'une analyse de risque honnête doit écrire.

Ce que ça change pour vous

• Le niveau de sécurité de votre projet ne dépend pas de ma vigilance du jour : il dépend de contrôles qui refusent une mise en ligne non conforme.
• Les preuves existent déjà le jour où on vous les demande — client, partenaire, assureur, auditeur — parce qu'elles sont produites à chaque déploiement, pas rassemblées avant un audit.
• Vous héritez du travail des projets précédents au lieu de financer une mise en conformité repartie de zéro.
• Les limites sont écrites, pas masquées. Vous savez ce qui est couvert par de l'outillage, ce qui l'est par une mesure compensatoire, et ce qui demandera un tiers.

Viser CyFun Essential quand on est seul, ce n'est pas chercher un tampon. C'est se donner une cible exigeante et vérifiable, construite à partir des attaques qu'on veut réellement contrer, et l'inscrire dans la méthode pour qu'elle profite à chaque projet plutôt que de la refaire à chaque fois.

Si vous voulez savoir ce que ce niveau donnerait sur votre produit — ou simplement où vous en êtes aujourd'hui — parlons-en.