Conception
Chaque évolution qualifie sa finalité, ses utilisateurs, données, accès, dépendances, risques, erreurs possibles, exigences contractuelles et conditions de sortie. Sécurité, protection des données, accessibilité et supervision humaine sont intégrées avant le développement, pas ajoutées après coup.
Référence et demande de changement
La demande identifie l’état de départ, le résultat attendu, le périmètre, le responsable, la priorité et les impacts sur prix, délais, données, permissions, SLA, licences et documentation. Une conversation informelle ne suffit pas à modifier un engagement ou à autoriser une production.
Environnements séparés
Développement, test, préproduction et production sont séparés selon le risque. Les accès, secrets, domaines, bases et fournisseurs sont explicitement qualifiés ; un outil de test ne reçoit pas par défaut les mêmes droits que la production.
Données de test
Les tests utilisent prioritairement des données fictives, synthétiques ou réellement anonymisées. Un recours exceptionnel à des données réelles exige une nécessité documentée, un environnement protégé au niveau approprié, des accès restreints, une durée limitée et une suppression vérifiée.
Code, secrets et dépendances
Les secrets sont exclus du code, des tickets, journaux et jeux d’essai. Les composants suivent le registre Logiciels et services tiers et la politique Vulnérabilités et correctifs. Les sources et artefacts de livraison sont versionnés et leur provenance contrôlée.
Revue et séparation des tâches
Les changements sensibles font l’objet d’une revue proportionnée par une autre personne ou d’un contrôle compensatoire explicite lorsqu’une petite équipe ne permet pas cette séparation. L’auteur ne transforme pas seul un échec de contrôle en validation.
Tests
Selon le changement : tests unitaires, intégration, fonctionnels, sécurité, permissions, isolation des organisations, migrations, performances, accessibilité, non-régression et restauration. Les critères sont définis avant la décision ; un build réussi ne démontre pas à lui seul l’aptitude métier.
Migrations de données
Toute migration prévoit inventaire, sauvegarde, correspondance des champs, droits, doublons, contrôle de volume, rapprochement, retour arrière et preuve. Les données supprimées, oppositions et restrictions ne sont pas réintroduites silencieusement.
Porte de production
La mise en production identifie la version, les validations, la fenêtre, le responsable, les dépendances, la sauvegarde, le retour arrière, la surveillance, les contacts et la communication utile. Les points bloquants restent visibles ; aucune urgence commerciale ne les efface sans décision de risque documentée.
Changement urgent
Une mesure de sécurité urgente peut suivre un circuit raccourci avec périmètre minimal, approbation disponible, sauvegarde, surveillance et retour arrière. Elle est régularisée, revue et testée après stabilisation ; l’urgence répétée déclenche une action corrective.
Après déploiement
Les indicateurs, erreurs, journaux et retours sont surveillés pendant une période adaptée. Une anomalie entraîne correction, retrait, mode dégradé ou retour arrière. La documentation, l’inventaire, les conditions de solution et le dossier contractuel sont mis à jour lorsque le changement les affecte.
Porte de validation
Avant publication : finalité, risque, référence, revue, environnements, données de test, secrets, dépendances, tests, migrations, sauvegarde, retour arrière, surveillance, documentation et autorisation sont contrôlés. Une fonction visible ou un déploiement techniquement réussi ne vaut ni recette client ni conformité complète.
Références
CNIL — Encadrer les développements · CNIL — Tester les applications · ANSSI — S-SDLC et DevSecOps.