Rafiq IA Lab

IA-11 — IA pour scripts PowerShell, Bash et Python simples

---

1. Titre du module

IA-11 — IA pour scripts PowerShell, Bash et Python simples

Partie 3 — IA appliquée au travail IT

---

2. Objectif pédagogique

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

demander un script à une IA en fournissant le bon contexte technique ;
demander un script sécurisé, commenté, d'abord simple puis amélioré ;
demander une explication ligne par ligne d'un script ;
reconnaître des exemples de scripts simples en PowerShell, Bash et Python ;
appliquer une méthode de vérification d'un script généré par IA ;
identifier les dangers (suppression, commandes destructives, droits admin, données sensibles) ;
appliquer les bonnes pratiques : lire, comprendre, tester en lab, dry-run, confirmations, logs, sauvegarde.

Prérequis : IA-07/08 (prompts) et surtout IA-09 (vérification, -WhatIf, test en lab). Aucune expertise préalable en programmation n'est exigée, mais des bases aident.

---

3. Niveau

Intermédiaire.

Module pratique et sensible : un script mal compris peut casser un système. La discipline de vérification (IA-09) y est centrale.

---

4. Durée estimée

Activité	Durée indicative
Lecture du cours	50 à 60 minutes
Exemples + cas pratique guidé	35 minutes
Exercice à faire seul	20 minutes
Quiz + flashcards de révision	20 minutes
Mini-projet de fin de module	40 minutes
Total réaliste	environ 2h50

---

5. Résumé clair et simple

L'IA est très utile pour produire des brouillons de scripts : lister des utilisateurs, vérifier l'espace disque, exporter un rapport, sauvegarder un dossier, analyser des logs, surveiller un service. Elle fait gagner un temps réel sur l'écriture et la mise en forme.

Mais un script n'est pas un texte anodin : c'est du code qui agit sur un système. Une seule ligne mal comprise peut supprimer des fichiers, écraser des données ou nécessiter des droits dangereux. C'est pourquoi ce module repose sur une règle d'or : on ne lance jamais un script qu'on ne comprend pas, et jamais directement en production.

La bonne méthode tient en quelques réflexes. Côté demande : donner le contexte (OS, version, objectif), exiger un script commenté, sans action destructive, avec une gestion d'erreur simple, et demander d'abord une version simple puis des améliorations. Côté réception : lire le script en entier, demander une explication ligne par ligne, repérer les commandes dangereuses, tester en lab sur des données factices, utiliser un dry-run (-WhatIf en PowerShell, simulation en Bash/Python) quand c'est possible, puis ajouter confirmations, logs et sauvegarde.

Les exemples de ce module sont volontairement simples et non destructifs. Ils illustrent ce que l'IA peut produire, mais chaque script reste à adapter, comprendre et tester dans votre environnement. Et la confidentialité prime toujours : pas de secrets ni de données sensibles dans un prompt cloud (IA-17).

---

6. Compétences visées

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

rédiger une demande de script claire, sécurisée et contextualisée ;
obtenir un code commenté, en version simple puis améliorée ;
demander et exploiter une explication ligne par ligne ;
lire et comprendre un script simple en PowerShell, Bash ou Python ;
vérifier un script généré (lecture, dangers, dry-run, test en lab) ;
repérer les opérations destructives et les besoins de droits élevés ;
appliquer les bonnes pratiques de sécurité (confirmations, logs, sauvegarde).

---

7. Notions clés à comprendre

