Ce que font vraiment les consultants : un regard réaliste

Les consultants SAP configurent, développent, testent et stabilisent SAP pour une entreprise. Dans la pratique, l'essentiel de leur valeur se joue en cours de programme. Ils clarifient un périmètre qui a dérivé, organisent les démonstrations que personne n'avait organisées, trient les anomalies de la recette utilisateur (UAT) et stabilisent l'exploitation après le go-live. Les consultants fonctionnels s'occupent de la configuration des modules, les consultants techniques des extensions et des intégrations, et les consultants programme et conduite du changement de la livraison et de l'adoption. Cet article s'adresse aux dirigeants qui se demandent s'il faut faire appel à une aide extérieure, et à ceux qui envisagent le conseil comme métier. Si vous êtes dirigeant, le tableau des signaux plus bas vous dit quand appeler. Si vous êtes consultant, les sections sur le quotidien montrent ce que le métier recouvre vraiment.

La question revient chaque fois qu'on envisage un appui externe : que fait exactement un consultant que nous ne pouvons pas faire nous-mêmes ?

La réponse honnête n'est pas très flatteuse pour le secteur du conseil. L'essentiel de la valeur vient de la réparation de ce qui n'aurait pas dû casser. Des questions posées alors qu'elles auraient déjà dû l'être. Et de la capacité et de la clarté apportées au moment où l'équipe interne n'en a plus.

Ce n'est pas un reproche fait aux équipes internes. C'est ainsi que se déroulent la plupart des programmes SAP. L'équipe interne est sous tension. L'intégrateur a ses propres priorités. Les décisions s'accumulent et le périmètre dérive. Six mois après le début d'un programme de douze mois, quelqu'un ouvre le registre des points ouverts et y trouve vingt points marqués « à résoudre » qui y dorment depuis la semaine 3.

C'est généralement là que le téléphone sonne.

Certains consultants sont engagés pendant le blueprint ou la planification. Beaucoup reçoivent l'appel en cours de projet, souvent après deux ou trois mois de progression lente ou de passages de relais manqués. Les rapports du comité de pilotage virent à l'orange. L'équipe travaille dur. Ça avance lentement et personne ne sait dire précisément pourquoi.

1. ExploreAteliers et écartsAteliers fit-to-standard, écarts documentés
2. RealizeRéalisation et démonstrationsConfiguration et extensions. C'est en milieu de projet que tombent le plus souvent les appels de redressement
3. DeployTri des anomalies de recette et basculeÉcart de configuration, de processus ou de formation ? Le tri tranche
4. HypercareStabilisationLa première clôture mensuelle et la file des incidents

Les points d'entrée typiques :

1. Le périmètre a dérivé. Ce qui a été validé pendant Explore ne correspond plus à ce sur quoi travaille l'équipe de réalisation. Des exigences ont été ajoutées de façon informelle en atelier, le journal des changements n'a pas été tenu et personne ne dispose d'une liste de périmètre définitive.
2. Un chantier critique est à l'arrêt. La migration de données stagne depuis des semaines au même taux d'erreur, sans plan pour l'améliorer. La recette ouvre plus d'anomalies qu'elle n'en ferme.
3. La date de go-live est fixée et le plan ne la tient pas. Le conseil d'administration a fixé la date. Le plan n'a pas été rapproché de l'avancement réel. Le responsable de programme sait que la trajectoire manque la date, mais n'a pas encore fait remonter le sujet.

Dans chaque cas, le travail ne consiste pas à ajouter des personnes au plan existant. Il consiste à regarder ce qui se passe réellement, à nommer le problème sans détour et à produire une voie de sortie. Mon guide pour remettre les projets SAP sur les rails décrit cette séquence de redressement.

Clarification du périmètre et des processus

Parfois la configuration est bonne, mais le processus qui l'entoure est cassé. Cas fréquent : l'équipe a configuré d'après un document fit-to-standard issu d'Explore, et les utilisateurs métier n'ont pas revu la configuration depuis la validation. On leur a dit ce qui était construit, on ne le leur a pas montré.

Le correctif n'est pas technique. C'est un déficit de dialogue. Le travail consiste à présenter la configuration aux utilisateurs métier avant la recette et à produire une liste claire des modifications avant l'ouverture des tests.

Ce n'est pas glamour. C'est à quoi ressemble le travail.

Faire le lien entre équipes techniques et métiers

Les programmes SAP produisent régulièrement quelque chose de techniquement correct que le métier ne peut pas utiliser. Une détermination des prix qui fonctionne dans 90 % des cas et plante sur les commandes export. Un mouvement de marchandises qui se comptabilise correctement mais génère une pièce comptable que l'équipe de rapprochement ne reconnaît pas.

