Checklists : ne plus rien oublier en exploitation

Le chirurgien Atul Gawande raconte dans son livre The Checklist Manifesto comment une simple checklist de 19 points a réduit de 47% les complications et de 36% les décès dans les blocs opératoires. Pas une nouvelle technologie, pas une formation supplémentaire — juste une feuille de papier avec des cases à cocher.

En exploitation serveur, c’est pareil. Combien de fois avez-vous oublié de vérifier un point « évident » ? Redémarré un service sans avoir fait la sauvegarde ? Mis en production sans avoir testé le rollback ?

Une checklist bien conçue élimine ces oublis.

Qu’est-ce qu’une checklist d’exploitation ?

L’analogie du pilote d’avion

Avant chaque vol, même les pilotes les plus expérimentés (20 000 heures de vol, 40 ans de carrière) suivent une checklist. Pas parce qu’ils ne savent pas piloter, mais parce que :

• Le cerveau humain oublie des étapes sous stress ou fatigue
• Certaines erreurs sont catastrophiques et ne tolèrent pas l’improvisation
• La checklist garantit que chaque point critique est vérifié

Un avion de ligne a des centaines de systèmes interconnectés. Un serveur de production aussi. Dans les deux cas, oublier une vérification peut avoir des conséquences graves.

Définition simple

Une checklist d’exploitation est une liste structurée de points de contrôle à valider avant, pendant ou après une opération. Elle répond à une question simple : « Ai-je bien fait tout ce qu’il fallait ? »

Contrairement à un runbook qui décrit comment faire une opération, une checklist vérifie que rien n’a été oublié.

Runbook	Checklist
« Exécutez df -h pour vérifier l’espace disque »	« ☐ Espace disque vérifié »
Décrit les étapes	Vérifie que les étapes sont faites
Utilisé pendant l’opération	Utilisé avant/après l’opération
Peut faire plusieurs pages	Tient sur une page

Les deux sont complémentaires : le runbook explique comment faire, la checklist garantit que c’est fait.

Les trois types de checklists

Pré-opération

Checklists « avant » : s’assurer que tout est prêt.

Exemples :

• Pré-mise en production (serveur configuré, monitoring actif, sauvegardes OK)
• Pré-maintenance (fenêtre validée, communication faite, rollback préparé)
• Pré-déploiement (tests passés, environnement de staging validé)

Ces checklists bloquent l’opération si un point n’est pas validé. Mieux vaut retarder que de foncer tête baissée.

Post-opération

Checklists « après » : vérifier que tout s’est bien passé.

Exemples :

• Post-mise en production (service accessible, logs sans erreur, métriques OK)
• Post-maintenance (services redémarrés, alertes réactivées)
• Post-incident (cause identifiée, ticket créé, runbook mis à jour)

Ces checklists valident que l’opération est vraiment terminée, pas juste « techniquement finie ».

Audit

Checklists d’audit : évaluer la conformité d’un système.

Exemples :

• Audit de sécurité (ports ouverts, utilisateurs, permissions)
• Audit de configuration (conformité au baseline, drift détecté)
• Audit de documentation (runbooks à jour, schémas actuels)

Ces checklists sont utilisées périodiquement pour détecter les dérives avant qu’elles ne causent des incidents.

Pourquoi les checklists sont essentielles

Le problème de l’oubli sous pression

Vous connaissez la procédure par cœur. Vous l’avez faite des dizaines de fois. Mais cette fois, c’est vendredi soir, le téléphone n’arrête pas de sonner, et le manager vous demande « c’est quand que c’est fini ? ».

Dans ce contexte, même les experts oublient des étapes. Pas par incompétence, mais parce que le cerveau humain a des limites cognitives :

• Mémoire de travail limitée — On ne peut garder que 4-7 éléments en tête
• Biais de confirmation — On « sait » que c’est bon, donc on ne vérifie pas
• Interruptions — Chaque interruption augmente le risque d’oubli

Une checklist externalise ces vérifications. Le cerveau n’a plus à se souvenir de tout — il lui suffit de lire et cocher.

Les bénéfices mesurables