Script : un fichier de commandes exécutables (PowerShell .ps1, Bash .sh, Python .py).
Contexte technique : OS, version, shell, objectif, contraintes — à fournir à l'IA.
Commentaire : ligne explicative dans le code (n'est pas exécutée), précédée de # (Bash/Python) ou # (PowerShell).
Gestion d'erreur : code qui prévoit les cas d'échec (fichier absent, droits manquants).
Dry-run / simulation : exécution « à blanc » qui montre ce qui serait fait sans rien modifier (-WhatIf en PowerShell).
Commande destructive : commande qui supprime/écrase/force (ex. suppression récursive, formatage).
Droits administrateur / root : privilèges élevés ; un script qui les demande peut faire beaucoup de dégâts.
Idempotence : un script qu'on peut relancer sans effet de bord (notion utile, pas obligatoire).
Test en lab : essai en environnement isolé, sur données factices.

---

8. Cours complet structuré

8.1 — Comment demander un script à une IA

Reprenez la méthode R-C-T-F-C (IA-07) appliquée au code :

Rôle : « Tu es expert PowerShell / Bash / Python. »
Contexte : OS et version (« Windows Server 2019 », « Ubuntu 22.04 », « Python 3.11 »), où il s'exécute, avec quels droits.
Tâche : l'objectif précis (« exporter en CSV la liste des utilisateurs locaux »).
Format : « script commenté + explication courte ».
Contraintes : « aucune action destructive, gestion d'erreur simple, dry-run si pertinent ».

Donner le contexte technique est crucial : un script Bash valide sur Ubuntu peut échouer ailleurs ; une cmdlet PowerShell peut différer selon la version.

8.2 — Demander un script sécurisé et commenté

Imposez des contraintes de sécurité dès la demande :

« aucune action destructive » (pas de suppression/écrasement non demandé) ;
« commente chaque ligne » (pour comprendre et vérifier) ;
« ajoute une gestion d'erreur simple » (vérifier que les chemins/fichiers existent) ;
« propose une version dry-run » quand l'action modifie quelque chose ;
« indique les droits nécessaires » et « signale les points de vigilance ».

8.3 — Demander une version simple puis améliorée

Procédez par paliers :

Version simple : « Donne d'abord une version minimale et claire. »
Compréhension : lisez, testez, demandez les points obscurs.
Amélioration : « Ajoute la gestion d'erreur », « ajoute un log », « ajoute une confirmation avant action ».

Cette progression vous fait comprendre le code au lieu de recevoir un bloc complexe d'un coup.

8.4 — Demander une explication ligne par ligne

Réflexe indispensable avant d'exécuter quoi que ce soit :

« Explique ce script ligne par ligne, en indiquant ce que fait chaque commande, les droits requis, et tout risque éventuel. »

Puis vérifiez l'explication (l'IA peut se tromper sur son propre code) avec l'aide intégrée (Get-Help, man, doc Python) — méthode IA-09.

8.5 — Exemples de scripts PowerShell

Exemples simples et non destructifs, à adapter et tester. Ne pas exécuter sans comprendre.

a) Lister les comptes utilisateurs locaux

# Récupère les comptes locaux et affiche nom + état (activé/désactivé)
Get-LocalUser | Select-Object Name, Enabled

b) Vérifier l'espace disque

# Affiche, pour chaque disque, l'espace libre et total en Go
Get-PSDrive -PSProvider FileSystem |
  Select-Object Name,
    @{Name='LibreGo'; Expression={[math]::Round($_.Free/1GB,1)}},
    @{Name='TotalGo'; Expression={[math]::Round(($_.Used+$_.Free)/1GB,1)}}

c) Exporter un rapport CSV

# Exporte la liste des utilisateurs locaux dans un fichier CSV daté
$date = Get-Date -Format "yyyy-MM-dd"
$chemin = "C:\rapports\utilisateurs_$date.csv"
# Vérifie que le dossier de destination existe avant d'écrire
if (Test-Path "C:\rapports") {
    Get-LocalUser | Select-Object Name, Enabled |
      Export-Csv -Path $chemin -NoTypeInformation -Encoding UTF8
    Write-Host "Rapport créé : $chemin"
} else {
    Write-Warning "Le dossier C:\rapports n'existe pas."
}

8.6 — Exemples de scripts Bash

d) Sauvegarde simple (copie archivée, sans suppression)

