Migrer votre service desk de C4C vers Service Cloud V2 : cas, SLA et interfaces

SAP Service Cloud V2 n’est pas une mise à niveau de C4C, mais une nouvelle mise en œuvre : autre modèle de données, autres API, autre interface, autre cadre d’extension. Les équipes qui traitent le passage comme un simple changement de version s’en rendent compte en général pendant la migration des données, lorsque des correspondances censées « fonctionner toutes seules » ne fonctionnent pas. 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.

Pour une organisation de taille moyenne (50 à 200 agents de service), comptez 6 à 10 mois entre l’analyse et la mise en production. Cet article décrit les cinq phases que nous utilisons pour les service desks. Les raisons métier du passage sont exposées dans notre stratégie de migration de C4C vers V2, le produit sur la page de la solution SAP Service Cloud V2.

En bref : passer de C4C à Service Cloud V2 est une nouvelle mise en œuvre. Pour une organisation de service de taille moyenne, prévoyez 6 à 10 mois en cinq phases : analyse, refonte des intégrations, construction en parallèle, migration des données, formation et mise en production. Les délais dérapent surtout sur les intégrations et la formation des agents : commencez tôt avec les deux.

Ce qui change vraiment avec V2

SAP a construit Service Cloud V2 sur une nouvelle architecture cloud native au lieu de faire évoluer la base de code de C4C. SAP documente le nouveau produit séparément sur le portail d’aide SAP Service Cloud Version 2, à côté de la documentation SAP Cloud for Customer. Pour la migration, cinq différences comptent :

Plateforme technique. V2 fonctionne sur une autre plateforme, avec sa propre administration, sa propre surveillance et son propre modèle de déploiement. La logique spécifique s’exécute à côté, sur SAP BTP.

Modèle de données. Les tickets à plat deviennent des cas structurés avec des états de cycle de vie, des hiérarchies et un suivi SLA intégré. Les champs et objets métier personnalisés ne sont pas repris automatiquement.

API. V2 a sa propre conception orientée API. Chaque intégration construite sur les services OData de C4C doit être reconstruite sur les API de V2.

Interface. Entièrement nouvelle et basée sur les rôles. Les agents ont besoin d’une formation, pas seulement d’une liste des changements.

Extensibilité. Les extensions PDI/SDK de C4C n’ont pas d’équivalent dans V2 ; leur logique passe dans des services BTP (Node.js, Java, CAP). C’est plus souple, mais cela exige d’autres compétences. Pour une comparaison fonction par fonction, voir SAP Service Cloud V2 vs V1 : ce qui a changé.

Comment se déroule la migration en cinq étapes ?

Étape 1 : analyse et inventaire (2 à 4 semaines)

Recensez tout ce que contient votre environnement C4C : configuration, champs personnalisés, objets métier, intégrations, rapports, règles de workflow et rôles utilisateurs. Classez ensuite chaque élément.

Migrer s’il est nécessaire dans V2 et que vous le reconstruirez dans le nouveau modèle. Repenser s’il est nécessaire mais que V2 le couvre en standard (les règles de routage, par exemple, deviennent un routage par compétences). Abandonner s’il n’est plus utile ou n’était qu’un contournement.

Cette phase évite la cause de retard la plus fréquente : des personnalisations non documentées qui surgissent en plein projet. Si plus personne ne sait pourquoi une règle de workflow existe, l’équipe passe des jours à le découvrir. Sur les projets où l’analyse a été bâclée, c’est exactement ce qui s’est produit.

Étape 2 : refonte des intégrations (4 à 6 semaines)

La plupart des intégrations C4C doivent être entièrement reconstruites. L’avantage : V2 dispose de contenu d’intégration SAP pour S/4HANA, Sales Cloud V2, Commerce Cloud et d’autres produits SAP, si bien que la conception cible est souvent plus simple que l’existant.

Cartographiez chaque point d’intégration, évaluez les alternatives natives de V2 et définissez l’architecture cible avant que quiconque n’écrive du code. C’est aussi le bon moment pour remplacer les connexions point à point par une intégration événementielle via SAP Integration Suite, plus facile à surveiller et à maintenir. Si S/4HANA Public Cloud fait partie de votre paysage, SAP Service Cloud V2 + S/4HANA Public Cloud : du ticket de service à la commande ERP montre le processus cible.

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

Construisez V2 pendant que C4C reste en production. Pas de bascule « big bang ».

Les principaux domaines de configuration sont les états et transitions du cycle de vie des cas, les règles de routage par compétences et les profils des agents, la classification des cas par IA (qui nécessite des cas historiques), la migration et la restructuration de la base de connaissances, ainsi que les définitions SLA et les règles d’escalade.

Vous pouvez ainsi tester, valider les scripts de migration et former les utilisateurs avant la mise en production, pendant que vos agents continuent de travailler dans C4C.

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

