Prompts module 2 : les métiers de l'exploitation, du support à la sécurité

Jour 15 · 17/11 — Sysadmin : diagnostiquer depuis les journaux

Objectif : obtenir un diagnostic appuyé sur les lignes du journal, pas une liste de causes génériques.

Théorie 1/2 : le prompt faible

Mon site web est en panne, je fais quoi ?

Diagnostic : pas de système, pas de service, pas de symptôme, pas de journal. Le modèle ne peut produire que la liste générique de tous les forums. Parties manquantes : contexte, entrées, format de sortie, critères de réussite.

Théorie 2/2 : le prompt corrigé

Contexte : serveur Debian 13, nginx devant une appli PHP-FPM. Depuis
08:14 le site renvoie 502. Je suis le seul admin ; je peux lire les
journaux et redémarrer des services, pas modifier l'appli.
Tâche : trouve la cause la plus probable à partir des journaux ci-dessous.
Entrées :
<nginx_error>(20 dernières lignes de /var/log/nginx/error.log)</nginx_error>
<journal>(journalctl -u php8.4-fpm --since "08:00")</journal>
Sortie : 1) la ligne du journal qui désigne la cause, citée à
l'identique ; 2) la cause en une phrase ; 3) une commande pour la
confirmer ; 4) la correction, sans redémarrer autre chose.
Si les journaux ne montrent pas la cause, dis-le et dis quoi collecter.

Pratique (30 min)

1. Dans une VM Debian, installez nginx, puis cassez-le : arrêtez le service vers lequel il relaie, ou mettez une erreur de syntaxe dans un fichier de site et rechargez.
2. Collectez journalctl -u nginx --since "10 min ago" -p warning et les dernières lignes du journal d'erreurs de nginx.
3. Lancez le prompt faible, puis le corrigé, sur le modèle local. Cherchez chaque ligne citée avec grep -F.
4. Enregistrez le prompt corrigé en fiche prompts/sysadmin-log-diagnosis.md avec deux cas de test : votre installation cassée et un journal sain (la bonne réponse est « aucune cause dans ces journaux »).

Avec votre IA : « Voici un extrait de journal entre balises <log>. Ne diagnostique pas. Interroge-moi : pose trois questions qui m'obligent à lire les lignes moi-même (quel service, quelle heure, quel code d'erreur), puis dis-moi ce que j'ai manqué. »

Synthèse (10 min)

Trois lignes : ce qui manquait au prompt faible, les quatre parties de la sortie, le cas de test du journal sain et pourquoi il compte. Puis refaites les exercices sans notes.

Jour 16 · 18/11 — Sysadmin : demander un script digne de confiance

Objectif : obtenir un script shell avec des sécurités intégrées, et le relire avant qu'il tourne.

Théorie 1/2 : le prompt faible

Écris un script pour nettoyer les vieux fichiers du serveur.

Diagnostic : « vieux » et « fichiers » ne sont pas définis, et rien ne vous protège. Un modèle écrira sans broncher find / -mtime +30 -delete. Manquent : quel dossier, quel âge, quel shell, un mode simulation, une trace, ce qui ne doit jamais être touché.

Théorie 2/2 : le prompt corrigé

Écris un script bash pour Debian 13.
Tâche : supprimer les fichiers de plus de 30 jours dans /var/backups/app
seulement, sans jamais suivre de lien symbolique ni sortir de ce dossier.
Contraintes : commencer par set -euo pipefail ; le mode par défaut est
une simulation qui affiche seulement ce qui serait supprimé ; une option
--apply supprime ; afficher chaque chemin supprimé ; aucun outil hors
coreutils et findutils ; le script doit passer shellcheck sans
avertissement.
Sortie : le script, puis la liste de chaque commande lancée et pourquoi.

Pratique (30 min)

