Refonte de l'architecture data : quand est-ce vraiment nécessaire ?

Une refonte de l'architecture data se justifie quand l'existant ne peut plus servir les usages structurants à un coût raisonnable : besoins métier impossibles à couvrir, coûts qui progressent plus vite que les usages, composants en fin de vie ou socle que plus personne ne maîtrise. Dans les autres cas, un ajustement ou une restructuration ciblée suffit.

L'idée d'une refonte revient régulièrement dans les directions data. Elle surgit après un incident, à l'arrivée d'un nouveau responsable, à l'occasion d'un salon où un éditeur a présenté une plateforme séduisante. Elle a pour elle une promesse forte : repartir sur des bases saines et en finir avec l'accumulation de solutions provisoires.

Cette promesse a un prix rarement estimé au moment où l'idée est lancée. Une refonte immobilise les équipes pendant de longs mois, impose une période où l'ancien et le nouveau socle tournent en parallèle et fait courir un risque réel sur les usages en production. Une refonte décidée pour de mauvaises raisons consomme le budget de plusieurs années sans régler le problème qui l'a motivée.

À l'inverse, certaines organisations repoussent une refonte devenue indispensable. Elles multiplient les correctifs sur un socle qui ne tient plus, et chaque nouvel usage coûte plus cher que le précédent.

Entre ces deux écueils, la décision mérite une méthode. Elle repose sur la distinction entre les vrais signaux et les faux, puis sur une comparaison honnête entre le coût du changement et le coût du statu quo.

Refonte de l'architecture data : de quoi parle-t-on ?

Le mot « refonte » recouvre en pratique des chantiers de nature très différente. Le préciser avant toute discussion évite de comparer un remplacement complet de plateforme avec une simple réorganisation des flux.

Ajuster, restructurer, refondre : trois niveaux d'intervention

Faire évoluer une architecture data ne passe pas forcément par une refonte. Trois niveaux d'intervention se distinguent, avec des coûts et des risques sans commune mesure :

• Ajuster : corriger ou optimiser des composants existants sans changer leur rôle. Par exemple revoir la fréquence de certains traitements, supprimer des flux inutilisés ou optimiser des requêtes coûteuses.
• Restructurer : réorganiser une partie de l'architecture en conservant le socle principal. Par exemple réorganiser les couches de transformation, introduire un orchestrateur de données ou séparer un flux critique sur un circuit dédié.
• Refondre : remplacer le socle lui-même et migrer l'ensemble des usages vers une nouvelle architecture. C'est le niveau le plus coûteux, le plus long et le plus risqué.

La plupart des difficultés d'une architecture relèvent des deux premiers niveaux. La refonte ne devient la bonne réponse que lorsque l'ajustement et la restructuration ont été examinés et jugés insuffisants.

Pourquoi la décision de refonte est souvent mal calibrée

La décision de refondre se prend rarement à froid. Elle intervient dans un contexte de tension : un incident en production, une facture qui a doublé, une direction métier mécontente. Dans ce contexte, la refonte apparaît comme une réponse globale à des problèmes qui n'ont pas tous la même origine.

Deux biais reviennent souvent. Le premier consiste à attribuer à l'architecture des difficultés qui relèvent de l'organisation ou de la gouvernance. Le second consiste à sous-estimer ce que l'existant fait correctement, parce que ce qui fonctionne ne fait jamais parler de lui. Dans les deux cas, la refonte reproduit sur une nouvelle technologie une partie des problèmes de l'ancienne.

Les signaux qui justifient une refonte de l'architecture data

Certains signaux indiquent que l'architecture a atteint ses limites structurelles. Pris isolément, aucun ne suffit à justifier une refonte. Leur accumulation, en revanche, rend le statu quo plus coûteux que le changement.

Des usages structurants que l'architecture ne peut plus servir

Le premier signal est fonctionnel. Des usages importants pour l'entreprise ne peuvent pas être couverts sans contournements lourds : une prévision qui exige un historique que le socle ne conserve pas, une analyse qui croise des données que l'architecture ne sait pas réunir, un besoin de fraîcheur que les traitements actuels ne peuvent pas atteindre.

