SAP Integration Suite : décisions et arbitrages en production

SAP Integration Suite est la plateforme d'intégration de SAP sur SAP BTP : Cloud Integration (l'ancien CPI), plus API Management, Event Mesh, Integration Advisor, Open Connectors et des outils pour migrer depuis PI/PO. C'est le middleware par défaut des programmes S/4HANA cloud et la voie de sortie de PI/PO, dont la maintenance standard s'arrête en 2027. Les retards d'interface viennent rarement de la technologie. Ils viennent d'une responsabilité mal définie, d'hypothèses non vérifiées sur les systèmes legacy et de tests conçus pour réussir plutôt que pour déceler les défaillances. Ce guide s'adresse aux responsables d'intégration, aux architectes et aux chefs de programme. Il couvre le rôle de chaque composant, le contenu standard face au développement spécifique, la migration PI/PO, les risques liés au legacy et aux tests, et la gouvernance après le go-live.

PI/PO est sur le compte à rebours. SAP Process Integration et Process Orchestration 7.5 sont en maintenance standard jusqu'à fin 2027. Une maintenance étendue optionnelle court jusqu'à fin 2030, après quoi le support SAP prend fin. L'architecture de référence de migration de SAP décrit la voie à suivre. Integration Suite inclut une application Migration Assessment qui dimensionne chaque scénario PI/PO, ainsi qu'un outillage de migration à base d'assistants dans Cloud Integration. Migrez par vagues : d'abord les flux SAP vers SAP à faible risque, le B2B et l'EDI au milieu, les flux de commandes à fort volume en dernier. Un basculement forcé sous la pression de l'échéance prend plus de temps et coûte plus cher.

1. Vague 1Flux SAP vers SAP à faible risqueDimensionner d'abord chaque scénario avec Migration Assessment
2. Vague 2B2B et EDI
3. Vague 3Flux de commandes à fort volume
4. 2027Fin de la maintenance standard de PI/PO 7.5Fin d'année. Planifiez les vagues pour finir avant cette date
5. 2030Fin de la maintenance étendue optionnelleFin d'année. Ensuite, le support SAP s'arrête

Source: Dates de maintenance SAP et architecture de référence de migration, vérifiées en octobre 2026

Vérifiez ce que couvre votre contrat cloud. Les contrats RISE et GROW incluent généralement des crédits SAP BTP qui peuvent payer Integration Suite. Confirmez quelle édition et quels volumes de messages votre droit d'usage couvre avant de comparer Integration Suite à MuleSoft ou Boomi sur les seules fonctionnalités. L'économie d'une plateforme incluse change la comparaison.