#!/bin/bash
# Crée une archive datée d'un dossier source vers un dossier de sauvegarde.
# Aucune suppression : opération non destructive.
SOURCE="/var/www/site"
DEST="/backups"
DATE=$(date +%Y-%m-%d_%H-%M)

# Vérifie que la source existe avant d'agir
if [ -d "$SOURCE" ]; then
    tar -czf "$DEST/site_$DATE.tar.gz" "$SOURCE" && echo "Sauvegarde OK : $DEST/site_$DATE.tar.gz"
else
    echo "Erreur : dossier source introuvable ($SOURCE)" >&2
fi

e) Analyse rapide de logs (lecture seule)

#!/bin/bash
# Affiche les 10 adresses IP les plus fréquentes dans un log (lecture seule).
LOG="/var/log/nginx/access.log"
if [ -f "$LOG" ]; then
    awk '{print $1}' "$LOG" | sort | uniq -c | sort -rn | head -10
else
    echo "Log introuvable : $LOG" >&2
fi

f) Surveillance d'un service (lecture seule)

#!/bin/bash
# Vérifie si un service est actif et affiche un message clair.
SERVICE="nginx"
if systemctl is-active --quiet "$SERVICE"; then
    echo "Le service $SERVICE est actif."
else
    echo "ATTENTION : le service $SERVICE est inactif." >&2
fi

8.7 — Exemples de scripts Python

g) Lire un fichier (lecture seule)

# Lit un fichier texte et affiche son nombre de lignes.
chemin = "notes.txt"
try:
    with open(chemin, "r", encoding="utf-8") as f:
        lignes = f.readlines()
    print(f"{len(lignes)} lignes dans {chemin}")
except FileNotFoundError:
    print(f"Fichier introuvable : {chemin}")

h) Générer un rapport simple

# Crée un petit rapport texte daté à partir de quelques valeurs.
from datetime import date

elements = {"Serveurs actifs": 12, "Alertes": 3, "Tickets ouverts": 7}
with open(f"rapport_{date.today()}.txt", "w", encoding="utf-8") as f:
    f.write(f"Rapport du {date.today()}\n")
    for cle, valeur in elements.items():
        f.write(f"- {cle} : {valeur}\n")
print("Rapport généré.")

i) Manipuler un CSV (lecture)

# Lit un CSV et compte les lignes par valeur d'une colonne "statut".
import csv
from collections import Counter

compte = Counter()
try:
    with open("tickets.csv", newline="", encoding="utf-8") as f:
        for ligne in csv.DictReader(f):
            compte[ligne.get("statut", "inconnu")] += 1
    for statut, n in compte.items():
        print(f"{statut} : {n}")
except FileNotFoundError:
    print("Fichier tickets.csv introuvable.")

Ces exemples sont volontairement simples et non destructifs. Avant tout usage réel : lisez, comprenez, adaptez les chemins, et testez en lab sur des données factices.

8.8 — Méthode de vérification d'un script généré par IA

Application directe d'IA-09 au code :

Lire le script en entier : que fait-il, sur quoi, avec quels droits ?
Repérer les actions destructives (suppression, écrasement, forçage) et les chemins ciblés.
Recouper les commandes/cmdlets avec l'aide officielle (Get-Help -Full, man, doc Python).
Tester en lab sur des données factices ; utiliser un dry-run (-WhatIf) quand c'est possible.
Valider : ajouter confirmations, logs et sauvegarde ; décision humaine avant la production.

8.9 — Les dangers à connaître

Suppression de fichiers : une commande de suppression mal ciblée (chemin vide, variable non définie) peut détruire bien plus que prévu.
Commandes destructives : formatage, écrasement, arrêt de service en masse.
Droits administrateur / root : un script exécuté en root amplifie tout dégât.
Données sensibles : ne jamais coder en dur des mots de passe, clés API, tokens dans un script, ni les coller dans un prompt (IA-17).
Confiance excessive : un script « qui a l'air bien » peut contenir une erreur subtile.

8.10 — Les bonnes pratiques de sécurité

