Rafiq IA Lab

IA-09 — Vérifier, corriger et fiabiliser une réponse IA

---

1. Titre du module

IA-09 — Vérifier, corriger et fiabiliser une réponse IA

Partie 2 — Utiliser efficacement les assistants IA (module de clôture)

---

2. Objectif pédagogique

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

expliquer pourquoi une IA peut se tromper et la différence entre plausible et vrai ;
reconnaître les types d'erreurs : hallucinations, erreurs techniques, fausses commandes, fausses références, fausses bonnes pratiques ;
appliquer une méthode de vérification en 5 étapes ;
vérifier concrètement une commande Linux, un script PowerShell, une configuration réseau, une information juridique/réglementaire, une information de cybersécurité ;
demander des sources fiables, comparer plusieurs réponses, tester en lab, lire les logs ;
demander à l'IA d'indiquer ses incertitudes ;
savoir quand ne pas utiliser l'IA.

Prérequis : avoir suivi IA-04 (hallucinations, « probabilité ≠ vérité ») et IA-06 à IA-08 (usage et prompts).

---

3. Niveau

Intermédiaire.

C'est le module qui verrouille toute la Partie 2 : sans vérification, tout le reste est dangereux. Il sert de référence pour tous les modules pratiques suivants (Parties 3 à 5).

---

4. Durée estimée

Activité	Durée indicative
Lecture du cours	45 à 55 minutes
Exemples + cas pratique guidé	30 minutes
Exercice à faire seul	20 minutes
Quiz + flashcards de révision	20 minutes
Mini-projet de fin de module	30 minutes
Total réaliste	environ 2h30

---

5. Résumé clair et simple

Depuis le début du parcours, une idée revient : une réponse d'IA peut être fausse, même quand elle paraît parfaite. Un LLM vise le texte le plus probable, pas le plus vrai (IA-04). Il peut donc inventer une commande, une option, une référence ou une « bonne pratique » — avec un ton parfaitement assuré. C'est ce qu'on appelle une hallucination.

Ce module transforme ce constat en méthode. L'idée n'est pas de se méfier de tout au point de ne plus rien utiliser, mais d'avoir un réflexe systématique proportionné au risque : plus une action a de conséquences (production, sécurité, conformité), plus la vérification doit être rigoureuse.

La méthode tient en 5 étapes : Repérer ce qui est factuel et risqué → Recouper avec une source fiable → Comprendre avant d'appliquer → Tester en environnement isolé → Valider (décision humaine et journalisation). On l'applique ensuite à des cas concrets : commande Linux, script PowerShell, config réseau, info juridique, info de cybersécurité.

Deux outils complètent la méthode : demander des sources quand c'est nécessaire (en gardant à l'esprit qu'une IA peut aussi inventer des sources), et comparer plusieurs réponses ou plusieurs assistants. Enfin, savoir quand ne pas utiliser l'IA est une compétence à part entière : pour certaines décisions critiques, sensibles ou réglementées, l'IA n'est pas l'outil adapté.

---

6. Compétences visées

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

expliquer les causes et les types d'erreurs d'une IA ;
distinguer une réponse plausible d'une réponse vérifiée ;
appliquer une méthode de vérification en 5 étapes, proportionnée au risque ;
vérifier des éléments techniques (commande, script, config) et non techniques (juridique, sécurité) ;
demander et évaluer des sources, comparer des réponses, tester en lab, lire les logs ;
demander une déclaration d'incertitudes utile ;
décider quand l'IA n'est pas l'outil adapté.

---

7. Notions clés à comprendre

Plausible vs vrai : une réponse peut être crédible et fausse en même temps.
Hallucination : réponse inventée présentée comme un fait (IA-04).
Erreur technique : commande, option, chemin, paramètre incorrects.
Fausse référence : citation, lien, nom de fichier ou documentation inventés.
Fausse bonne pratique : conseil présenté comme une norme alors qu'il est faux, obsolète ou inadapté.
Recoupement : confirmer une information à une source fiable (doc officielle, aide intégrée, autorité compétente).
Test en lab : essayer dans un environnement isolé, sans risque pour la production.
Dry-run : exécution « à blanc » qui montre ce qui serait fait sans rien modifier.
Validation humaine : décision finale prise par une personne compétente.
Proportionnalité : intensité de vérification adaptée au niveau de risque.

