Politique de Sécurité des Systèmes d'Information

1. Objet et périmètre

La présente politique fixe les règles de sécurité applicables aux systèmes d'information de LAYOR YABAG EAST, notamment à la plateforme LMS qu'elle édite et exploite sous la marque Floreal. Floreal désigne ci-après ce produit et non une entité juridique distincte. Elle a pour objectifs de protéger la confidentialité, l'intégrité et la disponibilité des données confiées par les clients (organisations utilisatrices, formateurs, apprenants) et des données internes de l'entreprise.

Elle s'applique à :

• l'ensemble des salariés, dirigeants, stagiaires et alternants de LAYOR YABAG EAST ;
• les prestataires et indépendants intervenant sur la plateforme ou ayant accès aux données ;
• l'ensemble des actifs : plateforme Floreal (API, front web, worker IA), infrastructure cloud, dépôts de code, outils SaaS internes, postes de travail.

Le Trust Center public est la déclinaison externe de cette politique. En cas de divergence, la présente PSSI fait foi en interne et le Trust Center est mis à jour.

2. Organisation et responsabilités

Les fonctions RSSI et référent données sont cumulées par la même personne compte tenu de la taille de l'entreprise. Ce cumul sera réexaminé à partir de 10 collaborateurs.

3. Classification des données

Les données des apprenants sont des données personnelles au sens du RGPD. Elles sont traitées pour le compte des organisations clientes, LAYOR YABAG EAST agissant en qualité de sous-traitant au sens de l'article 28.

4. Gestion des accès et des identités

4.1 Principes

• Chaque accès est nominatif. Les comptes partagés sont interdits.
• Moindre privilège : chaque personne dispose uniquement des droits nécessaires à ses missions.
• Authentification multifacteur : son déploiement est planifié d'ici le 31/12/2026 sur la console AWS, le compte racine AWS, GitHub, le gestionnaire de mots de passe, la messagerie professionnelle et les comptes fournisseurs (OpenAI, Pinecone, Customer.io, Stripe, Sentry), en commençant par le compte racine AWS et GitHub.
• Le compte racine AWS n'est utilisé qu'en cas de nécessité absolue ; les opérations courantes passent par des rôles IAM.

4.2 Cycle de vie

• Arrivée : création des accès sur demande du RSSI, après signature du contrat et de l'engagement de confidentialité, et lecture de la présente PSSI.
• Changement de poste : révision des droits dans les 5 jours ouvrés.
• Départ : révocation de tous les accès le jour du départ, rotation des secrets auxquels la personne a eu accès dans les 7 jours.
• Revue : revue trimestrielle de l'ensemble des comptes et droits (AWS IAM, Cognito, GitHub, SaaS), consignée par le RSSI.

4.3 Accès applicatif

• L'authentification des utilisateurs de la plateforme repose sur Amazon Cognito. Les mots de passe ne sont jamais stockés par Floreal.
• Le contrôle d'accès est fondé sur les rôles (RBAC) et sur l'isolation stricte par organisation cliente (multi-tenant) : aucune requête ne peut lire les données d'une autre organisation.
• Les sessions expirent automatiquement. Les jetons d'API ont une durée de vie limitée.
• L'accès du personnel aux données clients est limité au support technique et aux obligations légales. Chaque accès est journalisé.

5. Mots de passe et secrets

