ChatGPT pour DevOps : créer et fiabiliser des runbooks (2026)

À la fin de cette leçon, vous saurez structurer un runbook exploitable à 3 h du matin, prompter ChatGPT pour le générer ou le densifier à partir d’alertes et de logs anonymisés, appliquer une checklist sécurité (zéro secret, human-in-the-loop), et brancher la suite vers Custom GPTs / Teams Enterprise.

Niveau : Débutant → Intermédiaire · Temps estimé : 45–60 min · Versions cibles : ChatGPT (Plus / Team / Enterprise, modèles GPT-4.1 / o-series selon plan 2026) · Markdown runbooks versionnés Git · kubectl 1.31+ (lab) · Dernière vérification : 2026-09-11

Statut : HOLD — draft only (ne pas publier sur WordPress)

Prérequis

• [ ] Compte ChatGPT (Plus, Team ou Enterprise recommandé pour projets / contrôles data)
• [ ] Notions DevOps : incident, on-call, rollback — voir hubs Kubernetes, Jenkins, Docker
• [ ] Un dépôt Git pour stocker les runbooks en Markdown (docs/runbooks/)
• [ ] (Lab) cluster ou sandbox kubectl + un extrait de logs déjà redacté
• [ ] Coût estimé : abonnement ChatGPT selon plan · 0 € d’infra si lab local

Cette page ne remplace pas votre playbook d’astreinte : elle montre comment ChatGPT accélère la rédaction et la revue de runbooks, pas l’exécution aveugle en production.

Ce que nous allons construire

ChatGPT × Runbooks DevOps (leçon 26)
  ├── Anatomie d’un runbook (déclencheur → checks → fix → verify → owners)
  ├── Patterns de prompts : générer / densifier / challenger
  ├── Lab : CrashLoopBackOff → runbook Markdown versionné
  ├── Sécurité : redaction, dry-run mental, human approval
  ├── Checklist qualité + FAQ
  └── Suite : Custom GPTs, Actions, Teams/Enterprise, parcours IA

(Schéma à remplacer par une image locale, alt : « Pipeline ChatGPT vers runbook Markdown versionné Git pour on-call DevOps ».)

Étape 1 — Pourquoi ChatGPT pour les runbooks en 2026

Un runbook est une procédure opérationnelle : quoi faire quand une alerte tire, dans quel ordre, avec quelles preuves et quel rollback. En 2026, on gagne du MTTR surtout en réduisant le temps de compréhension (triage), pas en laissant un modèle exécuter des commandes inventées.

Usage ChatGPT	Valeur	Limite
Brouillon / densification	Doc plus vite, plus claire	Flags ou APIs inventés
Revue adverse	Trous et ambiguïtés	Ne remplace pas un SRE
Résumé de logs redactés	Hypothèses classées	Preuves obligatoires
Exécution prod sans garde-fou	—	Interdit ici

Règle d’or : ChatGPT propose ; humain / CI / agent allowlist décide et exécute. Voir prompt injection & sécurité.

Concrètement, le gain apparaît quand l’astreinte ouvre un runbook déjà structuré. ChatGPT transforme bien un squelette + symptômes redactés en procédures lisibles (diagnostics read-only d’abord). Il reste faible dès qu’on lui demande d’inventer la vérité du cluster : flags inventés ou « delete le pod » comme solution unique. Votre métier : cadrer le prompt et vérifier chaque commande en lab avant merge.

Étape 2 — Anatomie d’un runbook exploitable

Avant de prompter, figez le contrat du document. Sans lui, le modèle produit du texte long peu actionnable. Chaque runbook Markdown du dépôt devrait contenir :

Bloc	Contenu minimum
Métadonnées	ID, sévérité, service, owners, dernière revue
Déclencheur	Alerte / symptôme / seuil (ex. KubePodCrashLooping)
Impact	Utilisateur, SLO, blast radius
Diagnostics	Commandes read-only + sortie attendue
Remédiation	Étapes ordonnées, risque, prérequis
Vérification	Postconditions mesurables
Rollback	Comment annuler si ça empire
Escalade	Qui appeler après N échecs

Ce contrat sert de grille d’évaluation : section manquante → consigne ciblée (« ajoute verify », « marque les writes APPROBATION HUMAINE ») plutôt que tout régénérer. Exemple de squelette (docs/runbooks/k8s-crashloop.md) :

# Runbook : Pod CrashLoopBackOff

- **ID :** RB-K8S-001
- **Sévérité :** Sev-2
- **Service :** payments-api
- **Owners :** @platform-oncall
- **Dernière revue :** 2026-09-11

## Déclencheur
Alerte Prometheus `KubePodCrashLooping` sur namespace `prod`.

