Migration de SAP C4C vers Sales & Service Cloud V2 : pourquoi la stratégie prime sur la vitesse

C4C a été solide pour ce qu’il était. Il fonctionne toujours et SAP continue de le maintenir. Mais les nouvelles fonctionnalités CRM de SAP, dont Joule et les nouveaux agents d’IA, sont conçues pour Sales Cloud V2 et Service Cloud V2. L’écart entre ce que C4C sait faire et ce que V2 propose se creuse à chaque version.

Comme SAP n’a fixé aucune date de fin pour C4C, vous pouvez choisir votre moment. Le comment compte donc davantage que le quand.

En bref : passer de C4C à V2 est une réimplémentation, pas une mise à jour : modèle de données, API et framework d’extension changent. Notre stratégie en cinq phases (analyse, refonte des interfaces, construction en parallèle, migration des données, adoption) prend 6 à 10 mois pour une organisation ventes et service de taille moyenne. Commencez par un inventaire complet de votre système C4C et un calendrier réaliste. En septembre 2026, SAP n’a annoncé aucune date de fin de maintenance pour C4C : rien ne justifie la précipitation.

Pourquoi V2 n’est-il pas une simple mise à jour ?

C’est le point le plus important. SAP a construit V2 de zéro sur SAP BTP. Presque rien ne se transfère tel quel :

• Modèle de données : différent. Champs personnalisés, objets métier et extensions ne sont pas repris automatiquement.
• API : différentes. Chaque interface bâtie sur les services OData de C4C doit être reconstruite sur les API V2.
• Interface : différente. Elle est nouvelle, orientée rôles et suit le design SAP Fiori.
• Extensibilité : différente. C4C utilisait les outils key user et le PDI/SDK. V2 utilise les services de SAP BTP. Plus de souplesse, mais d’autres compétences.

Les entreprises qui traitent V2 comme un simple changement de version rencontrent vite des problèmes. Pour une comparaison fonction par fonction, lisez SAP Sales Cloud V2 vs. C4C : ce qui a vraiment changé et, pour les équipes de service, Service Cloud V2 : ce qui change.

Pourquoi la stratégie compte-t-elle plus que la vitesse ?

Quand l’avenir d’une plateforme paraît incertain, le réflexe est de se précipiter. Une migration précipitée vous apporte :

• Des interfaces cassées que personne n’avait recensées avant la bascule
• De la logique métier perdue, enfouie dans du code C4C non documenté
• Des utilisateurs frustrés, parce que la nouvelle interface ne ressemble en rien à l’ancienne
• Des dépassements de budget, parce que reprendre coûte plus cher que planifier

La bonne approche commence par un inventaire complet. Chaque champ personnalisé, règle de workflow, interface et rapport est recensé et évalué. Tout n’a pas sa place dans V2. Certains éléments étaient des contournements que V2 gère en standard. D’autres sont obsolètes. Ceux qui comptent méritent une reconstruction propre, pas un portage hâtif.

À quoi ressemble une migration solide ?

Pour le passage de V1 à V2, SAP fournit un Readiness Check Tool (RCT) et un Data Transfer Tool (DTT), tous deux enrichis avec les versions 2508 et 2511 (aperçu de la version). Ces outils aident, mais ne remplacent pas une stratégie. Voici les cinq phases que nous suivons.

Phase 1 : analyse et découverte (2 à 4 semaines)

Recensez tout l’environnement C4C : configuration, objets personnalisés, interfaces, rapports, rôles utilisateurs et automatisations de workflow. Classez chaque élément :

• Migrer : nécessaire dans V2, à reconstruire dans le nouveau modèle
• Reconcevoir : nécessaire, mais V2 le gère nativement (par exemple, les règles d’acheminement deviennent un routage par compétences)
• Remplacer : une meilleure option existe dans V2 ou sur BTP
• Retirer : plus nécessaire, ou n’a jamais été qu’un contournement

