Définition

La mise en production est l'opération qui rend accessible aux utilisateurs réels une version validée d'un site ou d'une application. Elle consiste à porter le code, les contenus et les données de l'environnement de préproduction vers l'environnement de production, puis à vérifier que le service fonctionne dans ses conditions réelles. On dit aussi mise en ligne, bascule, ou déploiement.

Le sigle MEP est courant dans les équipes techniques et désigne la même chose. La production, souvent abrégée en prod, est l'environnement où se trouvent les vrais clients et les vraies données ; c'est ce qui la distingue de la préproduction, sa copie de répétition.

Ce qu'une mise en production recouvre

Elle ne se limite pas à copier des fichiers. Sur une refonte, l'opération touche cinq objets différents, et chacun peut faire échouer la bascule.

  • Le code et la configuration. La version exacte qui a été recettée, avec les paramètres de production : clés d'API, adresses de messagerie, mode débogage désactivé.
  • Les contenus. La reprise des pages et des médias, souvent le poste le plus long et le plus sous-estimé du projet.
  • Les données. Comptes, commandes, historiques : leur migration se répète à blanc avant le jour J, jamais le jour même.
  • Le réseau et les accès. Nom de domaine, certificat, courriels sortants, sauvegardes actives.
  • Le référencement. Redirections, fichier robots, sitemap, et la levée de l'interdiction d'indexation qui protégeait la préproduction.

Les points de vigilance

Ce que je contrôle systématiquement, parce que ce sont les défauts qui partent réellement en ligne.

  • La balise noindex oubliée. La préproduction est bloquée à l'indexation pendant des mois. Si personne ne lève ce blocage à la bascule, le site disparaît des résultats de recherche sans qu'aucun voyant ne s'allume.
  • Les redirections non vérifiées en production. Une règle qui fonctionne en préproduction peut être ignorée par le serveur réel. Je reteste un échantillon d'anciennes URL après la bascule, pas seulement avant.
  • Les formulaires et les courriels sortants. Le message part-il, et surtout arrive-t-il ? Un formulaire muet ne déclenche aucune alerte : il perd des contacts en silence.
  • Le suivi d'audience. Un marqueur analytics resté en configuration de test rend la comparaison avant et après impossible, donc le bilan de la refonte indéfendable.
  • La sauvegarde de l'ancien. Avant de toucher à quoi que ce soit, je veux une sauvegarde complète et restaurable de l'existant, testée et non supposée.

Le plan de bascule et le retour arrière

Une mise en production se prépare comme un déménagement : une liste d'opérations ordonnée, un responsable par ligne, une heure estimée et un point de non-retour identifié. J'y ajoute deux choses que l'on oublie souvent. La première est le gel du contenu : personne ne modifie l'ancien site pendant la migration, sinon les mises à jour faites entre la copie et la bascule sont perdues. La seconde est la procédure de retour arrière, écrite à l'avance : qui décide de revenir en arrière, sur quel critère, et en combien de temps.

Je programme aussi la bascule à un moment où l'équipe est disponible pour surveiller les heures qui suivent. Un lancement le vendredi soir laisse le week-end aux incidents, sans personne pour les traiter. Le déroulé complet, avec ce qui précède et ce qui suit, figure dans mon guide sur les étapes d'une refonte.

Ce qui vient après

La mise en production n'est pas la fin du projet. Les jours qui suivent servent à surveiller les erreurs serveur, les pages introuvables et la couverture d'indexation, puis à traiter les réserves levées pendant le recettage. C'est aussi le moment où la responsabilité bascule vers un contrat de TMA ou vers l'équipe interne. Sur une refonte, la surveillance du référencement mérite une attention particulière, que j'ai détaillée dans mon guide pour refondre sans perdre son SEO.

Questions fréquentes

Le déploiement désigne l'acte technique de porter une version sur un environnement, quel qu'il soit. La mise en production est le déploiement particulier qui vise l'environnement des utilisateurs réels. On déploie plusieurs fois par jour en préproduction sans que cela concerne personne ; une mise en production, elle, se prépare et s'annonce.
C'est possible quand les anomalies restantes sont mineures et documentées comme réserves, avec une date de correction. Cela ne l'est pas quand un parcours essentiel est cassé : commande, contact, connexion. La règle que j'applique est simple, aucune anomalie qualifiée de bloquante ne passe en production, et cette qualification se décide avant la campagne, pas sous la pression du planning.
On applique la procédure de retour arrière prévue à l'avance : restauration de la sauvegarde, remise en service de l'ancienne version, information des utilisateurs. C'est pour cela qu'elle s'écrit avant la bascule, quand tout le monde est calme. Improviser un retour arrière au milieu d'un incident, avec une sauvegarde jamais testée, est la meilleure façon d'aggraver la panne.
Laurent Tulpan

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des bascules de sites et d'applications, et écrit toujours la procédure de retour arrière avant le jour J. Découvrir son approche.

À lire ensuite

Les étapes d'une refonte

Où se place la bascule dans le déroulé complet du projet.

Le plan de redirection 301

La pièce qui protège le trafic le jour de la mise en ligne.

Refondre sans perdre son SEO

Ce qu'il faut surveiller dans les semaines qui suivent la bascule.

Le recettage

L'étape de vérification qui autorise la mise en production.