ISMS Copilot Docs

Politique de gestion des changements

ISMS Copilot maintient une politique formelle de gestion des changements pour garantir que toutes les modifications apportées à nos systèmes de production sont examinées, testées et déployées en toute sécurité. Notre…

ISMS Copilot maintient une politique formelle de gestion des changements pour garantir que toutes les modifications apportées à nos systèmes de production sont examinées, testées et déployées en toute sécurité. Notre processus équilibre les exigences de sécurité et de conformité avec le besoin d'itération rapide.

Notre politique de gestion des changements s'intègre directement à notre workflow GitHub et à notre pipeline CI/CD pour une application automatisée.

Types de changements

Nous catégorisons les changements en trois types en fonction du risque et de l'impact :

  • Changements standard — Changements à faible risque, préapprouvés, tels que les mises à jour de documentation, les correctifs de dépendances et les mises à jour de configuration de routine. Ceux-ci peuvent être fusionnés automatiquement une fois les vérifications automatisées passées.
  • Changements normaux — Ajouts de fonctionnalités, modifications de schéma de base de données, changements d'API et mises à jour de sécurité. Nécessitent un processus de révision complet avec au moins une approbation avant le déploiement.
  • Changements d'urgence — Vulnérabilités de sécurité critiques, pannes de service ou problèmes d'intégrité des données. Suivent un processus d'approbation accéléré tout en maintenant une piste d'audit et une révision post-déploiement.

Processus d'approbation

Notre processus de changement standard suit ces étapes :

  1. Création d'une issue GitHub — Demande de changement documentée avec justification et évaluation de l'impact
  2. Branche et pull request — Modifications de code développées dans une branche de fonctionnalité avec une PR descriptive
  3. Tests automatisés — Le pipeline CI exécute des tests automatisés incluant des tests unitaires, des tests d'intégration et des analyses de sécurité
  4. Révision par les pairs — Au moins un membre de l'équipe examine le code, l'architecture et les implications de sécurité
  5. Approbation et fusion — Les changements approuvés sont fusionnés dans la branche principale
  6. Déploiement automatisé — Les changements sont automatiquement déployés en production via notre pipeline CI/CD (Supabase, Fly.io, Vercel)

Les changements d'urgence suivent un chemin accéléré mais maintiennent tout de même une piste d'audit et nécessitent une révision post-déploiement dans les 24 heures.

Tests et barrières de qualité

Avant qu'un changement n'atteigne la production, notre pipeline CI automatisé impose :

  • L'exécution de la suite de tests automatisés
  • La validation des migrations de base de données sur l'environnement CI de Supabase
  • L'analyse statique du code et le scan de sécurité
  • La vérification de la construction pour toutes les cibles de déploiement

Retour arrière et récupération

Notre politique de gestion des changements inclut des procédures de retour arrière pour les déploiements échoués. Nous maintenons la capacité de revenir rapidement en arrière tout en préservant l'intégrité des données et la disponibilité du système.

Tous les changements sont suivis dans GitHub avec un historique d'audit complet incluant les approbateurs, les horodatages et la justification des changements.

Gestion des secrets et de la configuration

Les changements impliquant des secrets, des clés API ou une configuration sensible suivent des contrôles de sécurité supplémentaires au-delà des procédures standard de changement pour prévenir l'exposition des identifiants.

On this page