Loading…
.jpg&w=3840&q=75)
← Manuel
Runbooks
Un système n'est pas terminé quand il fonctionne — il est terminé quand quelqu'un d'autre peut l'exploiter lorsqu'il tombe en panne. Chaque réalisation est livrée avec des runbooks : déploiement, restauration, réponse aux incidents et remise en main propre en langage clair. Voici un exemple réel et abrégé issu d'une plateforme littéraire en production.
.jpg&w=3840&q=75)
Du zéro à la production
Un déploiement ordonné par les dépendances
Ordonné parce que l'ordre compte — les utilisateurs initiaux existent avant l'exécution de la migration de données initiales, les variables d'environnement existent avant le premier déploiement, l'URL du site est définie avant la bascule DNS.
- 1
Provisionner les données
Créer le projet Supabase dans af-south-1 (Le Cap) ; créer les utilisateurs d'authentification avant la migration de données initiales afin que les données de profil/récit se résolvent par UUID ; exécuter les migrations strictement dans l'ordre ; vérifier que les buckets de stockage sont correctement configurés.
- 2
Connecter les services
Vérifier le domaine de messagerie (SPF / DMARC / DKIM), obtenir un jeton d'accès social à longue durée de vie et créer la clé d'IA — chacun avec sa propre checklist.
- 3
Configurer & déployer
Ajouter chaque variable d'environnement avant le premier déploiement (jamais après) ; déployer ; définir l'URL canonique du site et redéployer afin que les liens d'authentification se résolvent.
- 4
DNS
Faire pointer les enregistrements apex et www, puis revérifier l'URL du site afin que les liens de récupération de mot de passe et OAuth soient sûrs d'un appareil à l'autre.
- 5
Test de fumée
Exécuter une checklist fixe après chaque déploiement : rendu de la page d'accueil + couverture, page podcast, réponse de l'assistant IA, connexion admin + redirection selon le rôle, sauvegarde de brouillon, transfert éditorial, un envoi de newsletter de test (en moins de 2 min) et un téléversement d'image.
.jpg&w=3840&q=75)
Quand quelque chose casse
Procédures opérationnelles
Réinitialiser le mot de passe d'un utilisateur
Trois parcours documentés — e-mail en libre-service, réinitialisation déclenchée depuis le tableau de bord et forçage d'urgence.
Dépublier / soft-delete / restaurer
Sortir un récit de l'état « publié » (disparu publiquement en ~60 s), le soft-delete avec deleted_at, ou le restaurer en l'effaçant — jamais une suppression définitive.
Échec d'envoi de newsletter
Vérifier les journaux du fournisseur pour les rebonds/limites de débit, croiser avec les abonnés actifs, réessayer par destinataire et marquer les rebonds définitifs comme désabonnés.
Échec de publication sur les réseaux sociaux
Une cartographie des codes d'erreur (jeton expiré / autorisations / signalement de contenu) plus un runbook de rotation de jeton : régénérer, prolonger, mettre à jour la variable d'environnement, redéployer.
Diagnostiquer une erreur RLS
Inspecter la politique via pg_policies, distinguer le client soumis au RLS du client de service, et tester en changeant de rôle.
Restaurer un déploiement
Lire les journaux de build ; restaurer en promouvant le précédent déploiement valide en production ; redéployer pour prendre en compte les changements de variables d'environnement.
.jpg&w=3840&q=75)
La remise en main propre
Vous le possédez — et vous savez l'exploiter.
La livraison comprend une checklist de remise rédigée en langage clair — ce que fait chaque réglage restant, ce qu'est un webhook « en mots simples » et un guide de dépannage pour les rares étapes accessibles uniquement depuis le tableau de bord. Le code, le schéma, les runbooks et les données sont à vous. C'est la réponse à la question que tout acheteur sérieux pose au sujet d'un petit studio : que se passe-t-il quand vous n'êtes pas disponible ? Le système est documenté suffisamment bien pour que la réponse soit « vous, ou toute personne que vous engagez, pouvez continuer ».
