Les bonnes pratiques pour bien migrer

Sur ce marché, par exemple, il existe des centaines de fournisseurs, malgré les regroupements intervenus ces dernières années. Les principales raisons qui poussent les entreprises à changer d’éditeur de BI sont essentiellement la perte de confiance dans l’éditeur en place, le fait qu’une solution n’est plus supportée ou qu’elle n’offre pas certaines fonctionnalités, par exemple des capacités évoluées de visualisation ou en matière de mobilité dans le domaine de la Business Intelligence.

Outre le choix de la nouvelle solution et de fonctionnalités mieux adaptées à l’évolution des besoins, dans tous les cas, se pose le problème de la migration de l’ancienne solution à la nouvelle. Pour mener à bien ce type de chantier, plusieurs bonnes pratiques sont recommandées.

1. Créer une task force spécifique. La migration constitue un projet à part entière et suppose des ressources dédiées non seulement pour les aspects techniques, mais également pour les aspects organisationnels.
2. Définir la roadmap de migration. La planification est essentielle, notamment pour éviter les incohérences, surtout si la solution est très structurante pour les métiers.
3. Auditer le patrimoine applicatif. L’objectif est de s’assurer que le patrimoine applicatif reste cohérent avec la nouvelle solution et de vérifier qu’il n’y a pas de doublons pour répondre à un même besoin. Ainsi, une solution beaucoup plus fédératrice conduira à éliminer des solutions de niche.
4. Synthétiser les nouveaux usages. La migration doit prendre en compte un maximum de nouveaux besoins de manière à pérenniser les investissements. Il ne s’agit pas d’être exhaustif, mais d’éviter d’oublier des fonctionnalités importantes.
5. Procéder à une analyse de risques. La migration est toujours source de risques et on ne compte plus les incidents, souvent sérieux, qui sont liés à des changements de solutions, voire à de simples montées de versions.
6. Rassurer les utilisateurs avec des projets pilotes. Un changement d’application, même mineur, constitue une source de perturbations, voire de stress, pour les utilisateurs. Il est important de les rassurer, notamment en mettant en avant le fait que la nouvelle solution va simplifier leurs tâches au quotidien. Un projet pilote, ou un POC, sont utiles pour montrer l’application en situation réelle. Dans le domaine du décisionnel, par exemple, on peut travailler à partir d’un échantillon d’univers par domaine fonctionnel et de rapports qui, après conversion, sont testés auprès des utilisateurs pour leur montrer ce dont ils disposeront après la migration (ergonomie, navigation, nouveaux processus…).
7. Réaliser un cadrage préliminaire pour limiter la migration à ce qui est indispensable. Tout migrer n’est souvent pas indispensable et il est souvent utile, à cette occasion, de « faire le ménage », par exemple dans le domaine du décisionnel : Lorsqu’il y a plusieurs centaines ou milliers de rapports destinés aux utilisateurs, il faut identifier ceux qui sont vraiment utiles, consultés et opérationnels, et enlever les doublons et ceux qui sont obsolètes.
8. Analyser la structure et la qualité des données. Une migration constitue une occasion de réaliser ce qui n’est jamais, ou rarement, fait par les équipes de la DSI ou les métiers, faute de temps : se pencher sur la qualité des données. Dans ce domaine, on a souvent des surprises, surtout pour des applications anciennes : d’un côté, les métiers créent des données en pensant que la DSI dispose des outils pour corriger toutes les incohérences ; d’un autre côté, la DSI estime que c’est aux métiers de vérifier la cohérence des informations.
9. Identifier les outils d’automatisation de la migration. Une migration à la manière artisanale n’est pas une option envisageable, sauf peut-être pour quelques fichiers dont la taille est raisonnable ou dans de petites entreprises. Heureusement, il existe des outils qui permettent d’automatiser. Les éditeurs concernés par la migration proposent des solutions d’automatisation ou des services facturés à la journée.
10. Tester la non-régression. Le changement d’application peut occasionner des perturbations de type pertes de données et d’intégrité des informations. Les tests de non-régression permettent de s’assurer que la nouvelle application n’altère pas l’existant.
11. Vérifier la stabilité de la nouvelle solution en conservant momentanément l’ancienne solution en fonctionnement. La migration a évidemment pour objectif d’abandonner une ancienne solution pour la remplacer par une nouvelle. Il est utile de définir une période plus ou moins longue en fonction de la complexité de l’application et du nombre d’utilisateurs de manière à bien vérifier que tout fonctionne. En cas de difficultés, il sera toujours possible de revenir en arrière de manière à ne pas perturber les utilisateurs.
12. Gérer les temps d’indisponibilité lors du passage d’une solution à l’autre. Même si les deux solutions, l’ancienne et la nouvelle, fonctionnent en parallèle pendant un certain temps et sont testées, il arrivera un moment où il faudra « débrancher » l’ancienne solution. En fonction de la complexité de la solution, il peut être nécessaire que les équipes anticipent une indisponibilité : celle-ci peut être volontaire et planifiée (de quelques minutes à quelques heures), mais elle peut aussi être involontaire, en cas de dysfonctionnement qui n’aura pas été identifié de manière préventive. Dans le premier cas, il convient de communiquer en amont auprès des utilisateurs ; dans le second cas, il est utile d’anticiper, par exemple avec des ressources techniques (internes ou externes) supplémentaires, et d’avoir prévu des procédures de gestion de crise et de communication spécifiques.
13. Organiser la formation. Même une évolution mineure d’application va perturber le quotidien des utilisateurs. La formation aux nouvelles fonctionnalités est indispensable et elle présente trois avantages : une réduction du temps d’appropriation de la nouvelle solution par les utilisateurs, une limitation des appels au support technique et une amélioration de la satisfaction des utilisateurs.
14. Gérer le changement. Outre la formation, des applications très structurantes pour les métiers nécessitent un accompagnement bien au-delà de la période de mise en œuvre de la nouvelle solution. Surtout si elle s’accompagne d’une reconfiguration des processus, d’évolutions organisationnelles ou de besoin profond de mise à niveau des compétences.