Mode visiteur Parcours public

IA-22

Mini-projets pratiques IA pour l’IT

Créer des outils, agents IA, projets et SaaS · Projet

Disponible

Rafiq IA Lab

IA-22 — Mini-projets pratiques IA pour l'IT

---

1. Titre du module

IA-22 — Mini-projets pratiques IA pour l'IT

Partie 5 — Créer des outils, agents IA, projets et SaaS

---

2. Objectif pédagogique

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

  • choisir et réaliser un mini-projet IA adapté à son niveau et à son métier ;
  • appliquer concrètement tout ce qui a été vu (prompts, vérification, outils, sécurité, automatisation) ;
  • suivre une méthode de projet : objectif, scénario, étapes, critères de réussite, vigilance ;
  • produire un livrable réutilisable (assistant, script, analyseur, générateur, bot…) ;
  • intégrer sécurité, contrôle humain et vérification dans chaque projet.

Ce module propose un catalogue de 15 mini-projets (section 8), chacun décrit avec les mêmes champs, pour passer de la théorie à la pratique.

Prérequis : l'ensemble des parties 1 à 4, et surtout IA-09 (vérification), IA-13 (n8n), IA-15 (local), IA-17/18 (sécurité/gouvernance), IA-19/20/21 (API, outils, agents).

---

3. Niveau

Professionnel avancé / projet.

Module de mise en pratique. Les mini-projets vont du niveau intermédiaire au professionnel avancé : chacun indique son niveau pour que vous choisissiez selon votre progression.

---

4. Durée estimée

Activité Durée indicative
Lecture du catalogue 40 à 50 minutes
Cas pratique guidé (réaliser 1 projet) 1 à 2 heures
Exercice à faire seul 30 minutes
Quiz + flashcards de révision 20 minutes
Mini-projet de fin de module 2 à 4 heures (selon le projet)
Total réaliste variable : 4 à 8 heures selon le(s) projet(s) choisi(s)

---

5. Résumé clair et simple

Ce module est différent des précédents : c'est un atelier. Plutôt que d'apprendre une nouvelle notion, vous allez construire quelque chose d'utile en réutilisant tout ce que vous savez déjà. La meilleure façon d'ancrer des compétences IA, c'est de réaliser un projet du début à la fin.

Vous trouverez en section 8 un catalogue de 15 mini-projets orientés IT : assistant de support, générateur de scripts, analyseur de logs, générateur de documentation, assistant de révision, bot Telegram, assistant local, checklist de cybersécurité, résumeur de tickets, générateur de procédures, veille cybersécurité, rapports d'incident, troubleshooting réseau, assistant Docker/Linux, préparation d'entretien. Chacun est décrit avec la même fiche : objectif, niveau, prérequis, scénario, étapes, données d'entrée, résultat attendu, critères de réussite, points de vigilance, amélioration possible, lien métier, risques à éviter, idée d'évolution.

Tous ces projets reposent sur les mêmes briques vues dans le parcours : un bon prompt (IA-07/08), une structure d'outil claire (IA-20), parfois une API (IA-19) ou un workflow n8n (IA-13), souvent une IA locale (IA-15) pour le confidentiel. Et tous partagent les mêmes garde-fous : anonymiser, vérifier (IA-09), garder l'humain dans la boucle, journaliser.

Choisissez un projet à votre niveau, suivez sa fiche, et réalisez-le vraiment — c'est en faisant qu'on apprend. À la fin, vous aurez non seulement compris l'IA, mais vous aurez produit des outils concrets, valorisables dans votre travail ou votre portfolio.

---

6. Compétences visées

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

  • mener un mini-projet IA de bout en bout ;
  • transposer les méthodes du parcours en livrables concrets ;
  • choisir le bon niveau de projet et les bons outils ;
  • intégrer sécurité, vérification et contrôle humain à chaque étape ;
  • évaluer son projet avec des critères de réussite ;
  • faire évoluer un projet (améliorations, intégrations).

---