Cette phase évite la cause de retard la plus fréquente : des personnalisations non documentées découvertes en pleine migration. Si personne ne se souvient pourquoi une règle de workflow existe, l’équipe passe des jours à enquêter au lieu de construire. Pour une première étape à prix fixe, notre évaluation de préparation à la migration de V1 vers V2 examine votre paysage en 3 jours pour CHF 7’500, déduits de la mise en œuvre V2.

Phase 2 : refonte des interfaces (4 à 6 semaines)

La plupart des interfaces C4C doivent être reconstruites, ce qui est aussi l’occasion de simplifier. SAP fournit du contenu d’intégration standard entre V2 et S/4HANA, et SAP Integration Suite couvre la plupart des autres scénarios : vous avez besoin de moins de code de liaison sur mesure.

Recensez chaque point d’intégration, vérifiez si V2 propose une alternative standard et remplacez les interfaces point à point par une intégration fondée sur les événements, là où V2 publie les événements utiles. Définissez l’architecture cible avant d’écrire la moindre ligne de code. Si S/4HANA fait partie de votre paysage, notre guide sur le fonctionnement de S/4HANA Public Cloud et Sales Cloud V2 comme pile intégrée explique les données de base partagées, le processus quote-to-cash et ce qu’il faut conserver de votre intégration C4C.

Phase 3 : construction en parallèle (8 à 12 semaines)

Construisez V2 pendant que C4C reste en production. Pas de bascule big bang. Vous pouvez ainsi tester correctement, valider les migrations d’essai et former les utilisateurs avant la mise en production.

Principaux domaines de configuration pour les équipes de service :

• États et transitions du cycle de vie des dossiers
• Règles de routage par compétences et profils de compétences des agents
• Classification des dossiers par IA, si elle est sous licence (chargez tôt les dossiers historiques)
• Migration et restructuration de la base de connaissances
• Définitions des SLA et règles d’escalade

Phase 4 : migration des données (4 à 6 semaines)

Clients, contacts, opportunités, dossiers et activités passent dans V2 avec les outils de migration de SAP. Définissez les règles de mappage, effectuez plusieurs migrations d’essai avec des volumes proches de la production et fixez une fenêtre de bascule claire. Notre guide pas à pas du DTT présente l’outil.

Si vous prévoyez d’utiliser la classification des dossiers par IA, importez tôt les dossiers historiques. Le modèle apprend à partir de dossiers réels, pas de données de test fictives.

Phase 5 : conduite du changement et formation (2 à 4 semaines)

Le changement d’interface justifie à lui seul une formation dédiée, mais ce n’est pas tout : workflows, routage, visibilité des SLA et fonctions d’IA fonctionnent autrement dans V2. Impliquez les utilisateurs clés dans les tests de recette, formez par la pratique plutôt qu’avec des présentations et prévoyez 2 à 4 semaines de stabilisation après la mise en production.

Que nous apprend le travail de migration ?

Les mêmes schémas reviennent chaque fois que nous planifions ou examinons un passage de C4C à V2.

Documentez tout dans C4C avant de commencer. Les plus gros retards viennent de personnalisations non documentées découvertes en pleine migration.

Ne migrez pas la dette technique. Si un contournement C4C a toujours été bancal, ne le reconstruisez pas dans V2. V2 règle en standard beaucoup d’anciens irritants : hiérarchies de dossiers, routage par compétences, automatisation des SLA. Profitez de la migration pour faire le ménage.

Prévoyez largement le temps des interfaces. Chaque point de terminaison API de C4C change dans V2. Dix interfaces signifient dix reconstructions, et le budget doit le refléter.

Investissez tôt dans l’adoption. Le meilleur système échoue si les gens le rejettent. Lancez la conduite du changement dès le premier jour. Pour les équipes de service, il s’agit de nouvelles compétences sur le poste de travail agent, pas seulement de nouveaux écrans.

Testez avec des données réelles. Les données de test fictives cachent les problèmes. Effectuez des migrations d’essai avec des volumes proches de la production pour détecter les erreurs avant la mise en production.

Pourquoi le choix du partenaire est-il décisif ?

