Contexte et fonctions du plan review

Dans les pipelines d’infrastructure as code, le plan review consiste à faire lire un diff à un humain qui décide d’approuver ou non. Cette action remplissait quatre fonctions distinctes : conformité aux politiques, estimation du blast radius, vérification de l’intention et production d’une trace d’audit. Aucun composant n’a été conçu pour regrouper ces tâches ; elles se sont accumulées après une panne et un audit, puis ont été codées dans le fichier de workflow.

Saturation et perte d’efficacité

Le volume de changements a explosé. Un agent peut ouvrir 40 pull‑requests avant le déjeuner. Les réviseurs approuvent rapidement pour vider la file, mais le workflow indique toujours que l’approbation bloque le merge et génère un événement d’audit. Le contrôle devient alors indistinguable d’un contrôle fonctionnel. Deux effets majeurs apparaissent : le code généré ne fournit plus de référence visuelle, ce qui empêche la reconnaissance humaine des anomalies, et le temps de latence passe de deux jours dans le pipeline à 90 secondes via la console. Les changements qui empruntent le chemin console échappent à toute planification, révision ou enregistrement, réduisant la couverture de gouvernance.

Réorientation des contrôles vers l’automatisation

Pour restaurer la fiabilité, l’article propose de déplacer la vérification de conformité dans l’exécution du plan. Le moteur de politique compare le plan proposé à un jeu de règles et rejette immédiatement les ressources critiques (IAM, réseau, données). Les ressources non critiques sont auto‑approuvées. Cette approche diminue la charge des réviseurs, qui ne sont sollicités que pour les cas explicitement routés vers une personne. Le blast radius, auparavant estimé, est remplacé par des contraintes : TTL pour les environnements expérimentaux, plafonds budgétaires, restriction des types de ressources et isolation dans des comptes non‑production. Ainsi, la protection repose sur des limites techniques plutôt que sur une prédiction humaine.

Gestion des agents et audit renforcé

Lorsque le changement provient d’un agent, aucune intention humaine n’est capturée. La solution consiste à exiger un identité d’agent limitée, à appliquer les mêmes règles de politique et à enregistrer l’agent comme acteur dans le journal. Le journal d’audit doit être produit par le moteur de politique : il indique la règle exécutée, les entrées, la décision et le timestamp. Cette trace remplace la preuve d’attention humaine. En complément, la détection de dérive planifiée (drift) doit mesurer le temps moyen de réparation (MTTR) plutôt que le simple nombre d’incidents, afin de refléter la rapidité de correction.