Les mesures ci-dessous relèvent d’une politique approuvée, à mettre en œuvre et à vérifier dans le cadre de l’accord de projet. Les responsabilités opérationnelles effectivement applicables sont celles attribuées par le contrat d’exploitation ou d’assistance.
Journalisation
Les journaux se limitent aux informations nécessaires au diagnostic des défaillances et au soutien de l’exploitation. Les données sensibles sont masquées et l’accès est réservé aux personnes habilitées. Les durées de conservation sont définies selon les besoins opérationnels, avec suppression automatique à leur expiration. Les mots de passe et les clés d’accès ne doivent pas être consignés dans les journaux, et le contenu sensible des requêtes ne doit pas y être enregistré en intégralité.
Suivi des erreurs
Les erreurs sont collectées et hiérarchisées en fonction de leur impact sur le service, avec des alertes qui aident la personne désignée à enquêter et à assurer le suivi. Les données sont expurgées avant d'être envoyées à l'outil de suivi, et les diagnostics ne doivent pas se transformer en une collecte inutile de données sur les visiteurs.
Surveillance
La politique approuvée prévoit une surveillance automatisée de la disponibilité, des performances et des erreurs, avec une personne désignée pour recevoir et suivre les alertes. L’accord d’exploitation ou d’assistance définit les horaires de prise en charge, les délais de réponse et les responsabilités. Cette politique ne promet ni une surveillance humaine permanente ni un pourcentage précis de disponibilité.
Sauvegardes
La politique approuvée prévoit des sauvegardes automatiques et chiffrées, isolées du système principal, avec une durée de conservation définie et des tests périodiques de restauration. Le contrat désigne les responsables des sauvegardes, du suivi et de la restauration ; cette responsabilité n’incombe pas automatiquement au développeur du seul fait qu’il a créé le site.
Le périmètre des sauvegardes dépend des données réellement présentes : fichiers du site, ressources, configuration nécessaire à la restauration et, le cas échéant, données évolutives. La réussite d’une tâche de sauvegarde ne suffit pas ; la possibilité de restaurer doit être vérifiée. La fréquence des sauvegardes, la perte de données acceptable et le délai de rétablissement sont fixés selon les besoins du service et l’accord, sans engagements chiffrés non approuvés.
Retour à la version précédente
Conservez une version stable et préparez une procédure testée de retour à la version précédente, avec des contrôles de bon fonctionnement du service après le déploiement et après le retour arrière. Les modifications de la base de données, le cas échéant, nécessitent un plan distinct pour protéger les données et vérifier la compatibilité. Il ne faut pas supposer que la restauration des fichiers de l’application restaure automatiquement les données.
Gestion des secrets
Les mots de passe des services et les clés API sont stockés dans un gestionnaire de secrets dédié. Les secrets de test et de production sont séparés, et l’accès est limité aux besoins. Les secrets ne doivent figurer ni dans le code source, ni dans les fichiers publics du frontend, ni dans les journaux. Ils sont révoqués et remplacés en cas de suspicion d’exposition, et les autorisations d’accès sont réexaminées.