# 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.*