IA générative, RGPD et AI Act en 2026 : ce que l'analyste et le manager doivent savoir

Un assistant d'IA sur un projet d'analyse

Un assistant écrit une réponse qui sonne juste, pas une réponse vérifiée ; on le briefe donc avec soin, puis on interroge ce qu'il affirme.

Un assistant d'IA (AI assistant) généraliste repose sur un modèle de langage : il produit le texte qui colle le mieux à la demande et à ce qu'il a appris. C'est donc un bon rédacteur et un bon explicateur, et une source peu fiable dès que la réponse doit être exacte. Le support met les deux côtés en regard.

Une consigne est un brief, écrit comme pour un analyste qui arrive

1. Contexte et dictionnaire de données. Qui vous êtes, quelle décision est en jeu, quelles tables et colonnes existent, ce que représente une ligne.
2. Tâche. Un seul travail par demande ; cinq questions dans une consigne reviennent souvent en cinq réponses minces.
3. Format. Quelque chose de vérifiable : une requête que vous exécuterez vous-même, un tableau, trois phrases.
4. Contraintes. Ce qu'il ne doit ni supposer ni toucher, et pour finir la demande de lister les hypothèses qu'il a faites.

La consigne (prompt) contient la structure de la table et un dictionnaire de données (data dictionary), jamais ses lignes : l'assistant rédige la requête, le groupe l'exécute dans DuckDB sur le vrai fichier. La première réponse se traite comme le travail d'un collègue rapide mais débutant. On lui demande quelles commandes sa requête a écartées et pourquoi, on relance avec une correction et un nombre de lignes vérifiable, et on réclame la meilleure objection à sa propre conclusion, pour l'entendre avant la réunion plutôt que pendant.

L'atelier se déroule au niveau le plus ouvert de l'échelle d'usage de l'IA du cours : l'assistant est attendu, et chaque groupe rapporte une sortie conservée, une sortie rejetée et la vérification qui a fait la différence. N'importe quel assistant convient, versions gratuites comprises. La règle de la séance 1 vaut en entreprise : décrire la structure des données à un outil approuvé, et ne jamais coller de données personnelles ou confidentielles dans un assistant grand public, dont les versions gratuites peuvent conserver les conversations.

Retour au sommaire.

Erreurs vraisemblables et cinq vérifications

Les erreurs dangereuses s'exécutent sans broncher et rendent un chiffre crédible, donc la vérification se règle sur l'enjeu.

Le support classe les erreurs selon la difficulté à les voir. Un nom de colonne inventé échoue bruyamment : la requête s'arrête. Une jointure qui multiplie les lignes s'exécute et rend un total d'apparence normale ; on ne s'en aperçoit qu'en le comparant à un total sûr. Le pire est l'hallucination (hallucination), une affirmation assurée ou la référence à une étude qui n'existe pas, parfois sous le nom d'un vrai auteur : rien dans la réponse ne l'annonce.

Exemple travaillé : une requête qui tourne et qui ment

L'exemple reprend la requête des commandes par État de SQL pour managers, réécrite par un assistant avec une jointure de trop vers la table des articles et un simple COUNT(*). Les États sortent dans un ordre plausible, mais chaque commande est comptée autant de fois qu'elle contient d'articles. Additionner la colonne et confronter cette somme à la taille de la table des commandes révèle le gonflement en quelques secondes ; la correction consiste à compter les identifiants de commande distincts, ou à supprimer une jointure dont la question n'avait pas besoin.

Toutes les sorties ne méritent pas les cinq. Un chiffre destiné à la diapositive de recommandation en demande au moins deux, les premières ; une phrase qui cite une étude exige toujours la troisième. Chaque vérification tient en une ligne (outil, tâche, ce qui a été comparé à quoi), et ces lignes forment l'annexe d'usage de l'IA (AI-use appendix) du rapport final, une demi-page. Dire que l'IA a servi partout n'apprend rien au lecteur ; une déclaration honnête n'est jamais reprochée au groupe.

Retour au sommaire.

Ce que le RGPD demande à un projet d'analyse

Des données sont personnelles dès qu'une personne est identifiable, même indirectement, et le projet doit alors avoir une base légale, une finalité compatible et rien de superflu.

