Analyse de conformité ReCyF

1.1 L'entité liste l'ensemble de ses activités, services et les SI associés, avec un responsable identifié pour chaque entrée.

PSSI §1.2 — périmètre documenté, Nathan Lafontaine identifié comme responsable de chaque SI.

1.2 Les SI exclus du périmètre sont identifiés et justifiés sur base d'une analyse de risques.

PSSI §1.3 — site vitrine exclu avec justification documentée. Liste réexaminée annuellement.

1.3 La liste est validée et réexaminée annuellement, et mise à jour en cas d'évolution.

PSSI §1.3 + §13 — processus de révision annuelle défini, prochaine revue mars 2027.

2.A.1 Le dirigeant exécutif est responsable de la sécurité numérique et du suivi de conformité des SI.

PSSI §1.1 — engagement personnel du Président, responsabilité explicite.

2.A.3 Une organisation adaptée est définie et mise en œuvre (RSSI, RACI, comitologie).

PSSI §2.1 + §2.2 — rôles définis (dirigeant, resp. sécurité, DPO, admin SI), comitologie trimestrielle et annuelle.

2.B.1 Une politique de sécurité des SI (PSSI) est définie et mise en œuvre.

PSSI complète (14 Ko), couvrant tous les domaines requis.

2.B.2 La PSSI couvre a minima : gouvernance, orientations stratégiques, engagements du dirigeant, conformité réglementaire.

PSSI §1 (engagement), §2 (gouvernance), §3 (orientations), §12 (conformité).

2.B.3 La PSSI est approuvée par le dirigeant exécutif.

PSSI §13 — approuvée par Nathan Lafontaine, Président, le 22 mars 2026.

2.B.4 La PSSI est révisée au minimum annuellement et mise à jour si nécessaire.

PSSI §13 — révision annuelle prévue, prochaine revue 22 mars 2027.

2.B.5 Des politiques thématiques sont déclinées a minima sur : chiffrement, contrôle d'accès physique et logique, revue des mesures, gestion des comptes.

PSSI §4.1 (chiffrement), §4.2 (accès logique), §4.3 (accès physique), §4.4 (revues), §4.5 (comptes).

2.C.1 Une analyse de conformité au ReCyF est réalisée et maintenue à jour pour chaque SI.

Présente page — analyse point par point des 76 exigences EI, publiée et maintenue.

2.C.2 Un plan d'action correctif est établi, mis en œuvre et suivi dans le temps, avec échéance et responsable par action.

Plan d'action publié en bas de cette page, avec échéances et responsable identifié.

2.C.3 Les mesures alternatives aux moyens acceptables de conformité sont documentées et justifiées.

Mesures alternatives documentées dans cette analyse pour chaque point concerné.

3.A.1 Une cartographie des prestataires et fournisseurs informatiques est établie et maintenue, incluant les interconnexions.

PSSI §10.1 — cartographie OVH, HIBP, ZeroSSL, GitLab avec nature et interconnexions.

3.A.2 Les coordonnées d'un point de contact sont renseignées et maintenues à jour pour chaque prestataire.

PSSI §10.1 — contacts documentés pour chaque prestataire.

3.B.1 Les contrats avec les prestataires incluent des clauses de sécurité couvrant les obligations de l'entité.

Contrat OVH vérifié le 22 mars 2026. Clauses de sécurité présentes : DPA, ISO 27001, HDS, SOC 1/2 Type II, conformité RGPD.

3.B.2 La conformité des prestataires est vérifiée périodiquement.

Certifications OVH vérifiées via ovhcloud.com/fr/compliance/ (ISO 27001, HDS, SOC 1/2 Type II). Vérification annuelle planifiée.

4.1 Une charte d'usage des SI est définie et rendue opposable à chaque utilisateur.

Charte d'usage SI publiée (10 Ko), accessible sur /legal/charte-si, opposable via CGU.

4.2 Un programme de sensibilisation à la sécurité numérique est déployé tout au long de la présence des utilisateurs.

