Un utilisateur t’appelle : « ca ne marche plus ». Voici comment corriger un bug SAP en mission sans paniquer, avec une methode qui rassure le client.
L’essentiel
- Un bug SAP est rarement un « bug » : c’est souvent un parametrage, une donnee ou un droit manquant.
- La bonne demarche commence par reproduire le probleme, pas par ouvrir le code.
- Le consultant fonctionnel a des outils simples pour investiguer : SU53, ST22, SLG1, le mode debug.
- Corriger vite compte moins que corriger sans casser le reste du flux.
Un bug SAP, c’est quoi vraiment en mission
Sur le terrain, un utilisateur qui dit « il y a un bug » veut dire une chose : le systeme ne fait pas ce qu’il attend. Dans la majorite des cas, ce n’est pas un defaut du logiciel SAP. C’est un ecart entre un besoin et une configuration. Le vrai bug technique, celui qui vient d’un programme mal ecrit, existe, mais il est minoritaire.
Un consultant fonctionnel range mentalement les causes en quatre familles. Un probleme de parametrage (le customizing ne couvre pas le cas). Un probleme de donnee (une fiche article ou un compte mal renseigne). Un probleme d’autorisation (l’utilisateur n’a pas le droit). Et enfin un vrai defaut de developpement specifique. Nommer la bonne famille des le depart fait gagner un temps enorme.
La methode pour isoler l’origine du probleme
La premiere erreur est de vouloir corriger avant d’avoir compris. La bonne demarche est l’inverse. Tu reproduis d’abord le probleme toi-meme, avec le meme utilisateur, la meme transaction et les memes donnees. Un bug que tu ne sais pas reproduire est un bug que tu ne sais pas corriger.
Ensuite tu isoles. Tu changes une seule variable a la fois : un autre utilisateur, une autre societe, une autre date. Si le probleme disparait avec un profil administrateur, c’est un droit. S’il disparait sur une autre fiche, c’est une donnee. Cette logique de dichotomie, empruntee au depannage classique, evite de tourner en rond.
Les outils SAP pour investiguer un bug
Le consultant fonctionnel dispose d’une boite a outils standard, sans savoir coder en profondeur.
- SU53 : affiche le dernier controle d’autorisation echoue. Le premier reflexe quand un utilisateur est bloque.
- ST22 : le journal des dumps, ces erreurs techniques qui stoppent net une transaction (ABAP runtime error).
- SLG1 : le journal applicatif, qui recueille les messages d’erreur fonctionnels de nombreux processus.
- Le mode debug (/h) : pour suivre pas a pas ce que fait le programme et voir ou la valeur derape.
Réflexe consultant
Double-clique sur le message d’erreur affiche a l’ecran. SAP donne son numero et sa classe de message. Avec ces deux informations, tu retrouves la source exacte du controle dans le code, sans deviner.
Corriger sans casser le reste du flux
Une fois la cause trouvee, la tentation est de corriger tout de suite en production. C’est le piege. Une modification de customizing part d’un environnement de developpement, passe par un ordre de transport, se teste en recette, puis remonte en production. Ce circuit protege le systeme des effets de bord.
Avant de valider, pose-toi une question simple : qu’est-ce que ce changement touche d’autre. Un parametre partage entre plusieurs societes ou plusieurs flux peut regler ton cas et en casser trois autres. Le bon consultant corrige le probleme sans en creer de nouveaux.
À éviter en mission
Corriger directement en production « pour aller vite ». Meme sous pression, tu documentes la cause, tu passes par le transport et tu fais valider. Un raccourci non trace est un risque que tu portes seul si le flux casse.
Vu en mission
Un flux bloque en urgence, tout le monde suspecte un defaut du programme. Apres investigation, la cause tient a une fiche article incomplete cree la veille. Le reflexe de reproduire et d’isoler a evite des heures perdues a chercher dans le code.
Ta demarche en 5 etapes face a un bug
- Ecoute et note le contexte exact : quel utilisateur, quelle transaction, quel message.
- Reproduis le probleme toi-meme, sinon tu ne pourras pas le valider corrige.
- Isole la cause en changeant une variable a la fois : droit, donnee ou parametrage.
- Confirme avec le bon outil : SU53, ST22, SLG1 ou le debug.
- Corrige dans le bon environnement, teste en recette, puis fais valider avant la production.
Tu veux gagner en autonomie sur le terrain ?
Savoir investiguer un incident sans dependre d’un developpeur est une competence qui rassure les clients. C’est exactement ce que l’on travaille dans le programme AZ Premium.
La video ci-dessous te montre, en situation, comment un consultant aborde la correction d’un bug SAP en mission.