1. Objet et portée

La présente Politique de Sécurité du Système d'Information (« PSSI ») définit les principes, mesures et procédures de sécurité mis en œuvre par MIBsoft pour garantir la confidentialité, l'intégrité, la disponibilité et la traçabilité (CIDT) des données et systèmes hébergeant le service.

Elle s'applique à l'ensemble des collaborateurs, prestataires, sous-traitants ayant accès au système d'information de MIBsoft, ainsi qu'à toute personne intervenant dans son cycle de vie.

2. Gouvernance

• Responsable sécurité : fonction assurée par la direction — security@mibsoft.fr ;
• DPO : dpo@mibsoft.fr ;
• Revue annuelle de la PSSI par la direction ;
• Comité sécurité trimestriel (technique + direction).

3. Architecture et hébergement

3.1 Topologie

• Frontend : Vercel (edge network), site statique + Edge Functions ;
• Backend / DB : Supabase — PostgreSQL managé sur AWS eu-central-1 (Frankfurt) ;
• Authentification : Supabase Auth (GoTrue), JWT signés ;
• Stockage fichiers : Supabase Storage (S3-compatible) en région Frankfurt ;
• Emails : Mailgun, région UE ;
• Paiements : Stripe.

3.2 Localisation des données

4. Chiffrement

• En transit : TLS 1.3 obligatoire (HSTS activé, redirection HTTPS automatique, suite cryptographique modernes — A+ SSLLabs) ;
• Au repos : AES-256 pour la base PostgreSQL et le stockage S3 (chiffrement géré par AWS + Supabase) ;
• Mots de passe : hachés en bcrypt (cost ≥ 10) ou argon2id, jamais stockés en clair ;
• Secrets applicatifs : stockés dans le coffre Vercel + variables d'environnement chiffrées, jamais commitées dans Git ;
• Tokens JWT : signés HMAC-SHA256 avec rotation périodique des secrets.

5. Authentification et gestion des accès

5.1 Utilisateurs finaux

• Mot de passe avec exigence de complexité (longueur min. 10 caractères, mélange) ;
• Verrouillage automatique après 5 tentatives échouées (5 minutes) ;
• Réinitialisation de mot de passe par email avec lien à usage unique limité à 1 h ;
• MFA (authentification à deux facteurs) recommandée pour les administrateurs centre, obligatoire à partir du plan Entreprise.

5.2 Administrateurs MIB

• MFA obligatoire sur tous les accès d'administration à distance, sans exception : Supabase, Vercel, Stripe, GitHub, Mailgun (envoi de tous les courriels de la plateforme) et Backblaze B2 (qui détient une copie chiffrée intégrale de la base). Les deux derniers ont longtemps manqué à cette liste alors qu'ils portent, l'un l'identité expéditrice, l'autre les données elles-mêmes ;
• Comptes nominatifs, pas de compte générique partagé ;
• Principe du moindre privilège ;
• Revue d'accès trimestrielle ;
• Révocation immédiate en cas de départ.

6. Cloisonnement multi-tenants (Row Level Security)

L'isolation entre centres de formation est garantie au niveau base de données par le mécanisme Row Level Security (RLS) de PostgreSQL.

• Chaque table sensible (stagiaires, formateurs, scores, sessions) porte une colonne center_id ;
• Des policies RLS strictes filtrent automatiquement chaque requête en fonction du JWT de l'utilisateur connecté ;
• Les tests automatisés vérifient régulièrement que les fuites cross-tenant sont impossibles ;
• L'accès direct à la base de données est interdit en production, hors administrateur dûment habilité.

7. Sauvegardes et restauration

• PITR (Point-In-Time Recovery) Supabase activé — restauration à n'importe quel point dans les 7 derniers jours ;
• Sauvegarde hors-site quotidienne chez un fournisseur distinct (Backblaze B2, région UE) : archive chiffrée en AES-256 avant l'envoi, déchiffrée et relue à chaque exécution pour vérifier qu'elle est restaurable, conservée 30 jours. Elle permet de tout restaurer même si l'accès à Supabase est perdu ;
• Backups quotidiens automatiques chiffrés, stockés en région distincte (résilience régionale) ;
• Test de restauration mensuel et automatisé : la dernière archive est téléchargée, déchiffrée et restaurée dans une base PostgreSQL jetable, puis les lignes sont comptées. Le résultat, réussite comme échec, remonte dans la supervision de l'espace d'administration (objectif : RTO < 4 h, RPO < 24 h — voir PRA/PCA) ;
• Sauvegardes hors-site purgées au-delà de 30 jours, pour respecter le principe de minimisation des données.

