Les tests appliqués à l’infra

Cela fait bien une dizaine d'années maintenant que le monde de l’ops a… bien changé . Avec l’essor de l’Infrastructure as Code, nous avons adopté des pratiques venues du développement, comme versionner notre code, faire des revues, automatiser les déploiements, mettre en place des pipelines CI/CD… L’infra que l’on connaît aujourd’hui est plus industrielle et plus collaborative.

Mais en travaillant récemment avec des développeurs sur un projet client, j’ai eu une prise de conscience. Il nous manque encore une brique essentielle. Chez les devs, il y a des tests. Qu’ils soient unitaires, d’intégration ou end-to-end, ils font partie de leur quotidien. Impossible d’imaginer livrer une nouvelle fonctionnalité sans une suite de tests pour garantir que rien n’est cassé.

Alors pourquoi côté Ops, ne fait-on pas la même chose ? Pourquoi la pratique des tests n’a-t-elle pas suivi le même chemin que le versionning ou l’automatisation ? Est-ce culturel, parce qu’on n’a jamais appris à faire autrement ? Est-ce trop coûteux, car tester l’infra suppose souvent de la déployer ? Ou bien est-ce qu’on se persuade que « si ça se déploie, c’est que ça marche » ?

Cette question m’a interpellé et je suis convaincu qu’il est temps d’y répondre. Car si nous voulons réellement « ramener les bonnes pratiques du développement à l’infrastructure », il faut aller jusqu’au bout, apprendre nous aussi, à tester.

Les tests dans le monde du dev, une évidence ?

Dans l’univers du développement logiciel, les tests ne sont pas une option. Tout développeur sait qu’écrire du code sans tests revient à sauter d’un avion sans parachute (un peu vénère comme métaphore mais j’ai rien d’autre la tout de suite mdr). Les tests permettent de détecter rapidement les erreurs, de valider le comportement attendu et surtout d’éviter les régressions quand une nouvelle fonctionnalité est ajoutée ou après un refactor.

On distingue généralement plusieurs niveaux de tests.

Il y a les tests unitaires, qui vérifient une fonctionnalité ou une règle métier isolée.

Les tests d’intégration, qui valident que les briques métiers fonctionnent bien avec l’infrastructure.

Les tests end-to-end (E2E), qui simulent un scénario complet du point de vue de l’utilisateur, du début à la fin.

Cette pyramide de tests est devenue un standard. Dans beaucoup d’équipes, elle est même intégrée directement dans la chaîne de livraison continue (CI/CD). Un commit déclenche automatiquement l’exécution des tests : si l’un d’eux échoue, le code ne peut pas être livré (normalement).

Avec tout ça, les développeurs bénéficient d' une boucle de feedback très courte. Ils savent rapidement si une modification casse quelque chose. Et je pense que ça leur permet d’avancer plus vite, avec plus de confiance et d’essayer des approches quand on est dans le doute. Tout ce qu’il faut pour maximiser la réussite d’un projet finalement.

Mais côté ops, ce réflexe est encore loin d’être acquis… et c’est là que le contraste devient intéressant.

Pourquoi les tests sont absents côté Ops ?

Quand on regarde du côté des Ops, la pratique des tests est loin d’être systématique (voir inexistante). Contrairement aux développeurs, nous n’avons pas grandi avec cette pratique. Plusieurs raisons peuvent expliquer ce décalage.

D’abord, il y a une histoire de culture, même si elle varie beaucoup d’une entreprise à l’autre. Certaines équipes ont mis en place depuis longtemps des tests de résilience, de performance, de charge… souvent rédigés par des architectes et exécutés par les Ops. Mais dans la majorité des environnements que j’ai pu croiser, ces pratiques restent l’exception plutôt que la règle. J’ai l’impression qu'historiquement, le rôle de l’Ops s’est surtout concentré sur la disponibilité et la stabilité des systèmes. On configurait, on surveillait, on intervenait en cas d’incident. La notion de « tester systématiquement » ce que l’on mettait en place n’était pas généralisée, contrairement à ce qu’on trouve côté développement.