Aspect	Sans checklist	Avec checklist
Oublis	Fréquents sous pression	Éliminés (si checklist suivie)
Cohérence	Dépend de l’opérateur	Identique pour tous
Traçabilité	Aucune	Checklist archivée = preuve
Audit	Difficile à démontrer	Facile à prouver
Formation	« Regarde comment je fais »	Liste claire des points

Les équipes qui utilisent des checklists systématiques rapportent une réduction de 50-70% des incidents liés à des oublis de configuration.

Anatomie d’une bonne checklist

La structure minimale

Une checklist efficace contient :

# Checklist : [Nom de l'opération]

## Contexte
* Quand utiliser cette checklist
* Prérequis

## Points de contrôle

### Avant l'opération
* [ ] Point 1
* [ ] Point 2

### Pendant l'opération
* [ ] Point 3

### Après l'opération
* [ ] Point 4
* [ ] Point 5

## Validation
* Opérateur : ___________
* Date : ___________
* Résultat : OK / NOK

Chaque point doit être :

• Binaire — Oui/Non, fait/pas fait, pas « partiellement »
• Vérifiable — On peut prouver que c’est fait
• Indépendant — Chaque point se vérifie seul

Exemple concret : mise en production d’un serveur

# Checklist : Mise en production serveur Linux

## Contexte
Utiliser avant de déclarer un serveur "prêt pour la production".
Prérequis : installation de base terminée.

## Configuration système
* [ ] Hostname configuré selon la convention de nommage
* [ ] Timezone correcte (Europe/Paris)
* [ ] NTP synchronisé et fonctionnel
* [ ] Locales configurées (fr_FR.UTF-8)

## Sécurité
* [ ] Firewall activé, seuls les ports nécessaires ouverts
* [ ] SSH : authentification par clé uniquement, root désactivé
* [ ] Utilisateurs : comptes nominatifs, pas de comptes partagés
* [ ] sudo : configuré avec journalisation
* [ ] Mises à jour de sécurité appliquées

## Monitoring
* [ ] Agent de monitoring installé et actif
* [ ] Métriques de base remontées (CPU, RAM, disque, réseau)
* [ ] Alertes configurées et testées
* [ ] Contact d'astreinte vérifié

## Sauvegarde
* [ ] Agent de sauvegarde installé
* [ ] Politique de sauvegarde définie
* [ ] Première sauvegarde effectuée
* [ ] Restauration testée au moins une fois

## Documentation
* [ ] Serveur documenté dans le CMDB/inventaire
* [ ] Schéma réseau à jour
* [ ] Runbooks applicables identifiés

## Validation finale
* [ ] Tests de charge/smoke tests passés
* [ ] Validation par un pair
* Opérateur : ___________
* Date : ___________

Les 5 qualités d’une checklist efficace

1. Courte — Moins de 20 points. Au-delà, divisez en plusieurs checklists. Une checklist trop longue ne sera pas utilisée.

2. Précise — « Firewall activé » plutôt que « Sécurité vérifiée ». Chaque point doit être sans ambiguïté.

3. Séquentielle — Les points sont dans l’ordre logique d’exécution. On peut suivre de haut en bas sans sauter.

4. Testée — Chaque point a été vérifié comme pertinent en conditions réelles. Pas de points « au cas où ».

5. Maintenue — Mise à jour après chaque incident révélant un oubli. Une checklist obsolète est dangereuse.

Comment créer vos checklists

Méthode pas à pas

1. Identifier l’opération à couvrir

   Commencez par les opérations critiques ou fréquentes : mise en production, maintenance planifiée, déploiement. Une opération = une checklist.

2. Lister tous les points de contrôle

   Brainstormez avec l’équipe : qu’est-ce qu’on oublie parfois ? Qu’est-ce qui a causé des incidents ? Incluez les points « évidents » — ce sont souvent ceux qu’on oublie.

3. Filtrer et prioriser

   Gardez uniquement les points critiques. Si un oubli n’a pas de conséquence grave, le point n’a pas sa place dans la checklist.

4. Structurer en phases

   Organisez en « avant / pendant / après ». Ça aide à savoir où on en est et à ne pas mélanger les vérifications.

5. Tester en conditions réelles

   Utilisez la checklist sur une vraie opération. Notez ce qui manque, ce qui est redondant, ce qui n’est pas clair.

6. Itérer après chaque utilisation

   Comme les runbooks : chaque opération est une occasion d’améliorer la checklist.

