L'IA dans le domaine QHSE : ce qu'elle fait vraiment bien, et où vont vos données

Tous les éditeurs de logiciels QHSE proposent désormais une présentation sur l'IA. Mais très peu d'entre eux sont en mesure de vous expliquer où aboutissent vos rapports d'incident une fois que le modèle les a analysés. Cette deuxième question est plus importante que la première, car les dossiers relatifs aux accidents et à la santé au travail ne sont pas des données d'entreprise ordinaires, et parce que la réglementation régissant l'utilisation de l'IA au travail a encore évolué cet été.

Ce que l'IA fait réellement bien aujourd'hui dans le domaine QHSE

Si l'on fait abstraction des démonstrations, il existe actuellement trois types de tâches pour lesquelles un modèle linguistique a toute sa place dans un système QHSE. Ces trois tâches suivent le même schéma : on reçoit une grande quantité de texte non structuré, et un humain doit le transformer en un format structuré avant que l'on puisse en tirer quoi que ce soit d'utile.

Trier ce qui arrive

Un quasi-accident signalé depuis un entrepôt à 6 h du matin se présente sous la forme de trois phrases tapées sur un téléphone. Quelqu’un doit déterminer s’il s’agit d’un quasi-accident ou d’un incident, à quel site et à quel processus il se rapporte, à quelle catégorie de risques il appartient, et qui doit en assumer la responsabilité. Un modèle effectue ce triage avec efficacité et cohérence, ce qui pose justement des difficultés aux humains sur douze sites et dans quatre langues différentes. Laissez l’humain intervenir à l’étape de validation : le modèle fait une proposition, le responsable QHSE la confirme.

Résumer un rapport d'audit ou un long document

Un audit interne génère quarante pages de notes que seules trois personnes liront jamais. Un modèle transforme le tout en une liste de constatations, un classement par niveau de gravité et un projet de plan d'action en quelques secondes. Le gain ne réside pas dans le temps gagné à la rédaction. Il réside dans le fait que le résumé soit effectivement produit, au lieu de rester dans un dossier jusqu'à la prochaine revue de direction.

Lire ce qui n'a jamais été tapé

« OCR plus un modèle » est le grand gagnant discret parmi les trois. Fiches de données de sécurité, certificats de fournisseurs, plaques signalétiques d’équipements, fiches d’inspection manuscrites, autorisations numérisées : tout cela constitue du texte que votre système ne peut actuellement pas analyser. Le simple fait d’extraire les dates d’expiration des certificats de fournisseurs permet d’éliminer toute une tâche de suivi manuel, et c’est précisément le genre de travail qui est négligé en silence lorsque personne n’a le temps de s’en occuper.

Ce qu'il ne fait toujours pas bien

Prédire les accidents. Les fournisseurs proposent des analyses prédictives en matière de sécurité sur la base d’ensembles de données bien trop restreints et bien trop biaisés pour étayer ces prédictions. Un site ayant enregistré onze incidents en trois ans ne contient aucun signal prédictif, et un modèle chargé d’en trouver un produira malgré tout une réponse avec un haut niveau de confiance. Considérez toute affirmation prédictive comme une question relative aux données d’apprentissage : combien d’événements, sur quelle période, provenant de combien de sites comparables ?

Prendre une décision de manière autonome. Clôturer une action corrective, juger qu’une constatation d’audit est conforme, valider un permis de travail : ce sont là des décisions relevant de la responsabilité. Quelqu’un doit en assumer la responsabilité en son nom propre, et cette personne ne peut pas être un « modèle ». Il ne s’agit pas seulement d’une bonne pratique. Si votre système évalue le comportement des travailleurs, c’est également là que se concentre le risque réglementaire, comme nous le verrons ci-dessous.

Travailler hors contexte. Un modèle général ne connaît ni votre taxonomie des risques, ni vos codes de site, ni la différence entre la manière dont votre équipe de maintenance et votre équipe SSE utilisent le terme « incident ». Sans ces bases, il génère des réponses qui semblent correctes mais qui classifient à tort. La solution réside dans l'exploitation de vos propres données structurées, et non dans un modèle plus volumineux.

Pourquoi vos données QHSE relèvent d'une catégorie juridique plus stricte

C’est la partie que la plupart des discussions sur les achats liés à l’IA ont tendance à négliger. En vertu du règlement général sur la protection des données ( RGPD), les données relatives à la santé constituent une catégorie particulière de données à caractère personnel au sens de l’article 9, et leur traitement est interdit sauf si une exception spécifique s’applique. Dans le contexte de l’emploi, la voie habituelle est celle de l’exception relative aux obligations relevant du droit du travail et de la sécurité sociale. Cette voie est soumise à des conditions : elle n’est ouverte que lorsque le droit de l’Union ou celui d’un État membre, ou encore une convention collective, autorise le traitement et prévoit des garanties appropriées. Le traitement à caractère purement médical relève d’une autre exception encore et, en France, relève de la compétence du service de médecine du travail dans le cadre du secret médical. Votre délégué à la protection des données (DPD) devrait confirmer sur quelle base juridique repose chacun de vos registres QHSE, car ils ne s’appuient pas tous sur la même.

