L'automatisation des tests : un pilier de la livraison continue
Introduction
Automatiser les tests ne se résume pas à exécuter pytest dans un pipeline. C'est construire un système de confiance qui permet de déployer sereinement plusieurs fois par jour. En tant que SRE et DevOps, j'ai souvent été celui qui disait "stop, on n'a pas de tests" avant de lancer un déploiement. Voici ce que j'ai appris en construisant des systèmes de tests automatisés pour des contextes aussi variés que la MedTech, la défense et le e-commerce.
Les tests d'infrastructure : le parent pauvre
Quand on parle de tests automatisés, on pense immédiatement aux tests applicatifs. Mais les tests d'infrastructure sont tout aussi critiques. Chez F2R2, avec 25 modules Terraform pour l'architecture AWS multi-comptes, chaque module avait ses tests : terraform validate et terraform plan sur chaque PR, puis des tests d'intégration Terratest qui vérifiaient que les ressources créées correspondaient aux spécifications. Un test vérifiait par exemple que les Security Groups n'ouvraient pas de ports non autorisés, qu'un WAF était bien configuré devant chaque ALB, et que GuardDuty était activé sur chaque compte. Ces tests d'infrastructure ont détecté des erreurs de configuration qui auraient créé des failles de sécurité en production.
Les tests de performance intégrés au pipeline
Chez Cardiologs, une MedTech qui analysait des électrocardiogrammes, la performance était une exigence fonctionnelle : un traitement ne pouvait pas dépasser 3 secondes. J'ai intégré des tests de performance directement dans le pipeline Jenkins. À chaque PR, un benchmark automatique comparait les temps de traitement avec la version précédente. Si une régression de plus de 10% était détectée, le pipeline échouait. Ces tests tournaient dans des conteneurs Docker avec des ressources limitées (CPU et mémoire identiques à la production) pour garantir des résultats comparables. Cette approche a prévenu au moins 5 régressions de performance en 6 mois sur un service critique pour des patients.
Les smoke tests post-déploiement
Un aspect que j'intègre systématiquement : les smoke tests après chaque déploiement. Chez Bloomflow, après qu'ArgoCD déployait une nouvelle version, un job Kubernetes se lançait automatiquement et exécutait une série de vérifications : l'API répond-elle en moins de 500ms ? Le healthcheck retourne-t-il 200 ? Les endpoints critiques fonctionnent-ils ? Les métriques Prometheus sont-elles émises ? Si un smoke test échouait, ArgoCD rollbackait automatiquement. Ce mécanisme a rattrapé des situations que les tests en CI n'avaient pas couvertes : un certificat TLS expiré, un secret Vault non renouvelé, une migration de base de données qui avait timeout en production mais pas en staging.
La gestion des données de test
Les données de test sont un casse-tête récurrent. Chez Coopengo, les tests d'intégration nécessitaient des données médicales anonymisées conformes HDS. J'ai mis en place un générateur de données qui produisait des jeux de données réalistes mais entièrement fictifs, versionnés dans le repository. Chaque pipeline recréait la base de données à partir de ces fixtures, garantissant l'isolation entre les exécutions. Le script de génération utilisait Faker avec des profils médicaux personnalisés. Pour les tests de charge, les données étaient amplifiées par un facteur 100 pour simuler des volumes de production. Cette approche a résolu les conflits de données qui causaient des faux positifs dans 15% des exécutions précédentes.
La culture du test : convaincre les équipes
Le plus grand défi n'est pas technique mais humain. Chez SFR Business Team, quand j'ai commencé à pousser l'automatisation des tests, certains développeurs voyaient cela comme une surcharge. La clé a été de montrer les bénéfices concrets : le temps gagné en debug, les week-ends non interrompus par des incidents. J'ai instauré une règle simple : chaque bug corrigé doit être accompagné d'un test qui le reproduit. En 6 mois, la suite de tests est passée de 50 à 300 tests, et le nombre d'incidents en production a chuté de 60%. La culture du test ne s'impose pas par décret, elle se construit par la preuve.
Conclusion
L'automatisation des tests dépasse largement le cadre applicatif : infrastructure, performance, sécurité, smoke tests post-déploiement. Chaque couche de test ajoute un filet de sécurité. Mon approche pragmatique : commencer par les tests qui ont le plus d'impact (ceux qui préviennent les incidents les plus coûteux), automatiser leur exécution dans le pipeline, et étendre progressivement la couverture. Un test qui ne s'exécute pas automatiquement est un test qui sera oublié.