Migration Cassiopae V3.x → V4.11 : stratégie, étapes, durée et budget

En 2026, la migration Cassiopae V4.11 de Sopra Financing Solutions (SFS) est devenue un chantier incontournable pour les établissements financiers qui exploitent le progiciel.

Projet complexe sur 18 à 24 mois, mobilisant des équipes pluridisciplinaires et un budget significatif, la migration V4.11 cristallise à la fois un enjeu réglementaire (conformité IFRS9, RWA), un enjeu technique (modernisation de la stack) et un enjeu métier (préservation des spécifiques accumulés depuis 10-15 ans). Ce guide s’adresse aux DSI, Responsables de Programme, Directeurs Métier Leasing, Release Managers et Directions Achats qui préparent ou pilotent une migration Cassiopae V4.11.

Il capitalise sur les retours d’expérience des consultants I-Lead Consulting intervenus sur plusieurs migrations dont la Société Générale CIB (projet de migration CBI V3.49 → SFS V4.11 en cours depuis 2024).

Par Mohamed Ali Ksouri,- Managing Partner I-Lead Consulting15 ans d’expérience dans le conseil IT bancaire et le financement spécialisé. Cet article s’appuie sur les retours d’expérience des consultants I-Lead intervenus sur des migrations Cassiopae (Société Générale CIB, Natixis Lease, Tunisie Leasing & Factoring). / Mis à jour le 19 avril 2026 · 16 min de lecture

Migration Cassiopae V4.11 : l’essentiel en 40 secondes 📅 Durée typique : 18 à 24 mois (4-6 mois cadrage + 12-18 mois migration + 3-6 mois stabilisation) 💰 Budget externe indicatif : 2,5 à 6 M€ selon périmètre (CBI, CBM ou périmètre complet) et volume de spécifiques 👥 Équipe type : 8 à 14 profils en parallèle (Release Manager, BA Senior, consultants techniques, Experts Front/Back, recette) 🎯 Enjeux majeurs : reprise des codes STAT en custom characteristics, migration des workflows, interfaces IN/OUT, coordination SFS ⚠ 3 pièges à éviter : sous-estimer l’analyse du code source, négliger le TNR, lancer la migration sans cadrage métier suffisant   → Discuter de votre projet de migration avec I-Lead Consulting

Pourquoi migrer vers Cassiopae V4.11 en 2026

La version V4.11 de Cassiopae / SFS n’est pas simplement une mise à jour mineure — elle représente un palier de maturité technique et fonctionnelle majeur par rapport aux V3.x et V4.5. Plusieurs facteurs convergent pour rendre la migration incontournable pour les établissements encore en V3.x.

Raisons techniques

• Fin du support V3.x progressive : Sopra Financing Solutions oriente ses investissements R&D sur la V4.11 et les versions ultérieures. Les correctifs sur V3.x deviennent plus espacés, et les nouvelles fonctionnalités ne sont plus rétro-portées.
• Stack technique modernisée : support natif Oracle 19c, APIs REST en plus des WebServices SOAP historiques, compatibilité avec les architectures modernes (Kubernetes, containers).
• Performances améliorées : traitements batch optimisés, meilleure tolérance aux volumes élevés de contrats, parallélisation accrue.

Raisons fonctionnelles

• Custom characteristics : nouveau modèle de paramétrage qui remplace les anciens codes STAT personnalisés — plus souple et maintenable.
• Workflows Front Office enrichis : matrices de décision et règles de gestion plus flexibles.
• Unités de gestion : regroupement de plusieurs sociétés de gestion sous une même structure — utile pour les groupes.

Raisons réglementaires

• IFRS9, RWA, Bâle III : la V4.11 intègre les dernières mises à jour réglementaires du reporting européen.
• Sécurité renforcée : audit trail, chiffrement, compatibilité CyberArk.
• Standardisation des modèles de données Groupe : indispensable pour les établissements qui consolident plusieurs entités.

Les 3 grandes stratégies de migration

Une migration Cassiopae V4.11 peut être abordée selon trois grandes stratégies, avec des implications très différentes en termes de durée, de budget et de risque.