7. Notions clés à comprendre

  • Mini-projet : réalisation concrète et bornée, avec objectif et critères de réussite.
  • Scénario : situation réelle qui motive le projet.
  • Données d'entrée : ce que le projet consomme (toujours anonymisé si sensible).
  • Critères de réussite : comment savoir que le projet fonctionne.
  • Points de vigilance : risques et limites propres au projet.
  • Lien métier : en quoi le projet sert un vrai besoin IT.
  • Idée d'évolution : comment aller plus loin.
  • Garde-fous communs : anonymisation, vérification (IA-09), contrôle humain, journalisation.
  • Livrable : le résultat réutilisable du projet.

---

8. Cours complet structuré — Catalogue des 15 mini-projets

Chaque projet suit la même fiche. Garde-fous communs à tous : anonymiser les données, vérifier les sorties (IA-09), garder un humain pour les actions à conséquence, ne jamais envoyer de secrets/données sensibles (IA-17), préférer l'IA locale pour le confidentiel (IA-15).

Projet 1 — Assistant de support niveau 1

  • Objectif : aider à répondre aux demandes courantes de support.
  • Niveau : intermédiaire.
  • Prérequis : IA-07/08, IA-20.
  • Scénario : un technicien N1 reçoit des demandes répétitives (mot de passe, imprimante, accès).
  • Étapes : définir les cas fréquents → créer des gabarits de prompt → générer des brouillons → faire valider.
  • Données d'entrée : description de la demande (anonymisée).
  • Résultat attendu : un brouillon de réponse clair et professionnel.
  • Critères de réussite : réponses pertinentes, validées avant envoi, gain de temps mesurable.
  • Points de vigilance : ne jamais promettre l'invérifiable ; pas d'envoi automatique au client.
  • Amélioration possible : ajouter une base de connaissances (RAG, IA-05).
  • Lien métier : support / helpdesk.
  • Risques à éviter : réponses fausses, données personnelles dans le prompt.
  • Idée d'évolution : intégrer dans un workflow (IA-13).

Projet 2 — Générateur de scripts PowerShell

  • Objectif : produire des scripts PowerShell simples, commentés et sûrs.
  • Niveau : intermédiaire.
  • Prérequis : IA-11.
  • Scénario : un admin a besoin de scripts récurrents (rapports, inventaires).
  • Étapes : décrire le besoin → demander version simple commentée → explication ligne par ligne → tester en lab.
  • Données d'entrée : description de la tâche, contexte (OS, version).
  • Résultat attendu : un script commenté, non destructif, testé.
  • Critères de réussite : script compris, testé en lab, sans action destructive.
  • Points de vigilance : lecture intégrale, -WhatIf, pas de secrets en clair.
  • Amélioration possible : bibliothèque de gabarits de scripts.
  • Lien métier : systèmes Windows.
  • Risques à éviter : commandes destructives, exécution sans test.
  • Idée d'évolution : planifier les scripts et envoyer les rapports (IA-13).

Projet 3 — Analyseur de logs Linux

  • Objectif : résumer et repérer les anomalies dans des logs Linux.
  • Niveau : intermédiaire à professionnel.
  • Prérequis : IA-10, IA-16.
  • Scénario : trop de lignes de logs à analyser manuellement.
  • Étapes : extraire un échantillon → anonymiser → demander résumé + anomalies + gravité → vérifier dans les logs réels.
  • Données d'entrée : extrait de logs anonymisé.
  • Résultat attendu : synthèse claire avec anomalies classées.
  • Critères de réussite : anomalies pertinentes, confirmées dans les vrais logs.
  • Points de vigilance : anonymisation, l'IA peut mal interpréter ; cadre défensif (IA-16).
  • Amélioration possible : IA locale pour logs sensibles (IA-15).
  • Lien métier : systèmes / sécurité défensive.
  • Risques à éviter : fuite de logs, fausses conclusions.
  • Idée d'évolution : alerte enrichie automatique (IA-13).

