« Encore en train d’attendre que Docker démarre ? » Cette phrase, devenue une private joke dans l’équipe, résume assez bien ce que représentait Colima au quotidien sur des projets WordPress conteneurisés volumineux : plusieurs images à reconstruire, des volumes montés lourds, et un temps de démarrage qui grignotait chaque matin quelques précieuses minutes avant de pouvoir commencer à travailler.
OrbStack, présenté comme une alternative légère à Docker Desktop sur macOS, promettait un démarrage plus rapide et une consommation mémoire réduite. Après plusieurs semaines d’usage réel sur les projets de l’équipe, voici ce qui a effectivement changé, et ce qui n’a pas bougé d’un pouce.
Le point de départ : pourquoi Colima frustrait l’équipe
Colima, machine virtuelle légère pilotée en ligne de commande, faisait le travail sans jamais vraiment convaincre sur les projets les plus lourds de l’équipe : plusieurs sites WordPress avec leurs bases de données, leurs services de cache et leurs outils de build JavaScript tournant simultanément. Le montage de fichiers entre macOS et la machine virtuelle Linux restait le point noir, avec des temps de réponse notables sur les projets aux nombreux fichiers, un problème classique de la virtualisation croisée entre systèmes de fichiers.
Ce qui a changé avec OrbStack
Le changement le plus immédiatement perceptible a été le temps de démarrage. Sur la machine de référence utilisée pour ce comparatif, un projet WordPress conteneurisé avec trois services (application, base de données, cache) démarrait en un peu moins d’une minute sous Colima, contre environ huit secondes sous OrbStack, une fois les images déjà construites localement.
- Le montage de fichiers entre macOS et les conteneurs répond de façon nettement plus fluide, perceptible dès qu’on édite un fichier PHP et qu’on observe le rechargement côté navigateur.
- La consommation mémoire au repos, mesurée sur les mêmes projets, a diminué de façon notable, ce qui a permis de faire tourner davantage de projets simultanément sans ralentir le reste de la machine.
- L’intégration réseau native simplifie l’accès aux conteneurs depuis le navigateur, sans configuration DNS locale supplémentaire à maintenir.
Un changement de commande, pas de configuration
La bascule elle-même s’est faite sans réécrire les fichiers docker-compose.yml existants : OrbStack se comporte comme un moteur Docker compatible, ce qui a limité l’effort de migration à l’installation de l’outil et à l’arrêt de Colima, sans modification du code des projets.
Ce qui n’a pas changé
Certains points restent identiques, et il serait malhonnête de les passer sous silence dans ce retour d’expérience :
- Le temps de construction initiale d’une image reste comparable entre les deux outils, la différence se jouant surtout au démarrage et à l’usage quotidien, pas à la première installation.
- Les projets les plus anciens de l’équipe, avec des
Dockerfilemal optimisés, restent tout aussi lents à reconstruire, indépendamment du moteur sous-jacent. - Aucun gain particulier n’a été observé sur les tests automatisés eux-mêmes, dont la durée dépend surtout du code testé, pas de l’infrastructure de conteneurisation.
Le cas des projets les plus volumineux
C’est sur les projets les plus lourds de l’équipe, ceux qui combinaient plusieurs sites WordPress dans un même environnement de développement partagé, que l’écart s’est révélé le plus marqué. Un environnement qui demandait presque une pause café pour redémarrer sous Colima redevient utilisable en quelques secondes, ce qui a changé concrètement la façon dont l’équipe redémarre ses environnements en cours de journée, sans plus hésiter à le faire par prudence après un changement de configuration.
Le gain de temps le plus précieux n’est pas celui qu’on mesure une fois, c’est celui qu’on ne remarque plus parce qu’on ne l’attend plus.
En résumé
Le passage de Colima à OrbStack a tenu ses promesses sur les points qui frustraient le plus l’équipe : démarrage, montage de fichiers et consommation mémoire. Ce retour d’expérience concerne des machines macOS ; il ne dit rien du développement sous Linux, où la question de la virtualisation ne se pose de toute façon pas dans les mêmes termes.