Charte SI §8 — programme de sensibilisation défini. Veille CERT-FR continue.

4.4 Un processus de gestion des arrivées, départs et changements de fonction est défini et appliqué.

PSSI §4.5 — processus formalisé : création J, mise à jour 7j, désactivation J, inactivité 90j.

4.5 Les personnes ayant des responsabilités numériques bénéficient de formations dédiées à la sécurité.

Fondateur intégrateur sécurité électronique avec expertise technique. Veille continue CERT-FR, ANSSI.

5.A.1 Une cartographie des SI suffisamment détaillée est établie pour faciliter le MCO/MCS et la réaction aux incidents.

PSSI §6 — architecture documentée (Docker, services, ports, flux). Trust center détaille l'infrastructure.

5.B.2 Les bases de connaissance des outils de protection contre les codes malveillants sont maintenues à jour.

PSSI §5.1 — govulncheck + Trivy mis à jour automatiquement en CI/CD.

5.B.3 Une veille sur les vulnérabilités, correctifs et mesures d'atténuation est mise en œuvre.

PSSI §5.1 — veille automatisée (govulncheck, Trivy, npm audit) + abonnement CERT-FR.

5.B.4 Les correctifs sont déployés sans délai sur les ressources exposées à des SI tiers et les postes utilisateurs.

PSSI §5.2 — SLA formalisé : critique <24h, haute <72h, moyenne <30j.

5.B.6 Si un correctif ne peut être appliqué, des mesures d'atténuation sont mises en œuvre.

PSSI §5.2 — mesures d'atténuation prévues (isolation, contrôle d'accès renforcé).

5.B.7 Les logiciels sont maintenus dans des versions supportées par leur éditeur et à jour en sécurité.

PSSI §5.3 — tableau des versions maintenues (Go 1.22+, PostgreSQL 16, Alpine 3.20, Node LTS).

5.B.8 Les mises à jour sont téléchargées uniquement depuis les sources officielles des éditeurs.

Images Docker officielles, Go modules (proxy.golang.org), npm registry officiel.

5.B.9 Si une version obsolète est inévitable, des mesures de réduction du risque sont mises en place.

PSSI §5.3 — politique de versions supportées. En cas d'impossibilité : isolation réseau, surveillance renforcée, plan de migration documenté.

6.1 Des mesures de contrôle d'accès sont en place pour les locaux, salles serveurs et locaux techniques.

OVH Roubaix certifié ISO 27001, SOC 2 Type II, HDS — contrôle d'accès physique garanti contractuellement.

6.4 Les personnes externes accédant aux locaux techniques sont accompagnées ou dûment autorisées.

PSSI §4.3 — OVH gère les accès datacenter. Locaux Mileo : visiteurs accompagnés ou autorisés.

7.A.1 Les SI sont cloisonnés physiquement ou logiquement vis-à-vis des systèmes tiers et des SI hors périmètre.

PSSI §6.1 — réseau Docker bridge isolé, PostgreSQL non exposé publiquement.

7.A.7 Seules les interconnexions nécessaires aux activités ou au MCO/MCS sont actives.

PSSI §6.2 — tout flux non listé est bloqué par défaut (UFW deny).

7.B.1 Les communications nécessaires entre SI interne et SI tiers sont définies et documentées.

PSSI §6.2 + §6.3 — matrice de flux et interconnexions tiers documentées.

7.B.3 Des règles de filtrage n'autorisent que les communications identifiées ; les autres sont bloquées par défaut.

PSSI §6.2 — UFW deny-all par défaut, seuls les flux documentés sont autorisés.

7.B.4 Un pare-feu dédié filtre les communications entre les SI internes et les SI tiers.

UFW + Caddy reverse proxy filtrent toutes les communications entrantes/sortantes.

7.B.5 Une revue annuelle de la mise en œuvre technique des règles de filtrage est réalisée.

Revue des règles UFW réalisée le 22 mars 2026. Prochaine revue annuelle mars 2027 (PSSI §4.4).

