Divulgation honnête

Reglyze est sous le seuil PME de l'article 2(1) NIS2.

Nous mettons volontairement en œuvre les mesures de gestion des risques en utilisant Reglyze (le produit) à la fois comme sujet et comme outil. C'est du dogfooding, pas une obligation réglementaire. Nous le publions pour que vous puissiez vérifier à quoi ressemble réellement une base d'évidence construite par IA avant d'acheter.

Centre de confiance

Reglyze fonctionne avec Reglyze

Nous utilisons notre propre plateforme pour gérer la conformité de Reglyze — dans le cadre national de chaque pays, et non en NIS2 brut. Même scoring, mêmes politiques, mêmes contrôles que nos clients. Sans discours marketing : nos vrais chiffres.

Dernière auto-évaluation: 19 mai 2026

Référentiel:

Comment nous l'avons construit

moins d'une heure

pour documenter toute notre base d'évidence (vs 80 à 120 h en manuel)

100 %

SLA de correctifs critiques (Dependabot + Renovate, 3 correctifs réels)

Trimestrielle

cadence d'auto-audit — dernier cycle T2-2026

ReCyF — Score de conformité

57/100

Implémentation: 54%Documentation: 61%

Organisation

Name

Reglyze

Country

Sector

digital_providers

Headcount

NIS2 Status

Out of scope

Reglyze est sous le seuil des entreprises moyennes (5 salariés) et hors catégorie spéciale NIS2. Nous nous conformons volontairement, nos clients exigeant des preuves de sécurité au titre de leur propre vigilance sur la chaîne d'approvisionnement.

ReCyF — Contrôles

1 Recensement des systèmes d'information

50%

1.1-EI/EE

Liste des activités, services et SIEstablished

Politique de gestion des actifs (REGLYZE-POL-ASM-001) définit l'inventaire des activités, services et SI ; le stack de production est identifiable (Hetzner, Cloudflare, GitHub, Postgres, Redis, MinIO). Aucun registre d'actifs formellement complété n'est encore produit comme artefact opérationnel. [NIS2 21.2.i.1]

2/32/3

1.2-EI/EE

Justification des SI exclus du périmètre d'applicationPartial

SaaS mono-produit : l'ensemble des SI est dans le périmètre. Aucune analyse de risques formalisée justifiant l'exclusion de SI n'est documentée (non nécessaire en pratique, mais l'exigence de justification écrite n'est pas satisfaite). [NIS2 21.2.i]

1/31/3

1.3-EI/EE

Validation et réexamen annuel de la listeEstablished

La politique d'actifs prévoit une revue annuelle ; aucun cycle de réexamen complété (documents en v1.0, prochain examen 2026). [NIS2 21.2.i.1]

1/32/3

2 Mise en œuvre d'un cadre de gouvernance de la sécurité numérique

57%

2.A.1-EI/EE

Dirigeant exécutif responsable de la sécurité numériqueEstablished

Cyril Poder, dirigeant unique, approuve les politiques ; le board briefing deck matérialise la supervision de gouvernance. Structure mono-dirigeant : cadence de revue formelle naissante et non testée. [NIS2 20.1.a]

2/32/3

2.A.3-EI/EE

Délégation et responsabilités formaliséesEstablished

Les rôles sont décrits dans l'ISP et le board deck ; avec 5 personnes et un dirigeant unique, la matrice de délégation formalisée reste embryonnaire. [NIS2 20.1.a]

1/32/3

2.B.1-EI/EE

PSSI formaliséeEstablished

PSSI complète (REGLYZE-ISP-001) en v1.0, approuvée par le dirigeant ; pas de cycle de revue annuel complété. [NIS2 21.2.a.2]

2/32/3

2.B.2-EI/EE

Politique de chiffrementEstablished

Politique de chiffrement (REG-SEC-POL-CRYPTO-001) v1.0 ; chiffrement opérationnellement fort (repos + transit). [NIS2 21.2.h.1]

2/32/3

2.B.3-EI/EE

Politique de contrôle d'accès physique et logiqueEstablished