Ensuite, je vois une contrainte technique et économique. Tester une application ne coûte « que » du temps, du CPU et de la mémoire. Tester une infra, c’est bien plus lourd. Il faut déployer de vrais composants (réseaux, machines virtuelles, bases de données, load balancers…), donc payer la facture associée. Cela représente du temps, de l’argent.

Mais ce n’est pas tout, au fils des projets sur lesquels j’ai pu travailler, j’ai remarqué qu’Il y avait aussi une illusion de confiance. On se dit que si le déploiement passe, c’est que l’infra est bonne. Mais en réalité, “réussir à déployer” ne veut pas dire que le système répond à nos attentes fonctionnelles ou qu’il est sécurisé. Combien de fois a-t-on découvert en production qu’un port était resté ouvert, qu’une règle IAM donnait trop de permissions, ou qu’un service ne répondait pas au bon endpoint ?

Enfin, il y a un manque de sensibilisation certain. Dans la formation et la culture Ops, la notion de tests automatisés n’est presque jamais abordée. On apprend à écrire du Bash, du Terraform ou de l’Ansible, mais rarement à se demander “comment être sûr que je n’apporterai pas de régressions aux prochains changements de mon code ? ”

Les tests sont souvent perçus comme un “truc” réservé aux développeurs. Et c’est précisément cette vision qu’il faut faire évoluer.

Changer de paradigme ?

Si nous voulons réellement professionnaliser et fiabiliser nos pratiques d’infrastructure, il est temps d’intégrer les tests dans notre quotidien d’Ops.

Sans tests, une erreur de configuration ou une mauvaise règle de sécurité n’est souvent découverte qu’en production, parfois dans l’urgence. Alors qu’avec des tests automatisés, on peut détecter ces problèmes bien plus tôt, dès le déploiement sur un environnement éphémère par exemple.

Aujourd’hui il faut voir l’infra, comme un composant de l’application. Elle évolue sans cesse, que ce soit par une  mise à jour d’un module Terraform, l’ajout d’une ressource, le changement de version d’un providers… Chaque modification comporte un risque. Les tests automatisés servent de garde-fou. Ils vont garantir que ce qui fonctionnait hier fonctionne encore aujourd’hui.

De plus, les architectures deviennent de plus en plus grandes, de plus en plus complexes, les équipes Ops ne peuvent plus se permettre de « tester à la main ». La charge cognitive est trop grande. Automatiser les tests devient non seulement une bonne pratique, mais une nécessité pour assurer la fiabilité de l’infra.

Au-delà de l’aspect purement technique, adopter les tests côté Ops, c’est aussi faciliter la collaboration avec les devs. On partage les mêmes pratiques, on intègre nos tests dans la CI/CD et on renforce la culture DevOps. 

Comment tester l’infra ?

On pourrait croire que tester l’infrastructure est quelque chose de complexe. Pourtant, il existe déjà des outils et approches qui permettent d’apporter de la rigueur. L’idée n’est pas de tout tester d’un coup, mais d’adopter une démarche progressive, en commençant par les bases puis en allant vers des tests plus aboutis.

Pour moi, le plus simple à mettre en place, c’est l’utilisation d'outils tels que Terraform validate, tflint, kube-linter ou ansible-lint. Ils permettent de vérifier la syntaxe, la cohérence et le respect de bonnes pratiques sans avoir besoin de déployer quoi que ce soit. Ces tests sont rapides, peu coûteux et déjà très efficaces pour éviter les erreurs de typo, de mauvaise ressource, de champ manquant… Mais ça on le voit assez régulièrement, c’est déjà plus ou moins adopté.

