Itération et cadence de releases

Affiner · 6.2

Pourquoi cela compte maintenant

Deux schémas fréquents après le go-live : (1) plus rien ne change (« on est en prod, fini ») et (2) tout change ad hoc (chaque changement est une crise). Les deux mènent à l’arrêt ou au chaos. Une cadence de releases est le moyen d’éviter les deux — petits changements, prévisibles, avec les mêmes étapes.

Que livrez-vous ?

Calendrier de releases

Rythme fixe (par ex. premier mardi du mois) avec scope et fenêtres de gel.

Flux RFC

Modèle Request for Change : demande → triage → impact → approbation → release.

Stratégie de test

Environnement de recette + smoke tests par release, avec sign-off par service owner.

Modèle de communication

Ce qui change, quand, pour qui — release notes que les utilisateurs comprennent.

Trois types de changement — trois cadences

Petit et sûr

Au besoin

Ajouter un champ, publier un article KB, modifier un modèle. Le propriétaire le pousse et le consigne au registre des changements.

Moyen

Release mensuelle

Modification de workflow, extension de classification, nouveau rapport. Flux RFC, test de recette, communication.

Grand / structurel

Release trimestrielle

Activer un nouveau module, ajouter une intégration, faire passer l'IA au niveau suivant. Mini-projet, décision du comité de pilotage.

Questions clés

1Quel rythme convient — sprint (2 sem.), mensuel ou trimestriel pour la couche « moyenne » ? Combien de changement les utilisateurs peuvent-ils absorber ?
2Qui fait le triage des change requests entrantes ? Quels critères (impact × fréquence × effort) utilisez-vous ?
3Approbation — quel change board approuve quoi ? Quels changements un admin peut-il faire seul, lesquels exigent le sponsor ?
4Environnement de recette — en avez-vous un ? Comment synchronisez-vous la config production vers test ? Combien de temps testez-vous avant la production ?
5Smoke tests par release — un jeu minimal de scénarios qui doit toujours passer, quel que soit le contenu de la release.
6Roll-back par changement — particulièrement pour les ajustements de workflow : pouvez-vous revenir en arrière si le comportement tourne mal ?
7Release notes — qui les écrit, dans quelle langue, à quel niveau de détail ? Pour les utilisateurs : court et dans leur langue. Pour les admins : détail technique.
8Moments de gel — pas de changements pendant la semaine d'audit, la clôture fiscale, la période de fin d'année ? Verrouillez dans le calendrier.
9Backlog — où vit la liste des change requests ouvertes ? Qui priorise, à quelle fréquence ?
10Mises à jour produit de Gfacility — lire les release notes, vérifier les régressions, informer les utilisateurs finaux. Qui possède ce rythme ?

Modèle — Fiche RFC

Champ	Valeur exemple
Titre	Ajouter la catégorie « assistant IA » au flux ticket IT
Demandeur / service owner	Sara Janssen (Service manager)
Type	Moyen — extension de classification
Pourquoi	15 % des tickets concernent Copilot/outils IA, actuellement « autre »
Impact	Reporting, règle de routage IA, tags KB
Risques	Les tickets « autre » existants doivent être reclassifiés
Roll-back	Désactiver la catégorie — les tickets existants gardent leur valeur
Release proposée	Release mensuelle de novembre
Approbation	CAB (service mgr, configurateur, PM) — pas besoin du sponsor

Modèle — Calendrier de releases

Mois	Date de release	Gel de/à	Focus du scope	Communication
Oct.	Mar 7 oct. 20 h 00	Ven 3 oct. — Mer 8 oct. 9 h 00	Modifications de workflow IT	Release notes ven.
Nov.	Mar 4 nov. 20 h 00	Ven 31 oct. — Mer 5 nov. 9 h 00	Extension de classification	Release notes ven.
Déc.	— (aucune)	Tout le mois	Gel pour la clôture annuelle	Annonce fin nov.
Jan.	Mar 13 jan. 20 h 00	Ven 9 jan. — Mer 14 jan. 9 h 00	Release trimestrielle : nouveau tableau de bord	Release notes + session de briefing
…	…	…	…	…

← Suivi des KPI et tableaux de bord Suivant : Activer et mettre l'IA à l'échelle →