1. Créez une arborescence de test : mkdir -p /tmp/lab/app && touch -d "40 days ago" /tmp/lab/app/old.tar && touch /tmp/lab/app/new.tar, et un lien symbolique vers /etc dedans.
2. Demandez le script avec le prompt corrigé, pointé sur /tmp/lab/app. Lisez chaque ligne avant de lancer quoi que ce soit.
3. Passez shellcheck, puis la simulation, puis --apply. Vérifiez que seul old.tar est parti et que /etc est intact.
4. Fiche : prompts/sysadmin-cleanup-script.md, avec les vérifications faites.

Avec votre IA : « Relis ce script ligne par ligne [coller]. Pour chaque ligne, dis ce qu'elle fait et ce qui pourrait mal tourner sur un serveur de production. Ne le réécris pas ; je le corrigerai moi-même. »

Le faire faire par un agent : maintenant que vous en avez écrit et relu un à la main, un agent de code peut rédiger ce genre de script et lancer ShellCheck et la simulation dans un dossier de labo avant de vous le montrer : « Écris le script de nettoyage de prompts/sysadmin-cleanup-script.md, lance shellcheck et une simulation sur /tmp/lab/app, et montre-moi la sortie ; ne lance pas --apply. » Vous relisez toujours le script et lancez --apply vous-même.

Synthèse (10 min)

Trois lignes : périmètre, simulation, vérification extérieure. Puis refaites les exercices sans notes.

Jour 17 · 19/11 — Support : le tri et la réponse à l'utilisateur

Objectif : classer un ticket et répondre à l'utilisateur avec des mots qu'il comprend.

Théorie 1/2 : le prompt faible

Réponds à ce ticket : « outlook marche plus depuis ce matin!!! »