L'IA arrive par étapes. Cloud Integration propose la génération de flux par IA générative dans son édition Premium depuis mi-2024. Elle produit la structure d'un iFlow (étapes, canaux, sous-processus d'exception), pas les mappings ni les scripts. L'édition enrichie de SAP, lancée en mars 2026, ajoute la génération de flux à partir de texte et l'optimisation des scripts, et SAP prévoyait la disponibilité générale de Joule dans Integration Suite au troisième trimestre 2026. Utile pour les flux standard. Les orchestrations complexes à forte logique métier exigent toujours des architectes seniors.

Integration Suite est un ensemble de services. Utiliser le bon service pour chaque besoin détermine la solidité du paysage.

Composant	Rôle	Ce qui tourne mal quand il est mal utilisé
Cloud Integration (CPI)	Flux de messages, routage et transformation ; le choix par défaut pour la plupart des iFlows	Tout mettre dans CPI, y compris les API et les événements, devient difficile à supporter et à tester
API Management	Gouverne l'exposition des API : sécurité, limites de débit, analytique	Sans lui, les appels point à point se multiplient ; la gouvernance est difficile à rattraper
Event Mesh	Messagerie asynchrone pour des déclencheurs découplés	Des files non suivies grossissent en silence sans alerter personne
Integration Advisor	Propositions de mapping pour les formats B2B comme EDIFACT, X12 et IDoc	Les équipes supposent une couverture élevée ; l'une attendait 80 % et a obtenu plutôt 40 %
Open Connectors	Connecteurs prêts à l'emploi vers des applications cloud tierces	Les changements d'API externes cassent les connecteurs en silence si personne ne les surveille
Migration Assessment et outillage	Dimensionne et migre les scénarios PI/PO	Traité comme une estimation ponctuelle au lieu d'un vrai plan de migration

Les équipes qui voient Integration Suite comme «  CPI avec des options » ignorent souvent API Management et Event Mesh. Ça tient jusqu'à ce que la complexité les rattrape. Mon guide SAP CPI approfondit Cloud Integration lui-même.

Le contenu d'intégration SAP prêt à l'emploi est vraiment utile quand le processus est standard. Connecter S/4HANA à SAP Ariba ou à SuccessFactors avec des processus standard est souvent un bon ajustement. Les vrais processus restent rarement dans les lignes de référence de SAP.

Choisissez le contenu standard quand :

1. Le scénario est de SAP vers SAP et proche du processus de référence de SAP
2. Le flux est simple et surtout à sens unique
3. Vous pouvez vivre avec le mapping de SAP et n'étendre que par les points d'extension prévus

Choisissez un développement spécifique quand :

1. Des années de décisions internes ont éloigné le processus du modèle de SAP
2. Du routage conditionnel, une logique en plusieurs étapes ou des particularités du legacy entrent en jeu
3. Une modification lourde ferait perdre au package standard son alignement avec le support SAP

Prenez cette décision pendant la phase de blueprint. Quand elle est prise tard, les équipes découvrent en cours de projet qu'un iFlow «  standard » a été modifié au point de perdre son alignement avec le support, et le reconstruisent sous la pression du go-live. J'ai vu des projets perdre des semaines parce que les équipes pensaient que le contenu standard absorberait en même temps des structures de données de base spécifiques, des champs supplémentaires et une authentification legacy. Ce n'a pas été le cas. L'analyse qui avait sa place en conception a eu lieu pendant l'UAT.

Dans les grands programmes SAP, l'intégration est souvent la première chose à tomber entre les chantiers. Les interfaces traversent les frontières entre équipes, mais personne n'est responsable de la coordination. J'ai vu deux équipes projet construire des intégrations séparées pour le même partenaire commercial, vers le même endpoint, sans se connaître. Aucune des deux ne l'a su avant l'UAT. C'est une défaillance structurelle, pas technique.

Mettez en place tôt une gouvernance d'intégration centrale :

1. Un backlog d'intégration partagé, visible de tous les chantiers
2. Un responsable nommé pour chaque interface, suivi jusqu'à la livraison
3. Des points de coordination entre chantiers avant chaque déploiement majeur
4. Une revue des dépendances entre interfaces avant tout engagement de go-live, avec les endpoints et les files partagés séquencés dans le plan de bascule
5. Un déploiement automatisé entre environnements, avec les identifiants documentés pour chaque paysage

Les problèmes d'intégration les plus durs viennent rarement des plateformes modernes. Ce sont les systèmes plus anciens, au milieu de processus critiques.

Les ERP legacy ne savent souvent pas gérer des appels synchrones concurrents. Envoyez cinq appels d'API en parallèle et le serveur ralentit, se fige ou perd des données en silence. L'intégration asynchrone n'aide que si le système récepteur sait traiter une file, et beaucoup n'en sont pas capables.

Les incompatibilités de protocole sont fréquentes et découvertes tard. Vous concevez avec OAuth2 et REST ; le système legacy parle SOAP avec un timeout de 30 secondes codé en dur et gère mal le renouvellement des jetons.

Chez un client, un flux de middleware échouait tous les vendredis parce que le jeton émis par un système de paie tiers expirait chaque semaine. Personne ne l'a remarqué avant le deuxième cycle d'UAT. Des particularités de ce genre sont courantes, et elles mangent le calendrier.

Le tableau liste les risques à vérifier avant le gel de la conception.

Risque	Problème courant	À faire en conception
Limites synchrones	Le legacy se bloque sous des appels parallèles	Utiliser la messagerie asynchrone ; étaler les appels via Event Mesh ou Cloud Integration
Incompatibilité de protocole	Le legacy rejette REST ou OAuth, ou expire en timeout sur SOAP	Confirmer protocoles et timeouts avant le début de la conception
Limites de débit des API	Les traitements par lots dépassent la limitation du tiers	Limiter le débit dans API Management ; ajouter une logique d'attente dans l'iFlow
Expiration des jetons	Les flux échouent en silence en dehors des heures de pointe	Planifier les cycles de renouvellement et surveiller les expirations
Formats rigides	Des charges utiles dynamiques cassent l'analyse du legacy	Valider avec de vrais échantillons de production
Absence de plan de repli	Les transferts de fichiers échouent sans relance et les données restent bloquées	Mettre en tampon dans le middleware ; intégrer relances et alertes dans les iFlows

Pour la version entre clouds de ces problèmes, voir mon article sur pourquoi l'intégration ERP avec Salesforce échoue.

L'intégration ne casse pas comme les tests fonctionnels le vérifient. Elle échoue sous pression temporelle, quand des jobs en arrière-plan se chevauchent, et quand les entrées arrivent en volume plutôt qu'une par une. Un test fonctionnel prouve qu'une transaction est comptabilisée et qu'un message apparaît dans le journal. Il ne prouve pas ce qui se passe quand la première paie envoie un déluge d'IDocs. Sur un projet, un IDoc qui avait l'air propre en test d'intégration système a bloqué la file quand les vrais volumes de paie sont arrivés. Seul le test de charge l'a trouvé.

Les tests d'interface doivent couvrir :

1. Des volumes de données réalistes avec des utilisateurs concurrents
2. Les interruptions de service et le comportement de reprise
3. Les timeouts et les relances entre le middleware et les systèmes back-end
4. Des jobs batch qui tournent en même temps que des appels temps réel
5. La clôture mensuelle et les autres périodes de pointe

Les environnements de développement sont propres. Les deadlocks, les situations de concurrence et la limitation de débit apparaissent en UAT et en préproduction, où les autres systèmes et les fenêtres batch sont actifs : faites-y vos tests de charge. Répartissez clairement les responsabilités : les équipes fonctionnelles valident les résultats métier sur l'ensemble du flux, les équipes d'intégration possèdent les journaux, les relances et les flux d'exception, et les chefs de projet confirment la couverture. Mon guide des tests de performance SAP couvre le volet charge.

Integration Advisor propose des mappings pour des formats B2B structurés. Pour des partenaires qui respectent des conventions strictes, il fait gagner un vrai temps de paramétrage. Pour les intégrations d'entreprise avec des systèmes legacy, des champs spécifiques, de la logique conditionnelle et des règles non documentées, c'est un point de départ.

Une équipe avec laquelle j'ai travaillé attendait 80 % de couverture de mapping. La couverture réelle a été d'environ 40 %. Le reste a dû être personnalisé, validé avec le métier et testé à la main.

Il ne résout pas la logique métier accumulée de façon informelle au fil des ans (conditions de paiement, catégories de prix, conventions d'unités), ni les règles conditionnelles fondées sur le contexte métier, ni les exceptions hors du format standard. Cela demande un apport fonctionnel. Sans lui, les interfaces sont techniquement mappées et logiquement fausses dans des cas précis.

L'intégration se dégrade après le go-live quand la documentation dérive et que la responsabilité n'est pas formelle. Une documentation utile couvre les mappings de champs et la logique de transformation, ainsi que les détails d'authentification : endpoints, renouvellement des jetons et rotation des identifiants. Elle couvre aussi la gestion des erreurs, les règles de repli et les volumes attendus pour les fenêtres critiques comme la clôture mensuelle et la paie. Le test : quelqu'un qui rejoindrait l'équipe de support la semaine prochaine pourrait-il dépanner une interface en échec avec la seule documentation ?

Chaque interface, même à faible volume, a besoin d'un responsable nommé pour la supervision, l'escalade et les changements de cycle de vie. Sans lui, les défaillances rebondissent entre Basis, middleware et équipes fonctionnelles pendant que le métier attend. Après l'hypercare, la supervision a tendance à s'éroder. Prévoyez des revues régulières des journaux d'erreurs, une passation formelle du projet au support et des niveaux de service convenus entre le métier et l'IT. Une intégration négligée est à l'origine de nombreuses écritures en retard, de factures manquantes et de rapports financiers désalignés qui apparaissent des semaines après le go-live.

Qu'est-ce que SAP Integration Suite et en quoi diffère-t-il de CPI ?

Cloud Integration, anciennement SAP Cloud Platform Integration (CPI), est l'une des capacités d'Integration Suite. La suite ajoute API Management pour une exposition gouvernée des API et Event Mesh pour la messagerie asynchrone. Elle comprend aussi Integration Advisor pour les propositions de mapping B2B, Open Connectors pour les applications cloud tierces, et des outils d'évaluation et de migration pour PI/PO. Les équipes qui la traitent comme un CPI rebaptisé sautent souvent API Management et Event Mesh, et le paient plus tard en défauts de gouvernance.

Quand le support SAP PI/PO prend-il fin ?

SAP Process Integration et Process Orchestration 7.5 sont en maintenance standard jusqu'à fin 2027. Les clients peuvent souscrire une maintenance étendue optionnelle jusqu'à fin 2030, après quoi le support SAP prend fin. Integration Suite inclut une application Migration Assessment pour dimensionner chaque scénario et un outillage de migration pour déplacer les artefacts de façon semi-automatique. Commencez par un plan par vagues plutôt que d'attendre l'échéance.

Quand utiliser du contenu standard plutôt qu'un développement spécifique pour l'intégration SAP ?

Utilisez le contenu standard quand le scénario est de SAP vers SAP, proche du processus de référence de SAP et relativement simple. Construisez du spécifique quand le processus s'est éloigné du modèle de SAP, quand des particularités du legacy demandent un traitement précis, ou quand une logique conditionnelle et en plusieurs étapes imposerait de lourdes modifications du package standard. Décidez pendant le blueprint ; reconstruire un flux standard sur-modifié sous la pression du go-live coûte plus cher qu'un développement spécifique propre.

Quelles sont les causes des échecs d'intégration SAP dans les programmes complexes ?

Surtout des causes structurelles. Pas de responsable nommé pour la supervision et la résolution des erreurs, si bien que les défaillances rebondissent entre équipes. Deux chantiers qui construisent des intégrations partageant un endpoint ou une file sans le savoir. Des systèmes legacy qui ne supportent pas les appels concurrents, découverts seulement sous charge. Et des tests qui passent proprement en isolation mais ne simulent jamais le chevauchement des batchs ni les volumes de pointe.

Comment structurer les tests d'intégration pour SAP Integration Suite ?

Au-delà des tests fonctionnels, couvrez des volumes réalistes comme la première clôture mensuelle ou la première paie. Testez des jobs batch qui tournent en même temps que des interfaces temps réel, la reprise quand un système en aval est indisponible et les limites de débit des tiers pendant les traitements en masse. Faites les tests de charge et de performance dans des environnements proches de la production, car des systèmes de développement propres masquent les problèmes.

Comment gouverner l'intégration SAP après le go-live ?

Donnez à chaque interface un responsable nommé pour la supervision, l'escalade et les changements. Tenez la documentation à jour : mappings, authentification et rotation des identifiants, gestion des erreurs et volumes attendus. Et construisez un modèle de support durable avec des revues régulières des journaux d'erreurs, une passation formelle du projet au support et des niveaux de service convenus. Une intégration devenue invisible est une intégration négligée.