La checklist production avant l'arrivée des vrais utilisateurs

Ce que veut vraiment dire « prêt pour la production »

Une démo fonctionne quand tout se passe bien. Une plateforme en production fonctionne quand les choses tournent mal : un pic de trafic, un déploiement raté, un mot de passe divulgué, un disque qui se remplit la nuit. La mise en production se juge sur les cas d'échec, pas sur le parcours idéal.

La checklist ci-dessous est celle que FlexiGlob applique avant qu'une plateforme construite avec la méthode The Super Platform ne reçoive son premier utilisateur réel. Chaque point est binaire : vérifié ou non. Une plateforme avec un point non vérifié n'est pas prête, quel que soit le calendrier.

Sécurité : la périphérie, les utilisateurs et les secrets

La sécurité commence en périphérie, avant que la moindre requête n'atteigne l'application. Le trafic doit être chiffré, filtré et limité, et chaque utilisateur ne doit voir que ce que son rôle autorise.

• TLS partout, avec renouvellement automatique des certificats et redirection de HTTP vers HTTPS.
• HSTS activé, pour que les navigateurs refusent de revenir en HTTP simple.
• Un pare-feu applicatif (WAF) avec un jeu de règles maintenu couvrant le Top 10 de l'OWASP.
• Authentification et rôles testés rôle par rôle : chaque profil est connecté et vérifié sur ce qu'il ne doit pas voir.
• Limitation de débit sur la connexion, la réinitialisation du mot de passe, l'inscription et toute API publique.
• Secrets hors du dépôt de code, stockés avec des permissions restreintes et renouvelés après toute fuite.
• Interfaces d'administration et bases de données inaccessibles depuis l'internet public.

Données : sauvegardes, restaurations, instantanés et retour arrière

La perte de données est la panne qu'une entreprise pardonne le moins. La règle est simple : une sauvegarde jamais restaurée est un espoir, pas une sauvegarde.

Les instantanés et le retour arrière protègent contre la cause d'indisponibilité la plus fréquente : un déploiement qui tourne mal. Quand chaque mise en ligne prend d'abord un instantané et qu'une seule commande permet d'y revenir, un mauvais déploiement coûte quelques minutes au lieu d'un week-end.

• Sauvegardes quotidiennes automatiques de la base de données et des fichiers, stockées hors du serveur.
• Une restauration testée de bout en bout sur un environnement séparé, avec sa durée notée.
• Un instantané pris automatiquement avant chaque déploiement.
• Une commande de retour arrière exécutée au moins une fois avant le lancement.
• Un export des données que le client peut demander, dans un format ouvert comme CSV ou JSON.

Supervision : savoir avant que vos utilisateurs ne vous le disent

Si la première alerte d'une panne est l'e-mail d'un client, la plateforme n'est pas supervisée. La surveillance dit si le service répond ; le suivi des erreurs dit pourquoi quelque chose a cassé ; les journaux disent ce qui s'est passé.

• Contrôles de disponibilité des pages publiques et des routes critiques, depuis l'extérieur du serveur.
• Alertes sur le disque, la mémoire et l'expiration des certificats, envoyées sur un canal réellement lu.
• Suivi des erreurs qui regroupe les exceptions et les relie à la version qui les a introduites.
• Journaux structurés conservés assez longtemps pour enquêter, et assez peu pour respecter la politique de confidentialité.
• Tâches de fond et files d'attente surveillées, car les échecs silencieux sont les plus difficiles à repérer.

Conformité et portée : pages légales, langues et accessibilité

Une plateforme qui vend doit pouvoir être exploitée légalement et lue par ceux qui achètent. Ces points passent souvent pour des finitions. Ce sont des conditions de lancement.

Pour les plateformes qui servent le Maghreb, l'Afrique francophone et le Golfe, trois langues sont généralement le bon choix par défaut, avec un arabe livré dans une vraie mise en page de droite à gauche, et non un texte traduit dans une page orientée à gauche.

• Politique de confidentialité, conditions d'utilisation et mentions légales, rédigées avec les vraies informations de la société et liées depuis chaque page.
• Un mécanisme de consentement si un traceur ou un cookie non essentiel est utilisé.
• Chaque langue sous forme de vraie page, avec dir="rtl" et une mise en page inversée pour l'arabe.
• Navigation au clavier, focus visible, contraste suffisant et textes alternatifs pour les images.
• Respect de prefers-reduced-motion sur les pages animées.

Performance et visibilité

La vitesse est une fonctionnalité que les utilisateurs ressentent et que les moteurs de recherche mesurent. Fixez un budget de performance avant le lancement et vérifiez-le sur un téléphone de milieu de gamme, pas seulement sur l'ordinateur d'un développeur.

La visibilité fait partie du même travail. Les moteurs de recherche et les assistants IA ne recommandent que ce qu'ils peuvent lire : les bases du SEO appartiennent donc à la checklist, et le GEO mérite son propre plan.

• Un budget de performance pour le poids des pages et le temps de chargement, vérifié sur mobile.
• Compression et cache longue durée pour les fichiers statiques.
• Titre, méta-description et URL canonique uniques sur chaque page publique.
• Un sitemap, un robots.txt qui autorise le site, et des balises hreflang pour chaque langue.
• Des données structurées (JSON-LD) décrivant l'organisation et le produit.

La procédure d'incident

Les incidents arriveront. La différence entre une crise et une procédure tient dans un court document écrit avant le lancement, quand tout le monde est calme.

Une bonne procédure tient sur deux pages. Elle dit qui est d'astreinte, comment revenir en arrière, comment restaurer, qui prévient le client et ce que dit le message aux utilisateurs. FlexiGlob en rédige une pour chaque plateforme et répète le retour arrière avant la mise en ligne.

• Qui est responsable pendant un incident, et comment le joindre.
• Les commandes exactes de retour arrière et de restauration, testées.
• L'emplacement des journaux, de la supervision et des sauvegardes.
• Un modèle de message pour les utilisateurs et pour le client.
• Un court retour d'expérience, rédigé dans les jours qui suivent.

Comment cela tient dans un lancement en une semaine

Cette checklist n'est pas une semaine de travail supplémentaire. Dans la méthode de lancement en sept jours, l'infrastructure qui couvre la plupart des points est en place dès le premier jour, et les derniers jours servent à vérifier, pas à construire.

Si vous voulez une plateforme qui valide chaque point de cette liste avant son premier utilisateur, découvrez comment FlexiGlob construit des super plateformes.

Questions

Questions