Les 10 étapes clés de la migration d'une solution de reporting décisionnel

De toutes les composantes d'un système d'information décisionnel, la solution de reporting est la brique la plus visible. Largement éprouvée, cette méthodologie permet de prendre en compte les impératifs techniques, la sécurité et les attentes des utilisateurs.

1. Cadrage & étude de l’existant

L’objectif de cette phase de préparation est double. Il s’agit à la fois de sensibiliser les acteurs concernés et de réaliser une cartographie de l’outil dans sa version existante. Ce travail de sensibilisation et de cartographie se fait en ateliers avec les utilisateurs métiers. À l’issue des ateliers, le périmètre à migrer est clairement défini, ainsi que la stratégie de migration.

2. Passage en revue des licences

La migration est l’occasion de réévaluer le parc de licences et de le redimensionner. Il n’est pas exceptionnel de découvrir, grâce à cet examen, qu’un certain nombre de licences sont inutilisées, ce qui représente un surcoût sans objet pour l’entreprise. Cet examen du parc de licences est d’autant plus nécessaire que le mode de licensing peut varier d’un éditeur à un autre, de même qu’il peut avoir évolué entre deux versions d’une solution du même éditeur.

3. Sauvegarde de l'environnement existant

La sauvegarde de l’environnement existant est une précaution indispensable. Cette opération consiste à réaliser une "photo" du système de reporting existant afin de pouvoir le restaurer dans un état que l’on sait stable en cas de problème lors de la migration. Dans le cas où l’on migre vers la solution d’un autre éditeur, il faut également prévoir de pouvoir fonctionner en double système tant que la migration n’est pas terminée.

4. Identification des contenus en doublon, inutiles, inactifs…

Au fil du temps, il est inévitable que les utilisateurs d’une solution de reporting dupliquent des rapports, créent des documents temporaires qui ne sont jamais supprimés, cessent d’utiliser certains documents… Tous ces éléments alourdissent inutilement le système de reporting et amoindrissent ses performances. La migration vers une nouvelle solution/version est l’occasion de procéder à un grand nettoyage pour repartir sur de bonnes bases.

5. Nettoyage des dossiers

Suite logique de la phase précédente, les contenus inutiles, obsolètes et inutilisés sont isolés. Ils ne seront pas pris en compte dans les étapes suivantes. L’arborescence y gagne en lisibilité, ce qui permet de mieux évaluer le travail à réaliser pour migrer efficacement les contenus utiles vers la nouvelle solution.

6. Analyse d'impact

Toute nouvelle version d’un logiciel s’accompagne de nouvelles fonctionnalités et de modifications fonctionnelles qui vont avoir un impact sur les objets existants et les modes d’utilisation. Cette analyse vise à anticiper les impacts de la migration sur le contenu et sur la sécurité. C’est aussi lors de cette étape que l’on anticipe les besoins en matière de conduite du changement et de formation des utilisateurs finaux.

7. Comparaison entre ancienne & nouvelle version

Cette opération technique consiste à comparer le nouvel environnement avec l’ancien. On vérifie que les contenus ont bien été migrés, qu’ils sont conformes à ce qu’ils étaient et qu’ils s’actualisent correctement. On vérifie également que tous les profils utilisateurs ont été récupérés et on s’assure qu’il n’y a pas de régression au niveau de la sécurité et des droits individuels.

8. Qualification & tests de non régression automatisés

Lors de cette étape, tous les éléments de reporting existants vont être testés : chaque document  est ouvert simultanément dans l’ancienne version et dans la nouvelle, puis est actualisé afin de voir comment il se comporte. Cette opération ne peut être réalisée à la main. On utilise donc un logiciel tiers qui automatise toute la procédure. Les résultats des tests de non régression sont capitalisés dans des cahiers de recettes et chaque régression identifiée fait l’objet de corrections.

9. Mise à niveau de tous les environnements avec le contenu testé

Dans la plupart des contextes, l’entreprise possède au moins deux environnements – un environnement de production et un environnement de développement. Lorsque l’on opère la migration qui permet de réaliser les deux étapes précédentes, on migre exclusivement le référentiel de production de l’ancienne version vers la nouvelle. Une fois celui-ci testé et qu’on est en mesure de certifier que cet environnement est stable, on initialise l’environnement de développement dans la nouvelle version avec le contenu du premier environnement. On en vérifie le bon fonctionnement à travers une série de tests.

10. Sécurisation du contenu

Avant la bascule finale, on profite de la migration pour réétudier la sécurité qui a été récupérée de l’ancienne version. Pour une sécurité optimale et des responsabilités traçables, nous recommandons la mise en place de matrices de sécurité. Prenant en compte tous les utilisateurs et tous les dossiers, elles permettent de spécifier les droits individuels vis-à-vis des dossiers, des données et des applications.

La bascule définitive

À l’issue de cette dernière étape, on considère que tout est en ordre de marche et on peut procéder à la bascule définitive. Cela signifie que tous les utilisateurs vont désormais travailler sur la nouvelle version/solution. L’ancienne plateforme restera active pendant une période convenue de façon à pouvoir récupérer à la demande des éléments qui n’auraient pas été migrés avec succès. Lorsque toute la démarche a été conduite dans les règles et en lien avec les utilisateurs, les recours à l’ancienne version sont exceptionnels.