SAP CPI : définition, architecture et migration depuis PI/PO

SAP CPI (Cloud Platform Integration) est le middleware cloud de SAP pour connecter des systèmes SAP et non SAP. Il s'appelle aujourd'hui Cloud Integration et constitue la capacité centrale de SAP Integration Suite sur SAP Business Technology Platform (SAP BTP).

Il transporte des messages entre applications, transforme leur format et les achemine vers la bonne cible. Si vous utilisez encore SAP PI/PO, le calendrier compte : la maintenance standard de SAP NetWeaver 7.5, qui inclut PI/PO, prend fin à la fin de 2027.

Ce guide explique ce que fait CPI, comment fonctionne son architecture, comment il se compare à PI/PO et comment planifier la migration. Il s'adresse aux responsables de l'intégration et aux DSI, pas seulement aux développeurs.

J'ai vu des équipes passer des mois à construire des scripts personnalisés fragiles pour connecter des systèmes SAP et non SAP. Au début, quelque chose fonctionne. Puis une mise à jour du système change le nom d'un champ, une nouvelle version d'API est déployée, ou le trafic double.

Le script casse sans bruit. Personne ne s'en rend compte jusqu'à ce qu'un rapport remonte des données périmées ou qu'une commande reste non traitée pendant trois jours.

