Finacca
Comment Finacca a préparé l'avenir de son système central en 4 semaines, avant son conseil d'administration
Contexte
Fondé en 1990, le Groupe Finacca regroupe huit entreprises spécialisées dans l'accompagnement des acteurs de la banque-assurance et de l'immobilier, sur trois métiers : investigation civile, identification des bénéficiaires de contrats d'assurance-vie en déshérence, et évaluation immobilière.
Depuis vingt ans, le groupe fonctionnait sur GEMS, son système informatique central. Trop coûteux à maintenir, avec des possibilités d'évolution devenues limitées, GEMS avait vocation à être remplacé. C'est pour ça que NOSE, un nouveau logiciel, avait été lancé en 2019 : d'abord conçu pour la saisie d'enquêtes, il avait progressivement absorbé de nouvelles fonctionnalités pour devenir le cœur du système. Mais au fil de sa construction, NOSE avait développé des dépendances vis-à-vis de GEMS. Retirer l'ancien système n'était plus aussi évident qu'au départ.
Fin février 2024, Finacca a mandaté Hones pour répondre à deux questions précises avant son conseil d'administration : GEMS pouvait-il être retiré de l'infrastructure d'ici la fin de l'année ? NOSE était-il maintenable à long terme dans l'état où il se trouvait ? Le CA se tenait moins d'un mois après le début de l'audit.
Défis
Défi #1 — Démêler deux systèmes qui s'étaient mutuellement contraints
En construisant NOSE par-dessus GEMS, l'équipe technique avait créé des dépendances dans les deux sens. NOSE s'appuyait sur des fonctions de GEMS pour certaines opérations ; retirer GEMS signifiait donc identifier chaque point de contact, évaluer son impact, et déterminer ce qui pouvait être migré, réécrit ou abandonné.
L'analyse croisée des deux systèmes a permis de cartographier ces dépendances précisément. La direction pouvait enfin voir ce que cachait la question "peut-on retirer GEMS ?" : non pas une décision binaire, mais un ensemble de conditions et de séquences à respecter.
Défi #2 — Comprendre pourquoi NOSE avait dérivé vers un projet qui s'enlisait
Ce qui avait commencé comme un remplacement ciblé était devenu, au fil des années, un projet massif. Chaque conseil d'utilisateur, chaque besoin remonté, chaque idée ajoutée au périmètre avait alourdi l'ensemble. L'équipe technique, junior et en partie reconvertie, n'avait pas la distance nécessaire pour mesurer le coût réel de ces accumulations successives. Personne ne disait "stop".
L'audit a mis en lumière le mécanisme précis de cette dérive : une approche "tout en même temps" là où une construction par blocs successifs, chacun opérationnel avant d'ajouter le suivant, aurait produit un résultat plus solide en moins de temps.
Défi #3 — Produire des scénarios actionnables pour un conseil d'administration, en moins d'un mois
La contrainte de délai était réelle. Hones disposait de quatre semaines pour conduire 23 entretiens auprès de membres du board, des équipes techniques, des utilisateurs et des équipes projet, analyser les deux systèmes en profondeur, et remettre un diagnostic avec plusieurs scénarios d'évolution. Chaque scénario devait décrire ses implications concrètes : coût, délai, risques, ressources nécessaires.
Le rapport final de 128 pages incluait un executive summary orienté décision, les constats détaillés par dimension, et une grille de scénarios permettant au conseil de trancher sur des faits.
Résultats
- Le conseil d'administration a pu se tenir avec un diagnostic complet, livré dans les délais impartis malgré la complexité du périmètre et le volume d'entretiens à conduire.
- La direction a disposé pour la première fois d'une vision consolidée des deux systèmes, de leurs dépendances réelles et de ce que chaque scénario impliquait concrètement en termes de coût, délai et ressources.
- L'audit a mis en lumière les causes structurelles de l'enlisement du projet, au-delà des symptômes techniques : méthode de construction, manque de séniorité dans l'équipe, périmètre sans garde-fou.
- Une décision structurante a été prise par la direction à l'issue de l'audit. Finacca a internalisé un CTO pour piloter la suite, première réponse directe au problème de maturité technique identifié dans le diagnostic.
Ce qu'on a appris
Les projets de migration de systèmes centraux ont une tendance commune : ils commencent petits et grossissent sans que personne ne décide vraiment que c'est ce qu'on veut. Chaque fonctionnalité ajoutée semble raisonnable prise isolément. Le problème se voit quand on prend du recul sur l'ensemble, ce que personne dans l'équipe n'a ni le temps ni la position pour faire.
La construction par blocs successifs, chacun opérationnel avant d'ouvrir le suivant, est moins spectaculaire qu'une refonte globale. Elle est aussi beaucoup moins risquée. Un projet qui livre de la valeur en continu, même lentement, reste sous contrôle. Un projet qui accumule des dépendances sans jamais finir crée une dette qui grossit chaque mois.