Stratégie	Principe	Durée	Risque
Big Bang	Bascule complète en une seule mise en production. Périmètre total migré en même temps.	12-18 mois	Élevé
Progressive par lot	Découpage par périmètre métier (CBI, puis CBM, puis LLD). Plusieurs mises en production étalées.	18-24 mois	Modéré
Parallèle (dual-run)	Les deux versions V3.x et V4.11 tournent en parallèle sur une période de plusieurs mois avant bascule définitive.	24-36 mois	Faible

Quelle stratégie privilégier ?

Pour la grande majorité des établissements, la stratégie progressive par lot est la plus pertinente. Elle offre un compromis entre vitesse, maîtrise du risque et capacité à apprendre d’un lot à l’autre. Le big bang reste adapté aux périmètres réduits (une seule entité, un seul métier). Le dual-run est généralement réservé aux contextes très critiques où toute interruption de service serait inacceptable, mais son coût est très supérieur. La stratégie progressive est celle retenue sur le programme de migration CBI de la Société Générale CIB, avec un cadrage de 6 mois suivi de plusieurs vagues de migration par périmètre.

Phase de cadrage : les 4 à 6 premiers mois

La phase de cadrage est la plus importante de tout le projet de migration. Une phase de cadrage négligée ou raccourcie se paie très cher en phase de migration — c’est l’erreur la plus fréquente que nous observons.

Objectifs de la phase de cadrage

1. Appropriation des macro-processus métier actuels (CBI, CBM, LLD, vendor finance selon le périmètre).
2. Inventaire exhaustif des développements spécifiques à traiter (packages PL/SQL, workflows, custom STAT, interfaces, états Business Objects).
3. Identification des irritants et des dettes techniques accumulées au fil des versions.
4. Définition de la stratégie de migration (big bang, progressive, parallèle).
5. Préparation et animation des ateliers métier avec les Product Owners et directions métier.
6. Classification des sujets selon 4 catégories : Adopt standard, Développement Spécifique à maintenir, Core, Paramétrage.
7. Analyse GAP entre les fonctionnalités V3.x actuelles et le standard V4.11.
8. Chiffrage fiable des impacts et production d’un planning macro.

Livrables attendus fin de cadrage

• Note de cadrage stratégique validée par la DSI et la direction métier.
• Inventaire exhaustif des spécifiques (typiquement 400 à 1 500 objets à analyser selon l’ancienneté).
• Matrice Adopt / Dev Spécifique / Core / Paramétrage.
• Planning macro 18-24 mois avec jalons métier majeurs.
• Budget consolidé avec provisions de risque (+15-20 %).
• Dispositif projet : gouvernance, RACI, comitologie, rôles SFS.

⚠ Erreur classique du cadrage Vouloir aller trop vite en cadrage pour démarrer la migration « concrète » rapidement.   Conséquence : les développements spécifiques sont mal chiffrés, les workflows métier sont mal identifiés, et le projet dérive en phase de migration. Dans 80 % des projets qui dérapent, la cause est dans le cadrage.   Règle : un cadrage sérieux sur une migration CBI ou CBM complète prend 5 à 6 mois. Moins = risque élevé.

Phase de migration : comment ça se passe concrètement

Une fois le cadrage validé, la phase de migration s’organise en 5 grands chantiers qui s’articulent entre eux, avec des cérémonies Agile @ Scale (SAFe) pour la coordination.

Chantier 1 — Préparation et validation des EDB

Les EDB (Expressions de Besoin) sont le document central de dialogue avec SFS. Sur un projet de migration CBI moyen, 50 à 80 EDB sont préparés et validés. Chaque EDB décrit un besoin métier, son impact fonctionnel, les options de traitement envisagées, et le chiffrage attendu de l’éditeur.

Chantier 2 — Analyse du code source et chiffrage des impacts

Analyse systématique des objets techniques Cassiopae via les repositories Git : packages PL/SQL, tables, fonctions, procédures, vues, vues matérialisées. Cette analyse est menée interface par interface (IN/OUT) en tenant compte de la criticité définie par le client, afin d’évaluer les impacts de migration et produire un chiffrage fiable des modules et interfaces à migrer.

Chantier 3 — Développements spécifiques et paramétrage