CPI remplace cela par des flux d'intégration managés et réutilisables. Non pas parce que c'est plus simple (ça ne l'est souvent pas), mais parce que l'architecture est conçue pour être supervisée et maintenue. Les petites décisions prises tôt dans la conception CPI se transforment en dette technique plus vite que la plupart des équipes ne le pensent.

Mon conseil à toute entreprise encore sur SAP PI/PO : passez à SAP Integration Suite. L'échec d'intégration le plus fréquent que je vois, c'est de ne pas consacrer assez de temps à l'intégration.

Le guide de migration de SAP décrit Cloud Integration comme la capacité qui sert à concevoir et exécuter des flux d'intégration dans des environnements cloud, sur site et hybrides. Elle couvre les scénarios d'application à application (A2A), d'entreprise à entreprise (B2B) et d'entreprise à administration (B2G). La plupart des consultants disent encore « CPI » ou « SAP CI », et c'est très bien.

SAP Integration Suite regroupe Cloud Integration avec d'autres capacités. Les principales sont API Management, Event Mesh, Integration Advisor, Trading Partner Management, Open Connectors et Migration Assessment.

Ce que fait CPI : il transporte des données entre systèmes, transforme les formats de message, achemine vers la bonne cible et gère les erreurs et les nouvelles tentatives. Il connecte des systèmes SAP (S/4HANA, SuccessFactors, Ariba) et des plateformes non SAP (Salesforce, Workday, ServiceNow) via des adaptateurs standard.

Ce qu'il ne fait pas : stocker des données à long terme, remplacer un ERP ou servir d'outil ETL pour une migration massive de données. Il est conçu pour des messages en temps réel ou quasi réel. L'utiliser comme entrepôt de données ou comme outil de migration crée plus tard des problèmes d'architecture.

CPI face à SAP BTP : BTP est la plateforme entière : développement d'applications, données, AI, analytique et intégration. CPI est un service parmi d'autres sur cette plateforme. Un architecte BTP conçoit à travers les services ; un spécialiste CPI est responsable des flux, des adaptateurs, des mappings et de la connectivité.

Le schéma ci-dessous montre les scénarios d'intégration pour lesquels CPI est conçu. Du cloud au cloud, du site au cloud, entre entreprises (B2B), entre entreprise et administration (B2G), et les connexions aux utilisateurs et aux appareils.

Comprendre l'architecture de CPI ne concerne pas que les développeurs. D'après mon expérience, les équipes qui saisissent la façon dont CPI gère l'intégration au niveau structurel font généralement de meilleurs choix de conception dès le départ.

CPI fonctionne comme un service cloud multitenant sur SAP BTP. SAP exploite la plateforme, vous n'avez donc pas à maintenir vos propres serveurs d'intégration. Quand un flux doit s'exécuter dans votre propre réseau, Edge Integration Cell est un environnement d'exécution hybride optionnel : vous concevez et supervisez dans le cloud et exécutez le flux dans votre propre réseau.

Le flux de messages en pratique

Au cœur se trouve l'iFlow (integration flow). Chaque intégration dans CPI est modélisée sous cette forme, et chaque iFlow fait passer un message d'une source à une cible en trois étapes :

1. Adaptateur émetteur. Reçoit le message du système source via SOAP, REST, OData, IDoc, SFTP, JMS, AS2 ou un autre protocole.
2. Étapes de traitement. Mapping, conversion de format (de JSON vers XML, par exemple), routage selon le contenu, appels à d'autres systèmes, chiffrement et gestion des erreurs.
3. Adaptateur récepteur. Envoie le message traité à sa cible.

Les flux s'exécutent de manière synchrone ou asynchrone, selon le cas d'usage. Le bon choix n'est pas toujours évident, donc testez les deux avec des volumes réels.

La supervision joue un grand rôle. Vous disposez des journaux de traitement des messages, de la trace et des messages persistés, chacun avec un usage différent. Pendant les tests ou le débogage, j'alterne en général entre la trace et la persistance selon la profondeur d'analyse dont j'ai besoin.

Composants de l'architecture SAP CPI

Le tableau associe chaque composant à son rôle dans l'architecture.

Composant	Ce qu'il fait	Rôle dans l'architecture
Environnement d'exécution des flux d'intégration	Exécute les iFlows	Gère le routage, le mapping, la transformation et la sécurité à l'exécution
Concepteur web	Éditeur graphique pour créer, configurer et déployer les iFlows	L'endroit où les développeurs modélisent les flux ; la logique complexe exige toujours Groovy ou JavaScript
Adaptateurs	SOAP, REST, OData, IDoc, JDBC, SFTP, JMS, AS2 et adaptateurs spécifiques aux SaaS	Connectent les systèmes cloud et sur site
Sécurité	OAuth 2.0, SAML, TLS, gestion des certificats et des clés	Protège les identifiants et les messages en transit
Supervision et exploitation	Journaux de messages, détail des erreurs, nouvelles tentatives, alertes	Permet aux équipes de support de trouver et corriger les échecs
Contenu préconfiguré	Packages d'intégration livrés par SAP sur le SAP Business Accelerator Hub	Accélère les scénarios standard avec du contenu testé
SAP Cloud Connector	Tunnel sécurisé entre votre réseau et SAP BTP	Atteint les systèmes sur site sans les exposer à internet
Edge Integration Cell	Environnement d'exécution optionnel dans votre propre centre de données ou cloud privé	Pour les flux qui doivent rester sur site

Les scripts Groovy gèrent la logique que les étapes graphiques ne savent pas traiter. Je conseille souvent d'en limiter l'usage, car trop de scripts entraîne plus tard des problèmes de maintenance. Les packages sont versionnés, donc aucune modification n'arrive en production en dehors d'un package déployé.

Trois dates pilotent aujourd'hui presque tous les plans d'intégration.

1. 2027Fin de la maintenance standard de PI/POFin d'année, pour SAP NetWeaver 7.5
2. 2028Fin de Cloud Integration sur Neo31 décembre. Les tenants Neo passent à Cloud Foundry
3. 2030Fin de la maintenance étendue de PI/POFin d'année. Le dernier arrêt pour tout système PI/PO

Source: Note SAP 1648480 et article 3355661 de la base de connaissances SAP

1. PI/PO arrive en bout de course. La note SAP 1648480 fixe la fin de la maintenance standard de SAP NetWeaver 7.5, qui inclut PI/PO, à la fin de 2027, avec une maintenance étendue jusqu'à la fin de 2030. Le système ne s'arrête pas le 1er janvier 2028, mais chaque année suivante coûte plus cher à maintenir.
2. Neo ferme. L'article 3355661 de la base de connaissances SAP confirme que Cloud Integration sur l'environnement SAP BTP Neo prend fin le 31 décembre 2028. Les anciens tenants CPI sur Neo doivent passer à l'environnement multicloud (Cloud Foundry), et ce passage est un petit projet à part entière.
3. L'hybride a une réponse. Edge Integration Cell exécute les flux d'Integration Suite dans votre propre réseau. Cela supprime la raison la plus courante qu'avançaient les équipes pour rester sur PI/PO.

Côté contrat : si vous êtes sous RISE with SAP, vérifiez quel droit d'utilisation SAP BTP votre contrat inclut déjà avant d'acheter séparément de la capacité Integration Suite.

PI (Process Integration) et PO (Process Orchestration) sont les middlewares sur site de SAP. Voici comment ils se comparent à CPI.

Critère	SAP PI/PO	SAP CPI (Integration Suite)
Déploiement	Sur site, sur vos serveurs	Cloud sur SAP BTP ; Edge Integration Cell pour une exécution sur site
Charge de maintenance	Élevée : correctifs, mises à niveau, gestion des serveurs	Plus faible : SAP exploite la plateforme
Extensibilité	Personnalisation poussée ; mises à niveau plus difficiles	Modulaire ; mises à jour plus rapides ; moins de contrôle de bas niveau
Licences	Licence plus votre propre infrastructure	Abonnement sur SAP BTP, selon l'édition
Orientation des investissements	Maintenance uniquement, aucune nouvelle fonctionnalité	Développement actif
Fin de la maintenance standard	Fin 2027 (étendue jusqu'à fin 2030)	Sans objet (service cloud)

Le guide de migration de SAP traite Cloud Integration comme le remplaçant principal, car il couvre l'essentiel de ce que fait PI/PO. Demandez à SAP comment votre édition est mesurée, puis modélisez-la avec vos volumes de messages réels avant de migrer. Certaines entreprises découvrent que leur trafic d'intégration est plus élevé qu'elles ne le pensaient.

La migration n'est pas une conversion automatique. Le comportement des adaptateurs diffère entre PI et CPI, et une gestion des erreurs qui fonctionnait dans PI peut se comporter autrement dans CPI. Certains flux doivent être reconstruits ; d'autres migrent avec de petites modifications.

SAP fournit deux outils officiels :

1. Migration Assessment. Une capacité d'Integration Suite qui se connecte à votre système PO, extrait les scénarios d'intégration et estime l'effort nécessaire pour les migrer. Le tutoriel SAP en décrit la mise en place.
2. Migration Tooling. Une fonctionnalité de Cloud Integration qui semi-automatise la migration des objets de configuration intégrée (ICO) de PO vers des iFlows. Seuls les scénarios évalués « Ready to migrate » ou « Adjustment required » peuvent être migrés avec cet outil.

SAP Learning est clair : aucun chemin de migration unique ne convient à tous les clients, et beaucoup font tourner PI/PO et Integration Suite en parallèle pendant la migration. Les outils réduisent le travail mécanique. Ils ne tranchent pas à votre place ce qu'il faut reconstruire et ce qu'il faut retirer.

Voici le plan par vagues que j'utilise comme point de départ. Adaptez les vagues à votre propre inventaire.

Vague	Ce qui migre	Pourquoi dans cet ordre	Responsable	Critères de sortie
0. Inventaire	Chaque interface PI : fréquence, volume, adaptateur, criticité, responsable	On ne peut pas planifier ce qu'on n'a pas compté	Responsable de l'intégration	Inventaire validé par les responsables métier
1. Faible risque	Flux SAP vers SAP avec contenu standard	Valide le modèle d'exploitation et la supervision	Responsable de l'intégration	Deux semaines stables en production, chemin PI retiré
2. Partenaires	Flux B2B et EDI avec les partenaires commerciaux clés	Exige des fenêtres de test avec les partenaires et une bascule coordonnée	Responsable de l'intégration avec les achats et les ventes	Chaque partenaire confirme par écrit
3. Risque élevé	Flux à gros volume, réglementés ou critiques pour le chiffre d'affaires	Migrent en dernier, avec le plus de répétitions	Architecte d'intégration	Test de volume réussi ; retour arrière vers PI répété
4. Retrait	Arrêt de PI/PO	Évite de payer deux plateformes	DSI	Tous les flux migrés ou retirés ; licences résiliées

Gardez un chemin de retour vers PI pour chaque vague jusqu'à ce que le nouveau flux ait tourné sans erreur en production. L'ordre compte : validez le modèle d'exploitation sur des flux à faible risque avant de toucher aux interfaces qui portent le chiffre d'affaires.

Les tests d'intégration sont l'endroit où le temps disparaît. Planifiez tôt les tests de non-régression avec les partenaires B2B et les cibles non SAP, car ce sont eux qui cassent sans bruit. Mon guide des tests SAP explique comment structurer les cycles de tests d'intégration et de non-régression.

Si la migration de PI/PO s'inscrit dans un programme S/4HANA, alignez les deux plans. Mon guide de migration d'ECC vers S/4HANA présente les voies possibles et les échéances côté ERP.

Les scénarios que je rencontre le plus souvent :

1. S/4HANA vers SuccessFactors. Données organisationnelles, effectifs et changements de rémunération. Le contenu d'intégration standard de SAP couvre les scénarios courants ; des flux personnalisés gèrent les écarts.
2. Ancien système d'achats vers SAP Ariba. Bons de commande à l'aller, confirmations et factures au retour. Généralement dans les deux sens.
3. Données financières vers SAP Analytics Cloud. Transfert de données depuis ECC ou des systèmes non SAP vers SAC.
4. Salesforce vers SAP. Les affaires conclues arrivent dans SAP pour l'exécution, la facturation et la mise à jour des stocks. Mon article sur les raisons de l'échec des intégrations Salesforce-ERP décrit les erreurs de conception.

Si le travail d'intégration prend déjà du retard sur votre programme, l'article sur les retards de livraison de SAP Integration Suite en présente les causes habituelles. La présentation des plateformes d'intégration SAP compare les options côte à côte.

Qu'est-ce que SAP CPI et comment s'appelle-t-il aujourd'hui ?

SAP CPI signifie Cloud Platform Integration. C'est aujourd'hui la capacité Cloud Integration de SAP Integration Suite sur SAP BTP, à côté d'API Management, d'Event Mesh et des outils d'intégration avec les partenaires. « CPI » reste le nom courant pour la création de flux d'intégration.

Qu'est-ce que SAP CI ?

SAP CI est l'abréviation de SAP Cloud Integration, le nom actuel de ce qui s'appelait SAP CPI. Les deux termes désignent la même capacité au sein de SAP Integration Suite.

SAP CPI est-il un middleware ?

Oui. CPI est un middleware cloud : il se place entre les systèmes, transforme et achemine les messages, et gère les erreurs et les nouvelles tentatives. Il remplace les middlewares sur site comme SAP PI/PO, et il ne stocke pas de données métier à long terme.

En quoi SAP CPI diffère-t-il de SAP PI/PO ?

PI/PO est un middleware sur site que vous installez, corrigez et exploitez vous-même. CPI est un service cloud sur SAP BTP que SAP exploite pour vous, avec de nouveaux adaptateurs et contenus livrés de manière centralisée. Edge Integration Cell couvre les flux qui doivent rester sur site.

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

La maintenance standard de SAP NetWeaver 7.5, qui inclut PI/PO, prend fin à la fin de 2027. Une maintenance étendue est disponible jusqu'à la fin de 2030. SAP propose Migration Assessment et Migration Tooling pour aider à migrer les scénarios vers Integration Suite.

SAP CPI est-il la même chose que SAP BTP ?

Non. SAP BTP est la plateforme : développement d'applications, données, analytique, AI et intégration. CPI est le service d'intégration de cette plateforme.

Au moment de cadrer le travail, budget et compétences diffèrent : un architecte BTP travaille à travers les services, un spécialiste CPI est responsable des flux, des adaptateurs et des mappings.

Si vous planifiez une sortie de PI/PO ou concevez l'intégration d'un nouveau programme S/4HANA, commencez par l'inventaire des interfaces. Si vous voulez un deuxième avis sur le plan avant de vous y engager, contactez-moi.