Une migration de données se sécurise par un périmètre réduit, des règles de mapping traçables, des reprises répétées et une recette chiffrée. La bascule ne doit intervenir que lorsque les écarts sont expliqués, acceptés par les métiers et qu’un plan de reprise permet de revenir à la situation précédente.
En bref, les décisions qui déterminent réellement la tenue du chantier sont les suivantes.
- Le périmètre doit distinguer les données actives, les historiques à archiver et les objets décisionnels réellement consultés.
- Les règles de correspondance entre source et cible doivent être validées par domaine métier avant tout chargement complet.
- La sauvegarde des données ne remplace pas un plan de reprise documenté, testé et doté de critères de déclenchement.
- La validation post-migration porte sur les volumes, les montants, les filtres, les droits et les résultats des rapports critiques.
- Une bascule globale réduit la durée de coexistence, tandis qu’une migration progressive réduit l’exposition immédiate mais prolonge le double run.
Ce dossier s’adresse aux responsables BI, chefs de projet décisionnel et DSI qui reprennent un entrepôt, des flux ETL, des univers BusinessObjects ou des rapports vers une cible nouvelle. Il traite la migration de données dans un contexte décisionnel et ne couvre ni les clauses contractuelles, ni la protection des données personnelles, qui relève de votre DPO et de votre direction juridique.
Comment cadrer les étapes de migration avant de déplacer la première table
Les étapes de migration commencent par un inventaire exploitable, pas par l’ouverture d’un outil ETL. Un projet qui ne sait pas quelles sources il reprend, quelles règles y sont enfouies et quels utilisateurs consomment les résultats ne peut pas chiffrer sa charge. Le périmètre doit donc couvrir les tables, les flux, les modèles sémantiques, les univers, les rapports, les planifications et les droits.
Dans un socle SAP BusinessObjects, l’inventaire ne s’arrête pas au nombre de documents Web Intelligence. Il faut relever les univers utilisés, les classes, les objets, les conditions d’objet, les contextes de requête, les listes de valeurs et les publications. Un filtre de statut client posé dans une condition d’objet peut modifier un chiffre d’affaires sans être visible dans le rapport Webi. La lecture des versions et de leur support doit aussi précéder le calendrier de sortie. La page consacrée aux échéances de support SAP BusinessObjects permet de rattacher ce travail à la version réellement présente dans votre parc.
Réduire le périmètre sans effacer l’historique utile
La question utile n’est pas « peut-on reprendre toutes les données ? », mais « quelles données doivent encore être interrogées dans la cible ? ». Les historiques anciens peuvent rester accessibles dans un dispositif d’archivage, à condition que les équipes sachent où les consulter et que les règles de conservation soient traitées avec les profils compétents. Reprendre une décennie de mouvements peu utilisés augmente les volumes de chargement, les contrôles et les anomalies à expliquer.
Le tri doit se fonder sur les journaux d’usage quand ils existent, sur douze mois glissants au minimum. Il faut toutefois vérifier la rétention réelle des logs. Un audit limité à quatre-vingt-dix jours masquera les rapports trimestriels, annuels et certains tableaux réglementaires. Les statistiques techniques doivent être complétées par la validation des propriétaires métier, car un rapport peu ouvert peut servir à une clôture ou à un contrôle précis.
Un audit de migration sérieux classe chaque objet dans quatre catégories : à reprendre à l’identique fonctionnel, à reconstruire, à archiver ou à retirer. Cette décision doit être datée et attribuée. Sans propriétaire nommé, le rapport réapparaît souvent à quelques jours de la bascule, lorsque la recette est déjà engagée.
| Objet examiné | Preuve d’usage attendue | Décision de migration | Contrôle à prévoir |
|---|---|---|---|
| Rapport Webi opérationnel | Consultation récurrente et propriétaire métier identifié | Reprise ou reconstruction prioritaire | Réconciliation des mesures, filtres et exports |
| Univers BusinessObjects | Rapports actifs, objets utilisés et règles non visibles dans les documents | Analyse du modèle sémantique avant conversion | Comparaison des requêtes générées |
| Flux ETL planifié | Dépendances aval et journal d’exécution | Reprise si la source reste nécessaire | Volumes, rejets et durée de traitement |
| Historique dormant | Aucun usage confirmé sur la période d’audit | Archivage séparé ou retrait | Accès documentaire et conservation validée |
Le tableau repose sur une méthode de classement, non sur une date de fin de support. Les dates de maintenance doivent être relevées directement sur le portail SAP Support, consulté avant chaque comité de calendrier, car un décalage de maintenance modifie parfois l’urgence mais ne réduit pas le travail de recette.
Lorsque le parc compte moins de cent rapports et qu’une part importante n’est plus utilisée, la reconstruction mérite d’être chiffrée face à la reprise. Au-delà de trois cents rapports, avec des règles de gestion mal documentées dans les univers ou les ETL, la conservation contrôlée des règles existantes devient souvent moins risquée qu’une réécriture complète.
Quels risques de migration doivent être chiffrés avant la recette
Les risques de migration ne sont pas tous techniques. Un chargement peut se terminer sans erreur dans le journal ETL alors que les données produisent des résultats métier inexacts. Une jointure devenue interne au lieu d’externe, une clé client normalisée différemment ou une hiérarchie commerciale reconstruite à un niveau différent suffisent à déplacer des montants dans les tableaux de bord.
La gestion des risques commence par la distinction entre intégrité physique et intégrité décisionnelle. L’intégrité des données physique vérifie que les lignes attendues sont présentes, que les clés sont cohérentes et que les types sont valides. L’intégrité décisionnelle vérifie que les indicateurs conservent un sens accepté : le chiffre d’affaires, la marge, le stock ou l’encours doivent être comparés selon la même date d’arrêté, les mêmes populations et les mêmes exclusions.
Identifier la cause d’un écart plutôt que viser une identité fictive
La cible ne produira pas nécessairement les mêmes résultats que l’ancien socle. Cette différence n’est pas un échec en soi. Elle doit être isolée, quantifiée, expliquée et acceptée. Une variation de 0,4 % sur un chiffre d’affaires consolidé peut provenir d’un filtre de statut client appliqué dans un objet d’univers, d’un décalage de date comptable ou d’une règle de conversion de devise différente.
Le dossier de recette doit donc prévoir une tolérance par indicateur. Pour une mesure de contrôle financier, la tolérance peut être nulle sur un périmètre clos. Pour un indicateur opérationnel alimenté avec des données de dernière minute, une tolérance écrite peut être retenue si elle est validée par le métier. Le projet ne doit jamais présenter cette tolérance comme une absence de contrôle.
Les erreurs de mapping sont un risque majeur. Une colonne source « statut » peut recouvrir des valeurs inactif, suspendu, prospect ou supprimé, alors que la cible ne propose qu’actif et inactif. Le mapping doit documenter chaque valeur source, chaque valeur cible, chaque valeur exclue et la personne qui arbitre. Sans cela, l’ETL applique une règle technique à une décision métier non prise.
La sauvegarde des données doit être vérifiée avant chaque répétition générale et avant la bascule. Une sauvegarde existe seulement si la restauration a été testée dans un environnement séparé et si son contenu est lisible. Conserver un export inutilisable ou incomplet n’offre aucune continuité d’activité. Les droits d’accès, les planifications et les fichiers de configuration des flux font partie du périmètre à sauvegarder, pas uniquement les tables.
La sécurité des accès pendant le chantier doit être préparée avec les équipes compétentes. Le périmètre des comptes de service, des répertoires d’export et des accès aux environnements de recette doit être tracé. La question des données personnelles, de leur durée de conservation et de leur éventuel transfert relève de votre DPO ; l’analyse décisionnelle s’arrête ici aux contrôles de cohérence et aux habilitations techniques nécessaires aux chargements.
Un risque qui n’a ni propriétaire, ni critère de détection, ni action de correction n’est pas géré. Il est seulement listé. Le registre doit donc associer chaque anomalie à une date de revue, une décision et une preuve de correction avant que le chantier n’entre en phase de bascule.
Comment construire un plan de reprise utilisable le jour de la bascule
Le plan de reprise ne consiste pas à écrire « retour à l’ancien système » dans un document projet. Il définit qui décide, à quel moment, sur quelles mesures et comment les opérations reviennent à l’état antérieur. Il doit être testé lors d’une bascule à blanc, avec les mêmes dépendances, les mêmes volumes représentatifs et les mêmes équipes que lors du passage en production.
La première décision consiste à établir un point de non-retour. Avant ce point, le retour arrière peut s’appuyer sur une suspension des chargements et sur la restauration des données modifiées. Après le démarrage de la production dans la cible, le problème change : des transactions, corrections ou nouveaux fichiers peuvent exister dans les deux environnements. La reprise exige alors une procédure de resynchronisation ou une décision de gel, qui doit être arbitrée à l’avance.
Fixer des critères de déclenchement mesurables
Les critères doivent porter sur les contrôles qui rendent le système exploitable. Un taux de lignes rejetées, une absence de référentiel critique, une divergence d’encours non expliquée ou l’échec d’un rapport de pilotage de clôture sont des critères possibles. Leur seuil doit être écrit avant le week-end de bascule, non négocié au milieu d’un incident.
Un plan de reprise complet sépare les actions techniques des décisions métier. Les équipes techniques arrêtent les traitements, restaurent les composants concernés et conservent les journaux. Les référents métier confirment si les opérations doivent revenir dans la source, être saisies de nouveau ou être mises en attente. Cette séparation évite qu’un incident de chargement soit traité comme une décision comptable improvisée.
- Geler les alimentations source et horodater le dernier lot accepté.
- Vérifier la sauvegarde des données, les exports de configuration et la capacité de restauration.
- Charger les référentiels avant les mouvements afin de respecter les dépendances.
- Exécuter les contrôles bloquants sur les volumes, les clés et les indicateurs convenus.
- Déclencher le retour arrière si un seuil est franchi et consigner la décision.
Le choix entre bascule globale et migration progressive ne dépend pas d’une préférence d’outil. Une bascule globale limite la période durant laquelle deux socles coexistent, mais elle concentre l’exposition. Une approche progressive permet de circonscrire un incident à un domaine ou à une population, mais elle impose des règles de synchronisation pendant plus longtemps. Si un même indicateur est produit par deux modèles sémantiques pendant cette période, il faut indiquer clairement lequel fait foi.
Le plan doit nommer les rapports qui autorisent la poursuite des opérations. Il peut s’agir d’un tableau de suivi d’encours, d’un rapport de stock ou d’un état de facturation. La page relative à un protocole de migration BI et de réconciliation complète cette approche pour les contrôles entre ancien et nouveau socle.
Une bascule à blanc doit aller jusqu’à la décision de retour arrière. Tester uniquement le chargement valide la mécanique ETL ; tester l’arrêt, la restauration et le redémarrage valide la capacité réelle de reprise.
Comment estimer la charge de reprise sans masquer la recette
Un chiffrage de migration de données doit séparer l’inventaire, le nettoyage, les mappings, les développements ETL, les chargements de répétition, la recette, la formation et la bascule. Les fourchettes globales sans hypothèses servent rarement un comité de pilotage. Elles ne permettent pas de savoir si les jours annoncés couvrent les contrôles métier ou seulement la reprise technique.
Les ratios varient selon la qualité du parc. Un rapport qui affiche trois mesures sur une dimension stable ne demande pas la même analyse qu’un document Webi avec variables, ruptures, contextes d’univers et requêtes combinées. De même, un flux PowerCenter avec des recherches, des rejets et des tables de correspondance ne se transpose pas ligne à ligne dans une autre chaîne d’intégration.
Exemple de calcul borné pour un parc décisionnel
Voici une hypothèse de travail pour un parc de 240 rapports, utilisable pour préparer un budget mais à recalibrer après inventaire. Le périmètre comprend 144 rapports simples, 72 intermédiaires et 24 complexes. Les ratios retenus sont respectivement de 2 heures, 6 heures et 14 heures pour analyser, reprendre et documenter chaque rapport. Ces ratios sont des hypothèses de chiffrage projet, pas un tarif éditeur ni une promesse de délai.
Le calcul donne 288 heures pour les rapports simples, 432 heures pour les intermédiaires et 336 heures pour les complexes, soit 1 056 heures pour la reprise documentaire et fonctionnelle. En ajoutant 30 % pour les répétitions de chargement et les corrections de mapping, le sous-total atteint 1 373 heures. Une recette métier représentant 25 % de ce sous-total ajoute 343 heures. L’estimation bornée est donc de 1 716 heures, hors formation, reprise des habilitations, licence de la cible et remédiation d’une source indisponible.
Le chiffre n’a de valeur que si l’on teste son hypothèse la plus fragile. Ici, il s’agit du classement des 24 rapports complexes. Si la moitié utilise des objets calculés dans l’univers, des filtres dans les conditions d’objet ou des sources multiples, le ratio de 14 heures devient insuffisant. À l’inverse, si ces rapports sont retirés après validation métier, la charge descend avant même la construction de la cible.
| Catégorie de rapport | Volume retenu | Ratio de reprise | Charge calculée |
|---|---|---|---|
| Rapport simple | 144 | 2 heures par rapport | 288 heures |
| Rapport intermédiaire | 72 | 6 heures par rapport | 432 heures |
| Rapport complexe | 24 | 14 heures par rapport | 336 heures |
| Répétitions et corrections | Base de 1 056 heures | 30 % | 317 heures |
| Recette métier | Base de 1 373 heures | 25 % | 343 heures |
Le choix de reconstruire ou de reprendre doit aussi intégrer le coût des licences, mais sans mélanger deux décisions. La charge de chantier est une estimation en heures ; le coût des outils dépend de l’offre, de l’unité de facturation et des remises négociées. Pour un parc BusinessObjects vers une cible Microsoft, le détail des hypothèses figure dans cette analyse du coût de migration de BusinessObjects vers Power BI.
Lorsque le nettoyage des référentiels est repoussé en fin de programme, il absorbe la marge de recette. Il doit être budgété comme une activité distincte, assortie d’un taux de doublons, de valeurs invalides et de champs sans correspondance mesuré sur un échantillon représentatif.
Comment organiser la validation post-migration et le double run
La validation post-migration commence avant la bascule. Elle repose sur un jeu de contrôles préparé dans l’ancien socle, rejoué dans la cible et signé par les propriétaires métier. Attendre la production pour sélectionner les rapports de comparaison revient à transformer les utilisateurs en équipe de recette, au moment où l’activité dépend déjà du nouveau dispositif.
La première famille de contrôles porte sur les volumes. Le nombre de clients, de produits, de contrats, de lignes de vente ou d’écritures chargées doit être rapproché entre source et cible selon une date d’extraction identique. Cette comparaison détecte les exclusions involontaires, les doublons créés par une jointure ou les chargements partiels. Elle ne prouve pas encore que les indicateurs sont justes.
Comparer les chiffres avec un protocole qui résiste aux écarts
La deuxième famille porte sur les mesures. Chaque indicateur retenu doit préciser son périmètre, sa source, ses filtres, sa granularité et son arrondi. Un chiffre d’affaires mensuel peut être exact au total mais faux par canal si une clé de regroupement a été recodée. Les contrôles doivent donc descendre d’un total consolidé vers les dimensions qui expliquent les écarts : société, période, client, produit, commercial ou statut.
Le double run consiste à exécuter, pendant une période définie, les chaînes nécessaires dans l’ancien socle et dans la cible. Il n’a pas vocation à durer indéfiniment. Sa durée doit être cohérente avec les cycles métier. Un pilotage hebdomadaire peut demander plusieurs comparaisons hebdomadaires ; un état de clôture impose au moins un cycle complet de clôture avant la décision de retrait.
La documentation doit conserver les écarts acceptés. Un écart expliqué par une règle cible volontairement différente, par exemple l’exclusion de comptes inactifs ou l’usage d’une nouvelle hiérarchie, reste un écart. Il doit apparaître dans le dossier de décision avec son impact chiffré et le visa du responsable concerné. C’est la seule manière d’éviter qu’il soit redécouvert plusieurs mois après, sous la forme d’un « chiffre faux » sans historique.
Les droits font aussi partie de la validation post-migration. Un tableau exact, inaccessible à son destinataire ou ouvert à une population non autorisée, n’est pas recevable. La recette doit vérifier les groupes, les restrictions de lignes, les répertoires de publication et les planifications. Les notions de dimensions, de mesures et de modèles sémantiques doivent être relues avant de transposer les droits ; cette ressource sur le rôle des dimensions dans BusinessObjects aide à identifier les objets qui influencent les filtres et les périmètres.
Aucun environnement de production n’a été ouvert pour établir ces contrôles. La méthode décrite s’appuie sur la documentation publique des éditeurs et sur des pratiques de recette applicables aux socles décisionnels ; elle doit être adaptée à vos versions, à vos journaux d’audit et à vos règles de gestion documentées.
Avant d’autoriser le retrait de l’ancien socle, sortez les journaux d’usage sur douze mois, rejouez les indicateurs de clôture dans les deux environnements et faites signer les écarts acceptés. Le retrait devient alors une décision documentée, non une échéance subie.
Quelle différence existe entre migration de données et intégration de données ?
La migration est une opération de reprise vers une cible, avec une date de bascule et des contrôles de complétude. L’intégration organise des échanges continus entre applications. Un flux ETL peut servir aux deux usages, mais les critères de recette et de reprise ne sont pas les mêmes.
Faut-il reprendre tout l’historique dans le nouveau socle ?
Non. Les historiques sans usage démontré peuvent être archivés séparément, sous réserve des règles de conservation validées par les personnes compétentes. Le tri doit s’appuyer sur les logs, les cycles de consultation et la validation des propriétaires métier.
Quelle est la première vérification après un chargement ?
Le premier contrôle compare les volumes source et cible à une même date d’extraction : lignes, clés distinctes, rejets et enregistrements exclus. Il doit être suivi d’une réconciliation des mesures et des filtres des rapports critiques.
Quand déclencher le plan de reprise ?
Le déclenchement intervient lorsqu’un seuil bloquant prévu avant la bascule est franchi, par exemple une absence de référentiel critique, des rejets non corrigeables ou un écart financier non expliqué. La décision, son heure et les actions exécutées doivent être consignées.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