Ce signal se vérifie usage par usage. Il ne suffit pas qu'un besoin soit difficile à servir, il faut que la difficulté tienne au socle lui-même et non à un composant remplaçable. Un besoin de fraîcheur isolé, par exemple, relève souvent d'un circuit dédié plutôt que d'une refonte, comme le montre l'arbitrage entre temps réel, quasi temps réel et batch.

Des coûts qui progressent plus vite que les usages

Le deuxième signal est économique. Le coût d'exploitation de l'architecture augmente chaque année, alors que le nombre d'usages servis reste stable. Chaque nouvelle demande exige un développement spécifique, et la maintenance absorbe une part croissante du temps de l'équipe.

Avant de conclure à une refonte, ce signal doit être analysé finement. Une facture qui explose sans explication peut venir de traitements mal dimensionnés ou de données dupliquées, ce qui relève de l'ajustement. Le signal devient structurel quand la hausse tient à la conception même du socle.

Une dépendance à des composants en fin de vie

Le troisième signal est technique. Un composant central n'est plus maintenu par son éditeur, ne reçoit plus de correctifs de sécurité ou repose sur des compétences que l'entreprise ne parvient plus à recruter. Un ancien data warehouse installé sur une infrastructure vieillissante en est un exemple fréquent.

Ce signal impose une échéance. Il ne dit pas pour autant qu'il faut tout refondre. Remplacer le composant en fin de vie, en conservant le reste, reste parfois l'option la plus raisonnable.

Une architecture que plus personne ne maîtrise

Le quatrième signal est organisationnel. Les flux se sont empilés au fil des années, la documentation est absente ou obsolète, et chaque modification fait craindre un effet de bord. Les chaînes d'ETL ou d'ELT ne sont comprises que par une ou deux personnes, dont le départ ferait peser un risque majeur.

Une plateforme qui en arrive là est devenue trop complexe pour être gouvernée. La refonte peut alors être l'occasion de reprendre la maîtrise, à condition qu'elle s'accompagne d'une documentation et de règles de responsabilité que l'ancien socle n'avait pas.

Combien de signaux faut-il réunir pour décider ?

Aucun seuil universel ne permet de dire qu'au-delà de deux ou trois signaux, la refonte s'impose. La décision dépend du poids de chaque signal et de leur combinaison.

Un composant central en fin de vie, associé à plusieurs usages structurants impossibles à servir, constitue un cas solide. Une hausse des coûts isolée, sans difficulté fonctionnelle, oriente plutôt vers un ajustement. Le signal le plus déterminant reste fonctionnel : tant que les usages structurants sont servis correctement, la refonte doit prouver qu'elle apporte davantage qu'une restructuration.

En pratique, chaque signal relevé gagne à être documenté avec ses faits : les usages concernés, les coûts observés, les composants en cause. Ce dossier sert ensuite de base à la discussion avec la direction et les métiers, et il évite que la décision se prenne sur une impression.

Les faux signaux qui poussent à refondre sans nécessité

Certaines situations créent un sentiment d'urgence sans justifier une refonte. Les reconnaître évite d'engager un chantier lourd pour régler un problème qui se traite autrement.

Les faux signaux les plus fréquents sont les suivants :

• Une technologie plus récente sur le marché : l'existence d'un outil plus moderne ne prouve pas que l'outil actuel est insuffisant pour les usages de l'entreprise.
• Des lenteurs localisées : quelques tableaux de bord lents relèvent presque toujours de l'optimisation, pas du remplacement du socle.
• Des problèmes de qualité des données : des chiffres faux ou incohérents viennent le plus souvent des sources et des règles de gestion, qu'une nouvelle architecture transportera à l'identique.
• Une demande isolée de temps réel : un seul usage exigeant une forte fraîcheur se traite par un circuit dédié, sans toucher au reste de l'architecture.
• L'arrivée d'une nouvelle équipe : une équipe qui préfère d'autres outils n'est pas une raison suffisante pour remplacer un socle qui sert correctement les usages.

Ces situations méritent une réponse. Elles ne méritent pas toutes la même. La question à poser reste toujours la même : le problème tient-il au socle, ou à un composant, une règle ou une organisation que l'on peut changer sans refondre ?

