Sécurité

Concerne le LMS Geduk, Geduk AI Scorm, le site geduk.fr et leurs infrastructures d'hébergement. Dernière mise à jour : octobre 2026.

Responsable de la sécurité

Vincent Lemaitre, fondateur et dirigeant de CVBSP Conseil et solution, est le responsable de la sécurité des systèmes d'information de Geduk. Il répond de la sécurité du code de la plateforme, des serveurs qui l'hébergent, des sauvegardes et du traitement des signalements de vulnérabilités. Geduk est conçu, développé et opéré par une équipe volontairement réduite : la personne qui écrit le code est aussi celle qui administre les serveurs et qui reçoit les signalements, sans intermédiaire.

Contact sécurité: vlemaitre@cvbsp.fr
Fichier security.txt: geduk.fr/.well-known/security.txt (norme RFC 9116)

Signaler une vulnérabilité

Si vous pensez avoir trouvé une faille de sécurité dans l'un de nos produits ou sur l'un de nos serveurs, écrivez-nous à l'adresse ci-dessus. Décrivez ce que vous avez observé, les étapes pour le reproduire et, si possible, l'impact que vous estimez. Nous n'avons pas de programme de prime, mais nous nous engageons à :

accuser réception sous deux jours ouvrés ;
vous tenir informé de la qualification du signalement et de la date de correction ;
ne pas engager de poursuites contre une personne qui a agi de bonne foi, sans dégrader le service ni accéder à des données au-delà de ce qui était nécessaire pour démontrer la faille, et qui nous laisse un délai raisonnable pour corriger avant toute publication ;
vous citer, si vous le souhaitez, lorsque la correction est publiée.

Périmètre

la plateforme de formation Geduk : app.geduk.fr et les instances dédiées opérées par CVBSP ;
l'outil Geduk AI Scorm : ai-scorm.geduk.fr ;
le site vitrine geduk.fr et ses outils gratuits ;
les serveurs qui hébergent ces services.

Hors périmètre : les tests de déni de service, l'envoi massif de courriels, l'ingénierie sociale visant nos clients ou leurs apprenants, et tout test sur une instance dédiée hébergée par un client sur ses propres serveurs sans l'accord de ce client.

Comment nous protégeons la plateforme

Hébergement

Les serveurs sont situés en France, chez OVH. Chaque client en instance dédiée dispose de sa propre base de données et de son propre espace de fichiers. Les sauvegardes sont quotidiennes, et une copie est conservée hors du serveur d'origine, chez un second hébergeur français. L'état des plateformes de production et la validité de leurs certificats sont contrôlés automatiquement chaque minute, avec alerte en cas d'anomalie.

Accès et authentification

Tous les échanges passent par HTTPS. Les mots de passe sont stockés sous forme hachée. La double authentification est disponible et peut être rendue obligatoire pour l'ensemble d'une plateforme. Les droits sont gérés par rôles et privilèges, et un utilisateur ne peut jamais attribuer un privilège qu'il ne détient pas lui-même. L'accès d'administration aux serveurs se fait exclusivement par clé SSH.

Développement

Chaque nouveau point d'entrée de l'API passe par une liste de contrôle d'autorisation et de cloisonnement entre organisations avant d'être mis en ligne. Les modifications sont testées sur des plateformes de recette distinctes de la production, puis déployées de façon programmée. Les dépendances sont mises à jour régulièrement et les secrets ne sont jamais versionnés avec le code.

Tests d'intrusion

CVBSP dispose d'une fonction interne de tests d'intrusion, distincte du développement courant et placée sous la responsabilité de Vincent Lemaitre, seul membre habilité à la mener. Elle teste le code du serveur, les plateformes de recette (*.dev.cvbsp.fr) et les serveurs de CVBSP, en boîte grise, avec des outils d'analyse statique et dynamique assistés par intelligence artificielle. Jamais sur les données des clients.

Chaque campagne donne lieu à un rapport : constats numérotés, gravité, preuve de concept, correctif et validation du correctif avant déploiement. Les failles non corrigées sont suivies dans un registre jusqu'à leur clôture. La dernière campagne a porté sur le serveur d'API du LMS en septembre 2026 : seize constats, dont les plus graves ont été corrigés et validés dans les jours qui ont suivi. Un rapport expurgé peut être communiqué sur demande à un client ou à un auditeur.

Règles d'engagement

Chaque campagne commence par une fiche de mission écrite : cibles (noms d'hôte, adresses IP, dépôts), méthode, exclusions et fenêtre de dates. Elle est approuvée par le responsable de la sécurité, qui est aussi le propriétaire des systèmes testés, avant tout premier test.
Les tests actifs ne visent que les plateformes de recette *.dev.cvbsp.fr, alimentées en données fictives. Sur les serveurs de production, seule la revue de configuration en lecture est autorisée ; aucune donnée client n'est manipulée.
Les constats sont consignés le jour même dans le registre des vulnérabilités, avec gravité et piste de correction, et rapportés au propriétaire du système sous cinq jours ouvrés.
Un correctif n'est déployé qu'après validation sur la plateforme de recette ; la fiche de mission est close quand tous les constats élevés et critiques sont corrigés ou acceptés par écrit.
Les tests qui touchent des clients hébergeant eux-mêmes leur instance ne sont menés qu'avec leur accord écrit.

Données personnelles

Ce que le site collecte est décrit sur la page Données personnelles et cookies. Les données des apprenants hébergées sur la plateforme sont encadrées par les contrats conclus avec les organisations clientes et ne quittent pas la France.