Diagnostic : le modèle ne connaît ni votre environnement, ni votre politique (ce que l'utilisateur peut faire seul), ni ce qu'est une bonne réponse. Il inventera des étapes, demandera peut-être de réinstaller Office. Un prompt de support a besoin du contexte du service, des actions permises et du ton.

Théorie 2/2 : le prompt corrigé

Contexte : support informatique d'une société de 40 personnes,
Microsoft 365, Windows 11. Les utilisateurs peuvent redémarrer les
applis et le PC ; ils ne peuvent ni installer de logiciel ni changer
les réglages de compte.
Tâche 1 : classe le ticket : catégorie (email, network, hardware,
account, other), urgence (bloque le travail : oui ou non),
informations manquantes (liste).
Tâche 2 : rédige une réponse à l'utilisateur : accuser réception, deux
étapes sûres qu'il peut essayer, la question qui nous aiderait le plus.
Contraintes : mots simples, moins de 90 mots, sans reproche, sans
promettre un délai qu'on ne tiendra pas.
<ticket>outlook marche plus depuis ce matin!!!</ticket>
Sortie : JSON pour la tâche 1, puis le texte de la réponse.

Pratique (30 min)

1. Écrivez huit courts tickets fictifs (sans vrais noms), du vague au précis, avec la catégorie attendue pour chacun.
2. Lancez le prompt corrigé sur les huit à température 0 ; validez le JSON et comptez les bonnes catégories.
3. Lisez chaque réponse comme l'utilisateur : une étape est-elle interdite par la politique ? Notez-les.
4. Fiche prompts/support-triage-reply.md avec les huit tickets comme tests.

Avec votre IA : « Joue une utilisatrice agacée et non technique dont la messagerie ne marche plus. Je suis le technicien support. Ne réponds à mes questions qu'avec ce qu'une vraie utilisatrice saurait ; après dix échanges, dis-moi lesquelles de mes questions étaient utiles et lesquelles étaient du jargon. »

Synthèse (10 min)

Trois lignes : le contexte dont un prompt de support a besoin, pourquoi deux livrables, ce que vous vérifiez dans la réponse. Puis refaites les exercices sans notes.

Jour 18 · 20/11 — Support : une procédure que l'utilisateur peut suivre

Objectif : transformer un ticket résolu en guide pas à pas pour les utilisateurs, et le tester sur quelqu'un.

Théorie 1/2 : le prompt faible

Écris un guide pour se connecter au VPN.

Diagnostic : quel client VPN, quel système, pour qui ? Le modèle produira un guide plausible pour un client quelconque, avec des noms de menus qui n'existent peut-être pas dans le vôtre. Une procédure ne vaut que par ses écrans et libellés exacts, que vous devez fournir.

Théorie 2/2 : le prompt corrigé

Contexte : les utilisateurs sont des employés de bureau sous Windows 11 ;
le client VPN est déjà installé. Voici mes notes de résolution du
ticket, avec les libellés exacts à l'écran :
<notes>…</notes>
Tâche : écris une procédure pour ces utilisateurs.
Contraintes : étapes numérotées, une action par étape, le libellé exact
en gras, ce que l'utilisateur doit voir après chaque étape, une ligne
« si ça échoue » à la fin avec quoi envoyer au support. N'utilise que
les libellés de mes notes ; s'il manque une étape, écris [MISSING]
au lieu de deviner.
Sortie : Markdown.

Pratique (30 min)

1. Prenez une tâche que vous connaissez sur votre machine (se connecter au Wi-Fi, ajouter une imprimante). Écrivez vos notes brutes avec les libellés exacts.
2. Lancez le prompt corrigé. Comptez les [MISSING] et les libellés inventés.
3. Donnez la procédure à quelqu'un (ou suivez-la vous-même sur un compte neuf) sans aider. Notez où ça bloque.
4. Fiche prompts/support-procedure.md.

Avec votre IA : « Voici une procédure utilisateur [coller]. Fais comme si tu ne l'avais jamais faite. À chaque étape, dis où tu cliquerais et où tu pourrais te perdre. Ne corrige pas la procédure. »

Synthèse (10 min)

Trois lignes : pourquoi les libellés viennent de vous, l'astuce [MISSING], le test sur une vraie personne. Puis refaites les exercices sans notes.

Jour 19 · 21/11 — Réseau : dépanner avec les vraies sorties

Objectif : donner au modèle la topologie et les sorties de commandes, et obtenir un diagnostic raisonné.

Théorie 1/2 : le prompt faible

Je n'arrive pas à pinguer le serveur. Pourquoi ?

Diagnostic : pas de topologie, pas d'adresses, pas de sorties. Un ping échoue pour une douzaine de raisons sur quatre couches. Le modèle a besoin des faits que vous donneriez à un collègue au téléphone : d'où, vers où, ce qu'il y a entre les deux, et ce qu'ont dit les commandes.

Théorie 2/2 : le prompt corrigé

Contexte : client 192.0.2.10/24, passerelle 192.0.2.1 ; serveur
198.51.100.20 dans un autre sous-réseau derrière le même routeur.
Les autres clients de 192.0.2.0/24 joignent le serveur.
Tâche : trouve la couche et la cause la plus probable, étape par
étape, à partir des sorties seulement.
<ip_addr>…</ip_addr> <ip_route>…</ip_route>
<ping>…</ping> <traceroute>…</traceroute>
Sortie : un tableau | étape | ce que montre la sortie | conclusion |,
puis la prochaine commande pour confirmer. Ne propose pas de
modification sur le routeur : je n'y ai pas accès.

Pratique (30 min)

1. Dans une VM, cassez le réseau d'une façon : mauvaise passerelle, mauvais masque, ou serveur DNS qui ne répond pas.
2. Collectez les quatre sorties, plus dig example.com. Remplacez toute vraie adresse par une adresse de documentation.
3. Lancez le prompt corrigé ; vérifiez vous-même chaque conclusion contre les sorties.
4. Fiche prompts/network-troubleshoot.md avec votre cas cassé et un cas qui marche.

Avec votre IA : « Donne-moi un symptôme réseau et les sorties de ip addr, ip route et ping pour une petite installation en panne, avec des adresses de documentation. Laisse-moi trouver la panne ; donne des indices un par un seulement si je les demande. »

Synthèse (10 min)

Trois lignes : les quatre sorties, la ligne qui réduit la recherche, pourquoi pas de modification du routeur. Puis refaites les exercices sans notes.

Jour 20 · 22/11 — Réseau : relire une config, et vérifier les calculs soi-même

Objectif : obtenir une relecture de configuration utile, et ne jamais croire sans vérifier les calculs de sous-réseau d'un modèle.

Théorie 1/2 : le prompt faible et le corrigé

Faible :  Ma config de pare-feu est OK ? (collage de 200 lignes)
Corrigé : Relis le jeu de règles nftables ci-dessous pour un serveur web
          qui doit accepter 80 et 443 depuis partout, 22 seulement depuis
          203.0.113.0/24, et rien d'autre en entrée.
          <ruleset>…</ruleset>
          Sortie : un tableau | règle (citée) | ce qu'elle autorise |
          conforme à la politique : oui ou non |, puis les règles qui
          manquent pour la politique. Ne réécris pas le jeu de règles.

« Est-ce OK ? » n'a pas de réponse sans politique. Avec la politique, chaque règle se compare à elle, et vous vérifiez le tableau règle par règle.

Théorie 2/2 : les modèles et l'arithmétique

Masques, nombres d'hôtes et plages sont des calculs exacts. Les modèles les réussissent souvent et se trompent parfois avec aplomb, parce qu'ils prédisent des chiffres au lieu de les calculer. Demandez le binaire, puis vérifiez de tête ou avec ipcalc. Mieux : laissez un outil calculer et le modèle expliquer.

Pratique (30 min)

1. Écrivez un petit jeu de règles nftables avec un trou volontaire (22 ouvert à tous).
2. Lancez la relecture corrigée. A-t-elle trouvé le trou ? A-t-elle signalé à tort une règle correcte ?
3. Demandez au modèle de découper 198.51.100.0/24 en quatre sous-réseaux avec leurs plages ; vérifiez chaque nombre à la main.
4. Fiche prompts/network-ruleset-review.md.

Avec votre IA : « Interroge-moi sur le découpage en sous-réseaux : dix préfixes dans les plages de documentation, un à la fois, demande le masque, le nombre d'hôtes et l'adresse de diffusion, et corrige-moi. Montre ton calcul binaire seulement après ma réponse. »

Synthèse (10 min)

Trois lignes : une relecture a besoin d'une politique, pourquoi les modèles glissent sur les calculs, qui calcule et qui explique. Puis refaites les exercices générés sans notes.

Jour 21 · 23/11 — DevOps : relire un Dockerfile et un pipeline

Objectif : obtenir une relecture qui nomme des problèmes concrets selon des règles posées.

Théorie 1/2 : le prompt faible

Améliore ce Dockerfile.

Diagnostic : améliorer pour quoi ? Taille, temps de construction, sécurité, reproductibilité tirent dans des sens différents. Le modèle réécrira tout, et vous ne saurez pas quel changement compte. Un prompt de relecture pose les critères et demande des constats, pas une réécriture.

Théorie 2/2 : le prompt corrigé

Relis ce Dockerfile d'une appli web Python qui part en production.
Critères, dans l'ordre : 1) tourne avec un utilisateur non root ;
2) image de base épinglée à une version ; 3) aucun secret dans une
couche ; 4) dépendances installées avant la copie du code, pour le
cache des couches ; 5) taille de l'image finale.
<dockerfile>…</dockerfile>
Sortie : une ligne par constat : numéro du critère, la ligne citée,
le problème, la plus petite correction. Si un critère est respecté,
écris « ok ». Pas de réécriture complète.

