Pourquoi vos changements d'infrastructure nécessitent la même discipline que les changements de code

Imaginez ceci : quelqu'un dans votre équipe doit ouvrir un port pour un nouveau service. Il se connecte à la console cloud, ajoute une règle de pare-feu, et passe à autre chose. Cinq minutes plus tard, l'ensemble de l'application de production devient inaccessible. La nouvelle règle a accidentellement bloqué le trafic vers la base de données. Personne ne sait ce qui a changé, qui a fait la modification, ni comment revenir en arrière rapidement.

Ce scénario est plus courant que la plupart des équipes ne l'admettent. Les changements d'infrastructure — règles de pare-feu, configurations d'équilibreur de charge, politiques de stockage, paramètres réseau — n'arrivent pas tous les jours. Mais quand ils tournent mal, ils mettent tout par terre. Un seul groupe de sécurité mal configuré peut rendre votre application invisible pour les utilisateurs. Un seul changement DNS erroné peut rediriger le trafic vers nulle part.

Le problème est que de nombreuses équipes traitent les changements d'infrastructure différemment des changements de code applicatif. Les changements de code passent par des pull requests, des revues de code, des tests automatisés et des déploiements progressifs. Les changements d'infrastructure se font souvent via un accès direct à la console, des commandes ad-hoc ou des identifiants partagés. L'écart de discipline crée un angle mort qui finit par provoquer une panne.

L'infrastructure en tant que code est la fondation, pas la solution

L'Infrastructure as Code (IaC) signifie que vous écrivez votre configuration d'infrastructure dans des fichiers, les stockez dans un dépôt et les appliquez via l'automatisation. Des outils comme Terraform, Pulumi ou AWS CDK rendent cela possible. Mais avoir des fichiers IaC dans un dépôt ne suffit pas. La discipline vient de la manière dont vous gérez les modifications de ces fichiers.

Si quelqu'un peut pousser un changement sur la branche principale et le voir appliqué en production sans revue, vous avez le même problème que le scénario de la console cloud. L'outil vous donne la répétabilité, mais pas la sécurité. La sécurité vient du processus.

Un modèle pour les changements d'infrastructure

Chaque changement d'infrastructure doit suivre une séquence reproductible. Cette séquence fonctionne quel que soit l'outil IaC que vous utilisez. Elle protège votre équipe des schémas de défaillance les plus courants.

Le diagramme suivant illustre la séquence recommandée et les points de décision :

flowchart TD A[Commencer par un changement de code] --> B[Exécuter le plan] B --> C{Revue du plan} C -- Approuvé --> D[Tester en non-production] C -- Rejeté --> A D --> E{Tests OK ?} E -- Oui --> F[Appliquer via le pipeline] E -- Non --> A F --> G[Vérifier après application] G --> H{Vérification OK ?} H -- Oui --> I[Changement terminé] H -- Non --> J[Exécuter le plan de rollback] J --> A

Commencer par un changement de code

Chaque changement d'infrastructure doit commencer par une pull request vers votre dépôt d'infrastructure. Aucune exception. Personne ne doit modifier l'infrastructure de production directement via une console cloud, une commande CLI sur un serveur ou un script manuel.

La pull request montre exactement ce qui a changé : une nouvelle ressource, une configuration réseau modifiée, un bucket de stockage supprimé. Les membres de l'équipe peuvent examiner le diff, poser des questions et repérer les problèmes avant que quoi que ce soit ne s'exécute. Exigez au moins un relecteur qui comprend l'impact du changement. Pour les infrastructures critiques comme le réseau ou les groupes de sécurité, envisagez d'exiger deux relecteurs.

Exécuter un plan avant d'appliquer

Les outils IaC peuvent vous montrer ce qui va changer sans effectuer réellement le changement. Terraform appelle cela un plan. Pulumi l'appelle un aperçu. Le concept est le même : l'outil compare votre configuration à l'état actuel et liste chaque ressource qui sera créée, modifiée ou détruite.

Exécutez ce plan dans le cadre de votre processus de pull request. Sauvegardez la sortie et joignez-la à la PR. Les relecteurs doivent vérifier les changements inattendus : une ressource est-elle supprimée alors qu'elle ne devrait pas l'être ? Un changement est-il appliqué au mauvais environnement ? Si le plan montre quelque chose de surprenant, arrêtez-vous et enquêtez avant de continuer.

