Clean core : pourquoi la discipline d’architecture est devenue un sujet de direction générale.

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 des plateformes d’extension prévues pour cela, derrière des interfaces documentées. SAP en a fait la doctrine officielle de S/4HANA et de RISE, 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 écran mal fichu, 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, 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.

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 test : un différenciant prouvé, sinon le standard

Faut-il pour autant interdire le spécifique ? Non, et les intégristes 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 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 définitivement 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, que nous retrouvons chez tous ceux qui durent. 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 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, et c’est lui qui donne au sujet son urgence. La fin de la maintenance mainstream d’ECC, fixée à fin 2027 avec une extension possible jusqu’en 2030, impose à chaque entreprise un passage vers 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. L’occasion ne se représentera pas au tarif de 2027.

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, notre offre S/4HANA et notre approche de la transformation SAP, où cette discipline se décide et s’outille.