Pratique (30 min)

1. Écrivez un Dockerfile volontairement médiocre : base non épinglée, utilisateur root, COPY . . avant l'installation des dépendances, un secret en ENV.
2. Lancez la relecture corrigée ; puis passez hadolint sur le même fichier. Comparez les deux listes.
3. Même chose avec un fichier de CI de votre choix (critères posés : actions épinglées, aucun secret affiché, tests avant déploiement).
4. Fiche prompts/devops-dockerfile-review.md.

Avec votre IA : « Voici les constats de hadolint et la relecture d'un modèle sur le même Dockerfile [coller]. Pour chaque constat présent dans une liste et pas dans l'autre, explique si c'est un vrai problème, en citant la section de la documentation Docker que je dois lire. »

Synthèse (10 min)

Trois lignes : des critères dans l'ordre, des constats pas des réécritures, le linter comme second avis. Puis refaites les exercices sans notes.

Jour 22 · 24/11 — DevOps : postmortem et runbook

Objectif : transformer des notes d'incident brutes en postmortem sans reproche et en étape de runbook.

Théorie 1/2 : le prompt faible

Écris un postmortem de la panne d'hier.

Diagnostic : le modèle n'était pas là. Il inventera une chronologie, une cause racine et des actions qui sonnent juste. Un prompt de postmortem donne les faits (chronologie, journaux, extraits de discussion), le modèle de document, et interdit tout ce qui n'y est pas. Le livre SRE de Google décrit le postmortem sans reproche : on regarde les systèmes et les causes, pas les personnes.