Par exemple, un plan Terraform pour un changement de groupe de sécurité pourrait ressembler à ceci :

Terraform will perform the following actions:

  # aws_security_group_rule.app_ingress will be updated in-place
  ~ resource "aws_security_group_rule" "app_ingress" {
        id                     = "sgrule-1234567890"
      ~ from_port              = 8080 -> 8443
        protocol               = "tcp"
      ~ to_port                = 8080 -> 8443
        type                   = "ingress"
        # (5 unchanged attributes hidden)
    }

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

Cette sortie montre exactement quelle règle va changer et comment, permettant aux relecteurs de détecter les erreurs avant que le changement ne soit appliqué.

Tester d'abord dans un environnement non-production

Appliquez le changement à un environnement de staging ou de développement avant la production. Si vous n'avez pas d'environnement d'infrastructure de staging complet, créez une réplique plus petite qui reflète les parties critiques de la production. Certaines équipes utilisent un compte ou un projet d'infrastructure séparé spécifiquement pour tester les changements.

Si un environnement de staging est absolument impossible, exécutez au moins le plan contre la production en mode lecture seule. Cela vous donne une visibilité sur ce qui changerait sans rien modifier réellement.

Appliquer via un pipeline, pas depuis un ordinateur portable

La commande d'application réelle doit s'exécuter dans un pipeline CI/CD, pas sur la machine d'un développeur. Le pipeline enregistre qui a déclenché l'application, quand cela s'est produit et ce qui a changé. Cette piste d'audit est essentielle pour le débogage et la conformité.

Le pipeline doit s'arrêter immédiatement si l'application échoue en cours de route. Ne le laissez pas continuer à appliquer des changements à d'autres ressources après un échec. Les changements d'infrastructure partiels sont difficiles à diagnostiquer et encore plus difficiles à corriger.

Avoir un plan de rollback

Avant d'appliquer, sachez comment vous reviendrez en arrière si quelque chose tourne mal. Pour une infrastructure immuable, cela signifie détruire les nouvelles ressources et recréer les anciennes à partir d'un état précédent. Pour une infrastructure mutable, prenez un instantané ou une sauvegarde de la configuration avant d'apporter des modifications.

Stockez vos fichiers d'état d'infrastructure dans un backend versionné. Certaines équipes conservent le dernier fichier d'état valide connu afin de pouvoir le restaurer rapidement. Le plan de rollback doit être documenté et testé, pas inventé en plein milieu d'un incident.

Vérifier après l'application

Ne présumez pas que tout va bien simplement parce que l'application s'est terminée sans erreur. Vérifiez que les nouvelles ressources fonctionnent. Testez que les connexions réseau fonctionnent. Confirmez que les applications dépendant de l'infrastructure sont toujours saines.

Automatisez cette vérification autant que possible. Un simple script qui vérifie l'état des ressources, ping des points de terminaison ou exécute des tests de connectivité peut détecter des problèmes que la commande d'application ne signale pas.

Une checklist pratique pour les changements d'infrastructure

  • Le changement commence par une pull request dans le dépôt d'infrastructure
  • Au moins un relecteur qui comprend l'impact a approuvé la PR
  • La sortie du plan a été examinée et correspond aux attentes
  • Le changement a d'abord été appliqué à un environnement non-production
  • L'application s'exécute via un pipeline, pas depuis une machine locale
  • Le plan de rollback est documenté et prêt
  • Les vérifications de validation passent après l'application

Cette checklist n'est pas de la bureaucratie. C'est une protection contre le type de panne qui commence par un simple clic dans une console cloud et se termine par une équipe qui se démène pour comprendre ce qui s'est passé.

L'essentiel à retenir

Les changements d'infrastructure sont des opérations à haut risque et à faible fréquence. Cette combinaison les rend dangereux. Quand vous faites quelque chose rarement, vous êtes plus susceptible de faire des erreurs. Quand l'impact est large, ces erreurs font plus mal.

Traitez les changements d'infrastructure avec la même rigueur que les changements de code applicatif. Les pull requests, les revues, les plans, les environnements intermédiaires, l'exécution via pipeline et la vérification ne sont pas des options supplémentaires. Ce sont les processus minimaux pour maintenir votre infrastructure stable. L'outil que vous utilisez importe moins que la discipline que vous appliquez.