Comment sécuriser une migration Cassiopae : 6 étapes

Sécuriser une migration Cassiopae (upgrade V3.x vers V4.11), c’est réduire le risque d’un go-live raté : régressions fonctionnelles, reprise de données incomplète, dépassement de planning, indisponibilité prolongée au démarrage. La méthode s’articule autour de 6 étapes : (1) diagnostic d’entrée, (2) cartographie technique et fonctionnelle, (3) stratégie de bascule (big bang, phased ou parallel run), (4) plan de tests à 5 niveaux (cycle en V), (5) plan de reprise de données et de rollback, (6) go-live, cutover et hypercare. Sur une migration type d’un grand compte, comptez 12 à 24 mois calendaires, un budget projet entre 1,5 et 8 M€ HT, et une équipe mixte de 15 à 40 personnes (client + intégrateur + éditeur). Les trois causes d’échec les plus fréquentes : sous-estimation des interfaces, plan de tests incomplet, absence de plan de rollback documenté et testé.

Par Mohamed Ali Ksouri, Directeur Associé i-lead Consulting Co-fondateur d’i-lead Consulting depuis 2016. Expert Cassiopae / Sopra Financing Solutions depuis 2011. J’ai piloté ou accompagné plusieurs migrations Cassiopae de tailles variées, en France et à l’international. Cet article reprend ce que j’ai vu marcher — et ce que j’ai vu échouer. contact@i-leadconsulting.com · · 🔗 LinkedIn : Mohamed Ali Ksouri Publié le 21 avril 2026 · Revue trimestrielle · 20 min de lecture · ∼ 5 400 mots

Les 6 étapes de sécurisation en un coup d’œil

#	Étape	Livrable principal	Durée typique
1	Diagnostic d’entrée (pré-cadrage)	Note de cadrage + 3 risques majeurs	2 à 4 semaines
2	Cartographie technique et fonctionnelle	Dossier d’architecture + inventaire interfaces	4 à 8 semaines
3	Stratégie de bascule (big bang, phased, parallel run)	Dossier de stratégie + décision comité	2 à 4 semaines
4	Plan de tests à 5 niveaux (cycle en V)	Cahier de recette + jeu de données + outils	8 à 16 semaines
5	Plan de reprise données + plan de rollback	Procédures chiffrées, testées, signées	6 à 12 semaines
6	Go-live, cutover et hypercare (J-7, J-Day, J+30)	Runbook + war room + dashboard hypercare	4 à 8 semaines

Les 10 risques majeurs d’une migration Cassiopae

Avant de parler méthode, voici ce qui fait trébucher la majorité des projets que j’ai vus passer — par ordre de fréquence.

• 1. Sous-estimation des interfaces. Cassiopae dialogue avec 15 à 40 systèmes périphériques (comptabilité, KYC, risque, BI, factoring, DSI groupe). Chaque interface est un sous-projet, souvent géré via ETL ou ESB.
• 2. Plan de tests incomplet. Tests unitaires et intégration faits, recette utilisateur bâclée, aucun test non-fonctionnel. On découvre les régressions en production.
• 3. Jeu de données de test obsolète. Tests joués sur des contrats simplifiés, non sur la vraie diversité du portefeuille (MDM non synchronisé, doublons, statuts exotiques).
• 4. Absence de plan de rollback documenté. En cas d’incident au go-live, « on avise ». Dans la panique, c’est la catastrophe. Un plan de rollback est un composant du PRA / PCA projet.
• 5. Pré-prod sous-dimensionnée. Les tests de performance sont joués sur un environnement 2 fois moins puissant que la prod. On découvre les blocages le jour J.
• 6. Équipe métier indisponible. La recette est confiée à des ressources junior parce que les seniors « n’ont pas le temps ». Pas de vrai stress-test métier.
• 7. Cahier des charges daté de V3. On migre sans rationaliser les paramétrages. On transporte la dette technique vers V4.
• 8. Mauvaise gestion de la cohabitation V3/V4. Double saisie, rapprochements comptables en souffrance, équipes épuisées.
• 9. Communication interne défaillante. Les utilisateurs découvrent la nouvelle interface à J-15. Adoption basse pendant 6 mois (KPI taux d’appel support à surveiller).
• 10. Sponsor qui décroche. À M+6, le DSI n’est plus en comité de pilotage. Les arbitrages s’enlisent. Le projet dérive

