00 - Workflow Git & Docker (Transversal)

Ce workflow s’applique à TOUS les modules


Pourquoi un workflow transversal ?

Les agents LLM modifient votre code.
Sans workflow structuré, vous perdez :

  • L’historique des changements
  • La possibilité de revenir en arrière
  • La traçabilité de ce que l’agent a fait

Ce module est référencé dans tous les TP.
Appliquez-le systématiquement.


Git Workflow Obligatoire

Règle #1 : Une feature = Une branche

# JAMAIS travailler sur main/master directement
git checkout main
git pull origin main
git checkout -b feature/nom-de-la-feature

Pourquoi ?

  • Isolation des changements
  • Possibilité d’abandonner sans casser main
  • Historique propre

Règle #2 : Commits atomiques

Un commit = Une logique.

# BON : commits atomiques
git add src/auth.ts
git commit -m "feat: add JWT token validation"

git add src/middleware.ts
git commit -m "feat: add auth middleware"

git add tests/auth.test.ts
git commit -m "test: add auth JWT tests"

# MAUVAIS : un gros commit
git add .
git commit -m "feat: add auth system with tests and fixes and refactors"

Comment écrire un bon message :

<type>: <description courte>

Types possibles:
- feat: nouvelle fonctionnalité
- fix: correction de bug
- refac: refactoring
- test: ajout de tests
- docs: documentation
- chore: tâche maintenance

Règle #3 : Agent Visibility

Git est votre fenêtre sur ce que l’agent fait.

# Avant de demander à l'agent
git status  # Vérifier l'état

# Après que l'agent a fait des changements
git diff    # Voir exactement ce qui a changé

# Si l'agent modifie 50 fichiers
git diff --stat  # Vue d'ensemble

# Isoler les changements par fichier
git diff src/specific-file.ts

Pattern de sécurité :

YOU: "Add authentication to the app"
AGENT: [modifies 12 files]

YOU: 
git diff --stat
# Hmm, pourquoi setup.py a changé ?

git diff setup.py
# L'agent a ajouté une dépendance suspicieuse ?

# Questionner l'agent avant de commit

Règle #4 : Push régulier

# Push à chaque milestone
git push origin feature/ma-feature

# En cas de problème majeur
git reset --hard origin/feature/ma-feature  # Revenir au dernier push

Docker Workflow Optionnel

Pourquoi Docker ?

Isolation des environnements agents.

Avantage Description
Sandbox L’agent ne peut pas casser votre système
Reproductibilité Même environnement pour toute l’équipe
Cleanup facile docker rm et c’est propre

Guardrails SOFT avec Docker

Container = Protection du filesystem.

# Dockerfile pour agent sandbox
FROM node:20-slim

WORKDIR /app

# Pas de volumes sensibles
# Pas de USER root (si possible)
# Network limité

COPY package*.json ./
RUN npm install

COPY . .

CMD ["bash"]
# Lancer un agent dans un container
docker build -t agent-sandbox .
docker run -it --rm \
  -v $(pwd):/app \
  agent-sandbox \
  bash

# L'agent travaille dans /app
# Il ne peut pas toucher au reste du système

Guardrails HARD (Linux User)

Alternative : User Linux sans permissions.

# Créer un user limité
sudo useradd -m -s /bin/bash agentuser

# Donner accès uniquement au projet
sudo chown -R agentuser:agentuser /path/to/project

# Lancer les commande agent en tant que agentuser
sudo -u agentuser bash
cd /path/to/project
# L'agent ne peur pas toucher à ~, /etc, etc.

Avantages :

  • Plus proche de l’environnement réel
  • Pas de couche Docker

Inconvénients :

  • Setup plus complexe
  • Moins isolé que Docker

Règle #5 : Slop Removal (Avant Commit)

Les agents génèrent du code “slop” - code inutile qu’il faut nettoyer.

Qu’est-ce que le slop ?

Type Exemple Pourquoi c’est un problème
Commentaires TODO // TODO: improve this Reste dans le code
Code commenté // function oldVersion() Pollue le code
Imports inutilisés import { unused } Bundle size
Console.log console.log("debug") Logs en production
Fonctions mortes function oldHelper() Maintenance burden
Types inutilisés interface OldFormat Confusion

Pattern de cleanup obligatoire

# APRÈS que l'agent a fini, AVANT de commit
git diff --stat
# Vérifier quels fichiers sont modifiés

# Identifier le slop
git diff src/new-feature.ts
# L'agent a-t-il laissé des console.log ?
# Des commentaires TODO ?
# Des imports inutilisés ?

# Demander le cleanup
YOU: "Remove all console.log, commented code, and unused imports from src/new-feature.ts"

# Re-vérifier
git diff src/new-feature.ts

# Maintenant commit propre
git add src/new-feature.ts
git commit -m "feat: add new feature"

Slop Removal Checklist

Avant chaque commit, vérifier :
- [ ] Pas de console.log/print statements
- [ ] Pas de code commenté
- [ ] Pas de TODO/FIXME laissés
- [ ] Imports inutilisés supprimés
- [ ] Fonctions mortes supprimées
- [ ] Variables inutilisées supprimées

Règle #6 : Commits Multiples par Feature

Une feature = Plusieurs commits atomiques.

Le problème

❌ BAD: Un seul commit pour toute la feature
YOU: "Add user authentication"
AGENT: [modifies 15 files, adds auth, tests, middleware, docs]
YOU: git add . && git commit -m "feat: add auth"
# Diff énorme, impossible à review, rollback tout ou rien

