Chaque année, la même scène se répète dans les directions des systèmes d’information : mi-novembre, un correctif « simple » est poussé en production, et trois semaines plus tard le DAF découvre que le rapprochement des stocks ne tombe plus juste, en pleine préparation de l’inventaire. Personne n’a mal travaillé. Le changement était correct. Il est simplement arrivé au pire moment.
Le change freeze ERP, ou gel des changements, est la réponse à ce problème. Mais un gel mal conçu crée l’inverse de l’effet recherché : un backlog qui explose en janvier, des équipes qui contournent la règle, des correctifs de sécurité repoussés. Ce guide s’adresse aux DSI d’ETI, aux responsables applicatifs ERP et aux DAF. Il explique comment construire un calendrier de gel réaliste, quoi geler, quoi laisser passer, comment traiter les dérogations et les mises à jour SaaS imposées, puis comment dégeler proprement.
Pourquoi geler : les risques du changement en période sensible
Un changement en production n’est jamais neutre. Il l’est encore moins quand trois conditions se cumulent : les données sont figées par des échéances légales, les utilisateurs sont sous tension, et l’équipe qui sait corriger est en congés.
Pendant l’inventaire. Un changement de paramétrage de valorisation, de gestion des lots ou des emplacements en plein comptage fausse la comparaison entre stock théorique et stock physique. Pour les bonnes pratiques de comptage, voyez notre guide sur l’inventaire initial et tournant dans l’ERP.
Pendant la clôture. La clôture annuelle enchaîne des opérations irréversibles : amortissements, provisions, écritures de régularisation, verrouillage des périodes, report à nouveau. Modifier un plan de comptes, une règle d’imputation ou un interface bancaire pendant cette séquence expose à des écarts difficiles à expliquer aux commissaires aux comptes. Le détail de ces étapes figure dans notre checklist de clôture annuelle dans un ERP cloud.
Pendant les pics d’activité. Pour un distributeur ou un e-commerçant, la fin d’année concentre une grande part de l’activité : soldes, fêtes, campagnes promotionnelles. Une indisponibilité de quelques heures ou une régression sur le calcul des prix coûte alors beaucoup plus que le même incident en mars.
Avec des équipes réduites. Entre congés, fermetures de sites et indisponibilité des intégrateurs, la capacité de diagnostic baisse au moment où le risque monte.
Le gel n’a donc pas pour but d’arrêter l’évolution du système d’information. Il vise à réduire la probabilité et l’impact d’un incident sur une fenêtre où l’entreprise ne peut pas se le permettre.
Construire le calendrier de gel
Un bon calendrier ne part pas d’une date choisie au hasard. Il se construit en superposant trois séries de contraintes, puis en cherchant les fenêtres réellement disponibles.
Contraintes finance : inventaire, clôture, déclarations
Demandez au DAF et au responsable comptable un calendrier des échéances qui dépendent du système :
- la date de l’inventaire physique, par site si vous en avez plusieurs ;
- le début de la clôture des périodes intermédiaires (novembre, décembre) et celui de la clôture annuelle ;
- les déclarations fiscales et sociales de fin d’année (TVA, déclarations sociales) ;
- les échéances d’audit : intérim des commissaires aux comptes, remise des fichiers d’écritures ;
- les dates de verrouillage des périodes dans l’ERP.
Ces dates varient selon l’exercice comptable. Une entreprise à exercice décalé (clôture au 30 juin ou au 31 mars) appliquera la même logique à une autre période : le principe du gel suit le calendrier comptable, pas le calendrier civil.
Contraintes métier : soldes, fêtes, campagnes
Interrogez les directions commerciales, logistiques et e-commerce :
- opérations promotionnelles et événements commerciaux de la fin d’année ;
- pics de volumétrie sur les commandes, les expéditions et les retours ;
- fermetures de sites ou d’entrepôts, périodes de congés ;
- lancements produits ou ouvertures de marché prévus, qui peuvent justifier une exception pilotée.
L’objectif est de repérer la période où une panne coûte le plus cher, qui n’est pas toujours celle de la clôture. Pour un détaillant, c’est souvent la période commerciale. Pour un industriel, c’est l’arrêt de fin d’année et la reprise de janvier.
Contraintes éditeur : release waves et patchs imposés
Avec un ERP SaaS, une partie du calendrier ne vous appartient pas. Listez, pour chaque éditeur et chaque application satellite, les mises à jour planifiées entre novembre et février, les règles de report éventuelles et la fenêtre de maintenance contractuelle. Les cadences et possibilités de report diffèrent fortement d’un éditeur à l’autre : notre guide sur les mises à jour ERP SaaS et le release management les compare et explique comment les intégrer à votre plan annuel. Vérifiez toujours la documentation officielle de votre éditeur avant de figer le calendrier.
Exemple de calendrier type sur 10 semaines
Le tableau ci-dessous est illustratif. Il suppose un exercice calendaire, un inventaire début janvier et une activité commerciale marquée en fin d’année. À vous d’adapter les dates.
| Semaines | Phase | Règle de changement |
|---|---|---|
| S1 à S3 (mi-novembre à début décembre) | Pré-gel | Dernières mises en production planifiées ; revue des demandes en attente ; les nouveaux développements sont refusés sauf urgence |
| S4 (mi-décembre) | Gel strict, partie 1 | Aucun changement de paramétrage, de développement ni d’interface ; seules les dérogations validées passent |
| S5 à S6 (fêtes) | Gel strict, partie 2 | Même régime, avec équipe d’astreinte réduite et procédure de hotfix actualisée |
| S7 (début janvier) | Inventaire et début de clôture | Gel maintenu sur le périmètre finance et stocks |
| S8 | Clôture annuelle | Gel maintenu sur la comptabilité ; ouverture progressive des périmètres sans lien avec la clôture |
| S9 | Dégel progressif | Reprise par vagues du backlog, en commençant par les correctifs et les évolutions à faible risque |
| S10 | Retour au rythme normal | Bilan du gel, ajustement du processus pour l’année suivante |
Notez que le gel n’est pas le même pour tous les périmètres. Une vente à emporter en boutique n’a pas les mêmes contraintes que la consolidation comptable. Un calendrier par domaine fonctionnel (finance, supply chain, vente, RH) est presque toujours plus réaliste qu’un gel global.
Que geler et que laisser passer
Le « gel total » est la première erreur classique : il est irréaliste, donc il est contourné. Raisonnez par catégorie de changement et par niveau de risque.
| Catégorie | Position par défaut | Commentaire |
|---|---|---|
| Paramétrage fonctionnel (comptabilité, valorisation, tarification) | Gelé | Impact direct sur les écritures et les prix ; dérogation uniquement pour une erreur bloquante |
| Développements spécifiques et extensions | Gelé | Aucune mise en production ; les développements continuent en environnement de test |
| Interfaces et intégrations (banque, EDI, marketplace, transporteur) | Gelé, avec surveillance | Y compris côté partenaire : un changement chez un tiers peut casser l’échange sans que vous ayez rien touché |
| Droits et habilitations | Encadré | Les arrivées et départs restent traités ; pas de refonte de profils ; attention à la séparation des tâches pendant l’audit |
| Correctifs de sécurité critiques | Autorisé | Jamais gelé, mais passe par la procédure de dérogation avec test ciblé |
| Correctifs de bugs bloquants | Autorisé sur dérogation | Critère : l’activité ou une échéance légale est bloquée |
| Données de référence (articles, tiers) | Autorisé | Opérations courantes ; les modifications en masse sont traitées comme des changements |
| Environnements hors production | Libre | Développement, test et recette continuent : c’est ce qui prépare le dégel |
Deux points méritent une attention particulière. Le premier : les interfaces tierces, souvent oubliées. Votre ERP peut rester inchangé alors que votre banque, votre transporteur ou votre plateforme e-commerce modifie son format d’échange ou son API. Ajoutez ces partenaires à votre veille et demandez-leur leur propre calendrier de gel. Le second : les comptes à privilèges. Réduire les accès de changement en production pendant la période de gel est une mesure simple, qui rend le gel vérifiable plutôt que déclaratif.
Procédure de dérogation et hotfix
Un gel sans mécanisme d’exception ne tient pas. La première urgence réelle le fera voler en éclats, et les contournements informels seront pires que des dérogations encadrées. Prévoyez la procédure avant le début du gel.
Critères d’éligibilité. Une dérogation n’est recevable que si au moins l’un des critères suivants est rempli :
- une échéance légale, fiscale ou contractuelle est menacée ;
- une faille de sécurité critique est exploitable ;
- l’activité est bloquée, ou une perte financière significative est avérée ;
- l’absence de changement entraînerait un risque plus élevé que le changement lui-même.
« Le directeur commercial le veut pour lundi » n’est pas un critère. Cela relève du backlog de janvier.
Dossier minimal. Pour chaque demande : la description du changement, la raison de l’urgence, les processus impactés, le résultat des tests, le plan de retour arrière et le nom du demandeur.
Approbateurs. Prévoyez au minimum deux visas : le responsable applicatif ERP (faisabilité technique) et le propriétaire du processus métier concerné (finance ou supply chain, selon le cas). Pour les changements touchant les écritures, impliquez le DAF. Désignez des suppléants nommés pour la période des fêtes.
Plan de retour arrière. Aucune dérogation sans réponse précise à la question : « si cela échoue, comment revenons-nous à l’état précédent, en combien de temps, et qui décide ? ». Pour un correctif de code, cela peut être le rollback du transport. Pour un changement de paramétrage ou de données, c’est plus délicat : il faut avoir exporté l’état précédent. Un changement impossible à annuler exige un niveau de validation plus élevé.
Traçabilité. Chaque dérogation est consignée dans le registre des changements, avec date, décision et résultat. Ce registre servira à la revue post-gel et, le cas échéant, aux auditeurs.
Gérer les mises à jour SaaS imposées pendant le gel
C’est le point où le gel d’un ERP SaaS diffère de celui d’un ERP sur site. L’éditeur peut déployer une mise à jour pendant votre période sensible, et votre comité de changement n’a pas voix au chapitre.
Quatre leviers existent, à confirmer auprès de votre éditeur et dans votre contrat :
- Demander le report quand il est possible. Certains éditeurs permettent de décaler une mise à jour ou de choisir une fenêtre. Anticipez : les demandes de report ont souvent un délai limite.
- Contrôler l’activation des nouveautés. Même quand la mise à jour s’installe, les fonctions nouvelles peuvent rester désactivées par défaut. Maintenez-les désactivées pendant le gel.
- Lire les notes de version avant le déploiement. Repérez les changements qui touchent la finance, les interfaces et les API que vous utilisez. Les mises à jour qui modifient un comportement existant sont celles qui vous menacent.
- Cibler les tests de non-régression. Vous n’avez pas le temps de tout retester. Constituez une suite courte sur les processus critiques de la période : écritures comptables, valorisation des stocks, facturation, échanges bancaires et EDI, prise de commande. Pour automatiser ce socle, consultez notre article sur l’automatisation des tests de régression ERP avec l’IA.
Une mise à jour imposée qui tombe pendant le gel doit être traitée comme un changement d’urgence à observer, pas comme un événement subi : lancez la suite de non-régression ciblée dès que la mise à jour est appliquée à votre environnement de test ou de préproduction, puis surveillez la production de près dans les jours suivants. Prévoyez aussi l’inscription de la mise à jour dans le registre, comme toute autre modification.
Communication et gouvernance
Un gel fonctionne quand tout le monde sait ce qu’il couvre et à qui s’adresser. Quelques règles simples suffisent.
Annoncer tôt et clairement. Communiquez les dates, le périmètre et la procédure de dérogation au moins six semaines avant le début du gel. Précisez ce qui reste possible : cela évite l’impression d’un blocage général.
Un comité de changement resserré. Pendant la période de gel, un comité court (quinze à trente minutes, une ou deux fois par semaine) traite les demandes de dérogation et revoit les incidents. En dehors de ces rendez-vous, un canal d’urgence unique et connu.
Un RACI explicite.
| Activité | DSI | Resp. applicatif ERP | DAF | Resp. process métier | Intégrateur / TMA |
|---|---|---|---|---|---|
| Définir le calendrier de gel | A | R | C | C | I |
| Valider les contraintes finance | I | C | A/R | C | I |
| Instruire une dérogation | I | R | C | A | C |
| Approuver une dérogation sensible | A | R | R | C | I |
| Appliquer le hotfix et le retour arrière | I | A | I | I | R |
| Suivre les mises à jour éditeur | I | A/R | I | I | C |
| Bilan et dégel | A | R | C | C | C |
R : réalise, A : approuve, C : consulté, I : informé.
Impliquer les prestataires. Alignez le contrat de TMA et les engagements de l’intégrateur sur le calendrier : disponibilité pendant les fêtes, délai de réponse en cas de dérogation, interdiction de livrer sans accord. Faites de même avec les éditeurs des applications satellites (paie, e-commerce, WMS).
Le dégel : janvier, backlog accumulé, ordre de reprise
Le gel crée mécaniquement un backlog. Le dégel est la phase où beaucoup d’organisations reproduisent l’incident qu’elles voulaient éviter : tout est livré en même temps, la première semaine de janvier, avec des équipes qui reviennent de congés.
Pour l’éviter :
- Attendre la fin des opérations sensibles. Le dégel du périmètre finance n’intervient qu’après la clôture et le verrouillage des périodes. Les périmètres sans lien avec la clôture peuvent rouvrir plus tôt.
- Trier le backlog. Classez les demandes accumulées : correctifs, évolutions réglementaires, évolutions métier, confort. Les obligations légales de l’année qui commence passent en premier.
- Livrer par vagues. Une vague par semaine, avec un périmètre limité et une surveillance renforcée. Ne mélangez pas dans la même vague un correctif financier et une évolution de la chaîne logistique.
- Rejouer la suite de non-régression avant chaque vague, en particulier si une mise à jour éditeur a été absorbée pendant le gel.
- Faire le bilan. Combien de dérogations ? Lesquelles étaient justifiées ? Quel changement a causé un incident ? Quelle demande aurait dû passer avant le gel ? Ce retour d’expérience nourrit le calendrier de l’année suivante.
Les erreurs à éviter
- Le gel total. Si rien ne peut passer, tout passera en dehors du processus. Distinguez les catégories.
- Aucune dérogation prévue. La première urgence détruit la crédibilité du dispositif. La procédure doit exister avant le gel.
- L’oubli des interfaces tierces. Banque, transporteur, marketplace, administration : leur calendrier compte autant que le vôtre.
- Un gel décidé par la seule DSI. Sans le DAF et les métiers, les dates ne reflètent pas les vraies contraintes.
- Un dégel brutal. Le backlog livré d’un bloc concentre le risque sur une seule semaine.
- Pas de bilan. Sans retour d’expérience, le gel de l’année suivante répétera les mêmes défauts.
Modèle de calendrier et checklist
Trois phases à instruire en équipe, avec une personne nommée par ligne.
Avant le gel (au moins six semaines avant)
- Les échéances finance (inventaire, clôture, déclarations, audit) sont collectées auprès du DAF
- Les pics d’activité métier et les fermetures de sites sont recensés
- Les mises à jour éditeur prévues sont listées, avec les possibilités de report
- Le calendrier de gel est défini par domaine fonctionnel et validé par la DSI, le DAF et les métiers
- La procédure de dérogation, les critères, les approbateurs et leurs suppléants sont écrits
- La suite de non-régression ciblée est à jour
- Les partenaires (banque, transporteur, intégrateur, éditeurs) ont communiqué leurs propres gels
Pendant le gel
- Les accès de changement en production sont restreints
- Le comité de changement se réunit selon le rythme prévu
- Chaque dérogation est consignée avec son plan de retour arrière
- Les mises à jour éditeur sont testées sur le périmètre critique et tracées
- Les interfaces tierces et les traitements nocturnes sont surveillés
Au dégel
- La clôture et le verrouillage des périodes sont confirmés avant d’ouvrir le périmètre finance
- Le backlog est trié et planifié par vagues
- La non-régression est rejouée avant chaque vague
- Le bilan du gel est partagé et le processus ajusté
Pour aller plus loin
Pour structurer votre gouvernance du changement et votre prochain choix de solution avec méthode, téléchargez notre grille d’évaluation ERP : 30 critères sur 100 points pour comparer trois éditeurs côte à côte, dont la capacité à tenir un calendrier de releases maîtrisé.
