Rafiq IA Lab

IA-05 — Données, entraînement, modèles et évaluation

---

1. Titre du module

IA-05 — Données, entraînement, modèles et évaluation

Partie 1 — Comprendre les bases de l'intelligence artificielle (module de clôture)

---

2. Objectif pédagogique

À la fin de ce module, l'apprenant doit être capable de :

• expliquer le rôle central des données dans toute IA ;
• distinguer les jeux de données d'entraînement, de validation et de test ;
• comprendre ce qu'est un modèle pré-entraîné et le fine-tuning ;
• expliquer simplement le RAG (génération augmentée par récupération) et les embeddings ;
• comprendre ce qu'est un benchmark et savoir le relativiser ;
• lire les indicateurs de base : précision, rappel, faux positif, faux négatif ;
• expliquer pourquoi les scores ne suffisent pas et pourquoi un modèle « performant » peut se tromper ;
• comprendre l'importance de tester un outil IA dans son propre contexte.

Prérequis : avoir suivi IA-01 à IA-04 (IA, ML, DL, IA générative et LLM ; vocabulaire dataset/features/labels/modèle/prédiction).

---

3. Niveau

Débutant (introduit quelques notions intermédiaires).

C'est le module le plus conceptuel de la Partie 1. Il reste accessible, mais introduit des termes (RAG, embeddings, fine-tuning, précision/rappel) que l'on retrouvera en Parties 3 à 5. Aucune compétence en programmation requise.

---

4. Durée estimée

---

5. Résumé clair et simple

Tout, dans l'IA, repose sur les données. Un modèle apprend ce qu'on lui montre : la qualité, la représentativité et l'organisation des données déterminent ses performances réelles (rappel d'IA-02 : « garbage in, garbage out »).

Pour entraîner et évaluer un modèle proprement, on sépare les données en trois paquets : entraînement (pour apprendre), validation (pour régler le modèle), test (pour évaluer honnêtement, sur des données jamais vues). Confondre ces paquets, c'est se mentir sur la vraie performance.

Aujourd'hui, on part rarement de zéro. On utilise des modèles pré-entraînés (déjà entraînés sur d'immenses corpus), qu'on peut éventuellement spécialiser : soit par fine-tuning (ré-entraînement sur des données métier), soit, plus souvent côté IT, par RAG — une méthode où le modèle va d'abord chercher l'information dans vos documents, puis répond en s'appuyant dessus. Le RAG s'appuie sur des embeddings, une façon de transformer du texte en nombres pour comparer le sens.

Enfin, pour savoir si un modèle est bon, on mesure. Mais attention : un bon score sur un benchmark (un test standardisé) ne garantit pas un bon comportement chez vous. Des indicateurs comme la précision et le rappel, et la distinction faux positif / faux négatif, aident à comprendre quel type d'erreurs le modèle commet — ce qui compte souvent plus que le score global.

Conclusion du module et de la Partie 1 : les chiffres ne remplacent pas le test en conditions réelles, ni la vérification humaine.

---

6. Compétences visées

À l'issue de ce module, l'apprenant saura :

• expliquer pourquoi les données sont le facteur déterminant d'une IA ;
• décrire le rôle des jeux d'entraînement, de validation et de test ;
• expliquer ce qu'apporte un modèle pré-entraîné, le fine-tuning et le RAG ;
• définir simplement un embedding et son utilité ;
• relativiser un benchmark et comprendre ses limites ;
• interpréter précision, rappel, faux positif et faux négatif sur un cas concret ;
• choisir le bon compromis d'erreurs selon le contexte (ex. sécurité vs confort) ;
• justifier la nécessité de tester un outil IA dans son propre environnement.

---

7. Notions clés à comprendre

