S/4HANA n'est pas ECC avec un nouveau nom

Beaucoup d’équipes abordent le passage à S/4HANA comme une montée de version : même périmètre, même logique, un moteur plus rapide. C’est l’erreur de cadrage la plus coûteuse du projet. S/4HANA n’est pas ECC accéléré. C’est un modèle de données différent, et il ne tolère pas qu’on lui livre les données de l’ancien monde telles quelles.

On ne charge pas des données dans S/4HANA. On charge des données qualifiées pour S/4HANA.

Le schéma a changé là où on ne regarde pas

Les écrans se ressemblent. Les tables, non. Trois changements suffisent à faire dérailler une reprise mal préparée :

• MATDOC remplace MSEG et MKPF : les mouvements de stock ne vivent plus dans deux tables séparées mais dans un document matière unique. Les anciennes tables ne sont plus que des vues de compatibilité ;
• ACDOCA, le journal universel, fusionne la comptabilité générale, analytique et les écritures de coût qui étaient éclatées dans une dizaine de tables ;
• BSEG, contrairement à une idée répandue, ne disparaît pas. Il coexiste avec ACDOCA. Confondre les deux, c’est dupliquer ou perdre des écritures à la reprise.

Aucun de ces points n’apparaît dans une checklist fonctionnelle. Ils n’existent que dans la structure cible — et c’est précisément à la structure cible qu’il faut conformer les données avant de les charger.

Une donnée valide n’est pas une donnée qualifiée

Une donnée peut être parfaitement correcte dans ECC et inutilisable dans S/4HANA. Un mouvement de stock cohérent côté source peut violer une contrainte du document matière. Une écriture équilibrée dans l’ancien plan comptable peut ne pas se projeter proprement dans le journal universel.

La validité se constate dans le système d’origine. La qualification, elle, se mesure contre le modèle d’arrivée. Ce sont deux questions distinctes, et seule la seconde décide du Go-Live.

Qualifier, c’est un travail unitaire

Qualifier des données pour S/4HANA ne se fait pas en bloc, sur un export massif validé d’un coup. Cela se fait record par record, chacun confronté aux règles de la cible, chacun traçable.

C’est exactement la logique d’une architecture event-driven : chaque enregistrement est un événement traité individuellement, avec son verdict propre. Ce qui passe avance. Ce qui échoue part en file d’attente d’erreurs, est diagnostiqué, corrigé, rejoué — sans bloquer le reste du flux. À la fin, on ne livre pas un lot dont on espère qu’il tient. On livre des données dont chaque ligne a déjà été acceptée par le modèle cible.

La bascule cesse alors d’être un pari. Elle devient la confirmation de ce qui a déjà été prouvé, ligne par ligne.