Pourquoi cette procédure est-elle indispensable ?

Sans procédure stricte, les développeurs ou les administrateurs pourraient modifier le système "en direct". Cela entraîne souvent :

• Des pannes inattendues (le fameux "ça marchait sur mon poste").
• Une impossibilité de revenir en arrière (pas de plan de secours).
• Une perte de traçabilité (on ne sait pas qui a modifié quoi ni pourquoi).
• Des conflits entre différentes équipes travaillant sur le même sujet.

Une procédure de gestion des changements et des développements (souvent appelée Change Management et Release Management dans le jargon ITIL) est un ensemble de règles et de processus formalisés visant à garantir que toute modification apportée à un système informatique, un logiciel ou une infrastructure est effectuée de manière contrôlée, efficace et sûre.

L'objectif principal est de permettre l'évolution des systèmes tout en minimisant les risques d'interruption de service ou de bugs en production :

• Stabilité : Assurer que les nouveaux développements ne cassent pas l'existant.
• Traçabilité : Avoir un historique complet des modifications (audit).
• Qualité : Garantir que tout changement a été testé avant d'être visible par les utilisateurs.
• Communication : Informer les parties prenantes des maintenances ou des nouvelles fonctionnalités.

Description du Processus (Cycle de Vie)

Ce processus couvre le cycle complet, de la demande utilisateur jusqu'au déploiement final en Production.

Phase 1 : Centralisation de la Demande

Toute demande d'évolution ou de correction doit être tracée.

• Entrée : Les demandes peuvent arriver par mail, par GLPI en cas d'anomalie. Dans le cas des de demandes d'évolutions, elle se font par atelier entre le métier et l'équipe de réalisation. Ensuite toutes les demandes sont mises en ticket sous Azure DevOps pour les développeurs.
• Règle impérative : Si une demande arrive par mail, elle doit obligatoirement être convertie en ticket Azure DevOps par le receveur avant toute action technique. Un développement ne démarre pas sans numéro de ticket Azure DevOps associé.
• Acteurs : Clients / Chef de Projet (CP).

Phase 2 : Développement (Flux Continu)

Cette phase est itérative et continue.

• Environnement : DEV.

• Processus :

  • Le développeur traite le ticket Azure DevOps.
  • Il effectue ses tests unitaires locaux.
  • Il déploie (ou le code est déployé automatiquement) sur l'environnement de DEV.

• Collaboration France/Nouvelle-Calédonie :

  • Pour les tâches complexes nécessitant une collaboration, les "Daily meetings" ou points de synchro se font sur les créneaux de recouvrement (matin France / fin de journée NC ou inversement).
  • Le ticket Azure DevOps doit être journellement mis à jour pour assurer le passage de relais sans perte d'information.

Phase 3 : Qualification au fil de l'eau

Dès qu'un développement est stable en DEV, il est poussé en Qualification.

• Environnement : QUAL.
• Fréquence : Continue (dès qu'une fonctionnalité est prête).
• Validation Fonctionnelle NCIT :
  • Le Chef de Projet (CP) teste la fonctionnalité sur l'environnement QUAL.
  • Si KO : Retour au développement (Phase 2).
  • Si OK : Le ticket Azure DevOps passe au statut "Validé pour prochaine Release".
• Validation Fonctionnelle Client :
  • Le Chef de Projet (CP) organise et assiste la recette avec le client. Il fournit un cahier de recette.
  • Si KO : Retour au développement (Phase 2).
  • Si OK : Le ticket Azure DevOps passe au statut "Validé pour prochaine Release".
• Stockage : Les développements validés s'accumulent sur cet environnement en attendant la fin de la version en cours ou du cycle de corrections.

Phase 4 : Préparation de la Release

À l'approche de la date de mise en production planifiée, on fige le périmètre.

• Gel de version (Code Freeze) : Une date est fixée (ex: J-7 avant la prod). Plus aucun nouveau développement n'est accepté en QUAL, sauf corrections de bugs critiques.
• Validation Globale (Go/No-Go) :
  • Le Chef de Projet passe en revue l'ensemble des tickets Azure DevOps validés durant la période.
  • Il vérifie la cohérence globale de la version.
  • Le GO : Le Chef de Projet donne son accord formel (par écrit dans un CR de COPRO ou de COPIL, ou par mail récapitulatif) pour déployer ce "paquet" de tickets en Production.

Phase 5 : Mise en Production (MEP)

Cette étape est critique car elle impacte les utilisateurs finaux.

• Environnement : PROD.

• Séparation des pouvoirs : Conformément à la politique interne, le développeur ayant codé les fonctionnalités ne peut pas déclencher seul la mise en production. L'action est réalisée par un profil autorisé (Lead Tech, Ops, ou un binôme sous supervision).

• Planification Géographique (Avantage Fuseau) :

  • La MEP est idéalement planifiée pour profiter du décalage horaire afin de minimiser l'impact utilisateur.
  • Exemple : Si les utilisateurs sont en France, l'équipe Nouvelle-Calédonie peut réaliser la MEP pendant la nuit française (leur journée de travail), assurant une disponibilité et une réactivité maximale sans fatigue nocturne.

• Procédure technique :

  • Sauvegarde préalable des bases de données (Snapshot).
  • Exécution des scripts de déploiement.
  • Vérification technique immédiate (Sanity Check).

Phase 6 : Clôture et Communication

• Notification : Le Chef de Projet informe les utilisateurs de la disponibilité des nouvelles fonctionnalités (Release Note basée sur les tickets Azure DevOps).
• Fermeture : Les tickets Azure DevOps associés sont passés au statut "Clos / En Production".

Procédure Spécifique : Correctif d'Urgence (Hotfix)

Utilisée uniquement en cas de bug bloquant ou faille de sécurité en Production. Elle contourne le cycle de 3 mois mais pas la sécurité.

• Alerte : Création d'un ticket Azure DevOps "Incident Critique".
• Qualification rapide : Reproduction du bug en QUAL ou DEV.
• Correction : Développement du correctif (Patch).
• Validation Express : Le Chef de Projet valide le correctif en QUAL immédiatement.
• Go MEP : Le Chef de Projet autorise le déploiement exceptionnel du Hotfix seul.
• Déploiement : Réalisé par l'équipe disponible (France ou NC selon l'heure de l'incident) pour rétablir le service au plus vite.
• Rétro-ingénierie : Le correctif est impérativement reporté sur l'environnement de DEV pour ne pas être écrasé lors de la prochaine mise à jour trimestrielle.