• Données : la matière première de l'IA ; tout modèle apprend à partir d'elles.
• Jeu d'entraînement : données servant à apprendre.
• Jeu de validation : données servant à régler et comparer des versions du modèle.
• Jeu de test : données jamais vues, servant à évaluer honnêtement la performance finale.
• Modèle pré-entraîné : modèle déjà entraîné sur de grands corpus, prêt à être utilisé ou spécialisé.
• Fine-tuning : ré-entraînement ciblé d'un modèle pré-entraîné sur des données spécifiques.
• RAG (Retrieval-Augmented Generation) : méthode où le modèle récupère d'abord des informations dans une base documentaire, puis répond en s'appuyant dessus.
• Embedding : représentation d'un texte (ou d'une image) sous forme de nombres, qui capte le « sens » pour permettre des comparaisons.
• Benchmark : test standardisé pour comparer des modèles.
• Précision : parmi les cas que le modèle a signalés positifs, combien le sont vraiment.
• Rappel : parmi tous les vrais cas positifs, combien le modèle a réussi à détecter.
• Faux positif : une fausse alerte (le modèle dit « oui » à tort).
• Faux négatif : un cas manqué (le modèle dit « non » à tort).

---

8. Cours complet structuré

8.1 — Les données, matière première de l'IA

Tous les modules précédents convergent vers une idée : un modèle ne vaut que ce que valent ses données. Les données déterminent ce que le modèle peut apprendre, et donc ses forces et ses angles morts.

Quatre qualités comptent particulièrement :

• Qualité : données exactes, propres, bien étiquetées.
• Représentativité : reflètent les cas réels que le modèle rencontrera.
• Quantité suffisante : assez d'exemples pour apprendre (surtout en Deep Learning, IA-03).
• Équilibre : pas de classe écrasante qui fausse l'apprentissage (rappel IA-02).

Un défaut sur l'une de ces qualités se paie en erreurs, parfois invisibles tant qu'on n'a pas testé en conditions réelles.

8.2 — Entraînement, validation, test : trois paquets, trois rôles

Pour évaluer honnêtement un modèle, on divise les données :

Pourquoi cette séparation ? Parce qu'un modèle peut apprendre par cœur ses données d'entraînement (le surapprentissage vu en IA-02). Si on l'évalue sur ces mêmes données, on obtient un score flatteur mais trompeur. Seul le jeu de test, jamais vu pendant l'apprentissage, donne une idée honnête de la performance.

Règle d'or : on n'évalue jamais un modèle sur des données qui ont servi à l'entraîner. Sinon, on mesure sa mémoire, pas sa capacité à généraliser.

8.3 — Modèle pré-entraîné et fine-tuning

Modèle pré-entraîné. Entraîner un grand modèle de zéro coûte très cher (données, calcul). On part donc presque toujours d'un modèle pré-entraîné : déjà entraîné sur d'immenses corpus, il « connaît » déjà beaucoup de langage ou d'images. Les LLM (IA-04) en sont l'exemple type.

Fine-tuning (spécialisation). On peut ré-entraîner un modèle pré-entraîné sur des données spécifiques pour l'adapter à un domaine (vocabulaire métier, style, tâche précise). C'est le fine-tuning.

• Avantage : le modèle devient plus pertinent sur votre domaine.
• Coûts/risques : il faut des données de qualité, du temps, des compétences ; un mauvais fine-tuning peut dégrader le modèle ou introduire des biais.

Pour beaucoup de besoins IT, le fine-tuning n'est pas nécessaire : fournir un bon contexte (prompt, IA-07/IA-08) ou utiliser le RAG suffit souvent et coûte bien moins cher.

8.4 — Le RAG, expliqué simplement

RAG signifie Retrieval-Augmented Generation : « génération augmentée par récupération ».

Le problème qu'il résout : un LLM ne connaît pas vos documents internes, et il peut halluciner (IA-04). Le RAG corrige cela en deux temps :

1. Récupérer : face à une question, le système va d'abord chercher les passages pertinents dans votre base documentaire (procédures, tickets, wiki interne).
2. Générer : il transmet ces passages au LLM en même temps que la question, et le modèle répond en s'appuyant dessus.

Analogie. C'est la différence entre répondre de mémoire et répondre livre ouvert. Avec le RAG, le modèle ne récite pas ce qu'il « croit savoir » : il s'appuie sur des documents fournis. Cela réduit les hallucinations et permet de citer la source.