Ces faux signaux ont un point commun : ils décrivent un inconfort réel, mais localisé. Le traiter par une refonte revient à mobiliser toute l'organisation pour un problème qui concerne une partie de l'architecture. La réponse proportionnée consiste à isoler la cause, à la traiter à son niveau, puis à vérifier si le problème persiste.

Refondre ou faire évoluer l'architecture data : comment trancher ?

Une fois les signaux identifiés, la décision se prend sur trois critères : l'écart entre l'existant et la cible, le rapport entre le coût de la refonte et le coût de l'inaction, et la capacité de l'organisation à mener le chantier.

Mesurer l'écart entre l'existant et l'architecture cible

La décision de refonte suppose une cible. Sans elle, il est impossible de dire si l'existant peut y mener par ajustements successifs ou s'il faut repartir d'un autre socle. La démarche consiste à définir l'architecture des données cible à partir des usages, puis à confronter chaque composant existant à cette cible.

Pour chaque composant, trois issues sont possibles :

• Le conserver : il répond aux exigences de la cible, éventuellement avec des ajustements mineurs.
• Le faire évoluer : il peut être adapté ou réorganisé pour répondre aux exigences, sans remplacement.
• Le remplacer : il ne peut pas répondre aux exigences de la cible, même modifié.

Quand le socle principal tombe dans la troisième catégorie, la refonte devient difficile à éviter. Quand seuls quelques composants périphériques sont concernés, une restructuration suffit le plus souvent.

Comparer le coût de la refonte au coût de l'inaction

Le coût d'une refonte est visible : construction, migration, double exploitation, accompagnement des utilisateurs. Le coût de l'inaction l'est beaucoup moins, ce qui biaise souvent la comparaison en faveur du statu quo.

Une comparaison équitable intègre plusieurs postes du côté de l'inaction :

• La maintenance croissante : le temps passé chaque année à maintenir et corriger l'existant.
• Les contournements métier : les extractions manuelles et les fichiers intermédiaires produits pour pallier les manques du socle.
• Les usages non servis : les décisions prises sans la donnée qui aurait dû les éclairer.
• Le risque : l'exposition liée aux composants non maintenus ou aux compétences rares.

Ces postes ne se chiffrent pas tous avec précision. Les estimer, même grossièrement, suffit souvent à éclairer une décision que l'on aurait prise par défaut.

Évaluer la capacité de l'organisation à mener le chantier

Une refonte justifiée sur le papier peut échouer faute de moyens. Elle mobilise des compétences rares, du temps métier pour la recette et une capacité à piloter un programme long. Une organisation qui sort d'un autre chantier majeur, ou dont l'équipe data est déjà saturée, prend un risque élevé en lançant une refonte immédiate.

Les limites d'une plateforme ne sont d'ailleurs pas toujours techniques. Une Modern Data Stack peut passer à l'échelle techniquement sans passer à l'échelle organisationnellement, et la même logique vaut pour une refonte : le nouveau socle ne tiendra que si l'organisation qui l'exploite est prête.

Associer les métiers à la décision de refonte

Une refonte se décide souvent entre la direction data et la DSI. Les métiers sont informés une fois le choix arrêté, alors que ce sont eux qui subiront la période de transition et qui devront valider chaque bascule.

Les associer en amont présente plusieurs avantages :

• Une évaluation plus juste des usages : les métiers savent quels usages souffrent réellement de l'architecture actuelle et lesquels fonctionnent correctement.
• Une priorisation partagée : l'ordre de migration des usages se discute avec ceux qui en dépendent.
• Une disponibilité anticipée : la recette de chaque usage migré demande du temps métier, qu'il vaut mieux planifier dès le départ.

Une refonte que les métiers découvrent au moment de la bascule a toutes les chances d'être perçue comme une contrainte, même quand elle améliore leur quotidien.

Croiser les situations les plus fréquentes avec les trois niveaux d'intervention donne une première orientation. Elle reste à confirmer par l'analyse détaillée de chaque cas, en particulier quand plusieurs situations se cumulent.

👉 À lire aussi : Architecture Data : comment faire des choix qui tiennent dans le temps ?

Mener une refonte de l'architecture data sans interrompre les usages

