Les problèmes qui peuvent être générés par une mise en production un vendredi après-midi:

• Tests négligés: En mettant en ligne sous la contrainte du temps, vous n'avez surement pas fait des tests complets de vos développements, ceci aura pour conséquence qu'il y a de grands risques de bugs.
• Mise en prod mal planifiée: En agissant sous la pression du temps, vous allez brûler quelques étapes et votre mise en production va mal se passer, ça va monopoliser votre temps et vous faire travailler sous le stress d'un éventuel problème.
• Indisponibilité: En prenant le risque de mettre en production un vendredi, ou la veille d'un jour férié, votre équipe sera indisponible les jours suivants pour intervenir en cas de problèmes, or nous savons tous que le risque zéro n'existe pas lors d'une mise en production.

Ce qui vous a poussé à cette mauvaise pratique:

• Le client le veut, ou veut tester pendant le week-end: Le client est pressé, impatient, il veut voir votre travail, mais là où le bât blesse, c'est qu'en faisant une mauvaise mise en production, le client va être stressé et va vous stresser pendant tout le reste du projet. Sa confiance va se réduire et vous allez en payer les conséquences.
• Des retards dans le projet: Nous savons tous que les retards de projet sont mal vécus par les clients, mais imaginez maintenant que vous allez vous précipiter à mettre en production sans faire des tests approfondis, le client sera alors doublement déçu, retards dans le projet + travail mal fini.
• Vendredi après-midi c'est la même chose que le lundi matin: Il n'y a aucune différence entre le vendredi 17h et le Lundi 10h, autant alors repousser la mise en production à Lundi matin (ou mardi matin), vous aurez alors tout le week-end de bien vérifier votre travail et éventuellement faire les derniers correctifs lundi matin. Le client sera déçu par ce décalage, mais en lui livrant un travail plus maîtrisé, il oubliera rapidement les quelques heures de décalage.

Les contres arguments:

Certains avis de spécialistes s’élèvent ces derniers temps pour dénoncer cette recommandation, accusant les auteurs d'amateurisme, car en effet des solutions existent:

• Des outils de déploiement existent, qui permettent de faire un "rollback" rapide (retour en arrière) en cas de problème.
• Il faut mettre en place un processus de mise en production, composé de plusieurs étapes sur plusieurs serveurs: Un serveur interne à l'agence, puis un serveur de pré-production, puis le serveur de production, puis la mise en production doit suivre les étapes définies avec dans chaque étape des tests.
• Et surtout: Tester, tester, tester et TESTER sérieusement le travail effectué, tests unitaires, test fonctionnel, le travail doit être testé de fond en comble pour chaque ligne de code modifiée.

Mais au final, il évident de comprendre que le risque zéro n'existe pas, toute modification sur un site représente un risque, et seul le chef de projet a la capacité de peser entre les bénéfices et les risques. Le but est de minimiser les risques et d'essayer de s'isoler de la pression du client.

En résumé, c'est une question de rapport en Bénéfices et Risques:

Il n'est pas du tout interdit de mettre en production un vendredi à 17h, certains sites ecommerce font 10 mises en production par jour sans que génère de problèmes, mais pour arriver à ce stade il faut que vous soyez équipé en terme de compétences et en terme de processus de mise en production.

Une grande partie des agences ne sont pas équipées d'un processus de mise en production, soit par manque d'expérience soit simplement que le problème n'a pas été réfléchis, ou à cause d'une mauvaise organisation, pourtant des solutions existent.

Pour tous les autres, évitez simplement de mettre en production la veille d'un jour chômé, ça vous évitera beaucoup de stress, et vous aurez plus de temps pour réfléchir à comment procéder pour améliorer votre processus de mise en production.

Pour finir, expliquer au client tout ceci le rassurera sur le fait que vous maîtrisez votre travail et pourra comprendre plus facilement les reports de mise en production.

BLOG COMMENTS POWERED BY DISQUS