Maintenance et capacité

La maintenance préventive réduit les interventions urgentes. Elle doit être planifiée comme un changement de production : périmètre, sauvegarde, validation et preuve d’exécution.

Cadence suggérée

Quotidien

• état des applications, certificats et derniers déploiements ;
• erreurs 5xx, redémarrages et espace disque ;
• échecs d’e-mail, calendrier, média ou IA ;
• présence d’un backup récent.

Hebdomadaire

• croissance de pb_data, logs et images Docker ;
• previews orphelines et volumes temporaires ;
• erreurs fonctionnelles récurrentes ;
• dérive entre commits staging et production ;
• compte des invitations ou traitements bloqués.

Mensuel

• test de restauration d’un backup ;
• revue des accès Dokploy, GitHub, DNS et fournisseurs ;
• vérification des dates d’expiration de certificats et identifiants ;
• mises à jour de sécurité des images et dépendances ;
• revue de capacité et de rétention ;
• contrôle de la documentation et des contacts d’incident.

Mise à jour des dépendances

1. Lisez notes de version et avis de sécurité.
2. Séparez runtime, framework et dépendances applicatives quand le risque est élevé.
3. Validez sur une branche et une preview avec les lockfiles mis à jour.
4. Exécutez make verify dans le dépôt concerné et make e2e pour un parcours cross-stack.
5. Déployez en staging, observez, puis promouvez.

Gardez Node aligné sur .nvmrc, package.json, CI et Dockerfiles. Gardez Go aligné sur .go-version, go.mod, CI et l’image builder.

Migrations PocketBase

Chaque migration est versionnée dans backend/migrations/ et exécutée par PocketBase. Avant production :

• relisez le comportement sur des enregistrements existants, pas seulement sur une base vide ;
• vérifiez l’idempotence attendue du démarrage et l’ordre des migrations ;
• testez une copie réaliste et mesurez la durée ;
• identifiez les changements destructifs et la stratégie de rollback ;
• sauvegardez immédiatement avant le déploiement.

Une migration qui ajoute d’abord une structure compatible, laisse les deux versions fonctionner, puis nettoie dans une release ultérieure facilite le rollback.

Capacité

Surveillez les tendances, pas seulement les seuils actuels :

• taille SQLite et fichiers médias ;
• espace libre nécessaire aux backups et migrations ;
• mémoire maximale du backend pendant traitement média ;
• temps de build web/Storybook/documentation ;
• latence des endpoints et volume de demandes ;
• quotas SMTP, cartographie et IA.

Conservez une marge suffisante pour dupliquer pb_data lors d’une restauration. Atteindre 100 % du disque peut corrompre une écriture avant que le health check ne devienne rouge.

Rétention et nettoyages

• supprimez les previews et volumes éphémères après fermeture des PR ;
• conservez les logs selon leur utilité et sensibilité ;
• appliquez la rétention des sauvegardes après vérification de la copie hors site ;
• nettoyez les audits IA expirés par lots bornés, avec une politique initiale de 90 jours ;
• ne supprimez pas manuellement des fichiers PocketBase sans passer par les règles applicatives.

Un nettoyage doit publier avant/après : volume concerné, nombre d’éléments, espace récupéré et erreurs. Commencez par un mode lecture seule ou un rapport lorsqu’il existe.

Revue d’accès

Contrôlez périodiquement :

• membres et permissions GitHub ;
• accès administrateur Dokploy et SSH ;
• comptes superuser PocketBase ;
• utilisateurs back-office suspendus ou obsolètes ;
• tokens DNS, MapTiler, SMTP et OpenAI ;
• secrets inutilisés dans les environnements.

Révoquez d’abord les accès devenus inutiles, puis vérifiez que les automatisations légitimes continuent de fonctionner. Toute clé partagée sans propriétaire doit être remplacée par un secret attribué et traçable.

Fenêtre de maintenance

Pour une opération avec interruption : annoncez début, impact, durée estimée et canal de suivi ; activez une page ou un mode de maintenance ; bloquez les écritures ; réalisez l’opération ; validez les parcours ; rouvrez le trafic ; annoncez la fin et consignez la durée réelle.