Applied AI · Intermédiaire 🟡 · Session 10
✏️ Exercices
← Retour au programme 📄 Source .md

Exercices — Session 10 : Gouvernance, éthique & projet final

Programme : Applied AI — Niveau Intermédiaire — Instructeur : Yann Isola Matériel : feuille d’exercices, page web de la session (simulateur de biais, arbre de décision), le canevas du projet final.

Exercice 1 — Audit de biais d’un prompt (en classe, 15 min, binômes)

Contexte

Votre entreprise fictive « Nexa Assurances » utilise le prompt suivant pour présélectionner des candidatures à un poste de conseiller clientèle. Le prompt a été écrit rapidement par un manager pressé.

Le prompt à auditer

Tu es un assistant de recrutement. Analyse le CV ci-dessous et donne un score de 0 à 10.

Nous cherchons un jeune conseiller dynamique, disponible le soir et le week-end,
avec une excellente présentation. Le candidat idéal a fait ses études dans une
grande école, habite près de nos bureaux de Neuilly, et s'exprime dans un
français parfait, sans accent. Privilégier les profils qui s'intégreront
naturellement à notre équipe soudée de jeunes diplômés.

CV : {cv_text}
Réponds uniquement par : score, puis 2 phrases de justification.

Votre mission

  1. Détecter (7 min). Relevez au moins 6 formulations problématiques dans ce prompt. Pour chacune, indiquez :
    • le terme ou critère exact,
    • le type de biais : direct (critère explicitement discriminant) ou indirect/proxy (critère apparemment neutre qui pénalise un groupe),
    • le ou les groupes potentiellement pénalisés.
  2. Corriger (5 min). Réécrivez le prompt en version neutre : critères objectifs et liés au poste, sortie structurée (rappel Session 3) avec justification traçable par critère.
  3. Vérifier (3 min). Collez votre version corrigée dans le simulateur de biais de la page web. Obtenez-vous un signalement résiduel ? Est-il justifié ou est-ce un faux positif du détecteur ? (Rappel : l’outil détecte des motifs, il ne certifie rien.)

Corrigé indicatif (pour le formateur)

Formulation Type Groupe pénalisé
« jeune conseiller », « jeunes diplômés » Direct Candidats seniors (discrimination par l’âge — illégale)
« dynamique » Indirect Stéréotype d’âge/handicap
« disponible le soir et le week-end » Indirect Parents, aidants (impact genré statistique) — acceptable uniquement si c’est une exigence réelle du poste, formulée factuellement
« excellente présentation » Indirect Critère subjectif, porte d’entrée aux biais d’apparence
« grande école » Indirect Discrimination sociale ; le diplôme précis est-il nécessaire au poste ?
« habite près de Neuilly » Indirect Proxy socio-économique (code postal)
« sans accent » Direct Discrimination liée à l’origine — illégale en France
« s’intégreront naturellement à notre équipe » Indirect « Fit culturel » = clonage ; pénalise toute différence

Version corrigée attendue (exemple) : critères = expérience en relation client (années, contexte), maîtrise des outils listés, compétences de communication évaluées sur des éléments factuels du CV ; disponibilité horaire mentionnée comme contrainte factuelle du poste si réelle ; sortie JSON (JavaScript Object Notation, format de données structuré) {score_par_critère, justification_par_critère, éléments_manquants} ; aucune référence à l’âge, l’adresse, l’apparence, l’origine ; mention explicite « ignore le nom, l’âge, l’adresse et la photo ».

Point de débriefing : la moitié des biais du prompt original sont des proxys — c’est la leçon clé. Le biais moderne ne dit pas « pas de femmes » ; il dit « disponible le week-end » et « près de Neuilly ».

Exercice 2 — Analyse d’impact vie privée (en classe, 15 min, binômes)

Contexte

« MediConseil », un cabinet de télémédecine, veut lancer un assistant IA qui résume les échanges patient-médecin pour pré-remplir le dossier médical. L’assistant enverrait la transcription de la consultation à une API de LLM hébergée aux États-Unis.

Votre mission — remplir la mini-AIPD

