Déploiement Laravel en production : la checklist essentielle pour TPE/PME

Mettre une application Laravel en production reste un moment stressant, même pour les équipes expérimentées. Un oubli sur les variables d'environnement, un backup mal configuré ou l'absence de healthcheck peuvent transformer un lancement en incident critique. Cet article s'inspire de la checklist publiée par Deploynix — distillée de centaines de déploiements réels — et la priorise pour les contextes TPE/PME : ressources humaines limitées, tolérance aux erreurs faible, pas toujours d'équipe ops dédiée.

L'objectif n'est pas d'appliquer 50 points le jour J, mais d'automatiser les vérifications critiques en CI pour que le go-live soit serein.

1. Variables d'environnement et secrets : zéro tolérance

C'est la source numéro un d'incidents au lancement. Une APP_KEY manquante, un APP_ENV resté à local ou une DATABASE_URL qui pointe sur la base de staging : ces erreurs arrivent, et leurs conséquences vont de l'exposition de données à l'application complètement cassée.

Ce qu'il faut vérifier avant chaque déploiement :

• APP_ENV=production et APP_DEBUG=false sont explicitement définis
• APP_KEY est présent et unique par environnement
• Aucune valeur sensible n'est versionnée dans le dépôt (audit .gitignore + git log --all -- .env)
• Les connexions base de données, cache et queue pointent sur les bons services

Comment l'automatiser en CI :

# Exemple GitHub Actions — vérification des variables critiques
- name: Vérification des variables d'environnement
  run: |
    php artisan config:cache
    [ "$APP_ENV" = "production" ] || (echo "APP_ENV incorrect" && exit 1)
    [ -n "$APP_KEY" ] || (echo "APP_KEY manquante" && exit 1)

Ajoutez une commande artisan custom (app:check-env) qui valide la présence et le format de chaque variable attendue. Elle devient un step obligatoire dans votre pipeline.

2. Backups et stratégie de rollback

Un déploiement sans plan de retour arrière n'est pas un déploiement, c'est un pari. Pour une TPE/PME, perdre la base de données ou ne pas pouvoir revenir à la version précédente peut avoir des conséquences directes sur l'activité.

Backups :

• Automatisez les snapshots de base de données avant chaque déploiement (pas seulement en cron nocturne)
• Testez la restauration régulièrement — un backup non testé n'existe pas
• Stockez les backups hors du serveur applicatif (S3, Backblaze, ou même un NAS distant)

Rollback :

Avec Laravel et un déploiement par symlink (Deployer, Envoyer), le rollback applicatif se fait en quelques secondes. La partie délicate, c'est la base de données.

# Exemple avec Deployer
dep rollback production

# Rollback migration Laravel (si la migration est réversible)
php artisan migrate:rollback --step=1

Règle pratique : si une migration n'est pas réversible proprement, c'est un signal d'alarme. Documentez explicitement les migrations destructives et prévoyez un dump avant leur exécution.

3. Smoke tests automatisés et healthchecks

Un smoke test, c'est la vérification minimale que l'application répond correctement après déploiement. Ce n'est pas une suite de tests complète — c'est un filet de sécurité rapide.

Healthcheck HTTP :

Exposez un endpoint /healthcheck qui vérifie les dépendances critiques :

// routes/web.php
Route::get('/healthcheck', function () {
    $checks = [
        'database' => DB::connection()->getPdo() !== null,
        'cache'    => Cache::store()->put('hc', true, 10),
        'queue'    => Queue::size() !== null,
    ];

    $status = collect($checks)->every(fn($v) => $v) ? 200 : 503;

    return response()->json($checks, $status);
});

Cet endpoint est appelé par votre load balancer, votre outil de monitoring, et en step final de votre pipeline CI avant de router le trafic.

Smoke tests post-déploiement :

# Step CI après déploiement
- name: Smoke tests
  run: |
    curl -f https://monapp.fr/healthcheck || exit 1
    curl -f https://monapp.fr/login || exit 1
    # Ajouter les pages critiques métier

Si l'un de ces appels échoue, le pipeline déclenche automatiquement le rollback.

4. Monitoring minimal et plan de communication incident

Beaucoup de TPE/PME sautent cette étape par manque de temps, et le constatent au pire moment. Un monitoring minimal ne nécessite pas d'infrastructure complexe.

Stack monitoring légère :

• Uptime : UptimeRobot (gratuit) ou Better Uptime — alerte SMS/email si l'app ne répond plus
• Erreurs : Sentry (tier gratuit suffisant pour débuter) branché sur le handler d'exceptions Laravel
• Logs : centralisez avec Laravel Log + un canal Slack ou Discord pour les erreurs critical et emergency

// config/logging.php — canal Slack pour les erreurs critiques
'slack' => [
    'driver'   => 'slack',
    'url'      => env('LOG_SLACK_WEBHOOK_URL'),
    'username' => 'Laravel Production',
    'level'    => 'critical',
],

Plan de communication incident :

Définissez avant le lancement — pas pendant la panne — qui fait quoi :

Même pour une équipe de 2 personnes, avoir ce tableau affiché quelque part évite la panique et les doublons d'action sous pression.

Conclusion

La mise en production n'est pas la fin du travail, c'est le début de la responsabilité opérationnelle. Pour les TPE/PME, l'enjeu est de maximiser la fiabilité avec des ressources limitées. Les quatre piliers couverts ici — variables d'environnement, backups/rollback, smoke tests et monitoring — forment le socle minimum non négociable.

L'approche pragmatique : intégrez ces vérifications dans votre pipeline CI dès maintenant, même imparfaitement. Un check automatisé qui passe à 80% vaut mieux qu'une checklist manuelle oubliée le jour J.

Pour aller plus loin, la checklist complète des 50 points de Deploynix est une excellente référence pour les équipes qui veulent couvrir l'intégralité des aspects (sécurité TLS, optimisation des assets, configuration PHP-FPM, scaling, etc.).