Livrer : recette, mise en production et réversibilité
La fin d'un projet est le moment où l'on est le plus pressé et le moins vigilant. C'est aussi celui qui décide de ce que le client gardera en mémoire. Ce mémo découpe cette fin en gestes précis, dont le plus important est le seul qu'on ne fait presque jamais : prévoir le retour en arrière.
Avant d'appliquer ce mémo
Les manipulations décrites ici peuvent entraîner une perte de données ou l'indisponibilité d'un service. Avant d'en appliquer une seule : faites une sauvegarde complète et vérifiez qu'elle se restaure, travaillez d'abord sur un environnement sans enjeu, et n'exécutez aucune commande dont vous ne comprenez pas l'effet.
Ce mémo est un contenu pédagogique de portée générale. Il ne tient pas compte de votre situation, n'a pas valeur de conseil professionnel, et son application relève de votre seule responsabilité. Avertissement et limites d'usage
1. Livrer n'est pas mettre en ligne Trois moments qu'on confond, et ce que ça coûte
Dans la plupart des projets, la fin est vécue comme un seul événement : « on met en ligne ». C'est en réalité trois moments distincts, avec trois responsables différents, et les confondre est la cause principale des fins de projet qui s'enlisent.
vous
Vous remettez quelque chose de testé, sur un environnement de test
le client
Il vérifie que ça correspond à ce qui était prévu
vous, après son accord
Le public y accède
! Ce qui se passe quand on les mélange
On met en ligne d'abord, et le client « regardera après ». Trois conséquences, chaque fois les mêmes :
- Le public voit un site en cours de correction, ce qui abîme l'image que le projet devait servir.
- La recette ne finit jamais, parce que rien ne la déclenche ni ne la clôt : les remarques arrivent au fil de l'eau, pendant des mois.
- Le solde de la facture n'est jamais dû, puisqu'il n'y a jamais eu de moment officiel où le travail a été accepté.
Le troisième point est le plus douloureux, et il découle entièrement des deux premiers.
test.monsite.com, protégé par un mot de passe et interdit aux moteurs de recherche. La plupart des hébergements mutualisés permettent de le créer en trois clics, sans supplément. C'est la brique la plus rentable de toute la fin de projet.2. Le plan de test Écrit avant de construire, pas après
Un plan de test est la liste de ce qu'on vérifiera, écrite au moment du cadrage, quand on sait encore exactement ce qu'on a promis. Écrit à la fin, il ne contient que ce dont on se souvient, c'est-à-dire ce qu'on a bien fait.
1 La forme, en trois colonnes
Une ligne par vérification, et rien de plus élaboré :
| Je fais | J'attends | Résultat |
|---|---|---|
| J'envoie le formulaire sans remplir l'e-mail | Un message d'erreur clair, mes autres réponses conservées | |
| J'envoie le formulaire correctement | Confirmation à l'écran, et un courriel reçu par le client | |
| J'ouvre l'accueil sur mon téléphone | Le menu s'ouvre, le numéro est cliquable | |
| Je publie une actualité depuis l'administration | Elle apparaît sur le site sans autre manipulation |
Ce qu'on n'oublie pas d'y mettre
- Les cas d'erreur : champ vide, fichier trop lourd, mauvais format. C'est là que les sites cassent.
- Le téléphone, avec un vrai appareil : une fenêtre rétrécie montre que la mise en page est responsive, elle ne dit rien du doigt qui rate un bouton trop petit.
- Les courriels envoyés par le site, reçus dans une vraie boîte, et pas dans les indésirables.
- Les parcours d'administration, faits par le client lui-même.
- Les anciennes adresses, s'il y a un site à remplacer.
3. Cadrer la recette pour qu'elle se termine Le problème n'est pas de la lancer
La recette est le moment où le client vérifie. Livrée sans cadre, elle s'étire indéfiniment : il regarde quand il a le temps, envoie trois remarques le mardi, deux le mois suivant, et le projet n'est jamais fini. Ce n'est pas de la mauvaise volonté, c'est un manque de cadre.
1 Les cinq éléments d'une recette qui finit
- Une date de début et une date de fin. Une à deux semaines selon la taille. Annoncées au cadrage, rappelées à la livraison.
- Un nom. Une personne désignée qui centralise les remarques. Sans cela, vous recevez trois listes contradictoires.
- Un canal unique. Le tableau de la section 2, ou un document partagé. Pas de remarques par téléphone, par message et par courriel en même temps.
- Un format. Une remarque = une ligne = une page + ce que j'ai fait + ce que j'attendais + ce que j'ai obtenu. Une capture d'écran vaut dix lignes de description.
- Ce qui se passe à la fin. « Sans retour au terme de la période, la recette est réputée acceptée. » Cette phrase figure dans le devis, elle est annoncée d'avance, et elle est parfaitement usuelle.
Accompagner, plutôt que d'envoyer un lien
Beaucoup de clients ne savent pas comment recetter, et n'osent pas le dire. Une visioconférence de trente minutes où vous déroulez le plan de test avec eux change tout : ils comprennent ce qu'on attend d'eux, et les remarques qui arrivent ensuite sont utilisables.
C'est un investissement, pas une politesse. Il fait gagner plusieurs jours.
Le piège de la recette silencieuse
Un client qui ne répond rien n'est pas satisfait : il est occupé, ou intimidé par l'exercice. Le silence se traite par un appel, pas par une relance écrite de plus.
S'il persiste, appliquez la clause d'acceptation tacite, mais prévenez avant qu'elle joue, jamais après. Une acceptation obtenue par surprise se paie en confiance perdue, et la confiance vaut plus que ce solde de facture.
4. Bug, anomalie ou évolution La distinction qui sauve la fin du projet
Pendant la recette, tout arrive mélangé. Trier chaque remarque en trois catégories, dès sa réception, évite la conversation pénible où l'on découvre à la fin que « corriger » recouvrait aussi « ajouter ».
| Catégorie | Définition | Qui paie | Exemple |
|---|---|---|---|
| Défaut | Ce qui était prévu ne fonctionne pas. | Vous | Le formulaire n'envoie pas de courriel. |
| Écart | Cela fonctionne, mais pas comme décrit au cadrage. | Vous | Trois champs au lieu des cinq prévus. |
| Évolution | Cela fonctionne comme prévu, et le client veut autre chose. | Avenant | « Finalement, il faudrait aussi un champ pour la surface. » |
! Comment le dire sans braquer personne
Le tri se fait à la réception, et il s'annonce simplement : « Les points 1, 3 et 4 sont pour moi, je les corrige d'ici jeudi. Le point 2 est un ajout, ce n'était pas dans le périmètre : c'est faisable, environ une demi-journée. Je vous fais un avenant, ou on le garde pour la suite ? »
Ce qui rend cette phrase acceptable, c'est qu'elle arrive tout de suite et qu'elle commence par ce que vous prenez à votre charge. Le même message envoyé trois semaines plus tard, après avoir laissé croire que tout était inclus, passe très mal, et à juste titre.
5. La checklist avant de basculer À cocher, pas à lire
1 Technique
- Le certificat SSL est en place et le cadenas s'affiche sur toutes les pages
- Une seule adresse canonique, l'autre redirige
- Les anciennes adresses sont redirigées une à une vers leur équivalent
- L'environnement de test est bien interdit aux moteurs, la production bien autorisée
- Le plan du site est déposé et la console de recherche configurée
- Une sauvegarde complète existe et a été restaurée une fois pour de vrai
- Les messages d'erreur techniques ne s'affichent plus aux visiteurs
- Les accès de test et les comptes de démonstration sont supprimés
2 Contenu et conformité
- Aucun texte de remplissage ni image d'exemple ne subsiste
- Les mentions légales et l'information sur les données collectées sont en place
- La bannière de consentement, s'il y a des mesures d'audience concernées
- Les coordonnées sont justes, partout, y compris dans le pied de page
- Les liens sortants fonctionnent, les liens internes aussi
- Le formulaire arrive dans une boîte que quelqu'un relève
- Les images ont un texte alternatif et ne pèsent pas trois mégaoctets
6. Le retour arrière La seule question qui compte vraiment
Ne mettez jamais en production sans savoir comment revenir en arrière.
Cette question se pose avant la bascule, à froid, avec tout le temps de réfléchir. Posée pendant l'incident, à 18 h, avec un client au téléphone, elle ne trouve pas de bonne réponse.
1 Les trois questions, à écrire
- Comment je remets l'ancien site en ligne ? En combien de temps, avec quelle commande, à partir de quelle copie ?
- Qu'est-ce que je perds en revenant ? Les commandes passées depuis la bascule, les messages reçus, les comptes créés.
- Jusqu'à quand le retour est-il possible ? Passé un certain volume de données nouvelles, revenir devient plus coûteux que corriger.
Ce qu'il faut avoir sous la main
- Une copie complète de l'ancien site, fichiers et base, téléchargée chez vous
- L'ancien hébergement laissé en place au moins deux semaines, sans rien résilier
- Les valeurs DNS d'avant, notées, pour pouvoir les remettre telles quelles
- Un TTL bas, posé la veille, qui rend le retour rapide
Ces quatre points coûtent une demi-heure et quelques euros d'hébergement en double. C'est l'assurance la moins chère du métier.
7. La bascule Quand, qui, et ce qu'on annonce
Quand
Un mardi ou un mercredi matin. Jamais un vendredi, jamais la veille d'un pont, jamais à 18 h.
La règle tient en une phrase : basculez quand vous et l'hébergeur êtes disponibles pendant les six heures qui suivent.
Qui
Une personne aux commandes, une autre qui vérifie. Si vous êtes seul, la liste de contrôle joue le rôle de la seconde personne : on la coche, on ne la lit pas de mémoire.
Le client est prévenu et joignable, même s'il n'a rien à faire.
Ce qu'on annonce
Au client, la veille : ce qui va se passer, à quelle heure, ce qu'il pourrait voir d'inhabituel, et à qui écrire.
Prévenez qu'une messagerie ou un site peut se comporter bizarrement quelques heures : annoncé, c'est normal ; découvert, c'est une panne.
1 Les vérifications dans l'heure qui suit
- La page d'accueil, une page profonde, une image, depuis une connexion extérieure au réseau où vous travaillez
- Le cadenas de sécurité, et une adresse en
httpqui bascule bien enhttps - Le formulaire, envoyé pour de vrai, et le courriel reçu pour de vrai
- Un courriel envoyé vers une adresse du domaine, s'il y a une messagerie
- Trois anciennes adresses, prises au hasard dans la liste des redirections
- Le site sur un téléphone, avec les données mobiles et non le wifi du bureau
8. Le lendemain Surveiller les bons signaux, à zéro euro
La semaine qui suit une mise en production est celle où les problèmes réels apparaissent : ceux que la recette n'a pas vus parce qu'ils demandent du vrai trafic, du vrai contenu et de vrais utilisateurs.
1 Les cinq signaux à regarder
- Les erreurs 404 dans la console de recherche : elles révèlent les redirections oubliées.
- Le journal d'erreurs du serveur, le document le plus honnête de tout l'hébergement.
- Les formulaires reçus : zéro message en trois jours sur un site qui en recevait, c'est une panne, pas une accalmie.
- Le temps de réponse des pages principales.
- L'indexation : le nombre de pages connues des moteurs, qui doit remonter et non s'effondrer.
La surveillance qui ne coûte rien
Trois briques gratuites suffisent pour un site de TPE :
- La console de recherche du moteur, gratuite, qui alerte par courriel sur les erreurs et la couverture
- Un service de surveillance de disponibilité en offre gratuite, qui prévient si le site ne répond plus
- Une alerte d'expiration du certificat et du nom de domaine, posée dans votre agenda
Les offres payantes apportent de la finesse, pas la détection. Pour un site vitrine, la version gratuite couvre l'essentiel de ce qui peut mal tourner.
9. La garantie Un début, une fin, et un contenu
« Garantie incluse » ne veut rien dire tant qu'on n'a pas écrit ces trois choses. Sans elles, le client comprend « support à vie », et vous comprenez « corrections des bugs de livraison ». Les deux sont de bonne foi, et le désaccord est garanti.
1 Ce qu'elle couvre
- Les défauts et les écarts au sens de la section 4
- Ce qui cesse de fonctionner sans que personne y ait touché
- Une durée : trente à quatre-vingt-dix jours après la mise en production, selon la taille
2 Ce qu'elle ne couvre pas, et qu'il faut écrire
- Les évolutions et les nouvelles demandes
- Ce que le client a modifié lui-même depuis son administration
- Les mises à jour du CMS, des extensions et du serveur
- Les pannes de l'hébergeur ou d'un service tiers
- La formation et l'assistance à l'usage
10. Rendre les clés La réversibilité, et pourquoi elle vous sert aussi
La réversibilité, c'est la capacité du client à reprendre son projet sans vous, ou à le confier à quelqu'un d'autre. Beaucoup de prestataires la redoutent. C'est un mauvais calcul : ce qui retient un client, c'est la qualité du travail, pas l'impossibilité de partir. Et un client qui se sait libre recommande beaucoup plus volontiers.
1 Ce que le client doit avoir en main à la fin
- Le nom de domaine à son nom, sur son compte, avec ses identifiants
- L'hébergement à son nom, ou clairement identifié comme fourni par vous et refacturé
- Les accès d'administration du site, avec un compte administrateur qui lui appartient
- Le code source, si le contrat en prévoit la cession, et le dépôt qui va avec
- Les comptes tiers créés pour lui : statistiques, console de recherche, service d'envoi de courriels
- Une sauvegarde complète, fichiers et base, à un endroit qu'il maîtrise
- La documentation de la section 11
Comment transmettre les accès
Pas par courriel, pas par message instantané, pas dans un document partagé qui restera en ligne dix ans. Un gestionnaire de mots de passe permet de partager proprement, et beaucoup en proposent gratuitement.
À défaut, transmettez l'identifiant par un canal et le mot de passe par un autre, et demandez au client de le changer à la première connexion.
Ce que ça vous évite
Un client qui repart avec tout ne revient pas vous demander, deux ans après, un accès que vous n'avez plus. Il ne vous appelle pas non plus en urgence parce que son nouveau prestataire est bloqué.
La réversibilité est aussi une manière de refermer proprement votre propre responsabilité.
11. La documentation minimale qui tient Deux pages, écrites une fois
Une documentation exhaustive n'est ni lue ni maintenue. Deux pages, écrites au moment de la livraison quand tout est frais, valent mieux qu'un manuel que personne n'ouvrira.
1 La page technique, pour vous ou votre successeur
- Où est hébergé le site, chez qui est le domaine, chez qui est la messagerie
- Les versions employées, et les extensions installées avec leur rôle
- Comment on déploie une modification, en trois lignes
- Ce qui est sauvegardé, où, à quelle fréquence, et comment on restaure
- Les tâches planifiées et ce qu'elles font
- Les services tiers appelés par API, et où sont rangées leurs clés d'accès
- Les particularités : le réglage bizarre qui a une raison, celui qu'il ne faut pas toucher
2 La page utilisateur, pour le client
- Comment se connecter à l'administration
- Comment publier, modifier et dépublier un contenu
- Comment ajouter une image, et quelle taille utiliser
- Ce qu'il ne faut pas faire, avec la raison
- Qui appeler, et dans quel cas
Une capture d'écran annotée remplace trois paragraphes. Un enregistrement d'écran de cinq minutes, commenté à voix haute, remplace la page entière et se fait avec les outils déjà présents sur n'importe quel poste.
12. Le déroulé complet, en une page De la livraison à la clôture
Étape 1 : Livrer sur un environnement de test
Site complet, protégé, interdit aux moteurs. Avec le plan de test rempli de votre côté : vous ne livrez pas quelque chose que vous n'avez pas vérifié vous-même.
Étape 2 : Lancer la recette, en accompagnant
Trente minutes avec le client pour dérouler le plan. Dates de début et de fin annoncées, canal unique, interlocuteur désigné.
Étape 3 : Trier et corriger
Chaque remarque classée en défaut, écart ou évolution, à la réception. Les deux premiers sont corrigés, le troisième fait l'objet d'une proposition.
Étape 4 : Obtenir l'accord écrit
Une phrase suffit. C'est elle qui déclenche la mise en production et le solde de la facture.
Étape 5 : Préparer le retour arrière, puis basculer
Copie de l'ancien site, ancien hébergement conservé, TTL abaissé la veille. Puis la checklist, un mardi matin.
Étape 6 : Surveiller une semaine
Les cinq signaux de la section 8, et le formulaire de test du lundi.
Étape 7 : Rendre les clés et clore
Accès, sauvegarde, documentation. Puis un point de clôture : ce qui a bien marché, ce qui a coincé, et la proposition de maintenance.
Les six règles qui résument ce mémo
- Livrer, recetter et mettre en production sont trois moments distincts.
- Le plan de test s'écrit au cadrage, quand on sait encore ce qu'on a promis.
- Une recette sans date de fin ne finit pas.
- Chaque remarque se classe à la réception, jamais à la fin.
- On ne bascule pas sans savoir comment revenir en arrière.
- Un client qui peut partir librement est un client qui recommande.
Mémo publié par NET&PRO à titre pédagogique. Information générale, sans garantie d'exactitude, d'exhaustivité ni d'actualité, et sans valeur de conseil personnalisé. Avertissement et limites d'usage
Dans le glossaire
Les mots croisés au fil de ce mémo, définis en une phrase. Ils sont soulignés dans le texte : un clic y mène directement.
Mémos liés
Mettre un site en ligne de A à Z
Nom de domaine, hébergement, transfert du code, HTTPS, droits, sauvegardes : la mise en ligne expliquée pas à pas.
Lire le mémoChiffrer un projet et tenir son devis
Calculer un taux journalier qui tient, découper pour estimer sans mentir, choisir entre forfait et régie en sachant qui porte le risque, facturer le cadrage à part.
Lire le mémoRecruter un profil tech quand on n'est pas technique
Les cinq façons de ne pas recruter, ce que coûte vraiment un développeur en France et au Maroc, lire un CV technique sans savoir coder, l'exercice qui remplace le test technique et les trente premiers jours.
Lire le mémoSur le blog
Si vous préférez me le confier
Sur ce sujet, voici ce que je fais pour mes clients. Les formules disent ce qui est compris, ce qui ne l'est pas, et ce que ça coûte au bout de trois ans.