Une AIPD (Analyse d’Impact relative à la Protection des Données — en anglais DPIA, Data Protection Impact Assessment) complète est un exercice juridique ; vous en faites ici la version ingénieur en 5 questions :

  1. Quelles données partent vers l’API ? Listez tout ce que contient réellement une transcription de consultation (pensez large : identité, santé, mais quoi d’autre ?).
  2. Classez ces données : PII (Personally Identifiable Information, informations personnelles identifiables) directe / PII indirecte (ré-identifiante par combinaison) / donnée sensible au sens du RGPD (Règlement Général sur la Protection des Données) — la santé est une catégorie spéciale, protection renforcée.
  3. Proposez un pipeline d’anonymisation : quelles étapes techniques avant l’appel API ? (détection PII par règles + NER — Named Entity Recognition, reconnaissance d’entités nommées —, pseudonymisation par jetons, ré-association au retour). Que reste-t-il impossible à anonymiser sans détruire l’utilité médicale ?
  4. Résidence & fournisseur : quels problèmes pose l’hébergement États-Unis ⚠ ? Quelles questions poser au fournisseur (traitement en UE disponible ? rétention des prompts ? entraînement sur vos données ? engagements contractuels ?) ?
  5. Verdict : sous quelles conditions ce projet est-il déployable ? Qui doit valider (indice : DPO — Data Protection Officer, délégué à la protection des données — obligatoire ici, et probablement l’avis d’un juriste santé) ?

Corrigé indicatif (pour le formateur)

  1. Données transmises : identité du patient et du médecin, données de santé (symptômes, diagnostics, traitements, antécédents), mais aussi : situation familiale évoquée en consultation, profession, adresse, habitudes de vie (alcool, tabac), parfois des tiers mentionnés (« ma fille a la même chose »).
  2. Classification : nom/date de naissance = PII directe ; profession + ville + pathologie rare = combinaison ré-identifiante ; tout le contenu médical = donnée de catégorie spéciale RGPD (article 9) — traitement en principe interdit sauf exceptions encadrées (soins), exigences maximales.
  3. Pipeline : transcription → détection PII (règles pour formats connus : téléphone, e-mail, numéro de sécurité sociale ; NER pour noms/lieux) → remplacement par jetons stables ([PATIENT], [MEDECIN], [VILLE]) → appel API → ré-association locale des jetons dans le résumé. Limite structurelle : le contenu médical lui-même (symptômes, diagnostic) EST la donnée utile — on ne peut pas l’anonymiser, seulement le pseudonymiser. Le risque résiduel demeure : c’est précisément pour cela que le choix du fournisseur et du lieu de traitement devient critique.
  4. Résidence : transfert hors UE de données de santé = terrain le plus sensible du RGPD ⚠ ; exiger une option de traitement UE ⚠, zéro rétention ou rétention minimale contractualisée, exclusion contractuelle de l’entraînement sur les données, et vérifier les certifications (hébergement de données de santé : en France, certification HDS — Hébergeur de Données de Santé ⚠).
  5. Verdict attendu : déployable uniquement avec : pseudonymisation systématique en amont, fournisseur avec traitement UE + garanties contractuelles (ou modèle auto-hébergé), AIPD formelle validée par le DPO, information des patients, et supervision humaine (le médecin valide chaque résumé — le résumé IA ne devient jamais dossier médical sans relecture).

Point de débriefing : la bonne réponse n’est ni « c’est interdit » ni « on y va » — c’est une liste de conditions. C’est exactement ça, la maturité en gouvernance IA.

Exercice 3 — 🎓 PROJET FINAL : concevoir un produit IA complet

Format : par équipe de 2–3. Idéalement préparé en amont (brief distribué une semaine avant) et présenté en session (pitch 4 min). Variante « atelier express » : 25 min de conception en session sur le canevas, puis galerie d’affichage.

Le brief

Concevez un produit IA complet, de la feuille blanche au plan de déploiement, sur un cas d’usage de votre choix (idéalement tiré de votre contexte professionnel réel). Vous ne codez rien : vous produisez le dossier de conception qu’un ingénieur pourrait exécuter et qu’un comité de revue pourrait approuver.