Projet 4 — Générateur de documentation technique

  • Objectif : transformer des notes en procédures propres.
  • Niveau : intermédiaire.
  • Prérequis : IA-12.
  • Scénario : la documentation est en retard ou inexistante.
  • Étapes : rassembler les notes → anonymiser → demander une procédure structurée → vérifier commandes/chemins/versions.
  • Données d'entrée : notes brutes d'une intervention/installation.
  • Résultat attendu : procédure datée, structurée (prérequis, étapes, vérif, rollback).
  • Critères de réussite : procédure testée par un tiers, sans détail inventé.
  • Points de vigilance : interdire les inventions (champs [à renseigner]).
  • Lien métier : documentation, exploitation.
  • Amélioration possible : produire aussi un DEX (IA-12).
  • Risques à éviter : commandes fausses, procédure non testée.
  • Idée d'évolution : modèle de doc réutilisable pour l'équipe.

Projet 5 — Assistant de révision IT

  • Objectif : créer quiz et flashcards pour monter en compétence.
  • Niveau : débutant à intermédiaire.
  • Prérequis : IA-14.
  • Scénario : préparer un sujet (réseau, Linux, sécurité) ou une certification.
  • Étapes : choisir le sujet → générer quiz + flashcards → réviser en répétition espacée → vérifier les réponses.
  • Données d'entrée : sujet et niveau visés.
  • Résultat attendu : un set de quiz et flashcards exploitables.
  • Critères de réussite : contenus exacts (vérifiés), progrès mesurable.
  • Points de vigilance : vérifier les réponses (l'IA peut se tromper).
  • Lien métier : formation, montée en compétence.
  • Amélioration possible : plan d'apprentissage complet (IA-14).
  • Risques à éviter : apprendre une erreur, dépendance.
  • Idée d'évolution : suivi de progression personnel.

Projet 6 — Bot Telegram avec n8n et IA

  • Objectif : recevoir des notifications enrichies par IA sur Telegram.
  • Niveau : professionnel.
  • Prérequis : IA-13, IA-19.
  • Scénario : l'équipe veut des alertes claires et priorisées.
  • Étapes : déclencheur → préparation/anonymisation → nœud IA → validation → message Telegram.
  • Données d'entrée : événement/ticket/alerte (anonymisé).
  • Résultat attendu : message Telegram clair et priorisé.
  • Critères de réussite : messages utiles, données minimisées, humain sur les cas critiques.
  • Points de vigilance : coût API, données envoyées, mode dégradé.
  • Lien métier : supervision, support.
  • Amélioration possible : routage par catégorie.
  • Risques à éviter : fuite de données, action automatique sur cas critique.
  • Idée d'évolution : tableau de bord d'alertes.

Projet 7 — Assistant local avec Ollama ou LM Studio

  • Objectif : un assistant confidentiel qui ne sort pas les données.
  • Niveau : professionnel.
  • Prérequis : IA-15.
  • Scénario : besoin de traiter des données sensibles hors cloud.
  • Étapes : choisir l'outil (Ollama/LM Studio) → choisir un modèle adapté au matériel → tester sur cas réels → vérifier.
  • Données d'entrée : notes/logs internes (restent en local).
  • Résultat attendu : assistant local fonctionnel pour résumé/aide.
  • Critères de réussite : qualité suffisante, données non exposées, vérification maintenue.
  • Points de vigilance : « local ≠ fiable », limites matérielles.
  • Lien métier : confidentialité, environnements isolés.
  • Amélioration possible : exposer une API locale (IA-19).
  • Risques à éviter : excès de confiance, machine hôte non sécurisée.
  • Idée d'évolution : assistant documentaire local (RAG).

Projet 8 — Générateur de checklist cybersécurité défensive

  • Objectif : produire des checklists de durcissement.
  • Niveau : professionnel.
  • Prérequis : IA-16.
  • Scénario : besoin d'une checklist de durcissement pour un service.
  • Étapes : préciser le périmètre → générer la checklist → recouper avec sources officielles → adapter.
  • Données d'entrée : type de système à durcir.
  • Résultat attendu : checklist claire et recoupée.
  • Critères de réussite : éléments vérifiés (ANSSI/éditeur), cadre défensif respecté.
  • Points de vigilance : rejeter toute mesure affaiblissant la sécurité ; recouper.
  • Lien métier : sécurité défensive.
  • Amélioration possible : versions par OS/service.
  • Risques à éviter : fausses bonnes pratiques, sources non vérifiées.
  • Idée d'évolution : checklist intégrée à une procédure (IA-12).

Projet 9 — Résumeur automatique de tickets GLPI

  • Objectif : résumer et classer les tickets.
  • Niveau : professionnel.
  • Prérequis : IA-13, IA-20.
  • Scénario : flux de tickets trop important.
  • Étapes : extraire le ticket → anonymiser → résumé + catégorie + urgence → validation humaine sur critiques.
  • Données d'entrée : tickets (anonymisés).
  • Résultat attendu : résumé + classification fiables.
  • Critères de réussite : classification utile, cas critiques validés humainement.
  • Points de vigilance : données personnelles, faux classement.
  • Lien métier : support / ITSM.
  • Amélioration possible : routage automatique des non-critiques.
  • Risques à éviter : fuite, mauvaise priorisation automatique.
  • Idée d'évolution : statistiques de tickets.

Projet 10 — Générateur de procédures DEX

  • Objectif : produire des dossiers d'exploitation (DEX).
  • Niveau : professionnel.
  • Prérequis : IA-12.
  • Scénario : besoin de documenter l'exploitation d'un service.
  • Étapes : décrire le service → générer le DEX (tâches récurrentes, surveillance, sauvegardes, contacts) → vérifier.
  • Données d'entrée : description du service et de son exploitation.
  • Résultat attendu : un DEX clair et daté.
  • Critères de réussite : exploitable par un autre technicien, sans inventions.
  • Points de vigilance : vérifier commandes/contacts, ne rien inventer.
  • Lien métier : exploitation, transmission de connaissances.
  • Amélioration possible : modèle de DEX standard d'équipe.
  • Risques à éviter : informations périmées ou fausses.
  • Idée d'évolution : lien avec une supervision.

Projet 11 — Assistant de veille cybersécurité

  • Objectif : suivre et résumer l'actualité des menaces.
  • Niveau : professionnel.
  • Prérequis : IA-16, IA-13.
  • Scénario : besoin de rester informé sans y passer des heures.
  • Étapes : choisir des sources fiables → résumer les nouveautés → recouper les vulnérabilités → prioriser.
  • Données d'entrée : bulletins/sources de sécurité (publics).
  • Résultat attendu : synthèse de veille priorisée.
  • Critères de réussite : informations recoupées, sources officielles.
  • Points de vigilance : l'IA peut inventer une CVE → recouper (IA-09).
  • Lien métier : sécurité défensive, veille.
  • Amélioration possible : digest hebdomadaire automatisé (IA-13).
  • Risques à éviter : fausses références, désinformation.
  • Idée d'évolution : alertes ciblées sur votre stack.

Projet 12 — Générateur de rapports d'incident

  • Objectif : structurer des rapports d'incident.
  • Niveau : professionnel.
  • Prérequis : IA-12, IA-16.
  • Scénario : après incident, besoin d'un rapport clair et rapide.
  • Étapes : rassembler les faits (anonymisés) → générer le rapport (contexte, impact, actions, mesures) → vérifier.
  • Données d'entrée : faits constatés de l'incident.
  • Résultat attendu : rapport structuré et factuel.
  • Critères de réussite : faits exacts, pas d'invention, structure claire.
  • Points de vigilance : vérifier chaque fait, anonymiser.
  • Lien métier : sécurité, gestion d'incident.
  • Amélioration possible : modèle réutilisable + retour d'expérience.
  • Risques à éviter : faits inventés, données sensibles exposées.
  • Idée d'évolution : base de connaissances d'incidents.

Projet 13 — Assistant de troubleshooting réseau

  • Objectif : aider au diagnostic réseau.
  • Niveau : intermédiaire à professionnel.
  • Prérequis : IA-10.
  • Scénario : panne réseau à diagnostiquer rapidement.
  • Étapes : décrire contexte/symptômes → demander hypothèses classées + tests → mener les tests → conclure sur les faits.
  • Données d'entrée : contexte et symptômes (anonymisés).
  • Résultat attendu : arbre de diagnostic priorisé.
  • Critères de réussite : hypothèses pertinentes, tranchées par les mesures réelles.
  • Points de vigilance : l'IA ne connaît pas votre réseau ; tester soi-même.
  • Lien métier : réseaux, support.
  • Amélioration possible : gabarits par type de panne (IA-10).
  • Risques à éviter : appliquer une commande sans comprendre.
  • Idée d'évolution : checklist de diagnostic réseau.

Projet 14 — Assistant Docker/Linux

  • Objectif : aider sur les commandes et concepts Docker/Linux.
  • Niveau : intermédiaire à professionnel.
  • Prérequis : IA-11, IA-14.
  • Scénario : monter en compétence et gagner du temps sur Docker/Linux.
  • Étapes : poser une question/objectif → obtenir explication + commandes commentées → vérifier (man, doc) → tester en lab.
  • Données d'entrée : besoin technique précis.
  • Résultat attendu : commandes comprises et testées.
  • Critères de réussite : commandes vérifiées, comprises, testées en lab.
  • Points de vigilance : hallucinations de commandes ; vérifier la doc officielle.
  • Lien métier : conteneurs, systèmes.
  • Amélioration possible : mémo personnel de commandes.
  • Risques à éviter : commande destructive, copier sans comprendre.
  • Idée d'évolution : lab Docker d'entraînement.

Projet 15 — Assistant de préparation d'entretien IT

  • Objectif : s'entraîner aux entretiens techniques.
  • Niveau : débutant à professionnel.
  • Prérequis : IA-14.
  • Scénario : préparer un entretien (support, sysadmin, réseau, sécurité).
  • Étapes : indiquer le poste visé → générer des questions → s'entraîner à répondre → faire corriger → vérifier les réponses techniques.
  • Données d'entrée : intitulé du poste, niveau.
  • Résultat attendu : banque de questions/réponses + entraînement.
  • Critères de réussite : réponses exactes (vérifiées), aisance accrue.
  • Points de vigilance : vérifier l'exactitude technique ; ne pas réciter sans comprendre.
  • Lien métier : carrière, recrutement IT.
  • Amélioration possible : simulation d'entretien (questions/réponses en direct).
  • Risques à éviter : informations fausses, réponses apprises par cœur sans compréhension.
  • Idée d'évolution : fiche de préparation personnalisée.

---

9. Exemples concrets liés au monde IT

Les 15 projets ci-dessus sont les exemples concrets, couvrant support, systèmes, réseaux, Linux, Windows, cybersécurité défensive, documentation, automatisation, scripts, conteneurs et carrière. Quelques combinaisons utiles :

  • Projets 3 + 6 : analyseur de logs + notification Telegram = supervision enrichie.
  • Projets 4 + 10 : documentation + DEX = dossier d'exploitation complet.
  • Projets 7 + 9 : assistant local + résumeur de tickets = traitement confidentiel des tickets.
  • Projets 5 + 15 : révision + préparation d'entretien = montée en compétence et employabilité.

---

10. Cas pratique guidé — Réaliser le Projet 9 (Résumeur de tickets GLPI)

Objectif : réaliser un mini-projet de bout en bout, de la conception à la vérification.

Étape 1 — Cadrer. Objectif : résumer et classer les tickets. Forme : workflow n8n (IA-13) ou script + API (IA-19). Décidez cloud ou local selon la sensibilité (tickets clients → anonymiser ou local, IA-15).

Étape 2 — Entrée + anonymisation. Définissez ce que vous envoyez (objet + corps), et retirez noms, emails, identifiants.

Étape 3 — Contexte (prompt). « Résume ce ticket en 1-2 phrases, propose une catégorie (matériel/logiciel/réseau/accès) et une urgence (faible/moyenne/haute). Format : RÉSUMÉ | CATÉGORIE | URGENCE. Si incertain, urgence = moyenne. »

Étape 4 — Traitement + sortie. Appelez l'IA ; récupérez la sortie structurée. Plafonnez les coûts (IA-19).

Étape 5 — Vérification + validation. Vérifiez la cohérence ; routez les "haute" vers une validation humaine avant toute escalade.

Étape 6 — Journalisation + test. Journalisez les usages (IA-18). Testez sur des tickets factices avant le réel. Mesurez le gain de temps.

Résultat : un résumeur de tickets fonctionnel, sûr et contrôlé — votre premier vrai outil IA de production (après validation).

---

11. Exercice pratique à faire seul

Consigne. Choisissez UN mini-projet du catalogue (section 8) adapté à votre niveau et à votre métier. Avant de le réaliser, rédigez sa fiche de lancement :

  1. Objectif et scénario (votre cas réel) ;
  2. Données d'entrée et anonymisation ;
  3. Outils (n8n / script + API / IA locale) et pourquoi ;
  4. Étapes de réalisation ;
  5. Critères de réussite ;
  6. Points de vigilance et risques à éviter (dont sécurité et contrôle humain) ;
  7. une idée d'évolution.

Contexte. Vous transformez un projet du catalogue en plan d'action personnel.

Résultat attendu. Une fiche de lancement prête à exécuter.

Critères de réussite :

  • projet adapté à votre niveau/métier ;
  • entrée anonymisée, outils justifiés ;
  • étapes claires et réalistes ;
  • critères de réussite mesurables ;
  • vigilance, sécurité et contrôle humain présents ;
  • une évolution envisagée.

---

12. Quiz de 10 questions QCM

Une seule bonne réponse par question.

Q1. Quel est le but de ce module ?

  • A. Apprendre une nouvelle théorie
  • B. Réaliser des mini-projets concrets en réutilisant ses acquis
  • C. Installer un site
  • D. Coder en PHP

Q2. Avant d'envoyer des tickets/logs à une IA dans un projet, il faut :

  • A. Les anonymiser
  • B. Ajouter des secrets
  • C. Tout envoyer sans tri
  • D. Les supprimer

Q3. Pour un projet traitant des données sensibles, on privilégie :

  • A. Une API cloud publique sans précaution
  • B. Une IA locale (Ollama / LM Studio)
  • C. Un email non chiffré
  • D. Aucune anonymisation

Q4. Dans le résumeur de tickets, les cas « urgence haute » doivent :

  • A. Être traités automatiquement sans contrôle
  • B. Passer par une validation humaine
  • C. Être supprimés
  • D. Être ignorés

Q5. Un script généré pour un projet doit toujours être :

  • A. Exécuté en production sans test
  • B. Lu, compris et testé en lab
  • C. Envoyé au client
  • D. Ignoré

Q6. Pour un assistant de veille cybersécurité, une CVE citée par l'IA doit :

  • A. Être crue sans vérifier
  • B. Être recoupée avec une source officielle
  • C. Être diffusée immédiatement
  • D. Être inventée

Q7. Comment évaluer la réussite d'un mini-projet ?

  • A. Au hasard
  • B. Avec des critères de réussite définis à l'avance
  • C. Sans critère
  • D. Selon la couleur du livrable

Q8. Quel garde-fou est commun à tous les projets ?

  • A. Aucune vérification
  • B. Garder un humain dans la boucle pour les actions à conséquence
  • C. Actions destructives automatiques
  • D. Clés API en clair

Q9. Pour un assistant de révision, que faut-il faire des contenus générés ?

  • A. Les apprendre sans vérifier
  • B. Vérifier leur exactitude avant de réviser
  • C. Les ignorer
  • D. Les diffuser comme officiels

Q10. Quelle est la meilleure façon d'apprendre dans ce module ?

  • A. Lire seulement
  • B. Réaliser réellement un projet de bout en bout
  • C. Copier sans comprendre
  • D. Éviter de tester

---

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

Q1 → B. Le module est un atelier : réaliser des projets concrets. A, C et D sont hors sujet.

Q2 → A. On anonymise avant d'envoyer. B, C et D exposent des données.

Q3 → B. IA locale pour le sensible (IA-15). A, C et D exposent les données.

Q4 → B. Les cas critiques passent par une validation humaine. A est dangereux, C et D inadaptés.

Q5 → B. Un script se lit, se comprend, se teste en lab (IA-11). A et C sont dangereux, D inutile.

Q6 → B. Une CVE se recoupe avec une source officielle (IA-09/16). A, C et D sont risqués.

Q7 → B. On définit des critères de réussite à l'avance. Les autres réponses sont fausses.

Q8 → B. Humain dans la boucle pour les actions à conséquence. A, C et D sont dangereux.

Q9 → B. On vérifie l'exactitude avant de réviser (IA-14). A, C et D sont inadaptés.

Q10 → B. On apprend en réalisant un projet de bout en bout. A, C et D ne font pas progresser.

Barème indicatif : 8/10 ou plus = prêt à réaliser un projet. 5 à 7 = relisez les garde-fous communs (section 8). Moins de 5 = revoyez IA-09, IA-17 et IA-20.

---

14. Flashcards de révision

Carte 1 Q : Quel est le but de ce module ? R : Réaliser des mini-projets concrets en réutilisant ses acquis.

Carte 2 Q : Garde-fou commun n°1 sur les données ? R : Anonymiser ; jamais de secrets/données sensibles (IA-17).

Carte 3 Q : Pour le sensible, quel type d'IA ? R : IA locale (Ollama / LM Studio).

Carte 4 Q : Que faire des cas critiques (ticket "haute", action à impact) ? R : Validation humaine avant exécution.

Carte 5 Q : Un script de projet doit toujours être… ? R : Lu, compris et testé en lab.

Carte 6 Q : Une CVE citée par l'IA ? R : À recouper avec une source officielle.

Carte 7 Q : Comment évaluer un projet ? R : Avec des critères de réussite définis à l'avance.

Carte 8 Q : Garde-fou commun à tous les projets ? R : Humain dans la boucle pour les actions à conséquence.

Carte 9 Q : Contenus d'un assistant de révision ? R : À vérifier avant de réviser (l'IA peut se tromper).

