Il fut un temps où j’ai cru que Devilbox allait sauver mes projets PHP. Un outil tout-en-un, prêt à l’emploi, avec Apache, Nginx, MySQL, PHP, Redis, et tout le tintouin. Plus besoin de bidouiller des docker-compose.yml ou de maudire les permissions de fichiers. Juste docker-compose up, et hop : un environnement de développement clé en main. Sauf que, comme souvent avec les solutions magiques, la réalité a fini par me rattraper. Et cette réalité, c’est que configurer ses projets à la main, c’est souvent plus rapide, plus flexible, et surtout, moins chiant.
La promesse : tout est prêt, mais rien ne marche vraiment
Devilbox, c’est un peu comme ces meubles en kit suédois : sur le papier, c’est génial. Tu déballes la boîte, tu suis les instructions, et en théorie, tu as un truc qui ressemble à un bureau. Sauf que dans la pratique, il te manque toujours une vis, le mode d’emploi est écrit en hiéroglyphes, et au final, tu passes trois heures à essayer de faire tenir un pied qui refuse obstinément de s’emboîter. Avec Devilbox, c’est pareil : tu lances la stack, tout semble fonctionner… jusqu’à ce que tu réalises que ton Xdebug ne se connecte pas, que ton mailhog refuse de capturer tes emails, ou que ton php.ini est une version préhistorique que tu ne peux pas modifier sans tout casser.
Le pire ? Quand tu cherches une solution, tu tombes sur des issues GitHub vieilles de trois ans, des réponses du type « ça marche chez moi », ou des workarounds qui consistent à éditer des fichiers de config directement dans les conteneurs Docker. Autant dire que l’avantage de « tout est prêt » s’évapore dès que tu sors des sentiers battus. Et en développement, on sort toujours des sentiers battus.
La réalité : configurer à la main, c’est souvent plus simple
Un jour, j’en ai eu marre. J’ai supprimé Devilbox, j’ai ouvert un terminal, et j’ai écrit mon propre docker-compose.yml. Pas de magie, pas de surcouche, juste les services dont j’avais besoin :
version: '3.8'
services:
php:
image: php:8.2-fpm
volumes:
- ./:/var/www/html
environment:
- XDEBUG_CONFIG=client_host=host.docker.internal
networks:
- app-network
nginx:
image: nginx:latest
ports:
- "80:80"
volumes:
- ./:/var/www/html
- ./.docker/nginx:/etc/nginx/conf.d
depends_on:
- php
networks:
- app-network
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: app_db
volumes:
- mysql_data:/var/lib/mysql
networks:
- app-network
networks:
app-network:
driver: bridge
volumes:
mysql_data:
Résultat ? En 10 minutes, j’avais un environnement qui faisait exactement ce que je voulais. Pas de services inutiles, pas de configurations obscures, pas de dépendances cachées. Juste un docker-compose up -d, et c’était parti. Et si quelque chose ne marchait pas, je savais exactement où chercher : dans mon fichier, pas dans les entrailles d’un outil qui essaie de tout faire à ma place.
Le plus drôle, c’est que Devilbox se vend comme un gain de temps. Pourtant, entre les heures passées à debugguer ses problèmes, à chercher des solutions sur des forums, et à essayer de comprendre pourquoi ton php-fpm refuse de communiquer avec ton nginx, tu aurais déjà pu configurer trois projets à la main. Sans compter que quand tu maîtrises ta stack, tu peux l’adapter à tes besoins réels, pas à ceux que l’outil a décidés pour toi.
Pourquoi les outils « tout-en-un » séduisent (et déçoivent)
Il y a une raison pour laquelle les outils comme Devilbox, Laragon, ou même MAMP ont du succès : ils flattent notre paresse. « Plus besoin de réfléchir, on s’occupe de tout pour toi ! » Sauf que le développement, ce n’est pas de la paresse, c’est de la précision. Et un outil qui essaie de tout faire finit souvent par ne rien faire bien.
Prenez les environnements de développement pré-packagés : ils sont parfaits pour les débutants, ou pour ceux qui veulent un truc qui marche sans se poser de questions. Mais dès que tu commences à avoir des besoins un peu spécifiques – un module PHP particulier, une version de MySQL qui n’est pas celle par défaut, une configuration réseau un peu exotique – tu te retrouves à lutter contre l’outil au lieu de l’utiliser. Et là, le gain de temps initial se transforme en perte de temps chronique.
Autre problème : ces outils vieillissent mal. Devilbox, par exemple, utilise des images Docker qui ne sont pas toujours à jour. Tu veux du PHP 8.3 ? Bonne chance. Tu veux une version récente de Redis ? Il va falloir bidouiller. Alors qu’avec une configuration manuelle, tu contrôles tout, et tu peux mettre à jour tes images quand tu veux, sans attendre que quelqu’un d’autre le fasse pour toi.
Quand Devilbox (ou ses équivalents) peut encore servir
Bon, je ne vais pas faire semblant : il y a des cas où Devilbox peut être utile. Si tu débutes en PHP et que tu veux un environnement qui marche sans te prendre la tête, c’est une bonne solution. Si tu dois bosser sur plusieurs projets avec des stacks différentes (PHP 5.6 pour un legacy, PHP 8.2 pour un nouveau projet), ça peut dépanner. Et si tu n’as vraiment pas envie de toucher à Docker, c’est toujours mieux que WAMP ou XAMPP.
Mais dès que tu commences à avoir des besoins un peu avancés, ou que tu veux optimiser ton workflow, tu vas te heurter aux limites de l’outil. Et là, tu auras deux choix : soit tu passes des heures à essayer de le faire marcher comme tu veux, soit tu jettes l’éponge et tu fais les choses à ta manière et cette deuxième option est presque toujours la meilleure...
Au final, Devilbox, c’est comme ces régimes miracles : ça promet monts et merveilles, mais au bout du compte, tu réalises que la solution la plus simple était sous ton nez depuis le début. Configurer ses projets à la main, c’est un peu comme cuisiner soi-même au lieu d’acheter des plats préparés : c’est un peu plus long au début, mais au moins, tu sais ce qu’il y a dedans, et tu peux ajuster les ingrédients à ton goût. Et surtout, tu n’as pas à subir les caprices d’un outil qui a décidé que la moutarde, c’était obligatoire.
Alors oui, Devilbox est génial… jusqu’à ce qu’il ne le soit plus. Et quand ce jour arrive, tu te rends compte que tu as perdu plus de temps à essayer de le faire marcher qu’à apprendre à faire les choses toi-même. Moralité : parfois, la solution la plus rapide, c’est de ne pas chercher de raccourci.