Bascule ERP : préparer le calendrier et le retour arrière

Une bascule ERP doit définir qui décide, quelles données sont figées et quels contrôles autorisent l’ouverture. Préparez un déroulé avec des points d’arrêt, un traitement des opérations en attente et un retour arrière réaliste. Une date de lancement ne suffit pas : les conditions qui rendent cette date tenable doivent être vérifiées avant la fenêtre de bascule.

Construire un déroulé de dépendances

Listez les étapes dans leur ordre réel : arrêt de certaines saisies, extraction, import, rapprochement, ouverture des accès et reprise d’activité. Attribuez un responsable et un remplaçant à chacune. Ajoutez les dépendances externes, comme la disponibilité d’une application connectée ou d’un intervenant. Une durée estimée doit être issue d’un essai ou signalée comme hypothèse. Prévoyez des marges fondées sur les risques identifiés, pas une réserve indistincte. Le déroulé doit être assez clair pour qu’une autre personne puisse comprendre où le projet se trouve et ce qui bloque.

Définir le gel et les opérations en attente

Précisez quelles données ne pourront plus être modifiées et à partir de quel moment. Les commandes, livraisons ou paiements qui surviennent pendant la fenêtre doivent avoir une procédure de traitement. Évitez une double saisie non rapprochée entre ancien et nouveau système. Si un registre temporaire est utilisé, attribuez sa tenue et son contrôle. Les équipes doivent savoir comment signaler une urgence et qui peut autoriser une exception. Une bascule technique réussie peut néanmoins produire des données incohérentes si ces opérations transitoires ne sont pas maîtrisées.

Préparer les contrôles avant ouverture

Les contrôles doivent couvrir données, fonctions indispensables, droits et interfaces. Utilisez les rapprochements validés pendant les répétitions et ajoutez un échantillon d’opérations de bout en bout. Définissez les écarts qui interdisent l’ouverture et ceux qui peuvent faire l’objet d’une réserve. La décision ne doit pas dépendre d’une personne isolée qui affirme que « tout semble bon ». Rassemblez les résultats et faites intervenir les responsables concernés. Si un contrôle prend plus de temps que prévu, le calendrier doit permettre d’appliquer le point d’arrêt préparé.

Rendre le retour arrière praticable

Un plan de retour arrière indique comment rétablir l’ancien fonctionnement et préserver les opérations réalisées pendant l’essai. Vérifiez les sauvegardes, les accès et la possibilité réelle de redémarrer. La décision de retour doit intervenir avant un seuil où les données deviennent trop difficiles à réconcilier. Demandez une répétition adaptée à l’enjeu et notez ses limites. Un fichier de sauvegarde non testé ne prouve pas que l’activité pourra reprendre. Les responsabilités du prestataire et de votre équipe doivent être définies, ainsi que les communications aux utilisateurs.

Organiser les premiers jours

Après ouverture, surveillez les processus critiques et les interfaces. Prévoyez des personnes capables de qualifier les incidents et de distinguer blocage technique, difficulté d’usage et défaut de données. Faites un point régulier sur les réserves et les corrections. Évitez d’ajouter des évolutions non urgentes pendant cette stabilisation. Les utilisateurs doivent connaître un canal d’aide unique, même si plusieurs acteurs interviennent derrière. Conservez un journal des décisions et des corrections qui modifient les données. La fin de la période renforcée doit être décidée sur des critères de fonctionnement, pas seulement sur une date.

Exemple de travail

Exemple de planning illustratif : l’extraction commence après le gel, puis l’import ne démarre qu’après vérification des fichiers. Un contrôle bloquant constate que certaines pièces jointes ne sont pas accessibles. Le responsable applique le point d’arrêt prévu au lieu d’ouvrir les accès pour respecter la date annoncée. Selon le plan, l’équipe corrige dans la fenêtre restante ou revient au fonctionnement précédent. Aucune durée universelle n’est proposée ici : elle dépend de vos essais, des données et des systèmes. Le scénario montre surtout l’utilité d’une décision préparée avant que la pression du lancement n’apparaisse.

Fiche de vérification

Élément	Question à documenter	Preuve ou responsable
Gel	Données et heure de coupure	Responsable de l’ancien système
Reprise	Extraction et import	Journaux et rejets
Décision	Contrôles bloquants	Autorité de lancement
Stabilisation	Support renforcé	Critères de sortie

À faire dans votre équipe

Faites une réunion de répétition sur table : chaque participant annonce ce qu’il ferait à son étape et le résultat qu’il transmettrait au suivant. Introduisez un incident plausible, comme un import plus lent ou une interface indisponible. Vérifiez si le plan indique encore une décision claire. Notez les numéros, accès ou validations manquants et corrigez le déroulé. Demandez aussi qui informe les équipes si le lancement est reporté. Cette simulation ne remplace pas les essais techniques, mais elle révèle les dépendances humaines souvent oubliées. Gardez une version unique du plan et évitez que plusieurs calendriers contradictoires circulent le jour de la bascule.

Questions fréquentes

Faut-il toujours basculer un week-end ?

Aucune règle universelle ne s’applique. Choisissez une fenêtre compatible avec l’activité, les volumes, les personnes disponibles et les dépendances externes.

Une répétition garantit-elle le lancement ?

Non. Elle permet d’identifier des limites et d’améliorer les estimations. Les données finales et les conditions réelles doivent encore être contrôlées.

Qui décide de revenir en arrière ?

Une autorité doit être nommée avant la bascule, avec des critères et un moment limite de décision. Elle s’appuie sur les responsables métier et techniques concernés.

Pour poursuivre

Sources et portée

CNIL — rôles des acteurs du cloud — référence officielle consultée le 30 octobre 2026.

Les démarches, tableaux et scénarios sont des propositions de méthode propres à ce guide. La référence officielle permet de vérifier les conditions ou notions mentionnées ; elle ne valide pas les hypothèses chiffrées illustratives et ne constitue pas un classement de produits.