Le canevas (une page par rubrique maximum — la concision est notée)

  1. Énoncé du problème. Qui a mal où ? Quelle est la situation actuelle (baseline) ? Quel est le critère de succès mesurable ? Pourquoi l’IA (et pas un script, un formulaire, un humain) ?
  2. Architecture. Schéma des composants : sources de données, RAG (Retrieval-Augmented Generation, génération augmentée par récupération) oui/non et pourquoi, outils/tool calling, agent simple ou multi-agents, modèle(s) pressenti(s) avec routage éventuel (économique vs puissant). Justifiez chaque choix par un besoin, pas par la mode.
  3. Stratégie de prompts. Le prompt système principal (rédigé !), la gestion du contexte, les sorties structurées attendues, le versionnage prévu (registre de prompts).
  4. Plan d’évaluation. Votre jeu d’évaluation : combien de cas, d’où viennent-ils, quelles métriques, quel seuil de mise en production, évaluation segmentée par groupe si le cas s’y prête (Session 9 + aujourd’hui). Comment évaluerez-vous en continu après le lancement ?
  5. Plan de déploiement. Patron retenu (serverless/conteneur/dédié — Session 8), budget de latence, estimation de coût mensuel en tokens ⚠ (fourchette + hypothèses), observabilité (quoi journaliser), stratégie de montée en charge progressive (pilote → général).
  6. Analyse de risques. Les 5 risques principaux : technique (hallucination, injection), éthique (biais — sur qui ?), juridique (RGPD, AI Act : classez votre cas dans une catégorie de risque via l’arbre de décision de la page web), opérationnel, réputationnel. Pour chacun : probabilité, impact, mitigation.
  7. Cadre de gouvernance. Qui valide le lancement ? Qui est responsable (accountable) de chaque décision du système ? Où est l’humain dans la boucle ? Quel chemin d’escalade en cas d’incident ? Quels artefacts documentaires (model card, journal de décision, rapport d’incident) ?

Grille d’évaluation du projet final — /100

# Critère Points Ce qui est évalué
1 Problème & valeur /12 Problème réel et précis (4) ; critère de succès mesurable (4) ; justification « pourquoi l’IA » honnête — y compris ce qu’un non-LLM ferait moins bien (4)
2 Architecture /15 Composants adaptés au besoin, sans sur-ingénierie (6) ; choix RAG/outils/agents justifiés (5) ; choix et routage de modèles argumentés (4)
3 Stratégie de prompts /12 Prompt système effectivement rédigé et de qualité pro (6) ; sorties structurées définies (3) ; versionnage/registre prévu (3)
4 Plan d’évaluation /15 Jeu d’éval réaliste et sourcé (5) ; métriques et seuil de mise en prod explicites (5) ; éval continue post-lancement + segmentation si pertinente (5)
5 Plan de déploiement /12 Patron justifié (4) ; budget latence + estimation de coûts avec hypothèses ⚠ (4) ; observabilité et lancement progressif (4)
6 Analyse de risques /15 5 risques couvrant technique/éthique/juridique (6) ; classification AI Act correcte et argumentée ⚠ (4) ; mitigations concrètes et proportionnées (5)
7 Gouvernance /12 Responsabilités nominatives claires (4) ; humain dans la boucle positionné au bon endroit (4) ; escalade + artefacts documentaires (4)
8 Qualité du pitch /7 Tenue du temps (2) ; clarté et structure (3) ; réponses aux questions (2)
TOTAL /100

Barème d’interprétation : ≥ 85 : dossier présentable à un vrai comité de revue. 70–84 : solide, quelques angles morts. 55–69 : la technique tient, la gouvernance ou l’éval est décorative — c’est le défaut n°1 à corriger. < 55 : reprendre le canevas rubrique par rubrique avec le formateur.

Bonus (jusqu’à +5, sans dépasser 100) : cohérence transversale exceptionnelle — chaque risque identifié en rubrique 6 a une trace dans l’éval (4), le déploiement (5) ou la gouvernance (7). C’est LA marque d’un dossier mûr.

Malus type (à annoncer avant) : −3 si l’estimation de coûts n’énonce pas ses hypothèses ; −3 si « biais » est mentionné sans dire qui serait affecté ; −3 si la classification AI Act est absente ou manifestement fausse pour un cas RH/santé/crédit.

Rappel de fin de programme : gardez vos trois exercices. L’audit de biais (Ex. 1), l’AIPD express (Ex. 2) et le canevas (Ex. 3) sont trois gabarits directement réutilisables au travail — c’est votre boîte à outils de gouvernance.