Réussir son projet SAP en 2026 : ce que trente ans de terrain nous ont appris

On parle beaucoup de S/4HANA, d’IA générative, de SAP BTP. Les promesses fusent, les échéances aussi. Mais quand on demande à un consultant qui a passé près de trente ans sur le terrain ce qui fait vraiment réussir un projet SAP, la réponse est rassurante : l’essentiel n’a pas tant changé.

Nous avons longuement échangé avec Olivier, consultant SAP au profil double — développeur à l’origine, puis fonctionnel logistique — qui a travaillé dans la grande distribution, l’industrie, les utilities et de grandes organisations internationales. Voici ce qu’on en retient.

Commencer petit, mais solide

L’erreur la plus fréquente en démarrage de projet ? Mettre la barre trop haut. On veut tout traiter d’emblée, ou à l’inverse on se dit « commençons petit, on verra le reste plus tard »… et ce « plus tard » n’arrive jamais.

« Les bases doivent être posées par une équipe pas très large, mais très compétente. »

La leçon est simple : mieux vaut un noyau restreint et solide pour construire des fondations propres, plutôt qu’un démarrage en ordre dispersé qui se transforme en grand bazar.

Le standard d’abord, le spécifique quand il crée de la valeur

Depuis vingt ans, on répète qu’il faut privilégier le standard SAP. La bonne méthode tient en quelques questions, posées noir sur blanc dans un blueprint : voici le besoin, voici ce que propose le standard, peut-on s’y adapter ? Si non, quelle est l’alternative la plus rentable ?

Le travers le plus coûteux, c’est le réflexe « nous, c’est différent ». Presque tous les clients sont persuadés que leur métier ne rentre pas dans le standard. Résultat : des développements spécifiques en cascade, lourds à maintenir — parfois faute d’un regard fonctionnel pour filtrer les demandes, on développe au lieu de vérifier si ça existe déjà. C’est justement là qu’un consultant expérimenté fait la différence : poser la bonne question avant d’ouvrir le chantier.

« J’ai parfois du mal à comprendre pourquoi encoder une facture serait si différent d’une société à l’autre. C’est toujours la même chose. »

Or, neuf fois sur dix, le besoin est moins unique qu’on ne le croit. Le vrai spécifique — celui qui mérite un développement — est rare : c’est celui qui vous donne un avantage que vos concurrents n’ont pas. Le reste du temps, dix jours d’encodage manuel coûtent souvent moins cher qu’un développement sur mesure à maintenir pendant des années.

Avec S/4HANA — surtout dans sa version Cloud, hébergée — cette discipline du standard devient incontournable. C’est moins une contrainte qu’une chance : un système plus standard, c’est un système plus simple à faire évoluer.

Détecter tôt, agir vite

Tous les projets connaissent des turbulences. Ce qui distingue ceux qui s’en sortent, ce n’est pas l’absence de problèmes, c’est la vitesse de détection.

« Une fois qu’un gros paquebot part dans la mauvaise direction, on ne le corrige pas en deux ou trois jours. »

D’où l’importance de tirer la sonnette d’alarme avant que les dégâts ne deviennent irréversibles. C’est tout l’intérêt d’un regard extérieur lucide, capable de dire tôt ce que les équipes embarquées ne voient plus.

La conduite du changement se joue avec les gens

Sur un projet international réunissant deux équipes issues de cultures différentes après un rachat, la tension était vive entre utilisateurs. La solution n’est pas venue d’un outil, mais du temps passé ensemble, sur place, à travailler côte à côte.

« Les contacts se font naturellement, et le système finit par être accepté. »

La patience et la présence terrain restent les meilleurs antidotes à la résistance au changement. La bonne vieille rencontre, en somme.

SAP, un socle qui dure — et qui se transmet

Un des grands atouts de SAP, c’est la durée. Une solution de calcul de royalties déployée au début des années 2000 tournait encore quinze ans plus tard — mieux, elle avait été étendue à de nouveaux usages par le client lui-même.

Autre force : la portabilité des compétences. Si votre expert finance part, vous retrouverez un profil SAP partout dans le monde, capable de reprendre le flambeau rapidement. Avec une solution maison, le départ de l’unique sachant tourne vite au casse-tête. Un ERP solide, c’est aussi une assurance contre la dépendance à une seule personne.

L’IA, un accélérateur à apprivoiser

Joule, l’assistant génératif de SAP, s’appuie sur les données propres à l’éditeur et sur l’expérience accumulée chez ses clients — ce qui a marché, ce qui a échoué. Il peut esquisser un plan de projet, rédiger un premier jet, déblayer le terrain. Le réflexe juste : s’en servir pour gagner du temps, puis humaniser et adapter le résultat au contexte réel.

Côté développement, des approches comme RAP permettent de produire du code plus vite. Mais l’outil ne fait pas la méthode.

« Une société doit avoir une manière de travailler cohérente. On ne peut pas mélanger cinquante-six outils. »

La nouveauté n’est pas une valeur en soi. L’informatique n’a pas pour but d’être jolie : elle est là pour faire avancer les processus plus vite. C’est cette boussole — l’efficacité réelle, pas la mode — qui doit guider chaque choix d’outil.

Ce qu’on en retient chez Sapristic

Un projet SAP réussi, ce n’est pas celui qui coche toutes les nouveautés. C’est celui qui pose des fondations solides, qui assume le standard, qui détecte tôt, qui embarque les équipes et qui met la technologie au service du métier — pas l’inverse.

C’est exactement notre façon de travailler : traduire le besoin métier en solution qui tient dans la durée, sans vous vendre la dernière mode.

Un projet SAP en vue, une migration S/4HANA à cadrer, un développement à arbitrer ? Parlons-en.