Introduction : la fin d'une ère
Pendant vingt-cinq ans, développer sur SAP signifiait ecrire du Z dans SE80. On modifiait des user exits, on copiait des programmes standards pour les adapter, on ajoutait des includes dans des BAdI. Cette ère est en train de se refermer. SAP ne le dit pas brutalement, mais le message est clair : en 2026, le code custom pertinent est du code ABAP Cloud, pas du code Z classique.
J'accompagne depuis trois ans des equipes de développement ABAP dans leur transition vers ce nouveau modèle. Ce que je constate est fascinant : les développeurs qui embrassent ABAP Cloud deviennent bien plus productifs qu'auparavant, avec un code plus propre, plus testable et plus durable. Ceux qui resistent voient leur valeur de marche decroitre rapidement. Dans cet article, je vais detailler ce qu'est ABAP Cloud, ce qu'il apporte concrètement, et comment reussir la bascule sans jeter vingt ans d'expérience par la fenêtre.
Les trois tiers du modèle ABAP
Tier 1 : ABAP Cloud
C'est le modèle cible. Le code ABAP Cloud :
- S'écrit exclusivement dans ADT (ABAP Development Tools pour Eclipse)
- N'accede qu'a des APIs released par SAP
- Utilise les langages et frameworks modernes : RAP (RESTful Application Programming), CDS views, ABAP Managed Database Procédures
- Suit les règles syntaxiques les plus restrictives : pas de dynamic calls non contrôles, pas de FIELD-SYMBOLS sauvages, pas d'acces direct aux tables DB
ABAP Cloud est le seul modèle autorise sur S/4HANA Cloud Public Edition. Sur Private Cloud et On-Premise, il est le mode par defaut pour tout nouveau développement.
Tier 2 : Cloud API Enablement pour code classique
Ce tier concerné le code ABAP classique qui a besoin d'être enrichi pour devenir Cloud-ready. Ce n'est pas du pur ABAP Cloud, mais c'est un pas vers la conformité. Typiquement :
- On garde la logique métier en ABAP classique
- On encapsule les acces aux données derriere des APIs released
- On remplace les acces SELECT directs sur les tables SAP par des CDS views ou des BAPIs released
Ce tier est pertinent pour les systèmes S/4HANA Private Cloud Edition en phase de transition.
Tier 3 : ABAP Classic (le legacy)
Tout le code Z existant qui n'a pas encore ete assaini. Il continue de fonctionner mais n'evoluera plus vers le futur : pas d'acces aux nouvelles fonctionnalites Joule, pas de montee de version sans friction, pas de compatibilité garantie avec les prochains releases.
Comment cohabiter les trois tiers
Dans la pratique, un système S/4HANA Private Cloud heberge les trois tiers simultanement. L'architecture consiste a proteger les zones Tier 1 de toute contamination par les zones Tier 3. Le mécanisme technique est la software component, avec le Cloud Development Model actif sur les composants Tier 1.
Lors d'un projet pour un acteur de la defense, nous avons adopte la règle suivante : toute nouvelle software component créée en 2025 est en ABAP Cloud. Les composants legacy sont geles en Tier 3 et leur code évolué uniquement pour correction de bugs. Toute extension nouvelle passe par Tier 1 avec appels vers Tier 3 via des wrappers released.
Les APIs released, pierre angulaire du modèle
Qu'est-ce qu'une API released ?
Une API released est un objet (classe, interface, CDS view, BAPI, function module) que SAP garantit stable dans le temps. Le contrat est explicite : cet objet conserve sa signature, son comportement, sa disponibilite à travers les releases.
Tout objet NON released peut disparaitre, être modifie, changer de semantique à chaque mise à jour. Construire du code dessus, c'est construire sur du sable.
Comment trouver les APIs released
Trois sources :
- Dans ADT, la vue Project Explorer marque les objets released avec un tag spécifique
- La transaction SAP API Business Hub liste toutes les APIs released par domaine métier
- Le rapport ABAP_WHERE_USED_LIST avec le filtre C1 (contract: use system-internally) identifie les objets exposes
Pour un développeur ABAP classique, le reflexe est de SELECT sur VBAK, VBAP, BKPF. En ABAP Cloud, ces tables ne sont pas accessibles directement. A la place, on utilise les CDS views released correspondantes : I_SalesOrder, I_SalesOrderItem, I_JournalEntry.
Le shock culturel
La première fois qu'un développeur ABAP senior découvre qu'il ne peut plus faire SELECT * FROM MARA, c'est un choc. Sa reaction typique : "Comment je fais alors ?". Reponse : SELECT FROM I_Product WHERE Product = @iv_product INTO @DATA(ls_product). La CDS view I_Product est released, elle agrege proprement MARA, MAKT, MARC avec les bonnes conversions, et restera stable dans les prochains releases.
ADT Eclipse : l'environnement moderne
Pourquoi abandonner SE80
SE80 est une interface lourde, mono-serveur, sans vraie gestion de projet. ADT est un plugin Eclipse qui apporte :
- Navigation instantanee entre objets
- Refactoring automatisé (rename, extract method, etc.)
- Debugger graphique avance
- Integration avec abapGit pour le versioning
- Templates de code modernes
- Analyse ATC en temps reel pendant la saisie
Un développeur qui passe de SE80 à ADT gagne typiquement 30 à 40% de productivite après deux mois d'adaptation.
Les fonctionnalites clés
- Project Explorer : arborescence multi-systèmes, un développeur peut travailler simultanement sur DEV, QAS, PRD
- Quick Fix (Ctrl+1) : propose des corrections et refactorings
- Search (Ctrl+H) : recherche transversale sur tout le depot ABAP
- ABAP Doc : génération automatique de la documentation
- CDS Graphical Editor : visualisation des associations entre vues CDS
CI/CD avec abapGit et gCTS
abapGit : le pont vers Git
abapGit permet d'exporter les objets ABAP vers un depot Git standard (GitHub, GitLab, Azure DevOps). Cela change radicalement le workflow :
- Historique complet des modifications par développeur
- Pull requests et code reviews
- Branches pour les features en parallele
- Merge automatique des modifications non conflictuelles
Chez un gestionnaire de reseau electrique que j'accompagne, nous avons mis en place abapGit + GitLab avec des workflows de review obligatoires. Le taux de bugs en production a chute de 60% en six mois, simplement parce que chaque ligne de code est relue par un pair avant integration.
gCTS : le transport moderne
git-enabled Change and Transport System (gCTS) remplace progressivement le vieux système STMS. Les transports SAP sont relies a des commits Git, avec la même tracabilite. L'integration permet :
- Pipeline CI/CD declenche par push Git
- Tests unitaires automatiques à chaque commit
- Déploiement automatisé vers les systèmes cibles
- Rollback possible via Git revert
La configuration n'est pas triviale : il faut un runner CI, une connexion securisee aux systèmes ABAP, un mapping entre branches Git et systèmes SAP. Mais le retour sur investissement est substantiel : chez un acteur de la construction, le cycle DEV vers PRD est passe de 10 jours a 2 jours grâce à gCTS.
Les restrictions syntaxiques d'ABAP Cloud
Ce qui est interdit
- Dynamic SQL non contrôle : SELECT (dynamic_table) est interdit. Le développeur doit utiliser des techniques RTTI/RTTC en mode restreint.
- Modifications du repository : pas de CALL FUNCTION 'RS_TABLE_CREATE' dynamique
- Acces FS non types : FIELD-SYMBOLS genericites sont largement limites
- WRITE / WRITE-LIST : l'ancien mode de liste est interdit, il faut utiliser Fiori
- BDC, CALL TRANSACTION : interdits, il faut appeler les APIs released
Ce qui remplace
- RAP pour construire des applications transactionnelles complètes
- CDS views pour tous les acces en lecture
- Released BAPIs / classes pour les acces en ecriture
- Fiori Éléments pour les UIs standards
- SAPUI5 custom pour les UIs specialisees
- Eventing via Event Mesh pour les notifications asynchrones
Le test ATC integre
Le checkset SAP_CP_READINESS_REMOTE execute par ATC identifie automatiquement les violations. Dans ADT, il s'execute en temps reel et signale les non-conformités pendant la saisie. Un développeur debutant en ABAP Cloud recoit typiquement 50 à 100 alertes sur son premier programme, puis rapidement descend sous 10 après deux semaines de pratique.
La migration : feuille de route réaliste
Phase 1 : formation (2 mois)
- Formation théorique des développeurs seniors sur ABAP Cloud et RAP
- Mise en place de l'environnement ADT
- Création d'un projet pilote non-critique pour apprendre
- Revue croisee du code pilote par SAP ou un partenaire expert
Phase 2 : fondations (3 mois)
- Déploiement abapGit + gCTS dans le paysage DEV
- Configuration du pipeline CI avec tests automatisés
- Définition des conventions de nommage et de structuration
- Activation du Cloud Development Model sur les software components nouvelles
- Formation elargie des développeurs juniors
Phase 3 : productivite (6 à 12 mois)
- Tous les nouveaux développements en ABAP Cloud
- Migration progressive du code Tier 3 le plus consulte vers Tier 1
- Integration d'Integration Suite pour les flux asynchrones
- Mise en place d'un programme continu de reduction du code legacy
Phase 4 : excellence (12 mois et au-dela)
- Publication de bibliotheques partagees entre equipes
- Reutilisation des APIs Cloud entre projets
- Metriques de qualité code suivies trimestriellement
- Formation continue aux nouveautés (Joule, IA générative pour ABAP)
Comparaison de productivite : chiffres reels
Sur un projet d'extension de gestion fournisseurs chez un industriel, nous avons mesure la productivite sur deux equipes en parallele :
- Equipe A : 4 développeurs ABAP classique, SE80, STMS classique
- Equipe B : 4 développeurs ABAP Cloud, ADT, abapGit + gCTS
Sur un périmètre fonctionnel équivalent :
- Temps de développement : A = 120 j/h, B = 85 j/h
- Bugs en recette : A = 42, B = 14
- Bugs en production post Go-Live : A = 11, B = 3
- Temps de correction moyen : A = 4h, B = 1,5h
- Couverture tests unitaires : A = 12%, B = 78%
Le gain net après Go-Live est considérable. Et ces chiffres sous-estiment l'avantage long terme : le code de l'equipe B passera sans friction les trois prochaines montees de version, pas celui de l'equipe A.
Migration path pour le développeur ABAP classique
Ce qu'il faut desapprendre
Le développeur ABAP classique a des reflexes qu'il faut gommer :
- Le SELECT * sur les tables SAP
- Le WRITE / NEW-PAGE pour faire des listings
- Le CALL TRANSACTION pour chainer des programmes
- La modification directe des user exits
- L'include personnel ZGLOBAL que tout le monde touche
Ce qu'il faut apprendre
- Les constructeurs modernes : VALUE #( ), REDUCE, FILTER, COND, SWITCH
- Les expressions functionelles inline
- L'approche TDD avec ABAP Unit
- La modélisation par CDS views et BDEF
- L'architecture clean : separation données / logique / présentation
- Les patterns Git : branches, rebase, pull requests
La courbe d'apprentissage reelle
Dans les equipes que j'accompagne, la courbe typique est :
- Mois 1 : frustration, productivite divisee par 2
- Mois 2 : apprentissage, productivite revenue au niveau initial
- Mois 3 : declic, premiers gains visibles
- Mois 6 : productivite superieure de 30% au mode classique
- Mois 12 : autonomie complète, capacité a former d'autres développeurs
Le role du management est de proteger les equipes pendant les deux premiers mois. C'est un investissement. Ceux qui coupent la formation a mi-parcours detruisent leur equipe.
L'arrivee de Joule Developer
Joule Developer, assistant IA SAP integre a ADT, apporte en 2026 une dimension nouvelle :
- Génération de code CDS à partir de la description métier
- Suggestions de refactoring vers ABAP Cloud
- Detection des anti-patterns en temps reel
- Génération automatique de tests unitaires
- Traduction de code Tier 3 vers Tier 1 supervisee
Sur nos projets, Joule Developer accelere de 25 à 40% les tâches de conversion de code. Il ne remplace pas le développeur, mais il demultiplie sa capacité.
Conclusion : pas une option, une évolution
ABAP Cloud n'est pas la lubie d'un directeur produit SAP. C'est la trajectoire inevitable d'un écosystème qui doit rester competitif face aux plateformes cloud modernes. Les entreprises qui refusent cette transition se retrouveront, d'ici trois a quatre ans, avec un patrimoine de code impossible a faire évoluer, des développeurs en perte de compétitivité sur le marche, et des projets de migration brutaux et coûteux.
Mon conseil : commencez maintenant, pilote, a petite échelle, avec vos développeurs les plus curieux. Donnez-leur du temps. Mesurez les gains. Puis elargissez progressivement. Dans deux ans, vous aurez une equipe capable de tenir le rythme des innovations SAP. Ceux qui attendront le dernier moment subiront une transition forcee dans les pires conditions.
Le Z est mort, vive le Cloud ABAP.