Pour les sujets classés « Développement Spécifique », SFS livre des spécifications et des développements qui doivent être testés. Pour les sujets classés « Paramétrage », les équipes client paramètrent la nouvelle V4.11 (combo box, master script, matrices, custom characteristics).

Chantier 4 — Migration des données

Scripts de migration SQL, validation des règles de migration, tests unitaires puis tests d’intégration. Pour les périmètres qui intègrent plusieurs entités (fusion, absorption), la migration de données est souvent le chantier le plus complexe — notamment quand le progiciel source n’est pas Cassiopae (PLEASE, Ekip, etc.).

Chantier 5 — Interfaces IN/OUT

Tests des interfaces post-migration entre Cassiopae et les systèmes connexes (comptabilité SAGE, CRM Microsoft Dynamics, scoring externe, ADD’ONs comme AssureLease, GER, ROC, Provision, JuriLease, WRAP). Vérification de l’intégrité des flux et de la non-régression.

Cérémonies Agile @ Scale

En méthodologie SAFe (Scaled Agile Framework), la coordination se fait via des cérémonies régulières :

• Daily meetings au niveau de chaque équipe.
• Sprint planning (toutes les 2 semaines généralement).
• Sprint review et rétrospective.
• PI Planning tous les 10-12 semaines avec l’ensemble des équipes du programme.
• Comités hebdomadaires avec SFS pour le suivi projet.
• Utilisation de Jira Software et Zephyr pour le suivi des epics, stories, cas de tests.

Les EDB : structurer le dialogue avec SFS

Les Expressions de Besoin (EDB) sont le livrable contractuel qui encadre les demandes du client vers SFS. La qualité de leur rédaction conditionne directement la qualité du chiffrage SFS et la maîtrise du budget projet.

Anatomie d’un bon EDB

1. Contexte métier : la situation actuelle en V3.x et le besoin fonctionnel.
2. Besoin exprimé : ce que le client veut obtenir dans la V4.11.
3. Options de traitement envisagées : avec leurs avantages et inconvénients respectifs.
4. Impacts identifiés : sur les workflows, les interfaces, les données, les autres modules.
5. Questions ouvertes : points à clarifier avec SFS ou le métier.
6. Priorisation : criticité business, dépendances, jalons attendus.

Le process de validation

• Rédaction par le Business Analyst I-Lead en co-construction avec le métier.
• Validation par le Product Owner client.
• Soumission à SFS pour chiffrage et précisions.
• Itérations (2-3 en moyenne par EDB) pour aligner les attentes.
• Validation finale et intégration au backlog projet.

Exemple réel — migration CBI Société Générale CIB Sur le projet CBI, les consultants I-Lead ont préparé et validé 64 EDB avec le métier et les Product Owners avant soumission à SFS, toutes intégrant la contrainte des unités de gestion regroupant une ou plusieurs sociétés de gestion.   Détail : validation des workflows Front Office, migration de plus de 300 codes STAT personnalisés en custom characteristics, définition des tâches et formalités associées.

Reprise des spécifiques : le cœur du sujet

La migration des développements spécifiques accumulés au fil des années (voire des décennies) est le défi technique et fonctionnel central d’une migration V4.11. Sur un établissement en production depuis 10-15 ans, les spécifiques représentent souvent 30 à 50 % du périmètre global à traiter.

Types de spécifiques à reprendre

Type de spécifique	Volume typique	Approche V4.11
Codes STAT personnalisés	100-500	Migration en custom characteristics
Workflows Front Office	20-80	Refonte avec les nouveaux outils V4.11
Packages PL/SQL personnalisés	50-200	Analyse au cas par cas (adopt standard ou migration)
États Business Objects / JasperReports	100-300	Reprise et adaptation au nouveau modèle de données
Interfaces IN/OUT	20-60	Revue de chaque interface (criticité, volumétrie)
Batch spécifiques	10-40	Redéveloppement ou paramétrage standard V4.11
ADD’ONs (AssureLease, GER, etc.)	3-8	Mise à jour ou remplacement

La logique Adopt / Dev Spécifique / Core / Paramétrage

Chaque spécifique identifié est classé dans une des 4 catégories suivantes, qui détermine sa stratégie de migration :

