Introduction

La mise en production est une étape stratégique mais aussi à haut risque, surtout lorsqu’elle est bâclée ou improvisée. Pour un freelance DevOps ou un développeur en mission, une erreur peut entraîner des pannes critiques, des pertes de données ou un client mécontent.

Voici une checklist complète des erreurs à éviter, avec des rappels essentiels sur la sauvegarde, la communication, la supervision et la relance des services.

1. Ne pas faire de sauvegarde avant la mise en production

Erreur critique : déployer sans avoir effectué une sauvegarde complète du système existant.

• Ce qu’il faut faire :

  • Sauvegarder la base de données

  • Sauvegarder les fichiers de configuration, code source, assets

  • Conserver la sauvegarde hors du serveur (cloud ou stockage externe)

Astuce : horodater et versionner la sauvegarde. Elle doit permettre un retour arrière (rollback) immédiat.

2. Ne pas prévoir de plan de retour arrière

Même si tout semble prêt, un plan de rollback est obligatoire.

• Erreur fréquente : « Ça ne va pas planter, donc je ne prévois pas de retour »

• Ce qu’il faut faire :

  • Définir le scénario de restauration (base, fichiers, accès)

  • Tester ce scénario dans un environnement de préproduction

  • Rédiger une procédure de rollback partagée avec l’équipe

3. Ne pas prévenir les équipes concernées par mail ou Slack

Une mise en production sans communication claire, c’est comme couper le courant sans prévenir les voisins.

• Avant le déploiement :

  • Informer les métiers, support, IT (heure prévue, durée estimée, fonctionnalités concernées)

  • Spécifier s’il y aura interruption de service

• Après le déploiement :

  • Envoyer un message de fin de mise en prod + tests validés

  • Joindre le changelog si nécessaire

Modèle de mail type :
Objet : Mise en production prévue lundi 14h – Durée 30 min – Impact : Portail client indisponible pendant l’opération.

4. Laisser la supervision active pendant la mise en production

Grosse erreur : ne pas désactiver les alertes de supervision (Zabbix, Grafana, Centreon, etc.)

• Conséquences :

  • Faux positifs dans les alertes (CPU haut, redémarrage service)

  • Notifications automatiques envoyées à tort aux équipes ou aux clients

• Ce qu’il faut faire :

  • Désactiver temporairement les alertes liées à l’application ou au service concerné

  • Les réactiver uniquement après vérification complète

5. Ne pas tester après le déploiement

Ne jamais supposer que « tout s’est bien passé » simplement parce que le site fonctionne.

• Tests à effectuer après mise en production :

  • Connexion utilisateur

  • Navigation, formulaires, paiement

  • Accès back-office ou admin

  • Logs, erreurs serveur, intégrations externes

Astuce : avoir une checklist de validation post-déploiement avec des cases à cocher.

6. Oublier de redémarrer la supervision

Après avoir désactivé la surveillance pendant la mise en production, il faut penser à la réactiver.

• Ce qu’il faut faire :

  • Relancer les sondes, relier les métriques

  • Tester manuellement un cas d’alerte pour s'assurer que tout est bien en place

7. Ne pas documenter la mise en production

Beaucoup de freelances ou techs n’enregistrent pas ce qu’ils ont fait.

• Erreur : personne ne sait ce qui a été déployé, ni comment

• Ce qu’il faut faire :

  • Rédiger une fiche de mise en production (date, version, auteur, procédures suivies)

  • L’intégrer dans la documentation projet (Notion, Confluence, Google Docs…)

Checklist complète à suivre pour chaque mise en production

Conclusion

La mise en production n’est pas seulement une action technique. C’est un processus structuré qui demande de la rigueur, de l’anticipation et de la communication.

En tant que freelance, vous devez montrer que vous maîtrisez cette étape de bout en bout, car c’est souvent à ce moment-là que la qualité de votre travail est réellement mesurée.