## Diagnostics (read-only)
1. `kubectl -n prod get pod -l app=payments-api`
2. `kubectl -n prod describe pod <pod>`
3. `kubectl -n prod logs <pod> --previous --tail=200`

## Remédiation
(à compléter — jamais de delete sans confirmation humaine)

## Vérification
Pod `Running` + ready ; taux d’erreur 5xx < seuil SLO 15 min.

## Rollback / Escalade
Revert dernier deploy ; escalade Sev-1 si > 30 min.

Étape 3 — Patterns de prompts (générer, densifier, challenger)

Travaillez en trois passes (générer → revue humaine → densifier/challenger → commit). Versionnez les prompts dans le dépôt (prompts/runbook-*.md) pour éviter la dérive de style.

Prompt A — Générer depuis un squelette

Tu es un SRE senior. À partir du squelette Markdown ci-dessous, produis un runbook
complet en français pour on-call 3h du matin.

Contraintes :
- Commandes diagnostics UNIQUEMENT en read-only (get, describe, logs, top).
- Toute remédiation destructive (delete, scale, rollout undo) doit être marquée
  « APPROBATION HUMAINE REQUISE ».
- Sépare clairement : Faits observés / Hypothèses / Actions proposées.
- N’invente pas de flags kubectl inexistants ; si tu n’es pas sûr, dis « à vérifier ».
- Sortie : Markdown prêt à committer dans docs/runbooks/.

Squelette :
<<<COLLER LE SQUELETTE>>>

Contexte anonymisé (pas de secrets, pas d’IP internes, pas de tokens) :
<<<COLLER ALERTE + EXTRAIT LOGS REDACTÉS>>>

Prompt B — Densifier un runbook trop court

Voici un runbook trop vague. Ajoute : prérequis, sorties attendues par commande,
critères go/no-go, limite de retries (max 3), et une section « Ce que ce runbook
ne couvre PAS ». Garde le ton FR opérationnel. Ne change pas l’ID ni les owners.

Prompt C — Revue adverse (challenger)

Joue le rôle d’un reviewer SRE exigeant. Liste les trous du runbook (ambiguïtés,
commandes dangereuses, absence de verify, secrets potentiels, blast radius).
Pour chaque trou : sévérité (P1/P2/P3) + correction concrète en une phrase.
Ne réécris pas tout le document.

Enchaînez A → revue humaine → B ou C → commit Git. Les slash commands ChatGPT figent ces prompts en raccourcis. Revue humaine en trois questions : diagnostics sans risque ? writes gated ? verify mesurable ? Sinon, pas de merge.

Étape 4 — Lab : de CrashLoopBackOff au runbook versionné

Objectif lab : runbook RB-K8S-001 commit-ready en ~20 min (pod payments-api en CrashLoopBackOff). Rejouable sur un job CI rouge en changeant le bundle.

1. Redactez : gardez le signal (stack, exit code), enlevez le sensible (REDACTED).
2. Collez squelette + extrait dans le Prompt A (Faits / Hypothèses / Actions).
3. Exécutez les diagnostics vous-même en lab ; corrigez commandes inventées ou ambiguës.
4. Lancez le Prompt C ; corrigez les P1/P2 avant la remédiation gated.
5. Committez :

mkdir -p docs/runbooks
# coller le Markdown final dans docs/runbooks/k8s-crashloop.md
git add docs/runbooks/k8s-crashloop.md
git commit -m "docs(runbooks): add RB-K8S-001 CrashLoopBackOff payments-api"

Succès : un collègue suit sans demander « laquelle des pods ? » ni « on delete ? ». Si la lecture dépasse cinq minutes avant la première commande utile, raccourcissez.

Variante CI : job Jenkins rouge — bundle anonymisé ; ChatGPT propose la prochaine commande de lecture, pas un patch. Liez ensuite l’alerte vers docs/runbooks/k8s-crashloop.md.

Étape 5 — Sécurité : ce qu’il ne faut jamais coller

Interdit dans le chat	Alternative
Tokens, clés API, mots de passe, kubeconfig	Magasin de secrets / vault ; placeholders ***
Données perso / payloads clients	Synthèse agrégée ou fixtures
Dump complet de prod	Fenêtre courte + redaction
« Exécute ce delete sur mon cluster » via un outil non borné	Approbation humaine + dry-run

Préférez ChatGPT Team / Enterprise quand les runbooks touchent des systèmes sensibles : contrôles d’admin, rétention, pas d’entraînement sur vos données selon contrat. Détails : ChatGPT Teams / Enterprise. Activez la discipline Memory avec parcimonie (préférences d’équipe, pas de secrets).

Human-in-the-loop : toute write (rollout undo, scale, delete, restart) reste derrière « APPROBATION HUMAINE REQUISE ». Traitez l’historique de chat comme zone sensible : pas de kubeconfig « pour le contexte » ; fixtures dans labs/fixtures/ plutôt que exports prod.

