Un centre de formation médicale : chiffrer les évaluations envoyées à un LMS

Une évaluation de compétences professionnelles dans le domaine de la santé n’est pas une donnée anodine : elle peut révéler des lacunes précises d’un praticien sur un geste technique, une information sensible tant pour la personne évaluée que pour l’établissement qui l’emploie. Un centre de formation médicale qui transmet ce type d’évaluation à une plateforme d’apprentissage externe, un LMS spécialisé dans le suivi de compétences professionnelles de santé, doit traiter cette transmission avec un niveau d’exigence supérieur à une simple synchronisation de contenu pédagogique classique.

La checklist qui suit couvre les deux couches de chiffrement nécessaires sur ce type d’intégration : le chiffrement en transit, entre le site WordPress du centre de formation et l’API du LMS externe, et le chiffrement au repos, une fois la donnée arrivée et stockée côté plateforme tierce. Les deux couches sont indispensables et ne se substituent pas l’une à l’autre.

Chiffrement en transit : ce qui est déjà acquis, ce qui ne l’est pas

Le chiffrement en transit via HTTPS, obligatoire pour tout appel d’API vers le LMS, protège la donnée pendant son trajet réseau contre une interception. C’est une condition nécessaire mais largement insuffisante à elle seule :

• Vérifier que l’appel wp_remote_post() vers l’API du LMS utilise systématiquement une URL en https://, jamais de repli possible vers du HTTP non chiffré.
• Désactiver explicitement toute option qui ignorerait la vérification du certificat TLS du serveur distant, un réglage parfois activé par erreur pour contourner un problème de certificat en environnement de test, et oublié en production.
• Vérifier que le contenu de l’évaluation ne transite jamais en clair dans un paramètre d’URL (GET), qui se retrouverait journalisé par des serveurs proxy intermédiaires, mais uniquement dans le corps chiffré de la requête POST.

Chiffrement au repos : la question à poser au LMS

Le chiffrement en transit s’arrête au moment où la donnée atteint les serveurs du LMS. Ce qui se passe ensuite dépend entièrement des garanties offertes par la plateforme externe, qu’il faut vérifier explicitement plutôt que supposer :

• La donnée est-elle stockée chiffrée au repos sur les serveurs du LMS, ou uniquement protégée par un contrôle d’accès applicatif ?
• Qui, chez l’éditeur du LMS, dispose d’un accès technique aux données brutes en cas de support ou de maintenance ?
• Quelle est la durée de conservation contractuelle de ces évaluations, et existe-t-il une procédure de suppression sur demande ?

Ces questions, documentées dans un registre de sous-traitance tenu par le centre de formation, conditionnent le choix même du LMS retenu, indépendamment de ses qualités pédagogiques par ailleurs.

Chiffrer une couche supplémentaire côté source avant l’envoi

Au-delà des garanties du LMS lui-même, une protection supplémentaire consiste à chiffrer le contenu le plus sensible de l’évaluation avant même son envoi, avec une clé connue uniquement du centre de formation :

function preparer_evaluation_pour_lms( $evaluation ) {
    $contenu_sensible = wp_json_encode( array(
        'commentaires_evaluateur' => $evaluation['commentaires'],
        'points_a_ameliorer'      => $evaluation['points_faibles'],
    ) );

    $nonce   = random_bytes( SODIUM_CRYPTO_SECRETBOX_NONCEBYTES );
    $chiffre = sodium_crypto_secretbox( $contenu_sensible, $nonce, CLE_CHIFFREMENT_EVALUATIONS );

    return array(
        'praticien_id'     => $evaluation['praticien_id'],
        'score_global'     => $evaluation['score_global'], // non sensible, transmis en clair
        'contenu_chiffre'  => base64_encode( $nonce . $chiffre ),
    );
}

Le score global, jugé non sensible en lui-même par le centre de formation, reste transmis en clair pour permettre au LMS d’afficher les tableaux de bord attendus par les formateurs. Le contenu qualitatif le plus sensible, commentaires détaillés et points faibles identifiés, voyage chiffré, et ne redevient lisible qu’après déchiffrement côté centre de formation, jamais côté LMS lui-même.

Encadrer contractuellement ce qui ne peut pas être vérifié techniquement

Toutes les garanties ne peuvent pas être vérifiées techniquement depuis le site WordPress du centre de formation. La checklist se termine donc par un volet contractuel, complémentaire du volet technique :

1. Un accord de traitement des données signé avec l’éditeur du LMS, précisant la nature des données transmises.
2. Une clause de notification en cas d’incident de sécurité affectant les données du centre de formation.
3. Une procédure documentée de récupération et de suppression des données en cas de fin de contrat avec le LMS.

Le chiffrement technique protège la donnée pendant son trajet et pendant son stockage ; seul un engagement contractuel clair protège ce qui se passe une fois que la donnée est entre les mains d’un tiers.

Checklist récapitulative

Avant toute mise en production d’une intégration de ce type, l’ensemble des points suivants doit être coché : HTTPS strict sans repli possible, absence de donnée sensible en paramètre d’URL, garanties de chiffrement au repos vérifiées auprès du LMS, chiffrement applicatif supplémentaire sur le contenu qualitatif le plus sensible, et encadrement contractuel formalisé du traitement des données. Aucun de ces points, pris isolément, ne suffit à garantir la confidentialité attendue pour ce type d’évaluation professionnelle de santé.