Où stocker vos checklists ?

Solution	Avantages	Inconvénients
Wiki	Facile à éditer, recherche	Pas de workflow de validation
Git	Versionné, revue par PR	Moins accessible pour certains
Outil dédié (Notion, Confluence)	Templates, assignation	Dépendance à un outil
Papier	Toujours disponible	Pas de versioning, perte facile

Recommandation : stockez les templates dans Git, utilisez des copies dans le wiki ou un outil de tickets pour l’exécution avec traçabilité.

Les anti-patterns à éviter

La checklist fleuve

Symptôme : 50 points, personne ne la lit en entier.

Problème : Une checklist trop longue sera survolée ou ignorée.

Solution : Maximum 15-20 points. Divisez en plusieurs checklists si besoin.

La checklist vague

Symptôme : « Vérifier la sécurité », « S’assurer que tout fonctionne ».

Problème : Impossible de savoir si c’est vraiment fait.

Solution : Points précis et vérifiables. « SSH : authentification par clé uniquement » plutôt que « SSH sécurisé ».

La checklist fossile

Symptôme : « Ce point date de 2018, on ne fait plus ça depuis longtemps ».

Problème : Points obsolètes = perte de confiance = checklist ignorée.

Solution : Revue trimestrielle, mise à jour après chaque incident.

La checklist optionnelle

Symptôme : « On utilise la checklist quand on a le temps ».

Problème : Les oublis arrivent justement quand on n’a pas le temps.

Solution : Checklist obligatoire, intégrée dans le workflow (pas de mise en prod sans checklist validée).

Intégrer les checklists dans votre workflow

Lier checklists et processus

La checklist ne doit pas être un document isolé. Intégrez-la dans vos outils :

• Tickets/Issues : template de ticket incluant la checklist
• CI/CD : étape de validation manuelle avec checklist
• Change management : checklist comme condition de validation
• Postmortem : « La checklist était-elle à jour ? »

Exemple : intégration GitLab

## Checklist de déploiement

### Avant merge
* [ ] Tests unitaires passés
* [ ] Review par un pair
* [ ] Documentation mise à jour

### Avant déploiement prod
* [ ] Déployé en staging
* [ ] Smoke tests passés
* [ ] Rollback testé
* [ ] Communication équipe faite

### Après déploiement
* [ ] Métriques vérifiées (pas d'anomalie)
* [ ] Logs vérifiés (pas d'erreur)
* [ ] Ticket clos

Checklists de référence

Pour commencer (minimum viable)

• Identifier 3 opérations critiques sans checklist
• Créer une checklist simple pour chacune (< 15 points)
• Stocker dans un endroit accessible à tous
• Tester sur une opération réelle
• Identifier un responsable par checklist
• Planifier une revue trimestrielle

Pour une organisation mature

• Toutes les opérations critiques ont une checklist
• Checklists versionnées dans Git
• Intégration dans les outils (tickets, CI/CD)
• Mise à jour systématique après chaque incident
• Métriques d’utilisation (taux de complétion)
• Audit régulier de la pertinence
• Formation des nouveaux sur les checklists clés

À retenir

1. Une checklist n’est pas pour les débutants — Même les experts oublient sous pression. Les pilotes chevronnés utilisent des checklists.

2. Court et précis — 15-20 points maximum, chaque point vérifiable et sans ambiguïté.

3. Binaire — Fait ou pas fait. Pas de « partiellement » ou « à peu près ».

4. Obligatoire, pas optionnel — Si la checklist est facultative, elle ne sera pas utilisée quand on en a le plus besoin.

5. Vivante — Mise à jour après chaque incident ou oubli découvert.

6. Intégrée — Dans les outils et processus, pas un document isolé.

Prochaine étape : identifiez l’opération critique que vous faites le plus souvent. Créez une checklist de 10 points. Utilisez-la lors de la prochaine occurrence. Améliorez.

Liens internes

• Runbooks — Procédures détaillées d’exploitation
• Patch management — Gestion des mises à jour
• Baselines et drift — Conformité des configurations

Sources et références

• The Checklist Manifesto ↗ — Atul Gawande
• Site Reliability Engineering (Google) ↗ — Pratiques SRE
• CIS Controls ↗ — Bonnes pratiques de sécurité