Théorie 2/2 : le prompt corrigé

Contexte : postmortem sans reproche, lecteurs internes.
Entrées : <timeline>(notes horodatées)</timeline>
<evidence>(lignes de journaux, graphiques décrits)</evidence>
Tâche : remplis ce modèle avec les seules entrées :
Résumé / Impact / Chronologie / Cause racine / Ce qui a bien marché /
Ce qui a mal marché / Actions (responsable : [TBD], échéance : [TBD]).
Contraintes : aucun nom de personne, décrire les actions par rôle ;
chaque affirmation de la cause racine cite une entrée de la chronologie
ou une ligne de preuve ; ce qui n'est pas étayé s'écrit en question ouverte.

Pratique (30 min)

1. Prenez comme incident le labo cassé du jour 15. Écrivez une chronologie de six lignes horodatées et trois lignes de preuve.
2. Lancez le prompt corrigé. Soulignez chaque phrase et retrouvez sa ligne source ; ce qui n'en a pas est inventé.
3. Demandez une entrée de runbook : « symptôme, vérification, correction, retour arrière », à partir des mêmes entrées.
4. Fiche prompts/devops-postmortem.md.

Avec votre IA : « Voici mon brouillon de postmortem [coller]. Joue le relecteur d'une réunion de postmortem sans reproche : pose-moi cinq questions sur les causes et les preuves manquantes, jamais sur qui a fait quoi. »

Synthèse (10 min)

Trois lignes : pourquoi les faits seulement, pourquoi sans reproche, pourquoi [TBD]. Puis refaites les exercices sans notes.

Jour 23 · 25/11 — Sécurité : trier alertes et journaux

Objectif : obtenir un tri défendable de lignes de journal suspectes, avec la prochaine vérification.

Théorie 1/2 : le prompt faible

Est-ce que je me fais pirater ? (collage de auth.log)

Diagnostic : une question oui ou non appelle une réponse dramatique. Un tri utile compte et regroupe les événements, les rattache à une technique connue, note la confiance et propose la vérification suivante, en disant ce que les journaux ne peuvent pas montrer.

Théorie 2/2 : le prompt corrigé