Le règlement général sur la protection des données (RGPD), règlement (UE) 2016/679, protège des personnes, pas des fichiers. Son article 4, paragraphe 1, définit les données à caractère personnel (personal data) comme toute information se rapportant à une personne identifiée ou identifiable. En analyse, le risque est rarement la colonne des noms : il vient de détails ordinaires (une date, un code postal, un montant) qui, réunis, désignent quelqu'un.

Chaque usage repose sur une base légale (lawful basis), fixée avant de commencer et non trouvée après coup. Le consentement n'est pas le réflexe par défaut que beaucoup imaginent ; l'analyse interne s'appuie souvent sur le contrat ou sur l'intérêt légitime, ce dernier après une vraie mise en balance. Deux principes de l'article 5 reviennent tous les jours. La limitation des finalités (purpose limitation) : des données recueillies pour un but ne sont pas réemployées pour un but incompatible, comme des adresses de livraison transformées en profils de quartier. La minimisation des données (data minimisation) : ne prendre que ce dont la question a besoin. Mesurer les retards de livraison ne demande pas le nom des clients, et moins de colonnes, c'est aussi moins d'erreurs.

La pseudonymisation (pseudonymisation) remplace les identifiants directs par des codes, mais celui qui détient la table de correspondance peut revenir en arrière : le RGPD continue donc de s'appliquer. Seules des données que personne ne peut relier à une personne par des moyens raisonnables sont anonymes et sortent du règlement, et la barre est haute : supprimer noms et adresses électroniques suffit rarement tant que restent dates, lieux et montants. Le fichier Olist a été publié comme données ouvertes anonymisées, ce qui permet à la classe de s'en servir librement.

Quatre questions à poser à tout projet, dans cet ordre

1. Données personnelles ? Directement, indirectement ou par recoupement. Sinon, le RGPD s'arrête là.
2. Quelle base légale ? Une par usage, décidée en amont.
3. Même finalité ? Le réemploi est-il compatible avec la raison de la collecte ?
4. Le strict nécessaire ? L'analyse a-t-elle besoin de savoir qui est chaque personne ?

Retour au sommaire.

L'AI Act : quatre niveaux, fournisseurs et déployeurs

L'AI Act encadre ce à quoi sert un système d'IA, avec des règles qui se durcissent à mesure que le risque pour les personnes augmente.

L'AI Act est le règlement (UE) 2024/1689. En tant que règlement, il s'applique directement dans chaque État membre, sans transposition. Entré en vigueur le 1er août 2024, il déploie ses obligations par étapes. Hormis son chapitre sur les modèles d'IA à usage général, il ne réglemente pas une technologie : il réglemente des usages, selon le risque qu'ils font peser sur la santé, la sécurité et les droits fondamentaux. Un même modèle de langage peut donc être à risque minimal quand il rédige des courriels marketing et à haut risque quand il classe des candidats.

Quel que soit le niveau, deux choses demeurent : l'obligation de maîtrise de l'IA (AI literacy) de l'article 4, et le RGPD avec toutes les autres lois. Les obligations se répartissent aussi le long de la chaîne de valeur. Le fournisseur (provider) développe un système et le met sur le marché, par exemple l'éditeur d'un outil de tri de CV. Le déployeur (deployer) utilise un système sous sa propre autorité, par exemple Olist qui trie ses propres candidats avec cet outil. Le manager se trouve le plus souvent côté déployeur ; une entreprise qui construit son propre système, même sur le modèle d'un autre, peut en devenir le fournisseur.

Ce que doit faire le déployeur d'un système à haut risque (high-risk system), en substance

1. Suivre la notice. Utiliser le système comme le fournisseur l'indique.
2. Confier la surveillance. Attribuer le contrôle humain à des personnes compétentes pour l'exercer.
3. Surveiller et conserver. Observer le comportement du système et garder les journaux qui sont sous son contrôle.
4. Informer. Prévenir les salariés et les personnes concernées quand le texte l'exige.

Aucun de ces devoirs ne suppose de comprendre l'intérieur du modèle ; tous supposent que quelqu'un reste aux commandes de son usage.

Retour au sommaire.

La modification de 2026 et les dates qui comptent

Une modification en vigueur depuis juillet 2026 a repoussé les échéances du haut risque, si bien que la date applicable dépend du type d'usage.

