Valider et relire son code IaC

Relire du code IaC ne consiste pas seulement à vérifier que la syntaxe passe. Une bonne revue cherche à répondre à trois questions: le code est-il lisible, le changement est-il valide, et l’impact sur l’infrastructure est-il bien compris avant exécution. Tant que ces trois niveaux restent mélangés, les revues deviennent inefficaces. L’équipe perd du temps sur le formatage, laisse passer des changements risqués, ou approuve des modifications dont elle n’a pas réellement mesuré le périmètre.

Dans une pratique saine, on enlève d’abord les problèmes mécaniques grâce à l’automatisation. Ensuite seulement, la revue humaine se concentre sur le périmètre, la sécurité, la cohérence et le risque de changement. C’est cette séparation qui rend la revue IaC utile au lieu d’en faire un simple rituel de validation.

Ce que vous allez apprendre

comprendre ce qu’une bonne revue IaC doit vérifier ;
mettre les contrôles automatiques avant la relecture humaine ;
savoir relire un changement d’infrastructure sans se limiter à la syntaxe.

Un exemple simple de revue ratée

Une pull request ajoute une nouvelle VM, ouvre un flux réseau et modifie un rôle de configuration système. Si la revue se limite à regarder rapidement les fichiers, plusieurs problèmes peuvent passer: un changement de topologie trop large, un secret sorti au mauvais endroit, un plan de remplacement involontaire, ou un couplage flou entre création de ressource et configuration du système.

À l’inverse, si l’équipe laisse les outils vérifier le formatage, la syntaxe et les règles évidentes, la revue humaine peut se concentrer sur les vraies questions: qu’est-ce qui change, pourquoi, avec quel impact, et comment revient-on en arrière si besoin ?

Ce qu’il faut valider avant la revue humaine

La première couche de qualité doit être automatique.

Couche	Ce qu’elle vérifie	Exemple typique
Formatage	Cohérence de forme	`terraform fmt`, formatage YAML
Validation syntaxique	Syntaxe et cohérence interne	`terraform validate`
Lint	Bonnes pratiques et erreurs fréquentes	`ansible-lint`, hooks `pre-commit`
Analyse statique	Risques, règles, erreurs de sécurité	scanner IaC ou règles dédiées
Plan ou aperçu du changement	Impact attendu sur le réel	plan Terraform ou équivalent

Le principe est simple : la relecture humaine ne doit pas perdre du temps sur ce qu’un outil peut bloquer avant elle.

Le bon ordre de travail

Nettoyer les problèmes triviaux

Formatez le code, lancez les validations de base et corrigez les erreurs évidentes avant d’ouvrir la revue.
Produire une lecture claire du changement

Le diff doit montrer 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.
Examiner l’impact réel

Pour l’infrastructure déclarative, la lecture du plan est centrale. Pour la configuration, il faut comprendre quelles machines, quels services et quelles règles sont touchés.
Faire la revue humaine sur le fond

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

Ce que la revue humaine doit vraiment regarder

Quand les contrôles automatiques sont déjà passés, la revue gagne en qualité. Elle peut se concentrer sur les points suivants :

le périmètre du changement est-il clair ;
le dépôt ou l’outil concerné est-il le bon ;
le changement crée-t-il un risque de dérive ou de recouvrement avec un autre outil ;
le plan annonce-t-il des remplacements ou destructions inattendus ;
les variables, outputs, secrets et conventions restent-ils lisibles ;
la marche arrière ou la correction après incident reste-t-elle compréhensible.

Checklist de revue rapide

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 du changement est-il cohérent ?	Réduit les surprises à l’exécution
Un secret ou une donnée sensible apparaît-il dans le diff ?	Réduit le risque immédiat
Le changement est-il trop large 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

Exemples de commandes utiles avant revue

Le contenu exact dépend des outils, mais l’idée reste la même : préparer un changement propre avant validation humaine.

# Exemple côté Terraform
terraform fmt -check
terraform validate

# Exemple côté hooks locaux
pre-commit run --all-files

# Exemple côté Ansible
ansible-lint

Ces commandes ne remplacent pas la revue. Elles la rendent plus utile.

Les erreurs de revue les plus fréquentes

Relire uniquement la syntaxe

Quand une PR est approuvée parce que “ça a l’air propre”, sans lecture du périmètre ni du changement réel, la revue passe à côté de sa fonction principale.

Lancer la revue avant les contrôles automatiques

Si le reviewer doit signaler un mauvais formatage, une règle évidente de lint ou une validation oubliée, l’équipe gaspille son temps sur des points mécaniques.

Approuver des changements trop gros

Une PR qui modifie trop de zones à la fois devient difficile à comprendre. En IaC, ce problème est plus grave encore, car les effets sur l’infrastructure peuvent être larges.

Ce que cette page ne remplace pas

Ce guide pose la méthode transversale. Il ne remplace pas les guides plus spécifiques sur les outils de validation, de test ou d’analyse statique. Son rôle est de vous donner l’ordre logique entre ces briques.

À retenir

Une bonne revue IaC ne se limite pas à la syntaxe : elle vérifie aussi le périmètre, le risque et la cohérence du changement.
Les contrôles automatiques doivent passer avant la revue humaine.
Le reviewer doit se concentrer sur ce qu’un outil ne peut pas juger seul : responsabilité, impact, sécurité, lisibilité, risque opérationnel.
Une PR trop large se relit mal, surtout quand elle touche l’infrastructure.
Le but n’est pas de ralentir le changement, mais de rendre son impact compréhensible avant exécution.

Prochaines étapes

Tests et contrôles automatiques Continuez avec la couche qui complète la revue humaine par des tests, des lint et des garde-fous automatiques.

pre-commit : bloquer les erreurs avant qu'elles n'atteignent le dépôt Voyez comment décaler les contrôles triviaux au plus tôt, dès le poste du développeur.

Le workflow Terraform : init, plan, apply, destroy Approfondissez la lecture du plan et l'ordre logique des commandes côté Terraform.

Ansible-lint : valider et améliorer votre code Ansible Passez à un exemple concret de lint et de revue automatisée côté Ansible.