• Adopt (adopter le standard V4.11) : le spécifique peut être abandonné au profit d’une fonctionnalité standard V4.11 qui répond au même besoin. C’est la catégorie idéale — allègement de la dette technique, réduction du coût de maintenance.
• Dev Spécifique (à conserver) : le spécifique est justifié par un besoin métier qui n’est pas couvert par le standard. Il doit être re-développé dans la V4.11.
• Core (intégration au standard) : SFS accepte d’intégrer le spécifique dans la prochaine version standard — idéal pour mutualiser avec d’autres clients.
• Paramétrage : ce qui ressemblait à un spécifique est en réalité reproductible par un simple paramétrage V4.11. Gain de simplification.

Un objectif sain sur une migration V4.11 est de viser 60-70 % d’Adopt ou Paramétrage, et de contenir les Dev Spécifiques à 20-30 % du périmètre. Au-delà, la migration reproduit la dette technique du legacy.

Le TNR : pierre angulaire de la réussite

Les Tests de Non-Régression (TNR) sont le filet de sécurité qui garantit qu’aucune régression n’a été introduite entre la V3.x et la V4.11. C’est un chantier à part entière, qui mobilise des ressources importantes pendant toute la durée de la migration.

Objectifs du TNR

• Valider que chaque fonctionnalité qui marchait en V3.x marche toujours en V4.11.
• Identifier les écarts de comportement (calculs financiers, imputations comptables, workflows).
• Couvrir les interfaces IN/OUT (flux entrants et sortants).
• Valider les batchs critiques (facturation, intérêts de retard, domiciliation, lettrage automatique, interface comptable).
• Certifier métier des flux collectés et des données valorisées.

Outillage TNR recommandé

• Jira Software + Zephyr : élaboration et exécution des cas de tests, suivi des anomalies.
• Cas de tests structurés : pré-requis, actions, résultats attendus, résultats obtenus, statut.
• Zephyr pour V4.11 : permet de structurer les cas de tests de recette de façon réutilisable d’un sprint à l’autre.
• Environnements de test dédiés : au moins 2 environnements non-PROD (intégration, recette), avec nettoyage régulier des bases.

Volumétrie typique

Sur un projet de migration CBI complet, on peut compter entre 800 et 2 500 cas de tests structurés, répartis entre Front Office, Back Office, interfaces, batchs et reporting. Le taux de couverture cible est de 90-95 % des fonctionnalités critiques et de 70-80 % des fonctionnalités secondaires.

Durée et budget d’une migration V4.11

Les ordres de grandeur suivants sont issus de l’observation du marché français 2024-2026 sur plusieurs projets réels — ils ne constituent pas une grille contractuelle mais une aide à l’estimation.

Durée par phase

Phase	Durée typique	Livrables clés
Cadrage	4-6 mois	Note cadrage, inventaire spécifiques, planning macro
Migration — EDB et dev	8-12 mois	EDB validés, spécifiques développés, environnements prêts
Migration — TNR et recette	4-6 mois	Cas de tests validés, anomalies corrigées
Stabilisation post MEP	3-6 mois	Support niveau 3, scripts correctifs, solutions pérennes
TOTAL programme	18-30 mois	Selon stratégie (big bang, progressive, parallèle)

Budget externe indicatif

Périmètre	Budget externe	Commentaire
CBI uniquement (moyen volume)	2,5-4 M€	Environ 30-50 personnes-année externes
CBM uniquement	3-5 M€	Plus complexe que CBI en général (volumes, spécifiques)
Périmètre complet (CBI+CBM+LLD)	4-8 M€	Grands groupes, multi-entités, multi-pays
Migration + fusion d’entité	5-10 M€	Type YOGA SG — fusion + migration simultanées

Répartition du budget externe

• Licences et upgrades SFS : 15-25 %
• Prestations SFS (accompagnement éditeur) : 20-30 %
• ESN et conseil externe (cadrage, pilotage, BA, recette) : 40-50 %
• Infrastructure et environnements (cloud ou on-premise) : 5-10 %
• Provisions de risque et évolutions hors périmètre : 10-15 %

Composition d’équipe recommandée

Une équipe de migration V4.11 complète mobilise typiquement 8 à 14 profils en parallèle sur le pic d’activité. Voici la composition type que nous recommandons chez I-Lead Consulting.