Le règlement (UE) 2026/1744, dit Digital Omnibus sur l'IA, a été publié au Journal officiel le 24 juillet 2026 et est entré en vigueur le 27 juillet 2026. Son effet le plus visible porte sur le calendrier des obligations du haut risque. La frise du support, vérifiée en septembre 2026, se lit ainsi.

Décembre 2027, c'est à peu près le moment où les étudiants du cours occuperont leurs premiers postes de management, d'où l'insistance du support. La modification a aussi reformulé l'article 4 : le texte de 2024 demandait aux fournisseurs et déployeurs de garantir un niveau suffisant de maîtrise de l'IA chez leur personnel, le texte modifié leur demande de prendre des mesures pour la soutenir. La formulation est plus légère, la direction la même, et l'obligation couvre toujours tout fournisseur et tout déployeur, quel que soit le niveau. Les deux versions du support sont des paraphrases ; on ne cite l'article 4 que depuis le texte consolidé sur EUR-Lex.

Retour au sommaire.

Classer un usage d'IA en trois questions

Se demander si l'usage est interdit, puis s'il figure sur la liste du haut risque, puis s'il parle aux gens ou génère du contenu.

La méthode, dans cet ordre (le premier oui donne le régime le plus lourd)

1. Est-ce une pratique interdite ? Si oui, on ne la construit ni ne l'utilise.
2. Est-ce sur la liste du haut risque, ou intégré à un produit réglementé ? Si oui, des obligations pèsent sur le fournisseur comme sur le déployeur.
3. Le système parle-t-il aux gens, ou génère-t-il texte, images, son ou vidéo ? Si oui, des obligations de transparence s'appliquent, éventuellement en plus d'un niveau supérieur.

Trois non laissent un usage à risque minimal, qui garde l'obligation de maîtrise de l'IA. Et dans tous les cas, des données personnelles ramènent les quatre questions du RGPD. Le support insiste : c'est une lecture simplifiée, suffisante pour savoir quelles questions poser, pas un avis juridique.

Exemple travaillé : le modèle de retards de livraison

Le support applique la méthode au modèle construit dans l'analytique prédictive pour décideurs, qui signale à l'équipe des opérations les commandes susceptibles d'arriver en retard. Il note des commandes, pas des personnes : ce n'est pas une pratique interdite. La planification des livraisons ne figure pas sur la liste du haut risque et le modèle n'est pas intégré à un produit réglementé. Il ne dialogue pas avec les clients et ne génère pas de contenu ; il signale des commandes au personnel. Résultat : risque minimal, l'article 4 s'appliquant toujours à Olist. Deux réserves complètent la réponse. Les commandes portent un numéro de client, donc le RGPD s'applique. Et si les mêmes scores servaient à répartir le travail entre livreurs ou à évaluer leur performance, l'usage relèverait de l'emploi (annexe III, point 4) et deviendrait à haut risque : même modèle, autre niveau.