Voyons ce que recouvre concrètement un système QHSE. Un rapport d’accident cite le nom d’un salarié, décrit une blessure et consigne souvent le suivi. Un dossier de maladie professionnelle contient, par définition, des données de santé. Un registre d’exposition établit un lien entre un salarié identifié et un agent cancérigène ou chimique sur plusieurs années. Une restriction d’aptitude au travail est une limitation professionnelle enregistrée au nom d’une personne identifiée, découlant d’un avis médical dont votre organisation ne dispose pas elle-même. Aucune de ces informations ne relève des données opérationnelles courantes, et aucune ne devrait être traitée avec la même désinvolture qu’un tableau de suivi de projet.

Il en découle trois conséquences pratiques, qui s'appliquent que vous intégriez ou non l'IA :

• L'accès doit être véritablement restreint, en fonction du rôle, du site et du service, et non pas selon une convention de dossiers partagés que tout le monde a fini par délaisser.
• Les modifications doivent pouvoir être retracées. Qui a modifié la description d'un accident du travail, et quand ? C'est une question qui vous sera tôt ou tard posée, que ce soit par un inspecteur, par un comité d'entreprise ou par un avocat.
• La question de savoir où les données sont physiquement stockées devient un véritable enjeu, et non plus une simple formalité informatique. En France, la certification HDS constitue le cadre de référence pour l'hébergement des données de santé personnelles, et il est tout à fait raisonnable d'exiger d'un prestataire QHSE qu'il s'y conforme, même lorsque cette obligation est sujette à débat.

Ajoutez un modèle linguistique à ce tableau et vous obtenez un nouveau processeur, un nouveau transfert et une nouvelle copie des données les plus sensibles que vous détenez. Ce qui nous amène à la seule question qui compte vraiment.

La question à poser à chaque fournisseur : où va la ligne de commande ?

Lorsque votre outil QHSE vous propose de synthétiser un rapport d'accident, certaines données quittent votre système. Le texte de ce rapport, y compris le nom de la personne concernée et la nature de la blessure, est transmis là où le modèle est exécuté. Posez-vous trois questions : quel prestataire, dans quel pays et selon quelles conditions contractuelles en matière de conservation des données et de formation ?

En réalité, il n'existe que trois architectures sur le marché, et ce n'est pas la performance qui les distingue les unes des autres, mais leur visibilité.

La raison pour laquelle la géographie n’est pas synonyme de paranoïa réside dans le CLOUD Act américain, qui autorise les autorités américaines, muni d’un mandat ou d’une assignation à comparaître, à contraindre un fournisseur relevant de la juridiction américaine à produire les données en sa possession, sous sa garde ou sous son contrôle, y compris celles stockées sur des serveurs situés en dehors des États-Unis. Il convient de noter que le critère déterminant est la juridiction américaine et non la présence d’un siège social aux États-Unis, ce qui élargit le champ d’application de cette loi bien au-delà de ce que la plupart des gens imaginent, et que cela s’étend aux données détenues par des filiales. La loi prévoit certes la possibilité pour un fournisseur de demander l’annulation de la divulgation si celle-ci entre en conflit avec le droit étranger, mais il s’agit d’une procédure sur laquelle vous n’avez aucun contrôle. Il s’agit là d’un risque lié à la juridiction plutôt que d’une faille de sécurité, et le chiffrement au repos géré par le fournisseur n’y remédie pas, car c’est ce dernier qui détient les clés.

Une dernière chose à demander, que presque personne ne propose et que les auditeurs apprécient de plus en plus : un journal de tous les appels effectués par l'IA. Quel document, quel modèle, quel utilisateur, à quel moment. Cela permet de transformer l'affirmation « nous utilisons l'IA de manière responsable » en quelque chose que l'on peut réellement démontrer.

La loi sur l'IA, dans sa version d'octobre 2026

Le cadre réglementaire a évolué cet été, et bon nombre des recommandations publiées sont désormais obsolètes. Voici la situation actuelle, expliquée en termes simples.