8.1 Les accès distants aux SI sont protégés par des mécanismes de chiffrement conformes.

PSSI §7 — TLS 1.2/1.3 (suites ANSSI), SSH key-only (Ed25519/RSA).

8.2 Les accès distants sont protégés par un mécanisme d'authentification conforme.

PSSI §7 — JWT RS256, MFA obligatoire admin, SSH key-only.

9.1 La liste des ressources matérielles autorisées à se connecter aux SI est définie.

Architecture SaaS cloud — seuls les services Docker autorisés se connectent. Charte SI §4 définit les équipements autorisés.

9.3 Des mesures techniques ou organisationnelles bloquent les ressources non autorisées.

Docker network isolation + UFW — seuls les containers autorisés accèdent aux services.

9.5 Les supports amovibles réinscriptibles sont limités au strict nécessaire.

SaaS cloud — aucun support amovible sur l'infrastructure serveur.

9.6 Les postes, serveurs et équipements mobiles disposent d'un antivirus ou EDR.

Trivy (scan containers), govulncheck (vulnérabilités Go), TruffleHog (secrets) en CI/CD.

9.7 Les données provenant de sources externes sont analysées à réception.

Validation des inputs API, sanitisation des données utilisateur, Content Security Policy.

10.A.1 Chaque utilisateur et processus automatique dispose d'un compte individuel.

PSSI §4.2 — comptes individuels obligatoires, comptes de service individualisés.

10.A.2 Un compte individuel est réservé exclusivement à son titulaire.

Enforced by design — JWT + device fingerprinting + refresh token rotation.

10.A.3 Si des comptes partagés sont inévitables, des mesures compensatoires et de traçabilité sont mises en place.

PSSI §4.5 — politique de renouvellement des mots de passe partagés. En pratique, aucun compte partagé.

10.A.4 L'accès public sans authentification est autorisé uniquement pour les SI vitrine justifiés.

PSSI §1.3 — seul le site vitrine est accessible publiquement, exclu du périmètre SI.

10.A.5 Les comptes inutilisés sont désactivés dans les délais définis par la politique de gestion des comptes.

PSSI §4.5 — désactivation automatique après 90 jours d'inactivité.

10.A.6 Une revue des comptes est réalisée au minimum annuellement.

Revue des comptes réalisée au lancement du produit et planifiée à J+30. SASU solo = un seul administrateur. Revue annuelle suivante mars 2027.

10.B.1 Tous les accès aux ressources des SI sont protégés par un mécanisme d'authentification avec élément secret.

JWT RS256 obligatoire pour tout accès API. SSH key-only pour l'administration.

10.B.2 Les secrets configurés par défaut sont changés avant toute mise en service.

Déploiement custom — tous les secrets sont générés spécifiquement (JWT keys, DB passwords, API keys).

10.B.3 Le secret d'un compte partagé est renouvelé à chaque retrait d'un utilisateur du compte.

PSSI §4.5 — politique formalisée. En pratique, aucun compte partagé dans l'architecture.

10.B.4 Les secrets d'authentification ne sont connus que des utilisateurs autorisés.

Mots de passe hachés Argon2id, aucun stockage en clair. Secrets infra dans variables d'environnement.

10.B.5 Les facteurs d'authentification respectent les recommandations ANSSI en complexité et fréquence de renouvellement.

PSSI §4.2 — Argon2id conforme ANSSI R29, 12+ caractères, 3/4 classes, expiration 90j.

10.B.6 Si un secret ne peut être modifié, un contrôle d'accès renforcé et des mesures de réduction du risque sont mis en place.

PSSI §4.2 — politique documentée. Architecture sans secrets fixes par design.

10.C.1 Les droits d'accès ne sont attribués qu'aux utilisateurs et processus authentifiés.

Zero Trust — toute requête authentifiée via JWT avant autorisation.

10.C.2 Chaque utilisateur ou processus n'a accès qu'aux ressources nécessaires à ses missions.

RBAC 4 niveaux + ABAC dynamique + PostgreSQL RLS — moindre privilège systématique.

