Décider sans benchmark : 25 formats de connexion à migrer

Vingt-cinq façons de se connecter à la même offre. Réparties sur plusieurs sites, plusieurs produits, plusieurs générations de technologies.

Personne n’a décidé cela. Chacun de ces vingt-cinq formats a été, en son temps, une décision raisonnable : un besoin client réel, une contrainte technique du moment, un partenariat, une acquisition. Prise isolément, aucune n’était une erreur.

C’est le temps qui a fait le travail. Une décision bonne à un instant T ne l’est plus cinq, dix ou vingt ans plus tard — non pas parce qu’on s’est trompé, mais parce que le contexte a changé autour d’elle. Les standards de sécurité ont évolué. Les attentes des utilisateurs aussi. Et ce qui était une solution est devenu un cas particulier à maintenir.

Je ne prétends pas ici tirer la leçon de dix migrations. J’en vis une, en ce moment, et je suis à peu près à mi-parcours. Ce que je décris est ce que j’observe depuis l’intérieur, pas une synthèse de bonnes pratiques.

D’où viennent vraiment ces empilements

Il existe une explication paresseuse à ce type de situation : la dette technique, la négligence, le manque de vision. Elle est presque toujours fausse.

Dans mon cas comme dans beaucoup d’autres, la cause principale est la croissance externe. Les opérations de fusion-acquisition, souvent multiples et parfois en cascade, sont des machines à fabriquer de l’hétérogénéité. Chaque entité rachetée arrive avec ses clients, ses produits, ses systèmes d’identification. On intègre le commercial, on intègre le juridique, on intègre les équipes — et l’accès client, lui, reste tel quel, parce qu’il fonctionne et que le toucher demanderait un chantier que personne n’a budgété dans l’opération.

J’ai eu l’occasion d’observer ces opérations de l’autre côté, en accompagnant un cabinet spécialisé en fusions-acquisitions sur son acquisition digitale. Je n’y étais ni analyste ni expert du montage : je voyais surtout comment ces opérations se présentent et se racontent. On y raisonne en synergies, en périmètres, en valorisation.

Mon hypothèse, et je la donne pour ce qu’elle est, c’est que l’accès client relève à ce stade de la catégorie « question technique, on verra plus tard ». C’est une erreur de cadrage : l’accès n’est pas un sujet d’infrastructure, c’est le premier point de contact entre le client et le produit. Le traiter comme de la plomberie, c’est décider sans le savoir de ce que sera l’expérience de dizaines de milliers de personnes pendant les dix années suivantes.

Ce qu’on budgète, et ce qu’on paye

Un projet de migration se chiffre sur la cible. On dimensionne le nouveau système, on estime le développement, on prévoit la bascule.

Ce n’est pas là que se trouve le coût.

Le coût réel est la coexistence. Pendant toute la durée du programme — et cette durée se compte en années, pas en trimestres — les deux mondes vivent en parallèle. Chaque parcours ancien continue d’exister. Chaque cas particulier continue d’être traité. Les équipes support doivent connaître les deux systèmes. Les nouveaux développements doivent tenir compte des deux. Les tests doublent. Les incidents peuvent venir de l’un ou de l’autre.

Et cette charge ne décroît pas proportionnellement à l’avancement. Tant qu’il reste des clients sur un format, ce format reste ouvert, avec sa documentation, ses tests, sa surveillance. Passer de vingt-cinq formats à vingt-quatre demande de migrer le dernier client du vingt-cinquième — ce qui est souvent le plus difficile de tous.

C’est la première chose que je dirais à quelqu’un qui démarre : le budget que vous défendez couvre la construction. Le coût que vous allez porter est celui de la double exploitation.

Le compromis raisonnable est parfois le statu quo déguisé

Trois options étaient sur la table.

Option 1 — Conserver l’existant. Ne rien changer, continuer à maintenir les formats en place.

Option 2 — Sécuriser sans transformer. Garder les comptes partagés, mais imposer à chacun un mot de passe personnel et robuste.

Option 3 — Migrer tout le monde. Un compte personnel unique pour chaque utilisateur, quel que soit son point d’entrée.

