Cette architecture qui façonne l’entreprise
Architecte d’entreprise SAP : un métier exigeant.
Dans les couloirs feutrés des directions informatiques, il y a un personnage qu’on sollicite pour un problème de fond.
Pas pour régler un bug, pas pour configurer un module, pas pour livrer un projet.
Pour répondre à la question que toute organisation complexe finit tôt ou tard par se poser, souvent dans la douleur : pourquoi nos systèmes d’information freinent-ils notre stratégie au lieu de la porter ?
Cette femme ou cet homme, c’est l’architecte d’entreprise SAP. Un titre qui dit peu à ceux qui n’ont jamais vécu de transformation informatique majeure et qui dit tout à ceux qui en ont traversé une.
Dans l’univers SAP qui fait tourner les flux de plus de 400 000 organisations dans 180 pays, l’architecture n’est pas qu’une affaire de technique. C’est aussi une affaire de stratégie.
Le cœur du réacteur
Pour comprendre ce que fait un architecte d’entreprise SAP, il faut d’abord comprendre ce qu’est SAP dans la vie d’une organisation. Ce n’est pas un outil parmi d’autres. C’est le système nerveux central.
Chaque commande client qui part, chaque facture fournisseur qui arrive, chaque pièce produite en usine, chaque embauche, chaque clôture comptable : tout transite d’une façon ou d’une autre par SAP.
Le qualifier de « cerveau » ou de « cœur » du système d’information n’est pas qu’une métaphore. C’est une réalité opérationnelle.
Cette centralité crée une responsabilité architecturale hors norme.
Une mauvaise décision dans l’architecture SAP d’un groupe industriel peut coûter des années de retard, des dizaines de millions d’euros et des nuits blanches à des milliers de collaborateurs.
Une bonne décision, prise au bon moment avec la bonne méthode, peut transformer la compétitivité d’une organisation pour les cinq à dix années suivantes.
C’est exactement l’espace dans lequel opère l’architecte d’entreprise SAP.
Ni technique, ni purement stratégique : un role singulier
Ce qui rend ce métier singulier, c’est l’étendue des compétences qu’il requiert simultanément.
L’architecte d’entreprise SAP doit être capable de parler stratégie avec un Directeur Général le lundi matin, de débattre de patterns d’intégration avec un développeur le mardi après-midi, de modéliser un processus Order-to-Cash avec un Directeur Supply Chain le mercredi et de présenter un business case chiffré à un Comex le jeudi.
Le tout en maintenant une cohérence globale que personne d’autre dans l’organisation n’a ni le temps ni la vision de tenir.
Il ne faut pas le confondre avec le consultant SAP fonctionnel qui se concentre principalement sur son module. Ni avec l’architecte technique dont le regard se pose essentiellement sur l’infrastructure. Ni avec le DSI, qui décide mais délègue la conception.
L’architecte d’entreprise SAP est celui qui fait le lien entre tous ces univers.
Il conçoit, il recommande, il arbitre, il documente et il pilote.
TOGAF, SAP EAF : la boîte à outils des bâtisseurs
Comme toute discipline, l’architecture d’entreprise SAP s’appuie sur des méthodes éprouvées.
La plus connue est le TOGAF (The Open Group Architecture Framework) utilisée par plus de 80 % des entreprises U.S qui pratiquent l’architecture d’entreprise.
TOGAF n’est pas un logiciel.
C’est un langage commun et une méthode structurée qui organise l’architecture en 4 couches indissociables :
- la couche métier, qui décrit les processus et la stratégie
- la couche données, qui gouverne la qualité et les flux d’information
- la couche applicative, qui cartographie les systèmes et leurs interactions
- la couche technologique, qui couvre l’infrastructure, le cloud et la sécurité.
La méthode en quelques mots
Sa méthode centrale, l’ADM (Architecture Development Method) est un cycle itératif en 9 phases qui guide l’architecte de la vision initiale jusqu’à la gouvernance du changement.
SAP a complété ce dispositif avec son propre cadre, le SAP EAF (Enterprise Architecture Framework) qui enrichit le TOGAF avec des outils spécifiques à SAP :
- La Business Capability Maps pour positionner rapidement quelles solutions SAP couvrent quels besoins
- Les Reference Architectures pré-construites par secteur pour éviter de repartir de zéro à chaque programme
- L’outil SAP Signavio pour modéliser et analyser les processus métier
- SAP LeanIX pour cartographier le portefeuille des applications et construire des roadmaps de transformation.
Un autre défi du métier est de maitriser tous ces outils.
Les cinq compétences qui font la différence
Quand on connait la complexité des programmes de transformation SAP, il me semble que les compétences techniques seules ne suffisent pas.
Un architecte d’entreprise SAP confirmé maîtrise en simultanée plusieurs domaines qui, pris séparément, définissent déjà des métiers entiers et c’est bien là la complexité du poste.
La connaissance fonctionnelle transverse
L’architecte ne doit pas être expert de chaque module SAP, mais il doit comprendre comment les grands processus end-to-end (Order-to-Cash, Procure-to-Pay, Plan-to-Produce, Record-to-Report, Hire-to-Retire) traversent plusieurs modules et plusieurs systèmes.
Maîtrise de la plateforme S/4HANA et SAP BTP
Comprendre la base de données in-memory HANA et ses implications de performance, l’interface Fiori, les services disponibles sur BTP. Pas pour coder mais pour challenger intelligemment ceux qui codent.
L’architecture d’intégration
Dans un paysage applicatif moderne, SAP ne vit pas seul. Il coexiste avec des systèmes MES, WMS, CRM, des plateformes e-commerce, des outils RH tiers. Connaître SAP Integration Suite, comprendre quand utiliser un IDoc et quand préférer une API REST est déjà une compétence à part entière.
La gouvernance des données
La qualité des données est le talon d’Achille de tous les programmes SAP. Articles, clients, fournisseurs : sans gouvernance structurée via SAP MDG, aucune architecture ne tient. L’architecte doit aussi savoir concevoir ce dispositif.
Des savoir-être importants
L’écoute active, la pédagogie, la capacité d’influence sans autorité hiérarchique (surement le plus difficile) : des qualités qui ne s’enseignent pas dans les formations TOGAF et qui font la différence sur le terrain.
2027 : l’horloge tourne
L’écosystème SAP vit aujourd’hui l’une des transformations les plus profondes de son histoire. SAP a annoncé la fin de la maintenance standard de son ERP historique (SAP ECC) qui équipe la majorité de ses clients depuis vingt ans pour 2027. Une maintenance étendue est disponible jusqu’en 2030. Mais le message est clair : il va falloir migrer vers S/4HANA.
Pour la plupart des grandes entreprises, cette migration est le programme informatique le plus complexe qu’elles auront jamais mené.
Des systèmes configurés et personnalisés pendant quinze ou vingt ans, des centaines de développements ABAP spécifiques (Z-Programs), des dizaines d’interfaces avec des systèmes tiers, des données de production accumulées pendant deux décennies : tout cela doit être analysé, décidé, migré ou abandonné. C’est un chantier de cathédrale.
Et l’architecte d’entreprise SAP en est le maître d’œuvre.
Un arbitrage majeur : la stratégie de migration
Le choix de la stratégie de migration est en lui-même un arbitrage majeur.
La voie Greenfield (repartir de zéro sur S/4HANA avec de nouveaux processus) offre le plus de bénéfices mais exige le plus de changement et de courage organisationnel.
La voie Brownfield (migration technique depuis ECC en conservant l’existant) est moins risquée à court terme mais ne tire pas pleinement parti des capacités du nouveau système et reporte la dette technique sans l’éliminer.
L’option Bluefield qui est une approche hybride et sélective, tente de combiner les avantages des deux.
Chaque choix engage l’organisation pour des années.
L’architecte d’entreprise SAP doit savoir évaluer en fonction des priorités business, métiers et IT de l’entreprise, quelle migration sera la plus à même de garantir la stabilité opérationnelle du système tout en ayant en tête les performances prioritaires attendues et effectives.
Sur les migrations, voir un de mes tous premiers articles Migrations SAP S/4HANA – Quelles stratégies ?
Le Clean Core : une révolution culturelle autant que technique
Parmi les grandes évolutions que l’architecte d’entreprise SAP doit aujourd’hui porter, le Clean Core mérite une attention particulière.
Ce principe de ne plus modifier le noyau SAP, ne plus développer en ABAP dans les objets standard, déporter toutes les extensions sur SAP BTP via des API stables, constitue un véritable changement de paradigme pour des organisations qui ont, pendant vingt ans, personnalisé leur ERP comme on personnalise une maison : en ajoutant des pièces, en modifiant les cloisons, jusqu’à rendre le tout complexe à rénover.
Des centaines, parfois des milliers de « programmes Z », ces développements ABAP spécifiques, dont chaque organisation a accumulé le catalogue au fil des années doivent être inventoriés, évalués, rationalisés.
Certains seront absorbés par le standard S/4HANA qui a évolué.
D’autres seront reconstruits en extensions BTP.
D’autres, enfin, seront abandonnés car ils ne correspondaient qu’à des habitudes de travail que personne n’avait jamais remises en question.
C’est un chantier archéologique autant qu’architectural.
Et la tâche est d’une complexité avérée.
Sur le sujet de la complexité, voir aussi l’article « comment gérer la complexité et les situations critiques sur les projets SAP ».
Cloud, IA et souveraineté : les nouveaux fronts
Les enjeux ne s’arrêtent pas à la migration. L’architecte d’entreprise SAP doit simultanément anticiper plusieurs révolutions en cours.
Le Cloud d’abord. Les organisations gèrent des paysages hybrides d’une grande complexité : un core ERP en cloud privé, une plateforme d’extension et d’intégration sur BTP, des systèmes tiers également dans le cloud.
Orchestrer ces environnements de façon cohérente, performante et sécurisée exige une vision architecturale que les outils seuls ne peuvent pas fournir.
L’intelligence artificielle ensuite. SAP Joule, l’assistant IA générative natif de SAP, commence peu à peu à s’intégrer dans les processus.
SAP Analytics Cloud enrichit ses capacités de planification prédictive. L’architecte doit anticiper comment ces nouvelles briques s’intègrent dans l’architecture globale sans créer de nouveaux silos ni de nouvelles dettes.
La souveraineté des données, enfin. Où les données sont-elles hébergées ? Qui y a accès ? Les contraintes RGPD, les exigences fiscales locales, les normes sectorielles : tout cela doit être intégré dès la conception architecturale, pas ajouté en correctif une fois que les problèmes surgissent. Car en matière d’architecture, ce qui n’est pas pensé au début coûte dix fois plus cher à corriger ensuite.
Un métier de l’ombre
Quand un groupe industriel consolide ses comptes en 48 heures au lieu de 7 jours, quand une entreprise intègre une acquisition en six mois au lieu de trois ans, quand un système d’information cesse d’être un frein pour devenir un accélérateur : derrière ces transformations silencieuses, il y a des centaines de personnes qui ont rendu tout cela possible.
Les équipes métiers qui ont accepté de revoir leurs processus de fond en comble.
Les développeurs et l’IT qui ont tenu des délais impossibles.
Les key users qui ont servi de cobaye pendant des mois de tests.
Les directions qui ont eu le courage de remettre en question des habitudes installées depuis quinze ans.
Les partenaires, les consultants et les managers qui ont tenu leurs engagements quand la pression était maximale.
Dans tout cela, l’Architecte d’Entreprise SAP joue un rôle précis : poser le cadre, maintenir la cohérence globale, anticiper les dérives, et s’assurer que les décisions d’aujourd’hui ne compromettent pas les possibilités de demain. Il est le gardien de la vision d’ensemble et doit avoir plusieurs casquettes ou oserai-je dire plusieurs bras (cf : photo d’illustration ci-dessous).
La meilleure architecture du monde ne vaut rien sans les femmes et les hommes qui acceptent de la faire vivre.
C’est peut-être ça, la définition la plus juste du métier : créer les conditions pour que les autres puissent réussir.
