Utilisez cette checklist de remise prête pour la production pour empaqueter environnements, secrets, monitoring, sauvegardes et runbooks afin qu’ops puisse déployer et gérer votre app.
Une remise prête pour la production signifie qu’ops peut exploiter l’app sans avoir à deviner. Ils peuvent déployer une version connue, confirmer qu’elle est saine, répondre aux alertes et récupérer d’un mauvais déploiement ou d’une panne. Si l’un de ces points dépend de la mémoire d’un développeur, la remise n’est pas terminée.
Considérez la remise comme un paquet qui répond à une question : si les créateurs disparaissent pendant une semaine, ops peut‑il quand même maintenir le système sûr et disponible ?
Un bon paquet couvre généralement ce que fait l’app, à quoi ressemble un état « sain », comment fonctionnent les releases (déployer, vérifier, revenir en arrière), où vit la configuration, comment sont gérés les secrets, et comment monitorer, sauvegarder et répondre aux incidents.
Tout aussi important, ce que la remise ne couvre pas. Ce n’est pas une promesse d’ajouter des fonctionnalités, de refactoriser, de redessiner des écrans ou de « nettoyer plus tard ». Ce sont des projets séparés avec leur propre périmètre.
Avant de considérer la remise comme complète, mettez par écrit la propriété et les temps de réponse. Par exemple : ops prend en charge la disponibilité et effectue les déploiements ; l’équipe produit gère la roadmap ; l’équipe dev fournit une fenêtre définie de support post‑remise pour corrections et questions.
Ops ne peut prendre en charge que ce qu’ils voient. Un inventaire d’une page évite les approximations lors des déploiements, incidents et audits. Restez en anglais simple et précis.
Listez chaque partie en fonctionnement et où elle vit : API back‑end, application web, workers, jobs planifiés et comment les apps mobiles se connectent. Même si iOS/Android sont distribués via les stores, ils dépendent du même backend.
Incluez les services externes dont l’app ne peut se passer. Si vous utilisez PostgreSQL, une queue, du stockage d’objets ou des APIs tierces (paiements comme Stripe, messagerie, email/SMS, Telegram), notez le nom exact du service et son usage.
Capturez les exigences réseau pour éviter les essais‑erreurs d’hébergement : domaines requis (app, api, admin), ports et protocoles, qui renouvelle les certificats TLS, où DNS est géré et toute allowlist d’entrée/sortie.
Enfin, notez la charge attendue en chiffres : requêtes max par minute, utilisateurs actifs, tailles typiques de payload, taille actuelle de la base et croissance prévue. Même des fourchettes approximatives aident ops à fixer des limites et des alertes.
Si vous avez construit avec AppMaster, inventairez le back‑end généré, l’app web et les intégrations pour que ops sache ce qui doit être déployé ensemble.
Les déploiements production échouent souvent sur la partie ennuyeuse : la config qui n’existe que dans la tête de quelqu’un. Traitez la configuration comme un livrable. Ops doit pouvoir voir quelles options existent, ce qui diffère par environnement et comment les modifier en toute sécurité.
Commencez par nommer chaque environnement qui existe aujourd’hui, même temporaire. La plupart des équipes ont dev, staging et production, plus des copies comme « production‑eu » ou « staging‑us ». Indiquez quel environnement sert aux tests de release, aux migrations de données et aux exercices d’incident.
Fournissez une seule référence de config qui liste les noms de variables et des valeurs d’exemple sûres (jamais de vraies identifiants). Rendez les placeholders évidents.
Votre paquet de remise devrait inclure :
Ajoutez un processus simple de changement. Par exemple : demande via ticket, relecture par le responsable du service, appliquer en staging d’abord, puis promouvoir en production dans une fenêtre planifiée avec un plan de rollback si le taux d’erreur augmente.
Si vous exportez et auto‑hébergez une app AppMaster, gardez la même règle : livrez un ensemble propre et documenté de clés de config avec le code généré pour que ops puisse l’exécuter de manière cohérente entre environnements.
Les secrets sont la voie la plus rapide pour qu’une remise propre devienne un incident de sécurité. L’objectif est simple : ops doit connaître chaque secret nécessaire à l’app, où il est stocké, qui peut le lire et comment le changer sans interruption.
Commencez par une courte liste de secrets que ops peut scanner en une minute. Pour chaque élément, indiquez ce qu’il débloque (base de données, SMTP, Stripe, clé de signature JWT), où il réside (vault, store cloud, Kubernetes Secret, fichier chiffré) et qui en est responsable pour la rotation.
Rédigez les étapes de rotation comme une recette, pas une politique. Incluez l’ordre exact, combien de temps l’ancien secret doit rester valide et la vérification unique qui prouve que ça a fonctionné.
Utilisez ce modèle pour chaque secret :
Soyez explicite sur les attentes de chiffrement. Les secrets doivent être chiffrés au repos dans le gestionnaire et protégés en transit (TLS) entre l’app et ses dépendances. Ne mettez jamais de secrets dans le contrôle de version, les artefacts de build ou des documents partagés.
Définissez l’accès break‑glass. Si une panne empêche l’accès normal, précisez qui peut approuver l’accès d’urgence, combien de temps il dure et ce qui doit être audité ensuite.
Ops ne peut prendre en charge que ce qu’ils peuvent reproduire. Un bon package de déploiement facilite trois questions : qu’est‑ce qu’on exécute exactement, comment on le redéploie, et comment revenir en arrière rapidement si quelque chose casse.
Incluez une « liste de matériel » claire pour la build. Indiquez le type d’artefact et comment le vérifier, pas seulement où il se trouve :
Ajoutez un petit exemple concret. Par exemple : « Déployer v1.8.2 en mettant à jour le tag d’image, en lançant les migrations, puis en redémarrant les workers web. Si les checks de santé échouent pendant 10 minutes, revenir à v1.8.1 et arrêter le job de migration. »
Un plan de rollback doit se lire comme des instructions à suivre à 2 h du matin. Il doit indiquer :
Si l’app a été construite avec AppMaster et exportée en source pour auto‑hébergement, incluez la version du code généré, les instructions de build et les attentes runtime pour que ops puisse reconstruire la même release plus tard.
La remise n’est pas complète tant qu’ops ne peut pas voir ce que fait l’app et être averti avant que les utilisateurs se plaignent.
Mettez d’accord quels logs doivent exister et où ils vont (fichier, syslog, plateforme de logs). Assurez‑vous que les logs sont synchronisés en temps et incluent un ID de requête ou de corrélation afin que les incidents soient traçables de bout en bout.
Vous voulez en général : logs applicatifs (événements clés et échecs), logs d’erreur (stack traces et jobs échoués), logs d’accès (requêtes et codes de status), logs d’audit (actions admin et exports) et logs d’infrastructure (redémarrages, pression sur les nœuds, problèmes disque).
Ensuite, définissez un petit ensemble de métriques représentant l’état système et l’impact utilisateur. Si vous n’en choisissez que cinq : latence (p95/p99), taux d’erreur, saturation (CPU/mémoire/disque), profondeur des files et contrôles de disponibilité externes.
Les règles d’alerte doivent être sans équivoque : déclencheur, gravité (pager vs ticket), qui est d’astreinte et quand escalader. Ajoutez une capture d’écran du dashboard « bon état » et une courte note décrivant ce qu’est la normale (plage de latence typique, taux d’erreur attendu, profondeur habituelle des queues). Ce contexte évite les alertes bruyantes et aide les nouveaux répondants à agir rapidement.
Les sauvegardes ne sont pas quelque chose qu’on « a ». C’est quelque chose dont on peut restaurer, à la demande.
Écrivez le périmètre exact : base de données, stockage de fichiers (uploads, rapports, factures) et les éléments souvent oubliés, comme la config qui n’est pas dans le code et les clés de chiffrement nécessaires pour lire les données protégées.
Gardez les objectifs clairs. RPO = combien de données vous pouvez perdre (par ex. 15 minutes). RTO = durée maximale d’indisponibilité acceptée (par ex. 1 heure). Choisissez des chiffres approuvés par le business, car ils déterminent le coût et l’effort.
Incluez :
Si vous exportez et auto‑hébergez une app AppMaster, incluez les étapes de restauration PostgreSQL ainsi que les buckets de stockage externes et les clés utilisées pour les champs chiffrés.
Planifiez un exercice de restauration. Enregistrez le temps, ce qui a cassé et ce que vous avez changé pour que la prochaine restauration soit plus rapide et moins stressante.
Une remise n’est valide que si quelqu’un peut être pagé à 2 h du matin et résoudre le problème sans deviner. Les runbooks transforment le savoir tribal en étapes qu’un on‑call peut suivre.
Commencez par les incidents les plus probables : panne totale, lenteur, et un déploiement qui casse quelque chose. Gardez chaque runbook court. Placez les vérifications les plus rapides en haut pour que le répondant obtienne un signal en quelques minutes.
Gardez la structure cohérente pour qu’elle soit lisible sous pression :
Si l’app a été exportée ou auto‑hébergée depuis AppMaster, incluez où tournent les services générés, comment les redémarrer en sécurité et quelles valeurs de config sont attendues par environnement.
Gardez une checklist post‑incident courte. Enregistrez la timeline, ce qui a changé en dernier, les messages d’erreur exacts, les utilisateurs affectés et l’action qui a réparé. Puis mettez à jour le runbook pendant que les détails sont frais.
Ops ne peut pas prendre en charge un système s’il n’est pas clair qui peut agir et comment l’accès est tracé.
Rédigez les rôles réellement utilisés. Pour beaucoup d’équipes, ceux‑ci suffisent :
Documentez la « politique de porte » en étapes simples : qui accorde l’accès, où il est accordé (SSO, cloud IAM, utilisateurs DB, CI/CD, panels admin), qui peut le révoquer et comment vérifier qu’il est bien retiré lors d’un offboarding.
N’oubliez pas l’accès non humain. Listez chaque compte de service et token utilisés par des jobs, intégrations et monitoring, avec une note de moindre privilège pour chacun (ex. « peut only lire le bucket X »). Si vous exportez le code AppMaster pour auto‑hébergement, indiquez quelles variables d’environnement ou fichiers de config définissent ces identités, sans coller les valeurs secrètes dans le document de remise.
Précisez aussi les attentes d’audit : ce qui doit être journalisé (connexion, déploiement, changement de config, actions admin BD), qui peut lire les logs, la rétention, où les logs sont stockés et comment les demander pendant un incident ou une revue.
Les notes de sécurité doivent être lisibles par des non‑spécialistes, mais assez précises pour que ops agisse. Ajoutez une page de résumé répondant : quelles données stockons‑nous, où vivent‑elles et qui y accède ?
Commencez par les types de données : profils clients, tickets support, métadonnées de paiement, fichiers. Identifiez les catégories sensibles comme la PII (noms, emails, numéros), les identifiants et toute donnée régulée. Si vous avez exporté le code pour auto‑hébergement (y compris depuis AppMaster), notez où ces données se trouvent en base et quels services peuvent les lire.
Ensuite, rédigez les règles de rétention et suppression en termes pratiques. Indiquez ce que vous conservez, pendant combien de temps, et comment la suppression fonctionne (soft delete vs purge définitive, délai). Si vous avez des retenues légales ou besoins d’audit, notez qui approuve les exceptions.
Les logs fuguent souvent plus que les bases. Soyez clair sur où la PII peut apparaître (logs d’accès, logs d’erreur, événements analytics) et comment la réduire ou la masquer. Si un champ ne doit jamais être logué, écrivez la règle.
Gardez les approbations explicites :
Si vous ne pouvez ajouter qu’une chose en plus, ajoutez une note de preuve : où sont les logs d’audit et comment les exporter quand on vous demande une preuve.
Ops reprend un portail client développé par une petite équipe produit et le migre vers une nouvelle infra auto‑hébergée. L’objectif n’est pas seulement « ça tourne », mais « ops peut l’exploiter sans appeler les créateurs ».
Jour 1 : ops effectue un premier déploiement propre dans un nouvel environnement en n’utilisant que le paquet de remise. L’app monte, mais la connexion échoue car une variable d’environnement pour le fournisseur d’email manque. On l’ajoute au template d’env, puis on redéploie jusqu’à ce que tout fonctionne depuis zéro.
Jour 2 : la première alerte est déclenchée volontairement. Ops provoque une panne contrôlée (arrêter un service ou bloquer l’email sortant) et vérifie : les métriques montrent le problème, les alertes arrivent au bon canal et le message indique quoi faire ensuite.
Jour 3 : un jeton expire dans le bac à sable de paiement. Comme l’emplacement des identifiants et les étapes de rotation sont documentés, ops le remplace sans deviner ni exposer de secrets.
Jour 4 : coupure DNS. Un mauvais enregistrement pointe vers l’ancienne IP et le portail paraît indisponible pour certains utilisateurs. Ops suit le runbook pour vérifier DNS, TLS et checks de santé dans le bon ordre.
Jour 5 : premier test de restauration de backup. Ops restaure dans une base propre et prouve que le portail charge des données réelles.
L’app a tourné 7 jours sans corrections mystérieuses, une restauration réussie, des alertes claires et un déploiement répétable qu’ops peut effectuer seul.
La façon la plus rapide de transformer une remise calme en feu à 2 h du matin est de croire que « on a tout dit à ops » équivaut à « ops peut s’en occuper sans nous ».
Les motifs d’échec courants après une remise pour auto‑hébergement incluent : secrets partagés dans des feuilles ou le chat, rollback dépendant d’un développeur, backups existants mais jamais testés en restauration, alertes qui se déclenchent en continu car les seuils n’ont pas été ajustés, et détails d’environnement qui vivent seulement dans la tête de quelqu’un (ports, noms DNS, schedules cron, permissions cloud).
Exemple : vous exportez le code source depuis AppMaster pour auto‑hébergement et le premier déploiement fonctionne. Deux semaines plus tard, un changement de config casse les connexions. Si les secrets circulaient dans le chat et que le rollback nécessite le créateur original, ops perdra des heures à retrouver l’état « ça marchait hier ».
Avant de clore le ticket, lancez un petit exercice de démarrage à froid. Donnez le paquet de remise à un ingénieur ops et un environnement propre (nouvelle VM, namespace Kubernetes ou projet cloud vierge). S’ils peuvent déployer, observer et récupérer l’app dans un temps fixé (par ex. 2 heures), vous êtes proches du but.
Utilisez ces vérifications :
Si vous exportez le code généré pour auto‑hébergement, confirmez aussi qu’ops sait où sont enregistrés les inputs de build, les versions et les tags de release pour que les futures releases restent reproductibles.
Faites une dernière répétition avec les personnes qui porteront la pager. Traitez‑la comme une répétition générale. Prouvez que le déploiement, le rollback, la restauration et l’alerting fonctionnent tous avec l’exact paquet remis.
Une répétition finale couvre généralement : déployer en test puis en production avec les mêmes étapes, revenir à la version précédente et vérifier le fonctionnement, restaurer depuis la sauvegarde dans un environnement propre et valider une vérification simple (login, création d’un enregistrement, envoi d’un message), déclencher une alerte test sûre, et confirmer où trouver logs et dashboards pendant un incident.
Rendez la propriété explicite. Assignez un responsable nommé pour chaque runbook (déploiement, incident, restauration) et pour chaque route d’alerte (astreinte principale, backup, comportement hors heures). Si personne ne possède une alerte, elle sera soit ignorée soit réveillera la mauvaise personne.
Rédigez un court plan Day 2 pour que ops sache quoi améliorer après la première semaine : ajuster les seuils, vérifier les coûts, nettoyer les anciens artefacts et revoir les accès. Gardez‑le petit et limité dans le temps.
Si vous avez construit avec AppMaster (appmaster.io), incluez le code source exporté ou les détails exacts de déploiement (cloud, régions, paramètres de build, services requis) pour que ops puisse reproduire l’app sans dépendre de l’espace projet d’origine. Définissez une cadence simple pour mettre à jour le paquet chaque fois que les exigences changent, afin que les runbooks ne dérivent pas de la réalité.
Que signifie concrètement « remise prête pour la production » ?Une remise « prête pour la production » signifie qu’ops peut déployer une version connue, vérifier qu’elle est saine, répondre aux alertes et récupérer après des pannes sans dépendre de la mémoire d’un développeur en particulier. Si une semaine sans les créateurs mettrait la disponibilité en risque, la remise n’est pas terminée.
Que doit contenir un inventaire système basique ?Commencez par une inventaire d’une page qui liste chaque composant en fonctionnement et où il se trouve : API, application web, workers, jobs planifiés, base de données, stockage et services tiers requis. Ajoutez les domaines, ports, la gestion DNS/TLS et une estimation de la charge attendue pour que ops n’ait pas à deviner.
Comment transmettre la configuration d’environnement sans fuir des secrets ?Fournissez une référence de configuration unique qui liste chaque clé de config, son type et une valeur d’exemple non sensible, ainsi que ce qui diffère entre dev/staging/prod. Ne mettez pas de vraies informations d’identification ; documentez où la config est stockée et comment elle est appliquée lors des déploiements afin que les changements soient reproductibles.
Que faut‑il au minimum documenter pour la rotation des secrets et identifiants ?Créez une courte liste de secrets indiquant à quoi sert chaque secret, où il est stocké, qui peut le lire et qui est responsable de sa rotation. Écrivez les étapes de rotation comme une checklist avec une vérification claire, et incluez un processus « break‑glass » pour les urgences avec des attentes d’audit.
Qu’est‑ce qui rend un package de déploiement « reproductible » pour ops ?Ops doit pouvoir identifier précisément ce qui tourne et comment le reproduire : nom/tag de l’artifact, version, date de build, checksum et la référence source utilisée pour la build. Indiquez la cible recommandée, l’ordre de déploiement, le temps typique et comment les migrations de base de données sont lancées et vérifiées.
Que doit contenir un plan de rollback utilisable à 2 h du matin ?Définissez les signaux déclencheurs (par ex. contrôles de santé qui échouent ou taux d’erreur élevé), la dernière version connue bonne et les étapes exactes pour revenir rapidement en arrière. Précisez si les changements de base de données sont réversibles et quel est le repli sûr si ce n’est pas le cas, afin que le rollback ne devienne pas de l’improvisation.
Quels signaux de monitoring prioriser lors de la remise ?Choisissez un petit ensemble de métriques reflétant l’impact utilisateur : latence (p95/p99), taux d’erreur, saturation (CPU/mémoire/disque), profondeur des files et un contrôle d’uptime externe. Rédigez des règles d’alerte claires indiquant le déclencheur, la gravité, qui est d’astreinte et quand escalader, et assurez‑vous que les logs sont horodatés et traçables avec un ID de corrélation.
Comment rendre les sauvegardes et restaurations vraiment fiables ?Documentez ce qui est sauvegardé, où c’est stocké, la rétention et qui peut lancer des restaurations. Incluez une procédure de restauration étape par étape avec une vérification, et planifiez un exercice de restauration : les sauvegardes n’ont d’intérêt que si la restauration fonctionne à la demande dans un environnement propre.
À quoi doit ressembler un runbook pour l’astreinte sur incidents courants ?Gardez les runbooks courts et cohérents : symptômes, premières vérifications, étapes suivantes, points de décision et escalade. Concentrez‑vous sur les incidents probables (panne totale, lenteur, déploiement problématique) et mettez à jour le runbook juste après l’incident pendant que les détails sont frais.
Comment documenter le contrôle d’accès et les permissions pour la prise en charge par ops ?Notez les rôles réels utilisés (deployer, admin BD, lecture seule, commandant d’incident), comment l’accès est accordé et révoqué, et ce qui doit être journalisé pour l’audit. N’oubliez pas les comptes de service et tokens : listez ce qu’ils peuvent accéder et où leur identité est configurée sans inclure de valeurs secrètes.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