Contexte : tri défensif de mon propre serveur (Debian 13, SSH sur 22,
connexion par mot de passe active). Je veux savoir ce qui s'est passé,
pas attaquer.
<authlog>(extrait)</authlog>
Tâche : 1) regroupe les événements par adresse source et par type,
avec les nombres ; 2) nomme la technique probable (identifiant MITRE
ATT&CK s'il y en a un) ; 3) dis si une connexion a réussi, en citant
la ligne ; 4) confiance : faible, moyenne, élevée, et pourquoi ;
5) les trois prochaines vérifications, en commandes.
Dis ce que ces journaux ne peuvent pas dire.

Pratique (30 min)

1. Dans votre VM, provoquez des échecs : ssh wronguser@localhost plusieurs fois, puis une connexion réussie.
2. Extrayez journalctl -u ssh --since today ; remplacez les adresses par des adresses de documentation.
3. Lancez le prompt corrigé. Recomptez les événements avec grep -c et comparez avec les nombres du modèle.
4. Fiche prompts/security-authlog-triage.md.

Avec votre IA : « Génère un faux extrait de auth.log de 30 lignes avec des adresses de documentation, qui contient exactement une réussite suspecte au milieu d'échecs. Ne me dis pas où elle est ; je la trouve, puis tu confirmes. »

Le faire faire par un agent : une fois le tri fait à la main, un agent avec un accès shell en lecture seule peut faire le comptage chaque matin : « Lis le journal SSH du jour, regroupe les échecs par source avec les nombres, cite toute ligne Accepted, et écris le tableau dans triage.md. Lecture seule : ne modifie aucun fichier hors de ce dossier et ne bloque aucune adresse. » Vous décidez vous-même de chaque blocage.

Synthèse (10 min)

Trois lignes : échec contre réussite, les cinq sorties, pourquoi recompter. Puis refaites les exercices sans notes.

Jour 24 · 26/11 — Sécurité : revue de durcissement, périmètre et autorisation

Objectif : cadrer une demande de sécurité pour qu'elle soit légitime, précise et vérifiable.

Théorie 1/2 : le périmètre d'abord

Un prompt de sécurité dit ce que vous avez le droit de toucher : vos propres systèmes, un labo, une mission avec autorisation écrite. C'est la règle du métier, et cela aide aussi le modèle à répondre à la bonne question. « Comment entrer sur ce serveur » est ambigu ; « relis le durcissement de mon propre serveur selon ce référentiel » est un travail.

Théorie 2/2 : le prompt de revue corrigé

Contexte : mon propre serveur Debian 13, exposé sur Internet, les
admins se connectent seulement par clé.
Tâche : relis sshd_config selon ces exigences : pas de connexion root ;
pas d'authentification par mot de passe ; seul le groupe "admins" peut
se connecter ; algorithmes par défaut du protocole.
<sshd_config>(sortie de sshd -T)</sshd_config>
Sortie : | exigence | directive et valeur trouvées | respectée : oui/non |
et les lignes exactes à changer. Rappelle-moi de garder une session
ouverte pendant que je teste le changement.

Pratique (30 min)

1. Sur la VM, lancez sudo sshd -T et gardez la sortie.
2. Lancez le prompt corrigé ; vérifiez chaque « respectée » contre la sortie avec grep.
3. Appliquez un changement dans une deuxième session, testez la connexion dans une troisième, gardez la première ouverte jusqu'à ce que ça marche.
4. Fiche prompts/security-ssh-review.md.

Avec votre IA : « Interroge-moi sur le durcissement SSH : dix questions, une à la fois, sur des directives de sshd_config, ce qu'elles font et leur valeur sûre, avec pour chaque réponse un lien vers la section de la page de manuel. »

Synthèse (10 min)

Trois lignes : le périmètre d'abord, la revue selon des exigences, garder une session ouverte. Puis refaites les exercices sans notes.

Jour 25 · 27/11 — Infrastructure as code : demander un playbook

Objectif : obtenir un playbook Ansible idempotent et vérifiable avant qu'il touche quoi que ce soit.

Théorie 1/2 : le prompt faible

Écris un playbook Ansible pour installer un serveur web.

