DevOps avec l'IA : de Linux et Git au pipeline CI/CD déployé

Objectifs pratiques

Dans cette leçon de 20 minutes, tu vas dessiner le chemin d'un changement de code, du commit jusqu'à la production, puis rédiger un pitch de 60 secondes. Ce pitch est la base de la réponse à la première question d'entretien : « C'est quoi le DevOps ? ». Tu t'appuies sur l'application fil rouge : une API de suivi des ventes d'une boutique Mobile Money, avec des données fictives.

Pourquoi c'est utile pour ton objectif

Ton objectif est de décrocher un poste lié au DevOps. Les recruteurs testent d'abord ta capacité à expliquer simplement. Si tu sais raconter le cycle de livraison, le reste du parcours (Linux, Git, Docker, CI/CD, supervision) trouve sa place dans ce schéma. Tu peux ensuite montrer chaque projet de ton portfolio comme une étape de ce cycle.

Les trois idées à maîtriser

1. Le DevOps rapproche développement et exploitation

Le développement veut livrer vite. L'exploitation veut un service stable. Le DevOps rapproche les deux par l'automatisation : les tests, la construction et le déploiement sont faits par des scripts répétables, pas à la main.

2. Livraison continue ou déploiement continu

• Livraison continue : chaque changement validé est prêt à être mis en production, mais un humain déclenche la mise en production.
• Déploiement continu : si tous les tests passent, la mise en production se fait automatiquement, sans validation manuelle.

3. L'IA amplifie, elle ne remplace pas

Le rapport DORA 2025 conclut que l'IA amplifie les forces comme les faiblesses d'une équipe. Elle peut accélérer l'écriture de scripts et l'explication d'erreurs. Elle peut aussi inventer des commandes ou des noms de paquets (risque de « slopsquatting »). Tout ce qu'elle produit doit être relu et testé.

Méthode pas à pas

1. Prends une feuille ou un outil de schéma gratuit. Écris en haut : « API ventes Mobile Money ».
2. Place 6 cases dans l'ordre : 1) Commit et push sur GitHub, 2) Tests automatiques, 3) Construction (image Docker), 4) Livraison dans un environnement de préproduction, 5) Validation (automatique ou manuelle), 6) Production avec supervision.
3. Sous chaque case, note l'outil visé : Git, GitHub Actions, Docker, un serveur, des journaux et des alertes.
4. Marque le point de décision : entre les étapes 5 et 6, écris « manuel = livraison continue » et « automatique = déploiement continu ».
5. Ajoute une flèche de retour de la supervision vers le commit : une panne détectée donne un correctif.
6. Rédige le pitch en 4 phrases : définition, schéma, distinction livraison/déploiement, IA (un bénéfice et un risque).
7. Chronomètre-toi à voix haute. Vise 60 secondes, soit environ 150 mots.

Exemple concret

Voici un pitch type, à adapter avec tes mots :

« Le DevOps rapproche les développeurs et l'exploitation grâce à l'automatisation. Prenons une API de ventes pour une boutique Mobile Money. Quand je pousse un commit, un pipeline lance les tests, construit une image Docker, la livre en préproduction, puis la met en production sous supervision. En livraison continue, une personne valide avant la mise en production. En déploiement continu, tout passe seul si les tests sont verts : c'est adapté à une petite correction, moins à un changement de calcul des montants. L'IA m'aide à rédiger et expliquer des scripts plus vite, mais elle peut inventer une commande ou un paquet. Je relis et je teste toujours avant de livrer. »

Erreurs à éviter

• Réciter une définition sans exemple : donne toujours le cas de l'API.
• Confondre livraison et déploiement continus.
• Citer seulement les bénéfices de l'IA, sans aucun risque.
• Faire un schéma de plus de 6 étapes : la clarté prime.
• Copier un pitch d'IA sans le reformuler. Ton oral doit être naturel.

À faire maintenant

Produis deux livrables : le schéma en 6 étapes nommées, puis le pitch de 60 secondes. Enregistre-toi une fois, réécoute, corrige. Enfin, crée un fichier pitch-devops.md dans ton dépôt Git avec le schéma (photo ou texte) et le pitch, puis fais un commit.

Pourquoi cet exercice

