Migrer à l'identique : payer le cloud pour rester en legacy.

La migration iso-fonctionnelle n’est pas neutre. Elle ne transporte pas seulement des flux. Elle transporte aussi des habitudes, des exceptions et des règles devenues opaques.

Le confort est réel au démarrage. On retrouve les mêmes écrans, les mêmes files, les mêmes routages. Mais la facture change vite, car le cloud exécute plus vite une logique qui n’a pas été remise à plat.

Le problème n’est pas la technologie. Le problème est la conservation mécanique d’un modèle ancien. Une plateforme neuve ne corrige pas les décisions floues. Elle les rend simplement plus visibles, plus chères et plus durables.

Le piège de la fausse simplicité

Le discours paraît rassurant. Même périmètre, même organisation, même routage. Le projet avance sans conflit ouvert, et chacun a l’impression de limiter le risque.

Cette simplicité est trompeuse. Elle évite les arbitrages difficiles et repousse le tri des usages. Les files créées pour un besoin ponctuel restent actives. Les compétences héritées survivent. Les exceptions de routage deviennent des règles de fait.

Le cloud ne nettoie rien par lui-même. Il industrialise ce qu’on lui donne. Si la logique métier n’est pas revue avant la bascule, elle se fige dans un socle plus moderne, mais tout aussi encombré.

Demandez à l’éditeur ou à l’intégrateur : "Pouvez-vous me montrer la liste complète des files, des compétences et des règles de routage, avec leur usage sur douze mois ?" Exigez un export daté, pas un tableau de synthèse. Un objet sans trafic mesurable, ou avec moins de 1 % des interactions, mérite une décision explicite.

Vérifiez aussi un piège fréquent : la file conservée "par sécurité" alors qu’elle ne sert qu’en secours manuel. Le symptôme est simple : personne ne sait dire qui l’active, ni dans quel délai. Cette zone grise finit souvent en dette permanente.

Le tri avant la bascule

La bonne approche n’est pas la refonte totale. C’est le tri. Chaque file, chaque compétence, chaque règle doit avoir un propriétaire métier identifié et une raison d’exister.

Sans propriétaire, la règle devient orpheline. Sans raison, elle devient patrimoine. C’est ainsi que les contournements se transmettent d’un projet à l’autre, puis se multiplient dans le nouveau socle.

Le tri doit rester binaire. Migrer, fusionner ou supprimer. Dès qu’une quatrième option apparaît, comme "on verra après", la dette entre dans le cadrage et sort rarement du projet.

Demandez : "Qui signe la conservation de cette file, et qui assume sa suppression ?" Demandez une réponse nominative, pas une fonction générique. Un critère vérifiable peut être inscrit au contrat : aucune règle ne passe en production sans propriétaire métier, date de décision et motif de conservation.

Le piège classique est la règle maintenue parce qu’elle "pourrait servir". Le symptôme est un catalogue qui grossit sans baisse du volume actif. Plus le nombre d’objets non tranchés augmente, plus la migration devient une simple copie de l’héritage.

Le volume réel, pas le volume supposé

Les équipes surestiment souvent l’importance des structures héritées. Une file paraît critique parce qu’elle existe depuis longtemps. Un routage semble sensible parce qu’il a survécu à plusieurs réorganisations.

Le seul juge utile reste le trafic réel. Douze mois de volumes donnent une lecture plus fiable que les impressions internes. Ils révèlent les doublons, les impasses, les pics saisonniers et les exceptions devenues normales.

Un faible volume ne signifie pas suppression automatique. Il peut cacher une file de secours, un usage réglementaire ou une activité saisonnière. Mais il impose une justification écrite et une validation métier claire.

Demandez les exports historiques par file, par compétence et par règle. "Pouvez-vous me fournir les volumes mensuels, les pics et les périodes creuses sur douze mois ?" Exigez un rapprochement entre trafic observé et trafic supposé. Si l’écart dépasse 20 %, la règle doit être réexaminée.

Le piège est la file "historique" que tout le monde croit critique. Le symptôme est un volume faible, mais une forte peur de la toucher. Cette peur signale souvent une dépendance mal documentée, pas une vraie criticité.

Le coût caché de la dette de configuration

La dette de configuration ne ressemble pas à une panne. Elle ressemble à une accumulation de micro-décisions. Chaque réglage paraît acceptable, puis l’ensemble devient opaque.

Plus la base est héritée, plus chaque changement coûte cher. Une modification simple exige alors plusieurs validations, plusieurs tests et plusieurs exceptions. La plateforme moderne perd son avantage, car elle porte une logique trop dense pour rester lisible.

Le cloud ne corrige pas un legacy. Il le facture plus vite.

Le bon indicateur n’est pas le nombre de fonctionnalités migrées. C’est le nombre de règles justifiées, maintenables et attribuées. Si ce nombre n’est pas mesuré, la complexité a déjà pris la main.

Demandez à l’intégrateur : "Quel est le seuil maximal de règles par file, et comment le contrôlez-vous ?" Faites inscrire un critère contractuel vérifiable : toute règle sans propriétaire, sans test associé ou sans documentation de changement est refusée en recette. Le piège, ici, est la configuration qui fonctionne mais que personne n’ose modifier. Le symptôme est un délai de changement qui s’allonge à chaque demande.

Ce qu’il faut exiger avant la migration

Je regarde trois preuves. Un inventaire exhaustif. Un propriétaire métier par objet. Une décision explicite pour chaque file, compétence et règle.

Sans ces trois éléments, la migration copie l’existant. Avec eux, elle devient un tri. La différence se voit avant la conception détaillée, pas après la mise en service.

Demandez un tableau unique avec trois colonnes : migrer, fusionner, supprimer. Ajoutez le volume réel, le propriétaire et la justification. "Pouvez-vous me livrer ce tableau avant le gel de conception ?" Refusez toute ligne sans décision signée.

Exigez aussi un critère de sortie clair : aucune bascule tant que 100 % des objets n’ont pas un statut, un responsable et une date de revue. Le piège final est le lot "à traiter après", qui grossit jusqu’à devenir la nouvelle dette de référence.