Carte 10 Q : Meilleure façon d'apprendre ici ? R : Réaliser réellement un projet de bout en bout.

Carte 11 Q : Briques communes des projets ? R : Prompt (IA-07/08), structure d'outil (IA-20), API (IA-19) ou n8n (IA-13), local si sensible (IA-15).

Carte 12 Q : Que produire à la fin ? R : Un livrable réutilisable (assistant, script, analyseur, générateur, bot…).

---

15. Erreurs fréquentes

  • Choisir un projet trop ambitieux pour son niveau (commencer simple).
  • Sauter l'anonymisation des données d'entrée.
  • Ne pas définir de critères de réussite.
  • Oublier la vérification des sorties / des scripts.
  • Automatiser une action à conséquence sans validation humaine.
  • Ne pas tester en lab avant le réel.
  • Exposer des clés API ou des données sensibles.
  • Lire le catalogue sans rien réaliser (l'atelier sert à faire).

---

16. Bonnes pratiques

  • Choisir un projet adapté à son niveau et son métier.
  • Suivre la fiche (objectif → critères de réussite).
  • Anonymiser ; préférer le local pour le sensible (IA-15).
  • Vérifier les sorties et tester en lab (IA-09, IA-11).
  • Garder l'humain dans la boucle ; pas d'action destructive automatique.
  • Protéger les clés API et plafonner les coûts (IA-19).
  • Journaliser (IA-18) et documenter le projet (IA-12).
  • Itérer : réaliser, mesurer, améliorer.

---

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

Bloc obligatoire à lire attentivement.

Ce qu'il faut vérifier :

  • les données d'entrée (anonymisées ? sensibles ?) ;
  • les sorties (exactitude, format) avant usage (IA-09) ;
  • les scripts/commandes (lus, compris, testés en lab) ;
  • les critères de réussite (le projet fait-il ce qu'il doit ?).

Ce qu'il ne faut pas faire :

  • envoyer des secrets/données sensibles à une IA cloud ;
  • automatiser une action à conséquence sans validation ;
  • déployer un projet sans test ni journalisation ;
  • diffuser une sortie non vérifiée.

Risques de mauvaise utilisation :

  • propagation d'erreurs à grande échelle (un outil répète une faute) ;
  • fuite de données ; coûts d'API incontrôlés ; mauvaise décision automatique.

Risques de confidentialité :

  • les projets manipulent souvent tickets, logs, notes internes ;
  • anonymiser et préférer le local (IA-15) ; RGPD : IA-17 ; gouvernance : IA-18.

Limites :

  • chaque projet hérite des limites du modèle (hallucinations) ;
  • la qualité dépend des entrées et des prompts ;
  • aucun projet ne dispense de la vérification humaine.

Cas où une validation humaine est indispensable :

  • toute sortie vers un client / un livrable officiel ;
  • toute action en production ou de sécurité ;
  • tout traitement de données sensibles.

Principe à retenir : réaliser des projets est le meilleur apprentissage — à condition de garder, dans chacun, les garde-fous communs : anonymiser, vérifier, contrôle humain, journalisation.

---

18. Mini-projet de fin de module

Titre : « Mon mini-projet IA réalisé de A à Z »

Objectif. Réaliser réellement un mini-projet du catalogue (ou un projet personnel équivalent), de la conception au livrable testé.

Contexte. Vous concrétisez vos acquis. Tout repose sur des données anonymisées / de lab.

Prérequis. Avoir lu le catalogue (section 8) ; maîtriser IA-09, IA-17, IA-20.

Étapes :

  1. Choisir un projet adapté à votre niveau.
  2. Rédiger sa fiche (objectif, scénario, entrée, étapes, critères).
  3. Choisir les outils (n8n / script + API / IA locale) et sécuriser (anonymisation, clés, plafonds).
  4. Réaliser le projet (ou un prototype fonctionnel).
  5. Tester en lab et vérifier les sorties.
  6. Mesurer les critères de réussite et journaliser.
  7. Documenter le projet (IA-12) et noter une idée d'évolution.

Résultat attendu. Un mini-projet réalisé, testé, documenté.

Critères de réussite :

  • projet adapté au niveau, fiche claire ;
  • sécurité intégrée (anonymisation, clés, contrôle humain) ;
  • réalisé et testé en lab ;
  • critères de réussite mesurés ;
  • documentation et évolution prévues.

Amélioration possible. Présentez votre projet dans un portfolio ou sur LinkedIn (sans exposer de données sensibles) — c'est un excellent atout professionnel, et une transition idéale vers le module IA-23 (concevoir un SaaS).

---

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

  • n8n (docs.n8n.io), Ollama (ollama.com), LM Studio (lmstudio.ai) — pour réaliser les projets (workflows, IA locale). À vérifier avant publication (liens et conditions).
  • Documentation des API IA (OpenAI, Anthropic, Gemini, Mistral) — pour les projets utilisant une API. À vérifier avant publication (tarifs/limites évoluent).
  • Documentation officielle des technologies du projet (Linux, Docker docs.docker.com, Microsoft Learn, GLPI, ANSSI pour la sécurité) — pour vérifier les éléments techniques. À vérifier avant publication (liens variables).
  • Environnements de lab gratuits (VM, conteneurs) — pour réaliser et tester sans risque. À vérifier avant publication (disponibilité/licences).

Remarque : réalisez vos projets sur des données factices/anonymisées et en environnement de test. Ce module ne promet aucune certification.

---

20. Résumé final du module

  • Ce module est un atelier : on réalise des mini-projets pour ancrer les compétences.
  • Un catalogue de 15 projets IT couvre support, scripts, logs, documentation, révision, bot Telegram, IA locale, sécurité défensive, tickets GLPI, DEX, veille, rapports d'incident, réseau, Docker/Linux et préparation d'entretien.
  • Chaque projet a sa fiche (objectif, niveau, prérequis, scénario, étapes, données, résultat, critères, vigilance, amélioration, lien métier, risques, évolution).
  • Tous reposent sur les mêmes briques (prompt, structure d'outil, API ou n8n, local si sensible) et les mêmes garde-fous (anonymiser, vérifier, humain dans la boucle, journaliser).
  • À retenir : choisissez un projet à votre niveau et réalisez-le vraiment. C'est en faisant qu'on apprend — et vous obtenez des livrables valorisables. Étape finale : concevoir un SaaS (IA-23).

---

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 ?

(Dernier module du parcours prévu : IA-23 — Créer un SaaS de A à Z avec l'aide de l'IA.)