Tu vises un poste junior en DevOps avec seulement 20 minutes par jour. Deux choses font tenir une reconversion dans la durée : une routine qui laisse une trace vérifiable, et une cible claire. Le journal d'ingénieur te donne la trace : commande tapée, erreur rencontrée, correction. Le tableau de veille d'offres te donne la cible : il montre quels outils le marché demande vraiment (Linux, Git, Docker, CI/CD, cloud). La traduction de tes compétences de l'ancien métier te montre que tu ne pars pas de zéro. Ces trois éléments alimenteront ton futur portfolio GitHub et ton CV orienté DevOps.

Durée estimée : 60 à 75 minutes, à répartir sur 3 à 4 séances de 20 minutes. Chaque séance se termine par un commit Git.

Objectif pratique

Tu produis un dépôt GitHub public nommé par exemple devops-reconversion contenant :

• un fichier JOURNAL.md avec au moins 1 entrée datée ;
• un fichier VEILLE.md avec un tableau de 10 offres juniors ;
• un fichier COMPETENCES.md avec 3 compétences de ton ancien métier traduites en langage DevOps.

Étape 1 : créer le dépôt (séance 1, 20 min)

1. Crée un compte GitHub si besoin, puis un dépôt public avec un README.
2. Ajoute dans le README 2 phrases : ton objectif (décrocher un poste junior de type support N2, administration systèmes ou cloud ops) et ta routine (20 min par jour).
3. Crée JOURNAL.md directement depuis l'interface web, puis valide par un commit.

Étape 2 : écrire ta première entrée de journal

Utilise ce modèle pour chaque séance :

```

2026-10-10 : Séance 1

• Objectif de la séance :
• Commande ou action réalisée :
• Erreur rencontrée :
• Correction ou piste trouvée :
• Ce que j'ai retenu en une phrase :

```

Si tu n'as rencontré aucune erreur, note une difficulté de compréhension. Une entrée vide de problème est suspecte : l'apprentissage en produit presque toujours.

Étape 3 : construire le tableau de veille (séances 2 et 3)

Cherche 10 offres sur LinkedIn, des sites d'emploi de ton pays et les pages carrières d'entreprises. Utilise les mots-clés « support N2 », « administrateur systèmes », « cloud ops », « DevOps junior » et « intégrateur ». Crée VEILLE.md avec ce tableau :

`` | # | Poste | Entreprise / lieu | Outils demandés | Prérequis (expérience, diplôme) | Lien | Date | |---|-------|-------------------|-----------------|----------------------------------|------|------| ``

Ensuite, ajoute sous le tableau 3 lignes de synthèse : les 3 outils les plus fréquents, l'expérience demandée la plus courante et une compétence que tu n'as pas encore.

Étape 4 : traduire 3 compétences (séance 4)

Choisis 3 compétences de ton ancien métier. Reformule chacune en langage DevOps, avec un exemple concret.

• Gérer un client mécontent devient la gestion d'incident et la communication en cas de panne.
• Respecter une procédure qualité devient l'automatisation de contrôles et la documentation reproductible.
• Suivre des stocks ou des ventes devient la supervision d'indicateurs et d'alertes.

Écris ces traductions dans COMPETENCES.md, avec une phrase d'exemple vécu pour chacune.

Utiliser l'IA avec vérification

Tu peux demander à un assistant IA de reformuler tes compétences ou de t'expliquer un terme d'une offre. Vérifie ensuite chaque terme technique dans une source officielle ou dans l'offre elle-même. N'invente aucune offre : chaque ligne du tableau doit avoir un lien réel.

Erreurs à éviter