Le RAG est l'une des approches les plus utiles en IT : assistant documentaire, recherche intelligente dans une base de connaissances, chatbot interne. On le retrouvera en IA-19 / IA-20 (outils et API) et dans les mini-projets (IA-22). Attention toutefois : si les documents fournis sont faux ou obsolètes, la réponse le sera aussi (« garbage in, garbage out » à nouveau), et les données récupérées peuvent être sensibles (RGPD, IA-17).

8.5 — Les embeddings, expliqués simplement

Pour « chercher par le sens » (au cœur du RAG), on a besoin de transformer le texte en nombres : ce sont les embeddings.

Un embedding est une représentation d'un texte sous forme d'une liste de nombres, construite de telle sorte que des textes de sens proche aient des nombres proches.

Analogie. Imaginez une grande carte où chaque phrase est un point. Les phrases qui parlent de la même chose se retrouvent proches sur la carte, même si elles n'emploient pas les mêmes mots. « Le serveur ne répond plus » et « la machine est injoignable » seraient voisines.

Grâce aux embeddings, un système peut retrouver les passages pertinents d'une base documentaire même quand la question est formulée différemment des documents. C'est ce qui rend la recherche « intelligente » possible.

8.6 — Les benchmarks : utiles mais à relativiser

Un benchmark est un test standardisé qui permet de comparer des modèles sur des tâches communes (compréhension, raisonnement, code…).

Utilité : donner un repère comparatif, suivre les progrès.

Limites importantes :

• un benchmark mesure une tâche standardisée, pas votre cas d'usage ;
• un modèle peut être optimisé pour « bien figurer » sur des benchmarks connus ;
• un excellent score global peut cacher de mauvaises performances sur votre type de données ou de questions.

Conclusion : un benchmark aide à présélectionner, jamais à décider seul. La vraie évaluation, c'est le test dans votre contexte (8.9).

8.7 — Précision, rappel, faux positif, faux négatif

Pour évaluer un modèle qui dit « oui / non » (par ex. « cette connexion est-elle suspecte ? »), le score global ne suffit pas. On regarde quel type d'erreurs il commet.

Quatre situations possibles :

• Faux positif : le modèle alerte à tort (ex. bloquer un mail légitime).
• Faux négatif : le modèle laisse passer un vrai cas (ex. ne pas détecter une vraie attaque).

Deux indicateurs :

• Précision = parmi les cas signalés « oui », combien le sont vraiment. (« Quand il alerte, a-t-il raison ? »)
• Rappel = parmi tous les vrais « oui », combien ont été détectés. (« Rate-t-il des cas ? »)

Le bon compromis dépend du contexte :

• En cybersécurité défensive, un faux négatif (rater une attaque) est souvent plus grave qu'un faux positif → on privilégie le rappel (sujet approfondi en IA-16).
• Pour un filtre antispam trop agressif, trop de faux positifs (vrais mails bloqués) frustrent les utilisateurs → on surveille la précision.

8.8 — Pourquoi les scores ne suffisent pas

Même avec de bons indicateurs, des pièges subsistent :

• Le piège du déséquilibre. Si 99 % des cas sont « normaux », un modèle qui répond toujours « normal » a 99 % de bonnes réponses… tout en ratant 100 % des cas critiques (rappel IA-02). Le score global est trompeur.
• Le piège du benchmark. Bon « sur le papier » ≠ bon chez vous (8.6).
• Le piège du contexte qui change. Un modèle performant hier peut se dégrader quand les données réelles évoluent (nouvelles attaques, nouveaux usages).
• Le piège de la moyenne. Un bon score moyen peut cacher de très mauvaises performances sur un sous-groupe important.

8.9 — Pourquoi tester dans SON propre contexte

C'est la leçon centrale du module. Un outil IA doit être évalué avec vos données, vos cas, vos contraintes, car :