Politique de contrôle d'accès logique (REG-SEC-POL-001) ; volet physique largement hérité de Hetzner (ISO 27001, Francfort). [NIS2 21.2.i.2]

2/32/3

2.B.4-EI/EE

Politique de revue de l'application des mesures de sécuritéEstablished

Politique de test d'efficacité (REG-POL-ETP-001) définit la revue d'application des mesures ; aucun cycle de revue/audit complété. [NIS2 21.2.f]

1/32/3

2.B.5-EI/EE

Revue annuelle des politiquesEstablished

Toutes les politiques prévoient une revue annuelle ; aucune revue effectuée (v1.0). [NIS2 21.2.a.5]

1/32/3

2.C.1-EI/EE

Analyse de conformité aux objectifsEstablished

L'auto-évaluation NIS2 de mai 2026 EST une analyse de conformité (dogfooding du produit) ; l'analyse ReCyF est en cours. [NIS2 21.2.f]

2/32/3

2.C.2-EI/EE

Plan d'action pour corriger les écartsEstablished

Les écarts sont identifiés par l'auto-évaluation ; un plan d'action formel de remédiation est partiellement suivi. [NIS2 21.2.f.4]

1/32/3

2.C.3-EI/EE

Suivi du plan d'action dans la duréePartial

Pas de suivi longitudinal documenté d'un plan d'action de remédiation dans la durée. [NIS2 21.2.f.5]

1/31/3

3 Maîtrise de l'écosystème

58%

3.A.1-EI/EE

Cartographie des prestataires et fournisseursEstablished

7 fournisseurs identifiés et évalués (Hetzner, Cloudflare, Anthropic, Stripe, GitHub, Resend, Google) dans l'évaluation de la chaîne d'approvisionnement. [NIS2 21.2.d.1]

2/32/3

3.A.2-EI/EE

Identification des dépendances critiquesEstablished

Criticité des fournisseurs classée (critical/high/medium) avec scores de risque résiduel par fournisseur. [NIS2 21.2.d.1]

2/32/3

3.B.1-EI/EE

Exigences de cybersécurité dans les contratsEstablished

La politique chaîne d'approvisionnement (REGLYZE-POL-SC-001) exige des clauses contractuelles ; aucun contrat fournisseur exécuté avec clauses de sécurité/DPA n'est attesté. [NIS2 21.2.d.2]

1/32/3

3.B.2-EI/EE

Suivi périodique des engagements de sécurité des tiersEstablished

Pas de cadence de revue périodique des tiers attestée ; Dependabot/Renovate couvrent les dépendances logicielles. [NIS2 21.2.d.3]

1/32/3

4 Intégration de la sécurité numérique dans la gestion des ressources humaines

54%

4.1-EI/EE

Charte d'utilisation des systèmes d'informationEstablished

La politique RH (hr_security) couvre l'usage acceptable ; aucune charte signée archivée pour les 5 collaborateurs. [NIS2 21.2.i]

1/32/3

4.2-EI/EE

Sensibilisation à la cybersécuritéEstablished

Le plan de formation couvre la sensibilisation de l'ensemble des 5 collaborateurs ; aucun enregistrement de complétion. [NIS2 21.2.g.1]

2/32/3

4.4-EI/EE

Gestion des accès à l'arrivée du personnelEstablished

La politique RH couvre l'arrivée ; aucune checklist d'onboarding / journal NDA complété. [NIS2 21.2.i.4]

1/32/3

4.5-EI/EE

Révocation des accès au départ ou en cas de mobilitéEstablished

La politique RH couvre le départ/la mobilité ; aucun journal de révocation d'accès. [NIS2 21.2.i.5]

1/32/3

5 Maîtrise des systèmes d'information

56%

5.A.1-EI/EE

Inventaire des composants matériels et logicielsEstablished

Politique d'actifs + stack identifiable ; SBOM de fait via Dependabot/Renovate ; pas de registre formel complété. [NIS2 21.2.i.1]

2/32/3

5.B.2-EI/EE

Application des correctifs de sécurité dans des délais maîtrisésMature