• Écrire des entrées de journal vagues (« j'ai appris Git »). Note la commande exacte.
• Remplir le tableau avec des offres seniors sans le signaler.
• Copier-coller une réponse de l'IA sans la relire ni la vérifier.
• Y mettre des données personnelles sensibles : ne publie ni téléphone ni adresse.

Livrables et critères de réussite

• Le dépôt contient JOURNAL.md avec au moins 1 entrée datée.
• Le tableau liste 10 offres avec les outils demandés.
• 3 compétences transférables sont reformulées en termes DevOps.
• Au moins 3 commits ont été faits sur des jours différents.

Objectifs pratiques

À la fin de cette leçon de 20 minutes, tu sauras naviguer dans un terminal Linux, lire des fichiers, chercher une information et expliquer 10 commandes avec tes propres mots grâce à --help et man. C'est le socle de tout le parcours : Git, Docker et CI/CD s'utilisent dans un terminal, et la plupart des serveurs tournent sous Linux.

Pourquoi c'est utile pour votre objectif

Un DevOps travaille presque toujours sur des machines distantes, sans interface graphique. Si tu sais lire l'aide d'une commande, tu peux te débrouiller seul sur n'importe quel serveur ou projet, sans tout mémoriser. Cette autonomie se voit en entretien et dans ton portfolio. Elle te servira aussi à vérifier ce qu'un assistant IA te propose avant de l'exécuter.

Méthode pas à pas

1. Ouvre GitHub Codespaces sur ton dépôt du fil rouge (application de suivi des ventes d'une boutique Mobile Money, données fictives). Le terminal est en bas de l'écran.
2. Crée les données fictives :

mkdir -p ventes && cd ventes printf "date,produit,montant\n2025-01-03,credit,1500\n2025-01-04,forfait,3000\n2025-01-05,credit,500\n" > janvier.csv cp janvier.csv fevrier.csv

1. Exécute les 10 commandes de survie : pwd (où suis-je ?), ls (lister), cd (changer de dossier), mkdir (créer un dossier), cp (copier), mv (déplacer ou renommer), cat (afficher un fichier), head (premières lignes), grep (chercher un texte), find (chercher un fichier).
2. Pour chaque commande, lis l'aide : tape ls --help (résumé court) ou man grep (manuel complet, q pour quitter, /mot pour chercher dans la page).
3. Utilise une option trouvée dans l'aide. Exemple : ls -l (détails), grep -c credit janvier.csv (compte les lignes contenant « credit »), head -n 2 janvier.csv.
4. Note dans ton journal d'ingénieur : commande tapée, résultat, une phrase d'explication formulée avec tes mots, et les erreurs rencontrées.
5. Termine par un commit : git add journal.md && git commit -m "Journal terminal jour 1".

Exemple concret

Tu veux savoir combien de ventes « credit » figurent dans janvier. Tu tapes grep --help et tu repères l'option -c, qui compte les lignes correspondantes. Tu lances grep -c credit janvier.csv et obtiens 2. Pour retrouver tous les fichiers CSV du projet, tu lances find . -name "*.csv". Dans ton journal, tu écris : « grep -c compte combien de lignes contiennent un mot ; find . -name cherche des fichiers par nom à partir du dossier courant. »

Erreurs à éviter

• Copier-coller une commande de l'IA sans la comprendre. Lance d'abord --help ou man dessus, surtout si elle contient rm.
• Lancer rm -rf sans vérifier le dossier avec pwd et ls. La suppression est définitive.
• Oublier que Linux distingue majuscules et minuscules : Ventes n'est pas ventes.
• Recopier l'aide mot pour mot dans ton journal. Reformule avec tes propres mots, sinon tu ne retiens rien.
• Rester bloqué dans man : appuie sur q pour sortir.

À faire maintenant

Livrable : un fichier journal.md dans ton dépôt, contenant un tableau avec 10 lignes : commande, ce qu'elle fait (tes mots), source consultée (--help ou man). Ajoute une ligne indiquant l'option utilisée dans un exemple, puis fais un commit.

Pourquoi cet exercice t'aide

Un DevOps passe une grande partie de son temps à lire des journaux (logs) pour comprendre pourquoi un service tombe en panne. Dans cet exercice, tu construis un mini-analyseur de logs avec des pipes et des redirections. Tu travailles sur l'application fil rouge, une API fictive de suivi des ventes d'une boutique Mobile Money. Tu produis une preuve vérifiable, un fichier rapport.txt. Il ira dans ton futur portfolio GitHub et nourrira ton journal d'ingénieur. Durée estimée : 20 minutes.

Objectif pratique

À partir d'un fichier access.log fictif, produire un rapport.txt qui contient :

• le nombre de requêtes en erreur 500 ;
• les 5 URL les plus appelées, avec leur nombre d'appels.

Tu n'utilises que des commandes enchaînées, sans éditeur de texte pour calculer les résultats.

Étape 1 : préparer le fichier de log (4 min)

Crée un dossier de travail et un fichier de log d'au moins 12 lignes. Chaque ligne suit ce format : date, méthode, URL, code HTTP.

`` mkdir -p ~/devops-logs && cd ~/devops-logs cat > access.log << 'EOF' 2026-01-10T08:00:01 GET /ventes 200 2026-01-10T08:00:05 POST /ventes 201 2026-01-10T08:01:10 GET /ventes 500 2026-01-10T08:02:20 GET /clients 200 2026-01-10T08:03:00 GET /ventes 200 2026-01-10T08:03:30 GET /produits 404 2026-01-10T08:04:00 POST /paiements 500 2026-01-10T08:05:00 GET /clients 200 2026-01-10T08:06:00 GET /ventes 200 2026-01-10T08:07:00 GET /stock 200 2026-01-10T08:08:00 GET /paiements 500 2026-01-10T08:09:00 GET /clients 200 EOF ``

Note d'abord le nombre d'erreurs 500 que tu comptes à la main (ici 3). Il te servira de vérification.

Étape 2 : compter les erreurs 500 (5 min)

Le pipe | envoie la sortie d'une commande vers l'entrée de la suivante. Essaie ceci :

`` grep " 500$" access.log | wc -l ``

grep filtre les lignes qui se terminent par 500. wc -l compte ensuite les lignes. Compare le résultat à ton comptage manuel.

Étape 3 : trouver les 5 URL les plus appelées (5 min)

`` awk '{print $3}' access.log | sort | uniq -c | sort -rn | head -5 ``

Voici le rôle de chaque commande. awk extrait la 3e colonne, l'URL. sort regroupe les URL identiques. uniq -c les compte. sort -rn trie du plus grand au plus petit. head -5 garde les 5 premières.

Étape 4 : écrire le rapport avec les redirections (3 min)

`` echo "Erreurs 500 :" > rapport.txt grep " 500$" access.log | wc -l >> rapport.txt echo "Top 5 des URL :" >> rapport.txt awk '{print $3}' access.log | sort | uniq -c | sort -rn | head -5 >> rapport.txt cat rapport.txt ``

> crée ou écrase le fichier. >> ajoute à la fin. Pour capturer aussi les messages d'erreur d'une commande, utilise commande > sortie.txt 2>&1.

Erreurs à éviter

• Utiliser > partout : tu écrases le rapport à chaque commande.
• Oublier sort avant uniq -c : uniq ne compte que les lignes identiques qui se suivent.
• Chercher 500 sans précision : grep 500 peut aussi trouver une heure ou un montant qui contient 500.
• Faire confiance à l'IA sans tester : si tu lui demandes une commande, exécute-la et compare le résultat à ton comptage manuel.

Livrables et critères de réussite

• rapport.txt contient le bon nombre d'erreurs 500.
• Les 5 URL les plus appelées sont listées avec leur nombre d'appels.
• Au moins un pipe et une redirection sont utilisés.
• Les commandes sont copiées dans un fichier commandes.md, avec une note sur une erreur rencontrée et sa correction.
• Fais un commit Git de access.log, rapport.txt et commandes.md.

Pour aller plus loin (optionnel)

Demande à un assistant IA d'expliquer ta commande awk. Vérifie sa réponse avec man awk ou en exécutant la commande, puis note ce qui était juste ou faux.

Objectifs pratiques

Dans cette leçon de 20 minutes, tu vas lire les droits d'un fichier avec ls -l, corriger un « Permission denied » avec chmod, et savoir quand sudo est vraiment nécessaire. C'est une compétence de base du DevOps : un pipeline ou un script de déploiement qui échoue pour une question de droits est l'une des pannes les plus fréquentes. À la fin, tu auras un script deploy.sh qui s'exécute et une note de diagnostic dans ton journal d'ingénieur. Le script fait partie de l'application fil rouge (suivi des ventes d'une boutique, avec des données fictives).

Pourquoi c'est utile pour ton objectif

Un DevOps passe beaucoup de temps à diagnostiquer. Les droits Linux reviennent à chaque étape : exécuter un script, écrire dans un dossier de logs, lancer Docker, faire tourner un pipeline. Savoir lire une erreur de droits, la corriger au strict nécessaire et le documenter, c'est la boucle « casser → diagnostiquer → réparer → documenter » que tu montreras en entretien. Un assistant IA peut te proposer chmod 777 pour « faire marcher » : tu dois savoir pourquoi c'est une mauvaise réponse.

Méthode pas à pas

1. Reproduire l'erreur. Dans ton dépôt fil rouge, crée un script volontairement non exécutable :

printf '#!/bin/bash\necho "Déploiement OK"\n' > deploy.sh puis lance ./deploy.sh. Tu obtiens Permission denied.

1. Lire les droits. Tape ls -l deploy.sh. Tu vois par exemple -rw-r--r-- 1 user user ... deploy.sh. Décode : le premier caractère est le type (- fichier, d dossier), puis 3 blocs de 3 lettres : propriétaire, groupe, autres. r = lire, w = écrire, x = exécuter. Ici, personne n'a x.
2. Identifier la cause. Le fichier est lisible mais pas exécutable. Vérifie aussi le propriétaire (colonnes 3 et 4) avec ls -l et ton identité avec whoami.
3. Corriger au minimum. Ajoute seulement l'exécution pour le propriétaire : chmod u+x deploy.sh. Évite chmod 777, qui donne tous les droits à tout le monde.
4. Vérifier. Relance ls -l deploy.sh (tu dois voir -rwxr--r--), puis ./deploy.sh. Le message doit s'afficher.
5. Cas du propriétaire. Si le fichier appartient à un autre utilisateur (par exemple root), utilise sudo chown $USER:$USER deploy.sh pour reprendre la propriété, puis le chmod ci-dessus. Utilise sudo pour cette seule commande, jamais pour lancer tout ton script « par défaut ».
6. Documenter. Écris 5 lignes dans ton journal : symptôme, commande de diagnostic, cause, commande de correction, vérification. Puis fais un commit.

Exemple concret

Le script deploy.sh de l'application de suivi des ventes doit copier un fichier de configuration puis afficher un message. Il échoue avec bash: ./deploy.sh: Permission denied. ls -l montre -rw-r--r--. La cause est l'absence du bit x. Après chmod u+x deploy.sh, le résultat est -rwxr--r-- et le script tourne. Journal :

• Symptôme : Permission denied sur ./deploy.sh
• Diagnostic : ls -l deploy.sh → pas de x
• Cause : droit d'exécution absent
• Correction : chmod u+x deploy.sh
• Vérification : ./deploy.sh affiche le message attendu

Erreurs à éviter

• chmod 777 : cela fonctionne, mais c'est une faille de sécurité et un mauvais signe en entretien.
• Mettre sudo devant tout : le principe du moindre privilège demande de n'élever les droits que pour la commande qui l'exige.
• Ne pas lire l'erreur : Permission denied peut venir du fichier, mais aussi du dossier parent (il manque le x sur le dossier) ou d'un autre propriétaire.
• Copier une commande de l'IA sans la comprendre : demande-lui d'expliquer chaque option, puis vérifie avec man chmod ou chmod --help.
• Oublier la vérification : un correctif n'est valide que si tu as relancé le script.

À faire maintenant

Crée deploy.sh sans droit d'exécution, reproduis l'erreur, corrige-la avec le droit minimal, puis rédige ton entrée de journal en 5 lignes (cause, commande, vérification). Fais un commit avec le message « fix: droits d'exécution de deploy.sh ».

Pourquoi cet exercice t'aide

Un ingénieur DevOps automatise ce qu'il fait à la main. Écrire server-stats.sh est ton premier livrable de portfolio. Il prouve trois compétences : utiliser le terminal, gérer des arguments, et signaler une erreur avec un code de sortie. Ces codes sont ce que les pipelines CI/CD lisent pour savoir si une étape a réussi. Tu les réutiliseras dans les modules suivants. Durée estimée : 20 à 40 minutes. Tu peux le faire en deux séances de 20 minutes.

Contexte

Tu gères la machine qui héberge l'application fil rouge, une API fictive de suivi des ventes d'une boutique Mobile Money. Ton équipe veut un script qui donne l'état de la machine en une seconde. Travaille dans GitHub Codespaces ou dans un terminal Linux, sans carte bancaire.

Étapes

1. Préparer le dépôt

Crée un dossier server-stats, lance git init, puis crée le fichier server-stats.sh. La première ligne doit être #!/usr/bin/env bash. Rends le fichier exécutable avec chmod +x server-stats.sh.

2. Afficher CPU, mémoire et disque

Utilise des commandes standard : top -bn1 ou uptime pour la charge CPU, free -h pour la mémoire, df -h / pour le disque. Stocke les résultats dans des variables et affiche-les avec des titres clairs. Vérifie chaque commande dans ton terminal avant de l'ajouter au script.

3. Gérer les arguments

Sans argument, le script affiche les trois sections. Avec --disk, il affiche seulement le disque. Utilise $1 et une structure case. Pour tout autre argument, affiche un message d'erreur sur la sortie d'erreur (>&2), puis un message d'usage. Termine avec exit 1. En cas de succès, termine avec exit 0.

4. Tester les codes de sortie

Lance ./server-stats.sh, puis echo $? : tu dois lire 0. Lance ./server-stats.sh --foo, puis echo $? : tu dois lire une valeur non nulle.

5. Utiliser l'IA avec vérification

Demande à un assistant IA de relire ton script et de proposer une amélioration. Avant de l'accepter, exécute la proposition et lis chaque commande. Si l'IA suggère un paquet à installer, vérifie qu'il existe vraiment. Note dans ton journal d'ingénieur ce que tu as accepté ou refusé, et pourquoi.

6. Documenter et committer

Écris un README.md de 3 lignes : ce que fait le script, comment l'exécuter, et quels codes de sortie il renvoie. Puis lance git add ., git commit -m "Ajoute server-stats.sh", et pousse le dépôt sur GitHub.

Erreurs à éviter

• Oublier chmod +x (erreur « Permission denied »).
• Oublier de mettre les variables entre guillemets.
• Afficher une erreur sans exit non nul : le pipeline croirait que tout va bien.
• Copier du code IA sans le tester.

Livrables

• server-stats.sh fonctionnel
• README.md de 3 lignes
• Un commit poussé sur GitHub
• Une note de journal sur l'usage de l'IA

Critères de réussite

• Le script affiche CPU, mémoire et disque.
• Un argument invalide renvoie un code de sortie non nul.
• Le README explique l'exécution en 3 lignes.
• Le dépôt est visible sur GitHub avec au moins un commit propre.

Objectifs pratiques

Dans cette leçon de 20 minutes, tu vas demander à un assistant IA un script Bash d'archivage de logs, puis le valider avec une grille de fiabilité. Tu pourras ainsi utiliser l'IA pour aller plus vite sur le projet fil rouge (l'API de suivi des ventes d'une boutique Mobile Money) sans exécuter à l'aveugle du code que tu ne comprends pas. Cette compétence te rapproche de ton objectif : travailler en autonomie sur un terminal et garder des preuves de ton travail dans ton journal IA.

Pourquoi c'est utile pour votre objectif

Un DevOps écrit beaucoup de scripts : sauvegardes, nettoyage, déploiement. L'IA te fait gagner du temps, mais elle peut se tromper. Elle peut proposer une option qui n'existe pas, une commande destructrice ou un paquet inventé. Le risque du « slopsquatting » est documenté : un attaquant enregistre un nom de paquet halluciné par l'IA, et celui qui l'installe sans contrôle récupère du code malveillant. En entretien, savoir expliquer comment tu vérifies une réponse de l'IA montre une vraie maturité professionnelle. Le rapport DORA 2025 va dans le même sens : l'IA amplifie les forces comme les faiblesses d'une équipe.

Méthode pas à pas

1. Écris un prompt précis avec le contexte, les contraintes et le format attendu. Exemple : « Écris un script Bash pour Linux qui archive en .tar.gz les fichiers .log de /var/log/boutique plus vieux de 7 jours dans /var/backups, avec un horodatage dans le nom. Utilise uniquement des outils présents par défaut (tar, find, date). Gère les erreurs, n'efface rien sans message, et explique chaque ligne. »
2. Lis le script avant de l'exécuter et relève au moins 3 points à vérifier. Cherche les commandes destructrices (rm, -delete), les chemins en dur, la gestion d'erreur (set -euo pipefail), les variables non protégées par des guillemets, et toute commande curl | bash ou pip/npm install.
3. Contrôle chaque option dans la documentation officielle. Utilise man tar, man find ou commande --help. Vérifie que chaque option existe réellement et fait ce que l'IA affirme.
4. Contrôle chaque dépendance sur son registre officiel. Si le script cite un paquet (PyPI, npm, apt), vérifie qu'il existe, qui le maintient, sa date de création et son nombre de téléchargements. Un paquet récent, sans historique et au nom étrange est suspect. Si le script n'utilise que des outils système, note « aucune dépendance externe ».
5. Teste dans un dossier de test, jamais sur de vraies données. Crée des faux logs : mkdir -p ~/labo/logs && touch -d '10 days ago' ~/labo/logs/ancien.log && touch ~/labo/logs/recent.log. Lance le script sur ce dossier, puis vérifie l'archive avec tar -tzf.
6. Remplis la grille de fiabilité dans ton journal IA : vérification, source consultée, résultat, décision (accepté, corrigé ou rejeté).
7. Fais un commit Git du script et de la grille.

Exemple concret

L'IA propose un script qui contient find $DIR -name "*.log" -mtime +7 -delete avant la création de l'archive. Tu repères deux problèmes : $DIR n'est pas entre guillemets, et la suppression a lieu avant de savoir si l'archive est valide. Tu consultes man find pour confirmer le sens de -mtime +7. Tu fais corriger le script : archive d'abord, test avec tar -tzf, suppression ensuite seulement si le test réussit. Sur ton dossier de test, l'archive contient ancien.log et pas recent.log. Tu notes le résultat dans la grille.

| Vérification | Source | Résultat | Décision | |---|---|---|---| | Option -mtime +7 | man find | conforme | accepté | | Variable $DIR sans guillemets | relecture | risque avec les espaces | corrigé | | Dépendances externes | script | aucune (tar, find, date) | accepté | | Test sur faux logs | exécution | 1 fichier archivé sur 2 | accepté |

Erreurs à éviter

• Copier-coller et exécuter directement sur un vrai serveur ou un vrai dossier.
• Faire confiance à l'IA quand elle dit « ça marche » : seul ton test compte.
• Installer un paquet sans le chercher sur le registre officiel (PyPI, npm).
• Fournir un prompt vague, sans système, chemin ni contrainte.
• Oublier de noter le résultat du test : sans trace, il n'y a pas de preuve pour ton portfolio.

À faire maintenant

Crée dans ton dépôt un fichier journal-ia.md. Demande le script d'archivage de logs à ton assistant IA avec un prompt précis. Remplis une grille d'au moins 3 vérifications, teste le script sur de faux logs, note le résultat, puis fais un commit.

Objectifs pratiques

Dans cette leçon de 20 minutes, tu vas créer deux branches, provoquer volontairement un conflit sur le README, le résoudre, puis fusionner via une Pull Request (PR) bien décrite. C'est une preuve concrète de collaboration. Elle te rapproche de ton objectif : un portfolio GitHub de 3 projets DevOps démontrables en entretien.

Pourquoi c'est utile pour votre objectif

Un DevOps travaille toujours en équipe : chaque changement passe par une branche, une PR et une revue. Les recruteurs regardent ton historique Git pour juger ta rigueur. Un conflit résolu proprement, avec une PR claire, montre que tu sais travailler à plusieurs. Plus tard, ton pipeline CI/CD se déclenchera sur ces PR.

Notions à maîtriser

• Commit : un instantané du projet avec un message clair.
• Branche : une ligne de travail parallèle, sans toucher à main.
• Fusion (merge) : on réunit deux lignes de travail.
• Conflit : Git ne sait pas choisir entre deux modifications de la même ligne. C'est normal, et tu décides.
• Pull Request : une demande de fusion sur GitHub, avec description et revue.

Méthode pas à pas

1. Dans ton dépôt du fil rouge (API de suivi des ventes d'une boutique Mobile Money, données fictives), vérifie que tout est propre : git switch main puis git status.
2. Choisis une ligne du README, par exemple Statut : en développement.
3. Crée la première branche : git switch -c feature/statut-beta. Modifie la ligne en Statut : bêta, puis git add README.md et git commit -m "docs: statut passe en bêta".
4. Reviens sur main : git switch main. Crée la seconde branche : git switch -c feature/statut-prod. Modifie la même ligne en Statut : production, puis commit : git commit -am "docs: statut passe en production".
5. Pousse les deux branches : git push -u origin feature/statut-prod, puis la même commande avec feature/statut-beta.
6. Sur GitHub, ouvre une PR pour feature/statut-beta vers main avec une description (voir l'exemple) et fusionne-la.
7. Ouvre la PR de feature/statut-prod. GitHub signale un conflit. Dans le terminal : git switch feature/statut-prod, puis git merge main.
8. Ouvre le README. Tu vois les marqueurs <<<<<<<, ======= et >>>>>>>. Garde le texte final voulu (par ex. Statut : bêta publique) et supprime tous les marqueurs.
9. Termine : git add README.md, git commit (le message de fusion par défaut convient), git push.
10. Fusionne la PR. Contrôle l'historique avec git log --oneline --graph --all : le conflit résolu doit y être visible.

Exemple concret

Description de PR claire :

• Titre : docs: aligner le statut du projet dans le README
• Pourquoi : deux branches modifiaient la même ligne, d'où un conflit.
• Ce qui change : une seule formulation du statut, « bêta publique ».
• Vérification : relecture du README, aucun marqueur de conflit restant.

Avec un assistant IA, tu peux lui demander d'expliquer les marqueurs de conflit ou de reformuler ta description. Vérifie toujours ses commandes avant de les lancer, surtout reset --hard ou push --force.

Erreurs à éviter

• Laisser des marqueurs <<<<<<< dans le fichier et commiter.
• Paniquer et supprimer le dépôt : un conflit se résout toujours.
• Écrire une PR vide ou des messages de commit comme « fix » ou « test ».
• Utiliser git push --force pour contourner un conflit.
• Travailler directement sur main.

À faire maintenant

Réalise le scénario complet dans ton dépôt. Livrable : le lien de ta PR fusionnée, plus 3 lignes dans ton journal d'ingénieur (commande tapée, erreur rencontrée, correction). Fais ensuite git log --oneline --graph --all et vérifie que l'historique reste lisible.

Pourquoi cet exercice t'aide à devenir DevOps

Committer une clé API par erreur est l'un des incidents les plus fréquents en entreprise. Un DevOps junior est attendu sur un point précis : il révoque d'abord la clé, puis il nettoie, puis il protège. Cet exercice t'entraîne à ce réflexe. Il alimente aussi ton portfolio GitHub (objectif : 3 projets documentés) et ton journal d'ingénieur. Il se rattache à l'objectif « maîtriser Git et le terminal en autonomie ».

Durée estimée : 20 à 25 minutes. Utilise un dépôt de test jetable, par exemple dans GitHub Codespaces ou sur ta machine.

Contexte

Tu travailles sur l'application fil rouge : une API fictive de suivi des ventes d'une boutique Mobile Money. Un collègue a poussé par erreur un fichier .env contenant une clé API. Tu vas simuler cet incident avec une fausse clé (par exemple FAKE_API_KEY=sk_test_000000_fausse_cle). N'utilise jamais un vrai secret dans cet exercice.

Étapes à réaliser

Étape 1 : simuler l'incident (5 min)

1. Crée un dépôt : mkdir boutique-api-test && cd boutique-api-test && git init.
2. Crée un fichier .env contenant API_KEY=sk_test_000000_fausse_cle.
3. Fais git add .env && git commit -m "ajout config".
4. Vérifie la présence du secret dans l'historique avec git log -p.

Étape 2 : rédiger la procédure en 4 étapes (8 min)

Crée un fichier PROCEDURE_SECRET.md. Il décrit les 4 étapes dans cet ordre :

1. Révoquer la clé chez le fournisseur et en générer une nouvelle. Dès qu'elle a été poussée, elle est considérée comme compromise.
2. Évaluer l'exposition : quels dépôts, quelles branches, quelle durée, quels accès ont été utilisés (journaux du fournisseur).
3. Nettoyer l'historique (outils de réécriture comme git filter-repo, puis push --force et prévenir l'équipe). Précise la limite : les copies, forks et clones existants peuvent toujours contenir le secret, d'où la priorité de la révocation.
4. Protéger : .gitignore, .env.example, et idéalement une analyse automatique des secrets.

Étape 3 : protéger le dépôt (7 min)

1. Retire le fichier du suivi : git rm --cached .env.
2. Crée un .gitignore contenant au minimum .env.
3. Crée un .env.example avec uniquement des valeurs factices : API_KEY=remplace_par_ta_cle.
4. Committe : git add .gitignore .env.example PROCEDURE_SECRET.md && git commit -m "protège les secrets".
5. Teste : git status ne doit plus proposer .env.

Livrables attendus

• Un dépôt de test avec PROCEDURE_SECRET.md, .gitignore et .env.example.
• Trois lignes dans ton journal d'ingénieur : commande tapée, erreur rencontrée, correction.
• Optionnel : demande à un assistant IA de relire ta procédure, puis vérifie chaque commande qu'il propose avant de l'utiliser.

Critères de réussite

• La procédure place la révocation avant le nettoyage.
• Le .gitignore exclut le fichier de secrets.
• Aucun vrai secret n'est présent dans le dépôt.

Erreurs à éviter

• Nettoyer l'historique sans révoquer : la clé reste utilisable par quiconque l'a copiée.
• Ajouter .gitignore après le commit et croire le problème réglé : il n'agit pas sur les fichiers déjà suivis.
• Utiliser un vrai secret, même pour tester.
• Oublier de prévenir l'équipe avant un push --force.