• Les mots de passe personnels sont générés et stockés dans un gestionnaire de mots de passe d'entreprise. Longueur minimale 16 caractères, uniques par service.
• Les secrets applicatifs (clés d'API, identifiants de base de données, clés de signature) sont stockés dans AWS Secrets Manager et injectés à l'exécution. Ils ne figurent jamais dans le code source, les fichiers de configuration versionnés, les tickets ou les messageries.
• Les fichiers d'environnement locaux sont exclus du versionnement et contiennent uniquement des valeurs de développement.
• Rotation : clés d'API fournisseurs et identifiants de base de données au moins une fois par an, et immédiatement en cas de suspicion de compromission ou de départ d'une personne y ayant eu accès.
• Toute fuite de secret, même supposée, est traitée comme un incident de sécurité (section 11).

6. Sécurité des postes de travail

Chaque poste utilisé pour accéder au code, à l'infrastructure ou aux données clients respecte :

• chiffrement intégral du disque (FileVault ou BitLocker) ;
• verrouillage automatique après 5 minutes d'inactivité ;
• mises à jour du système et des navigateurs appliquées sous 15 jours ;
• pare-feu système activé ;
• compte utilisateur sans droits administrateur pour l'usage quotidien ;
• aucune donnée client stockée localement de façon durable ; les exports sont supprimés après usage ;
• usage des réseaux Wi-Fi publics uniquement via VPN ou partage de connexion mobile.

Les téléphones ayant accès à la messagerie professionnelle sont protégés par code ou biométrie et peuvent être effacés à distance.

7. Sécurité de l'infrastructure et de l'hébergement

7.1 Hébergement

• L'ensemble des données clients est hébergé chez Amazon Web Services, région Paris (eu-west-3). Aucune donnée client n'est stockée hors de l'Union européenne par LAYOR YABAG EAST.
• L'infrastructure est décrite et déployée en code (Terraform). Toute modification passe par une revue avant application.
• Trois environnements distincts et isolés : développement, préproduction, production. Les environnements de développement et de préproduction n'utilisent jamais de données réelles de production.

7.2 Mesures techniques

• Chiffrement au repos : bases de données RDS, compartiments S3 et sauvegardes chiffrés en AES-256 avec clés gérées par AWS KMS.
• Chiffrement en transit : TLS 1.2 minimum sur toutes les interfaces, certificats gérés par AWS Certificate Manager.
• Réseau : la base de données est hébergée dans le VPC du Prestataire, protégée par un groupe de sécurité et une authentification par identifiants stockés dans AWS Secrets Manager, avec connexions chiffrées. Son passage en sous-réseau privé sans accès public, avec exécution de l'API à l'intérieur du VPC, est planifié d'ici le 31/12/2026. Les compartiments S3 ont le blocage d'accès public activé.
• Journalisation : CloudWatch pour les journaux applicatifs et d'infrastructure, conservation 90 jours minimum ; alarmes CloudWatch sur les erreurs et la disponibilité.
• Supervision des erreurs : Sentry pour la capture des erreurs applicatives, sans données personnelles dans les événements envoyés.
• Sauvegardes : sauvegardes automatiques quotidiennes de la base de données RDS, chiffrées avec la clé KMS dédiée, conservées 7 jours, avec restauration possible à un instant donné (point-in-time recovery). Les sauvegardes sont stockées par AWS de façon redondante sur plusieurs zones de disponibilité. Les compartiments S3 ont le versionnement activé. Un test de restauration est réalisé au moins une fois par an.

7.3 Continuité

• Objectif de reprise (RTO) : 24 heures. Objectif de perte de données maximale (RPO) : 24 heures, et de l'ordre de 5 minutes grâce à la restauration à un instant donné de RDS.
• L'instance de base de données de production est déployée en zone de disponibilité unique ; le passage en Multi-AZ est évalué chaque année en fonction des engagements de disponibilité contractuels.
• La reconstruction complète de l'infrastructure est possible depuis le code Terraform et les sauvegardes.

8. Développement sécurisé

• Le code source est hébergé sur GitHub dans des dépôts privés, avec accès nominatifs.
• Toute modification destinée à la production fait l'objet d'une revue de code par une seconde personne, ou d'une revue assistée documentée lorsque l'équipe est réduite à une personne.
• Les dépendances sont surveillées (alertes de vulnérabilité GitHub) et mises à jour selon la criticité : vulnérabilité critique sous 7 jours, haute sous 30 jours.
• Les entrées utilisateur sont validées côté serveur ; les requêtes en base passent par un ORM paramétré pour prévenir les injections.
• Les développements suivent les recommandations OWASP Top 10. Des analyses automatisées sont exécutées sur le code.
• Les déploiements en production sont tracés (qui, quoi, quand) et réversibles.

9. Intelligence artificielle et traitement des données

• Les fonctions d'IA de la plateforme (tuteur IA pour les apprenants, assistance à la création et à la mise en forme de contenus de formation, recherche sémantique dans les contenus) font appel aux fournisseurs externes listés en section 10.
• Les données envoyées aux fournisseurs d'IA sont limitées au strict nécessaire au traitement demandé. Les contrats et paramètres retenus excluent l'utilisation des données pour l'entraînement des modèles.
• Aucune donnée client n'est conservée par les fournisseurs d'IA au-delà de la durée nécessaire au traitement, selon leurs engagements contractuels respectifs.
• Les réponses et suggestions produites par l'IA sont des aides pédagogiques. Elles ne prennent aucune décision automatisée produisant des effets juridiques sur les apprenants ; l'évaluation et la validation des parcours restent sous le contrôle des formateurs.
• Les échanges entre apprenants et tuteur IA sont classés Confidentiel et soumis aux règles de rétention de la section 12.

10. Sous-traitants et fournisseurs

LAYOR YABAG EAST fait appel aux prestataires suivants. Chacun est lié par un contrat incluant des clauses de protection des données (DPA). La liste est revue à chaque ajout de fournisseur et au minimum une fois par an. Elle est reprise à l'identique dans le registre des traitements.

Les transferts hors UE reposent sur les clauses contractuelles types de la Commission européenne ou sur le Data Privacy Framework UE-États-Unis lorsque le fournisseur y est certifié.

LAYOR YABAG EAST ne recourt à aucune co-traitance. Tout nouveau sous-traitant ayant accès à des données clients fait l'objet d'une évaluation (localisation, certifications, DPA) et d'une information préalable des clients conformément à l'article 28 du RGPD.

11. Gestion des incidents de sécurité

11.1 Définition

Constitue un incident tout événement portant ou susceptible de porter atteinte à la confidentialité, l'intégrité ou la disponibilité des données ou des systèmes : accès non autorisé, fuite de secret, perte de données, indisponibilité prolongée, vulnérabilité exploitée, poste compromis, hameçonnage réussi.

11.2 Procédure

Les clients sont informés même en cas de doute, puis tenus au courant jusqu'à clôture. Aucun incident n'est clos sans mesure corrective documentée.

12. Conservation et suppression des données

• Comptes actifs : données conservées pendant toute la durée du contrat.
• Comptes inactifs depuis plus de 6 mois : notification au client, puis suppression 30 jours après en l'absence de réponse.
• Résiliation : période de 90 jours pendant laquelle le client peut exporter ses données, puis suppression automatique.
• Sauvegardes : purgées selon leur cycle de 7 jours, ce qui constitue le délai maximal de persistance après suppression.
• Journaux techniques : 90 jours, puis suppression.
• Les demandes d'exercice de droits (accès, rectification, effacement, portabilité) sont traitées sous 30 jours. LAYOR YABAG EAST assiste ses clients responsables de traitement dans leurs réponses aux apprenants.

13. Sensibilisation et engagement

• Toute personne couverte par cette politique la lit et en accuse réception par écrit avant de recevoir ses accès.
• Un rappel des règles essentielles (hameçonnage, mots de passe, secrets, signalement) est fait au moins une fois par an et à chaque mise à jour majeure de la PSSI.
• Les prestataires reçoivent la présente politique en annexe de leur contrat.

14. Conformité

LAYOR YABAG EAST est conforme au RGPD et tient un registre des traitements.

15. Sanctions

Le non-respect de la présente politique peut entraîner des mesures disciplinaires pour les salariés, conformément au règlement intérieur et au Code du travail, et la résiliation du contrat pour les prestataires.

16. Révision

La PSSI est revue au moins une fois par an, et à chaque changement significatif : nouvel hébergeur, nouveau sous-traitant traitant des données clients, incident majeur, évolution réglementaire. Chaque version est datée, numérotée et archivée.