Le consultant fonctionnel comble cet écart. Pas en étant la personne la plus technique de la salle. En comprenant le comportement du système et l'impact métier suffisamment bien pour que les bonnes personnes prennent la bonne décision.

Accompagnement de la recette (UAT)

La recette utilisateur est le moment où les décisions accumulées d'un programme tiennent ou s'effondrent. Chaque raccourci pris pendant Explore, chaque ajout informel de périmètre et chaque cas de test rédigé de façon sommaire refait surface ici.

Bien accompagner la recette, c'est trier correctement les anomalies, en distinguant les écarts de configuration, les écarts de processus et les écarts de formation. C'est aussi savoir gérer la tension quand les utilisateurs métier enchaînent les échecs qui ébranlent leur confiance dans l'ensemble du programme. Sans cela, chaque anomalie d'une session de recette devient une raison de remettre en cause le go-live, le plus souvent parce que le tri était faible et que personne n'avait défini ce que « prêt pour le go-live » voulait dire.

Stabilisation après le go-live

Le travail le moins glamour du conseil SAP, c'est l'hypercare. Le go-live a eu lieu, les e-mails de félicitations sont partis, l'équipe de projet a commencé à se retirer. Puis arrive la première clôture mensuelle. Les écritures ne correspondent pas au format de rapprochement. Les ordres de fabrication se terminent mais ne sont pas décomptés. Le service d'assistance se remplit d'utilisateurs formés, mais pas préparés aux cas limites.

C'est là qu'une grande partie de la valeur réelle est créée, et là que la plupart des programmes manquent de ressources. L'équipe d'hypercare traite la file des incidents de façon systématique, distingue les problèmes systémiques des erreurs ponctuelles et reconstruit la confiance dans le système.

La structure du travail n'a pas changé. La répartition du temps, si.

La documentation se rédige presque toute seule. SAP Joule for Consultants, disponible de manière générale depuis 2025, répond aux questions de configuration à partir de la base de connaissances de SAP, notes SAP comprises, et explique le code ABAP. Les assistants fondés sur Joule dans SAP Cloud ALM rédigent des exigences et des cas de test à partir du matériel d'atelier. Le consultant fonctionnel passe moins de temps à rédiger des documents et plus de temps à remettre en cause les conclusions des ateliers.

Le code est davantage relu qu'écrit. Les assistants de développement de SAP rédigent du code, notamment SAP Build Code pour des extensions Java et JavaScript sur SAP BTP. Les consultants techniques le relisent, le sécurisent et le testent désormais.

Les équipes d'hypercare reçoivent moins de questions courantes. Joule peut répondre dans les applications SAP à des questions courantes comme les soldes de congés ou l'état d'une note de frais, ce qui retire un peu de volume au support d'hypercare. Le temps des consultants se déplace vers les écarts de processus, les problèmes de données de base et les cas qui exigent une personne.

L'intérêt de faire venir un consultant n'a pas changé. Ceux qui ont appris à utiliser ces outils consacrent plus de temps au jugement, à la communication et à l'escalade, et moins à un travail que l'IA rédige désormais de façon acceptable. La description que SAP donne elle-même de Joule for Consultants résume correctement ce qu'il couvre.

Les consultants fonctionnels se spécialisent dans des modules comme FI, CO, SD, MM, PP, EWM ou SuccessFactors. Ils configurent le système autour des processus métier et comblent l'écart entre le standard SAP et les exigences du client. Leur valeur tient à la profondeur sur un module et à la connaissance des processus métier.