FORCE opérationnelle : Dependabot + Renovate ouvrent des PR de correctifs automatiques ; 3 PR de sécurité réelles appliquées (SLA de patch 100%). [NIS2 21.2.e.3, 21.2.d.4]

3/32/3

5.B.3-EI/EE

Veille sur les vulnérabilités publiéesMature

Veille continue via Dependabot/Renovate + GitHub advisories. [NIS2 21.2.e.3]

3/32/3

5.B.4-EI/EE

Mécanisme d'évaluation et de priorisation des correctifsEstablished

La politique de gestion des vulnérabilités (REG-SEC-POL-003) définit la priorisation ; labels de sévérité Dependabot. [NIS2 21.2.e]

2/32/3

5.B.6-EI/EE

Plan de gestion des fins de supportPartial

Pas de suivi documenté des fins de support au-delà des montées de version majeures Renovate. [NIS2 21.2.e]

1/31/3

5.B.7-EI/EE

Désactivation des fonctionnalités non utiliséesEstablished

Images conteneurisées minimales ; durcissement implicite mais non documenté. [NIS2 21.2.e.5]

2/31/3

5.B.8-EI/EE

Maîtrise des supports amoviblesPartial

Infra cloud entièrement distante, aucun support amovible en production ; l'exigence n'est pas formalisée (faible pertinence opérationnelle). [NIS2 21.2.i]

1/31/3

5.B.9-EI/EE

Procédure d'autorisation des supports amoviblesPartial

Idem 5.B.8 : procédure d'autorisation des supports amovibles non formalisée, faible pertinence (pas de média on-prem). [NIS2 21.2.i]

1/31/3

6 Maîtrise des accès physiques aux locaux

58%

6.1-EI/EE

Contrôle d'accès aux locauxEstablished

Aucun local serveur détenu par Reglyze ; sécurité physique héritée du datacenter Hetzner (ISO 27001, Francfort), équipe entièrement distante sans bureau central. Contrôle hérité, documenté dans l'évaluation chaîne d'approvisionnement. [NIS2 21.2 env. physique]

2/32/3

6.4-EI/EE

Accompagnement ou habilitation des visiteurs des locaux techniques et salles serveursEstablished

Sans locaux techniques propres, l'accès des visiteurs aux salles serveurs est géré par Hetzner. Contrôle hérité. [NIS2 21.2 env. physique]

2/31/3

7 Sécurisation de l'architecture des systèmes d'information

61%

7.A.1-EI/EE

Cartographie de l'architecture des SIEstablished

Architecture documentée (fichiers compose, ADRs) ; docs actifs/PCA décrivent la topologie ; instance Hetzner unique. [NIS2 21.2.e]

2/32/3

7.A.7-EI/EE

Cloisonnement des SIPartial

Services conteneurisés mais hôte unique, pas de segmentation réseau multi-niveaux ; le RLS assure l'isolation tenant en base. [NIS2 21.2.e]

1/31/3

7.B.1-EI/EE

Filtrage des flux entrants et sortantsEstablished

Cloudflare WAF + reverse-proxy Traefik filtrent l'entrant ; blocage egress ajouté (correctif SSRF S2). [NIS2 21.2.e]

2/32/3

7.B.3-EI/EE

Chiffrement des communications vers et depuis l'InternetMature

FORCE : TLS imposé partout via Cloudflare. [NIS2 21.2.h.3]

3/32/3

7.B.4-EI/EE

Recours à des dispositifs cryptographiques recommandésEstablished

TLS Cloudflare (suites modernes) ; la politique de chiffrement référence des standards ; conformité aux recommandations ANSSI non formellement validée. [NIS2 21.2.h]

2/32/3

7.B.5-EI/EE

Désactivation des protocoles non sécurisésEstablished

HTTPS-only, HSTS (S5) ; protocoles hérités désactivés côté Cloudflare ; non formellement documenté. [NIS2 21.2.h]

2/31/3

8 Sécurisation des accès distants aux systèmes d'information

75%

8.1-EI/EE

Tunnels chiffrés conformes aux recommandations ANSSI pour les accès distantsEstablished