Migrez les cas historiques, comptes, contacts et activités avec les outils de migration de SAP. Définissez les règles de correspondance pour le nouveau modèle de données, effectuez plusieurs migrations de test avec des volumes proches de la production et fixez une fenêtre de bascule claire. Le fonctionnement du Data Transfer Tool est décrit dans notre guide pas à pas de la migration avec DTT.

Un détail passe facilement inaperçu : la classification des cas par IA apprend à partir de cas réels. Chargez tôt les cas historiques afin que le modèle dispose de données avant la mise en production ; sinon, vous démarrez sans l’une des principales raisons de passer à V2.

Étape 5 : formation et mise en production (2 à 4 semaines)

La nouvelle interface à elle seule demande une vraie formation, et les changements de processus vont plus loin : routage, visibilité des SLA, accès aux connaissances et fonctions d’IA fonctionnent autrement que ce que vos agents connaissent.

Impliquez les utilisateurs clés dans les tests de recette, formez de manière pratique plutôt qu’avec des présentations et prévoyez 2 à 4 semaines de stabilisation avec accompagnement après la mise en production. Sauter cette étape est le moyen le plus rapide de perdre l’adhésion des agents au nouveau système.

Quels sont les écueils les plus fréquents ?

Presque chaque migration présente les mêmes schémas.

Des personnalisations C4C non documentées. Règles de workflow, champs calculés et correspondances d’intégration jamais consignés causent les plus grands retards. Profitez de la phase d’analyse pour tout documenter, y compris la règle de workflow créée il y a des années par un prédécesseur.

Traiter V2 comme un simple déménagement. Les équipes qui recopient leur configuration C4C à l’identique manquent l’occasion de simplifier. Plusieurs contournements de C4C sont inutiles dans V2, car les hiérarchies de cas et le routage par compétences sont standard.

Sous-estimer le travail d’intégration. Chaque interface C4C change. Dix intégrations signifient dix reconstructions, qui prennent en général plus de temps que prévu.

Négliger la conduite du changement. L’interface demande une formation, tout comme les processus modifiés, le routage, la visibilité des SLA et les fonctions d’IA. Les agents non formés reviennent en quelques jours à des contournements manuels.

Ignorer les prérequis de données pour l’IA. La classification des cas a besoin de données historiques. Chargées trop tard, vous démarrez sans IA.

Pourquoi migrer maintenant plutôt que plus tard ?

L’innovation de SAP pour le service se fait dans V2. En septembre 2026, SAP n’a annoncé aucune date de fin de maintenance pour C4C, et V1 reçoit toujours des versions, mais les nouvelles fonctions comme les agents Joule ciblent V2. Les plans actuels figurent dans le SAP Roadmap Explorer. Chaque trimestre sur C4C ajoute des personnalisations et des intégrations à migrer plus tard, et creuse l’écart avec les fonctions d’IA et le modèle d’extension BTP de V2.

Se précipiter reste pire qu’attendre. Une stratégie claire, une analyse approfondie et un calendrier réaliste font de la migration une amélioration plutôt qu’un risque. Si vous êtes encore en phase de décision, notre assistant de migration V1 vers V2 donne une première estimation, et la comparaison V1 vs V2 approfondit la décision. Lorsque vous êtes prêt à planifier, parlez à notre équipe.

Questions fréquentes

Service Cloud V2 est-il une mise à niveau de V1 ?

Non. Service Cloud V2 est un nouveau produit, avec son propre modèle de données, ses propres API, sa propre interface et son propre modèle d’extension. Les champs personnalisés, intégrations et extensions de C4C (V1) ne sont pas repris : ils doivent être reconstruits ou repensés dans V2.

Combien de temps dure une migration de C4C vers Service Cloud V2 ?

Pour une organisation de taille moyenne (50 à 200 agents de service, complexité d’intégration modérée), prévoyez 6 à 10 mois. Les environnements plus petits, sous 50 agents, peuvent aboutir en 4 à 6 mois ; les paysages fortement personnalisés demandent 10 à 14 mois.

Pouvons-nous exploiter V1 et V2 en parallèle pendant la migration ?

Oui, et c’est recommandé. Construire V2 pendant que C4C reste en production permet de tester, de répéter la migration des données et de former les agents avant la bascule. Nous recommandons une période parallèle d’au moins 8 à 12 semaines.

Que deviennent nos intégrations C4C ?

Chaque intégration C4C doit être revue et la plupart doivent être reconstruites, car les 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 d’autres produits SAP rend souvent la conception cible plus simple que l’original C4C.

Avons-nous besoin de compétences BTP pour V2 ?

Oui. La logique spécifique à V2 s’exécute à côté, sur SAP BTP (Node.js, Java ou SAP CAP), 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à réalisé des extensions V2.