L’option 1 a été écartée sans grande discussion. Les standards du marché avaient trop évolué, et surtout le partage de comptes posait un problème de sécurité et de traçabilité que le temps n’allait pas résoudre.

L’option 2 mérite qu’on s’y arrête, parce que c’est la plus tentante. Elle coûte moins cher. Elle demande beaucoup moins de conduite du changement. Elle passe très bien en comité, parce qu’elle a toutes les apparences de la mesure : on ne casse rien, on sécurise, on avance.

Elle a été écartée pour une raison simple : elle conservait le compte partagé. Or c’était précisément le problème à résoudre. Un mot de passe personnel sur un compte partagé, c’est de la sécurité en façade — la traçabilité reste impossible, le partage continue, et on aura dépensé un budget pour se retrouver au même endroit avec une couche de complexité en plus.

C’est un piège que j’ai appris à reconnaître : quand l’option intermédiaire préserve l’objet même du problème, ce n’est pas un compromis, c’est un report. La question à se poser est toujours la même — après cette option, le problème initial existe-t-il encore ?

Nous avons donc retenu l’option 3, en sachant qu’elle imposerait un effort considérable de conduite du changement, auprès des clients comme des équipes internes.

Il n’existe pas de benchmark pour ça

Avant de trancher, j’ai cherché des retours d’expérience publiés. Des cas réels, documentés, sur des migrations d’accès de cette nature.

Je n’ai rien trouvé d’exploitable. Le sujet cumule deux handicaps : il est très spécifique — chaque situation dépend d’un héritage particulier — et il est confidentiel. Personne ne publie le détail de ses systèmes d’identification, pour des raisons de sécurité évidentes. Ce qui existe en ligne est du contenu de fournisseur, écrit pour vendre une solution, ou de la généralité qui ne survit pas au premier cas particulier.

Mais admettons. Admettons que par le plus extraordinaire des hasards, j’aie trouvé un cas identique : même secteur, mêmes typologies d’utilisateurs, même héritage technique, avec des chiffres publiés.

Il n’aurait pas remplacé l’expérimentation. Un retour d’expérience externe est une donnée sur un autre contexte, avec ses propres clients, sa propre histoire, ses propres angles morts. Il informe une décision, il ne la valide pas.

La seule valeur de preuve, c’est de tester chez soi, sur un échantillon. Ce que nous risquions était identifiable et mesurable : l’insatisfaction des clients, et une surcharge d’appels au support. Deux effets qui se voient vite et qui se chiffrent.

C’est ce qui nous a permis d’avancer sans certitude préalable — et de constater ensuite, sur les premières vagues, que le risque redouté ne se matérialisait pas dans les proportions attendues.

Legacy ou nouveaux produits : le critère qui tranche

Le débat suivant a été plus difficile, et il est monté jusqu’au comité de direction.

Fallait-il investir dans la transformation de l’existant, ou concentrer les ressources sur les nouveaux produits, en laissant l’ancien s’éteindre naturellement ?

Les deux positions étaient légitimes, et je ne les caricature pas.

D’un côté : ne pas développer sur du jetable. Investir les ressources rares sur ce qui va durer. L’ancien est complexe, mal documenté, coûteux à toucher, et il disparaîtra de toute façon.

De l’autre : la conduite du changement doit démarrer le plus tôt possible, et simplifier la vie des clients ne peut pas attendre la sortie des nouveaux produits. C’est la position que défendait naturellement le service client, qui voit la douleur avant tout le monde.

J’ai passé du temps sur l’argument « ne pas développer sur du jetable », parce qu’il est solide.

La migration est, par essence, jetable — et ce n’est pas grave. Elle n’est pas la destination, elle est le chemin. Refuser d’investir dans le transitoire revient à refuser d’y aller.

Mais ce n’est pas cet argument qui a tranché. Ce qui a tranché, ce sont trois indicateurs :

Le nombre de clients concernés de chaque côté. Quand l’écrasante majorité des clients est sur l’existant, ignorer l’existant revient à ignorer presque tout le monde.

