Clean core : ce qu’il faut vraiment gouverner.

Le principe tient en une phrase. Dans un système propre, le cœur reste conforme au standard de l’éditeur ; tout ce que l’entreprise y ajoute vit à côté, sur une plateforme d’extension prévue pour cela, derrière des interfaces documentées. SAP en a fait la doctrine officielle de SAP S/4HANA et de RISE with SAP, et on aurait tort de n’y voir qu’un argument de vente : la promesse de mises à jour régulières ne tient que si personne n’a soudé le cœur de l’intérieur. Mais la vraie raison de s’y intéresser n’est pas chez l’éditeur. Elle est dans vos comptes.

Chaque spécifique est une dette

Un développement spécifique naît toujours d’une bonne intention. Un processus qui coince, un état réglementaire que le standard ne sort pas tel quel, une demande du métier qu’on veut satisfaire vite : quelques jours de développement et le sujet est réglé. Au moment où on le code, un spécifique paraît presque gratuit. C’est après qu’il commence à coûter.

Il coûte à chaque montée de version : tout ce qui touche au cœur doit être analysé, adapté, retesté, et la facture se répète aussi longtemps que le code vit. Dans un monde RISE with SAP, où l’éditeur pousse ses mises à jour à son rythme, cette charge cesse d’être un événement tous les cinq ans pour devenir un péage récurrent. Il coûte en innovation : les capacités que SAP livre, l’IA embarquée au premier chef, s’appuient sur les processus et les structures de données standard ; un cœur truffé d’exceptions les regarde passer. Il coûte enfin en dépendance : au fil des années, la connaissance d’un spécifique se concentre dans deux ou trois têtes, et le jour où elles partent, l’entreprise découvre qu’elle ne sait plus expliquer son propre système. Sur un marché où les compétences SAP sont rares, ce dernier coût est le plus lourd.

Aucun de ces coûts ne figurait dans le chiffrage du développement initial. C’est toute la difficulté du sujet : la dépense est visible et modeste, la dette est invisible et longue. Une direction générale qui l’ignore la paiera quand même.

Le cas particulier de la localisation

Dans l’espace OHADA, une part du spécifique n’est pas un caprice métier. Les états financiers du SYSCOHADA révisé, la TVA et les déclarations propres à chaque État de l’UEMOA, les bulletins de paie et les cotisations sociales nationales : tout cela doit sortir du système, et le standard de l’éditeur ne couvre pas toujours chaque détail de chaque pays. Ces développements sont légitimes. La question n’est pas de les interdire, mais de décider où ils vivent.

Notre position est nette : la localisation se construit en extension, sur SAP BTP, avec des interfaces documentées, et non par des modifications dans le cœur. Un état SYSCOHADA développé à l’extérieur survit aux montées de version et se maintient par une équipe locale. Le même état codé au cœur du système devra être revalidé à chaque mise à jour, par les rares personnes qui le comprennent encore. La différence de coût sur dix ans est considérable, et elle se décide au premier jour.

Le test : un différenciant prouvé, sinon le standard

Faut-il pour autant proscrire tout spécifique hors localisation ? Non, et les partisans du tout-standard se trompent autant que les autres. Certains processus font gagner des clients, des marges ou des jours de trésorerie précisément parce qu’ils ne ressemblent pas à ceux du voisin. Ceux-là méritent d’être défendus, développés proprement à l’extérieur du cœur, et entretenus comme des actifs.

Tout est dans le critère. Le nôtre est simple à énoncer et inconfortable à appliquer : un spécifique se justifie s’il est imposé par la réglementation, ou si le processus qu’il porte est un différenciant métier démontrable. Démontrable, pas ressenti : qui peut dire ce que l’entreprise perdrait, concrètement, en passant au standard ? Si personne ne sait répondre, la réponse est le standard, et c’est le processus qui s’adapte. Notre expérience des inventaires de spécifiques est constante sur ce point : la grande majorité échoue au test. Ils reproduisent une habitude, rarement un avantage.

La bonne question n’est pas « que fait ce spécifique ? » mais « que vaudrait l’entreprise sans lui ? ». Si la réponse est « pareil », il n’a rien à faire dans le cœur.

Ce que la discipline exige de la gouvernance

Un critère ne suffit pas ; encore faut-il quelqu’un pour le tenir. C’est ici que le sujet quitte la sphère technique, parce que tenir un critère, c’est dire non. Non à un directeur métier pressé, non à un projet qui a déjà promis, non à la solution de facilité qui rouvrirait le cœur. Une autorité d’architecture qui ne peut pas s’appuyer sur la direction générale cédera. Poliment, et systématiquement.

La gouvernance qui fonctionne repose sur trois pratiques. Une instance de décision où le métier vient plaider sa demande, avec le test du différenciant comme règle du jeu affichée d’avance. Un registre des dérogations, ensuite : chaque spécifique accepté y est inscrit avec son propriétaire, sa justification, son emplacement (cœur ou extension) et sa date de revue, parce qu’une dette se gère mal quand on n’en tient pas la comptabilité. Une revue à chaque montée de version, enfin : un spécifique doit regagner sa place à chaque échéance, sinon il sort. Sans ce rendez-vous, la dérive revient en quelques années, par accumulation de petites exceptions toutes raisonnables une à une.

2027, la purge qui ne repassera pas

Reste le calendrier. La fin de la maintenance standard d’ECC, fixée à fin 2027 avec une extension possible jusqu’à fin 2030, impose à chaque entreprise un passage vers SAP S/4HANA. Or une conversion est le seul moment où purger coûte moins cher que conserver : il faut de toute façon inventorier, analyser et retester chaque développement. Trier à cette occasion est un effort marginal ; tout embarquer, c’est convertir sa dette en même temps que son système, et la rembourser pendant dix ans de plus.

C’est pourquoi nous plaidons pour que la doctrine du spécifique soit fixée dès le cadrage, avant le choix du scénario et de l’intégrateur, plutôt que découverte en cours de programme quand chaque arbitrage retarde un jalon. L’entreprise qui arrive en négociation avec sa règle du jeu, son registre et sa liste de purge choisit son programme. L’autre le subit.

Pour prolonger : notre lecture de l’échéance 2027 pour les entreprises de la sous-région, notre offre SAP · S/4HANA & ERP et nos applications sur mesure, où les extensions se conçoivent et se construisent.