Rôle	Nombre	Mission principale
Directeur de Programme	1	Pilotage stratégique, sponsoring, comité de direction
Responsable Migration / Release Manager	1	Coordination opérationnelle, suivi releases, pilotage TNR
Product Owners métier	2-4	Représentation métier (CBI, CBM, LLD), priorisation backlog
Business Analysts Cassiopae	3-5	Rédaction EDB, analyse GAP, pilotage recette
Consultants technico-fonctionnels	2-3	Interfaces, migration données, PL/SQL
Experts Front / Back Office	2	Expertise pointue sur modules spécifiques
Consultants recette / testeurs	2-3	Cas de tests, exécution TNR, anomalies
Architecte données	1	Modèle de données, vues matérialisées, reporting

Cette composition évolue au fil du projet : l’équipe de cadrage est plus resserrée (3-5 profils), le pic est atteint en phase de migration (10-14 profils), puis l’équipe décroît en phase de stabilisation (3-5 profils en support niveau 3).

Les 7 pièges les plus fréquents à éviter

Après plusieurs migrations Cassiopae observées chez nos clients, voici les 7 pièges les plus récurrents que nous identifions — et comment les éviter.

Piège 1 — Sous-estimer l’analyse du code source

L’analyse exhaustive des packages PL/SQL, procédures, vues matérialisées et interfaces via les repositories Git prend 2 à 4 mois sur un périmètre CBI complet. Vouloir la compresser à 3-4 semaines conduit à des surprises coûteuses en phase de migration.

• Parade : prévoir un Expert Cassiopae dédié à l’analyse code source, avec une méthodologie outillée et un rendu structuré par module / criticité.

Piège 2 — Négliger le TNR

Le TNR est souvent perçu comme une activité « administrative » qu’on peut compresser. Erreur fréquente. Un TNR mal fait laisse passer des régressions qui se révèlent en production — avec un coût très supérieur.

• Parade : structurer les cas de tests dans Zephyr dès le début de la phase de migration, pas en fin. Prévoir 15-20 % du budget projet sur le TNR.

Piège 3 — Tout vouloir refaire en « Dev Spécifique »

Reproduire la dette technique du legacy en passant chaque spécifique en Dev Spécifique V4.11 = même problème 5 ans plus tard. C’est l’erreur stratégique la plus coûteuse à long terme.

• Parade : viser 60-70 % d’Adopt ou Paramétrage, et challenger systématiquement chaque Dev Spécifique demandé par le métier (« est-ce vraiment nécessaire ? »).

Piège 4 — Démarrer la migration sans cadrage métier solide

La tentation est de démarrer la phase technique rapidement. Mais si les Product Owners ne sont pas alignés sur les processus cibles, les EDB partent dans tous les sens.

• Parade : investir dans les ateliers métier en phase de cadrage, faire valider par écrit les processus cibles avant de démarrer la migration technique.

Piège 5 — Sous-dimensionner la coordination avec SFS

SFS est un partenaire critique du projet. Une communication insuffisante se traduit par des livrables en retard, des chiffrages flous, des désalignements.

• Parade : comité hebdomadaire avec SFS, référent unique côté client, transmission des livrables préparatoires dans les délais, respect des jalons contractuels.

Piège 6 — Ignorer les interfaces IN/OUT

Les interfaces (comptabilité SAGE, CRM, scoring externe, ADD’ONs) sont souvent sous-investies. Elles deviennent le principal source d’incidents post-MEP.

• Parade : recensement exhaustif des interfaces en cadrage, tests d’intégration dédiés, simulation de bout-en-bout avant bascule.

Piège 7 — Insuffisance de la phase de stabilisation

Dès la MEP réussie, la tentation est de « tourner la page » du projet. Mais les premières semaines post-bascule révèlent des anomalies qui nécessitent un support niveau 3 expérimenté.Parade : prévoir 3-6 mois de stabilisation budgétés, avec scripts correctifs (PRODOP), analyse des anomalies, comités hebdomadaires métier, solutions pérennes.

Retour d’expérience : projet Société Générale CIB

Le projet de migration CBI de la Société Générale CIB est l’un des programmes Cassiopae V4.11 les plus significatifs en cours en France. I-Lead Consulting y intervient depuis 2024 via un consultant Expert positionné comme Responsable Migration. Voici les principaux retours d’expérience que nous en tirons.