Votre migration est-elle sous contrôle ? Diagnostic express possible en 2-3 jours sur votre projet en cours. Réponse sous 48 h. 📧 contact@i-leadconsulting.com

Pourquoi cet article

Cette article Il s’adresse aux DSI Leasing, aux chefs de projet, aux Directeurs Métier qui sponsorisent une migration Cassiopae — qu’elle soit en cours ou en préparation. Je ne prétends pas épuiser le sujet : chaque migration est différente, chaque contexte impose ses arbitrages.

Mais la méthode en 6 étapes que je partage ici, je l’applique sur toutes les missions depuis 2019. Elle n’a jamais fait rater un go-live. Elle en a sauvé quelques-uns.

Pourquoi les migrations Cassiopae échouent

Sur les migrations Cassiopae que j’ai vu passer de près ou de loin depuis 2011, je n’en ai pas vu une seule « simple ». Même les projets les mieux préparés ont leurs moments de flottement.

Ça tient à la nature de Cassiopae : un progiciel très paramétrable, connecté à beaucoup de systèmes, porteur d’une comptabilité et d’un reporting sensibles.

Migrer, c’est déplacer simultanément la plomberie technique et le cœur métier d’une activité qui continue de tourner. Dans les faits, les migrations échouent (ou prennent du retard important) pour trois familles de causes.

Famille 1 — Causes techniques

• Reprise de données incomplète ou corrompue : mappings V3 → V4 approximatifs, valeurs par défaut qui écrasent la réalité, contrats en statut « exotique » non pris en compte, MDM (Master Data Management) non aligné.
• Interfaces sous-estimées : 15 à 40 interfaces sur un grand compte, avec des règles métier implicites documentées nulle part. Architecture ETL/ESB souvent imprécise.
• Performances dégradées au go-live : pré-prod non iso-prod. On découvre les saturations en production.
• Dépendances de version incompatibles : JVM, OS, Oracle, JBoss/WebLogic, middleware MQ, navigateurs supportés.

Famille 2 — Causes organisationnelles

• Sponsor qui se désengage : COPIL qui perd en hauteur, arbitrages qui ne tombent plus.
• Équipe métier surchargée : la recette est faite « en plus » du quotidien.
• Partage de responsabilité flou entre client, intégrateur et éditeur (le fameux « chacun renvoie la balle »).

Famille 3 — Causes méthodologiques

• Plan de tests dimensionné sur V3, pas sur le périmètre V4 enrichi.
• Pas de dress rehearsal (répétition générale) avant le go-live.
• Pas de plan de rollback documenté, testé, signé.
• Communication et formation utilisateurs lancées trop tard (J-15 au lieu de M-3).

La bonne nouvelle, c’est que ces causes sont presque toutes prévisibles. On ne les évite pas toutes — il y a toujours une surprise — mais on peut les désamorcer largement en amont. C’est l’objet des 6 étapes qui suivent.

Étape 1 — Diagnostic d’entrée

Paradoxalement, l’étape la plus importante d’une migration se joue avant qu’elle ne commence vraiment. Prendre 2 à 4 semaines pour poser un diagnostic d’entrée sérieux, c’est typiquement ce qui sépare les projets qui dérivent des projets qui tiennent.

Ce qu’on diagnostique

• L’état technique de l’installation. Version exacte, patches appliqués, Z-programs et customisations, architecture (serveurs, BDD, middleware, datacenters).
• La qualité des données. Répartition par statut, anciennetés, taux d’anomalies MDM, doublons, référentiels partagés.
• La maturité du paramétrage. Catalogues produits vraiment utilisés vs hérités, règles de gestion actives vs dormantes.
• L’écosystème d’interfaces. Flux entrants/sortants, criticité métier, APIs (REST/SOAP), batchs, ETL.
• L’organisation. Référents métier, compétences internes Cassiopae, capacité à libérer du temps.

Le livrable : une note de cadrage honnête

Au terme de l’étape, vous devez pouvoir répondre à quatre questions :

