Faire tourner deux ERP n’est pas une assurance, c’est un coût : il faut savoir ce qu’on veut prouver. Trop de comités de pilotage décident un « run parallèle » par réflexe de prudence, sans définir ce qui sera comparé, par qui, avec quelle tolérance et à quelle condition on s’arrête. Résultat : des équipes qui saisissent tout deux fois pendant des semaines, des écarts que personne ne sait expliquer, et une bascule décidée à l’usure plutôt que sur des preuves.
Ce guide s’adresse aux DSI, chefs de projet et DAF d’ETI. Il ne reprend pas le déroulé du cutover de J-30 à J-3 ni le décommissionnement de l’ancien système : il traite la question qui les précède, à savoir s’il faut doubler, quoi, combien de temps, et comment en sortir.
Run parallèle : définition et différence avec big bang, phasé et pilote
Un run parallèle (ou dual-run) consiste à exploiter un même processus métier simultanément dans l’ancien et le nouveau système pendant une période définie, puis à comparer les résultats. L’ancien système reste le système de référence officiel ; le nouveau est « en observation ». À la fin, on bascule la référence, ou on corrige et on recommence.
Il ne faut pas le confondre avec les trois autres stratégies de bascule :
- Big bang : tout le périmètre passe sur le nouvel ERP à une date donnée. Aucune coexistence, sauf l’accès en lecture à l’ancien.
- Phasé : on bascule par module, par entité ou par pays, successivement. Chaque lot est en big bang, mais le projet est découpé.
- Pilote : une entité ou un site réel passe en production sur le nouveau système, les autres restent sur l’ancien. C’est de la production réelle, pas de la comparaison.
- Parallèle : les mêmes opérations sont traitées deux fois, pour prouver que le nouveau système donne les mêmes résultats.
La nuance est importante : le pilote et le phasé exposent la production à un risque limité, le parallèle ne l’expose pas mais coûte du temps humain.
Ce que « parallèle » veut dire selon le domaine
Le mot recouvre des réalités très différentes :
- Paie : on calcule les mêmes bulletins dans les deux systèmes à partir des mêmes variables, puis on compare salarié par salarié et rubrique par rubrique. Le système officiel reste l’ancien tant que la comparaison n’est pas validée. Les éditeurs et intégrateurs décrivent la même pratique : sur les projets de paie SAP, Rizing note que le contrat prévoit typiquement deux cycles de paie parallèles.
- Comptabilité : on rejoue une clôture mensuelle (écritures, rapprochements, balance) dans le nouveau système et on compare balance générale, balance auxiliaire et états de TVA.
- Facturation : on génère les factures dans le nouvel outil en « blanc » (non émises) et on les compare à celles réellement émises.
- Stocks et logistique : le parallèle est généralement impossible tel quel (voir plus bas). On le remplace par des inventaires de bascule et des contrôles de cohérence.
Quand le run parallèle est justifié (et quand c’est un piège)
Critères de décision
Quatre critères suffisent à trancher, processus par processus :
- Criticité : une erreur a-t-elle un effet immédiat et irréversible vis-à-vis d’un tiers (salarié payé de travers, déclaration fiscale erronée, client mal facturé) ?
- Réversibilité : peut-on corriger après coup sans dommage ? Une paie rectifiée le mois suivant reste visible des salariés ; une écriture comptable corrigée avant clôture ne l’est pas.
- Volume et complexité des règles : plus il y a de règles (conventions collectives, taux de TVA multiples, consolidation), plus la comparaison apporte de valeur, car les tests unitaires ne couvrent pas toutes les combinaisons.
- Obligations légales : paie, déclarations sociales, TVA, clôture. Le calendrier légal ne bouge pas parce que le projet dérape.
Règle simple : le parallèle se justifie quand le calcul est complexe, vérifiable par comparaison, et que l’erreur est coûteuse à corriger. Il devient un piège quand le processus est un flux temps réel, quand personne ne peut dire ce qu’est un « bon » résultat, ou quand l’équipe n’a pas la capacité de traiter deux fois le même volume.
Tableau : big bang, phasé, pilote ou parallèle
| Critère | Big bang | Phasé | Pilote | Parallèle (sur un périmètre) |
|---|---|---|---|---|
| Risque de production | Élevé, concentré | Moyen, étalé | Limité à une entité | Faible (l’ancien système fait foi) |
| Charge équipe | Pic au moment de la bascule | Répartie, longue | Moyenne, avec double support | Forte et continue pendant la période |
| Durée de coexistence | Aucune | Longue | Longue | Courte et bornée (1 à 3 cycles) |
| Coût direct | Faible | Interfaces temporaires | Interfaces temporaires | Renforts et heures de double saisie |
| Ce qu’on prouve | Rien avant la bascule | Chaque lot indépendamment | Le système en conditions réelles | L’exactitude des calculs |
| Cas typique | PME, périmètre simple | ETI multi-entités | Groupe multi-pays | Paie, clôture, TVA |
Ces stratégies ne s’excluent pas. Le montage le plus courant en ETI : un phasé ou un big bang pour les flux opérationnels, avec un parallèle ciblé sur la paie et la clôture.
Périmètre : quoi doubler, quoi ne jamais doubler
À doubler en priorité
- La paie, sur un ou deux cycles complets, y compris un mois avec des événements particuliers (primes, sorties, absences longues).
- La clôture mensuelle comptable, avec rapprochements bancaires, immobilisations, régularisations et déclaration de TVA. Notre checklist de clôture mensuelle donne la trame des contrôles à comparer.
- Les calculs de reporting réglementaire (liasse, états fiscaux) si les règles de gestion ont été redéveloppées.
À ne jamais doubler
- Les flux clients et fournisseurs (EDI, factures électroniques, commandes) : envoyer deux fois un même document à un tiers crée des doublons, des litiges et de la confusion. On teste ces flux en environnement de recette avec le partenaire, pas en production double.
- Les stocks en temps réel : deux systèmes qui décrémentent le même stock physique divergent dès la première exception (casse, retour, transfert). On fige, on inventorie, on bascule.
- Les paiements et prélèvements : un seul système émet les ordres de paiement. Le second ne produit que des fichiers de comparaison, jamais transmis à la banque.
- Les processus à effet de bord externe : tout ce qui déclenche une action chez un tiers (envoi de documents, appel d’API, notification légale).
Le principe : on double le calcul, jamais l’effet. Le nouveau système calcule, compare et se tait.
Méthode de réconciliation
Sans méthode, le parallèle produit des dizaines d’écarts sans diagnostic. Une méthode éprouvée tient en quatre éléments.
1. Jeux de test figés. Avant le démarrage, on fixe les populations de test : tous les salariés ou un échantillon représentatif de chaque cas particulier (temps partiel, cadre au forfait, expatrié) ; pour la compta, toutes les sociétés ou les plus complexes. Rizing recommande de démarrer petit et tôt, en validant l’extraction des cumuls et les outils de comparaison pendant les tests unitaires, pas au premier cycle parallèle.
2. Tolérances d’écart définies à l’avance. On décide par écrit ce qui est un écart acceptable : arrondi de centimes sans impact, ou écart nul exigé sur les montants nets à payer et la TVA. Sans seuil explicite, chaque écart devient une discussion.
3. Rapports de rapprochement quotidiens ou par cycle. Pour chaque domaine, un rapport standard : nombre d’objets comparés, nombre d’écarts, valeur cumulée des écarts, cause. Le même format tous les jours, produit par la même personne, permet de voir la tendance.
4. Classification des causes. Chaque écart reçoit une cause parmi un petit nombre de catégories : donnée migrée erronée, paramétrage, règle de gestion mal spécifiée, interface, écart attendu (l’ancien système avait un défaut). Seule la classification permet de savoir si on converge.
Indicateurs d’écart à suivre
- Nombre d’écarts ouverts, par domaine et par jour.
- Valeur de ces écarts (en euros, et en part du total traité).
- Cause dominante, pour orienter les corrections.
- Délai moyen de résolution et nombre d’écarts qui réapparaissent après correction.
Un parallèle qui converge se reconnaît à ceci : le nombre d’écarts diminue d’un cycle à l’autre, et les causes restantes sont rares et comprises.
Durée recommandée par domaine
Il n’existe pas de durée universelle ; voici des ordres de grandeur de pratique, à adapter à la complexité :
| Domaine | Durée de pratique | Remarque |
|---|---|---|
| Paie | 1 à 2 cycles mensuels complets | Prévoir un cycle de rattrapage si le premier révèle des erreurs de fond |
| Clôture comptable | 1 à 2 clôtures mensuelles | Idéalement dont une avec TVA et une avec régularisations |
| Facturation (en blanc) | Quelques jours à un cycle de facturation | Surtout pour les règles de remise et de taxe |
| Consolidation | 1 clôture trimestrielle si les périmètres l’exigent | Coûteux, à réserver aux groupes |
| Stocks, EDI | Pas de parallèle | Inventaire de bascule et recette partenaire |
Coût caché : double saisie, fatigue, renfort
La part visible du budget est l’infrastructure et les licences de l’ancien système, que de toute façon on conserve. Le vrai coût est humain :
- La double saisie : les gestionnaires de paie ou les comptables traitent tout deux fois, en plus de leur charge courante. Si l’équipe n’a aucune marge, le parallèle dégrade la qualité du système officiel, ce qui est l’inverse de l’objectif.
- La fatigue : le parallèle se fait aux moments les plus chargés (paie, clôture). Au deuxième cycle, l’attention baisse et les écarts sont rapprochés trop vite, ou classés « sans importance ».
- Les compétences rares : la personne qui sait expliquer un écart de paie dans l’ancien système est souvent la même qui valide le nouveau.
Budgétez donc des renforts explicites (intérim comptable ou paie, consultant de l’intégrateur, ressource de back-fill pour libérer les experts) plutôt que de supposer que l’équipe « absorbera ». C’est ce que le prestataire omet de chiffrer lorsqu’il propose « deux cycles de parallèle » dans son offre. Et précisez dans le contrat qui, du client ou de l’intégrateur, produit les rapports de comparaison : l’ambiguïté de responsabilité est un des pièges identifiés par Rizing.
Matrice de responsabilités
| Activité | DAF / DRH | Chef de projet | Key users | Intégrateur | DSI |
|---|---|---|---|---|---|
| Définir le périmètre et les tolérances | A | R | C | C | I |
| Produire les données de test | I | A | R | C | C |
| Exécuter les deux traitements | I | I | R | C | I |
| Produire le rapport de comparaison | C | A | R | R | C |
| Analyser et classer les écarts | C | A | R | R | I |
| Corriger paramétrage et données | I | A | C | R | R |
| Décision go/no-go | A | R | C | C | C |
(R : réalise, A : approuve, C : consulté, I : informé.)
Critères de sortie (go/no-go) et plan de retour arrière
Le parallèle doit finir par une décision, pas par une lassitude. Fixez les critères avant le démarrage :
- Écart nul (ou sous le seuil convenu) sur les montants à payer, les montants de TVA et les soldes de trésorerie.
- Tous les écarts restants sont expliqués et classés, aucun « inconnu ».
- Tendance : au moins deux relevés consécutifs sans nouvelle cause d’écart.
- Les utilisateurs clés ont signé la validation de leur périmètre.
- Les ressources de la période de bascule sont disponibles (le parallèle ne doit pas avoir épuisé l’équipe avant le go-live).
Si les critères ne sont pas atteints, trois options : prolonger d’un cycle (une fois, pas plus), réduire le périmètre de bascule, ou reporter. Un report assumé coûte moins qu’une paie erronée.
Plan de retour arrière. Tant que l’ancien système fait foi, le retour est trivial : on abandonne le nouveau. Le point critique est le moment où la référence bascule. À partir de là, il faut une réversibilité documentée : sauvegarde figée de l’ancien système, accès maintenu, règle claire sur le délai au-delà duquel le retour n’est plus possible (par exemple après la première paie réelle versée ou la première déclaration de TVA déposée). Cette fenêtre doit apparaître dans le plan de cutover.
Articulation avec la recette (UAT) et l’hypercare
Le parallèle n’est pas la recette. La recette UAT vérifie que le système fait ce qui est spécifié, sur des scénarios construits. Le parallèle vérifie qu’il donne les mêmes résultats que l’ancien sur des données réelles. L’un ne remplace pas l’autre : un parallèle lancé avant la fin de l’UAT passe son temps à découvrir des anomalies de paramétrage.
Après la bascule, la phase d’hypercare prend le relais : le premier cycle réel de paie ou de clôture reste sous surveillance renforcée, avec les rapports d’écart du parallèle comme base de référence.
Cas typique : paie et clôture mensuelle sur un à deux cycles
Une ETI industrielle de plusieurs centaines de salariés migre sa comptabilité et sa paie vers un nouvel ERP. Elle choisit un big bang pour les achats, les ventes et les stocks, et un parallèle uniquement sur la paie et la clôture.
- M-3 à M-2 : jeux de test figés, outil de comparaison validé sur un échantillon de salariés, tolérances écrites.
- M-1 (premier cycle) : la paie est calculée dans les deux systèmes. L’ancien paie réellement. Les écarts sont classés ; la majorité vient de données migrées (cumuls, congés) et d’une règle de prime mal paramétrée.
- M (second cycle) : après correction, nouveau calcul. Écarts résiduels expliqués. La clôture comptable est rejouée en parallèle, avec rapprochement de balance.
- Comité go/no-go : critères atteints, validation signée par la DRH et le DAF, bascule de la référence au cycle suivant.
- M+1 : première paie réelle sur le nouvel ERP, hypercare renforcée.
Ce qui rend ce cas efficace : un périmètre étroit, des critères écrits et un renfort budgété pendant deux cycles.
Cinq erreurs fréquentes et contre-mesures
- Lancer le parallèle trop tôt, avant que la recette soit terminée. Contre-mesure : condition d’entrée explicite (UAT validée, données migrées de qualité).
- Tout doubler « par prudence ». Contre-mesure : appliquer les quatre critères de décision processus par processus et refuser le parallèle sur les flux à effet externe.
- Aucun seuil d’écart ni critère de sortie. Contre-mesure : tolérances et critères go/no-go signés avant le premier jour.
- Épuiser l’équipe. Contre-mesure : renforts budgétés, périodes de parallèle hors pics, pas plus de deux cycles sans décision.
- Comparer sans expliquer. Contre-mesure : chaque écart a une cause classée ; un écart « inconnu » bloque la sortie.
Checklist à copier
- Processus candidats évalués sur les quatre critères (criticité, réversibilité, volume, légal)
- Périmètre doublé écrit ; processus exclus listés (EDI, stocks, paiements)
- Condition d’entrée : UAT validée, données migrées contrôlées
- Jeux de test et outil de comparaison validés avant le premier cycle
- Tolérances d’écart écrites et signées
- Renforts budgétés et responsable du rapport de comparaison nommé
- Indicateurs suivis : nombre, valeur, cause, délai de résolution
- Critères go/no-go et durée maximale fixés d’avance
- Plan de retour arrière avec date limite de réversibilité
- Transfert des rapports d’écart vers l’équipe d’hypercare
Pour aller plus loin
Téléchargez notre checklist et nos grilles d’évaluation ERP pour cadrer votre bascule, et relisez en complément la checklist de cutover J-30 à J-3 et le guide de recette UAT.