Contexte du projet

• Périmètre : migration du Crédit-Bail Immobilier (CBI) depuis Cassiopae V3.49 vers SFS V4.11.
• Contexte élargi : s’inscrit dans le programme YOGA de fusion Crédit du Nord / Société Générale.
• Calendrier : phase de cadrage janv-juin 2024, phase de migration en cours depuis juin 2025.
• Méthodologie : Agile @ Scale (SAFe, PI Planning, SCRUM).

Les 5 apprentissages majeurs

Apprentissage 1 — La phase de cadrage a été décisive

La phase de cadrage de 6 mois a permis d’analyser en profondeur les macro-processus métier, les développements spécifiques, et de classifier chaque sujet en Adopt / Dev Spécifique / Core / Paramétrage. Cette rigueur initiale a évité bien des dérives en phase de migration.

Apprentissage 2 — 64 EDB préparés et validés

Volume qui démontre la rigueur du processus : chaque besoin métier a été formalisé, validé avec le Product Owner, puis soumis à SFS. Cela prend du temps (2-3 itérations par EDB en moyenne), mais sécurise le chiffrage et les attentes.

Apprentissage 3 — Migration de 300+ codes STAT en custom characteristics

C’est typiquement le type de spécifique à migrer. Les codes STAT personnalisés V3.x (qui permettaient d’enrichir les données contrat) sont migrés en custom characteristics V4.11 — un modèle plus souple et pérenne.

Apprentissage 4 — Release Management coordonné sur 5 releases

Sur la période 2023-2025, le consultant Expert I-Lead a coordonné 5 releases en FR/EN. Cette coordination permet de structurer la livraison progressive sans tout déployer en une seule fois.

Apprentissage 5 — Contrainte des unités de gestion

Toutes les EDB ont intégré la contrainte des unités de gestion regroupant une ou plusieurs sociétés de gestion. C’est une particularité V4.11 qui mérite une attention spécifique en cadrage.

Ce que ce projet illustre Une migration Cassiopae V4.11 réussie n’est pas une question de chance — c’est une question de méthode, d’anticipation et de consultants expérimentés.   Les projets qui dérapent partagent généralement les mêmes causes racines : cadrage insuffisant, sous-estimation du TNR, coordination éditeur défaillante. À l’inverse, les projets qui réussissent combinent rigueur dans le cadrage, outillage projet solide (JIRA, Zephyr, Git), et équipe expérimentée capable de dialoguer à la fois avec le métier, la DSI et SFS.

FAQ — Migration Cassiopae V4.11

En résumé : par où commencer

Une migration Cassiopae V3.x → V4.11 est un projet structurant sur 18 à 24 mois qui transforme durablement le SI d’un établissement financier. Sa réussite repose sur trois fondamentaux : un cadrage rigoureux qui prend le temps nécessaire, une équipe expérimentée capable de dialoguer avec le métier, la DSI et SFS, et un outillage projet solide (EDB structurés, cas de tests Zephyr, Release Management coordonné).

Chez I-Lead Consulting, nous accompagnons les grands établissements financiers sur ces programmes avec une équipe de consultants dont plusieurs interviennent actuellement sur des migrations V4.11 en production. Notre différenciation : une capacité à combiner expertise progicielle Cassiopae, maîtrise des enjeux métier du financement spécialisé, et excellence en delivery.

👉 Votre projet de migration Cassiopae V4.11 — discutons-en Cadrage · Pilotage · Rédaction EDB · TNR · Release Management · Support niveau 3   → contact@i-leadconsulting.com → Mohamed Ali Ksouri, Managing Partner : mohamedali.ksouri@i-leadconsulting.com → www.i-leadconsulting.com/expertises/consultant-cassiopae/

Pour approfondir

• Consultant Cassiopae en France : notre expertise → /expertises/consultant-cassiopae/

Sources et références

• Sopra Financing Solutions — communiqués officiels (sbs-software.com)
• Projet Société Générale CIB — migration CBI V3.49 → SFS V4.11 (référence publique via LinkedIn du Directeur de Programme et communiqués SG)
• Projet YOGA Crédit du Nord / Société Générale