• vos données diffèrent de celles des benchmarks ;
• votre tolérance aux faux positifs/négatifs vous est propre ;
• les enjeux (sécurité, conformité, satisfaction utilisateur) sont spécifiques.

Méthode simple : constituer un petit jeu de test maison représentatif de vos cas réels, faire tourner l'outil dessus, et mesurer les erreurs qui comptent pour vous. C'est plus parlant que n'importe quel classement public.

8.10 — Pourquoi un modèle performant peut quand même se tromper (synthèse)

• données d'entraînement non représentatives de votre cas ;
• surapprentissage ;
• contexte réel qui évolue ;
• déséquilibre des classes ;
• mauvais compromis précision/rappel pour votre besoin ;
• documents faux ou obsolètes dans un système RAG ;
• hallucinations (pour les LLM, IA-04).

La performance affichée n'est donc jamais une garantie : on teste, on surveille, on garde une validation humaine sur les décisions sensibles.

---

9. Exemples concrets liés au monde IT

1. Assistant documentaire (RAG). Un assistant répond aux questions des techniciens en s'appuyant sur le wiki interne. S'il cite ses sources, on peut vérifier. Si un document est obsolète, la réponse l'est aussi → maintenir la base à jour.
2. Recherche dans une base de connaissances (embeddings). Une recherche « par le sens » retrouve la bonne procédure même si l'utilisateur ne tape pas les mots exacts. À tester sur de vraies requêtes internes.
3. Analyse / classement de tickets (précision vs rappel). Pour un tri par priorité, rater un ticket « Haute » (faux négatif) est plus grave que sur-classer un ticket mineur (faux positif) : on privilégie le rappel sur les cas critiques.
4. Résumé de procédures. Un modèle résume des procédures longues. À relire : un résumé peut omettre une étape de sécurité essentielle.
5. Chatbot interne (RAG + garde-fou humain). Répond aux questions RH/IT courantes à partir de documents officiels ; les cas sensibles sont redirigés vers un humain.
6. Détection d'anomalies (faux positifs/négatifs). En supervision/sécurité, le réglage du compromis détection/fausses alertes est crucial (approfondi en IA-16).

Dans tous ces cas : on mesure les erreurs qui comptent, on teste sur ses propres données, et l'humain valide les décisions sensibles.

---

10. Cas pratique guidé

Objectif : évaluer un outil IA comme un professionnel, sans se laisser éblouir par un « bon score ».

Contexte. On vous propose un outil de classement automatique des tickets support par priorité (Basse / Moyenne / Haute). Le fournisseur annonce « 95 % de bonnes réponses ». Vous allez vérifier ce que vaut vraiment ce chiffre.

Étape 1 — Se méfier du score global. Demandez-vous : les tickets sont-ils équilibrés ? S'il y a 90 % de tickets « Basse », un outil qui classe presque tout « Basse » peut afficher un très bon score… tout en ratant les « Haute » (piège du déséquilibre, 8.8).

Étape 2 — Constituer un petit jeu de test maison. Rassemblez par exemple 100 tickets réels et déjà classés (la « vérité »), représentatifs de vos cas, en veillant à inclure suffisamment de « Haute ».

Étape 3 — Faire tourner l'outil et compter les erreurs par type. Sur les tickets « Haute », mesurez :

• combien l'outil a correctement détectés (rappel) ;
• combien de fausses alertes « Haute » il a produites (précision).

Étape 4 — Choisir le compromis selon vos enjeux. Ici, rater un ticket critique (faux négatif) est plus grave qu'une fausse alerte. Vous privilégiez donc le rappel sur les « Haute », quitte à accepter quelques faux positifs.

Étape 5 — Décider avec un garde-fou. Concluez : l'outil est-il acceptable pour votre contexte ? Prévoyez une validation humaine sur les tickets « Haute » avant toute escalade automatique.

Résultat du cas pratique : vous savez transformer un « 95 % » marketing en une évaluation honnête, fondée sur les erreurs qui comptent pour vous.

---

11. Exercice pratique à faire seul

