On verra pour la scalabilité plus tard.
Cette phrase m'a coûté 3 semaines de refonte en urgence sur un projet client.
Il y a 2 ans, un client me contacte en panique. Son application web PHP explose. 500 utilisateurs simultanés et tout rame. Le serveur pleure.
Le diagnostic :
- Requêtes SQL non optimisées (N+1 partout)
- Sessions stockées en fichiers
- Pas de cache applicatif
- Monolithe non découplé
- "On scale verticalement" = on paye plus de serveur
L'excuse initiale :
"On n'avait que 50 utilisateurs au début, on pensait avoir le temps."
Le temps ? Il est arrivé en 3 mois. Et là, c'était la panique.
Ce qu'on a dû faire en urgence :
- Migrer les sessions vers Redis
- Implémenter un cache sur les requêtes lourdes
- Réécrire 40% des requêtes Doctrine
- Découpler les jobs longs en asynchrone (Messenger)
Coût : 25k€ et 3 semaines de stress.
Ce qu'on aurait pu faire dès le départ :
- 🏗️ Architecture pensée pour le scale (2 jours de plus)
- 🗄️ Redis dès le début (configuration simple)
- 📊 Requêtes optimisées (bonnes pratiques de base)
- ⚡ Queue pour les tâches lourdes (emails, exports, etc.)
Coût : 3k€ de plus au démarrage.
La leçon ?
Scaler ne veut pas dire over-engineerer. C'est poser les bonnes fondations dès le départ. 🎯
Une application web bien architecturée dès le MVP, c'est :
- ✅ Moins de dette technique
- ✅ Coûts maîtrisés à la croissance
- ✅ Équipe sereine
Vous développez un MVP ou une nouvelle application ? Vous voulez éviter le mur de la scalabilité ?
👉 Contactez-moi. Je vous aide à poser une architecture qui tiendra la charge dès le premier jour.