---

8. Cours complet structuré

8.1 — Pourquoi une IA peut se tromper

Rappel des modules précédents :

un LLM prédit le plausible, pas le vrai (IA-04) ;
il n'a pas, par défaut, accès à la vérité ni aux faits récents ;
il ne sait pas qu'il se trompe : pas de mécanisme de doute fiable ;
il dépend du contexte fourni : un contexte pauvre produit des suppositions ;
il peut refléter des biais ou des informations périmées de ses données (IA-02, IA-05).

Conséquence : l'erreur n'est pas un accident rare, c'est une possibilité permanente à intégrer dans sa méthode.

8.2 — Plausible n'est pas vrai

C'est la distinction centrale. Une réponse peut être :

bien écrite, structurée, assurée → cela ne dit rien de son exactitude ;
fausse sur un détail décisif (une option de commande qui n'existe pas) tout en étant juste à 95 % ;
globalement correcte mais inadaptée à votre contexte (bonne pour Ubuntu, fausse pour CentOS).

Réflexe : dissocier la forme (claire) du fond (à prouver). La confiance se mérite par la vérification, pas par le style.

8.3 — Les types d'erreurs à connaître

Hallucination : l'IA invente (une commande, une fonction, un chiffre, un événement).
Erreur technique : syntaxe, option, chemin, version incorrects.
Fausse commande : commande qui n'existe pas, ou qui fait autre chose que ce qui est annoncé (parfois destructive).
Fausse référence : documentation, lien, CVE, norme ou citation inventés ou mal attribués.
Fausse bonne pratique : recommandation présentée comme standard alors qu'elle est obsolète, dangereuse ou hors contexte (ex. désactiver une sécurité « pour que ça marche »).

Les plus dangereuses ne sont pas les erreurs grossières (faciles à voir), mais les erreurs subtiles et crédibles glissées dans une réponse par ailleurs correcte.

8.4 — La méthode de vérification en 5 étapes

Une méthode simple, à adapter selon le risque.

1. Repérer. Surlignez tout ce qui est factuel et vérifiable : commandes, options, chemins, valeurs, références, affirmations « c'est la bonne pratique ». Ce sont les candidats à l'erreur.

2. Recouper. Confirmez à une source fiable : documentation officielle, aide intégrée (man, --help, Get-Help), site de l'éditeur, autorité compétente. Une IA peut servir à comprendre, pas à prouver.

3. Comprendre. N'appliquez rien que vous ne comprenez pas. Si une commande ou une ligne reste obscure, demandez une explication… puis vérifiez-la aussi.

4. Tester. Essayez en environnement isolé (lab/préprod). Utilisez un dry-run quand c'est possible. Observez le comportement réel.

5. Valider. Décision finale humaine, surtout si l'action est sensible. Journalisez ce qui a été fait. En cas de doute persistant : ne pas appliquer.

Proportionnalité : pour une explication de cours, l'étape 2 peut suffire ; pour une commande en production, les 5 étapes sont obligatoires.

8.5 — Vérifier une commande Linux

Lire l'aide : man <commande> ou <commande> --help.
Identifier les options destructives (suppression, écrasement, forçage) et les droits requis (root).
Tester sur un fichier ou une machine de test, jamais directement en production.
Pour les commandes qui modifient : chercher une option de simulation quand elle existe.
Recouper avec la documentation de la distribution (les options varient selon les versions).

Exemple de vigilance : une commande de suppression « pour nettoyer » peut viser un mauvais chemin. On vérifie le chemin exact et on teste sur une copie d'abord.

8.6 — Vérifier un script PowerShell (lien avec IA-11)

Lire le script en entier : que fait-il, sur quoi, avec quels droits ?
Repérer les actions destructives (Remove-, Format-, écrasements) et les chemins ciblés.
Vérifier les cmdlets et leurs paramètres via Get-Help <cmdlet> -Full.
Exécuter d'abord avec -WhatIf (équivalent dry-run) quand la cmdlet le supporte.
Tester en lab, sur des données factices, avant tout usage réel.
Ajouter des confirmations et des logs si nécessaire.

8.7 — Vérifier une configuration réseau

Comprendre chaque ligne de configuration proposée (adresses, masques, routes, règles).
Vérifier la cohérence avec votre plan d'adressage réel.
Tester sur un équipement de lab ou en fenêtre de maintenance, avec un moyen de retour arrière (sauvegarde de la config, accès console).
Attention aux changements qui peuvent vous couper l'accès (règles firewall, route par défaut) : prévoyez toujours un filet de sécurité.
Recouper avec la documentation du constructeur (la syntaxe diffère selon les équipements).

8.8 — Vérifier une information juridique ou réglementaire

Une IA n'est pas juriste et peut se tromper, citer des textes périmés ou inexistants.
Pour le RGPD, le droit du travail, les obligations légales : confirmer auprès de sources officielles (textes de loi, autorités compétentes comme la CNIL en France) ou d'un professionnel qualifié.
Ne jamais fonder une décision réglementaire uniquement sur une réponse d'IA.
Utiliser l'IA pour comprendre et dégrossir, pas pour trancher. (Confidentialité/RGPD approfondis en IA-17.)

8.9 — Vérifier une information de cybersécurité

Rester dans un cadre défensif et légal (IA-16).
Recouper toute affirmation de sécurité (CVE, correctif, règle, durcissement) avec des sources fiables : éditeur, bases officielles de vulnérabilités, CERT/autorités.
Méfiance sur les « solutions » qui affaiblissent la sécurité (désactiver un pare-feu, ouvrir des accès) : une vraie bonne pratique ne réduit pas la protection pour « faire marcher ».
Tester les mesures en lab avant déploiement, et garder une validation humaine.

8.10 — Demander des sources, comparer, tester, lire les logs

Demander des sources : utile, mais une IA peut inventer une source. Vérifiez que la source existe vraiment et dit bien ce qui est annoncé. Préférez un assistant avec navigation web qui cite des liens vérifiables (IA-06).
Comparer plusieurs réponses : reformuler, ou interroger un autre assistant. Des réponses divergentes signalent une zone à creuser.
Tester en lab : l'épreuve de vérité reste l'essai réel en environnement isolé.
Lire les logs : après une action, les journaux disent ce qui s'est réellement passé — souvent plus fiables que l'explication de l'IA.

8.11 — Demander à l'IA d'indiquer ses incertitudes

Ajoutez systématiquement : « Indique ce dont tu n'es pas sûr, tes hypothèses, et ce que je dois vérifier. » Cela n'élimine pas les erreurs (l'IA peut être sûre à tort), mais cela fait remonter des zones de doute exploitables. À combiner avec les 5 étapes.

8.12 — Savoir quand NE PAS utiliser l'IA

L'IA n'est pas l'outil adapté quand :

la décision est critique et irréversible sans possibilité de test ;
le sujet est strictement réglementé et exige une responsabilité humaine/professionnelle (juridique, médical, financier) ;
les données sont sensibles et ne peuvent pas être anonymisées pour un service cloud (IA-17) ;
la fraîcheur de l'information est vitale et vous n'avez pas d'outil connecté fiable ;
vous ne pourrez pas vérifier la réponse et le risque est élevé.

Reconnaître ces cas, c'est de la maturité professionnelle, pas un échec. Parfois, la bonne réponse est : doc officielle, collègue expert, ou procédure éprouvée.

---

9. Exemples concrets liés au monde IT

Commande Linux douteuse. L'IA propose une option qui n'existe pas dans votre version. man le révèle (étape 2) → vous corrigez avant tout test.
Script PowerShell avec Remove-Item. La lecture (étape 1) repère une suppression sur un chemin trop large. Un -WhatIf (étape 4) confirme le danger → vous restreignez le périmètre.
Config réseau qui coupe l'accès. Avant d'appliquer une règle firewall, vous prévoyez un accès console et une sauvegarde (étape 4/5) → l'accès est rétabli en cas d'erreur.
Fausse référence. L'IA cite une « documentation officielle » avec un lien qui n'existe pas. Vous vérifiez : la source est inventée → vous ne vous y fiez pas.
Info RGPD. L'IA affirme une obligation légale précise. Vous recoupez avec la CNIL/textes officiels avant toute décision (étape 2, section 8.8).
Alerte de sécurité. L'IA explique une alerte EDR et propose de « désactiver une protection » : signal d'alarme. Vous restez défensif et recoupez avec l'éditeur (8.9, IA-16).
Deux assistants, deux réponses. Sur un point de config, deux assistants divergent. Vous testez en lab et lisez les logs pour trancher (8.10).

Constante : la vérification transforme un brouillon plausible en action fiable.

---

10. Cas pratique guidé

Objectif : appliquer les 5 étapes sur une réponse d'IA contenant une erreur cachée.

Contexte. Vous demandez à un assistant un script Bash pour « libérer de l'espace en supprimant les vieux logs ». Il vous renvoie un script avec une commande de suppression récursive sur un chemin paramétrable.

Étape 1 — Repérer. Surlignez les éléments risqués : la commande de suppression, le chemin ciblé, l'option récursive/forçage, les droits requis.

Étape 2 — Recouper. Vérifiez la commande et ses options dans man/--help. Confirmez ce que fait réellement chaque option (notamment celles qui forcent ou rendent l'action irréversible).

Étape 3 — Comprendre. Relisez : que se passe-t-il si le chemin est vide ou mal renseigné ? La suppression pourrait viser bien plus que les logs. Demandez à l'IA d'expliquer ce cas… puis vérifiez l'explication.

Étape 4 — Tester. Créez un dossier de test avec des fichiers factices. Exécutez le script dessus (ou un équivalent dry-run : lister ce qui serait supprimé avant de supprimer). Observez le résultat réel.

Étape 5 — Valider. Ajoutez des garde-fous : vérification que le chemin existe et n'est pas vide, confirmation avant suppression, journalisation, et une sauvegarde préalable. Décision finale humaine. Si un doute subsiste : ne pas déployer.

Résultat du cas pratique : vous avez transformé un script potentiellement destructeur en procédure fiable, sans jamais faire confiance « sur parole ».

---

11. Exercice pratique à faire seul

Consigne. Prenez une réponse d'IA (réelle ou que vous générez) sur une tâche IT comportant des éléments factuels (commande, configuration, ou affirmation « bonne pratique »). Appliquez les 5 étapes par écrit :

Repérer : listez 3 à 5 éléments factuels à vérifier.
Recouper : indiquez pour chacun la source fiable que vous consulteriez.
Comprendre : notez un élément que vous ne comprenez pas encore et la question à poser.
Tester : décrivez comment vous le testeriez sans risque (lab, dry-run, données factices).
Valider : indiquez le garde-fou final et qui décide.

Contexte. Vous ancrez le réflexe de vérification proportionnée, valable pour tout le reste du parcours.

Résultat attendu. Une fiche d'application des 5 étapes sur un cas réel.

Critères de réussite :

3 à 5 éléments factuels correctement repérés ;
des sources fiables réalistes (doc officielle, aide intégrée, autorité) ;
une stratégie de test sans risque ;
un garde-fou de validation explicite ;
une mention « quand je ne l'utiliserais pas » si le risque est trop élevé.

---

12. Quiz de 10 questions QCM

Une seule bonne réponse par question.

Q1. Une réponse d'IA bien écrite et assurée est :

A. Forcément vraie
B. Potentiellement fausse : la forme ne prouve pas le fond
C. Toujours fausse
D. Vraie si elle est longue

Q2. Qu'est-ce qu'une hallucination ?

A. Une panne réseau
B. Une information inventée présentée comme un fait
C. Une image générée
D. Un type de log

Q3. Quelles sont les 5 étapes de la méthode de vérification ?

A. Repérer, Recouper, Comprendre, Tester, Valider
B. Lire, Copier, Coller, Exécuter, Oublier
C. Chercher, Cliquer, Partager, Aimer, Suivre
D. Entrée, Traitement, Sortie, Boucle, Fin

Q4. Pour vérifier une commande Linux, on consulte d'abord :

A. Un forum au hasard
B. L'aide officielle (man / --help) et la doc de la distribution
C. Rien, on l'exécute
D. Un autre utilisateur sur les réseaux sociaux

Q5. Avant d'exécuter un script PowerShell qui supprime des fichiers, on peut utiliser :

A. Rien de particulier
B. -WhatIf pour simuler, après avoir lu le script et testé en lab
C. Les droits root
D. Un mot de passe administrateur dans le prompt

Q6. Pour une information juridique (ex. RGPD), il faut :

A. Se fier uniquement à l'IA
B. Recouper avec des sources officielles ou un professionnel qualifié
C. Deviner
D. Ignorer la question

Q7. Une IA qui propose de « désactiver le pare-feu pour que ça marche » :

A. Donne une bonne pratique de sécurité
B. Propose une fausse bonne pratique à ne pas suivre sans recoupement
C. A forcément raison
D. Doit être appliquée immédiatement

Q8. Quand on demande des sources à une IA, il faut :

A. Les croire sans vérifier
B. Vérifier qu'elles existent vraiment et disent bien ce qui est annoncé
C. Ne jamais demander de sources
D. Copier les liens sans les ouvrir

Q9. Après une action sur un système, quelle source est souvent la plus fiable sur ce qui s'est réellement passé ?

A. L'explication de l'IA
B. Les logs du système
C. Un souvenir
D. Une capture d'écran d'un forum

Q10. Quand vaut-il mieux NE PAS utiliser l'IA ?

A. Jamais, l'IA convient à tout
B. Pour une décision critique, réglementée ou avec données sensibles non anonymisables et risque élevé
C. Uniquement le week-end
D. Quand la réponse est trop longue

---

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

Q1 → B. La forme (claire, assurée) ne prouve pas le fond. A et D sont faux, C est excessif.

Q2 → B. Une hallucination est une information inventée présentée comme un fait. A, C et D sont hors sujet.

Q3 → A. Repérer, Recouper, Comprendre, Tester, Valider. Les autres listes sont fantaisistes ou hors sujet.

Q4 → B. On consulte l'aide officielle et la doc de la distribution. A et D ne sont pas fiables, C est dangereux.

Q5 → B. -WhatIf simule l'action, après lecture du script et test en lab. A est risqué, C et D sont hors sujet ou dangereux.

Q6 → B. On recoupe avec des sources officielles ou un professionnel : l'IA n'est pas juriste. A, C et D sont irresponsables.

Q7 → B. Affaiblir la sécurité « pour que ça marche » est une fausse bonne pratique. A, C et D sont faux.

Q8 → B. On vérifie que les sources existent et disent bien ce qui est annoncé (l'IA peut en inventer). A, C et D sont incorrects.

Q9 → B. Les logs disent ce qui s'est réellement passé. L'explication de l'IA (A) reste une hypothèse.

Q10 → B. Décisions critiques/réglementées/données sensibles non anonymisables + risque élevé : l'IA n'est pas l'outil adapté. A est faux, C et D sont absurdes.

Barème indicatif : 8/10 ou plus = notions acquises. 5 à 7 = relisez les sections 8.4 et 8.12. Moins de 5 = reprenez le cours et appliquez les 5 étapes sur un cas réel.

---

14. Flashcards de révision

Carte 1 Q : Une réponse d'IA assurée est-elle forcément vraie ? R : Non : la forme ne prouve pas le fond ; plausible ≠ vrai.

Carte 2 Q : Qu'est-ce qu'une hallucination ? R : Une information inventée présentée comme un fait.

Carte 3 Q : Les 5 étapes de vérification ? R : Repérer, Recouper, Comprendre, Tester, Valider.

Carte 4 Q : Que veut dire « proportionnalité » de la vérification ? R : Plus l'action est risquée, plus la vérification doit être rigoureuse.

Carte 5 Q : Comment vérifier une commande Linux ? R : man / --help, doc de la distribution, test sur fichier/machine de test.

Carte 6 Q : Outil pour simuler un script PowerShell destructeur ? R : -WhatIf (après lecture du script et test en lab).

Carte 7 Q : Vérifier une info juridique/RGPD ? R : Recouper avec sources officielles (ex. CNIL) ou un professionnel ; l'IA n'est pas juriste.

Carte 8 Q : Réflexe face à une « solution » qui affaiblit la sécurité ? R : Méfiance : probable fausse bonne pratique ; recouper, rester défensif.

Carte 9 Q : Une IA peut-elle inventer des sources ? R : Oui : vérifier que la source existe et dit bien ce qui est annoncé.

Carte 10 Q : Source la plus fiable sur ce qui s'est réellement passé ? R : Les logs du système.

Carte 11 Q : À quoi sert de demander les incertitudes de l'IA ? R : À faire remonter des zones de doute (sans garantie) pour orienter la vérification.

Carte 12 Q : Quand ne pas utiliser l'IA ? R : Décision critique/réglementée, données sensibles non anonymisables, ou impossibilité de vérifier avec risque élevé.

---

15. Erreurs fréquentes

Confondre forme et fond : croire une réponse parce qu'elle est bien rédigée.
Sauter le recoupement et appliquer directement.
Exécuter sans comprendre une commande ou un script.
Tester en production au lieu d'un environnement isolé.
Faire confiance aux sources citées sans vérifier qu'elles existent.
Suivre une fausse bonne pratique (surtout celles qui réduisent la sécurité).
Fonder une décision juridique sur la seule IA.
Ne pas savoir renoncer : utiliser l'IA là où elle n'est pas adaptée.

---

16. Bonnes pratiques

Appliquer les 5 étapes (Repérer, Recouper, Comprendre, Tester, Valider), proportionnées au risque.
Recouper à des sources fiables (doc officielle, aide intégrée, autorité compétente).
Comprendre avant d'appliquer ; ne rien exécuter d'obscur.
Tester en lab, utiliser dry-run / -WhatIf, prévoir un retour arrière.
Lire les logs après action pour confirmer le résultat réel.
Comparer plusieurs réponses/assistants en cas de doute.
Demander les incertitudes de l'IA.
Savoir renoncer à l'IA quand elle n'est pas adaptée, et anonymiser sinon (IA-17).

---

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

Bloc obligatoire à lire attentivement.

Ce qu'il faut vérifier :

tout élément factuel (commande, option, chemin, valeur, référence, affirmation « bonne pratique ») ;
l'existence réelle des sources citées ;
l'adéquation à votre contexte (version, équipement, environnement) ;
le résultat réel via test et logs.

Ce qu'il ne faut pas faire :

appliquer une réponse en production sans recoupement, compréhension et test ;
suivre une recommandation qui affaiblit la sécurité sans vérification ;
fonder une décision juridique/réglementaire sur la seule IA ;
envoyer des données sensibles à un service cloud pour « faire vérifier » (IA-17).

Risques de mauvaise utilisation :

exécution d'une commande destructive issue d'une hallucination ;
décisions fondées sur des références inventées ;
propagation de fausses bonnes pratiques.

Risques de confidentialité :

la vérification ne doit pas conduire à exposer des secrets ou des données personnelles ;
RGPD, données sensibles et éthique : module IA-17.

Limites de la vérification :

demander des sources ou des incertitudes n'élimine pas les erreurs ;
comparer des réponses peut donner deux réponses fausses : le test réel reste l'arbitre.

Cas où une validation humaine est indispensable :

toute action sur un système réel (surtout en production) ;
toute mesure de sécurité, toute décision réglementaire ;
toute information destinée à un client ou à un document officiel.

Principe à retenir : l'IA propose ; vous vérifiez, testez et décidez. La vérification n'est pas une option : c'est ce qui rend l'usage de l'IA sûr et professionnel.

---

18. Mini-projet de fin de module

Titre : « Ma checklist de fiabilisation IA »

Objectif. Produire une checklist personnelle, réutilisable avant toute application d'une réponse d'IA — outil de référence pour toute la suite du parcours.

Contexte. Vous formalisez votre discipline de vérification, adaptée à votre métier. Aucun code requis.

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

Étapes :

Reformuler les 5 étapes avec vos mots, en une ligne chacune.
Créer une grille de proportionnalité : 3 niveaux de risque (faible / moyen / élevé) et le niveau de vérification associé.
Lister vos sources fiables de référence par domaine (Linux, Windows, réseau, sécurité, juridique).
Définir vos méthodes de test (lab, dry-run, -WhatIf, données factices) et de retour arrière.
Écrire 5 signaux d'alerte qui doivent déclencher une vérification renforcée (ex. action destructive, désactivation d'une sécurité, source douteuse, donnée sensible, décision réglementaire).
Définir vos critères « ne pas utiliser l'IA ».

Résultat attendu. Une checklist d'une page, claire et réutilisable.

Critères de réussite :

les 5 étapes sont reformulées clairement ;
la grille de proportionnalité est exploitable ;
les sources fiables sont réalistes et par domaine ;
les méthodes de test et de rollback sont concrètes ;
les signaux d'alerte et les critères de renoncement sont explicites.

Amélioration possible. Intégrez cette checklist en bas de chaque gabarit de votre bibliothèque (IA-07/IA-08) : « Vérifications obligatoires avant usage réel ».

---

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. »

Pages de manuel et aide intégrée (man, --help, Get-Help) — gratuites, hors ligne, et première source de vérification des commandes. (Gratuit, toujours disponible sur les systèmes concernés.)
Documentation officielle des éditeurs et distributions (Microsoft Learn, documentations Ubuntu/Debian/Red Hat, doc des constructeurs réseau) — sources de référence pour recouper. À vérifier avant publication (liens variables selon versions).
CNIL — cnil.fr — source officielle gratuite et fiable pour les questions RGPD/données personnelles (section 8.8). (Gratuit, source officielle.)
Bases officielles de vulnérabilités / CERT — pour recouper une information de cybersécurité (section 8.9), dans un cadre strictement défensif. À vérifier avant publication (choisir des sources officielles à jour).
« Objectif IA » (OpenClassrooms) et « Elements of AI » (course.elementsofai.com/fr/) — pour réviser les notions de limites et d'erreurs de l'IA. (Gratuits, vérifiés ; compte gratuit possible pour OpenClassrooms.)

Remarque : la meilleure compétence de fiabilisation s'acquiert en pratiquant les 5 étapes sur de vrais cas. Ce module ne promet aucune certification.

---

20. Résumé final du module

Une réponse d'IA peut être plausible mais fausse : la forme ne prouve jamais le fond.
Types d'erreurs : hallucinations, erreurs techniques, fausses commandes, fausses références, fausses bonnes pratiques.
Méthode en 5 étapes : Repérer → Recouper → Comprendre → Tester → Valider, avec une intensité proportionnée au risque.
Cas concrets maîtrisés : commande Linux (man), script PowerShell (-WhatIf), config réseau (retour arrière), info juridique (sources officielles, l'IA n'est pas juriste), info de cybersécurité (cadre défensif, recoupement).
Outils complémentaires : demander des sources (et vérifier qu'elles existent), comparer des réponses, tester en lab, lire les logs, demander les incertitudes.
Compétence clé : savoir quand ne pas utiliser l'IA (décisions critiques, réglementées, données sensibles, impossibilité de vérifier).
Fin de la Partie 2 : la vérification n'est pas une option, c'est ce qui rend l'usage de l'IA sûr et professionnel. Confidentialité/RGPD : IA-17 ; cybersécurité défensive : 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 2. Module suivant prévu : IA-10 — IA pour technicien support, systèmes et réseaux, début de la Partie 3.)