Consigne. Pour le scénario suivant, répondez à 4 questions.

Scénario : un outil IA filtre les e-mails entrants d'un support et bloque ceux qu'il juge « spam ». Sur 1000 mails, l'outil a bloqué 50 mails ; parmi eux, 10 étaient en réalité des mails légitimes de clients. Par ailleurs, 5 vrais spams sont passés sans être bloqués.

1. Combien y a-t-il de faux positifs ? Que représentent-ils concrètement ?
2. Combien y a-t-il de faux négatifs ? Pourquoi sont-ils gênants ici ?
3. Pour ce cas (mails de clients), faut-il plutôt privilégier la précision ou le rappel ? Justifiez.
4. Proposez un garde-fou pour limiter le risque le plus grave.

Contexte. Vous vous entraînez à raisonner en termes d'erreurs, pas seulement de score global.

Résultat attendu. 4 réponses courtes et justifiées.

Critères de réussite :

• faux positifs = 10 (vrais mails de clients bloqués à tort) ;
• faux négatifs = 5 (vrais spams non bloqués) ;
• choix argumenté (ici, bloquer un mail client est souvent plus coûteux qu'un spam qui passe → on tend à privilégier la précision, pour éviter de bloquer des clients) ;
• garde-fou concret (ex. mettre les mails « suspects » en quarantaine relue par un humain plutôt que les supprimer).

---

12. Quiz de 10 questions QCM

Une seule bonne réponse par question.

Q1. Quel est le facteur le plus déterminant pour la performance réelle d'une IA ?

• A. La couleur de l'interface
• B. La qualité, la représentativité et l'équilibre des données
• C. Le nom du modèle
• D. La vitesse d'Internet

Q2. À quoi sert le jeu de test ?

• A. À entraîner le modèle
• B. À évaluer honnêtement le modèle sur des données jamais vues
• C. À stocker les mots de passe
• D. À accélérer l'entraînement

Q3. Qu'est-ce qu'un modèle pré-entraîné ?

• A. Un modèle déjà entraîné sur de grands corpus, prêt à être utilisé ou spécialisé
• B. Un modèle qui n'a jamais appris
• C. Un modèle uniquement local
• D. Un type de processeur

Q4. Le fine-tuning consiste à :

• A. Supprimer les données
• B. Ré-entraîner un modèle pré-entraîné sur des données spécifiques
• C. Augmenter la fenêtre de contexte
• D. Réduire la taille de l'écran

Q5. En une phrase, le RAG permet à un modèle de :

• A. Répondre uniquement de mémoire
• B. Récupérer d'abord des informations dans une base documentaire, puis répondre en s'appuyant dessus
• C. Fonctionner sans aucune donnée
• D. Remplacer la vérification humaine

Q6. Qu'est-ce qu'un embedding ?

• A. Une représentation d'un texte sous forme de nombres captant le sens, pour comparer
• B. Un mot de passe chiffré
• C. Un type d'écran
• D. Une règle de pare-feu

Q7. Un « faux positif » désigne :

• A. Un cas réellement positif détecté correctement
• B. Une fausse alerte (le modèle dit « oui » à tort)
• C. Un cas manqué
• D. Un benchmark

Q8. En cybersécurité défensive, quel type d'erreur est souvent le plus grave ?

• A. Le faux positif (fausse alerte)
• B. Le faux négatif (vraie attaque non détectée)
• C. Aucun des deux
• D. Le vrai négatif

Q9. Pourquoi un bon score sur un benchmark ne suffit-il pas ?

• A. Parce que les benchmarks sont illégaux
• B. Parce qu'un benchmark mesure une tâche standardisée, pas forcément votre cas d'usage réel
• C. Parce que les scores sont toujours faux
• D. Parce que les benchmarks coûtent cher

Q10. Quelle est la meilleure façon d'évaluer un outil IA avant de l'adopter ?

• A. Se fier uniquement au classement public
• B. Le tester sur un petit jeu représentatif de vos propres cas et mesurer les erreurs qui comptent
• C. Le déployer directement en production
• D. Ne pas l'évaluer du tout

---

13. Réponses corrigées du quiz avec explications

Q1 → B. Les données (qualité, représentativité, équilibre) sont le facteur clé. Les autres options n'influencent pas la performance d'apprentissage.

Q2 → B. Le jeu de test évalue le modèle sur des données jamais vues. A décrit l'entraînement, C et D sont hors sujet.

Q3 → A. Un modèle pré-entraîné a déjà appris sur de grands corpus. B est faux, C et D confondent avec d'autres notions.

Q4 → B. Le fine-tuning ré-entraîne un modèle pré-entraîné sur des données spécifiques. Les autres réponses sont fausses.

Q5 → B. Le RAG récupère des infos dans une base documentaire avant de générer la réponse (réponse « livre ouvert »). A est l'inverse, C et D sont faux.

Q6 → A. Un embedding représente un texte par des nombres captant le sens, pour comparer des contenus. B, C et D sont hors sujet.

Q7 → B. Un faux positif est une fausse alerte. A décrit un vrai positif, C un faux négatif, D est sans rapport.

Q8 → B. En défense, rater une vraie attaque (faux négatif) est souvent le plus grave : on privilégie alors le rappel (voir IA-16).

Q9 → B. Un benchmark mesure une tâche standardisée, pas votre cas réel. Les autres réponses sont fausses.

Q10 → B. On teste sur un petit jeu représentatif de ses propres cas et on mesure les erreurs qui comptent. A est insuffisant, C est dangereux, D est irresponsable.

Barème indicatif : 8/10 ou plus = notions acquises. 5 à 7 = relisez les sections 8.7 et 8.9. Moins de 5 = reprenez le cours, en vous appuyant sur les exemples de tickets et de spam.

---

14. Flashcards de révision

Carte 1 Q : Quel est le facteur déterminant d'une IA ? R : Les données : qualité, représentativité, quantité, équilibre.

Carte 2 Q : Rôle des trois jeux de données ? R : Entraînement (apprendre), validation (régler), test (évaluer honnêtement sur du jamais-vu).

Carte 3 Q : Pourquoi ne pas évaluer un modèle sur ses données d'entraînement ? R : On mesurerait sa mémoire (surapprentissage), pas sa capacité à généraliser.

Carte 4 Q : Qu'est-ce qu'un modèle pré-entraîné ? R : Un modèle déjà entraîné sur de grands corpus, prêt à l'emploi ou à spécialiser.

Carte 5 Q : Qu'est-ce que le fine-tuning ? R : Ré-entraîner un modèle pré-entraîné sur des données spécifiques.

Carte 6 Q : En une phrase, le RAG ? R : Récupérer des infos dans une base documentaire, puis répondre en s'appuyant dessus (réponse « livre ouvert »).

Carte 7 Q : Qu'est-ce qu'un embedding ? R : Une représentation d'un texte en nombres captant le sens, pour comparer des contenus proches.

Carte 8 Q : Faux positif vs faux négatif ? R : Faux positif = fausse alerte ; faux négatif = cas réel manqué.

Carte 9 Q : Précision vs rappel ? R : Précision : quand il alerte, a-t-il raison ? Rappel : rate-t-il des cas réels ?

Carte 10 Q : Pourquoi un bon score de benchmark ne suffit-il pas ? R : Il mesure une tâche standardisée, pas votre cas d'usage réel.

Carte 11 Q : Le piège du déséquilibre ? R : Avec 99 % de cas « normaux », répondre toujours « normal » donne 99 % de bonnes réponses mais rate tous les cas critiques.

Carte 12 Q : Meilleure façon d'évaluer un outil IA ? R : Le tester sur un petit jeu représentatif de ses propres cas et mesurer les erreurs qui comptent.

---

15. Erreurs fréquentes

• Évaluer un modèle sur ses données d'entraînement. Score flatteur et trompeur.
• Se fier au score global sans regarder le type d'erreurs ni l'équilibre des classes.
• Prendre un benchmark pour une garantie de performance dans son propre contexte.
• Croire qu'il faut toujours faire du fine-tuning. Souvent, un bon prompt ou du RAG suffit, pour bien moins cher.
• Oublier que le RAG dépend des documents fournis. Des documents faux/obsolètes donnent des réponses fausses.
• Ignorer le compromis précision/rappel propre à chaque contexte (sécurité vs confort).
• Ne pas tester dans son environnement réel avant d'adopter un outil.

---

16. Bonnes pratiques

• Soigner les données : qualité, représentativité, équilibre, étiquetage fiable.
• Toujours séparer entraînement / validation / test, et évaluer sur du jamais-vu.
• Privilégier les solutions économiques (bon contexte, RAG) avant d'envisager un fine-tuning.
• Maintenir à jour la base documentaire d'un système RAG, et citer les sources quand c'est possible.
• Choisir le compromis précision/rappel selon l'enjeu réel (rater un cas critique vs gêner les utilisateurs).
• Constituer un jeu de test maison représentatif, et mesurer les erreurs qui comptent.
• Surveiller dans le temps : les performances se dégradent quand le contexte change.
• Garder une validation humaine sur les décisions sensibles.

---

17. Point vigilance : limites, risques, sécurité et vérification humaine

Bloc obligatoire à lire attentivement.

Ce qu'il faut vérifier :

• la qualité, la représentativité et l'équilibre des données ;
• que l'évaluation porte bien sur des données jamais vues (jeu de test) ;
• la fraîcheur des documents dans un système RAG ;
• le type d'erreurs (faux positifs / faux négatifs), pas seulement le score global.

Ce qu'il ne faut pas faire :

• adopter un outil sur la seule foi d'un benchmark ou d'un chiffre marketing ;
• déployer en production sans test sur ses propres cas ;
• alimenter un système RAG ou un fine-tuning avec des données sensibles sans précaution ni base légale.

Risques de mauvaise utilisation :

• décisions critiques fondées sur un score trompeur (piège du déséquilibre) ;
• mauvais compromis précision/rappel entraînant des cas critiques manqués ;
• réponses fausses issues de documents obsolètes (RAG).

Risques de confidentialité :

• les données d'entraînement, de fine-tuning ou récupérées par RAG peuvent contenir des informations personnelles ou internes sensibles ;
• l'usage de données personnelles est encadré par le RGPD. Ces aspects (données sensibles, RGPD, éthique, confidentialité) sont approfondis au module IA-17.

Limites de l'évaluation :

• un bon score ne garantit pas un bon comportement chez vous ;
• les performances peuvent se dégrader quand le contexte évolue ;
• les modèles restent peu explicables (« boîte noire », IA-03).

Cas où une validation humaine est indispensable :

• toute décision automatique touchant la sécurité, les personnes, l'argent ou la conformité ;
• tout déploiement d'un outil IA dans un processus réel ;
• toute situation où une erreur aurait des conséquences difficiles à réparer.

Principe à retenir : les chiffres et les benchmarks orientent, mais le test dans son propre contexte et la validation humaine décident.

---

18. Mini-projet de fin de module

Titre : « Grille d'évaluation d'un outil IA pour mon contexte »

Objectif. Construire une grille réutilisable pour évaluer sérieusement n'importe quel outil IA avant de l'adopter — synthèse de toute la Partie 1.

Contexte. Vous préparez un outil d'aide à la décision pour votre équipe : avant d'acheter ou d'adopter une solution IA, on la passe au crible. Aucun code requis.

Prérequis. Avoir lu le cours (section 8) et fait le quiz.

Étapes :

1. Décrire le besoin : quelle tâche, quels cas réels, quels enjeux (sécurité, confort, conformité).
2. Définir un mini jeu de test maison : combien d'exemples, comment les choisir pour qu'ils soient représentatifs et suffisamment équilibrés.
3. Choisir les indicateurs : précision, rappel, et préciser quel type d'erreur (faux positif / faux négatif) est le plus coûteux dans votre cas.
4. Lister les questions à poser au fournisseur : sur quelles données le modèle a-t-il été évalué ? Y a-t-il du RAG ? Les données sont-elles envoyées dans le cloud ?
5. Définir les garde-fous : validation humaine, surveillance dans le temps, points de confidentialité (renvoi IA-17).
6. Rédiger un verdict type : « adopté », « adopté avec garde-fous », ou « à retester », avec les conditions.

Résultat attendu. Une grille d'une page, claire, réutilisable pour tout futur outil IA.

Critères de réussite :

• le besoin et les enjeux sont clairs ;
• le jeu de test maison est pensé (représentativité, équilibre) ;
• le compromis d'erreurs est explicite et justifié ;
• les questions au fournisseur couvrent données, RAG et confidentialité ;
• les garde-fous incluent la validation humaine.

Amélioration possible. Ajoutez une colonne « risque RGPD / données sensibles » à votre grille, en anticipant le module IA-17.

---

19. Ressources gratuites recommandées

Ne recommander que des ressources gratuites ou accessibles gratuitement. Toute ressource dont la gratuité ou la disponibilité n'est pas certaine est signalée par la mention « À vérifier avant publication. »

• « Elements of AI » (version française) — course.elementsofai.com/fr/ — cours gratuit de l'Université d'Helsinki et MinnaLearn/Reaktor ; aborde les types d'apprentissage et l'évaluation des modèles à un niveau accessible. (Gratuit, vérifié.)
• « Objectif IA : initiez-vous à l'intelligence artificielle » (OpenClassrooms) — openclassrooms.com/fr/courses/6417031-objectif-ia-initiez-vous-a-l-intelligence-artificielle — MOOC francophone gratuit, utile pour le fonctionnement d'un projet d'IA et la sensibilisation aux données. (Gratuit, vérifié ; un compte gratuit peut être demandé.)
• « Initiez-vous au Machine Learning » (OpenClassrooms) — cours francophone plus appliqué (préparation des données, jeux d'entraînement/test, premières mesures). À vérifier avant publication (vérifier le lien et l'accès libre au moment de publier).
• Wikipédia (articles « Précision et rappel », « Surapprentissage », « Génération augmentée de récupération ») — bonnes définitions de référence, à recouper. (Gratuit.)
• France Université Numérique (FUN-MOOC) — fun-mooc.fr — MOOC gratuits réguliers sur le machine learning et la data science (incluant l'évaluation des modèles). À vérifier avant publication (sessions ouvertes variables).

Remarque : ce module ne promet aucune certification. Ces ressources sont des compléments d'apprentissage.

---

20. Résumé final du module

• Les données sont le facteur déterminant de toute IA : qualité, représentativité, quantité, équilibre.
• On sépare les données en entraînement / validation / test ; on n'évalue jamais un modèle sur ce qui a servi à l'entraîner.
• On part souvent d'un modèle pré-entraîné, qu'on peut spécialiser par fine-tuning (coûteux) ou, plus souvent en IT, par RAG (réponse « livre ouvert » à partir de vos documents).
• Le RAG s'appuie sur les embeddings, qui transforment le texte en nombres pour comparer le sens.
• Les benchmarks orientent mais ne suffisent pas ; il faut regarder le type d'erreurs via précision, rappel, faux positifs, faux négatifs, et choisir le bon compromis selon l'enjeu.
• Un modèle « performant » peut quand même se tromper (déséquilibre, contexte qui change, documents obsolètes, hallucinations).
• Leçon de clôture de la Partie 1 : on teste dans son propre contexte et on garde la validation humaine. Les risques et la confidentialité sont approfondis en IA-17, l'usage en infrastructure/sécurité en IA-16.

---

21. Validation demandée avant le module suivant

Validation demandée avant le module suivant

Souhaites-tu que je passe au module suivant ou que je corrige/améliore ce module d'abord ?

(Fin de la Partie 1. Module suivant prévu : IA-06 — Bien utiliser ChatGPT, Claude, Gemini et autres assistants IA, début de la Partie 2.)