8. Journalisation et audit

• Logs d'authentification (succès et échecs) conservés 1 an ;
• Logs d'actions sensibles (création, modification, suppression utilisateur, paiement) conservés 1 an ;
• Logs requêtes SQL anonymisés via Supabase ;
• Logs Vercel (Edge / Functions) ;
• Alerting automatique sur événements suspects (échecs massifs, requêtes anormales, élévation de privilèges).

9. Mise à jour et gestion des vulnérabilités

• Suivi automatisé des CVE des dépendances : Dependabot (.github/dependabot.yml, passe hebdomadaire sur les deux manifestes npm et sur les actions GitHub) et GitHub Security Advisories ;
• Les Edge Functions sont en Deno et importent par URL : Dependabot ne sait pas les suivre. Leurs versions sont épinglées dans le code et relues à chaque modification — c'est une vérification humaine, et elle est nommée ici pour ne pas passer pour automatique ;
• Application des patches critiques sous 48 h, des patches élevés sous 7 jours — délais plus stricts que les 30 jours exigés par les conditions de garantie de l'assurance (§18) ;
• Mise à jour mineure mensuelle planifiée ;
• Veille sur les bulletins ANSSI / CERT-FR.

10. Sécurité du développement

• Revue de code obligatoire (Pull Request) sur les modifications critiques ;
• Tests automatisés (unitaires, intégration) sur chaque PR ;
• Tests dédiés aux policies RLS (cross-tenant) ;
• Pas de secret en clair dans le code (scans automatiques via GitHub) ;
• Environnements séparés : développement, staging, production ;
• Données réelles jamais utilisées en développement (datasets anonymisés).

11. Sécurité physique

L'infrastructure étant intégralement hébergée chez des prestataires cloud certifiés (Supabase / AWS Frankfurt — certifications ISO 27001, SOC 2 Type II ; Vercel — SOC 2), la sécurité physique est déléguée à ces opérateurs. MIBsoft ne dispose pas de salle serveur en propre.

Les locaux administratifs de MIBsoft disposent d'un contrôle d'accès et les postes de travail des collaborateurs sont :

• Chiffrés (FileVault macOS / BitLocker Windows / LUKS Linux) ;
• Protégés par mot de passe fort + verrouillage automatique ;
• Équipés d'antivirus / EDR ;
• Mis à jour automatiquement.

12. Sensibilisation et formation

• Sensibilisation RGPD et sécurité de tout nouveau collaborateur à l'arrivée ;
• Rappel annuel des bonnes pratiques (phishing, mot de passe, gestion des données) ;
• Engagement de confidentialité signé par tous les collaborateurs et prestataires.

13. Sous-traitants et chaîne de sécurité

MIBsoft sélectionne ses sous-traitants sur leurs garanties RGPD et sécurité (voir sous-traitants). Tous les sous-traitants principaux disposent de certifications reconnues (ISO 27001, SOC 2) et signent un DPA conforme.

Le cas de l'assistance par intelligence artificielle. Les fonctions d'aide à la rédaction (arbre des causes, visite de sécurité, cotation des risques) transmettent à Anthropic PBC le texte que l'utilisateur a saisi, et lui seul. La clé d'API reste côté serveur et n'est jamais exposée au navigateur ; les fonctions sont réservées aux utilisateurs authentifiés. C'est le seul transfert sortant de données de contenu de la plateforme, et il ne se produit que si un utilisateur le déclenche : l'application reste entièrement utilisable sans ces aides.

14. Tests de pénétration et audits

• Test d'intrusion par un prestataire externe spécialisé, déclenché à la demande d'un Client — référencement grand compte, revue de sécurité fournisseur, ou exigence d'un appel d'offres. Aucun test d'intrusion n'a été mené à ce jour ;
• Scope : application web, API, infra exposée, RLS ;
• Rapport sécurisé, anomalies corrigées selon criticité (critique : 48 h, élevée : 7 jours) ;
• Synthèse anonymisée disponible sur demande aux Clients sous NDA.

15. Conformité RGPD et réglementaire

