IA dans les workflows et conformité

La conformité comme compétence de conception

Un modèle de langage branché dans un scénario d’automatisation peut classer un courriel entrant, résumer un document ou rédiger une première version de réponse. Cette capacité est réelle, et elle change ce qu’une automatisation peut faire. Elle change aussi ce qu’il faut vérifier avant de la déployer, parce qu’un workflow qui manipule des données personnelles et qui prend, même en partie, des décisions à leur sujet, entre dans le champ du RGPD et, pour certains usages, dans celui du règlement européen sur l’intelligence artificielle. Traiter cette conformité comme une case à cocher à la fin du projet est le meilleur moyen de devoir tout reconstruire. Elle se conçoit en même temps que le workflow, pas après.

Intégrer un modèle de langage avec des garde-fous

Un LLM inséré dans une automatisation n’est pas un maillon comme les autres : il produit un résultat probabiliste, pas déterministe. La même entrée peut produire des sorties légèrement différentes, et une entrée inhabituelle peut produire une sortie franchement fausse, avec la même assurance apparente qu’une sortie correcte. Deux garde-fous limitent ce risque.

La validation humaine : dès qu’une sortie du modèle déclenche une action qui affecte une personne, réponse envoyée, dossier classé, statut modifié, une relecture humaine avant exécution reste la protection la plus simple et la plus efficace. Elle peut être systématique sur les cas sensibles et allégée sur les cas répétitifs à faible enjeu, en cohérence avec la grille de criticité posée au chapitre 1.

Les seuils de confiance : quand la plateforme ou le modèle expose un indicateur de certitude sur sa réponse, fixer un seuil en dessous duquel le workflow bascule automatiquement vers une validation humaine plutôt que d’exécuter l’action évite qu’une réponse hasardeuse produise un effet en production. Un seuil mal calibré, trop bas, laisse passer l’erreur ; trop haut, il annule le gain de temps recherché : c’est un paramètre à ajuster avec des cas réels, pas à deviner.

Où vivent les données

Une automatisation qui appelle un modèle de langage envoie du texte, potentiellement des données personnelles, vers un service tiers. Trois questions se posent systématiquement.

Où résident les serveurs qui traitent la requête : dans l’Union européenne, ou dans un pays tiers dont le niveau de protection juridique est différent. Le fournisseur du modèle sous-traite-t-il lui-même à d’autres prestataires, une chaîne de sous-traitance dont chaque maillon doit être identifié et non simplement supposé. Et un transfert de données hors de l’Union européenne a-t-il lieu, auquel cas il suppose un encadrement juridique spécifique, clauses contractuelles types ou décision d’adéquation, que la CNIL documente précisément. Ces questions ne se répondent pas en lisant une page marketing : elles se vérifient dans la documentation contractuelle et technique du fournisseur choisi.

Qualifier RGPD une chaîne d’automatisation

Une automatisation qui traite des données personnelles engage plusieurs rôles définis par le RGPD, et les confondre est une erreur fréquente.

Le responsable de traitement est l’organisation qui détermine les finalités et les moyens du traitement : c’est en général celle qui décide de mettre en place l’automatisation et pour quel usage. Le sous-traitant, au sens de l’article 28 du RGPD, est le prestataire qui traite ces données pour le compte du responsable de traitement, selon ses instructions, ce que sont typiquement une plateforme d’automatisation et le fournisseur d’un modèle de langage dès lors qu’ils manipulent des données personnelles transmises par l’organisation. Un contrat de sous-traitance, précisant les garanties de sécurité et les conditions de recours à d’éventuels sous-traitants ultérieurs, doit exister avec chacun de ces prestataires.

Le registre des activités de traitement, enfin, doit être mis à jour dès qu’une nouvelle automatisation traite des données personnelles : quelles données, pour quelle finalité, avec quel prestataire, conservées combien de temps. Un registre tenu à jour au fil de l’eau coûte quelques minutes par automatisation ; un registre reconstitué a posteriori, à l’occasion d’un contrôle, coûte nettement plus.

Les obligations de transparence de l’AI Act

Le règlement européen sur l’intelligence artificielle (règlement UE 2024/1689), entré en vigueur le 1er août 2024, prévoit une entrée en application échelonnée de ses obligations. Celles de l’article 50, relatives à la transparence, sont pleinement applicables depuis le 2 août 2026 : elles imposent d’informer une personne qu’elle interagit avec un système d’intelligence artificielle, sauf évidence manifeste du contexte, et de marquer comme tel un contenu généré ou manipulé de façon significative par une IA, notamment les hypertrucages.

Pour une automatisation qui rédige une réponse à un client ou génère un visuel, cela se traduit concrètement : une mention informant que le message a été préparé avec l’assistance d’une IA, quand ce n’est pas déjà évident du contexte, et un marquage du contenu de synthèse quand il est diffusé publiquement. Ce n’est pas une contrainte annexe ajoutée en fin de projet : c’est un paramètre de conception du workflow, au même titre que le déclencheur ou l’action qui l’exécute.

Ce qu’il faut retenir

Une automatisation qui touche à des données personnelles ou intègre un modèle de langage n’est pas seulement un objet technique : c’est un objet juridique, avec des rôles à qualifier, un registre à tenir et des obligations de transparence à respecter dès sa conception. Cette rigueur a un coût, réel et mesurable. C’est justement ce que chiffre le chapitre suivant, qui construit le business case complet d’une automatisation, conformité comprise. Pour aller plus loin sur la pratique concrète des modèles de langage, notre cours L’IA sans filtre approfondit ce que ces outils font réellement, sans angélisme ni méfiance de principe.