La plupart des consultants SAP traitent la spécification fonctionnelle comme une corvée administrative à expédier avant d’attaquer le vrai travail. Erreur de jeune. Une FS bien écrite décide à elle seule si le développement tient en deux sprints ou si l’équipe ABAP va vous renvoyer le delivery six fois pour clarification.
Ce guide cible les consultants SAP fonctionnels, les chefs de projet et les juniors qui doivent rédiger, instruire ou auditer une FS sur un projet S/4HANA ou ECC. J’écris à partir des projets EAM et PP que je vois sur le terrain, à voir des FS qui tiennent et des FS qui partent en vrille. Je ne vais pas vous donner un template magique : je vais vous montrer comment structurer chaque catégorie WRICEF différemment, comment gérer la signature client, et les sept pièges qui font dériver une spec en delivery.
Pourquoi une FS bâclée se fait réécrire trois fois en cours de projet
Le Standish Group, dans son Chaos Report, place régulièrement le critère clear statement of requirements dans les trois premiers facteurs de réussite d’un projet IT, à côté de l’implication utilisateur et du soutien exécutif. Ce n’est pas une révélation pour qui a fait deux projets SAP. Une FS floue génère mécaniquement des retours BUILD, des recettes ratées et des change requests qui plombent le planning. À budget fixe, c’est la marge du projet qui paie.
Concrètement, voici à quoi ressemble une FS qui va dériver. Les règles de gestion sont décrites au présent vague : “le système vérifie la disponibilité”. Vérifie comment, dans quel contexte, sur quel statut ? Le développeur va trancher arbitrairement, la recette va découvrir l’écart trois mois plus tard, le change request va arriver en pleine UAT. Multiplié par quarante objets WRICEF sur un déploiement S/4HANA standard, ça devient un mur.
L’autre symptôme classique : la FS qui parle solution avant problème. Vous y trouvez des références à des BAPI précis, des programmes Z*, des transactions custom, alors que le besoin métier sous-jacent n’est même pas décrit. Le développeur reçoit une implémentation déguisée en spécification. Quand il découvre que le besoin réel pouvait être servi par du standard, c’est trop tard, le scope est figé.
Pas de FS sans au moins trois critères d’acceptation testables. Si je ne peux pas écrire “le test passe quand X égal Y et Z est dans tel statut”, je n’ai pas spécifié, j’ai décrit une intention. Et une intention ne valide pas une UAT.
FS, TS, SFG, SFD : remettre les définitions au clair avant d’écrire
Le vocabulaire flotte beaucoup entre projets, et la confusion entre FS, TS, SFG et SFD est un classique. Reprenons proprement, parce que la définition que vous adoptez dicte qui rédige, qui signe, et qui porte la responsabilité du livrable.
FS versus TS : la frontière fonctionnel ou technique
La spécification fonctionnelle décrit le QUOI. Quel processus métier, quelles règles de gestion, quel comportement attendu côté utilisateur. Elle est écrite dans la langue du métier, pas dans la langue ABAP. La spécification technique décrit le COMMENT. Quels objets SAP standard sont utilisés, quels enhancements points, quelle structure de code, quelle table contient la persistance. Elle est écrite pour le développeur par le développeur, ou par un consultant technico-fonctionnel senior.
Spécification fonctionnelle (FS)
- Décrit le besoin métier : pourquoi on fait, pour qui, dans quel processus
- Écrite par le consultant fonctionnel, validée par le key user
- Contient règles de gestion, exceptions, cas limites, critères d’acceptation
- Signée par le sponsor client avant build
- Lisible par un non-développeur, pas de pseudo-code, pas de noms de table sauf annexe
- Sert de référentiel pour la recette UAT
Spécification technique (TS)
- Décrit l’implémentation : quels objets SAP, quels enhancements, quelle structure de code
- Écrite par le développeur ABAP ou le technico-fonctionnel senior
- Contient diagrammes de classes, signatures de BAPI, BAdI choisis, tables impactées
- Validée par le tech lead ou l’architecte solution
- Référence la FS sur chaque section pour traçabilité
- Sert de référentiel pour la revue de code et les tests unitaires
SFG versus SFD : quand chacune est pertinente
La SFG, spécification fonctionnelle générale, donne la vue d’ensemble. Elle décrit le processus métier de bout en bout, les acteurs, les interfaces principales, sans rentrer dans le détail de chaque écran. On la rédige en début de phase Explore, elle sert de base au business case et au cadrage budgétaire. La SFD, spécification fonctionnelle détaillée, zoome sur chaque objet à développer ou à customiser, avec toutes les règles de gestion, les exceptions, les maquettes. On la rédige en début de phase Realize, par objet WRICEF.
Sur un projet bien dimensionné, vous avez une SFG par macro-processus (par exemple Achats indirects, Maintenance préventive, Sales order to invoice) et une SFD par objet WRICEF (par exemple Rapport tableau de bord MTBF, Interface IDoc INVOIC sortante vers OMS, BAdI custom sur détermination de centre de coût). Beaucoup de projets sautent l’étape SFG et attaquent directement les SFD. C’est une économie de court terme qui coûte cher : sans vue d’ensemble, les SFD se contredisent, les processus se chevauchent, et personne ne détecte les redondances avant la recette intégrée.
Qui rédige, qui relit, qui signe
La FS est rédigée par le consultant fonctionnel après atelier avec le key user. Le key user valide les règles de gestion sur le fond métier. Le développeur ABAP relit la faisabilité technique avant signature et flag toute zone d’ambiguïté. Le chef de projet relit pour l’impact planning et les dépendances inter-objets. Le sponsor client signe pour figer le périmètre. Sans signature, la FS reste un draft, et tout changement est libre. Avec signature, tout changement passe par un change request formalisé.
WRICEF : 6 catégories, 6 structures de FS différentes
WRICEF, c’est l’inventaire des choses que SAP standard ne sait pas faire pour vous. Workflows, Reports, Interfaces, Conversions, Enhancements, Forms. Chaque catégorie a sa logique de spec : une FS d’Interface IDoc n’a rien à voir avec une FS de Report ALV. Le piège typique est d’utiliser un seul template générique pour les six. Vous finissez avec des sections vides ou hors sujet, et vous oubliez les sections vraiment critiques pour chaque catégorie.
W comme Workflows : événements déclencheurs, branches, escalades
Une FS de Workflow décrit obligatoirement : l’événement déclencheur (création d’un OF, dépassement d’un seuil de stock, validation d’une commande), les acteurs et leurs rôles, l’arbre de décision branche par branche, les délais d’escalade, les notifications mail ou Fiori, et le comportement en cas de timeout. Transaction de référence côté technique : PFTC pour les standard tasks, SWDD pour le workflow builder, SBWP pour l’inbox métier.
R comme Reports : champs de sélection, layout ALV, autorisations
Une FS de Report décrit : les champs de sélection écran (obligatoires versus facultatifs, valeurs par défaut), les filtres métier (centre, gamme produit, période), le layout ALV de sortie avec ordre des colonnes, les totaux et sous-totaux, les variants utilisateurs, les autorisations cible. Transactions : SE38 pour le programme ABAP, SQ01 pour une SAP Query, SA38 pour l’exécution. Pour les autorisations, je renvoie à mon article sur les rôles et autorisations SAP.
I comme Interfaces : protocole, mapping, gestion d’erreur
Une FS d’Interface décrit : le protocole (IDoc, RFC, REST, fichier plat), le mapping champ par champ avec règles de transformation, la fréquence et le mode (synchrone ou asynchrone), la gestion d’erreur (réjeu, alerte, dead letter queue), le monitoring, la stratégie de fallback si l’interface est down. Transactions : WE30 pour le type d’IDoc, WE60 pour la documentation, SM59 pour les destinations RFC, BD64 pour le modèle de distribution ALE.
C comme Conversions : périmètre legacy, règles de transformation, cutover
Une FS de Conversion décrit : la liste des entités legacy à migrer, la volumétrie attendue, le mapping legacy vers SAP avec règles de transformation, les valeurs par défaut quand le legacy ne porte pas l’information, la stratégie de cutover (big bang, vague, phasé), le rollback. Outils selon le contexte : LSMW sur ECC, LTMC avec son LTMOM sur S/4HANA, ou batch input pour les chargements ciblés.
E comme Enhancements : point d’extension, comportement avant après, régression scope
Une FS d’Enhancement décrit : le point d’extension utilisé (BAdI, customer exit, enhancement spot, append structure), la transaction ou le programme standard impacté, le comportement avant et après custom, le périmètre de régression (quelles autres transactions touchent le même point d’extension), les conditions d’activation (par société, par centre, par utilisateur). Transactions : SE18 pour la définition BAdI, SE19 pour l’implémentation, CMOD et SMOD pour les enhancements customer classiques. Exemple concret côté PP : une règle de détermination de lot custom passe typiquement par un BAdI.
F comme Forms : layout, conditions d’impression, canaux de sortie
Une FS de Form décrit : le canal de sortie (impression, PDF, email, archivage GED), le layout (zones, blocs répétables, logos, conditions d’affichage), les variables de remplissage, les langues à supporter, les conditions de déclenchement (output determination), les copies (originale, transporteur, archive). Outils : SFP pour Adobe Form Builder, SMARTFORMS pour SmartForms, SE71 pour le SAPscript historique (à éviter en S/4HANA).
J’ai vu des projets imposer un template Word unique pour toutes les FS. Résultat : la FS de Form contenait une section “champs de sélection écran” (inutile, c’est un Form, pas un Report), et la FS de Report n’avait pas de section “autorisations cible” (parce que le template venait d’une FS de Workflow). Adoptez six templates dérivés d’un squelette commun, pas un seul.
Structurer une FS qui tient en projet : la trame en 9 sections
Toutes catégories WRICEF confondues, une FS solide tient en neuf sections : cinq sont communes à toutes les catégories, quatre sont spécifiques à la catégorie WRICEF. La trame que j’applique systématiquement.
- 1Cadrer le besoin métier avec le key user
Atelier dédié, jamais par email. Le but est de comprendre le processus avant de parler solution. Posez des questions ouvertes : qui déclenche, quand, dans quel contexte, qu’est-ce qui change après l’action, qu’est-ce qui ne doit jamais arriver. Sortie attendue : une description du processus en cinq à dix phrases, validée à voix haute par le key user.
- 2Identifier la catégorie WRICEF cible
Workflow, Report, Interface, Conversion, Enhancement ou Form. La catégorie détermine la structure de la FS. Si le besoin couvre plusieurs catégories (par exemple un Report qui déclenche un Workflow), découpez en deux FS distinctes liées par référence. Une FS, un objet.
- 3Documenter règles, exceptions, cas vides et critères d’acceptation
Pour chaque règle de gestion, listez l’exception correspondante. Pour chaque champ d’entrée, listez le comportement quand le champ est vide, null ou hors plage. Chiffrez la volumétrie attendue. Écrivez les critères d’acceptation au format “quand X alors Y”, testables un par un. C’est le contenu qui sépare une FS solide d’un cahier des charges.
- 4Faire relire en triangle
Trois relectures : key user pour valider la cohérence métier, ABAP lead pour valider la faisabilité technique et flag les zones d’ambiguïté, chef de projet pour valider l’impact planning et les dépendances inter-objets. Chaque relecteur signe son passage. Pas de signature client tant que les trois relectures ne sont pas closes.
- 5Obtenir signature périmétrée et archiver
Signature du sponsor client sur une version figée (PDF avec hash ou DocuSign). Archivage dans le repo projet, sur Solution Manager ou sur Confluence selon la stack du client. Le périmètre signé devient le référentiel : toute modification ultérieure passe par change request formel avec analyse d’impact, ré-estimation et nouvel accord sponsor.
Les quatre sections spécifiques à la catégorie WRICEF s’ajoutent au cœur de la FS : maquettes pour les Forms, mapping pour les Interfaces, arbre de décision pour les Workflows, ainsi de suite. La matrice ci-dessous résume quelles sections sont obligatoires par catégorie.
| Section | Workflow | Report | Interface | Conversion | Enhancement | Form |
|---|---|---|---|---|---|---|
| Contexte métier | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire |
| Périmètre IN/OUT | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire |
| Règles de gestion | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire |
| Critères d’acceptation | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire |
| Signature | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire | obligatoire |
| Arbre de décision | obligatoire | option | option | option | obligatoire | option |
| Layout et écrans | option | obligatoire | option | option | option | obligatoire |
| Mapping de données | option | option | obligatoire | obligatoire | option | option |
| Stratégie d’erreur | option | option | obligatoire | obligatoire | option | option |
| Point d’extension | option | option | option | option | obligatoire | option |
Les 7 pièges qui font dériver une FS en delivery
Sept pièges récurrents que j’ai vus se répéter sur quasiment tous les projets. Ils tuent silencieusement la qualité du livrable, parce qu’aucun ne déclenche d’alerte rouge à l’écriture : c’est en delivery qu’ils explosent.
Quand votre Report filtre sur un centre, que se passe-t-il si le centre est vide ? Quand votre Interface reçoit un IDoc sans le segment optionnel, comment réagit le système ? Une FS qui ne traite que le chemin nominal est une FS bancale. Pour chaque champ d’entrée, listez le comportement attendu sur valeur vide, sur valeur hors plage et sur valeur de longueur maximale. Le développeur doit pouvoir coder sans avoir à deviner.
Une FS de Report sans volumétrie va tomber en production. 10 lignes attendues, le développeur fait une boucle SELECT simple. 10 millions de lignes attendues, il faut une approche HANA-friendly avec pagination, des indexes spécifiques, peut-être un CDS view. Chiffrez l’ordre de grandeur dès la FS : nombre de lignes en sélection, nombre de transactions en pointe horaire, nombre d’IDoc par jour. C’est non négociable côté Interface et Conversion.
“Le système doit fonctionner correctement” n’est pas un critère d’acceptation. Un vrai critère se rédige au format “quand condition X alors résultat Y observable dans Z”. Exemple côté Workflow : “quand un OF passe en statut REL avec quantité supérieure à 10000, alors un mail est envoyé au responsable de production dans les 60 secondes, visible dans son inbox SBWP”. Testable, mesurable, opposable en recette.
La FS qui annonce “le système appelle la BAPI_PO_CREATE avec les paramètres EKKO-BUKRS et EKKO-LIFNR” n’est pas une FS, c’est une TS déguisée. Le besoin métier sous-jacent (créer une commande d’achat pour une société et un fournisseur sélectionnés) doit être décrit AVANT la solution. C’est le développeur qui traduit en BAPI dans la TS, pas l’inverse.
L’Interface IDoc tombe à 3h du matin. Que se passe-t-il ? Les commandes s’accumulent en queue, ou elles partent ailleurs, ou elles sont rejetées ? Qui est alerté, quand, par quel canal ? La FS doit documenter le comportement en mode dégradé, sinon le code par défaut sera “on logge et on attend que ça revienne”, ce qui se traduit par 24h de retard en production avant qu’un humain ne voie l’alerte.
La FS de Report MTBF d’un projet 2022 ne s’applique pas telle quelle au projet 2026 du même client. L’équipement a changé, le KPI a évolué, les règles d’acceptation se sont durcies. Le copier-coller fait gagner deux heures de rédaction et fait perdre trois semaines de delivery. Repartez du besoin actuel, même si la structure est familière.
Une FS livrée au développement sans signature client est une FS modifiable à l’infini. Chaque réunion produit une nouvelle “petite précision” qui devient un développement parallèle. La signature avec périmètre figé est l’outil contractuel qui transforme les modifications en change requests gérés. Sans elle, vous portez seul le risque commercial du projet.
Workflow de validation : du draft à la signature client
Une FS passe par quatre états : draft, revue, validée, signée. Le circuit standard de relecture mobilise quatre rôles. La matrice RACI que j’utilise par défaut, à ajuster selon la gouvernance projet.
| Action | Key user | Consultant fonctionnel | ABAP lead | Chef de projet | Sponsor client |
|---|---|---|---|---|---|
| Atelier de cadrage métier | R | A | C | I | I |
| Rédaction du draft | C | R/A | I | I | I |
| Relecture métier | R/A | C | I | I | I |
| Relecture faisabilité technique | I | C | R/A | I | I |
| Relecture planning et dépendances | I | C | C | R/A | I |
| Signature périmètre figé | C | C | C | C | R/A |
| Change request post-signature | C | R | C | A | R/A |
Pour l’archivage, choisissez selon la stack du client : SAP Solution Manager (avec son module ChaRM pour le Change Request Management aligné ITIL) si le client est full SAP, Confluence ou SharePoint si la documentation projet vit ailleurs. L’important est que la version signée soit identifiable sans ambiguïté (numéro de version, date, signataires) et que les versions ultérieures soient explicitement marquées comme révisions post-signature avec lien vers le change request.
Sur mes projets EAM, la qualité d’une FS prédit mieux la tenue du planning que le talent de l’équipe ABAP.
Pierre Balbinot, consultant SAP fonctionnel
Outils pratiques côté SAP pour rédiger et instruire une FS
Pour instruire une FS, vous avez besoin de plonger dans le standard SAP : comprendre comment la transaction cible fonctionne aujourd’hui, quels enhancement spots existent, quelle table porte la persistance. Les transactions par phase de scoping :
| Phase de scoping | Transaction | Usage |
|---|---|---|
| Explorer une transaction standard | SHDB | Enregistrer le déroulé d’une transaction pour comprendre l’enchaînement écran par écran avant de spécifier une variante |
| Explorer une table | SE16N | Vérifier les champs, les valeurs en base, les volumétries réelles sur sandbox |
| Scoper un enhancement | SE18 / SE19 | Lister les BAdI disponibles sur un domaine, vérifier les implémentations déjà actives |
| Scoper un Workflow | PFTC | Lister les standard tasks SAP existantes avant de créer du custom |
| Scoper un Form | SFP / SMARTFORMS | Vérifier les Forms standard existants avant de créer du Z* |
| Scoper une Interface IDoc | WE60 | Lire la documentation d’un type IDoc standard avant de spécifier les segments |
| Scoper une Conversion | LTMC | Identifier l’objet migration standard S/4HANA avant de coder du custom |
Côté gestion documentaire, deux familles d’outils dominent : Solution Manager avec son module ChaRM pour les projets full SAP avec gouvernance ITIL alignée, et la pile Atlassian (Jira pour le tracking, Confluence pour le wiki) pour les projets multi-vendor. DocuSign ou Adobe Sign couvrent la signature électronique à valeur probante. Évitez le PDF en pièce jointe d’email : impossible de tracer les versions, impossible de retrouver le dernier signé en cas de litige.
Questions fréquentes sur la spécification fonctionnelle SAP
Qui rédige la spécification fonctionnelle dans un projet SAP ?
Le consultant SAP fonctionnel rédige la FS après atelier dédié avec le key user métier. La maîtrise d’ouvrage (côté client) valide les règles de gestion sur le fond. La maîtrise d’œuvre (côté projet) traduit en faisabilité technique. Sur les projets agile, le rôle équivalent est le product owner pour le besoin et le consultant fonctionnel pour la rédaction de la spec.
Quelle est la différence entre une FS et une TS SAP ?
La FS décrit le QUOI : besoin métier, règles de gestion, comportement attendu côté utilisateur, critères d’acceptation. La TS décrit le COMMENT : objets SAP standard utilisés, BAdI choisis, programmes Z*, tables impactées, structure de code. Le consultant fonctionnel écrit la FS, le développeur ABAP écrit la TS. La TS référence la FS sur chaque section pour traçabilité.
Faut-il faire signer la FS par le client avant développement ?
Oui, signature obligatoire avant le go BUILD. Sans signature, tout changement après build est gratuit pour le client et coûteux pour le projet. La signature fige le périmètre et oblige les modifications ultérieures à passer par un change request formalisé avec analyse d’impact, ré-estimation et accord sponsor. C’est l’outil contractuel principal du delivery.
Comment structurer une FS pour un développement ABAP ?
Neuf sections : contexte métier, périmètre IN/OUT, règles de gestion avec exceptions et cas vides, maquettes ou layout, critères d’acceptation testables, impact et dépendances, stratégie de test et jeu de données, annexes techniques (Tcodes, tables, BAPI candidats), signature périmétrée. Les quatre sections de cœur (arbre de décision, mapping, layout, point d’extension) varient selon la catégorie WRICEF cible.
Que contient WRICEF et pourquoi cela change la structure de la FS ?
WRICEF couvre Workflows, Reports, Interfaces, Conversions, Enhancements, Forms. Chaque catégorie a ses sections obligatoires : une FS d’Interface décrit le protocole IDoc, le mapping et la gestion d’erreur, une FS de Report décrit les champs de sélection et le layout ALV, une FS de Form décrit le canal de sortie et les conditions d’impression. Un template unique pour les six catégories produit des FS bancales avec sections vides ou hors sujet.
Combien de temps prend la rédaction d’une FS SAP ?
Variable selon la catégorie et la complexité : 0,5 à 2 jours pour une FS de Report standard, 3 à 5 jours pour une FS d’Interface IDoc avec mapping complet, 5 à 10 jours pour une FS de Conversion ou de Workflow complexe avec ateliers métier inclus. Compter en jours-personne consultant fonctionnel, hors temps key user et hors relecture triangulée.
Comment gérer un changement de besoin après signature de la FS ?
Process Change Request formalisé : description du nouveau besoin, analyse d’impact (build, test, planning, dépendances inter-objets), ré-estimation en jours-personne et en planning, accord sponsor client, signature d’un avenant à la FS avec nouveau numéro de version. Pas de modification silencieuse ni d’accord verbal. Le change request fait partie du livrable projet et doit être archivé avec la FS d’origine.
Une FS est-elle obligatoire pour une simple customisation SAP ?
Pas pour du customizing standard SPRO sans impact business significatif (création d’un type de mouvement, ajout d’une langue, paramétrage d’un calendrier). Obligatoire pour tout développement spécifique (programme Z*, BAdI, IDoc custom, SmartForm, Workflow custom). Recommandée même sur du customizing standard quand le paramétrage touche un processus métier critique ou quand plusieurs équipes interviennent.
À lire ensuite
Rollout SAP : la méthode pratique pour piloter un déploiement multi-sites (SAP Activate, template, cutover)
Comment cadrer un rollout SAP multi-sites : phases SAP Activate, choix big bang vs phased, core template, cutover et hypercare. Pour praticiens chefs de projet.
Pierre B.
SAP Business Blueprint : pourquoi il a disparu et ce qui le remplace
Le Business Blueprint (méthodologie ASAP) n'existe plus : SAP Activate et les ateliers Fit-to-Standard l'ont remplacé. Ce qui change pour votre projet S/4HANA.
Michael A.
Déterminer le prix dans SAP SD : la mécanique de la condition technique
Comment SAP détermine le prix d'une ligne de commande SD : schéma de calcul, types de condition, séquence d'accès et enregistrements de condition, expliqués pas à pas pour un consultant...
Michael A.
S/4HANA vs ECC : les différences clés pour votre carrière SAP
Quelle différence entre SAP ECC et S/4HANA ? Les différences clés expliquées simplement, le jargon décodé, la fin de maintenance d'ECC et ce que cela change pour votre carrière SAP.
Michael A.