Les consultants techniques (développeurs ABAP, spécialistes SAP BTP, architectes d'intégration, Basis) construisent les extensions et les intégrations que la configuration ne peut pas couvrir. Sur les programmes S/4HANA modernes, les principes du Clean Core poussent les nouvelles extensions vers SAP BTP ou vers des API publiées, ce qui demande des compétences différentes de la modification ABAP classique.

Les chefs de projet et directeurs de programme apportent la structure de livraison : gouvernance, risques, planning et résolution des problèmes, avec une vision sur l'ensemble du programme pour que les difficultés remontent avant de devenir des crises.

Les consultants en conduite du changement travaillent sur le volet humain : formation, communication, mobilisation et gouvernance qui décident si les utilisateurs adoptent le système ou le contournent.

La plupart des grands programmes SAP ont besoin des quatre. Dans les programmes des entreprises de taille intermédiaire, moins de personnes couvrent plusieurs rôles, et c'est là que se forment les trous. Les méthodes de conseil et les compétences qui comptent dans le conseil sont les mêmes pour les quatre. Si vous êtes consultant et cherchez votre propre trajectoire entre ces rôles, SAPopedia présente des parcours de carrière et des formations, et ERPCV vous aide à présenter cette expérience aux recruteurs.

L'erreur de conseil la plus coûteuse consiste à faire venir quelqu'un trop tard. Une revue des risques avant la bascule, quatre à six semaines avant le go-live, peut détecter des problèmes critiques quand il est encore temps. Une mission de redressement après une bascule ratée coûte bien plus cher. Elle se déroule aussi sous pression opérationnelle, dans une organisation qui a perdu confiance dans le système.

Le tableau montre les signaux et l'aide que chacun appelle.

Signal	Ce que cela signifie en général	L'aide à mobiliser	Ce qu'elle doit livrer en deux semaines
Points du registre ouverts depuis plus de quatre semaines, sans date de résolution	Un problème de gouvernance, pas un problème technique	Conseiller programme indépendant	Une liste de décisions avec responsables et dates
Go-live dans les 60 jours et aucune répétition de la bascule	Une bascule non testée ; les surprises au go-live ne se rattrapent pas en temps réel	Responsable de la bascule ou du programme	Un plan de bascule répété et des critères go/no-go
Les responsables métier ont cessé de venir	La recette échouera sans intervention délibérée	Un responsable de la conduite du changement et un responsable fonctionnel	Des démonstrations aux utilisateurs clés et un plan de remobilisation
Un chantier bloqué au même taux d'erreur depuis des semaines	La cause racine n'a pas été trouvée	Un spécialiste de ce chantier	Une analyse de cause racine et un plan de redressement
Le reporting de l'intégrateur est la seule vision de l'état du programme	Aucun contrôle indépendant	Un conseiller côté client	Un état de santé honnête du programme pour le sponsor

Que font vraiment les consultants SAP sur un projet ?

Ils analysent les exigences métier, configurent SAP pour y répondre et comblent l'écart entre les réglages par défaut de SAP et ce dont l'entreprise a besoin. Pendant Explore, ils animent les ateliers fit-to-standard et documentent les écarts. Pendant Realize, ils construisent la configuration et travaillent avec les développeurs sur les extensions. Pendant Deploy, ils accompagnent la recette, gèrent les anomalies et préparent la bascule. En hypercare, ils résolvent les problèmes d'après go-live. Ce qui manque dans les fiches de poste, c'est le tri des écarts entre les phases et le maintien de la discipline de livraison sous pression.

Quand une organisation a-t-elle réellement besoin d'un consultant ?

Trois situations couvrent la plupart des missions. Le redressement de programme, quand le périmètre a dérivé, qu'un chantier est à l'arrêt ou que la date de go-live est menacée. La compétence spécialisée, quand l'équipe manque d'une compétence de module ou technique, comme la configuration PP-PI ou l'intégration sur SAP BTP. Et la gouvernance, quand l'organisation veut une supervision indépendante d'un programme mené par un intégrateur. Attendre que la situation se dégrade avant d'appeler est le schéma le plus courant et le plus coûteux.

Quelle différence entre un consultant SAP fonctionnel et un consultant SAP technique ?

Les consultants fonctionnels configurent SAP pour soutenir les processus métier dans des modules comme FI/CO, SD, MM, PP ou EWM, et travaillent directement avec les utilisateurs métier sur les exigences. Les consultants techniques construisent ce que la configuration ne peut pas faire : extensions ABAP et BTP, intégrations et administration système via Basis. Les principes du Clean Core déplacent le travail technique des modifications ABAP dans le système vers des extensions BTP et des API publiées.

Comment savoir si un consultant apporte de la valeur ?

Trois indicateurs. Il fait remonter des hypothèses jamais vérifiées et des décisions repoussées, au lieu de confirmer les opinions en place. Des décisions bloquées depuis des semaines commencent à être prises. Et le registre des points ouverts raccourcit parce que les causes racines sont traitées, pas parce que des points sont clos sans résolution. Un registre qui garde la même longueur malgré l'activité signifie que les problèmes sont systémiques ou que les correctifs n'atteignent pas la cause.

Quelle est la partie la plus difficile du métier de consultant ?

Nommer les problèmes que le client connaît déjà mais sur lesquels il n'a pas agi : le périmètre qui a dérivé, les cas de test jamais rédigés, le sponsor qui a cessé de s'impliquer. Il faut assez de confiance pour être entendu, assez de crédibilité pour être cru et assez de franchise pour dire des choses désagréables. Les consultants qui préservent la relation au détriment du diagnostic vendent de l'acquiescement, et cher.

Pourquoi engager un consultant indépendant si le client a déjà un intégrateur ?

L'intégrateur est responsable de la livraison du périmètre contractuel. Un consultant indépendant est responsable devant le client du résultat. Ce sont deux métiers différents. Le conseiller côté client remet en question les hypothèses de conception et vérifie que la conception répond aux besoins métier. Il protège la position commerciale du client dans le contrôle des changements et donne à la direction une vision de l'état du programme qui n'est pas filtrée par le reporting de l'intégrateur. C'est un conflit d'intérêts structurel, pas une critique des intégrateurs.