La valeur. Le nombre seul ne suffit pas : il faut le croiser avec le chiffre d’affaires associé, sinon on optimise pour le volume au détriment de l’essentiel.

La souffrance mesurée. Le nombre de sollicitations au support par typologie de client. C’est l’indicateur qui révèle où ça fait mal réellement, indépendamment des convictions de chacun.

Ces trois critères ont fait basculer une discussion de préférences en discussion d’arithmétique. Nous avons mené les deux chantiers en parallèle, avec la valeur et l’expérience client comme arbitre commun.

Ce que la double exécution m’a coûté

Mener les deux de front consomme des ressources doubles. Ça ne tient pas longtemps sans concession.

Des actions rapides ont été mises en place sur l’existant, ciblées sur des cas clients identifiés : campagnes d’incitation à créer un compte personnel, puis fermeture progressive de l’accès partagé. C’est là que l’expérimentation par vagues a payé — les deux risques que nous surveillions, l’insatisfaction et la surcharge du support, ne se sont pas matérialisés dans les proportions redoutées. Très peu de sollicitations, en proportion du volume touché. C’est probablement l’enseignement le plus contre-intuitif du programme : les clients acceptent le changement quand on leur explique et qu’on leur laisse le temps.

D’autres actions ont été abandonnées. L’une d’elles était la migration automatique d’une base de comptes existante, qui aurait permis de couvrir un périmètre nettement plus large sans effort de la part des clients concernés.

C’était ma proposition. J’y tenais. Ce plan aurait porté la couverture à un niveau que je considérais comme le bon objectif.

Il demandait des développements supplémentaires, alors que nous touchions déjà une large base de clients et que le calendrier était en risque. J’ai renoncé. Pas parce que j’avais tort sur le fond, mais parce que le lancement serait intervenu trop tard pour servir à quelque chose.

C’est un vrai compromis, et je le documente ici parce que c’est celui qui m’a le plus appris. Un plan de migration est une hypothèse formulée sur un système qu’on ne connaît pas encore entièrement. Il vieillit vite. Renoncer aux derniers pourcentages et aux fonctionnalités de confort, pour tenir un calendrier qui a de la valeur en soi, n’est pas un échec de conception : c’est le métier.

On ne planifie pas ce qu’on ne connaît pas

J’ai longtemps pensé qu’il fallait fixer dès le premier jour la date de fermeture de l’ancien système. Je n’y crois plus tout à fait.

Sur un système ancien, la connaissance disponible est incomplète par nature. La documentation est absente, ou elle existe mais contredit le comportement réel du code parce qu’elle n’a pas été tenue à jour. Le turn-over naturel a emporté ceux qui savaient pourquoi telle exception avait été codée. Et il reste des cas clients dont personne ne soupçonne l’existence avant de tomber dessus.

Nous avons sous-estimé cette complexité. Des découvertes sont arrivées au fil de l’eau, et chacune a décalé quelque chose.

Ce que je retiens n’est donc pas « fixez une date », mais : engagez-vous sur un objectif chiffré, et acceptez de découvrir en avançant. Un objectif chiffré crée la pression nécessaire pour que la coexistence ne devienne pas un état permanent. Une date précise, sur un périmètre qu’on ne connaît pas, ne crée que de la déception.

Où j’en suis

À mi-parcours, une majorité des clients est passée au compte personnel. Et les vingt-cinq formats de connexion existent tous encore.

Ce n’est pas une contradiction, c’est exactement le sujet de cet article. On ne ferme pas un chemin tant qu’un client l’emprunte. La fermeture est un programme à part entière, et c’est celui qui vient après.

Je publierai la suite quand j’aurai les chiffres de fin d’année. En attendant, si vous démarrez une migration : le budget que vous défendez aujourd’hui couvre la construction de la cible. Prévoyez le double, et prévoyez-le sur plusieurs années.

Sur la manière de conduire ce type de programme au quotidien — rituels, arbitrages, relation aux parties prenantes — j’ai détaillé ma pratique dans piloter une équipe produit.