1. Quel est le périmètre exact — fonctionnel, technique, organisationnel ?
2. Quels sont les 3 risques qui peuvent faire capoter le projet ?
3. Avons-nous en interne la capacité de piloter, ou faut-il renforcer ?
4. La timeline annoncée ou imposée est-elle tenable ?

Si la réponse à la question 4 est « non » ou « très tendu », c’est le moment de le dire. Pas à M+6. Je me souviens d’au moins deux projets où un diagnostic d’entrée bien fait a conduit à repousser le kick-off officiel de 3 à 4 mois — et ces mois supplémentaires ont été exactement ceux qui ont sauvé le go-live.

Étape 2 — Cartographie technique et fonctionnelle

Une fois le diagnostic posé, on passe à la cartographie. Cette étape nourrit tous les chantiers ultérieurs. On y passe 4 à 8 semaines sur un grand compte.

Cartographie fonctionnelle

• Processus métier impactés : souscription, mise en place, facturation, encaissement, restitution, recouvrement, cessions, back-office comptable.
• Rôles utilisateurs : nombre de profils, permissions, délégations.
• Produits commercialisés vs produits paramétrés mais non utilisés depuis 18 mois.
• Règles de gestion spécifiques, surtout celles documentées uniquement dans la tête d’un analyste parti à la retraite l’an dernier.

Cartographie technique

• Architecture complète : serveurs d’application, serveurs batch, BDD Oracle, middlewares (MQ, ESB, Kafka), proxies, pare-feux.
• Dépendances : JVM, OS, Oracle, JBoss/WebLogic, navigateurs.
• Customisations : Z-programs, triggers, batchs spécifiques, connecteurs.
• Interfaces : sens, fréquence, volumétrie, criticité, propriétaire client, propriétaire tiers.

Le référentiel des interfaces — le chantier sous-estimé

C’est presque toujours le point le plus mal traité. Sur les grands comptes, le nombre d’interfaces dépasse souvent 30. Chacune a ses règles, son référent, sa fenêtre batch, sa documentation plus ou moins à jour. Ne pas construire un référentiel unique et maintenu, c’est se condamner à découvrir pendant les tests d’intégration des comportements « oubliés » — typiquement à M+9, quand les marges sont déjà faibles. Conseil pratique : nommer un « responsable référentiel des interfaces » dès la cartographie. Une personne dédiée qui ne fait que ça à temps partiel pendant tout le projet. Ça paraît bête, ça sauve des mois. L’outillage minimum : un Excel structuré, voire Jira Confluence sur grand compte.

Étape 3 — Stratégie de bascule

Trois grandes familles de stratégies pour basculer de V3 vers V4. Le choix structure toute la suite du projet.

Option A — Big bang (cutover unique)

Toute l’activité bascule en une fois, un week-end donné. V3 arrêté le vendredi soir, V4 ouvert le lundi matin. Avantages : simplicité conceptuelle, pas de cohabitation, projet plus court. Inconvénients : concentration maximale du risque sur 48-72 h, rollback complexe, pas de marge d’erreur.

Option B — Bascule progressive (phased)

On bascule périmètre par périmètre : pays, produit, portefeuille. Avantages : risque réparti, apprentissage entre les vagues, rollback vague par vague. Inconvénients : cohabitation V3/V4 longue (6 à 18 mois), double maintenance, interfaces à dédoubler.

Option C — Parallel run

Les deux systèmes tournent en parallèle pendant 3 à 6 mois, avec double saisie ou réplication. Avantages : niveau de sécurité maximum. Inconvénients : coût et charge humaine très élevés, souvent irréaliste sur un périmètre large.

Comment choisir

Critère	Privilégier big bang	Privilégier phased
Taille portefeuille	< 50 000 contrats	> 100 000 contrats
Interfaces	< 15 interfaces	> 25 interfaces
Multi-pays	Mono-pays	≥ 3 pays
Maturité équipe	Équipe expérimentée	Équipe hétérogène
Fenêtre d’arrêt tolérée	48-72 h possibles	Arrêt impossible

Dans mon expérience, sur grand compte multi-pays, le bon choix est presque toujours une bascule phased. Avec une première vague « pilote » de 15 à 25 % du périmètre total qui permet d’apprendre avant de basculer le cœur critique.

Vous hésitez sur la stratégie de bascule ? Atelier d’aide à la décision en 1 à 2 jours. Réponse sous 48 h. 📧 contact@i-leadconsulting.com