Étape 6 — Custom GPTs et suite (sans tout automatiser)

Après 5–10 runbooks stables : Custom GPT « Runbook Writer » (instructions + 3 exemples gold), Actions read-only si gouvernance OK, puis AI Skills. Pas d’Actions d’écriture sans scopes minimaux et audit. Parcours : IA pour DevOps 2026.

Étape 7 — Checklist qualité avant merge

• [ ] Métadonnées complètes (ID, sévérité, owners, date de revue)
• [ ] Diagnostics read-only en premier ; remédiations marquées approval
• [ ] Sorties attendues + critères verify mesurables
• [ ] Limite de retries + escalade temporelle
• [ ] Section « hors scope »
• [ ] Aucun secret / PII dans le fichier ni dans l’historique de chat utilisé pour le rédiger
• [ ] Revue humaine (Prompt C + pair) avant main
• [ ] Lien depuis l’alerte (annotation runbook_url) testé

Étape 8 — Erreurs fréquentes

Symptôme	Cause probable	Correction
Runbook « magique » avec flags inventés	Confiance aveugle au modèle	Forcer « à vérifier » + tester en lab
MTTR qui n’améliore pas	Texte long, diagnostics faibles	Prioriser evidence links + 5 commandes max
Fuite de secret dans un GPT	Copier-coller kubeconfig / .env	Redaction checklist + Team/Enterprise
Boucle restart pods	Pas de max retries	Cap 3 + escalade
Runbook obsolète	Jamais revu après un incident	Date de revue + owner + lien postmortem

Quiz (5 questions)

1. Quel est le rôle principal de ChatGPT dans cette leçon ?
– A. Exécuter automatiquement les remédiations en production
– B. Rédiger, densifier et challenger des runbooks sous garde-fous humains
– C. Remplacer PagerDuty et l’astreinte

2. Que doit contenir en premier un runbook généré pour l’on-call ?
– A. Un script destructif prêt à coller
– B. Des diagnostics read-only avec sorties attendues
– C. Uniquement une explication théorique du symptôme

3. Que faire avant de coller des logs dans ChatGPT ?
– A. Tout coller pour maximiser le contexte
– B. Redacter secrets, PII et identifiants internes
– C. Désactiver Team/Enterprise

4. À quoi sert le Prompt C (revue adverse) ?
– A. Générer une image de couverture
– B. Lister trous, risques et corrections sans tout réécrire
– C. Pousser directement sur main

5. Où versionner le runbook final ?
– A. Uniquement dans l’historique ChatGPT
– B. Dans Git (docs/runbooks/), reviewé comme du code
– C. Dans un message Slack éphémère

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

1. ChatGPT peut-il remplacer PagerDuty / nos playbooks ?
Non. Il accélère la rédaction et le triage documentaire. L’alerte, l’escalade et l’exécution restent dans vos outils d’astreinte et vos garde-fous.

2. Faut-il un Custom GPT dès le premier runbook ?
Non. Commencez par 3 prompts versionnés dans le repo (prompts/runbook-*.md). Passez à un Custom GPT quand le style d’équipe est stable.

3. Quel modèle choisir en 2026 ?
Un modèle fort en raisonnement pour la revue adverse ; un modèle rapide pour densifier. L’essentiel est le contrat du runbook et la redaction, pas la marque du modèle.

4. Puis-je laisser un agent exécuter le runbook ?
Seulement avec allowlist, dry-run par défaut, approval sur les writes et verify — hors scope ici (module agents / MCP du parcours).

5. Où stocker les runbooks ?
Dans Git (docs/runbooks/), reviewés comme du code, liés depuis l’alerte. Pas uniquement dans une conversation ChatGPT.

Points clés à retenir

• ChatGPT sert à rédiger, densifier et challenger des runbooks — pas à exécuter la prod sans garde-fous.
• Un runbook utile a un contrat : déclencheur, diagnostics read-only, remédiation approuvée, verify, rollback, owners.
• Trois prompts suffisent pour démarrer : générer, densifier, revue adverse.
• Redaction et Team/Enterprise sont non négociables dès que le contexte est sensible.
• Versionnez dans Git et mesurez si le runbook réduit le temps de compréhension on-call.

Mesurez aussi le succès ops : temps jusqu’à la première commande utile et incidents où le runbook a vraiment été ouvert.

Pour aller plus loin

Custom GPTs · Actions · Teams / Enterprise · Prompt injection · Kubernetes · Jenkins · Docker

Maillage série IA (CTA)

← Précédent	ChatGPT Actions & outils
→ Suivant	ChatGPT Teams / Enterprise
Aussi	Slash commands panorama · Parcours IA DevOps 2026 · Custom GPTs