DevOps + IA

5.0Objectifs de la session

• Comprendre les étapes d'un pipeline CI/CD (build → test → deploy)
• Intégrer l'IA dans le pipeline : review auto, génération de tests, résumés
• Déployer une application simple avec environnements et rollback
• Poser les bases du monitoring et exploiter l'IA pour analyser des incidents

5.1CI/CD express pour novices

Un pipeline CI/CD, c'est l'automatisation du chemin entre un commit et la production : à chaque push, une machine neutre vérifie que le code compile, que les tests passent, puis déploie. Trois étapes canoniques : build → test → deploy. Si une étape échoue, la suivante ne part pas.

Exemple : workflow GitHub Actions complet

# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [main]
  pull_request:

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint        # 1. qualité statique
      - run: npm test            # 2. tests unitaires
      - run: npm run build       # 3. le projet compile

• Déclencheurs — on: push et on: pull_request : chaque PR est vérifiée avant merge.
• Machine jetable— le job part d'un environnement vierge : fini le « ça marche sur ma machine ».
• Branches protégées — configurer main pour exiger CI verte + review avant merge. C'est le verrou qui rend le pipeline utile.

5.2IA dans le pipeline

Une fois le pipeline en place, l'IA devient un reviewer infatigablequi tourne sur chaque PR. Cas d'usage éprouvés :

• Review auto sur PR— Claude Code en action GitHub : commente le diff, signale bugs, oublis de gestion d'erreur, incohérences avec les conventions du repo.
• Génération de tests — cibler le code non couvert (rapport de coverage en entrée) et proposer des tests unitaires en PR séparée.
• Résumés de diff— description de PR générée : quoi, pourquoi, points d'attention. Gain énorme pour les reviewers humains.
• Triage d'issues — labelliser, dédupliquer, demander les infos manquantes automatiquement.

# .github/workflows/claude-review.yml (extrait)
name: Claude Review
on:
  pull_request:

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Review ce diff : bugs, sécurité, conventions du repo."

5.3Déploiement

Trois options simples, par ordre de friction croissante :

Les environnements

• Preview — un déploiement par PR, URL unique : on teste la feature avant le merge.
• Staging— copie de la prod pour valider l'intégration.
• Production— ce que voient les utilisateurs. On n'y pousse que du code passé par les étapes précédentes.

Rollback: le déploiement précédent doit rester à un clic. Un bon setup rend le retour arrière plus rapide que le hotfix — c'est lui qui vous sauve à 18h un vendredi.

5.4Monitoring & boucle de retour

Déployer sans observer, c'est piloter sans instruments. Le minimum vital :

• Logs structurés — JSON avec niveau, timestamp, contexte (requestId, userId). Un log qu'on ne peut pas filtrer est un log perdu.
• Alerting basique— taux d'erreurs 5xx, latence p95, healthcheck. Trois alertes bien réglées valent mieux que trente ignorées.
• Uptime — un ping externe sur /health : vous apprenez la panne avant vos utilisateurs.

L'IA comme analyste d'incident

Cas concret : l'API renvoie des 500 depuis 14h32. Copiez 200 lignes de logs dans Claude Code avec le prompt : « Ces logs couvrent 14h25–14h40. Les 500 commencent à 14h32. Trouve la corrélation et propose une hypothèse. » Le modèle repère en secondes le pattern (déploiement à 14h31, pool de connexions saturé, variable d'env manquante…) qu'un humain met de longues minutes à isoler.

• Post-mortems assistés— timeline des événements + logs en entrée, brouillon de post-mortem en sortie : causes, impact, actions correctives. L'humain valide et complète.

5.5TP de la session

Dossier exercices/session-5/ du repo. Au programme :

• TP1 — Créer le pipeline CI du repo : lint + tests sur chaque PR, branche main protégée
• TP2 — Ajouter une review IA automatique sur PR et calibrer son prompt
• TP3— Déployer l'app d'exercice, puis provoquer une panne et la diagnostiquer avec l'IA à partir des logs

5.6Checklist de fin de session

• Je sais expliquer les trois étapes build → test → deploy et leur ordre
• J'ai écrit un workflow GitHub Actions qui lint et teste chaque PR
• J'ai mis en place une review IA sur PR et compris pourquoi elle ne bloque pas le merge
• J'ai déployé l'app d'exercice avec un environnement de preview
• J'ai diagnostiqué une panne en donnant des logs à l'IA

5.7Quiz de validation

5.8Défi inter-session