Quand la refonte est décidée, sa réussite dépend moins du choix des outils que de la manière de conduire la transition. L'objectif est de faire basculer les usages vers le nouveau socle sans interruption, et sans prolonger indéfiniment la coexistence des deux architectures.

Commencer par la cible, pas par le choix de l'outil

Le réflexe le plus fréquent consiste à lancer un appel d'offres dès que la refonte est décidée. Le choix d'outil se fait alors sur des démonstrations, avant que les usages et les exigences aient été formalisés.

Cette précipitation produit une nouvelle architecture choisie pour ses qualités générales plutôt que pour sa capacité à servir les usages de l'entreprise. Le temps passé à formaliser la cible avant l'appel d'offres se récupère largement pendant la construction.

Migrer usage par usage

Une refonte réussie ne bascule pas tout le socle d'un coup. Elle migre les usages un par un, en commençant par un usage structurant mais maîtrisé, qui permet de valider le nouveau socle sur un cas réel.

Chaque usage migré suit le même cycle :

• Reconstruire le flux : de la source jusqu'à l'exposition, sur le nouveau socle.
• Comparer les résultats : vérifier que les chiffres produits par les deux architectures concordent, ou expliquer chaque écart.
• Basculer les utilisateurs : accompagner le changement d'outil et de mode d'accès.
• Éteindre l'ancien flux : une fois la bascule validée, sans attendre la fin du programme.

La méthode rejoint celle d'une migration de données classique, avec une exigence supplémentaire : chaque palier doit livrer un usage complet, et pas seulement des données déplacées.

Choisir le premier usage à migrer

Le choix du premier usage conditionne la crédibilité de toute la refonte. Un premier palier qui échoue ou qui traîne fragilise le programme entier, alors qu'un premier palier réussi donne confiance aux métiers comme à la direction.

Le bon candidat réunit plusieurs caractéristiques :

• Un usage structurant : il doit compter pour les métiers, sinon sa réussite passera inaperçue.
• Un périmètre maîtrisé : peu de sources, des règles de calcul connues, un nombre limité d'utilisateurs.
• Un responsable métier disponible : quelqu'un qui peut valider les résultats et porter la bascule auprès des équipes.
• Une valeur visible : l'usage doit tirer un bénéfice concret du nouveau socle, par exemple une fraîcheur meilleure ou un historique enfin disponible.

Les usages les plus critiques, comme un reporting réglementaire, gagnent à être migrés une fois le nouveau socle éprouvé sur des cas moins exposés.

Fixer dès le départ la date d'extinction de l'ancien socle

La coexistence entre l'ancien et le nouveau socle est le poste le plus coûteux d'une refonte. Elle se prolonge facilement : un dernier rapport non migré, une équipe qui préfère l'ancien outil, une source oubliée.

Une date d'extinction fixée dès le lancement, connue de tous et suivie en comité, change le comportement des équipes. Elle oblige à traiter les derniers usages au lieu de les laisser en suspens.

Ce qu'une refonte de l'architecture data ne règle pas

Une refonte remplace un socle technique. Elle ne change pas, à elle seule, la manière dont l'organisation produit, partage et utilise ses données. Plusieurs difficultés lui survivent si elles ne sont pas traitées en parallèle.

Les définitions d'indicateurs non partagées restent non partagées sur une nouvelle plateforme. Les données de mauvaise qualité dans les sources arrivent tout aussi mauvaises dans le nouveau socle. Les usages que les métiers n'ont jamais adoptés ne le seront pas davantage avec un outil plus récent.

Une refonte réussie s'accompagne toujours d'un travail sur les règles, les responsabilités et l'accompagnement des utilisateurs. Sans ce travail, l'organisation dispose d'une architecture plus moderne, mais des mêmes difficultés à tirer parti de ses données.

La décision de refondre reste l'une des plus lourdes qu'une direction data ait à prendre. Elle mérite d'être prise sur des signaux vérifiés, face à une cible claire et avec une estimation honnête de ce que coûte le statu quo. Dans bien des cas, cette analyse conduit à une restructuration ciblée, plus rapide et moins risquée. Dans les autres, elle donne à la refonte les bases qui lui permettront de réussir.