Cloudflare Tunnel + SSH pour l'administration vers Hetzner (chiffré) ; conformité aux recommandations ANSSI non formellement vérifiée. [NIS2 21.2.e, 21.2.h]

2/32/3

8.2-EI/EE

Authentification des utilisateurs en accès distantMature

FORCE : MFA imposée partout, y compris accès distant (SSH, GitHub, Hetzner, Cloudflare). [NIS2 21.2.j.1]

3/32/3

9 Protection des systèmes d'information contre les codes malveillants

43%

9.1-EI/EE

Dispositif de protection contre les codes malveillantsPartial

Pas d'AV/EDR sur serveurs (infra conteneurisée immuable) ; Cloudflare WAF filtre les menaces web ; aucun programme anti-malware documenté. [NIS2 21.2.e]

1/31/3

9.3-EI/EE

Empêchement de la connexion des ressources matérielles non autoriséesPartial

Infra cloud, pas de surface d'attache de matériel non autorisé ; non formalisé. [NIS2 21.2.e]

1/31/3

9.5-EI/EE

Mise à jour régulière des signatures antimalwarePartial

Non applicable de fait (pas d'AV à signatures) ; les règles Cloudflare WAF sont mises à jour par Cloudflare. [NIS2 21.2.e]

1/31/3

9.6-EI/EE

Filtrage des contenus actifs (web) à l'exception des mises à jour fournisseursEstablished

CSP (S5) + filtrage Cloudflare des contenus actifs ; documenté partiellement. [NIS2 21.2.e]

2/31/3

9.7-EI/EE

Réaction et investigation en cas de détectionEstablished

Le PRI couvre détection -> réaction ; alertes Cloudflare/Dependabot ; non testé. [NIS2 21.2.b]

2/32/3

10 Gestion des identités et des accès des utilisateurs aux systèmes d'information

63%

10.A.1-EI/EE

Processus de création et de modification des identitésEstablished

Politique de contrôle d'accès + comptes plateforme-natifs (GitHub/Hetzner/Cloudflare) ; Better Auth pour les utilisateurs applicatifs. [NIS2 21.2.i.2]

2/32/3

10.A.2-EI/EE

Identités nominatives ou identifiablesEstablished

Comptes nominatifs sur l'ensemble des plateformes. [NIS2 21.2.i.2]

2/32/3

10.A.3-EI/EE

Suppression ou désactivation des comptes inutilisésEstablished

Politique d'offboarding ; aucun journal de révocation attesté. [NIS2 21.2.i.5]

1/32/3

10.A.4-EI/EE

Distinction comptes nominatifs / comptes de serviceEstablished

Comptes de service (CI, rôles DB dont le nouveau split RLS reglyze_app/reglyze_admin) distincts des comptes humains. [NIS2 21.2.i.2]

2/32/3

10.A.5-EI/EE

Maîtrise des comptes de serviceEstablished

Comptes de service cadrés (rôles RLS, jetons de déploiement) ; secrets en variables d'environnement. [NIS2 21.2.i.2]

2/32/3

10.A.6-EI/EE

Documentation des règles de gestion des identitésEstablished

La politique de contrôle d'accès documente les règles de gestion des identités. [NIS2 21.2.i.2]

2/32/3

10.B.1-EI/EE

Attribution des droits d'accès selon le moindre privilègeEstablished

Moindre privilège dans la politique ; RBAC applicatif ; rôles DB RLS. [NIS2 21.2.i.2]

2/32/3

10.B.2-EI/EE

Validation des droits d'accès par le responsable métierEstablished

Dirigeant unique : validation triviale mais non formalisée comme processus distinct. [NIS2 21.2.i]

1/32/3

10.B.3-EI/EE

Revue périodique des droits d'accèsEstablished

La politique impose une revue ; aucun cycle de revue des accès complété. [NIS2 21.2.i]

1/32/3

10.B.4-EI/EE

Révocation des droits inutilisésEstablished

L'offboarding couvre la révocation ; aucun journal. [NIS2 21.2.i.5]

1/32/3

10.B.5-EI/EE

Gestion des situations de mobilité interneEstablished

La politique RH couvre le changement de rôle ; petite équipe, gestion informelle. [NIS2 21.2.i]

1/32/3

10.B.6-EI/EE

Documentation des règles d'attributionEstablished

La politique de contrôle d'accès documente les règles d'attribution. [NIS2 21.2.i.2]

2/32/3

10.C.1-EI/EE

Politique de mot de passe robusteEstablished

Règles de mot de passe Better Auth + politique MFA. [NIS2 21.2.j]

2/32/3

10.C.2-EI/EE

Authentification multifacteur (MFA) lorsque techniquement possibleMature

FORCE : MFA imposée partout. [NIS2 21.2.j.1]

3/32/3

10.C.3-EI/EE

Stockage et transmission sécurisés des secrets d'authentificationEstablished

Identifiants hachés (Better Auth), secrets en environnement, TLS. (Rotation des secrets à effectuer — action opérationnelle interne, hors surface publique.) [NIS2 21.2.h]

2/32/3

10.C.4-EI/EE

Verrouillage des sessions inactivesEstablished

Expiration/verrouillage de session dans Better Auth. [NIS2 21.2.i]

2/32/3

11 Maîtrise de l'administration des systèmes d'information

67%

11.A.1-EI/EE

Comptes d'administration dédiésEstablished

Comptes d'administration séparés (admin org GitHub, Hetzner, superuser DB vs reglyze_app) ; split de rôles RLS. [NIS2 21.2.i]

2/32/3

11.A.2-EI/EE

Comptes d'administration distincts des comptes utilisateursEstablished

Administration distincte des comptes utilisateurs ; reglyze_admin (bypass) vs reglyze_app (scoped) en base. [NIS2 21.2.i]

2/32/3

11.A.3-EI/EE

Authentification renforcée des administrateursMature

FORCE : MFA sur toutes les consoles d'administration. [NIS2 21.2.j.1]

3/32/3

11.A.5-EI/EE

Revue périodique des comptes d'administrationEstablished

Aucun cycle de revue des comptes d'administration complété. [NIS2 21.2.i]

1/32/3

11.B.1-EI/EE

Traçabilité des actions d'administrationEstablished

Journaux d'audit GitHub, logs de déploiement, logs DB ; centralisation partielle (log-shipper). [NIS2 21.2.e.5]

2/32/3

12 Identification et réaction aux incidents de sécurité

67%

12.3-EI/EE

Mécanismes d'analyse et de qualification des événements de sécuritéEstablished

Le PRI comporte un cadre de classification/qualification des événements ; alertes Cloudflare/Dependabot en entrée ; non testé contre un événement réel. [NIS2 21.2.b.3]

2/32/3

13 Continuité et reprise d'activité

58%

13.1-EI/EE

Mécanismes de sauvegarde et de restauration des SI et donnéesEstablished

Sauvegardes quotidiennes rclone -> Google Drive opérationnelles ; politique BDR (REGLYZE-POL-BDR-001). [NIS2 21.2.c.2]

2/32/3

13.2-EI/EE

Tests des sauvegardes au minimum une fois par anEstablished

La politique impose un test ; la restauration n'a pas été testée sur les 12 derniers mois. [NIS2 21.2.c.2]

1/32/3

13.3-EI/EE

Stockage des sauvegardes adapté (par exemple : hors-ligne pour les incidents de type ransomware)Established

Sauvegardes hors-site Google Drive chiffrées au repos ; pas de véritable stockage hors-ligne/immuable. [NIS2 21.2.c]

2/32/3

13.5-EI/EE

Identification des besoins de disponibilité par serviceEstablished

Le PCA définit RTO/RPO à haut niveau ; besoins de disponibilité par service non entièrement cartographiés. [NIS2 21.2.c.1]

1/32/3

14 Réaction aux crises d'origine cyber

47%

14.1-EI/EE

Dispositif de gestion de crise cyberEstablished

Le PCA aborde la crise à haut niveau ; pas de dispositif de gestion de crise autonome exercé. [NIS2 21.2.c.4]

1/32/3

14.2-EI/EE

Équipes mobilisables et compétences identifiéesEstablished

Équipe de 5 personnes, astreinte unique (Cyril) ; compétences concentrées. [NIS2 21.2.c.4]

1/32/3

14.3-EI/EE

Liste des contacts accessibles hors SI (papier)Partial

Aucune fiche de contacts d'urgence hors-ligne (papier) attestée. [NIS2 21.2.c]

1/31/3

14.4-EI/EE

Identification des contacts externes pertinents (ANSSI, autorités sectorielles, prestataires)Established

Le PRI référence la notification ANSSI ; liste des contacts externes partielle. [NIS2 21.2.b.4]

1/32/3

14.5-EE

Retour d'expérience après crise et plan d'améliorationEstablished

Applicabilité réelle EI+EE (erreur de suffixe PDF v2.5). Le PRI comporte un REX post-incident ; jamais exercé. [NIS2 21.2.b.5]

1/32/3

15 Exercices, tests et entraînements

33%

15.1-EI/EE

Exercice sur table à fréquence définie par l'entitéPartial

La politique de test d'efficacité impose des exercices ; AUCUN exercice sur table n'a été conduit à ce jour, et aucun test d'intrusion n'a été réalisé (NIS2 21.2.f.2 = 0). Écart le plus important. [NIS2 21.2.b, 21.2.f.2]

0/32/3

Fournisseurs critiques (7)

Hetzner Online GmbH

Cloud infrastructure / hosting

critical

Data shared: All application data, customer accounts, encrypted backups

Cloudflare

CDN, DNS, WAF, TLS termination

critical

Data shared: All HTTP/S traffic metadata, no plaintext payloads

Anthropic

AI/LLM (Claude API for document generation)

high

Data shared: Customer organization context for document generation prompts

GitHub

Source code hosting and CI/CD

high

Data shared: Source code, deployment secrets via Actions

Resend

Transactional email delivery

medium

Data shared: Recipient email addresses (customer admins, vendor questionnaire contacts), email bodies (compliance notifications, vendor questionnaire requests, billing notices).

Google (Workspace + Drive via rclone)

Off-site backup destination

high

Data shared: Encrypted daily Postgres dumps + MinIO blob backups mirrored via rclone. Encryption at rest by Google; Reglyze does not currently apply client-side encryption on top.

Stripe

Payment processing and billing

high

Data shared: Customer billing details, subscription metadata

Politiques de sécurité (15)

NIS2 Article 20(2) Training Certificate — Cyril Poder

Updated 17 May 2026

Approved

Reglyze Information Security Policy

Updated 17 May 2026

Approved

Reglyze Incident Response Plan

Updated 17 May 2026

Approved

Reglyze Business Continuity Plan

Updated 17 May 2026

Approved

Reglyze Backup and Disaster Recovery Plan

Updated 17 May 2026

Approved

Reglyze Supply Chain Security Policy

Updated 17 May 2026

Approved

Reglyze Vulnerability Management Policy

Updated 17 May 2026

Approved

Reglyze Effectiveness Testing Policy

Updated 17 May 2026

Approved

Reglyze Cybersecurity Training Plan

Updated 17 May 2026

Approved

Reglyze Cryptography Policy

Updated 17 May 2026

Approved

Reglyze HR Security Policy

Updated 17 May 2026

Approved

Reglyze Access Control Policy

Updated 17 May 2026

Approved

Reglyze Asset Management Policy

Updated 17 May 2026

Approved

MFA & Secured Communications Policy

Updated 17 May 2026

Approved

Board/Management Cybersecurity Briefing Deck

Updated 17 May 2026

Approved

Why we publish this

Most compliance vendors talk about security but never show their own posture. We think that's backwards. If our platform is good enough for our customers, it's good enough for us.

Every score, control, supplier, and policy on this page comes from the same Reglyze platform we sell — rendered in each country's native framework, the way a French, Italian or German buyer actually assesses. There's no separate trust portal, no manually-curated security PDF.

You can verify it yourself: api.reglyze.com/api/public/trust/reglyze

Build your own trust page

Get your compliance score, generate policies, and manage suppliers in one platform — the same one we use.