Étape 4 — Plan de tests à 5 niveaux (cycle en V)

C’est le cœur technique de la sécurisation. Un plan de tests complet repose sur 5 niveaux complémentaires, structurés selon un cycle en V (V-Model). Sauter un niveau, c’est accepter que des régressions passent en production.

Niveau 1 — Tests unitaires et intégration (TU/TI)

Réalisés par l’intégrateur / l’éditeur. Outils typiques : SonarQube pour la qualité de code, Postman pour les APIs, scripts Jenkins pour l’automatisation. Durée 4 à 8 semaines. Livrable attendu : rapport avec taux de couverture et anomalies restantes.

Niveau 2 — Tests fonctionnels (recette métier)

Réalisés par les équipes métier du client (back-office, comptabilité, risques, conformité). Outils typiques : HP ALM ou OpenText Octane pour la gestion des cas de tests, Jira pour le suivi des anomalies. Durée 6 à 10 semaines. C’est ici que se jouent la majorité des surprises. La disponibilité des recettants seniors est le facteur critique.

Niveau 3 — Tests de bout en bout (E2E)

Scénarios qui traversent plusieurs systèmes : création contrat → facturation → encaissement → comptabilité → reporting. Orchestration souvent automatisée par des scripts spécifiques. Durée 3 à 6 semaines.

Niveau 4 — Tests non-fonctionnels (NFR)

Performance, montée en charge, tenue des batchs de nuit, temps de réponse, saturation. Outils : JMeter, LoadRunner, outils APM (AppDynamics, Dynatrace). Joués sur environnement iso-prod. Durée 2 à 4 semaines. Niveau le plus souvent bâclé — et celui qui déclenche les pires accidents au go-live.

Niveau 5 — Répétition générale (dress rehearsal)

Simulation complète du week-end de bascule, incluant la reprise de données, l’activation des batches, la validation des premiers cas d’usage. Doit être jouée au moins une fois, idéalement deux. 2 week-ends de tests + semaines de préparation.

Le bon réflexe Si votre chef de projet ne vous parle pas spontanément des 5 niveaux, posez-lui la question. Un plan qui couvre seulement les niveaux 1 et 2 est dangereux, même si le reste du projet est bien piloté. Le cycle en V est un minimum.

Le jeu de données de test

Un détail qui n’en est pas un : les tests doivent être joués sur un jeu représentatif de la vraie vie, pas sur des contrats de laboratoire. Je recommande — chaque fois que techniquement possible et compatible RGPD — de rejouer les tests de recette sur un extrait anonymisé de la production (30-50 % du volume). C’est là qu’on trouve les statuts « exotiques », les contrats hérités d’une M&A de 2015, les cas particuliers non documentés. Il y en a toujours. Outils de masquage : souvent une combinaison maison + scripts SQL + outils type Informatica Persistent Data Masking.

Étape 5 — Plan de reprise de données et rollback

La reprise de données est, avec le plan de tests, le chantier où j’ai vu le plus de projets déraper. Le plan de rollback est le plus souvent oublié.

Plan de reprise de données

• Cartographier les objets à migrer : contrats actifs, résiliés récents, tiers, opérations en cours, écritures comptables, historiques.
• Définir la profondeur d’historique : 3 ans ? 5 ans ? Tout ? Arbitrage avec métier et conformité (obligations RGPD, Sapin 2, obligations comptables).
• Définir les règles de mapping V3 → V4 : valeurs par défaut, conversions de référentiels, traitement des valeurs nulles. Architecture ETL typique.
• Chiffrer volumétrie et fenêtres techniques : extraction, transformation, chargement. Comparer avec la fenêtre de bascule disponible.
• Tester la reprise 3 fois minimum avant le go-live, sur jeu de plus en plus large. Outils : Liquibase pour les schémas, scripts SQL, outils éditeur Sopra.

Plan de rollback — le filet de sécurité

Le rollback, c’est la procédure qui permet de revenir en V3 si le go-live V4 tourne mal. Pendant longtemps, on a considéré ça comme un « nice to have ». Depuis 2020 et quelques incidents bien documentés dans le secteur bancaire, puis avec la montée en exigence DORA, c’est devenu un must. C’est un composant du PRA / PCA projet. Un vrai plan de rollback répond à six questions :

