🏢 SAP – Le Cœur de l'Entreprise

1.1 Vue d'ensemble (Principes ERP & Évolution)

Le Concept d'ERP (Enterprise Resource Planning)

Un ERP (ou PGI en français) est un système d'information qui centralise et intègre tous les processus métier d'une entreprise (finance, ventes, achats, production, RH...) au sein d'une **base de données unique**.

Avant l'ERP : Effet "Silo". La Compta a son logiciel, les Ventes un autre. Les données sont dupliquées, incohérentes et non-synchronisées.
Avec SAP : Intégration en temps réel. Une vente (module SD) génère instantanément une réservation de stock (module MM) et une écriture comptable (module FI). C'est le principe de la "Single Source of Truth" (Source Unique de Vérité).

L'Évolution des Architectures SAP

Comprendre SAP, c'est comprendre son évolution technique :

Version	Architecture	Caractéristique Clé
R/2 (1980s)	Mainframe	Architecture 1-Tier (Tout sur un seul serveur central, type IBM).
R/3 (1990s)	Client/Serveur (3-Tiers)	La révolution. Séparation : 1. Présentation (SAP GUI), 2. Application (Serveurs ABAP), 3. Base de Données (Oracle, DB2, etc.).
ECC 6.0 (2000s)	NetWeaver	"ERP Central Component". Le R/3 "moderne", bâti sur la plateforme NetWeaver. La BDD reste "classique" (Oracle, etc.). C'est encore la version la plus utilisée aujourd'hui.
S/4HANA (2015+)	HANA (In-Memory)	La nouvelle génération. "S" pour Suite, "4" pour 4ème gén. Ne tourne que sur la BDD HANA.

La Révolution S/4HANA

S/4HANA n'est pas une simple mise à jour, c'est une réécriture. Le changement majeur est la BDD HANA :

In-Memory : Les données sont en RAM (Mémoire Vive), pas sur disque. Accès quasi-instantané.
Stockage Colonne (Columnar Store) : Les données sont stockées par colonne, pas par ligne. Idéal pour l'analyse (agrégations ultra-rapides).
OLTP + OLAP en 1 : HANA peut gérer les transactions (OLTP) ET l'analyse (OLAP) en même temps.
- Avant : Il fallait extraire les données (ETL) de l'ERP (transactionnel) vers un "Data Warehouse" (analytique, ex: SAP BW) la nuit.
- Avec S/4 : L'analyse se fait en temps réel sur la donnée transactionnelle.
Nouveau Modèle de Données : La vitesse de HANA a permis de supprimer des centaines de tables.
- ACDOCA (Universal Journal) : La "Table de la Vérité" pour la Finance. Fusionne des dizaines d'anciennes tables FI et CO (BKPF, BSEG, COEP...).
- MATDOC : La nouvelle table unique pour les mouvements de stock (remplace MKPF, MSEG...).
UX Fiori : L'interface Fiori (web/mobile) devient le standard, remplaçant SAP GUI.

1.2 Modules Fonctionnels & Processus (O2C, P2P)

SAP est modulaire. Chaque module couvre un macro-processus métier. Les plus importants sont liés par des flux interdépendants (O2C et P2P).

FI – Financial Accounting (Comptabilité Financière)

Rôle : Comptabilité légale (externe). Gère le Bilan et le Compte de Résultat de l'entreprise pour l'État, les actionnaires, les banques.

Sous-Modules (Composants) :

FI-GL (General Ledger) : Comptabilité générale (le "grand livre" des comptes).
FI-AP (Accounts Payable) : Comptabilité fournisseurs (suivi des factures à payer).
FI-AR (Accounts Receivable) : Comptabilité clients (suivi des factures à recevoir).
FI-AA (Asset Accounting) : Comptabilité des immobilisations (gestion des amortissements, ex: PC, Bâtiments).
FI-BL (Bank Ledger) : Comptabilité bancaire.

Transactions clés : FB01 (Saisie pièce compta), FBL1N (Liste postes fournisseurs), FBL5N (Liste postes clients), F-28 (Encaissement client).

CO – Controlling (Contrôle de Gestion)

Rôle : Comptabilité analytique (interne). Gère l'analyse des coûts et de la rentabilité pour le management. "Où dépense-t-on l'argent ?" "Quel produit est le plus rentable ?"

Sous-Modules (Composants) :

