Paramétrage SAP : info ou intox ? 10 affirmations à classer

Utiliser SAP et le configurer sont deux compétences distinctes. Le key-user maîtrise les transactions et les écrans utilisateurs. Le consultant maîtrise la logique sous-jacente, l’IMG, les tables de customizing, les dépendances entre paramètres. L’expérience métier est un atout précieux, mais elle ne dispense pas d’apprendre une nouvelle discipline.

Sur un projet réel, le paramétrage représente en moyenne moins de 5% du temps consultant. Le reste, c’est analyser le besoin métier, animer des ateliers, rédiger des spécifications, faire tester, documenter, accompagner le changement. Le clic dans SPRO est l’aboutissement, pas le cœur du métier.

Le paramétrage commence bien avant l’écran. Il commence par comprendre un besoin métier, identifier les règles de gestion à traduire, vérifier les impacts transverses. Quand on arrive devant la transaction de customizing, 80% du travail est déjà fait. L’écran n’est que la traduction technique d’une décision fonctionnelle.

C’est la méthode officielle SAP, particulièrement sur S/4HANA. On part d’un scope item Best Practice, on copie le standard dans la nouvelle structure organisationnelle, puis on ajuste seulement les écarts validés en atelier. Cette approche réduit les risques, accélère la mise en œuvre et facilite les futures montées de version.

Le développement spécifique est le dernier recours, pas le premier réflexe. Avant d’écrire une ligne d’ABAP, on cherche une option de paramétrage, une variante, un user exit standard, une configuration alternative. Chaque ligne de code spécifique pèse sur la maintenance, les migrations, et le coût total de possession du système.

Société, site, division, organisation commerciale, organisation d’achat : ces objets forment le socle sur lequel repose toute la configuration. Une structure mal posée, c’est un projet qui dérape pendant des mois. Avant de paramétrer un processus, on s’assure toujours que la structure organisationnelle est validée et stable.

SAP est un système intégré. Un paramètre logistique peut générer une écriture comptable. Un paramètre de facturation peut bloquer un flux de stock. Une règle de tarification peut impacter la marge analytique. Le bon réflexe consultant : avant de modifier un paramètre, identifier les impacts amont et aval, dans son module et au-delà.

Chaque paramètre traduit une règle de gestion métier. Une règle de blocage client, une stratégie de besoins, une condition de prix, un type de mouvement : ce sont des décisions métier avant d’être des cases à cocher dans SPRO. Un consultant qui paramètre sans comprendre le métier ne fait que recopier ce qu’on lui dicte.

Sans documentation, pas de traçabilité, pas de maintenance, pas de transfert de connaissance. Un projet court devient un cauchemar dès que le consultant qui l’a configuré quitte la mission. La fiche de paramétrage et le cahier de tests font partie intégrante du livrable, au même titre que le paramétrage lui-même.

Le paramétrage est réalisé dans l’environnement DEV, enregistré dans une requête de transport, puis transporté vers QAS pour validation, puis vers PRD une fois validé. Ce circuit DEV → QAS → PRD est une règle non négociable. Paramétrer directement en production, c’est s’exposer à des incidents non testés et à une perte totale de contrôle sur la traçabilité.