1. Dans quels cas on rollback ? Critères objectifs chiffrés (taux d’erreur, indisponibilité, non-conformité critique).
2. Qui prend la décision ? Un décideur nommé, joignable en permanence le week-end de bascule.
3. Combien de temps dure le rollback ? Il doit être plus court que la reprise de confiance sur V4 dégradé.
4. Que fait-on des données saisies entre-temps dans V4 ? Procédure de reprise ou d’abandon documentée.
5. Comment communique-t-on aux utilisateurs ? Messages pré-rédigés, canaux identifiés.
6. Le plan a-t-il été testé ? Idéalement joué en blanc au moins une fois en environnement de pré-prod.

Je le dis avec insistance : un plan de rollback non testé est une illusion. Sur un projet accompagné en 2022, le rollback « théorique » aurait pris 36 heures alors que le SLA métier tolérait 8 heures d’arrêt maximum. On s’en est rendu compte au test en blanc à M-2. Il a fallu refondre la procédure. Sans ce test, on se serait retrouvé bloqué le jour J avec un plan inutilisable.

Étape 6 — Go-live, cutover et hypercare

La phase finale se joue sur trois fenêtres : J-7, J-Day, J+30. On parle souvent de « cutover » pour désigner le jour de bascule, et de « hypercare » pour désigner la phase de stabilisation renforcée qui suit.

J -7 — Revue de préparation

• Check-list finale : tous les prérequis techniques et organisationnels levés.
• Communication utilisateurs : dates de bascule, fenêtres d’indisponibilité, canal de support, numéro d’urgence.
• Gel des mises en production non liées à la migration : pas de change ITIL pendant les 3 semaines qui entourent le go-live.
• Cellule de crise (war room) formée : composition, rôles, astreintes, salle physique ou virtuelle.

J-Day — Le week-end de cutover

• Exécution du runbook minute par minute, timing prévisionnel et réel à chaque étape.
• Points go/no-go à chaque grande étape : extraction, transformation, chargement, ouverture des interfaces, premiers tests de production.
• Cellule de crise en continu, décideurs joignables, communication utilisateurs toutes les 2-3 heures.
• Critères de rollback clairs : si atteints, on déclenche. Pas de débat philosophique le dimanche soir à 23h.

J+1 à J+7 — La semaine critique (hypercare intense)

• Cellule de crise maintenue, équipe technique renforcée.
• Support utilisateurs gonflé (× 2 à × 3) avec ticketing dédié, priorisation ITIL.
• Suivi de KPI quotidien : volumétrie, temps de réponse, taux d’anomalies, incidents critiques.
• Revue quotidienne « hypercare » matin et soir avec le sponsor.

J+8 à J+30 — Stabilisation

• Passage progressif de la cellule de crise au pilotage normal.
• Traitement des anomalies résiduelles, priorisation selon impact métier.
• Premier bilan à J+30 : KPI techniques, KPI métier, retour utilisateurs, budget consommé.
• Clôture formelle du projet uniquement quand les KPI sont revenus au niveau d’avant-migration.

Votre go-live approche ? Audit de préparation J-30 possible : 5-7 jours pour challenger votre plan et identifier les angles morts. Réponse sous 48 h. 📧 contact@i-leadconsulting.com

Gouvernance projet et comité de pilotage

Les 6 étapes précédentes se tiennent si — et seulement si — la gouvernance projet est solide. C’est l’angle mort le plus fréquent des migrations qui dérivent : tout le monde fait bien son travail, mais les arbitrages n’arrivent pas au bon niveau, au bon moment.

Les 4 instances indispensables

Instance	Fréquence	Rôle	Participants clés
Comité de pilotage stratégique (COPIL)	Mensuelle	Arbitrages, budget, périmètre	Sponsor (DG/DSI), Directeur Métier, chef de projet, intégrateur, éditeur
Comité opérationnel (COOP)	Hebdomadaire	Suivi chantiers, risques, actions	Chef de projet, leads techniques, lead métier
Comité technique (CTECH)	Hebdomadaire	Architecture, interfaces, tests	Architecte, DBA, responsable interfaces, experts Cassiopae
Cellule de crise (war room)	Activée au cutover	Décisions rapides go/no-go, rollback	Sponsor, chef de projet, lead technique, communication