La loi européenne sur l’IA classe certains systèmes utilisés dans le cadre de l’emploi et de la gestion du personnel comme présentant un risque élevé, conformément au point 4 de l’annexe III, notamment les systèmes servant à surveiller et à évaluer les performances et le comportement des travailleurs. Le paquet législatif «Digital Omnibus» sur l’IA, adopté par le Parlement le 16 juin 2026 et par le Conseil le 29 juin 2026, et en vigueur depuis juillet, a reporté au 2 décembre 2027 les obligations applicables aux systèmes autonomes à haut risque visés à l’annexe III. Pour l’IA intégrée dans des produits déjà couverts par la législation européenne en matière de sécurité, la date d’application est reportée à août 2028. Les obligations de transparence prévues à l’article 50, notamment celle d’informer les personnes qu’elles interagissent avec un système d’IA, s’appliquent à compter du 2 août 2026, avec un délai de grâce jusqu’au 2 décembre 2026 pour le marquage lisible par machine du contenu généré sur les systèmes déjà commercialisés. Les pratiques interdites sont en vigueur depuis février 2025. Il convient de noter ce que le règlement « Omnibus » n’a pas fait : il n’a pas restreint la catégorie d’emploi ni modifié les critères de classification. Seules les dates ont été reportées.

Il y a deux interprétations possibles, et c'est la deuxième qui est utile.

Premièrement : la plupart des utilisations de l’IA dans le domaine QHSE ne présentent pas de risque élevé. Résumer un rapport d’audit, extraire une date d’un certificat, classer un événement signalé par catégorie de risque : aucune de ces tâches n’implique d’évaluer un salarié. Vous ne créez pas un système à haut risque en ajoutant la reconnaissance optique de caractères (OCR) à votre base de documents.

Deuxièmement : dès lors que votre système évalue les opérateurs sur leur comportement en matière de sécurité, classe les équipes en fonction de leur taux d’incidents pour tout ce qui touche à leur carrière, ou signale des individus comme présentant des profils à risque, vous vous retrouvez très probablement dans le champ d’application de l’annexe III. L’article 6, paragraphe 3, prévoit une exception pour les systèmes qui n’effectuent qu’une tâche procédurale restreinte ou n’influencent pas de manière significative l’issue d’une décision ; toutefois, pour pouvoir s’y prévaloir, une évaluation documentée et un enregistrement sont requis. Il s’agit donc d’une conclusion à laquelle on parvient sur le papier, et non d’une hypothèse que l’on peut simplement supposer. Le report à décembre 2027 est l’occasion de mettre cela en place correctement, et non une autorisation de l’ignorer. Les organisations qui conservent une fiche de modèle, une étape d’approbation humaine et un journal des décisions pour chaque fonctionnalité d’IA considéreront l’échéance de 2027 comme une simple formalité. Celles qui ne le font pas passeront un trimestre à reconstituer ce que leur fournisseur a fait.

Sept questions à poser à votre fournisseur

Imprimez ceci et emportez-le à votre prochaine démonstration. Les réponses permettent de distinguer très rapidement une plateforme sérieuse d'une simple présentation sur l'IA.

1. Quel modèle traite mes requêtes, et où est-il hébergé ?

   Vous voulez le nom d'un fournisseur et un pays, pas « un LLM de premier plan » ou « le cloud ».

2. Mon contenu est-il utilisé pour entraîner le modèle de quelqu'un ?

   Demandez-le dans le contrat, pas dans la FAQ. Les conditions générales figurant dans la documentation du produit sont susceptibles d'être modifiées sans préavis.

3. Puis-je choisir un mode différent selon le cas d'utilisation ?

   La traduction d'une procédure et la synthèse d'un rapport d'accident ne devraient pas nécessairement reposer sur la même architecture.

4. Existe-t-il un journal répertoriant tous les appels vers l'IA ?

   Document, modèle, utilisateur, horodatage. Ce sont vos éléments de preuve pour le prochain audit.

5. Où se situe l'étape de validation humaine ?

   Si un modèle est capable de clôturer une action ou de lever une constatation sans aide, il s'agit d'un problème de conception, et non d'une fonctionnalité.

6. Existe-t-il une fonctionnalité permettant d'évaluer chaque salarié individuellement ?

   Si oui, demandez directement au fournisseur comment il se prépare à respecter les obligations de l'annexe III qui s'appliqueront à partir de décembre 2027.

7. Qui est soumis au CLOUD Act dans cette chaîne ?

   Y compris les sous-traitants. La réponse diffère souvent de celle concernant la plateforme principale.

L'approche de TimeTonic

TimeTonic propose les trois architectures ci-dessus et vous permet de choisir en fonction de chaque cas d'utilisation : une IA en cloud public pour les contenus courants, une IA souveraine privée hébergée en France, et un serveur IA dédié lorsque votre secteur d'activité ou vos clients l'exigent. Vos données n’alimentent jamais les modèles de tiers, l’hébergement est certifié HDS et chaque appel IA est consigné. Les autorisations s’appliquent par rôle, site et service, ce qui est essentiel pour la gestion des incidents bien avant qu’un modèle ne soit impliqué. Vous trouverez une analyse approfondie de ces trois modes dans notre guide complet de l’offre IA de TimeTonic.

Foire aux questions