La solution : Orchestration des commits

✅ GOOD: Guide l'agent commit par commit

YOU: "Add user authentication. Commit after each logical step."

AGENT: 
  1. Creates auth types
  2. git add src/types/auth.ts && git commit -m "feat: add auth types"
  
  3. Adds JWT validation
  4. git add src/auth/jwt.ts && git commit -m "feat: add JWT validation"
  
  5. Creates middleware
  6. git add src/middleware/auth.ts && git commit -m "feat: add auth middleware"
  
  7. Adds tests
  8. git add tests/auth.test.ts && git commit -m "test: add auth tests"

YOU: git log --oneline -5
# 5 commits reviewables, rollbackables

Pattern d’orchestration

YOU: "Implement [FEATURE]. Make atomic commits after each logical step:
     1. Types/interfaces first
     2. Core implementation
     3. Integration/middleware
     4. Tests
     5. Documentation
     
     Run slop removal before each commit."

AGENT: [Implements step 1]
       [Removes slop]
       [Commits]
       [Implements step 2]
       ...

Checklist commits multiples

- [ ] Chaque commit a un message descriptif
- [ ] Chaque commit passe les tests
- [ ] Chaque commit est reviewable seul
- [ ] `git log --oneline` raconte l'histoire
- [ ] Rollback possible à n'importe quelle étape

Avantages :

  • Code review facilitée
  • Rollback granulaire
  • Historique lisible
  • Debugging plus simple (bisect)

Yolo Mode ⚠️

Le piège

Définition : Laisser l’agent opérer sans supervision.

❌ BAD:
YOU: "Fix the bug in auth.ts"
[AGENT modifies auth.ts]
[AGENT modifies package.json]
[AGENT modifies .env ← DANGER]
[AGENT modifies database schema]
YOU: "Thanks!" ← Vous n'avez rien vérifié

Le pattern sécurisé

✅ GOOD:
YOU: "Fix the bug in auth.ts. Only touch auth.ts."

[AGENT modifies auth.ts]

YOU: git diff auth.ts
# Vérifiez les changements

YOU: "Why did you change line 42?"

AGENT: Explains the reasoning

YOU: "OK, commit that separately from the fix."

git add auth.ts
git commit -m "fix: auth token expiration check"

Catastrophic Forgetting

⚠️ Si l’agent n’a pas de guardrails intégrés, l’oubli catastrophique contournera vos protections.

Ce qui arrive :

  1. Vous dites “Don’t modify files outside src/”
  2. L’agent dit “OK”
  3. 20 messages plus tard…
  4. L’agent “oublie” et modifie package.json
  5. Vous ne remarquez pas

Solution : Le test du nom

Dans votre AGENTS.md (ou instructions agent):

"Call me by my name at the beginning of each message.
 If you forget my name, it means you're experiencing
 catastrophic forgetting and should compress context."

Agent: "Hadrien, here's the fix..."

Agent: "Here's another fix..."  ← ALERTE : forgetting!

Vous: /compact  ← Compresser le contexte

Pourquoi ça fonctionne :
L’instruction “call me by name” est en préfixe du contexte.
Si le contexte grossit trop, cette instruction est éjectée.
L’agent arrête de vous nommer = signal d’alerte.


MCP Web Search (Transversal)

Pourquoi MCP Search ?

Les agents ont besoin de rechercher hors du code.

  • Documentation externe
  • Solutions sur Stack Overflow
  • Bugs connus dans les issues GitHub
  • Nouvelles versions de packages

MCP Search = Interface unifiée.


MCP Disponibles

MCP Usage
Google Custom Search Recherche générale
DuckDuckGo Search sans tracking
Brave Search Alternative privacy-first

// mcp-config.json
{
  "mcpServers": {
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": {
        "BRAVE_API_KEY": "your-key-here"
      }
    }
  }
}

Usage dans les TP

Pattern :

YOU: "Search for the latest best practices for Next.js 14 authentication"

AGENT: [uses MCP Brave Search]

AGENT: "Based on the search results, NextAuth.js v5 with OAuth 
       is recommended. Here's the pattern..."

Les TP qui utilisent MCP Search :

  • Module 8 : Debugging (recherche d’erreurs)
  • Module 9 : Tests (patterns de test)
  • Module 11 : Unknown Tech (doc Rust/Bevy)
  • Module 12 : Projet (recherche générale)

Récapitulatif du Workflow

Checklist avant chaque TP

  • Branche Git créée (feature/nom-feature)
  • Container Docker lancé (optionnel mais recommandé)
  • AGENTS.md configuré avec “call me by name”
  • MCP Search disponible si nécessaire

Pendant le TP

  • Commits atomiques après chaque changement
  • git diff avant chaque commit
  • Vérification que l’agent respecte les guardrails
  • Push régulier vers remote

Après le TP

  • Historique Git reviewé
  • Branche mergée dans main (ou PR créée)
  • Container nettoyé (docker rm)

Références Transversales

Ce module est référencé dans :

  • Module 7 : Ralph Loop
  • Module 8 : Debugging
  • Module 9 : Tests
  • Module 10 : Conventions
  • Module 11 : Unknown Tech (Rust/Bevy)
  • Module 12 : Projet Final

Appliquez ce workflow partout.
C’est votre filet de sécurité.