SAP Sales Cloud V2 vs. C4C : ce qui à vraiment changé

Votre C4C fonctionne encore. Mais il tourne au ralenti. SAP a donné la direction sans ambiguïté : Sales Cloud V2 est l’avenir. C4C ne reçoit plus de nouvelles fonctionnalités. La question n’est pas de savoir si vous allez migrer. La question est quand.

Nous avons migré plusieurs organisations de C4C vers V2. Nussbaum et intelligentfood sont en production. Ce que je vous donne ici n’est pas de la théorie. C’est ce que nous avons appris en le faisant.

Vue d’ensemble : même nom, produit différent

Non, pas comme ça : Sales Cloud V2 n’est pas une mise à niveau de C4C. C’est un produit entièrement reconstruit. Autre stack. Autre modèle de données. Autre framework d’extension. SAP a gardé le nom pour signaler la continuité, mais sous le capot, presque tout a changé.

C4C était monolithique. Son propre framework UI, son propre modèle de données, un modèle d’extension propriétaire appelé PDI. Ça fonctionnait. Mais chaque extension signifiait : apprendre les outils de SAP et accepter leurs limites.

V2 est API-first. L’interface repose sur Fiori. Les extensions vivent sur SAP BTP, pas dans l’application. Le modèle de données est plus propre. Les API sont RESTful, bien documentées, conçues pour l’intégration tierce.

C’est la bonne nouvelle. Le revers : la migration est de facto un projet de réimplémentation.

Ce qui est meilleur dans V2

L’interface Fiori est plus rapide, plus cohérente et fonctionne sur mobile. L’UI de C4C paraissait déjà datée en 2023. V2 ressemble à un produit de cette décennie.

Chaque objet dans V2 est accessible via des API REST. Dans C4C, certaines opérations nécessitaient des contournements ou des astuces OData. La couverture API de V2 est complète dès le premier jour.

Au lieu de PDI, V2 utilise SAP BTP pour les extensions. Node.js, Java, CAP, Cloud Foundry. De vrais outils de développement au lieu d’un bac à sable limité. C’est une amélioration massive.

L’IA est nativement intégrée : scoring de leads, insights d’opportunités, forecasting. Chez C4C, ces fonctionnalités avaient été greffées tardivement, et ça se voyait.

La performance est sensiblement meilleure. Temps de chargement des pages, recherche, vues en liste. Pour les équipes qui vivent dans le CRM toute la journée, ça compte.

Et l’intégration S/4HANA est plus étroite et préconfigurée. Comptes, contacts, données produits. C4C nécessitait un middleware pour la plupart des scénarios.

Ce qui est différent (ni meilleur, ni moins bon — simplement différent)

Le modèle de données est plus propre, mais c’est un autre modèle. Les objets personnalisés, champs personnalisés et relations doivent être reconçus. Pas copiés. C’est là que se concentre le plus gros effort de migration.

Les extensions PDI ne se transfèrent pas. Elles seront reconstruites comme applications BTP. BTP est plus puissant et plus maintenable. Mais c’est du développement neuf.

L’interface d’administration est différente. Workflows, règles d’attribution, notifications : tout se configure différemment. Votre équipe d’administration a besoin de formation.

Le reporting passe par SAP Analytics Cloud au lieu des rapports intégrés de C4C. Si vous dépendiez du reporting natif de C4C, prévoyez du temps pour SAC.

Points d’attention

Vérifiez la feuille de route SAP pour vos fonctionnalités spécifiques. V2 comble les écarts avec C4C chaque trimestre, mais certaines fonctionnalités C4C n’ont pas encore d’équivalent V2.

Objets personnalisés : prévoyez une reconception complète. Le framework de V2 est différent. Nous organisons généralement un atelier de découverte rien que pour cela. C’est le plus grand risque dans la plupart des migrations.

Chaque intégration C4C doit être revue. Points de terminaison API, authentification, formats de données. Tout a changé.

Et l’adoption utilisateur : l’interface est suffisamment différente pour nécessiter de la formation. Ne supposez pas que les gens comprendront parce que c’est « le même produit ». Ce n’est pas le même produit.

Ce que nous avons constaté en pratique

Nussbaum : 5 mois de zéro à la production. La visibilité du pipeline était le moteur. Données pipeline en temps réel, accès mobile pour le terrain, forecasting assisté par l’IA. Rien de tout cela ne fonctionnait correctement dans la configuration précédente.

intelligentfood : accent sur le terrain mobile. Nous avons construit des applications BTP sur mesure pour la planification d’itinéraires et la saisie de commandes avec capacité hors-ligne, intégrées à Sales Cloud V2. L’architecture API-first a rendu cela possible sans lutter contre la plateforme.

Les deux projets ont confirmé la même chose : V2 est le meilleur produit. Mais le chemin pour y arriver exige de le traiter comme une réimplémentation. Ceux qui l’abordent comme une montée de version échouent.

Approche de migration qui fonctionne

D’abord la découverte. Cartographiez votre utilisation C4C : fonctionnalités standard, objets personnalisés, intégrations, rapports. Ce qui se transfère conceptuellement, ce qui doit être reconçu.

Puis priorisez. Tout n’a pas besoin d’être en production le premier jour. Les processus de vente centraux d’abord. La complexité par phases.

Maintenez C4C en parallèle jusqu’à ce que V2 soit validé. La migration des données est un flux de travail à part — planifiez-la tôt.

BTP dès le départ. Si vous avez besoin d’extensions, construisez-les sur BTP dès le premier jour. Reproduire les patterns PDI serait la mauvaise voie.

Donnez accès aux utilisateurs clés aux sandboxes V2 tôt. Leurs retours façonnent la configuration.

En conclusion

V2 est objectivement la meilleure plateforme. L’architecture est moderne, les API sont propres, l’extensibilité est réelle. Mais la migration n’est pas gratuite. C’est un projet. Découverte, conception, implémentation, gestion du changement.

Si vous planifiez cela, le passage en vaut la peine. Si vous attendez une mise à jour en un clic, vous serez déçu.

Vous planifiez votre migration C4C vers V2 ? Nous l’avons fait. Contactez-nous.