Lire et comprendre avant d'exécuter.
Tester en lab sur des données factices ; jamais en production d'emblée.
Dry-run / -WhatIf pour simuler les actions qui modifient.
Confirmations avant toute action sensible.
Logs : journaliser ce que fait le script.
Sauvegarde préalable avant toute opération à risque.
Vérifier les chemins et variables (un chemin vide est un piège classique).
Ne jamais stocker de secrets en clair dans le code.

---

9. Exemples concrets liés au monde IT

Inventaire rapide. Le script PowerShell (a) liste les comptes locaux pour un audit léger ; vous vérifiez la cmdlet avec Get-Help.
Supervision d'espace disque. Le script (b) prépare un état des disques ; à intégrer plus tard dans un rapport automatisé (IA-13).
Rapport CSV daté. Le script (c) produit un export horodaté ; vous vérifiez le dossier de destination et l'encodage.
Sauvegarde non destructive. Le script Bash (d) archive un dossier sans rien supprimer ; vous testez sur un dossier factice avant le vrai site.
Top des IP dans un log. Le script (e), en lecture seule, aide à repérer une IP très active (à recouper en sécurité, IA-16) ; pensez à anonymiser si vous partagez la sortie.
Veille de service. Le script (f) signale un service arrêté ; base d'une future alerte (IA-13).
Traitement de données. Les scripts Python (g, h, i) lisent/produisent des fichiers simples ; parfaits pour automatiser un petit reporting.

Tous ces scripts sont des points de départ : à comprendre, adapter et tester avant usage réel.

---

10. Cas pratique guidé

Objectif : faire produire par l'IA un script de nettoyage, puis le sécuriser et le vérifier (IA-09).

Contexte. Vous voulez un script Bash qui supprime les fichiers .tmp de plus de 7 jours dans un dossier de cache. C'est une opération potentiellement destructive : prudence maximale.

Étape 1 — Demander une version simple et commentée. Prompt : « Tu es admin Linux (Ubuntu 22.04). Écris un script Bash qui liste (sans supprimer) les fichiers .tmp de plus de 7 jours dans /var/cache/app. Commente chaque ligne. » On commence par lister, pas supprimer.

Étape 2 — Demander l'explication ligne par ligne. Faites expliquer chaque commande (notamment find, ses options de temps et de motif), puis vérifiez avec man find (IA-09).

Étape 3 — Demander une version « dry-run » avant suppression. Prompt : « Ajoute une variable de simulation : si DRY_RUN=1, le script affiche seulement ce qu'il supprimerait, sans rien supprimer. »

Étape 4 — Ajouter les garde-fous. Demandez : vérification que le dossier existe et n'est pas vide, confirmation avant suppression réelle, et un log des fichiers supprimés. Vérifiez qu'aucune variable de chemin ne peut être vide (piège classique).

Étape 5 — Tester en lab. Créez un dossier de test avec de faux .tmp de dates variées. Lancez d'abord en DRY_RUN=1, vérifiez la liste, puis testez la suppression sur le dossier de test uniquement. Lisez le log. Ce n'est qu'après cela qu'un usage réel pourrait être envisagé.

Résultat du cas pratique : vous avez transformé une demande risquée en script sécurisé (liste → dry-run → suppression contrôlée), testé en lab et journalisé.

---

11. Exercice pratique à faire seul

Consigne. Choisissez un besoin de script simple (PowerShell, Bash ou Python) parmi : « exporter la liste des services en cours », « archiver un dossier de logs », « compter les erreurs dans un fichier de log », « générer un rapport CSV ». Puis :

