La checklist de mise en production

« Prêt pour la production » est employé comme s'il s'agissait d'une note de qualité, et c'est pourquoi personne ne s'accorde jamais sur le fait qu'un produit le soit. Ce n'est pas une note. C'est un ensemble de promesses faites à des personnes précises :

• À vos clients : leurs données sont protégées, ça fonctionne, et ça fonctionnera encore demain.
• À la personne d'astreinte : elle sera prévenue avant le client, et disposera d'assez d'informations pour corriger.
• À votre vous futur : vous pourrez modifier cela sans retenir votre souffle.

Chaque point ci-dessous existe pour tenir l'une de ces promesses. Ce qui signifie aussi que vous pouvez décider, délibérément, de ne pas encore en tenir certaines.

Calibrez selon les enjeux

Un projet du week-end et un système de paie n'appellent pas la même checklist, et prétendre le contraire est la raison pour laquelle ces listes sont ignorées. Trois niveaux honnêtes :

• Niveau 1 — vous avez de vrais utilisateurs. Tout ce qui relève des Données et de la Sécurité ci-dessous. Non négociable, quel que soit le produit.
• Niveau 2 — des gens en dépendent pour travailler. Ajoutez Fiabilité et Exploitation.
• Niveau 3 — vous manipulez de l'argent, de la santé ou des données réglementées. Ajoutez tout le reste, et faites réaliser une revue externe.

En dessous du niveau 1, « prêt pour la production » n'existe pas. Au-dessus, sauter un point est une décision et non un oubli — écrivez lesquels et pourquoi.

Données — les promesses qu'on ne peut pas réparer

Tout le reste est récupérable. Pas ceci.

• Sauvegardes automatiques, planifiées, conservées assez longtemps pour survivre à un problème constaté tardivement.
• Une restauration que vous avez réellement effectuée. Une sauvegarde non testée est un espoir. Faites-le une fois, chronométrez, notez la procédure.
• Migrations sous forme de code versionné, appliquées à l'identique sur chaque environnement. Les changements de schéma faits à la main dans une interface de base de données sont la voie royale vers des environnements divergents.
• Un retour arrière testé pour le dernier déploiement, y compris le sort des données écrites par la version que vous annulez.
• Une restauration à un instant donné si votre budget le permet. « Restaurer la nuit dernière » fait perdre une journée.

Sécurité — celles qui tuent des entreprises

Classées par dégâts évités.

• Un contrôle de propriété sur chaque endpoint qui reçoit un identifiant. La faille sérieuse la plus répandue dans le logiciel en général, et quasi systématique dans le code généré.
• Aucun secret dans le bundle client. Tout ce qui y a figuré est compromis et doit être renouvelé, pas déplacé.
• Limitation de débit sur la connexion, la réinitialisation de mot de passe, l'inscription et les endpoints coûteux.
• Audit des dépendances dans la CI, pour qu'une vulnérabilité connue fasse échouer le build au lieu d'attendre que quelqu'un la remarque.
• En-têtes de sécurité et HTTPS partout, avec HSTS.
• L'échec ferme la porte. Quand une vérification d'autorisation lève une erreur, la requête est refusée. Relisez les blocs catch et vérifiez-le.
• Les interfaces d'administration derrière un vrai contrôle d'accès, pas une URL difficile à deviner.

Fiabilité et exploitation — le test de 3 h du matin

Une seule question couvre l'essentiel : si cela casse à 3 h du matin, comment l'apprenez-vous, qui intervient, et dispose-t-il de ce qu'il faut ?

• Suivi des erreurs capturant les exceptions avec assez de contexte pour déboguer.
• Supervision de disponibilité sur les parcours critiques — pas seulement la page d'accueil. Un tunnel de commande cassé pendant que la page vitrine s'affiche est le mode de défaillance qui coûte de l'argent.
• Des alertes là où un humain les verra vraiment. Une alerte dans un canal que personne ne lit n'est pas de la supervision.
• Des logs structurés et consultables, avec identifiants de requête, conservés assez longtemps pour enquêter sur un signalement d'il y a une semaine.
• Un responsable nommé. Le point le plus souvent omis, et celui qui fait fonctionner tous les autres.
• Des sondes de santé exploitables par votre plateforme.
• Les traitements lents en tâches de fond, pour qu'une panne chez un tiers n'emporte pas votre parcours d'inscription.

Performance — là où cela devient du chiffre d'affaires

• Index sur chaque colonne filtrée ou jointe, et requêtes N+1 éliminées.
• Un pooler de connexions entre l'application et la base, surtout en serverless.
• Core Web Vitals au vert au 75e centile — mesurés sur des données de terrain, pas un score de laboratoire.
• Un test de charge à un pic plausible, pour connaître votre plafond avant que votre meilleure journée de trafic ne vous l'apprenne.

Le juridique et l'ingrat

Vraiment faciles à oublier, vraiment ennuyeux à manquer.

• Politique de confidentialité et conditions, surtout avec des paiements ou des clients dans l'UE.
• Consentement cookies là où c'est requis, implémenté sans casser vos métriques de mise en page.
• Délivrabilité e-mail configurée — SPF, DKIM, DMARC — pour que les réinitialisations n'atterrissent pas en spam.
• Suppression de compte, si vous avez des comptes. De plus en plus exigée, et lente à rajouter.
• Statistiques, pour apprendre quelque chose du trafic que vous avez gagné.
• Un parcours de facturation testé, échecs compris : cartes refusées, résiliations, remboursements, relances.

Mécanique de lancement

• Déployer depuis une branche, pas depuis le poste de quelqu'un.
• Un environnement de préproduction assez proche de la production pour être instructif.
• Un retour arrière documenté, répété au moins une fois.
• Un lancement progressif quand le produit le permet.
• Quelqu'un de disponible les premiers jours, capable de corriger réellement.

Comment s'en servir

Ne la parcourez pas de haut en bas. Traitez Données, puis Sécurité, puis le test de 3 h du matin — ces trois blocs couvrent les défaillances irrécupérables, fatales ou invisibles. Le reste peut se planifier.

Puis écrivez ce que vous avez sciemment laissé de côté. La valeur d'une checklist n'est pas dans les cases cochées : c'est dans la courte liste de ce que vous avez décidé d'assumer sans, pour que personne ne soit surpris plus tard.

Si vous préférez qu'on parcoure cela sur votre système réel et qu'on vous dise honnêtement où vous en êtes, c'est un travail que fait notre agence. Découvrez notre approche du développement SaaS, ou envoyez-nous le dépôt.