La PSSI s'inscrit en cohérence avec :

• L'article 32 du RGPD (sécurité du traitement) ;
• Le référentiel guide CNIL de la sécurité des données personnelles ;
• Les recommandations ANSSI applicables aux PME numériques ;
• Les bonnes pratiques OWASP (Top 10).

16. Gestion des incidents

La gestion opérationnelle des incidents (cyber, fuites de données, attaques) est détaillée dans la Procédure de gestion des incidents.

17. Continuité d'activité

La continuité et la reprise d'activité sont décrites dans le PCA / PRA.

18. Conditions de garantie de l'assurance — check-list de conformité

Le module RC Pro souscrit auprès d'Hiscox SA (police QTPRC013940, Conventions Spéciales TECH0623) subordonne la garantie « Événement cyber » à trois conditions cumulatives. Leur portée n'est pas théorique :

« En cas de non-respect d'une des conditions définies ci-dessus, aucune indemnisation ne vous sera due, sauf si le manquement n'est pas à l'origine du sinistre, n'a pas contribué à sa survenance ou n'a pas contribué à son aggravation. La charge de la preuve vous incombe. »

La dernière phrase commande tout le reste. Il ne suffit pas d'être en règle : il faut pouvoir le démontrer après coup, sur la période où le sinistre est survenu. C'est pourquoi chaque ligne ci-dessous porte, en plus de la mesure, ce qui en fait la preuve.

18.1 Condition « Sauvegardes »

« Que les données et systèmes de l'assuré fassent l'objet de sauvegardes. »

• Mesure : sauvegarde quotidienne chiffrée vers Backblaze B2 (§7), PITR Supabase 7 jours, test de restauration mensuel automatisé.
• Preuve : une ligne par exécution dans monitoring_alerts (source sauvegarde-b2 / sauvegarde-storage), consultable depuis l'espace d'administration, et l'historique des exécutions GitHub Actions.
• Angle mort connu : l'alerte d'échec est écrite depuis l'intérieur du job. Un job qui ne démarre pas — quota GitHub Actions épuisé, panne de la plateforme — n'écrit rien : le tableau de bord affiche alors la dernière sauvegarde réussie et aucune anomalie. C'est arrivé les 29 et 30 août 2026, quota atteint, deux nuits sans sauvegarde et sans signal. Le silence ne prouve donc pas la sauvegarde, et la surveillance doit venir d'ailleurs que du job surveillé.

18.2 Condition « Mise à jour sous 30 jours »

« Que l'assuré mette à jour les logiciels et systèmes informatiques (y compris anti-virus et pare-feu) dans les 30 jours suivant la mise à disposition de patchs par le fabricant. »

• Mesure : Dependabot hebdomadaire (§9) sur les deux manifestes npm et sur les actions GitHub ; relecture humaine des versions épinglées des Edge Functions Deno.
• Preuve : les pull requests Dependabot et leurs dates de fusion. Une PR ouverte depuis plus de 30 jours est, en soi, la preuve du contraire — d'où l'intérêt de les fermer explicitement quand on écarte une mise à jour, en écrivant pourquoi.

18.3 Condition « A2F sur les accès d'administration »

« Que les administrateurs des systèmes informatiques de l'assuré aient la vérification en deux étapes (A2F/MFA) pour accéder aux ou gérer tous les accès à distance de ses systèmes informatiques y compris télétravail, accès à des applications, cloud ressources. »