Diagnostic : quel système, quel serveur, quelle configuration, quelle version d'Ansible ? Le modèle produira souvent des commandes shell habillées en tâches, qui s'exécutent à chaque fois et ne sont pas idempotentes. Un bon prompt IaC nomme les modules à préférer et la vérification que vous lancerez.

Théorie 2/2 : le prompt corrigé

Écris un playbook Ansible pour des hôtes Debian 13 du groupe "web".
Tâche : installer nginx, déployer templates/site.conf.j2 vers
/etc/nginx/sites-available/site.conf, l'activer, recharger nginx
seulement en cas de changement.
Contraintes : noms de modules complets (ansible.builtin.*) ; ni module
shell ni module command ; un handler pour le rechargement ; le
playbook ne doit annoncer aucun changement au second passage.
Sortie : le playbook, puis les commandes à lancer pour le vérifier :
contrôle de syntaxe, mode check avec diff, second passage.

Pratique (30 min)

1. Installez Ansible sur votre machine ; ciblez votre VM dans un fichier d'inventaire.
2. Obtenez le playbook avec le prompt corrigé. Lancez ansible-playbook --syntax-check, puis --check --diff, puis un vrai passage, puis un second : il doit annoncer changed=0.
3. Fiche prompts/iac-ansible-playbook.md, avec les quatre commandes comme vérifications.

Avec votre IA : « Explique l'idempotence dans Ansible avec deux tâches qui font la même chose, l'une idempotente et l'autre non, et demande-moi laquelle est laquelle et pourquoi avant de répondre. »

Le faire faire par un agent : maintenant que vous avez vérifié un playbook à la main, un agent peut écrire les suivants et lancer le contrôle de syntaxe et le mode check sur un inventaire de labo : « Écris le playbook de prompts/iac-ansible-playbook.md pour mon inventaire de labo, lance --syntax-check et --check --diff, et montre-moi le diff ; ne lance rien sans --check. » Vous lisez toujours le diff et lancez le vrai passage.

Synthèse (10 min)

Trois lignes : les modules plutôt que le shell, le handler, le second passage. Puis refaites les exercices sans notes.

Jour 26 · 28/11 — Ce qui n'entre jamais dans un prompt

Objectif : nettoyer journaux et configurations avant de les envoyer à un modèle, à la main et par du code.

Théorie 1/2 : la règle

Un modèle hébergé est un tiers : ce que vous collez sort de votre organisation, peut être gardé dans des journaux, et relève des conditions du fournisseur. Ne collez jamais mots de passe, clés, jetons, données personnelles de clients, ni les noms et adresses internes de votre employeur sans autorisation. Un modèle local garde les données sur votre machine : c'est pour cela que ce parcours en utilise un. Remplacez les secrets par des emplacements, les adresses par les plages de documentation, les noms par des rôles.

Théorie 2/2 : masquer par du code

À la main, vous en raterez un. Une petite fonction attrape les motifs connus ; vous relisez quand même le résultat.

function redact(line) {
}

function redact(line) {
  return line
    .replace(/\b(?:\d{1,3}\.){3}\d{1,3}\b/g, '[IP]')
    .replace(/password=\S+/g, 'password=[REDACTED]');
}

Pratique (30 min)

1. Reprenez les journaux et configurations du module. Listez chaque sorte de valeur sensible qu'ils contiennent (adresses, noms de machines, utilisateurs, clés).
2. Écrivez le même masquage en commande sed ou en court script, ajoutez-y noms de machines et d'utilisateurs, et passez-le sur vos fichiers.
3. Lisez la sortie ligne par ligne : qu'a-t-il raté ?
4. Ajoutez une section « Redaction » au README de la bibliothèque avec le script et ses limites.

Avec votre IA : (modèle local seulement) « Voici un journal masqué [coller]. Liste tout ce qui pourrait encore identifier une personne, une entreprise ou un système, et explique pourquoi. Ne reproduis pas les valeurs elles-mêmes. »