CO-OM-CCA (Cost Center Accounting) : Comptabilité par centres de coûts (ex: "Combien coûte le département IT ?").
CO-OM-OPA (Order Processing Accounting) : Gestion des ordres internes (suivi des coûts d'un projet ponctuel, ex: "Coût du salon marketing 2024").
CO-PC (Product Costing) : Calcul du coût de revient des produits fabriqués.
CO-PA (Profitability Analysis) : Analyse de la rentabilité (par client, par produit, par région...).

Intégration (FI-CO) : Une facture FI (ex: électricité) est *automatiquement* affectée à un centre de coût CO (ex: Département IT). C'est le "pont" entre le légal et l'analytique.

SD – Sales and Distribution (Ventes)

Rôle : Gère l'intégralité du processus de vente, de la prise de commande à la facturation. C'est le cœur du flux "Order-to-Cash" (O2C).

Données de base (Master Data) :

Client (Customer Master) : XD01/XD02 (Qui est le client ? Où le livrer ? Qui paie ?).
Article (Material Master) : MM01/MM02 (Quel produit vend-on ?).
Conditions de Prix (Pricing) : VK11 (À quel prix ? Quelles remises ?).

Flux O2C (Order-to-Cash) :

Offre (Quotation) [VA21] : Proposition de prix au client.
Commande Client (Sales Order) [VA01] : Le client accepte. Le système vérifie le stock (intégration MM) et le crédit (intégration FI).
Livraison (Outbound Delivery) [VL01N] : Ordre de préparation au magasin.
Sortie Marchandise (Post Goods Issue) [VL02N] : Le stock sort (intégration MM) et le coût est comptabilisé (intégration FI/CO).
Facturation (Billing) [VF01] : Crée la facture. La créance est créée (intégration FI-AR).

MM – Materials Management (Achats & Stocks)

Rôle : Gère l'approvisionnement, la gestion des stocks et la vérification des factures fournisseurs. C'est le cœur du flux "Procure-to-Pay" (P2P).

Données de base (Master Data) :

Fournisseur (Vendor Master) : XK01/XK02 (Qui est le fournisseur ? Conditions de paiement ?).
Article (Material Master) : MM01/MM02 (Quel produit achète-t-on ? Unité de mesure ?).
Fiche Info-Achat : Lien Article-Fournisseur (prix d'achat négocié).

Flux P2P (Procure-to-Pay) :

Demande d'Achat (Purchase Req.) [ME51N] : Un besoin est identifié (ex: le stock est bas).
Commande d'Achat (Purchase Order) [ME21N] : Commande formelle envoyée au fournisseur.
Entrée Marchandise (Goods Receipt) [MIGO] : Réception physique des articles. Le stock augmente (intégration MM) et une dette d'attente est créée (intégration FI).
Vérification Facture (Invoice Verif.) [MIRO] : On reçoit la facture du fournisseur. Le système la compare à la commande (ME21N) et à la réception (MIGO) (c'est le " rapprochement à 3 voies"). Si OK, la dette est confirmée (intégration FI-AP).

Autres Modules Fonctionnels Clés

SAP couvre des dizaines d'autres secteurs :

PP (Production Planning) : Pour les industries. Gestion des ordres de fabrication, nomenclature (BOM), gammes, calcul des besoins (MRP).
QM (Quality Management) : Gestion de la qualité (contrôles à la réception, en production, avant livraison).
PM (Plant Maintenance) : Maintenance des équipements (ordres de maintenance préventive/curative).
HCM (Human Capital Management) : L'ancien module RH (paie, gestion admin...). Obsolescence : Il est aujourd'hui remplacé par la solution Cloud SAP SuccessFactors.
PS (Project System) : Gestion de projets complexes (structure WBS, budgets, planning).

2.1 Le Langage : ABAP (Advanced Business Application Programming)

ABAP est le langage propriétaire de SAP. Tout ce qui s'exécute côté serveur (logique métier) est écrit en ABAP. L'IDE principal est la transaction SE80 (Object Navigator) ou SE38 (éditeur simple).

Objets de Développement "Classic" (ECC)

Ces objets constituent 90% du code existant :

Data Dictionary (SE11) : La fondation. C'est ici qu'on définit les tables (ex: MARA, VBAK), les vues, les structures, les Éléments de Données (sémantique) et les Domaines (technique).
Rapports (SE38) : Programmes d'extraction et d'affichage de données.
- Rapports Classiques : Utilise l'instruction WRITE.
- ALV (SAP List Viewer) : Grilles de rapport interactives (tri, filtre, export Excel) via des modules fonctions (ex: REUSE_ALV_GRID_DISPLAY).
Module Pool (SE80) : Programmation transactionnelle (écrans). Utilise des "Dynpro" (Dynamic Programs) pour l'interface et des modules (PBO/PAI) pour la logique.
Modules Fonctions (SE37) : Fonctions réutilisables. Celles marquées "RFC" (Remote Function Call) peuvent être appelées depuis l'extérieur de SAP.
BAPI (Business API) : Des Modules Fonctions "standards" et stables pour manipuler les objets métier (ex: BAPI_SALESORDER_CREATE).
Interfaces :
- IDoc (ALE/EDI) : Format de données standard pour échanger des documents (ex: Cde Achat) avec d'autres systèmes.
- Batch Input (SHDB) : Simulation de saisie utilisateur pour charger des données en masse.

Enhancements (Le "Spécifique")

On ne modifie **JAMAIS** le code standard de SAP. Pour adapter le standard aux besoins du client, on utilise des "points d'extension" (Enhancements). Par convention, tout objet spécifique doit commencer par Z ou Y (ex: Z_MON_RAPPORT).

Du plus ancien au plus moderne :

User-Exits & Customer-Exits : (Obsolètes) "Trous" laissés par SAP dans le code standard où l'on peut insérer son propre code.
BAdI (Business Add-Ins) : L'approche moderne (Orientée Objet) des exits. Points d'ancrage définis par SAP où l'on peut "plugger" sa propre classe ABAP.
Enhancement Spots (Explicites/Implicites) : Le "Nouveau" BAdI. Permet d'ajouter du code à (presque) n'importe quel point d'un programme standard sans modifier l'original.

ABAP "Moderne" (sur S/4HANA)

Avec HANA, la philosophie change : "Code-to-Data" (ou "Code Pushdown"). On ne remonte plus des millions de lignes en ABAP pour les trier ; on pousse le calcul (l'agrégation, le tri) *vers* la base de données (HANA), qui est faite pour ça.

CDS Views (Core Data Services) : Le "nouveau SQL". C'est la façon moderne de lire les données. On définit des vues (dans Eclipse, pas SE11) qui sont exécutées nativement par HANA. Remplacent 90% des anciens rapports ALV.
AMDP (ABAP Managed Database Procedures) : Permet d'écrire du SQLScript (le langage de la BDD HANA) directement dans une méthode de classe ABAP. Pour les calculs très complexes.
Services OData (SEGW) : Pour exposer les données aux applications Fiori. Un développeur ABAP crée un "projet OData" (via SEGW) qui utilise souvent des CDS Views pour récupérer les données et les envoyer en JSON à l'interface Fiori.

IDE : Le développement ABAP moderne (CDS, AMDP, Fiori) se fait de plus en plus dans Eclipse (avec les "ABAP Development Tools - ADT") et non plus dans SAP GUI (SE80).

2.2 Interfaces (SAP GUI vs Fiori)

SAP GUI (L'Historique)

C'est l'interface "classique" (Rich Client) de SAP ECC, installée sur le poste client (saplogon.ini).

Philosophie : Basée sur les "Transactions" (T-Codes).
T-Codes : Raccourcis mnémoniques (ex: VA01, ME21N, FB01) qui lancent un programme ABAP (Dynpro). Un utilisateur "expert" navigue uniquement avec ces codes.
Ergonomie : Dense, puissante pour la saisie de masse (les "Key Users" l'adorent pour ça), mais peu intuitive, non-mobile et... disons, "datée".
Technologie : Programme C++/Java qui communique avec le serveur d'application via un protocole propriétaire (DIAG).

SAP Fiori (Le Moderne)

La nouvelle stratégie UX de SAP, obligatoire pour S/4HANA. C'est une collection d'applications web/mobiles.

Philosophie : Basée sur les "Rôles". L'utilisateur ne voit que les "Tuiles" (Tiles) correspondant à ses tâches.
Le Fiori Launchpad (FLP) : Le portail d'entrée qui regroupe les tuiles de l'utilisateur.
Design Principles : Role-Based, Responsive, Simple, Coherent, Delightful.
Types d'Apps Fiori :
- Transactional : Pour *faire* une action (ex: "Créer une Cde Achat", "Approuver une facture").
- Analytical : Pour *analyser* (ex: "KPI de Ventes", "Retards de Paiement").
- Factsheet : Pour *consulter* un objet (ex: "Fiche Client 360°").
Technologie (Stack) :
- SAPUI5 : Le framework JavaScript (HTML5) de SAP pour construire l'interface (le "frontend").
- OData : Le protocole (basé sur REST/JSON) pour communiquer avec le backend.
- SAP Gateway : Le composant serveur (côté ABAP) qui expose les données via OData (T-Code SEGW).

3.1 L'Architecture Technique (Basis, NetWeaver, TMS)

SAP Basis (L'Administration Système)

L'équipe "Basis" (ou "Admin NetWeaver") gère l'infrastructure SAP. Ils ne touchent ni au fonctionnel (SPRO) ni au code (ABAP), mais s'assurent que tout fonctionne, 24/7.

Tâches principales :

Installation & Upgrades : Installer SAP, la BDD HANA, appliquer les Support Packages (mises à jour).
Monitoring (SM50, ST22, SM21) : Surveiller les "Work Processes" (SM50), analyser les "Dumps" (plantages, ST22), et lire les logs système (SM21).
Gestion des Utilisateurs & Sécurité : Créer/gérer les utilisateurs (SU01) et assigner les Rôles/Autorisations (PFCG).
Gestion des Tâches Planifiées : Définir (SM36) et monitorer (SM37) les "Batch Jobs" (ex: paie de nuit, rapports...).
Performance : Tuning des buffers mémoires, optimisation de la BDD.

NetWeaver (Le Serveur d'Application)

NetWeaver est la plateforme technique, le "Serveur d'Application" (AS) qui fait tourner SAP. Il contient le "Kernel" (cœur) SAP. Une "Instance" NetWeaver (un serveur) est composée de :

Dispatcher : Le "contrôleur aérien". Il reçoit les requêtes (du SAP GUI ou Fiori) et les distribue à un "Work Process" disponible.
Work Processes (SM50) : Les "ouvriers" qui exécutent le code ABAP. Types principaux :
- DIA : Dialogue (pour les utilisateurs connectés).
- BTC : Batch (pour les jobs planifiés).
- UPD : Update (pour les écritures en BDD).
- SPO : Spool (pour les impressions).
- ENQ : Enqueue (gère les "verrous" pour qu'un utilisateur n'écrase pas les données d'un autre).

Paysage & Transports (TMS)

On ne modifie *jamais* la production. Un "Paysage" SAP standard a 3 environnements (serveurs) :

DEV : Développement (là où on code et on paramètre).
QAS (ou REC) : Qualité / Recette (là où le client et les Key-Users testent).
PRD : Production (là où l'entreprise travaille).

Le Transport Management System (TMS) est le processus pour déplacer les modifications :

Le développeur/fonctionnel sauvegarde son travail dans un Ordre de Transport (OT) en DEV (SE09/SE10).
Il "libère" l'OT.
Le "Basis" l'importe dans QAS via STMS pour les tests.
Si les tests sont OK, le Basis l'importe en PRD.

3.2 Les Métiers (Fonctionnel vs Technique)

L'écosystème SAP est très structuré. Les rôles sont clairement définis, principalement entre le "processus" (Fonctionnel) et le "code" (Technique).

Le Consultant Fonctionnel

Mantra : "Je comprends le métier."

C'est un expert des processus métier (ex: un ex-comptable devient consultant FI). Il fait le pont entre le besoin du client et la solution SAP.

Tâches :

Recueil du Besoin : Animer des ateliers (Blueprint).
Gap Analysis : "Ce que veut le client" vs "Ce que fait SAP en standard".
Paramétrage (Customizing) : Adapter SAP *sans coder*. Il utilise la transaction SPRO (le "menu de configuration").
Rédaction : Écrire les "Spécifications Fonctionnelles" (specs) pour les développeurs si le standard ne suffit pas.
Tests & Formation : Préparer les plans de test et former les utilisateurs finaux.

Le Consultant Technique

Mantra : "Je comprends le système."

Il existe deux types de "Techniques" :

1. Le Développeur (ABAP/Fiori) :

Il lit les "specs" du fonctionnel.
Il code les "spécifiques" (Z-Programs) en ABAP.
Il crée les rapports, les interfaces, les extensions (BAdI) et les apps Fiori (UI5/OData).

2. L'Administrateur (Basis) :

(Voir la carte 3.1) Il gère l'installation, la sécurité, la performance et les transports (TMS).
C'est l'expert de l'infrastructure NetWeaver et HANA.

L'Utilisateur (et Key-User)

Mantra : "Je travaille avec."

Utilisateur Final (End-User) : L'employé (comptable, commercial...) qui utilise SAP au quotidien pour ses tâches (ex: saisir une commande VA01).

Utilisateur Clé (Key-User) :

Un utilisateur final "expert" de son domaine.
Il est le référent métier pour les consultants lors d'un projet.
Il participe aux tests (Recette) et est souvent responsable de la formation de ses collègues.
C'est la première ligne de support avant de contacter l'IT.

🏢 SAP – Le Cœur de l'Entreprise

Vue d'ensemble (Principes)

Modules Fonctionnels (Piliers)

Le Langage : ABAP

Interfaces (SAP GUI vs Fiori)

Architecture Technique (Basis)

Les Métiers (Rôles)