Pourquoi l’IA déstabilise la conformité des SPST
Les SPST traitent par nature des données sensibles à grande échelle : dossiers médicaux en santé au travail (DMST), données d’exposition professionnelle, correspondances entre professionnels de santé, données d’identification des adhérents et de leurs salariés. L’introduction de briques d’IA dans cet écosystème, qu’il s’agisse d’aide à la décision médicale, d’analyse prédictive des risques professionnels, de transcription automatique des entretiens infirmiers ou de tri intelligent des convocations, crée trois tensions majeures avec le RGPD.
Première tension : l’opacité des modèles. Les systèmes fondés sur l’apprentissage profond produisent des résultats dont la logique reste difficilement explicable, y compris pour leurs concepteurs. Or l’article 22 du RGPD encadre strictement les décisions individuelles automatisées et impose un droit à une intervention humaine ainsi qu’une obligation d’information compréhensible. Pour un SPSTI, recourir à un outil d’IA dont les sorties influencent le suivi médical d’un travailleur sans pouvoir expliquer les critères de recommandation expose directement à un manquement.
Deuxième tension : la minimisation des données. Les modèles d’IA performants réclament de grandes quantités de données pour leur entraînement ou leur affinage. Ce besoin entre frontalement en conflit avec l’article 5(1)(c) du RGPD qui impose de limiter les données collectées au strict nécessaire. Dans un SPSTI, la tentation d’alimenter un modèle avec l’intégralité du DMST pour « en tirer des insights » doit être systématiquement écartée.
Troisième tension : la base légale. Le DMST repose sur l’article 9(2)(h) du RGPD, qui autorise le traitement de données de santé aux fins de la médecine du travail et de l’appréciation de la capacité de travail. Cette base légale ne couvre pas automatiquement les traitements accessoires à finalité d’entraînement d’un modèle d’IA. Toute réutilisation secondaire exige une nouvelle analyse de compatibilité au sens de l’article 6(4) du RGPD.
Cartographier les usages d’IA dans le SPSTI
Premier chantier opérationnel pour le DPO : dresser une cartographie exhaustive des usages réels et projetés de l’IA au sein du SPSTI. Cette cartographie doit couvrir :
- Les outils intégrés au logiciel médical (suggestions de codage, détection d’anomalies dans les constantes, aide à la rédaction de la fiche d’entreprise) ;
- Les outils utilisés en périphérie (transcription de consultations, assistants conversationnels généralistes, outils de traduction automatique) ;
- Les outils utilisés par les fonctions support (tri de CV, détection de fraude sur les déclarations, chatbots adhérents) ;
- Les outils en cours de test ou envisagés dans la prochaine feuille de route.
À retenir. Un usage non déclaré est un usage non maîtrisé. La circulation d’outils d’IA grand public sur les postes des professionnels de santé, à l’initiative individuelle, constitue aujourd’hui le risque le plus sous-estimé dans les SPSTI.
Qualifier chaque usage au regard de l’AI Act
L’AI Act (Règlement UE 2024/1689) s’applique par paliers. Pour chaque usage identifié, le DPO doit déterminer sa catégorie de risque :
- Risque inacceptable (art. 5 AI Act) : pratiques interdites, notamment la notation sociale et la reconnaissance des émotions sur le lieu de travail, sauf exceptions strictes. Un outil prétendant évaluer l’état émotionnel d’un salarié pendant un entretien serait ici directement concerné.
- Risque élevé (art. 6 et annexe III) : systèmes d’IA utilisés dans l’emploi et la gestion de la main-d’œuvre, y compris pour évaluer les performances ou prendre des décisions affectant la relation de travail. La plupart des outils d’aide à la décision dans un SPSTI relèvent de cette catégorie.
- Risque limité : obligations de transparence (informer la personne qu’elle interagit avec une IA).
- Risque minimal : aucune obligation spécifique, bonnes pratiques recommandées.
À retenir. Un outil d’IA utilisé pour préparer un avis d’aptitude ou pour orienter une visite de reprise relève très probablement du risque élevé. Les obligations de l’AI Act viennent alors se superposer à celles du RGPD.
L’AIPD comme pivot méthodologique
L’AIPD (Analyse d’Impact relative à la Protection des Données, art. 35 RGPD) est déjà obligatoire pour le DMST, confirmée par la CNIL dans son guide SPST. L’ajout d’une brique d’IA à un traitement déjà couvert par une AIPD impose systématiquement sa révision.
La méthodologie recommandée suit quatre temps :
- Description détaillée du traitement enrichi d’IA. Finalités, flux de données, durées de conservation, transferts, acteurs (responsable de traitement, sous-traitant, fournisseur du modèle).
- Évaluation de la nécessité et de la proportionnalité. La brique IA apporte-t-elle une valeur ajoutée démontrable au regard des risques induits ? Une alternative moins intrusive existe-t-elle ?
- Analyse des risques pour les personnes concernées. Risques de biais, de décision erronée, de réidentification, de fuite, de détournement de finalité, de perte de contrôle humain.
- Mesures de maîtrise. Pseudonymisation, limitation des accès, supervision humaine documentée, processus de recours, journalisation, audit régulier du modèle.
Cette AIPD doit être co-signée par le médecin du travail coordonnateur, le responsable de la sécurité des systèmes d’information et le DPO. Elle reste un document vivant, révisable à chaque mise à jour significative du modèle.
L’information des personnes concernées
L’information due au titre des articles 13 et 14 du RGPD s’enrichit lorsque l’IA entre en scène. La notice d’information remise au travailleur lors de sa première visite doit désormais préciser :
- L’existence d’un traitement automatisé lorsqu’il produit des effets significatifs sur la personne ;
- La logique sous-jacente, de manière compréhensible par un non-spécialiste ;
- Les conséquences envisagées du traitement ;
- Les modalités d’exercice du droit à une intervention humaine.
L’AFNOR SPEC 2217 (§ 4) impose par ailleurs au SPSTI d’assurer une information complète des employeurs et des salariés sur toutes les actions utilisant ou générant des données personnelles, y compris en télésanté. L’introduction d’un assistant IA dans le parcours de visite entre pleinement dans ce périmètre.
À retenir. Une notice qui se contente de mentionner « utilisation d’outils informatiques » ne satisfait plus aux exigences combinées du RGPD et de l’AI Act lorsqu’un système d’IA à risque élevé intervient dans le suivi du travailleur.
Encadrer la sous-traitance et les fournisseurs d’IA
La plupart des fonctionnalités d’IA arrivent dans les SPSTI par l’intermédiaire d’éditeurs tiers : éditeur du logiciel médical, fournisseur de transcription, plateforme d’analyse des expositions. Le cadre contractuel doit être renforcé sur trois points :
Article 28 du RGPD, Contrat de sous-traitance. Le contrat doit documenter précisément le périmètre des traitements, les instructions documentées du responsable de traitement, l’interdiction de réutiliser les données pour entraîner des modèles sans accord explicite et formalisé, et les mesures de sécurité.
Obligations AI Act pour les déployeurs. En tant que déployeur d’un système d’IA à risque élevé, le SPSTI doit s’assurer que le fournisseur respecte ses propres obligations (documentation technique, gestion des risques, qualité des données d’entraînement, transparence, supervision humaine, cybersécurité). Une clause contractuelle dédiée devient indispensable.
Référentiels ANS et hébergement. Toute brique d’IA qui touche aux données de santé doit être hébergée sur un système conforme aux référentiels de l’Agence du numérique en santé. Le recours à des API externes non certifiées, même pour des tâches apparemment annexes, constitue un point de rupture de conformité.
À retenir. Un éditeur qui refuse de documenter précisément où et comment les données transitent dans son chaîne d’IA est un signal d’alerte à traiter sans délai.
Sensibilisation et gouvernance interne
Les meilleures AIPD et les meilleurs contrats ne résistent pas à une pratique non sensibilisée. Le DPO doit organiser trois niveaux d’action :
Niveau stratégique. La direction du SPSTI formalise une politique d’usage de l’IA, validée par la commission de contrôle, qui fixe les usages autorisés, les usages interdits et le processus de validation des nouveaux outils. Cette politique est annexée au registre des activités de traitement.
Niveau opérationnel. Les professionnels de santé et les équipes support reçoivent une formation spécifique couvrant : reconnaissance d’un usage d’IA, règles de non-saisie de données identifiantes dans les outils grand public, principe de supervision humaine, procédure d’alerte en cas de résultat suspect.
Niveau individuel. Chaque nouveau collaborateur signe une charte d’usage du numérique intégrant un volet IA. Cette charte précise les outils validés, les outils interdits, les règles de confidentialité spécifiques et les sanctions applicables.
Référentiel applicable. L’exigence de sensibilisation découle à la fois de l’article 39 du RGPD (missions du DPO), de l’AFNOR SPEC 2217 et, pour les systèmes d’IA à risque élevé, de l’article 26 de l’AI Act qui impose aux déployeurs de confier la supervision à des personnes disposant de la compétence, de la formation et de l’autorité nécessaires.
Journalisation, audit et mesure de la conformité
La conformité en matière d’IA ne se démontre pas par une déclaration d’intention mais par des traces. Le SPSTI doit mettre en place :
- Un journal des usages d’IA à risque élevé, alimenté automatiquement lorsque le système le permet ;
- Un tableau de bord semestriel des écarts et incidents, présenté en commission de contrôle ;
- Un audit annuel ciblé sur au moins un système d’IA à risque élevé, conduit par le DPO ou par un prestataire indépendant ;
- Un processus de revue des biais à chaque mise à jour majeure du modèle.
Ces éléments alimentent le rapport annuel du DPO et peuvent être mobilisés en cas de contrôle CNIL ou d’audit de certification SPEC 2217.
Feuille de route pour les douze prochains mois
Pour un SPSTI qui découvre ces exigences, la priorisation suivante a fait ses preuves sur le terrain :
- Mois 1 à 2. Cartographie des usages d’IA actifs et projetés. Inventaire des clauses contractuelles existantes.
- Mois 3 à 4. Qualification AI Act de chaque usage. Identification des usages à risque élevé et des usages à suspendre.
- Mois 5 à 6. Révision de l’AIPD du DMST pour intégrer les briques d’IA concernées. Mise à jour de la notice d’information.
- Mois 7 à 8. Renégociation des clauses de sous-traitance avec les éditeurs. Documentation ANS pour les hébergements.
- Mois 9 à 10. Rédaction de la politique interne d’usage de l’IA. Formation des professionnels de santé et des équipes support.
- Mois 11 à 12. Premier audit de conformité IA, intégration au rapport annuel du DPO.
À retenir
L’IA n’abroge pas le RGPD, elle en démultiplie les exigences. Pour un SPSTI, la conformité passe par la convergence du guide CNIL SPST, de l’AFNOR SPEC 2217, du RGPD et de l’AI Act au sein d’une même gouvernance. Le DPO devient l’architecte de cette convergence, en articulant cartographie, AIPD, contractualisation et sensibilisation.
Trois réflexes à ancrer dès aujourd’hui :
- Ne laisser aucun usage d’IA s’installer sans qualification préalable de son niveau de risque.
- Traiter toute brique d’IA touchant au DMST comme un traitement à risque élevé par défaut, sauf démonstration contraire documentée.
- Rendre visible la supervision humaine dans les procédures, les contrats et l’information des personnes concernées.
La conformité IA ne se décrète pas, elle se construit traitement par traitement, outil par outil, avec la discipline méthodologique qui fait la force du métier de DPO.



































