Références

Ce que nous avons réellement livré

Trois chantiers récents chez notre client historique, un distributeur multi-sites sous SAP S/4HANA et SAP Retail que nous accompagnons depuis 2011. Les chiffres viennent de l'historique des tickets du projet.

Cas n°1 · Facturation électronique · 2026

Une bascule réglementaire tenue sur un SAP chargé d'historique

ClientDistributeur multi-sites
SystèmeS/4HANA 2023, SAP Retail
PérimètreFI, MM, SD · factures entrantes
PériodeMars – octobre 2026

Le contexte

Au 1er septembre 2026, la plateforme de facturation électronique du client passait d'un format plat à des IDoc INVOIC au format XML. L'intégration existante reposait sur un type de message non standard et sur une couche de dématérialisation construite au fil des années. Il fallait aussi produire l'e-reporting à partir de trois sources : SD, MM et FI.

Notre intervention

  • Intégration XML sans SAP PI/PO : correction de la structure des IDoc, port XML sur les trois environnements, traitement standard appelé par l'EAI.
  • Couche d'intégration défensive : correction automatique à l'entrée de SAP des données mal transmises par la plateforme (dates, taux de TVA, segments manquants, classification FI ou MM).
  • Recette sur volumes réels : rejeu de journées complètes de production avant chaque mise en production.
  • Hypercare : adaptation du code historique (avoirs sur retours, détermination de la société, codes articles) et réactivation du cockpit de correction des factures en erreur.
  • E-reporting : table de détermination des cas métier, CDS par module et CDS consolidée, application Fiori de contrôle, génération du flux XML.
À retenir : ne pas attendre que la plateforme soit parfaite. Fiabiliser les données à l'entrée de SAP et recetter sur des journées réelles de production permet de tenir l'échéance.
Cas n°2 · SAP Fiori · 2023-2025

Les demandes d'achat, de l'application historique à Fiori

ClientDistributeur multi-sites
SystèmeS/4HANA, Fiori Launchpad
PérimètreAchats, immobilisations, imputations
PériodeNov. 2023 – janv. 2025

Le contexte

Les demandes d'achat passaient par une application spécifique développée sur une solution tierce, avec ses propres règles d'autorisation. La DSI voulait revenir au standard SAP Fiori, sans perdre les fonctions auxquelles les utilisateurs tenaient : délégations, pièces jointes, motifs de refus, création d'immobilisations par la comptabilité.

Notre intervention

  • Cadrage : reprise des spécifications existantes, proposition d'interface, clarification des règles de gestion (workflow, autorisations par profil).
  • Back-end S/4HANA : CDS views, services OData, classes et BAPI standard.
  • Applications Fiori : gestion des demandes, approbation multi-niveaux, commandes à créer, historique du workflow et code couleur selon l'avancement.
  • Itérations avec les utilisateurs : ergonomie harmonisée, aides à la saisie, affichage adapté aux portables, performances sur de gros volumes de données de référence.
  • Mise en production en janvier 2025, puis lots d'optimisation au fil des demandes des utilisateurs.
À retenir : livrer tôt une version qui fonctionne, puis itérer avec les utilisateurs sur l'ergonomie, plutôt que de viser un design parfait dès la première livraison.
Cas n°3 · S/4HANA · 2025

Upgrade 1809 → 2023 : migrer le code utile, pas tout le code

ClientDistributeur multi-sites
SystèmeS/4HANA 1809 → 2023
PérimètreCode spécifique, flux, Fiori
PériodeFévrier – août 2025

Le contexte

Après une première migration d'ECC vers S/4HANA 1809, à laquelle nous avions contribué, le client devait passer en version 2023. L'enjeu : adapter un patrimoine important de programmes spécifiques et une trentaine de flux sans interrompre l'activité du réseau.

Notre intervention

  • Analyse d'impact croisée : contrôles ATC sur tout le code spécifique, croisés avec les statistiques d'utilisation des 12 derniers mois, et repérage des applications Fiori standard devenues obsolètes.
  • Arbitrage du périmètre avec le client, par criticité, type d'erreur et obsolescence.
  • Continuité du run : environnements parallèles en 1809 pour la maintenance courante et double maintenance des évolutions.
  • Migration par lots, en commençant par le réassort et la facturation, pour que la recette métier avance en parallèle. Traitement des étapes SPDD et SPAU.
  • Recette sur données réelles pour repérer les changements de comportement du standard SAP avant la bascule.
À retenir : croiser l'ATC avec l'usage réel du code réduit fortement le périmètre à migrer. Rejouer des flux de production en recette fait remonter les régressions du standard avant la production.
Et aussi

D'autres sujets traités pour le même client

Migration ECC → S/4HANA

Contribution à l'adaptation du code spécifique et des flux lors du passage en S/4HANA 1809, en 2020.

Reprise de données en masse

Cockpit de migration et reprise des coordonnées bancaires des fournisseurs, avec BAPI dédiée.

Dématérialisation fournisseurs

Installation et montées de version du connecteur entre SAP et la solution de dématérialisation des factures.

Un chantier comparable chez vous ?

Racontez-nous votre contexte : nous vous dirons ce que nous ferions, et ce que nous ferions différemment avec le recul.