Synthèse (10 min)

Trois lignes : ce qui n'entre jamais, local contre hébergé, pourquoi du code plus une relecture. Puis refaites les exercices sans notes.

Jour 27 · 29/11 — Router des alertes avec un petit modèle

Objectif : construire un prompt de classification qu'un petit modèle local réussit, et le mesurer.

Théorie 1/2 : petit modèle, tâche étroite

Un petit modèle est rapide et économe mais demande une tâche étroite : une liste fixe d'étiquettes, une définition de chacune, une étiquette « other » pour ce qui ne rentre nulle part, quelques exemples, une température basse, une sortie structurée. Ensuite on le mesure sur des cas étiquetés, comme au jour 8, et on envoie les « other » et les cas peu sûrs à un humain.

Théorie 2/2 : le prompt corrigé

Classe l'alerte dans exactement une équipe.
Équipes : network (liens, routage, DNS, pare-feu), systems (disque,
mémoire, services, OS), database (requêtes, réplication, verrous),
security (connexions, logiciels malveillants, politique), other
(aucune de ces équipes clairement).
<alert>{alert}</alert>
Réponds en JSON : {"team": "...", "reason": "15 mots max"}
Exemples :
"disk /var 95% full on web1" -> systems
"replication lag 300s on db2" -> database

Pratique (30 min)

1. Écrivez 20 courtes alertes fictives avec l'équipe attendue, dont quatre ambiguës.
2. Lancez le prompt à température 0 avec un schéma JSON ; comptez les bonnes réponses par équipe.
3. Changez une chose (définitions, un exemple) et relancez. Gardez la meilleure version.
4. Fiche prompts/ops-alert-routing.md avec les 20 cas et le score par version.

Avec votre IA : « Voici mes 20 alertes étiquetées et les réponses du modèle [coller]. Construis la table de confusion équipe par équipe, puis dis-moi quelle définition de mon prompt cause probablement le plus d'erreurs. »

Synthèse (10 min)

Trois lignes : ce qu'il faut à un petit modèle, pourquoi « other », comment vous avez mesuré. Puis refaites les exercices sans notes.

Jour 28 · 30/11 — Bilan du module 2 : le pack de prompts d'exploitation

Objectif : livrer un ensemble testé de prompts d'exploitation et refaire les exercices les plus durs du module.

Théorie 1/2 : ce que les prompts d'exploitation ont en commun

Tous les prompts du module avaient la même colonne vertébrale : le système et la version exacts, les vraies sorties balisées comme données, une politique ou des critères de comparaison, une sortie vérifiable ligne par ligne, une porte de sortie (« pas dans ces journaux », [MISSING], other), et une vérification hors du modèle (grep, shellcheck, hadolint, mode check).

Théorie 2/2 : corriger ce prompt

Tu es un expert Linux senior. Répare mon serveur, il est lent. Sois exhaustif !

Pratique (30 min)

1. Vérifiez que chaque fiche du module a entrées, sortie, critères et au moins deux cas de test.
2. Relancez-les toutes sur votre modèle actuel ; mettez à jour ## History.
3. Écrivez jobs/operations.md : un paragraphe par métier du module, avec le prompt que vous réutiliseriez en premier.
4. Livrable du module 2 : le pack de prompts d'exploitation poussé sur votre forge, avec ses cas de test et ses scores.

Avec votre IA : « Voici la liste de mes prompts d'exploitation avec leurs scores [coller]. Pose-moi cinq questions, une à la fois, sur les choix que j'y ai faits (pourquoi cette vérification, pourquoi cette sortie), comme le ferait un recruteur pour un poste d'administrateur système débutant. »

Synthèse (10 min)

Écrivez de mémoire les six éléments de la colonne vertébrale. Puis refaites les exercices du module que vous aviez ratés.