Rédigez le prompt (R-C-T-F-C + contraintes de sécurité : commenté, non destructif, gestion d'erreur, dry-run si pertinent).
Demandez une version simple puis une amélioration.
Notez 3 points à vérifier dans le script (commandes, chemins, droits).
Décrivez comment vous le testeriez en lab (données factices, dry-run).
Indiquez 2 dangers potentiels et leur parade.

Contexte. Vous appliquez la chaîne « demander → comprendre → sécuriser → tester ».

Résultat attendu. Le prompt + le plan de vérification et de test.

Critères de réussite :

le prompt impose des contraintes de sécurité claires ;
la logique version simple → améliorée est respectée ;
les points à vérifier sont pertinents ;
le test en lab est concret et sans risque ;
les dangers et parades sont identifiés ;
aucun secret ni donnée sensible dans le prompt.

---

12. Quiz de 10 questions QCM

Une seule bonne réponse par question.

Q1. Avant d'exécuter un script généré par IA, il faut d'abord :

A. Le lancer en production pour voir
B. Le lire et le comprendre en entier
C. Lui faire confiance car l'IA ne se trompe jamais
D. L'envoyer à un client

Q2. Quel contexte est utile pour demander un script ?

A. La couleur du terminal
B. L'OS, la version, le shell, l'objectif et les droits
C. Le nom de l'utilisateur
D. Rien

Q3. En PowerShell, quelle option permet de simuler une action sans l'exécuter ?

A. -Force
B. -WhatIf
C. -Recurse
D. -Confirm:$false

Q4. Pourquoi demander un script « commenté » ?

A. Pour le rendre plus long
B. Pour comprendre et vérifier chaque ligne
C. Pour le ralentir
D. Cela ne sert à rien

Q5. Quelle pratique est la plus sûre pour tester un script ?

A. Le tester en production
B. Le tester en lab sur des données factices
C. Ne pas le tester
D. Le tester sur les fichiers clients

Q6. Que ne faut-il jamais mettre en clair dans un script ?

A. Un commentaire
B. Un mot de passe, une clé API ou un token
C. Une variable de chemin
D. Un message d'erreur

Q7. Un chemin de variable vide dans une commande de suppression est :

A. Sans danger
B. Un piège classique pouvant entraîner une suppression bien plus large que prévu
C. Toujours bloqué automatiquement
D. Une bonne pratique

Q8. Quelle est une bonne progression de demande ?

A. Tout demander dans un script complexe d'un coup
B. Version simple → compréhension → amélioration
C. Ne jamais itérer
D. Demander uniquement la version finale sans explication

Q9. Après avoir reçu une explication ligne par ligne de l'IA, on doit :

A. La croire sans vérifier
B. La vérifier avec l'aide officielle (Get-Help, man, doc Python)
C. La supprimer
D. L'ignorer

Q10. Pour une opération à risque, quels garde-fous ajouter ?

A. Aucun
B. Confirmation, logs, sauvegarde préalable, dry-run
C. Exécution en root sans test
D. Suppression immédiate sans confirmation

---

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

Q1 → B. On lit et comprend le script avant tout. A, C et D sont dangereux ou irresponsables.

Q2 → B. OS, version, shell, objectif et droits sont le contexte utile. Les autres options sont hors sujet.

Q3 → B. -WhatIf simule l'action en PowerShell. -Force (A) et -Confirm:$false (D) suppriment des protections ; -Recurse (C) étend l'action.

Q4 → B. Les commentaires aident à comprendre et vérifier. A, C et D sont faux.

Q5 → B. Tester en lab sur des données factices est le plus sûr. A et D sont dangereux, C est irresponsable.

Q6 → B. Jamais de secrets en clair (mot de passe, clé, token). Les autres éléments sont normaux.

Q7 → B. Une variable de chemin vide est un piège classique pouvant élargir une suppression. A, C et D sont faux.

Q8 → B. Version simple → compréhension → amélioration est la bonne progression. A et D sautent la compréhension, C se prive d'itération.

Q9 → B. On vérifie l'explication avec l'aide officielle (l'IA peut se tromper sur son propre code). A, C et D sont inadaptés.

Q10 → B. Confirmation, logs, sauvegarde et dry-run sont les garde-fous. A, C et D sont dangereux.

Barème indicatif : 8/10 ou plus = notions acquises. 5 à 7 = relisez les sections 8.8 et 8.9. Moins de 5 = reprenez le cours et rejouez le cas pratique en mode dry-run.

---

14. Flashcards de révision

Carte 1 Q : Premier réflexe avant d'exécuter un script généré ? R : Le lire et le comprendre en entier.

Carte 2 Q : Contexte à fournir pour demander un script ? R : OS, version, shell, objectif, droits requis.

Carte 3 Q : Option PowerShell pour simuler une action ? R : -WhatIf.

Carte 4 Q : Pourquoi demander un script commenté ? R : Pour comprendre et vérifier chaque ligne.

Carte 5 Q : Où tester un script en priorité ? R : En lab, sur des données factices (jamais en production d'emblée).

Carte 6 Q : Que ne jamais mettre en clair dans un script ? R : Mots de passe, clés API, tokens.

Carte 7 Q : Danger d'une variable de chemin vide ? R : Une suppression/écrasement bien plus large que prévu.

Carte 8 Q : Bonne progression de demande ? R : Version simple → compréhension → amélioration.

Carte 9 Q : Que faire de l'explication ligne par ligne de l'IA ? R : La vérifier avec l'aide officielle (Get-Help, man, doc Python).

Carte 10 Q : Garde-fous pour une opération à risque ? R : Confirmation, logs, sauvegarde préalable, dry-run.

Carte 11 Q : Pourquoi commencer par « lister » avant « supprimer » ? R : Pour vérifier la cible sans rien détruire.

Carte 12 Q : Un script « qui a l'air bien » est-il sûr ? R : Non : il peut contenir une erreur subtile ; vérifier et tester.

---

15. Erreurs fréquentes

Exécuter sans lire ni comprendre le script.
Lancer directement en production sans test en lab.
Ignorer les commandes destructives ou les droits root nécessaires.
Coder des secrets en clair ou les coller dans un prompt.
Oublier de vérifier les chemins et variables (chemin vide = danger).
Demander un script complexe d'un coup au lieu de progresser par paliers.
Croire l'explication de l'IA sur son propre code sans la recouper.
Ne pas prévoir de sauvegarde avant une opération à risque.

---

16. Bonnes pratiques

Donner le contexte technique (OS, version, shell, droits) dans la demande.
Exiger un script commenté, non destructif, avec gestion d'erreur.
Procéder par paliers : version simple, puis améliorations.
Demander une explication ligne par ligne et la vérifier (IA-09).
Tester en lab sur des données factices ; dry-run / -WhatIf pour les actions modifiantes.
Ajouter confirmations, logs et sauvegarde pour les opérations à risque.
Vérifier chemins et variables, repérer les opérations destructives.
Ne jamais stocker de secrets en clair ni les envoyer à un service cloud (IA-17).

---

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

Bloc obligatoire à lire attentivement.

Ce qu'il faut vérifier :

chaque commande/cmdlet et ses options (via Get-Help, man, doc Python) ;
les chemins ciblés et les variables (aucune ne doit pouvoir être vide) ;
les droits requis et les actions destructives éventuelles ;
le comportement réel via dry-run puis test en lab.

Ce qu'il ne faut pas faire :

exécuter un script non compris ou non testé, surtout en production ;
coder des secrets en clair ou les coller dans un prompt cloud ;
lancer en root/administrateur sans nécessité et sans test.

Risques de mauvaise utilisation :

suppression ou écrasement de données par une commande mal ciblée ;
arrêt de services, indisponibilité, perte de données ;
fuite de secrets intégrés au script ou au prompt.

Risques de confidentialité :

un script ou ses données d'exemple peuvent contenir des informations sensibles ;
secrets, données personnelles, RGPD : module IA-17.

Limites de l'IA pour le code :

elle peut produire une commande inexistante ou inadaptée à votre version (hallucination, IA-04) ;
son explication de son propre code peut être fausse ;
un code « propre » n'est pas un code « sûr » par défaut.

Cas où une validation humaine est indispensable :

tout script destiné à la production ;
toute opération destructive ou nécessitant des droits élevés ;
tout script manipulant des données sensibles ou critiques.

Principe à retenir : l'IA écrit le brouillon ; vous lisez, comprenez, testez et sécurisez avant tout usage réel. La méthode de vérification est celle d'IA-09.

---

18. Mini-projet de fin de module

Titre : « Mon trio de scripts utiles, sécurisés et testés »

Objectif. Produire, avec l'aide de l'IA, trois scripts simples (un par langage si possible), entièrement compris, sécurisés et testés en lab.

Contexte. Vous constituez une petite boîte à outils personnelle. Aucun environnement de production ne doit être touché : tout se fait sur des données factices.

Prérequis. Avoir lu le cours (section 8) et maîtriser la vérification (IA-09).

Étapes :

Choisir 3 besoins simples (ex. PowerShell : rapport CSV ; Bash : archive d'un dossier ; Python : comptage dans un CSV).
Pour chacun, rédiger un prompt sécurisé (commenté, non destructif, gestion d'erreur, dry-run si pertinent).
Demander l'explication ligne par ligne et la vérifier (aide officielle).
Tester chaque script en lab sur des données factices ; utiliser un dry-run quand c'est utile.
Ajouter les garde-fous nécessaires (logs, confirmation, vérification de chemin).
Documenter chaque script (objectif, prérequis, usage, points de vigilance) — base du module IA-12.

Résultat attendu. Trois scripts simples, compris, sécurisés et testés, avec une mini-doc.

Critères de réussite :

chaque script est compris (vous savez expliquer chaque ligne) ;
aucune action destructive non maîtrisée ;
chaque script a été testé en lab ;
garde-fous présents (logs/confirmation/vérif. de chemin) ;
aucun secret en clair ;
mini-doc claire pour chacun.

Amélioration possible. Reliez ces scripts à une automatisation (IA-13) : par exemple, planifier le script de rapport et envoyer le résultat — toujours avec validation et contrôle des données.

---

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

Aide intégrée : Get-Help <cmdlet> -Full (PowerShell), man <commande> (Bash), help() et la doc Python — gratuites et indispensables pour vérifier ce que fait réellement une commande. (Gratuit, disponible localement.)
Documentation officielle : Microsoft Learn (PowerShell), pages de manuel Linux, documentation Python (docs.python.org) — références pour recouper la syntaxe et les options. À vérifier avant publication (liens variables selon versions).
Versions gratuites des assistants (ChatGPT, Claude, Gemini, Mistral) — pour générer et faire expliquer des scripts simples sur des cas factices. À vérifier avant publication (offres variables).
Environnements de test gratuits : machines virtuelles (ex. VirtualBox), conteneurs, ou un poste de test, pour exécuter les scripts sans risque. À vérifier avant publication (vérifier la disponibilité et les licences des outils choisis).

Remarque : la meilleure sécurité, c'est de tester en lab et de comprendre chaque ligne. Ce module ne promet aucune certification.

---

20. Résumé final du module

L'IA produit d'excellents brouillons de scripts (PowerShell, Bash, Python), mais un script agit sur un système : on ne lance jamais ce qu'on ne comprend pas.
Côté demande : contexte technique, script commenté, non destructif, avec gestion d'erreur, version simple puis améliorée, et explication ligne par ligne.
Côté réception : lire, recouper les commandes (aide officielle), tester en lab, utiliser dry-run / -WhatIf, ajouter confirmations, logs, sauvegarde.
Dangers majeurs : suppression/écrasement, commandes destructives, droits root, données sensibles (jamais de secrets en clair).
Les exemples fournis sont simples et non destructifs : des points de départ à comprendre, adapter et tester.
Méthode de vérification = celle d'IA-09. Confidentialité = IA-17. Étapes suivantes : documenter (IA-12), automatiser (IA-13).

---

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 ?

(Module suivant prévu : IA-12 — IA pour documentation technique, procédures, DAT, DEX et rapports.)