« Passer en conteneurs va accélérer notre site » : cette affirmation revient régulièrement dans les discussions d’équipe, sans toujours reposer sur une mesure réelle. Ce billet ne prend pas parti pour ou contre la conteneurisation, mais présente des chiffres comparatifs mesurés sur un même projet WordPress, exécuté d’abord en accès direct sur un serveur, puis dans un conteneur Docker configuré de manière équivalente.
Le protocole de mesure retenu
La même installation WordPress, avec le même thème, les mêmes extensions et le même jeu de données, a été exécutée dans deux configurations : une installation classique directement sur le système du serveur, et une installation conteneurisée avec Docker, en attribuant au conteneur les mêmes ressources de processeur et de mémoire que celles disponibles nativement sur le serveur de comparaison. Le temps de réponse a été mesuré sur un échantillon de pages représentatives, avec et sans cache actif.
Ce que les chiffres montrent réellement
| Configuration | Temps de réponse moyen, page en cache | Temps de réponse moyen, page générée |
|---|---|---|
| Installation directe sur le serveur | 48 ms | 210 ms |
| Installation conteneurisée, ressources équivalentes | 49 ms | 214 ms |
L’écart mesuré entre les deux configurations reste inférieur à deux pour cent, une différence qui se situe dans la marge de variation naturelle d’une mesure à l’autre sur un même environnement. La conteneurisation n’a donc apporté, sur ce protocole précis, aucun gain de vitesse mesurable par rapport à une installation directe équivalente en ressources.
Pourquoi cette croyance persiste malgré ces chiffres
La confusion vient souvent d’un amalgame entre deux bénéfices distincts de la conteneurisation. Le premier, réel et documenté, concerne la reproductibilité : un conteneur garantit qu’une configuration identique s’exécute de la même manière sur le poste local, en intégration continue et en production, éliminant une catégorie entière de bugs liés à des divergences d’environnement. Le second, souvent supposé à tort, concerne la performance brute, que la conteneurisation n’améliore pas par elle-même : elle ajoute même, en toute rigueur, une fine couche de virtualisation légère qui consomme des ressources supplémentaires, généralement négligeables mais jamais nulles.
- La reproductibilité d’un environnement conteneurisé constitue le bénéfice réel et mesurable de cette approche.
- La performance brute dépend des ressources allouées et de la configuration logicielle, pas du mécanisme de conteneurisation en lui-même.
- Une mauvaise configuration de conteneur, par exemple des limites de mémoire trop restrictives, peut au contraire dégrader les temps de réponse par rapport à une installation directe.
Quand la conteneurisation dégrade réellement la performance
Sur un second test, mené avec des limites de mémoire volontairement sous-dimensionnées sur le conteneur, le temps de réponse des pages générées dynamiquement a plus que doublé, du fait d’un recours fréquent à la mémoire d’échange. Ce résultat illustre que la conteneurisation n’est ni intrinsèquement plus rapide, ni intrinsèquement plus lente : le résultat dépend entièrement des ressources réellement allouées et de leur adéquation avec le besoin réel du projet.
La conteneurisation garantit qu’on reproduit fidèlement une configuration, pas qu’on l’accélère.
Ce qui mérite réellement d’être mesuré avant de décider
Plutôt que de chercher un gain de vitesse hypothétique, les questions à se poser avant de conteneuriser un projet portent sur des bénéfices opérationnels concrets : combien de temps une mise en place d’environnement local prend-elle aujourd’hui à une nouvelle recrue, combien d’incidents récents proviennent d’une divergence entre les environnements de développement et de production, quelle part du temps d’équipe est consacrée à résoudre des problèmes de configuration plutôt qu’à développer des fonctionnalités. Ce sont ces chiffres-là, et non un hypothétique gain de vitesse, qui justifient ou non un investissement dans la conteneurisation d’un projet existant.
Notre verdict
Attendre un gain de vitesse de la seule conteneurisation d’un projet WordPress revient à se tromper d’argument. Le bénéfice réel réside dans la reproductibilité de l’environnement entre les différentes étapes d’un projet, pas dans une accélération qu’aucune mesure sérieuse ne confirme à configuration égale. Décider de conteneuriser un projet doit donc reposer sur ce critère de reproductibilité, pas sur une promesse de performance qui ne se vérifie pas.
