Politique de gestion des changements
Cette politique décrit comment un changement (de code, de configuration ou d'infrastructure) parvient jusqu'à la production chez France Nuage. Elle décline, sur ce volet, les principes de notre politique de sécurité de l'information et couvre les contrôles A.5.3, A.8.4 et A.8.32 de la déclaration d'applicabilité.
Nos contrôles sont auto-évalués, alignés sur ISO/IEC 27001, non certifiés par un tiers à ce jour. Le statut de chaque mesure ci-dessous reflète cette auto-évaluation.
Objet et périmètre
La politique s'applique à tout changement susceptible d'affecter la plateforme ou les données qu'elle héberge (code applicatif, migrations de base de données, charts Helm, infrastructure décrite en code, définition de la chaîne d'intégration continue et montées de version des dépendances). Elle concerne les salariés comme les prestataires.
Principes
- Un seul chemin vers la production. Aucun changement ne rejoint la production autrement que par la branche principale, après passage de la chaîne d'intégration continue.
- Pas de modification à la main sur un système en production. L'état visé est déclaré dans Git ; ce qui n'est pas dans Git n'est pas censé exister.
- Séparation des tâches. Écrire un changement, le valider et le déployer ne relèvent pas du même rôle.
- Traçabilité par construction. L'historique Git, la demande de fusion et les journaux de la chaîne d'intégration constituent la piste d'audit de chaque changement.
- Vérification avant production. Un changement s'exécute d'abord dans un environnement de qualification jetable avant d'atteindre le service réel.
Mesures
| Domaine | Mesure |
|---|---|
| Circuit de validation | Tout changement passe par une demande de fusion soumise aux validations de la chaîne d'intégration continue, puis par une étape de qualification avant la production (A.8.32). |
| Environnements de vérification | Chaque pipeline déploie un environnement de qualification éphémère, isolé dans son propre espace de noms, détruit à la fermeture de la demande de fusion ou à l'expiration de sa durée de vie. |
| Promotion en production | Déploiement en production et publication de versions restreints à la branche principale (A.8.4, partiel). |
| Configuration | Configuration d'infrastructure et applicative déclarative dans Git (Helm + Terraform), validée en intégration continue : un changement d'infrastructure suit le même circuit qu'un changement de code (A.8.9). |
| Séparation des tâches | Séparation formalisée entre développement, exploitation et validation des changements (A.5.3). |
| Dépendances | Montées de version des dépendances proposées automatiquement et soumises aux mêmes conditions de recette que tout autre changement : une mise à jour n'est intégrée que si la chaîne d'intégration est verte. |
| Traçabilité | Historique Git immuable, journaux de pipeline et environnements étiquetés par pipeline et par demande de fusion (A.5.28, partiel). |
Responsabilités
- Le RSSI (François-Guillaume Ribreau) est responsable de cette politique et arbitre les changements à fort impact sur la sécurité.
- L'auteur d'un changement en documente l'intention et l'effet attendu dans la demande de fusion.
- La validation d'un changement relève d'une personne distincte de son auteur, conformément à la séparation des tâches.
- Tout contournement du circuit, y compris en situation d'urgence, est signalé à security@france-nuage.fr et régularisé par une demande de fusion a posteriori.
Statut et trajectoire
Le circuit de gestion des changements et la séparation des tâches sont en place et opérationnels (A.8.32, A.5.3), de même que la gestion déclarative de la configuration qui les soutient (A.8.9). L'accès au code source reste partiel (A.8.4). La restriction du déploiement et des publications à la branche principale est effective, mais les réglages de protection de branche restent à documenter formellement.
Deux volets adjacents restent en cours de formalisation, la procédure de préservation des preuves au-delà de la journalisation et de l'historique Git déjà disponibles (A.5.28, partiel) et la revue de conformité périodique au niveau du SMSI (A.5.36, partiel).
Revue
Cette politique est revue au moins une fois par an et à chaque évolution significative de notre chaîne de livraison ou de nos environnements.
Dernière revue : 31 août 2026.
Voir aussi
- Déclaration d'applicabilité (le statut des contrôles A.5.3, A.8.4 et A.8.32)
- Politique de développement sécurisé (les conditions de recette que traverse chaque changement)
- Politique de gestion des actifs (l'inventaire et la configuration déclarative sur lesquels s'appuient les déploiements)
- Modèle de sécurité (la séparation des environnements et la chaîne d'approvisionnement logicielle)
- Politique de sécurité de l'information (le cadre du SMSI dont cette politique découle)