Les groupes classent ensuite trois usages envisagés par Olist (un score d'attrition qui alimente des offres marketing, l'outil de tri de CV d'un éditeur, un agent conversationnel de service client) et indiquent pour chacun ce que le niveau exige d'Olist et une question de RGPD qu'il soulève. Le recrutement et la notation de crédit sont les exemples classiques d'usages autorisés mais à haut risque ; la notation sociale, l'exemple classique d'interdiction.

Retour au sommaire.

Responsabilité et souveraineté

La responsabilité d'une décision ne passe jamais à une machine, et choisir un outil d'IA, c'est aussi choisir où vont les données et quel droit s'applique.

La deuxième règle d'IA du cours, l'assumer (Own it), reflète la façon dont la responsabilité fonctionne en entreprise : dire que l'IA a produit un chiffre ne justifie rien. Celui qui signe une recommandation construite avec l'IA répond de la décision et de ses raisons, des données confiées au système, et des vérifications faites ou omises.

• Où les consignes et les fichiers déposés sont-ils traités et stockés ?
• Quel droit régit l'entreprise qui fournit l'outil ?
• Que deviennent vos processus si ses conditions ou ses prix changent l'an prochain ?
• Quelles options européennes ou à poids ouverts existent, et que coûtent-elles en argent, en effort et en compétences ?

Ces questions cadrent une discussion de dix minutes. Des assistants européens existent (le support cite Le Chat de Mistral AI, en précisant que ce n'est pas une recommandation), tout comme des modèles à poids ouverts (open-weight models) qu'une entreprise peut faire tourner sur une infrastructure qu'elle maîtrise. Chaque option répond à certaines questions, aucune à toutes. Le cas final demande ce qu'une entreprise exigerait d'un assistant unique pour tout son personnel, et ce qu'elle accepterait d'abandonner ; une bonne réponse nomme le renoncement et explique pourquoi il est acceptable pour cet usage.

Retour au sommaire.

À retenir

1. Une réponse d'assistant d'IA reste un brouillon tant qu'une vérification que l'on sait nommer ne l'a pas confirmée.
2. On briefe l'assistant avec la structure des données et un dictionnaire de données, jamais avec des lignes personnelles ou confidentielles.
3. Remplacer des noms par des codes ne rend pas les données anonymes ; tant qu'une clé existe, le RGPD s'applique.
4. Tout usage de données personnelles demande une base légale choisie à l'avance, et le consentement n'est que l'une des six.
5. Dans l'AI Act, c'est l'usage d'un système qui fixe son niveau, et les obligations du haut risque pour le recrutement et la notation de crédit s'appliquent à partir du 2 décembre 2027.
6. L'obligation de maîtrise de l'IA de l'article 4 et le RGPD s'appliquent quel que soit le niveau.
7. C'est le signataire de la recommandation, pas l'outil, qui en répond.

Glossaire

dictionnaire de données (data dictionary)

Liste des tables, de leurs colonnes et de ce que représente une ligne, donnée à l'assistant à la place des données.

consigne (prompt)

Texte adressé à l'assistant : contexte, tâche, format attendu et contraintes.

hallucination (hallucination)

Affirmation ou référence fausse produite avec assurance par un modèle de langage.

annexe d'usage de l'IA (AI-use appendix)

Courte annexe du rapport qui liste chaque outil, la tâche confiée et la façon dont la sortie a été vérifiée.

données à caractère personnel (personal data)

Toute information relative à une personne identifiée ou identifiable, directement, indirectement ou par recoupement.

base légale (lawful basis)

L'un des six fondements de l'article 6 du RGPD qui rendent licite un usage de données personnelles.

limitation des finalités (purpose limitation)

Principe du RGPD : des données recueillies pour un but ne sont pas réemployées pour un but incompatible.

minimisation des données (data minimisation)

Principe du RGPD : ne traiter que les données nécessaires à la finalité.

pseudonymisation (pseudonymisation)

Remplacement des identifiants directs par des codes ; les données restent personnelles car les codes peuvent être reliés.

fournisseur (provider)

Dans l'AI Act, celui qui développe un système d'IA et le met sur le marché.

déployeur (deployer)

Dans l'AI Act, celui qui utilise un système d'IA sous sa propre autorité, souvent l'entreprise acheteuse.

système à haut risque (high-risk system)

Usage d'IA listé par le règlement, comme le recrutement ou la notation de crédit, soumis à des obligations strictes.

maîtrise de l'IA (AI literacy)

Obligation de l'article 4, pour tout fournisseur et déployeur, de soutenir la compréhension de l'IA par son personnel.

modèles à poids ouverts (open-weight models)

Modèles dont les paramètres sont publiés, qu'une entreprise peut faire tourner sur une infrastructure qu'elle maîtrise.

Les autres fiches du cours

Un résumé public par deck, dans l'ordre du cours.

Précédent : L'analyse prédictive pour décideursSuivant : Présenter une analyse à des décideurs

1. Séance 1Des données à la décision
2. Séance 2Visualisation de données et récit
3. Séance 3L'essentiel du SQL pour managers
4. Séance 4L'analyse prédictive pour décideurs
5. Séance 5IA générative, RGPD et AI Act
6. Séance 6Présenter une analyse à des décideurs

Toutes les fiches, en liste de lecture

À propos de ces fiches

Écrites par l'enseignant à partir des slides du deck, comme un résumé public : les idées clés, les formules et un exemple calculé. Les exercices, leurs corrigés, les contrôles et la notation restent dans le deck, pour les élèves du cours.

Révision : 16 octobre 2026.