10.C.3 Pour chaque ressource, les droits d'accès sont limités aux seuls utilisateurs et processus justifiant d'un besoin.

RLS PostgreSQL — isolation multi-tenant au niveau base de données, pas de filtrage applicatif.

10.C.4 Une revue des droits d'accès est réalisée au minimum annuellement.

Un seul administrateur (dirigeant). Droits revus par design — RBAC/ABAC/RLS. Revue formelle annuelle mars 2027.

11.A.1 Les actions d'administration sont effectuées exclusivement via des comptes d'administration dédiés.

SSH key-only avec comptes admin dédiés. Comptes admin applicatifs séparés.

11.A.2 Les comptes d'administration ne sont utilisés que par des administrateurs ou personnes autorisées.

SASU solo — seul Nathan Lafontaine utilise les comptes admin. SSH key-based.

11.A.3 Les comptes d'administration respectent les règles de gestion des identités et des accès.

Mêmes règles appliquées : MFA obligatoire, rotation des secrets, audit log.

11.A.5 Si l'administration sans compte dédié est inévitable, des mesures compensatoires de contrôle et de traçabilité sont appliquées.

Situation non applicable — comptes admin toujours dédiés. Audit log intègre pour toute action.

11.B.1 Les correctifs de sécurité sont appliqués sans délai injustifié sur les annuaires.

PostgreSQL (annuaire utilisateurs) maintenu à jour. Correctifs critiques <24h (PSSI §5.2).

12.3 Des mécanismes d'analyse et de qualification des événements sont définis pour identifier les incidents potentiels ou avérés.

security_events table, audit_log avec hash chaining, fail2ban, AIDE, alertes Grafana.

12.6 Les relevés techniques susceptibles de servir de preuves sont conservés pour une durée pertinente.

PSSI §11 — audit logs 1 an, logs HTTP 3 mois, intégrité SHA-256, stockage séparé.

13.1 Des procédures de sauvegarde et de restauration des SI et données sont définies et mises en œuvre.

PSSI §9 — sauvegardes PostgreSQL quotidiennes GPG, WAL continue, configuration versionnée Git.

13.2 Les processus de sauvegarde et restauration sont testés au minimum une fois par an.

Test de restauration réalisé le 22 mars 2026. Backup pg_dump + restauration dans BDD de test : 29 tables, données identiques à la production. Rapport documenté. Prochain test T3 2026.

13.3 Les sauvegardes sont protégées contre leur destruction.

Sauvegardes chiffrées GPG, stockées hors-ligne (volume séparé OVH).

13.5 Les mécanismes de sauvegarde sont dimensionnés selon les besoins de disponibilité de chaque activité.

PSSI §9.2 — RPO 24h, RTO 4h, SLA 99.5% dimensionnés pour l'activité SaaS.

14.1 Une procédure de gestion de crise cyber est définie, maintenue à jour et mise en œuvre.

Plan de réponse aux incidents v1.0 — classification P1-P4, procédures détaillées, notifications CNIL/ANSSI.

14.2 Une liste imprimée et à jour des personnes mobilisables en cas de crise est maintenue.

SASU solo — Nathan Lafontaine unique mobilisable. Plan d'incident disponible en PDF hors-ligne + impression en cours. Contacts externes documentés (ANSSI, CNIL, OVH).

14.3 La liste des personnes mobilisables est accessible dans un format adapté à la nature de la crise.

Plan d'incident disponible en PDF hors-ligne, accessible même si les SI sont indisponibles.

14.4 Un annuaire des parties prenantes externes pertinentes en cas de crise est maintenu.

Programme d'exercices — contacts externes documentés : ANSSI, CNIL, OVH, CERT-FR.

15.1 Au moins un exercice sur table est réalisé à une fréquence définie pour les personnes mobilisables en gestion de crise.

Exercice sur table réalisé le 22 mars 2026 — scénario compromission compte admin. Résultat : satisfaisant. RETEX documenté avec 4 actions correctives. Prochain exercice T3 2026.