Infrastructure PHP/Symfony : quelle configuration selon votre MRR ?

L'une des erreurs les plus courantes chez les fondateurs de SaaS est de traiter les décisions d'infrastructure comme des décisions purement techniques. Or, chaque euro dépensé en serveurs est un euro qui ne va pas au développement produit ou à l'acquisition client. À l'inverse, sous-investir trop longtemps, c'est risquer de perdre vos clients durement acquis lors d'une panne sous charge.

Cet article propose une checklist concrète, palier par palier, pour adapter votre infrastructure PHP/Symfony à votre niveau de revenus — avec les indicateurs qui déclenchent une montée en gamme et les outils recommandés à chaque étape.

💡 Article inspiré de From Idea to $10K MRR: Infrastructure Decisions at Every Revenue Milestone publié sur DEV.to par Deploynix, adapté ici dans une perspective PHP/Symfony.

🚀 Palier 1 — $0 MRR : l'idée

Objectif : shipper vite, dépenser le moins possible.

À ce stade, vous êtes seul ou avec quelques bêta-testeurs. Votre infrastructure doit être quasi gratuite et suffisamment professionnelle pour partager une URL.

Configuration recommandée :

• Serveur unique : 2 Go RAM, 1 vCPU (Hetzner CX22 ou Vultr Cloud Compute)
• Base de données : MySQL sur le même serveur
• Cache : cache fichier natif Symfony (cache.adapter.filesystem), pas de Redis
• SSL : Let's Encrypt via Caddy ou Traefik (automatique)
• Backups : dump MySQL quotidien vers Wasabi S3 (~0,006 $/Go)

Stack Symfony minimale :

# .env
APP_ENV=prod
DATABASE_URL=mysql://user:pass@127.0.0.1:3306/app
CACHE_ADAPTER=cache.adapter.filesystem

Un simple cron avec mysqldump et rclone vers Wasabi suffit pour les backups. Le coût total mensuel à ce stade : moins de 10 €.

📈 Palier 2 — $1K à $3K MRR : les premiers clients payants

Objectif : fiabilité de base, monitoring, séparation des services.

Vous avez des clients qui paient. Les pannes ont désormais un coût réel : remboursements, churn, perte de confiance. Il est temps de séparer base de données et application, et de mettre en place un monitoring minimal.

Indicateurs qui déclenchent la montée en gamme :

• CPU moyen > 60 % en heures creuses
• Temps de réponse médian > 400 ms
• Plus de 5 erreurs 5xx par heure

Configuration recommandée :

• App server : 4 Go RAM, 2 vCPU
• Base de données : instance dédiée MySQL 4 Go (ou managed DB Hetzner/PlanetScale)
• Cache : Redis pour les sessions et le cache Symfony
• Monitoring : UptimeRobot (gratuit) + Sentry pour les erreurs PHP
• Backups : backup automatisé vers Wasabi avec rétention 7 jours

Ajout Redis dans Symfony :

# config/packages/cache.yaml
framework:
    cache:
        app: cache.adapter.redis
        default_redis_provider: '%env(REDIS_URL)%'

# Vérifier la latence Redis
redis-cli --latency -h 127.0.0.1

Coût mensuel estimé : 30 à 60 € selon le provider.

⚡ Palier 3 — $3K à $10K MRR : la croissance

Objectif : scalabilité horizontale, haute disponibilité, observabilité.

Vous avez une traction réelle. Votre SaaS génère du trafic prévisible mais aussi des pics (newsletters, Product Hunt, campagnes). Une panne de 30 minutes représente désormais un manque à gagner significatif et un risque réputationnel sérieux.

Indicateurs qui déclenchent la montée en gamme :

• Pics CPU > 80 % lors de pics de trafic
• RPS (requêtes/sec) > 50 en pointe
• Temps de réponse p95 > 800 ms
• Croissance MoM > 20 %

Configuration recommandée :

• Load balancer : HAProxy ou load balancer managé (Hetzner LB)
• 2 app servers minimum en active/active
• Base de données managée : avec réplica en lecture (MySQL managed Hetzner, PlanetScale, ou AWS RDS)
• Redis : instance dédiée ou Redis Cloud (clustering si besoin)
• Queue Symfony Messenger : workers dédiés pour les tâches asynchrones
• Stockage fichiers : S3-compatible (Wasabi, Scaleway Object Storage)
• Monitoring avancé : Grafana + Prometheus ou Datadog, alertes Slack

Exemple de configuration Messenger avec workers supervisés :

# config/packages/messenger.yaml
framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    auto_setup: false
        routing:
            'App\\Message\\EmailNotification': async

; /etc/supervisor/conf.d/messenger.conf
[program:symfony-messenger]
command=php /var/www/app/bin/console messenger:consume async --limit=500
numprocs=2
autostart=true
autorestart=true

Commandes de diagnostic essentielles :

# Surveiller les requêtes lentes MySQL
mysqladmin -u root -p processlist

# Analyser les logs Nginx pour le RPS
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | sort | uniq -c

# Vérifier l'utilisation mémoire PHP-FPM
php-fpm -t && systemctl status php8.2-fpm

Coût mensuel estimé : 150 à 400 € selon les choix de providers.

✅ Conclusion : ne construisez pas pour un futur hypothétique

La règle d'or en infrastructure SaaS : votre architecture doit refléter votre MRR actuel, pas celui que vous espérez dans 18 mois. Chaque palier décrit ici représente un équilibre entre coût, fiabilité et complexité opérationnelle.

Les transitions entre paliers ne doivent pas être déclenchées par l'intuition, mais par des métriques mesurables : CPU, latence, taux d'erreur, croissance MoM. Instrumentez votre application dès le premier palier avec Sentry et un monitoring HTTP basique — cela vous donnera les données nécessaires pour décider quand évoluer, pas seulement comment.

Chez MulerTech, nous accompagnons les équipes PHP/Symfony dans ces transitions d'architecture, de l'audit de performances à la mise en place d'infrastructures Docker scalables. N'hésitez pas à nous contacter si vous êtes à un palier charnière.