Les 8 KPI à suivre au COPIL

• Avancement par chantier (% pondéré).
• Budget consommé vs budget prévu.
• Écart planning (jours de retard cumulés).
• Top 5 risques (probabilité × impact).
• Anomalies ouvertes par criticité (P1/P2/P3/P4).
• Taux de couverture des tests (cas passés vs cas prévus).
• Qualité de la reprise de données (taux d’anomalies par passe).
• Indicateur d’engagement des équipes métier (heures consommées sur la recette).

Le RACI migration Cassiopae

• Responsable (R) : Chef de projet migration (côté client).
• Approbateur (A) : Sponsor (DSI ou DG selon taille).
• Consulté (C) : Directeur Métier Leasing, RSSI, Conformité, Juridique, DAF.
• Informé (I) : COMEX, Conseil d’administration via comité des risques.

Conduite du changement

La migration est un projet humain autant que technique. Un système techniquement impeccable mais mal accompagné sur le plan humain produit une adoption basse, des erreurs utilisateurs, et un surcoût de support qui peut dépasser les gains attendus de la migration

Les 4 dimensions à adresser

• 1. Information. Pourquoi on migre ? Quand ? Qu’est-ce qui change concrètement ? Canaux : intranet, newsletter projet, town halls trimestriels, roadshows pays par pays.
• 2. Formation. Plans de formation différenciés par rôle : super-utilisateurs (3-5 jours), utilisateurs finaux (1-2 jours), managers (demi-journée), DSI locale (5-10 jours). Supports e-learning + présentiel + capsules vidéo.
• 3. Accompagnement. Réseau de champions en interne (1 pour 20 utilisateurs), community management, FAQ dynamique, canal de questions rapides (Teams, Slack).
• 4. Soutien émotionnel. Reconnaissance de l’effort demandé, écoute des frustrations, retours réguliers aux équipes. Particulièrement important pour les équipes qui utilisent le système plusieurs heures par jour.

Le planning de conduite du changement

Phase	Actions
M-6 à M-4	Identification des impacts par rôle, recrutement des champions, plan de communication
M-3 à M-2	Premières communications, création des supports de formation, démos fonctionnelles
M-2 à M-1	Formation des super-utilisateurs, tests pilotes en environnement de formation
M-1 à J-0	Formation des utilisateurs finaux, activation du support renforcé, bascule des documentations
J+0 à J+30	Accompagnement hypercare, mesure adoption quotidienne, traitement rapide des frictions
J+30 à J+90	Formations de rappel, communauté d’utilisateurs, retour d’expérience formalisé

Les 4 KPI adoption à suivre

• Taux de connexion quotidien (vs baseline pré-migration).
• Nombre de tickets support par utilisateur par semaine.
• Taux de complétion des formations e-learning.
• NPS utilisateurs internes (mesure mensuelle à J+30, +60, +90).

Sécurisation cyber et conformité DORA

On parle depuis 2024-2025 beaucoup plus de cybersécurité et de conformité réglementaire dans les migrations. Une migration, c’est un moment de fragilité où les garde-fous habituels sont partiellement désactivés (droits élargis, environnements ouverts, données copiées dans plusieurs zones). C’est aussi, depuis janvier 2025, un moment de vigilance DORA accru.

Les risques cyber spécifiques à une migration

• Données de production copiées en environnements de test sans anonymisation systématique (enjeu RGPD).
• Comptes à privilèges élargis temporairement pour l’équipe projet.
• Ouvertures de flux réseau nouvelles (cloud éditeur vers SI client par exemple).
• Documentation projet qui circule en clair sur supports non sécurisés.
• Fenêtre de bascule où la surveillance SOC peut être partiellement levée.

Ce qu’impose DORA en phase de migration

Le règlement DORA (UE 2022/2554) considère une migration progicielle comme un événement significatif dans la relation avec un prestataire ICT critique. Plusieurs exigences s’appliquent. Voir notre guide complet DORA et Cassiopae pour le détail. Synthèse :

