Migrer vers le Cloud sans migrer toute la dette

Une migration vers le Cloud crée une échéance nette. Il faut choisir une cible, préparer une bascule et démontrer que l’activité peut continuer. Cette contrainte est utile : elle oblige à regarder une plateforme dont les décisions se sont parfois accumulées pendant des années.

La tentation est pourtant forte de traiter l’opération comme une reproduction. Plus la cible ressemble à l’existant, plus le changement paraît simple à expliquer. Mais une copie fidèle peut aussi transporter des projets abandonnés, des champs sans propriétaire, des droits devenus illisibles, des applications redondantes et des automatisations que personne ne sait encore justifier.

Le Cloud ne supprime pas cette dette. Il offre une occasion de décider ce qui mérite réellement d’y entrer.

Transformer l’inventaire en carte de décisions

Un inventaire utile ne se limite pas à compter les projets, espaces, utilisateurs ou pièces jointes. Il relie chaque élément important à un usage, un propriétaire et une décision.

Pour une plateforme Atlassian, cette lecture couvre généralement plusieurs couches :

• les produits, projets Jira, espaces Confluence et portails de service ;
• les utilisateurs, groupes, rôles, permissions et mécanismes d’identité ;
• les workflows, champs, écrans, types de demandes et automatisations ;
• les applications Marketplace et les fonctions qu’elles rendent possibles ;
• les intégrations, scripts, échanges de données et dépendances externes ;
• les obligations de conservation, de sécurité et de traçabilité ;
• les parcours métier qui doivent continuer à fonctionner.

L’objectif n’est pas de produire le fichier le plus long. Il est de rendre les arbitrages explicites. Pour chaque ensemble, quatre décisions suffisent souvent à structurer le travail : migrer en l’état, transformer, archiver ou abandonner.

Ces décisions doivent avoir un responsable et une justification. Sans cela, le principe implicite devient « nous migrons tout par prudence ». C’est précisément ainsi que l’on conserve une complexité que plus personne n’a choisie.

Rationaliser sans ouvrir un programme sans fin

Une migration n’est pas toujours le bon moment pour refondre chaque processus. Chercher la cible parfaite peut retarder indéfiniment la bascule et multiplier les changements simultanés.

Il faut donc séparer trois catégories :

1. ce qui doit être corrigé avant migration parce que cela empêche ou fragilise le passage ;
2. ce qui gagne à être rationalisé maintenant parce que le bénéfice est clair et le risque maîtrisé ;
3. ce qui peut être repris temporairement puis traité dans une trajectoire d’amélioration documentée.

Cette distinction protège le calendrier sans renoncer à la qualité. Elle évite aussi de présenter comme « à l’identique » une transformation qui comporte en réalité des changements de fonctionnalités, de sécurité ou d’expérience utilisateur.

Répéter pour apprendre, pas seulement pour rassurer

Une migration de test n’est pas une répétition cérémonielle destinée à confirmer le plan initial. C’est un instrument de mesure.

Elle permet d’observer la durée réelle des opérations, les conversions imparfaites, le comportement des applications, les différences de permissions et les étapes encore manuelles. Elle révèle surtout les écarts entre l’inventaire théorique et les usages rencontrés dans les données.

Chaque passage devrait donc produire quelque chose de vérifiable : un journal des écarts, une décision de transformation, un temps mesuré, un scénario de test enrichi ou une mise à jour du runbook. Rejouer exactement le même processus en espérant un résultat différent n’apporte pas de confiance supplémentaire.

Les critères de passage doivent également être décidés avant la dernière répétition. Quels écarts sont bloquants ? Qui peut accepter un risque résiduel ? Quel seuil impose un retour arrière ? Une décision de go/no-go est plus solide lorsqu’elle s’appuie sur ces règles plutôt que sur l’optimisme du jour de bascule.

Construire les vagues autour des dépendances

Découper par équipe ou par pays est facile à comprendre, mais ne suffit pas toujours. Deux périmètres apparemment séparés peuvent partager une application, une synchronisation, un annuaire ou un rapport transverse.

Une vague cohérente tient compte de la criticité, des dépendances et de la capacité à apprendre. Un premier périmètre doit être suffisamment représentatif pour tester la méthode, mais assez maîtrisé pour que les écarts restent récupérables. Les vagues suivantes réutilisent ce qui a été appris au lieu de repartir de zéro.

Cette approche oblige à regarder la plateforme comme un système. Elle réduit le risque qu’un périmètre déclaré « migré » dépende encore silencieusement d’un composant resté sur l’ancienne plateforme.

Tester les parcours métier de bout en bout

Comparer des volumes est indispensable : nombre de projets, d’espaces, de tickets, de pièces jointes ou d’utilisateurs. Mais une égalité de lignes ne prouve pas que le travail peut reprendre.

La recette doit parcourir des situations réelles : créer et traiter une demande, rechercher une connaissance, exécuter une automatisation, approuver un changement, produire un rapport, suivre un lien entre Jira et Confluence ou vérifier qu’un utilisateur voit exactement ce qu’il doit voir.

Ces tests doivent être portés par des personnes qui connaissent le processus, pas uniquement par l’équipe de migration. Ils transforment une vérification technique en preuve de continuité. L’article Une migration d’outil vaut par la visibilité qu’elle rend possible développe ce principe sous l’angle de l’usage et de la décision.

Préparer l’hypercare avant la bascule

L’hypercare n’est pas une période vague pendant laquelle l’équipe projet reste disponible. Il faut définir les canaux de remontée, les priorités, les responsables, les horaires de décision et la manière de distinguer un incident, une incompréhension et une demande d’évolution.

Cette préparation évite que les premiers jours soient absorbés par un flux non qualifié. Elle permet aussi de repérer les signaux d’adoption : difficultés récurrentes, recherche de fonctions disparues, contournements ou besoins de formation ciblée.

Le cas d’une grande plateforme Atlassian migrée vers le Cloud rassemble les faits publics d’une transformation conduite par vagues, avec répétitions, tests métier et hypercare. Le cas détaillé publié par Ovyka (s’ouvre dans un nouvel onglet) (opens in a new tab) présente l’échelle des plateformes, la démarche suivie et les résultats observés.

Une migration est une série de décisions

La réussite ne vient pas d’une promesse de copie parfaite. Elle vient d’un ensemble de décisions traçables : ce qui entre dans la cible, ce qui change, ce qui reste hors périmètre, ce qui a été prouvé et ce qui sera encore surveillé après la bascule.

Migrer moins n’est pas toujours la bonne réponse. Migrer consciemment l’est presque toujours. Le Cloud devient alors autre chose qu’une nouvelle destination technique : un point de départ plus lisible pour la suite.