Analytics Legends La plateforme de connaissance SAP Analytics
Guide

Conversion shell SAP BW — la voie qui oblige le parc à se justifier

À jour au 2026-08-14

Une conversion shell construit un système BW/4HANA vide, y reprend le modèle, puis recharge les données. C'est l'une des trois voies de conversion livrées par SAP avec l'in-place et la conversion remote, et c'est celle qu'on choisit quand le parc a besoin d'être élagué — parce qu'une coquille vide oblige quelqu'un à décider, objet par objet, ce qui mérite de faire le voyage.

Ce que fait réellement une conversion shell

La cible démarre vide. Le modèle — ce qui porte le sens analytique : InfoObjects, transformations, DTP, chaînes de processus et couche de requêtes — est repris dans le nouveau modèle d'objets, et les données sont rechargées ensuite plutôt que converties sur place.

Cet ordre est tout l'intérêt. Dans une conversion in-place, tout ce qui existe dans la source est dans le périmètre par défaut et doit être argumenté pour en sortir. Dans une conversion shell, rien n'y est par défaut et tout doit être argumenté pour y entrer.

L'écart entre les modèles d'objets fait de l'une comme de l'autre un exercice de modélisation : l'aDSO a absorbé ce que faisaient séparément les DSO standard, les DSO write-optimised et les InfoCubes. Moins de types d'objets à l'arrivée qu'au départ signifie des décisions par objet ; la coquille ne fait que les avancer dans le calendrier.

Quand elle bat l'in-place

Choisissez la coquille quand le parc a accumulé plus qu'il ne peut justifier : objets que personne n'interroge, hiérarchies construites pour une activité que l'entreprise n'exerce plus, transformations dont le propriétaire est parti. Reprendre tout cela n'est pas neutre : cela devient du coût sur la nouvelle plateforme, et la raison pour laquelle la transformation suivante coûtera cher elle aussi.

Choisissez l'in-place quand la continuité domine et que le parc est en état correct : identité du système et interfaces préservées, rien à re-décider.

Choisissez la conversion remote quand le système source ne peut pas être perturbé et qu'un paysage parallèle est finançable.

Le vrai test n'est pas technique : il consiste à savoir si quelqu'un accepte de dire à voix haute que tel rapport n'existera plus.

Le coût politique que personne ne chiffre

La conversion shell exige le plus de parrainage, parce que retirer du contenu est une décision politique et non technique. « Retirer » signifie que le rapport de quelqu'un disparaît, et un plan qui retire quatre cents rapports sans propriétaire métier nommé s'enlisera, quoi qu'en dise l'outillage.

Le signal à repérer est simple : une liste de retraits sans parrain associé. C'est le chemin critique du programme, posé sans propriétaire dans une annexe.

Le second poste non chiffré est l'historique. Chaque voie doit trancher ce que deviennent les années d'historique BW, et la coquille force cette question tôt — un avantage déguisé en obstacle. Traitée tardivement, elle dégrade calendrier et budget au dernier trimestre.

Ce qu'elle ne vous achète pas

Une coquille ne nettoie pas un modèle toute seule. Elle crée le moment où le nettoyage devient possible ; si personne ne s'en saisit, vous avez reconstruit le même parc sur une nouvelle plateforme, plus cher qu'une conversion in-place ne l'aurait facturé.

Elle ne supprime pas non plus le résidu : l'outillage porte une large part de toute conversion, ce qui reste est du jugement — logique personnalisée, hiérarchies inhabituelles, autorisations sur mesure — et c'est là que l'effort se concentre, quelle que soit la voie.

Enfin, elle ne tranche pas la destination. BW/4HANA est le successeur dans la lignée BW ; Datasphere et Business Data Cloud se situent à d'autres étages. Si le modèle d'exploitation visé est celui des produits de données cloud et que le parc est assez petit pour être reconstruit, la bonne conversation porte sur la cible, pas sur la voie de conversion.

Ce que nous ne pouvons pas affirmer

Nous ne publions pas de procédure outil par outil pour une conversion shell, ni la matrice indiquant quelle version d'outil supporte quelle version source : cela se règle dans la documentation de conversion de SAP pour la version concernée, et une procédure recopiée ailleurs est exactement le type de contenu qui se périme sans prévenir.

Questions fréquentes

Quelle différence entre conversion shell et in-place ?

L'in-place convertit un système BW existant sur place, objet par objet, avec tout dans le périmètre par défaut. La shell part d'un système vide, y reprend le modèle et recharge les données : rien n'est dans le périmètre tant que quelqu'un ne l'y a pas fait entrer.

La conversion shell est-elle plus lente ?

Elle démarre plus lentement et se termine souvent moins cher : le travail supprimé au départ n'est pas porté pendant toute la vie du système. La comparaison n'a de sens qu'au regard de la part du parc qui n'aurait pas dû voyager.

Conserve-t-on l'historique ?

Seulement ce que vous rechargez. C'est une décision explicite par jeu de données — archiver sur place, porter sélectivement, laisser froid — et la prendre tard fait déraper le dernier trimestre.

Qui doit porter la décision ?

Un parrain métier nommé, capable d'approuver les retraits, aux côtés de l'architecte. Sans lui, la voie n'est pas viable : tout son avantage repose sur des décisions que seul le métier peut prendre.

Sur quoi cette page s'appuie

À lire ensuite