• Information en temps utile de l’autorité compétente (ACPR) pour tout projet concernant un prestataire ICT supportant une fonction critique ou importante. La formulation exacte du règlement est « timely manner » ; à confirmer avec votre Direction Conformité pour le format précis.
• Mise à jour du registre des prestataires ICT : nouveau périmètre Sopra, nouveaux sous-traitants, nouvelles localisations de données.
• Procédure incidents robuste pendant la bascule : chaîne 4 h / 72 h / 1 mois opérationnelle dès le lancement.
• Plan de réversibilité actualisé sur V4 : certains éléments du plan construits pour V3 ne tiennent plus.
• Audit post-migration à planifier : revue de l’effectivité des contrôles dans la nouvelle configuration.

Concrètement, sur les migrations accompagnées depuis 2024, j’intègre systématiquement une « revue de sécurisation DORA » en phase de stabilisation, à J+60 environ. L’idée : vérifier que ce qu’on avait prévu avant la bascule tient toujours après, et corriger les écarts avant la prochaine revue ACPR.

Précision importante : l’interprétation juridique précise de l’Article 28 DORA sur les obligations d’information relève de votre Direction Conformité ou d’un cabinet d’avocats spécialisé. Le présent article donne une lecture opérationnelle, pas un avis juridique.

Budget et timing typique

Les chiffres qui suivent viennent d’une moyenne de projets de migration Cassiopae que j’ai vus passer, entre 2020 et 2025. Ils sont indicatifs — chaque projet a ses spécificités qui font bouger la note.

Timeline typique

Taille projet	Durée cadrage + migration	Équipe totale
ETI / captive, < 50 k contrats	8 à 14 mois	10 à 20 personnes
Grande banque universelle	14 à 22 mois	20 à 35 personnes
Multi-pays / multi-entités	22 à 36 mois	30 à 50 personnes

Budget indicatif (hors licences éditeur)

Taille projet	Budget total HT	Part sécurisation (conseil externe)
ETI / captive	1,5 à 3 M€ HT	80 à 200 k€ HT
Grande banque universelle	3 à 6 M€ HT	200 à 500 k€ HT
Multi-pays	6 à 15 M€ HT	500 k€ à 1,5 M€ HT

La « part sécurisation » correspond à l’accompagnement conseil indépendant (méthode, plans de tests, plan de rollback, pilotage qualité). Elle ne remplace pas les ressources de l’intégrateur ni celles de l’éditeur. Elle joue un rôle de tiers de confiance.

REX — migration V3.7 → V4.11 en 2023-2024

Je reviens sur le cas évoqué en introduction. Acteur européen du financement spécialisé, environ 100 000 contrats actifs, une dizaine de pays, Cassiopae V3.7 en production depuis plusieurs années. Projet de migration V4.11 lancé en juillet 2022. Go-live cible : septembre 2023. Budget initial : ∼ 5 M€ HT. Stratégie retenue : bascule phased par pays.

Où ça coinçait en mars 2023

• Retard de 5 mois sur le planning, go-live repoussé à février 2024.
• Reprise de données : taux d’anomalies > 7 % sur la première extraction complète, alors que l’objectif était <1%.
• Plan de tests : seulement 40 % des cas d’usage métier couverts, pas de tests NFR planifiés.
• Interfaces : sur ∼ 30 interfaces recensées, 9 n’avaient pas démarré les tests d’intégration.
• Plan de rollback : inexistant.

Ce qu’on a mis en place

Semaines 1 à 3 — Reprise de diagnostic. Cartographie complète revisitée, identification des 3 risques majeurs (données, interfaces, rollback). Décision partagée : on ne tient pas février. Nouvelle cible : juin 2024.

Mois 1 à 3 — Reprise de données. Création d’une équipe dédiée (4 personnes, dont 2 mi-temps métier). Trois passes de reprise successives avec correction des règles de mapping. Taux d’anomalies ramené à 0,6 % en juillet (sur la mission évoquée).

Mois 3 à 6 — Plan de tests refondu. Ajout des 5 niveaux (dont NFR et dress rehearsal manquants). Répétition générale jouée 2 fois, la deuxième sans anomalie bloquante.

Mois 4 à 5 — Plan de rollback. Construit de zéro, testé à M-2 du go-live. Durée de rollback ramenée de 36 h théoriques à 6 h réelles.