Ok, deuxième étape, tester nos briques d’infra de manière isolée. Pour ça, les blocks terraform test permettent de déployer un module ou une stack réduite, puis de vérifier son comportement. Par exemple, on va pouvoir s’assurer qu’un bucket S3 est bien créé avec la bonne politique de chiffrement, ou qu’un security group n’ouvre pas de port inutile. On peut aussi compléter cette approche avec du SAST (par exemple Checkov, tfsec ou SonarQube) afin de detecter des failles de sécurité directement dans le code et sans déploiement. Dans une logique de gouvernance on peut aussi parler d’outils de Policy as Code comme OPA ou Kyverno qui permettent de vérifier automatiquement que l’infrastructure respecte les règles définies par l’organisation.

Troisième et dernière étape, tester l’infra dans son ensemble. On déploie un environnement temporaire puis on lance une suite de tests qui valident le comportement attendu. ça peut être de vérifier qu’un load balancer répond bien sur le port 443 avec un certificat valide, tester qu’une base de données est uniquement accessible depuis le réseau interne… Et pour aller encore plus loin, certaines équipes utilisent aussi des pratiques de chaos engineering pour s’assurer que l’infrastructure reste résiliente face à des pannes ou des dégradations simulées.

Le vrai changement de culture vient quand ces tests sont directement spécifiés dans le “definition of done” et intégrés dans le pipeline de déploiement. Chaque merge sur une branche “protected” (par exemple) ou chaque nouvelle release déclenche :

1. Le linting
2. Le déploiement d’un environnement éphémère
3. L’exécution des tests unitaires et E2E
4. La destruction de l’environnement + la vérification que les ressources sont totalement détruites

Les tests deviennent automatique et systématique, au même titre que pour les applications.

Les défis à relever ?

Mettre en place la culture du test dans le monde de l’infrastructure est important mais vous savez ce que l’on dit, “c’est plus facile à dire qu’à faire”. J’ai identifié plusieurs points qui peuvent freiner son adoption.

Déployer une application de test est relativement léger (de ce que j’ai pu voir sur différents projets). Déployer une infrastructure de test peut coûter cher, ça nécessite de bien dimensionner les environnements éphémères et de penser à leur destruction automatiquement à la fin des tests pour éviter les mauvaises surprises sur la facture à la fin du mois (si c’est déployé sur le cloud, en on-prem on peut avoir des problèmes de ressources disponible).

Pour lancer une suite de tests E2E sur l’infra, il faut orchestrer le déploiement, l’exécution des tests, la validation des résultats puis la destruction. Tout cela doit s’intégrer dans un pipeline existant, ce qui demande parfois une bonne dose d’ingénierie.

Beaucoup d’Ops ne voient pas encore les tests comme une partie intégrante de leur métier (moi le premier, mais j’essaye de changer promis!).  De ce que j’ai pu voir ces dernières années, la culture reste très “déploiement et exploitation”, et moins “validation”. Cela demande un travail d’acculturation, de formation et de pédagogie pour convaincre que l’investissement est rentable.

Beaucoup d’équipes ont déjà une infra conséquente, parfois même hétérogène, avec du legacy difficile à automatiser. Introduire des tests sur une telle archi peut sembler difficile. La solution est d’y aller progressivement, commencer par les nouvelles briques, puis élargir à l’existant au fil du temps.

Conclusion

Ne pas tester, c’est accepter de découvrir les problèmes en production. Et parfois dans la douleur. Tester, c’est au contraire se donner les moyens de réduire la boucle de feedback, de prévenir les régressions et d’aborder chaque changement avec confiance.

Alors, par où commencer ? Inutile de viser la perfection dès le départ (Mentalité Kaizen comme dirait un célèbre youtuber). Commencez par mettre en place du linting si ce n’est pas déjà fait. Ajoutez quelques tests unitaires sur vos modules Terraform par exemple et intégrez progressivement des scénarios end-to-end dans vos pipelines.
Une autre question à se poser est, “Quelle est la criticité de l’application ou du service ?”. Les besoins en tests ne seront pas les mêmes selon que l’on déploie un environnement de dev ou de prod. Définir des SLI (Services Level Indicators) et des SLO (Service Level Objectives) aide à cadrer le niveau de test attendu. Plus le service est critique, plus la couverture et la rigueur des tests doivent être fortes.