La question arrive presque toujours de la même façon. Quelqu’un a lu que Docker était devenu le standard, ou un prestataire a proposé de « conteneuriser » l’existant, et la direction demande si les machines virtuelles sont dépassées.
La réponse tient en une phrase : les deux ne s’opposent pas, et dans la plupart des installations réelles ils cohabitent. Mais la vraie question, celle qui décide, n’est pas technique.
Ce que chacun résout réellement
Une machine virtuelle simule un ordinateur complet. Elle a son propre système d’exploitation, sa propre mémoire allouée, ses propres disques. Sur un serveur physique, l’hyperviseur en fait tourner plusieurs, étanches les unes aux autres. Si l’une plante, les autres ne le savent pas.
Ce qu’elle apporte : une isolation forte, la possibilité de faire tourner des systèmes différents côte à côte, et une opération que la plupart des équipes savent déjà mener. Sauvegarder une machine virtuelle, la déplacer, la restaurer sont des gestes connus et outillés depuis vingt ans.
Un conteneur ne simule pas un ordinateur. Il isole une application, avec ses dépendances, dans un système d’exploitation partagé avec les autres conteneurs. Il démarre en une seconde là où une machine virtuelle démarre en une minute, et il ne duplique pas un système par application.
Ce qu’il apporte : une application qui se déploie de façon identique partout, du poste du développeur à la production, parce que ce qui est livré inclut son environnement. C’est le vrai bénéfice, et il est important. Il ne concerne pas la consommation de ressources mais la reproductibilité.
Dans les faits, les conteneurs tournent presque toujours à l’intérieur de machines virtuelles. On ne remplace pas une couche par l’autre, on en ajoute une.
Ce qui change quand on ajoute cette couche
Trois gains réels, et il ne faut pas les minimiser.
Un déploiement qui cesse d’être artisanal. « Ça marche chez moi » disparaît comme catégorie de problème, parce que l’environnement voyage avec l’application. Sur une équipe qui livre souvent, c’est du temps récupéré chaque semaine.
Un retour arrière propre. Redéployer la version précédente devient une opération de quelques secondes, pas une restauration. Sur une mise en production qui tourne mal à 23h, cette différence est ce qui sépare une nuit blanche d’un incident de dix minutes.
Une reconstruction reproductible. Si le serveur brûle, ce qui doit être remonté est décrit dans des fichiers versionnés, pas dans la mémoire de celui qui l’avait installé.
Et trois coûts, qu’on présente moins souvent.
Une couche de plus à comprendre. Le réseau entre conteneurs, la persistance des données, la gestion des images. Ce sont des sujets, et ils s’ajoutent à ce que l’équipe doit déjà savoir.
Des sauvegardes à repenser. Un conteneur est jetable, ce qui est son intérêt, mais les données qu’il manipule ne le sont pas. Elles vivent dans des volumes, qui n’entrent pas dans la sauvegarde de machine virtuelle habituelle. Cette confusion produit des sauvegardes rassurantes et vides.
Un risque de dépendance à une personne. C’est le coût le plus sérieux et le moins évoqué. Une infrastructure conteneurisée mal documentée devient un assemblage que seul son auteur comprend.
Le critère qui tranche, et il n’est pas technique
Sur une PME de quinze à cent personnes, la question n’est pas « est-ce que c’est mieux ». Techniquement, sur la reproductibilité, oui. La question est : qui fera tourner ça dans deux ans.
Si vous avez une équipe technique interne qui livre régulièrement et sait déjà travailler avec ces outils, la conteneurisation est probablement rentable, et l’était déjà l’an dernier.
Si votre informatique repose sur une personne, ou sur un prestataire, et que la charge de travail est stable, ajouter cette couche ajoute un risque sans résoudre de problème que vous ayez. Une application qui tourne bien sur une machine virtuelle sauvegardée et testée n’a aucun besoin d’être déplacée.
Le test qui décide n’est pas une comparaison de performances. C’est celui-ci : si la personne qui met ça en place part dans six mois, qu’est-ce qui se passe ? S’il existe une documentation d’exploitation, des fichiers versionnés et quelqu’un d’autre capable de relire, la réponse est rien de grave. Sinon, vous venez d’échanger une contrainte connue contre une dépendance nouvelle.
Le cas de Kubernetes, à écarter tôt
La confusion la plus coûteuse du sujet consiste à croire qu’utiliser des conteneurs implique Kubernetes.
Kubernetes orchestre des conteneurs sur de nombreuses machines, en gérant automatiquement les pannes, la répartition de charge et la montée en échelle. C’est un outil remarquable pour le problème qu’il résout, et ce problème est celui d’organisations qui exploitent des dizaines de serveurs.
Sur une PME, on peut faire tourner des conteneurs sur une seule machine avec un fichier de composition, et cela couvre l’immense majorité des besoins. Adopter Kubernetes sans le problème d’échelle, c’est accepter une complexité d’exploitation permanente contre un bénéfice absent. Nous avons vu des installations où l’orchestrateur consommait plus de temps humain que toutes les applications qu’il hébergeait.
Ce qu’on recommande le plus souvent
Dans les faits, sur des missions de PME, la réponse la plus fréquente n’est ni l’un ni l’autre : c’est d’abord vérifier que les sauvegardes existantes se restaurent.
Ce n’est pas une pirouette. Sur les diagnostics qu’on mène, la question de la conteneurisation arrive presque toujours dans un contexte où la restauration n’a jamais été testée. Or une infrastructure moderne dont on ne peut pas récupérer les données est plus dangereuse qu’une infrastructure datée dont on peut les récupérer.
L’ordre utile est donc : restauration testée, puis supervision qui voit ce qui compte, puis modernisation. Inverser cet ordre est la façon la plus courante de dépenser de l’argent en ajoutant du risque.
Pour aller plus loin
- Virtualisation de serveurs en PME, où en est-on en 2026 : l’état du marché après le rachat de VMware
- Alternatives à VMware et migration d’hyperviseur : les quatre options crédibles et la séquence qui évite l’incident
- Sept pannes que la supervision classique ne voit pas : pourquoi les indicateurs verts ne prouvent rien
- Retour arrière d’une mise en production à 23h : le récit d’un repli qui a bien tourné
- Moderniser des outils legacy en PME : par quoi commencer, et dans quel ordre
- Cloud ou serveur dans vos murs : la couche en dessous, et son arbitrage