Mois 6 — Conduite du changement. Plan de formation relancé : vidéos, sessions Q&A par pays, canal d’urgence dédié. Réseau de 15 champions internes formés.

Le résultat

Go-live finalement réussi mi-juin 2024 sur la première vague (4 pays, environ 40 % du périmètre). Sur ces 4 pays, zéro incident critique dans les 7 premiers jours. Deux incidents P2 traités en 24-48 h. Les trois vagues suivantes se sont enchaînées sur 9 mois. Go-live complet finalisé en mars 2025. Budget final : ∼ 6,8 M€ HT (dépassement contenu à ∼ 30 %, ce qui reste dans mon référentiel un bon résultat sur un projet aussi lourd).

Le retour du DSI, 12 mois après le premier appel : « Le plus dur, c’est d’avoir accepté à temps qu’on n’arriverait pas à la date initiale. Tant qu’on croyait qu’on pouvait tenir, on poussait sur les équipes et on dégradait la qualité. Une fois la date repoussée honnêtement, tout s’est remis en ordre. »

Les 5 pièges qui font dérailler un projet Cassiopae

Piège 1 — Confier la recette à des juniors

La recette métier détecte les régressions les plus critiques. La confier à des ressources junior « parce que les seniors sont trop pris », c’est garantir qu’on passera à côté des cas limites. La recette, c’est le job d’un senior métier. Pas d’un stagiaire bien intentionné.

Piège 2 — Traiter la reprise de données en fin de projet

Beaucoup d’équipes attendent M-4 pour lancer la reprise sérieusement. Erreur. La reprise doit être lancée en parallèle du reste, pas après. Plus on tarde, plus on découvre d’anomalies au moment où on a le moins de marge pour corriger.

Piège 3 — Faire confiance au planning initial

Sur les migrations Cassiopae, un planning initial qui « tombe pile » est extrêmement rare. Il y a presque toujours 10 à 30 % de dérive. Ce n’est pas grave si on l’intègre dans la gouvernance dès le départ. C’est catastrophique si on découvre qu’on dérive à M+9.

Piège 4 — Oublier la conduite du changement

Les utilisateurs finaux sont souvent prévenus à J-15 ou J-7. Ils arrivent le lundi du go-live face à un nouveau système, sans formation sérieuse. Les appels au support explosent. L’adoption s’étale sur 6 à 12 mois au lieu de 2 à 3. La conduite du changement doit démarrer à M-3, pas à J-7. Voir section 9.

Piège 5 — Traiter le plan de rollback comme un formulaire administratif

Rédiger un plan de rollback n’est pas suffisant. Il faut le tester en conditions réelles au moins une fois. Sans test, c’est un document qui rassure les comités de pilotage mais ne protège personne le jour J.

FAQ — 14 questions fréquentes

Démarrer votre sécurisation avec i-lead

Si vous êtes en phase de cadrage, en cours de projet, ou à quelques mois du go-live et que le doute s’installe, voici les trois formats d’intervention que nous proposons.

Format 1 — Audit express (3 à 5 jours)

Diagnostic indépendant de votre projet en cours. Revue de la cartographie, du plan de tests, du plan de reprise, du plan de rollback. Livrable : note de 10-15 pages avec les 3 à 5 risques majeurs et les recommandations associées. Typiquement 15 à 30 k€ HT.

Format 2 — Assistance à maîtrise d’ouvrage (3 à 9 mois)

Accompagnement du chef de projet client sur les 6 étapes de sécurisation. Présence hebdomadaire, participation aux comités. Typiquement 80 à 300 k€ HT.

Format 3 — Mission flash de sauvetage (2 à 6 mois)

Intervention quand un projet est en dérive forte ou qu’un go-live approche sans filet de sécurité. Objectif : remettre le projet sur les rails. Typiquement 60 à 200 k€ HT

Prêt à sécuriser votre migration ? Premier échange gratuit de 30 minutes pour évaluer votre situation. 📧 contact@i-leadconsulting.com 🔗 linkedin.com/in/mohamed-ali-ksouri-87b0a5133 ⏱ Réponse garantie sous 48 h

Pour approfondir

• Notre méthodologie d’audit Cassiopae en 2 jours (/audit-cassiopae/)
• Le métier de consultant Cassiopae en 2026 (/consultant-cassiopae/)