Relire un changement IaC : revue humaine et checklist

Relire du code IaC ne consiste pas à vérifier que la syntaxe passe : c'est juger le périmètre, le risque et l'impact réel d'un changement avant qu'il s'exécute. Cette leçon porte sur la revue humaine : ce qu'elle regarde, dans quel ordre, avec quelle checklist. Les contrôles qui s'exécutent seuls (formatage, validation, lint, tests) sont l'objet de la leçon Tests et contrôles automatiques ; ici, on les suppose déjà passés. Elle s'adresse à une personne qui connaît Git et les pull requests, sans expérience de revue d'infrastructure.

Les extraits sont des illustrations à lire, pas des étapes à exécuter.

Ce que vous allez apprendre

• distinguer ce que la revue humaine juge de ce qu'un outil bloque seul ;
• lire un plan ou un aperçu de changement avant d'approuver ;
• appliquer une checklist de revue et rendre un verdict motivé ;
• repérer les erreurs de revue les plus fréquentes.

Que risque une revue qui parcourt seulement les fichiers ?

Dans le scénario de la formation (une équipe de quatre personnes, une application web en passage au code), une pull request (une demande de fusion de code dans la branche principale, relue par l'équipe) ajoute une VM, ouvre un flux réseau et modifie un rôle de configuration système. Si la revue se limite à parcourir les fichiers, plusieurs problèmes passent : un changement de topologie trop large, un secret sorti au mauvais endroit, un remplacement involontaire de machine, un couplage flou entre création de ressource et configuration.

À l'inverse, si les outils ont déjà vérifié la forme, le relecteur peut se concentrer sur quatre questions : qu'est-ce qui change, pourquoi, avec quel impact, et comment revient-on en arrière si besoin ?

Que juge la revue humaine, et que laisse-t-elle aux outils ?

Un outil sait dire qu'un fichier est mal formaté ou qu'un argument est invalide. Il ne sait pas dire si ce changement est le bon pour ce périmètre. Le tableau répartit les rôles.

Question	Qui y répond	Exemple
La forme est-elle conforme ?	Outil	formatage, syntaxe, lint (analyse automatique des erreurs courantes)
Une règle connue est-elle violée ?	Outil	bucket public, secret en clair détecté
Le périmètre du changement est-il le bon ?	Humain	la PR touche-t-elle un autre dépôt de responsabilité ?
L'impact sur le réel est-il compris ?	Humain	le plan annonce-t-il un remplacement inattendu ?
Le risque est-il acceptable, la marche arrière claire ?	Humain	que se passe-t-il si l'application échoue à mi-parcours ?

Glissez pour voir

La règle qui en découle : la relecture humaine ne perd pas de temps sur ce qu'un outil peut bloquer avant elle. Si le relecteur signale un mauvais formatage, le processus gaspille son attention.

Dans quel ordre préparer et mener la revue ?

L'ordre compte, car chaque étape évite à la suivante de traiter du bruit.

1. Faire passer les contrôles mécaniques avant d'ouvrir la revue

   Formatage, validation et lint s'exécutent d'abord, idéalement par un hook (un script que Git lance automatiquement à un moment précis, par exemple avant un commit). Les erreurs évidentes disparaissent avant que quelqu'un d'autre s'en occupe.

2. Produire une lecture claire du changement

   Le diff (la liste des lignes modifiées) montre un périmètre lisible. Si une même PR mélange topologie, configuration système et refonte de structure, la revue devient mécaniquement plus faible : demandez de la découper.

3. Examiner l'impact réel

   Pour l'infrastructure déclarative, la lecture du plan est centrale : c'est l'aperçu des créations, modifications et destructions que l'outil annonce avant d'agir. Pour la configuration, il faut comprendre quelles machines, quels services et quelles règles sont touchés.

4. Rendre un verdict sur le fond

   C'est le moment de juger la cohérence d'architecture, le découpage des responsabilités, les implications de sécurité et le risque opérationnel.

Le schéma reprend ces étapes sous forme de questions appliquées à la PR du scénario. Descendez la colonne centrale : chaque « oui » mène à la question suivante, chaque « non » sort à droite vers une action qui n'est pas une approbation. La première question est posée aux outils, les trois suivantes au relecteur.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Comment lire un plan avant d'approuver ?

Un plan se lit par ses symboles, pas par sa longueur. Ces symboles et l'ordre de lecture d'une sortie sont décrits dans État, plan et réconciliation ; ici, on s'en sert comme relecteur. Voici un extrait fictif d'un plan Terraform pour la PR du scénario (illustration à lire, pas une sortie à reproduire).

  # aws_instance.app_2 must be replaced
-/+ resource "aws_instance" "app_2" {
      ~ ami = "ami-0aaa" -> "ami-0bbb" # forces replacement
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Le plan annonce un remplacement de la VM app_2 alors que la description de la PR parle d'une simple mise à jour d'image, ce qui n'est probablement pas ce que l'auteur voulait annoncer. Le relecteur pose alors la question : que contient cette VM, et que perd-on pendant le remplacement ? La lecture détaillée du plan relève du guide Le workflow Terraform : init, plan, apply, destroy.

Quelle checklist appliquer en pratique ?

Cette checklist sert de rappel, pas de formulaire à remplir mécaniquement. Chaque ligne correspond à un risque que seul un humain voit dans le contexte de l'équipe.

Question	Pourquoi elle compte
Le diff change-t-il le bon périmètre ?	Évite de mélanger plusieurs responsabilités
Le plan ou l'aperçu est-il cohérent avec la description ?	Réduit les surprises à l'exécution
Un remplacement ou une destruction est-il annoncé sans raison ?	Protège les données et la disponibilité
Un secret ou une donnée sensible apparaît-il dans le diff ou le plan ?	Réduit le risque immédiat
Le changement est-il assez petit pour être bien relu ?	Une PR trop grosse se relit mal
La source de vérité reste-t-elle claire après ce changement ?	Évite la dérive structurelle
La marche arrière est-elle compréhensible ?	Prépare la réponse à incident

Glissez pour voir

Question de départ

Une bonne revue commence par : est-ce que je comprends précisément ce qui va changer dans le réel ? Si la réponse est non, clarifiez avant d'approuver.

Quelles sont les erreurs de revue les plus fréquentes ?

Deux erreurs reviennent. Relire uniquement la syntaxe : approuver parce que « ça a l'air propre », sans lire le périmètre ni le changement réel, passe à côté de la fonction de la revue. Approuver un changement trop gros : en IaC, une PR qui touche trop de zones a des effets larges sur l'infrastructure et devient impossible à comprendre.

Où s'arrête cette leçon ?

Cette leçon pose la méthode de relecture et son séquencement. Elle ne détaille ni la pyramide des contrôles automatiques (Tests et contrôles automatiques), ni les règles de conformité exprimées en code (la leçon facultative Policy as code). Pour installer les hooks localement, voir pre-commit : bloquer les erreurs avant qu'elles n'atteignent le dépôt.

À retenir

• La revue humaine juge le périmètre, l'impact et le risque ; les outils jugent la forme et les règles connues.
• Les contrôles mécaniques passent avant la revue, pas pendant.
• Un plan se lit par ses symboles : un remplacement ou une destruction non annoncé est le premier signal d'alerte.
• Une PR trop large se relit mal : demander de la découper est une revue valide.
• Un verdict de revue est motivé : il cite le diff, le plan et la checklist.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →