La recette d’une migration BI ne cherche pas à démontrer que le nouveau socle reproduira mécaniquement l’ancien. Elle sert à mesurer les écarts, à retrouver leur origine et à faire signer des critères d’acceptation avant la bascule. Sans protocole avant migration et après migration, le débat se déplace en production.
En bref
- Le périmètre de recette doit partir des rapports réellement consultés, des règles de gestion cachées dans les univers et des flux qui alimentent les indicateurs pilotés.
- Un écart de chiffre d’affaires, de marge ou de stock doit être expliqué par une règle, une période, un filtre ou une ligne de données manquante, jamais seulement constaté.
- La recette combine des contrôles exhaustifs, des comparaisons d’agrégats et des scénarios métier signés par les responsables concernés.
- Le double run réduit le risque de bascule lorsque les rapports concernent la finance, les opérations ou la clôture mensuelle.
- La migration BI peut être arrêtée si le coût de reprise dépasse la valeur des rapports encore utilisés ou si les règles de gestion ne peuvent pas être validées.
Ce protocole s’adresse aux responsables BI, chefs de projet décisionnel et équipes métier qui remplacent un parc de rapports, un univers BusinessObjects, un modèle BW ou une couche OBIEE. Il ne traite pas la négociation des licences, la protection des données personnelles ou le droit des contrats, qui relèvent respectivement de votre acheteur, de votre DPO et de votre direction juridique.
Comment cadrer la recette avant migration BI sans tester un périmètre inutile
La première erreur consiste à lancer la recette sur tout ce qui existe dans le catalogue technique. Un serveur peut contenir plusieurs centaines de documents Web Intelligence, de requêtes BEx ou d’analyses OBIEE, sans que cet inventaire reflète l’usage réel. La recette doit couvrir ce qui soutient une décision, une clôture, une facturation, un contrôle opérationnel ou une obligation de reporting interne.
Le point de départ est donc un relevé d’usage. Les journaux d’audit, l’historique des exécutions planifiées et les droits d’accès apportent une première liste. Cette liste reste insuffisante si la rétention des logs est limitée à quelques mois. Un rapport annuel peut paraître absent alors qu’il sera ouvert au prochain exercice. Il faut donc rapprocher les traces techniques des calendriers métier et des échanges avec les propriétaires fonctionnels.
Sur un parc BusinessObjects, le périmètre doit distinguer les Webi consultés à la demande, les documents planifiés, les exports transmis hors de l’outil et les rapports utilisés comme source d’un autre processus. Un document peu ouvert peut alimenter chaque lundi un fichier envoyé à la direction. Le compteur de consultations ne suffit pas à le classer comme rapport fantôme.
Documenter les règles qui ne figurent pas dans le rapport
Une grande partie des écarts apparaît parce que la règle de gestion est placée hors du document visible. Dans un univers BusinessObjects, un filtre de statut client peut être défini dans la condition d’un objet et non dans les filtres Webi. Dans BW, une variable obligatoire peut restreindre une requête avant même que l’utilisateur choisisse sa période. Dans OBIEE 12c, une règle de sécurité de ligne peut modifier le résultat selon le rôle connecté.
Le dossier de recette doit donc identifier la source technique, la requête, les objets sélectionnés, les filtres, les invites, les contextes, les jointures et les calculs locaux. Il doit aussi nommer le propriétaire métier qui confirme l’interprétation. Sans cette ligne de responsabilité, une anomalie circule entre l’équipe d’intégration et les utilisateurs jusqu’à ce que la date de bascule devienne le seul sujet de discussion.
Microsoft recommande une démarche de migration Power BI organisée par vagues, avec une évaluation du contenu et des dépendances avant la conversion des rapports. Cette méthode est décrite dans la documentation officielle sur la planification d’une migration Power BI, consultée le 18 mars 2026. Elle ne dispense pas de reconstituer les règles enfouies dans votre socle source.
| Élément à inventorier | Preuve avant migration | Contrôle attendu après migration | Décision possible |
|---|---|---|---|
| Rapport Webi ou analyse OBIEE | Fréquence d’ouverture, propriétaire et calendrier d’usage | Exécution sur la cible avec le même périmètre fonctionnel | Reprendre, reconstruire ou retirer |
| Univers, modèle sémantique ou requête BW | Objets, contextes, variables et restrictions de sécurité | Traçabilité du mapping vers mesures, dimensions et rôles | Valider ou revoir le modèle cible |
| Flux ETL et tables d’alimentation | Horaires, volumes, règles de rejet et dépendances | Contrôle de complétude et de fraîcheur des chargements | Conserver, remplacer ou isoler le flux |
| Indicateur de pilotage | Formule validée, période de référence et responsable métier | Écart chiffré, expliqué et accepté | Autoriser ou refuser la bascule |
Ce tableau constitue un croisement minimal entre objet technique, preuve disponible et décision. Il doit être complété à partir de vos propres exports d’audit. Aucun environnement client n’a été ouvert pour cet article. Les contrôles proposés reposent sur la documentation éditeur et sur un protocole de recette applicable à BusinessObjects, BW, OBIEE, PowerCenter ou Talend.
Le périmètre utile n’est pas celui qui contient le plus de rapports. C’est celui qui permet d’expliquer les chiffres qui seront contestés le premier jour.
Quels contrôles préparer avant migration pour rendre les écarts explicables
Avant migration, la recette doit produire une photographie opposable de l’ancien socle. Cette photographie ne se limite pas à exporter les données. Elle fixe la période analysée, l’heure d’extraction, les paramètres utilisés, les populations incluses et les exceptions connues. Sans ces éléments, comparer deux totaux revient à comparer deux requêtes dont personne ne maîtrise le contexte.
La première série de contrôles porte sur la complétude. Il faut vérifier que les lignes attendues sont présentes, que les clés techniques sont exploitables et que les historiques nécessaires ont été repris. Une absence de ligne n’a pas la même conséquence selon qu’elle concerne une commande annulée, un client fermé ou une facture émise. La règle d’inclusion doit être écrite avant l’extraction.
La deuxième série porte sur les agrégats. Les indicateurs financiers et opérationnels doivent être calculés par période, société, entité, produit, canal ou tout axe réellement utilisé par les métiers. Comparer uniquement un total national masque souvent les écarts de jointure ou les erreurs de rattachement. Un chiffre consolidé peut être juste alors que deux filiales se compensent par erreur.
Construire un jeu de référence avant de transformer les données
Le jeu de référence rassemble les extractions source, les paramètres de requête, les résultats agrégés et les cas métier retenus. Il doit être conservé dans un espace versionné et accessible à l’équipe de recette. Le fichier envoyé par courriel la veille de la réunion ne permet ni de tracer une correction ni de déterminer quel résultat faisait foi.
La transformation des données doit également être visible. Une date convertie, une clé de client dédoublonnée ou une devise retraitée modifie le résultat final. Cette transformation peut être justifiée, mais elle ne doit pas être découverte lors de la validation métier. Le mapping doit donc indiquer la colonne source, la règle appliquée, la colonne cible et le contrôle associé.
Les contrôles exhaustifs sont adaptés aux clés, aux volumes et aux montants agrégés. Les contrôles par échantillon sont adaptés aux règles complexes, aux libellés et aux cas d’exception. Les deux sont nécessaires. Un rapprochement exhaustif peut confirmer que 100 % des lignes ont été chargées sans démontrer que le calcul de marge repose sur le bon coût standard.
Un protocole robuste prévoit aussi les données rejetées. Une ligne rejetée par le workflow ETL doit porter un motif, une date, une clé de rapprochement et une décision. Elle sera corrigée, exclue avec validation métier ou réinjectée dans un traitement ultérieur. Le pire cas reste la ligne silencieusement perdue, car elle ne peut plus être recherchée après la mise en production.
- Extraire les données source à une date et une heure connues, avec les paramètres de la requête conservés.
- Calculer les volumes, les montants et les comptes distincts selon les axes de pilotage réellement utilisés.
- Identifier les règles de transformation appliquées par les flux, les univers et les calculs locaux des rapports.
- Constituer des scénarios métier comprenant les cas standard, les annulations, les corrections et les situations de bord.
- Faire valider le jeu de référence par le propriétaire de chaque indicateur avant le chargement cible.
Cette discipline est particulièrement utile lorsqu’un parc BusinessObjects est repris vers Power BI. La conversion d’un univers en modèle sémantique ne transfère pas automatiquement les contextes de requête, les objets avec liste de valeurs ni les calculs Webi. Le détail de cette rupture fonctionnelle doit être traité avant de choisir une reprise systématique, comme l’explique ce dossier sur le passage de BusinessObjects vers Power BI.
Le nettoyage ne doit pas être confondu avec une suppression indistincte. Retirer des doublons, normaliser un code pays ou corriger une date impossible relève d’une décision documentée. Si un même client est présent deux fois avec des identifiants distincts, la fusion peut modifier les historiques et les agrégats. Les utilisateurs doivent valider les cas ambigus, car une automatisation de dédoublonnage ne connaît pas la raison commerciale d’une exception.
Le jeu de référence doit rester stable pendant la recette. Si les données source changent sans nouvel horodatage, les équipes compareront des périodes différentes et attribueront à la cible des écarts qu’elle n’a pas produits.
Comment chiffrer la charge de recette et de réconciliation avant la bascule
La charge de recette est souvent sous-estimée parce qu’elle est absorbée dans la reprise des rapports. Pourtant, reproduire un visuel et expliquer les écarts qu’il produit sont deux travaux différents. Un rapport peut être techniquement disponible sur la cible tout en restant non recevable pour le pilotage si le chiffre de référence n’est pas réconcilié.
Un chiffrage défendable sépare au minimum l’inventaire, le mapping, la préparation des jeux de référence, l’exécution des tests, la correction des anomalies et la validation métier. La formation, la reprise des droits, les changements de processus et les licences n’entrent pas dans cet exemple. Les ajouter au même total sans les isoler rend le budget inutilisable.
Un exemple de charge calculé avec des hypothèses visibles
Considérons un parc de 240 rapports. L’inventaire d’usage sur douze mois permet de retenir 150 rapports actifs. Parmi eux, 90 sont classés comme rapports à logique limitée, 45 comportent des calculs, des filtres conditionnels ou plusieurs sources, et 15 alimentent une clôture mensuelle ou un indicateur de direction. Les ratios ci-dessous sont des hypothèses de budget pour un protocole de recette ; ils ne constituent pas un tarif ni une promesse de durée.
| Catégorie de rapport | Nombre retenu | Préparation et test par rapport | Charge calculée |
|---|---|---|---|
| Logique limitée | 90 | 4 heures | 360 heures |
| Logique intermédiaire | 45 | 10 heures | 450 heures |
| Indicateur critique | 15 | 22 heures | 330 heures |
| Pilotage de recette et consolidation des anomalies | 1 périmètre | 160 à 240 heures | 160 à 240 heures |
Le calcul donne une charge comprise entre 1 300 et 1 380 heures pour la préparation et l’exécution de la recette. Il exclut la construction initiale des rapports, les ateliers de formation, la reprise des habilitations et le traitement des changements de périmètre. La variation dépend surtout du nombre d’itérations nécessaires sur les 15 indicateurs critiques.
Ces ratios doivent être ajustés après un pilote. Sur un échantillon de dix rapports, l’équipe mesure le temps réellement passé à retrouver les règles, à produire les contrôles et à obtenir une décision. Si les dix premiers rapports montrent que les calculs locaux Webi sont plus nombreux que prévu, l’estimation des 140 suivants doit être revue avant d’engager une date de bascule.
La documentation Microsoft distingue d’ailleurs l’évaluation, la préparation, la migration et l’adoption dans son cycle de migration Power BI, consulté le 18 mars 2026 sur Microsoft Learn. Cette séparation confirme un point de méthode : la recette ne peut pas être réduite à une dernière semaine de contrôle.
Le coût de reprise d’un rapport dépend aussi de la cible retenue. Un Webi très tabulaire peut nécessiter un rapport paginé plutôt qu’un tableau de bord interactif. Le comparer à un visuel Power BI sans analyser son usage produit une reprise esthétiquement proche mais fonctionnellement insuffisante. Le cas des documents destinés à l’impression est détaillé dans cette analyse du passage de Webi vers les rapports paginés Power BI.
Sur un parc de moins de cent rapports, dont plus de la moitié ne sont plus consultés, la reconstruction ciblée coûte souvent moins de charge de recette qu’une reprise fidèle de tout l’existant. Au-delà de trois cents rapports actifs avec des règles non documentées, la reprise structurée devient plus prudente, car reconstruire oblige à réinterpréter trop de logique métier en même temps.
Le budget ne doit pas retenir un seul nombre. Il doit présenter une fourchette, les hypothèses qui l’expliquent et les éléments exclus, afin que l’arbitrage puisse être révisé dès les résultats du pilote.
Comment exécuter la recette après migration sans promettre l’identité des chiffres
Après migration, le sujet n’est pas de déclarer que les chiffres sont identiques. Cette promesse est rarement tenable. Les modèles changent, les périodes de chargement diffèrent, les arrondis évoluent et des règles auparavant implicites sont rendues explicites. La question correcte est de savoir si chaque écart est compris, mesuré et accepté au regard de son usage.
Le protocole commence par les contrôles de structure. Les tables attendues sont-elles chargées, les dimensions sont-elles reliées, les dates sont-elles disponibles, les comptes techniques correspondent-ils au périmètre source ? Ces contrôles ne remplacent pas les tests métier, mais ils évitent de perdre une journée à discuter d’un indicateur alors qu’un flux n’a pas terminé son chargement.
Viennent ensuite les contrôles de complétude. Le nombre de lignes, le nombre de clés distinctes et les volumes par période doivent être rapprochés. Une différence est enregistrée comme anomalie dès qu’elle dépasse la tolérance définie. La tolérance doit être adaptée à l’indicateur. Pour un nombre de factures, l’attente peut être zéro ligne manquante. Pour un montant issu d’une conversion de devise ou d’un arrondi, une tolérance bornée peut être nécessaire.
Qualifier un écart plutôt que le masquer dans une règle de calcul
Chaque anomalie doit posséder un identifiant, un rapport concerné, une période, une valeur source, une valeur cible, un écart absolu, un écart relatif, une cause supposée, un responsable et une décision. Cette traçabilité évite les corrections locales dans un rapport, qui font disparaître l’écart sans corriger le modèle sémantique ou le flux d’intégration.
Un écart de 0,4 % sur le chiffre d’affaires peut paraître faible. Il ne l’est pas s’il provient d’un filtre de statut client appliqué dans la condition d’un objet source. Il faut tester la répartition de cet écart par entité, statut, période et canal. Si l’ensemble de l’écart se concentre sur les clients inactifs, la cause est plus probable qu’une erreur d’arrondi.
Les scénarios métier complètent les comparaisons chiffrées. Ils vérifient qu’une commande annulée est traitée selon la même règle fonctionnelle, qu’un avoir est rattaché à la bonne période et qu’un changement de hiérarchie est visible dans le bon axe d’analyse. Les scénarios doivent être exécutés par les utilisateurs qui utilisent réellement les indicateurs, pas seulement par les équipes techniques.
Le modèle d’anomalie peut retenir trois statuts. Une anomalie bloquante interdit la bascule parce qu’elle affecte un indicateur de clôture ou un périmètre non maîtrisé. Une anomalie acceptée est documentée et signée parce que le nouveau modèle applique une règle volontairement différente. Une anomalie différée est planifiée avec une date, un responsable et un contournement explicite.
Le double run est pertinent pour les rapports qui alimentent des décisions répétitives. Pendant une ou deux périodes de référence, l’ancien et le nouveau socle sont exécutés avec les mêmes paramètres et les résultats sont comparés. Cette période ne doit pas être décorative. Elle doit comporter un calendrier, des responsables, une liste d’indicateurs et un seuil de décision.
Les flux doivent être contrôlés à la même heure. Comparer à 8 heures une cible chargée pendant la nuit à une source rafraîchie à 11 heures produit une anomalie artificielle. L’horodatage de la donnée fait partie du résultat. Il doit apparaître dans la feuille de recette et dans le rapport présenté aux décideurs.
La bascule devient défendable lorsque les écarts critiques sont soit corrigés, soit acceptés avec leur cause. Un total isolé ne constitue jamais une preuve suffisante.
Quels critères de bascule et de retour arrière inscrire dans le protocole de migration BI
La recette ne se termine pas quand les tests sont exécutés. Elle se termine quand les critères de bascule sont revus avec les responsables qui assument l’usage des chiffres. Un fichier d’anomalies fermé administrativement alors que la finance conteste encore un indicateur ne sécurise rien. Il reporte le conflit au premier cycle de production.
Les critères de bascule doivent être écrits avant migration. Ils peuvent prévoir l’absence d’anomalie bloquante, la validation des indicateurs critiques, la disponibilité des flux à l’heure attendue, la reprise des accès nécessaires et la conservation des exports de référence. Ils doivent également définir ce qui se passe si l’un de ces critères n’est pas atteint.
Prévoir le traitement des erreurs avant qu’elles ne deviennent urgentes
Le retour arrière n’implique pas toujours de remettre immédiatement l’ancien socle en service pour tous les utilisateurs. Selon le périmètre, il peut consister à maintenir un rapport source accessible, à prolonger un double run ou à restaurer une alimentation antérieure. Le choix dépend des contraintes d’exploitation et des dépendances entre les rapports.
Le protocole doit préciser qui décide d’un report, qui informe les utilisateurs, quel résultat fait foi pendant l’incident et comment les corrections seront retestées. Une anomalie sur un flux de nuit n’a pas le même traitement qu’un calcul erroné découvert dans un rapport de clôture. Dans les deux cas, l’absence de décision préécrite allonge le délai de réaction.
La communication aux métiers doit être concrète. Elle indique les rapports disponibles, ceux qui restent sur l’ancien outil pendant une période définie, les écarts connus et le canal de remontée des anomalies. Annoncer une transformation sans expliquer quel chiffre devient la référence nourrit la méfiance. Les utilisateurs ne demandent pas une formule générale ; ils demandent quel rapport utiliser lundi matin.
Pour une migration depuis SAP BW, la recette doit aussi isoler les divergences entre modèles et requêtes. Une requête BW peut inclure des variables, des restrictions et des formules qui ne se lisent pas directement dans le rapport consommé. Le sujet dépasse la reprise visuelle. Il porte sur la continuité du calcul et du chargement, comme le montre l’analyse consacrée à la migration de SAP BW vers BW/4HANA.
Une décision de bascule peut être formulée selon trois issues. La première autorise la mise en production, avec les anomalies acceptées consignées. La deuxième limite la bascule à une vague de rapports non critiques, le temps de corriger les indicateurs restants. La troisième reporte la bascule et maintient le socle source pour la période nécessaire. Cette dernière option doit rester possible. Forcer une date alors que les écarts ne sont pas expliqués ne résout pas un risque, elle le transfère aux utilisateurs.
Le protocole doit enfin prévoir un contrôle après la première exécution réelle. Les volumes de chargement, les temps d’actualisation, les erreurs de sécurité et les tickets utilisateurs doivent être observés pendant la période prévue. Une recette en environnement de test ne reproduit pas toujours les séquences de planification, les droits effectifs ou les volumes de production.
Avant d’autoriser la bascule, sortez la liste des indicateurs critiques et exigez pour chacun une valeur source, une valeur cible, un écart, une cause et une décision signée. Si une seule de ces colonnes manque, le processus de validation n’est pas terminé.
Quelle différence entre recette technique et recette métier dans une migration BI ?
La recette technique vérifie les chargements, les modèles, les droits et l’exécution des rapports. La recette métier vérifie que les règles de gestion, les indicateurs et les cas d’usage restent recevables pour les équipes qui prennent les décisions. Les deux validations sont nécessaires avant bascule.
Faut-il exiger zéro écart entre l’ancien et le nouveau socle décisionnel ?
Non. Certains écarts résultent d’arrondis, de changements de modèle, de périodes de chargement ou de corrections volontaires. Chaque différence doit toutefois être quantifiée, expliquée, rattachée à une règle et acceptée par le propriétaire métier concerné.
Combien de temps prévoir pour un double run ?
La durée dépend du cycle métier couvert. Pour un rapport de pilotage hebdomadaire, deux à quatre cycles peuvent suffire si les paramètres et les chargements sont comparés à heure fixe. Pour des indicateurs de clôture, le double run doit couvrir au moins un cycle représentatif de clôture.
Quels rapports tester en priorité après migration BI ?
Testez d’abord les rapports de clôture, de facturation, de stock, de marge et de pilotage de direction. Ajoutez les documents planifiés, les rapports alimentant d’autres processus et ceux dont les calculs sont localisés dans un univers, une requête ou un modèle sémantique.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