Une migration de C4C vers V2 n’est pas un projet standard. Un partenaire qui ne connaît que V2 passe à côté des particularités de votre système C4C. Un partenaire qui ne connaît que C4C ne sait pas bien concevoir l’état cible dans V2. Il vous faut une équipe qui comprend les deux, le système que vous quittez et celui vers lequel vous allez, et, si V2 doit dialoguer avec votre ERP, S/4HANA aussi.

Ce qu’il faut rechercher :

• Une expérience pratique de C4C : ancien modèle de données, particularités des API et schémas d’extension
• Des projets V2 livrés : des environnements V2 en production, pas seulement des formations SAP
• Des compétences d’intégration entre S/4HANA, SAP BTP et systèmes tiers
• Une méthode reproductible plutôt que de l’improvisation
• La conduite du changement, pas seulement la réalisation technique

Chez Spadoom, la même équipe couvre Sales et Service Cloud V2, les extensions BTP et le côté S/4HANA de l’intégration. Pour évaluer les partenaires de manière plus générale, lisez comment choisir un partenaire SAP CX et notre panorama des cabinets de conseil SAP CX en Suisse.

Pourquoi ne pas attendre un trimestre de plus ?

Attendre est une option légitime, puisqu’aucune date de fin n’a été annoncée pour C4C. Mais cela a un coût :

• V2 continue de gagner des fonctionnalités (classification des dossiers par IA, Joule, agents Joule) que C4C ne recevra pas.
• SAP Jam Collaboration, inclus dans l’offre V1, ne sera plus accessible à partir du 1er janvier 2027 (aperçu de la version). Si vous l’utilisez, il vous faut de toute façon une solution de remplacement.
• La dette technique de C4C continue de croître, et avec elle la future migration.

La précipitation reste pire que l’attente. Une stratégie claire, une analyse approfondie et un calendrier réaliste font de la migration une amélioration plutôt qu’un risque. Vérifiez les fonctions dont vous dépendez dans le SAP Roadmap Explorer et dans la documentation de Service Cloud V2, et utilisez notre comparaison V1-V2 pour dimensionner le passage.

Pour un guide détaillé destiné aux équipes de service, consultez notre guide de migration vers Service Cloud V2. Si vous souhaitez un second avis sur votre plan, parlez-en avec notre équipe.

Questions fréquentes

Combien de temps dure une migration de C4C vers V2 ?

Pour une migration conjointe ventes et service de 50 à 200 utilisateurs, prévoyez 6 à 10 mois en cinq phases. Les petits environnements peuvent aboutir en 4 à 6 mois ; les systèmes très personnalisés demandent 10 à 14 mois. La phase qui déborde le plus souvent est la reconstruction des interfaces : prévoyez large.

Pouvons-nous faire fonctionner C4C et V2 en parallèle ?

Oui, et c’est recommandé. Construire V2 pendant que C4C reste en production permet de tester, de valider la migration des données et de former les utilisateurs avant la bascule. Prévoyez au moins 8 à 12 semaines de chevauchement pendant la phase de construction.

Que deviennent nos interfaces C4C ?

Chacune doit être vérifiée et la plupart reconstruites, car les points de terminaison API et le modèle de données de V2 sont différents. Le contenu d’intégration standard de SAP pour S/4HANA et SAP Integration Suite rend souvent les nouvelles interfaces plus simples que les anciennes, surtout si vous remplacez les liaisons point à point par des échanges fondés sur les événements.

Faut-il de nouvelles compétences pour V2 ?

Oui. Les extensions V2 tournent sur SAP BTP avec CAP, Node.js ou Java au lieu du PDI/SDK de C4C. Si votre équipe n’a pas d’expérience BTP, prévoyez une formation ou travaillez avec un partenaire qui a déjà livré des extensions V2.

Existe-t-il une date officielle de fin de vie pour C4C ?

Non. En septembre 2026, SAP n’a annoncé aucune date de fin de maintenance pour C4C, et V1 reçoit toujours des versions régulières. Les nouveautés comme les agents Joule arrivent dans V2, et SAP Jam Collaboration, inclus dans l’offre V1, ne sera plus accessible à partir du 1er janvier 2027. Planifiez le passage à votre rythme, pas sous la pression d’une échéance.