• Mesure : MFA sur les six accès listés au §5.2 — Supabase, Vercel, Stripe, GitHub, Mailgun, Backblaze B2.
• Vérifié le 30 août 2026 sur sept accès : GitHub, Supabase, Vercel, Stripe, Mailgun, Backblaze B2 et IONOS. Ce dernier ne figure dans aucune clause et il est pourtant le plus sensible : il porte à la fois la boîte contact@mibsoft.fr, vers laquelle aboutissent toutes les réinitialisations de mot de passe, et la zone DNS de mibsoft.fr. Qui la contrôle redirige le domaine, obtient des certificats à ce nom et détourne le courrier — les six autres seconds facteurs deviendraient alors décoratifs.
• Preuve : capture datée de l'écran de sécurité de chaque compte, conservée hors du système d'information ; à refaire à chaque revue d'accès trimestrielle. Une capture prouve l'état du jour où elle est prise, pas celui d'un sinistre survenu six mois plus tard : c'est la série qui vaut, pas la pièce.
• Codes de secours conservés dans le gestionnaire de mots de passe, jamais dans la messagerie — l'y ranger reviendrait à remettre la clé sous le paillasson qu'on vient de verrouiller. Leur présence se vérifie pendant qu'on a encore l'accès : un second facteur perdu ne se constate qu'au moment où l'on voulait entrer.
• Retour d'expérience du 30/08/2026. L'activation a produit le jour même un blocage sur le second compte Mailgun (celui de gestion_ets). Sans conséquence — les envois passent par la clé d'API, pas par la console — mais la même mésaventure sur un compte de la plateforme empêcherait de révoquer une clé compromise, c'est-à-dire précisément le geste attendu le jour d'un sinistre. Deux comptes chez un même fournisseur apparaissent en outre sous le même nom dans l'application d'authentification : les renommer explicitement évite de saisir le code de l'un dans l'écran de l'autre.
• Point à faire trancher par l'assureur : les clés d'API et rôles de service (clé service_role Supabase, clé Mailgun, clés Stripe) n'ont par nature pas de second facteur. La clause vise « les administrateurs » ; il faut faire confirmer par écrit qu'elle ne s'étend pas aux accès applicatifs, faute de quoi aucun logiciel du marché ne pourrait la respecter.

18.4 Ce qui reste à obtenir de l'assureur

Demande adressée au courtier (Tiime Protect) le 30 août 2026, portant sur les points ci-dessous. La date compte autant que le contenu : en cas de sinistre, une question posée avant la souscription et restée sans réponse ne se plaide pas comme une question jamais posée. Les réponses écrites seront jointes au dossier dès réception, et cette section mise à jour.

Correction du 30/08/2026 au soir : cette section annonçait « neuf points » et n'en listait que cinq. Le courrier envoyé fait foi ; tout point qu'il porte et qui ne figure pas ici est à y reporter — une section qui compte faux se relit mal le jour où l'on cherche ce qui a été demandé.

• Déclaration d'activité. La police déclare : développement de logiciels, développement web et mobile, vente et paramétrage. Elle ne mentionne pas l'exploitation d'un service en ligne hébergeant les données de clients — c'est-à-dire l'activité réelle de MIBsoft, sous-traitant au sens de l'article 28 du RGPD. Une déclaration inexacte est sanctionnée par les articles L.113-8 et L.113-9 du Code des assurances, dont la nullité du contrat. À faire corriger ou confirmer par écrit avant toute signature.
• Exclusion « Data center ». Les garanties ne sont acquises qu'à condition de ne pas exercer dans ce domaine. MIBsoft n'exploite aucun centre de données — Supabase et Vercel le font — mais c'est une condition d'acquisition, pas une exclusion ordinaire : elle mérite un écrit.
• Périmètre de la garantie cyber. Obtenir le détail des postes couverts, en particulier les frais de notification aux personnes concernées et la gestion de crise : la procédure d'incidents engage MIBsoft à notifier la CNIL sous 72 h, les clients sous 48 h et, en cas de risque élevé, les personnes elles-mêmes.
• Sanctions administratives. Faire préciser si les amendes CNIL sont couvertes ou exclues. Aucun document de ce dossier n'affirmera qu'elles le sont tant que ce n'est pas écrit noir sur blanc.
• Seuil d'intelligence artificielle. L'intégration de solutions d'IA tierces est exclue au-delà d'un million d'euros de chiffre d'affaires. Sept Edge Functions appellent une IA tierce. Sans effet aujourd'hui — chiffre d'affaires déclaré 100 000 € — mais à rouvrir avant de franchir le seuil, pas après.
• Délai de déclaration d'un sinistre. Obtenir le délai contractuel, et à qui la déclaration s'adresse — le courtier ou l'assureur. C'est la question la plus opérationnelle des six, et elle manquait : la procédure d'incidents doit dire quoi faire dans l'heure, pas renvoyer à un contrat qu'on lira sous le choc. Tant que la réponse n'est pas écrite, cette procédure retient la règle prudente — déclarer sans attendre dès la qualification d'un P1.

19. Révision

La présente PSSI fait l'objet d'une revue annuelle minimum, et de mises à jour à la suite de tout incident significatif ou évolution majeure de l'architecture. Toute modification est validée par le RSSI et la direction.