Intégration CTI avec SAP Sales Cloud V2 : guide technique

Votre équipe commerciale décroche le téléphone. Le nom, l’entreprise et la dernière interaction de l’appelant devraient apparaître à l’écran avant même qu’il ne dise un mot. C’est le CTI — Couplage Téléphonie-Informatique. Prima vista, un concept simple. Dans la mise en oeuvre : exigeant.

SAP Sales Cloud V2 ne fournit pas d’adaptateur CTI intégré. Il met à disposition les API et le shell d’interface. L’intégration, vous la construisez (ou l’achetez) vous-même. Nous avons fait les deux — notre produit Engage CTI gère cela pour plusieurs clients. Voici l’architecture et les pièges concrets.

Vue d’ensemble de l’architecture

Une intégration CTI avec Sales Cloud V2 se compose de quatre éléments.

Le fournisseur de téléphonie : votre autocommutateur ou système de téléphonie cloud — Cisco, Genesys, RingCentral, Teams Phone ou un fournisseur basé sur SIP. C’est là que les appels se produisent réellement.

Le middleware CTI : un composant côté serveur qui fait le pont entre le fournisseur de téléphonie et Sales Cloud V2. Il traduit les événements téléphoniques (appel entrant, appel connecté, appel terminé) en actions CRM (affichage contextuel, création d’activité, journalisation d’appel). Dans notre architecture, il s’exécute sur SAP BTP.

Les API Sales Cloud V2 : API REST pour rechercher des contacts par numéro de téléphone, créer des activités d’appel et récupérer le contexte du compte. La conception API-first de V2 rend cela propre.

Le widget côté client : un composant d’interface intégré dans le shell Sales Cloud V2 qui affiche les contrôles d’appel (répondre, mettre en attente, transférer, raccrocher) et les informations de l’appelant. Ce widget fonctionne comme extension side-by-side via le framework de plug-in du shell V2.

Flux de données pour un appel entrant

1. L’appel arrive au système de téléphonie. L’autocommutateur envoie un événement d’appel au middleware CTI via WebSocket ou webhook.
2. Le middleware extrait le numéro de téléphone de l’appelant et interroge l’API Sales Cloud V2 : GET /sap/c4c/api/v1/phone-call-collection?$filter=phone eq '{number}'. (En pratique, nous recherchons à travers les comptes, les contacts et les clients individuels.)
3. Si une correspondance est trouvée, le middleware pousse le contexte de l’appelant (nom, compte, opportunités ouvertes, interactions récentes) vers le widget côté client via WebSocket.
4. Le widget déclenche un affichage contextuel — naviguant Sales Cloud V2 vers l’enregistrement du contact ou du compte correspondant.
5. Lorsque l’appel se termine, le middleware crée une activité d’appel téléphonique dans V2 avec la durée, la direction, les participants et les notes.

L’ensemble du flux prend moins de 2 secondes entre la sonnerie et l’affichage contextuel. Au-delà, la confiance des utilisateurs dans le système s’effrite.

Décisions techniques clés

WebSocket vs. interrogation périodique

Le widget côté client a besoin d’événements d’appel en temps réel. Interroger le middleware chaque seconde crée une charge inutile et ajoute de la latence. Les connexions WebSocket délivrent les événements en millisecondes.

Nous utilisons un serveur WebSocket sur BTP (Node.js) qui maintient des connexions persistantes avec chaque session active de Sales Cloud V2. Lorsqu’un événement d’appel arrive du système de téléphonie, il est poussé instantanément vers la bonne connexion WebSocket.

Correspondance des numéros de téléphone

Cela semble simple. Ça ne l’est pas. Les numéros de téléphone se présentent sous de nombreux formats : +41 44 123 45 67, 044 123 45 67, 0041441234567. Votre middleware doit normaliser les numéros avant de rechercher.

Nous normalisons au format E.164 (+41441234567) et recherchons par rapport à un champ normalisé dans V2. Sales Cloud V2 stocke les numéros de téléphone tels que saisis par les utilisateurs — dans des formats incohérents. Notre middleware gère la normalisation des deux côtés : le numéro de l’appelant entrant et les numéros stockés dans V2 lors de la comparaison.

Conseil pratique : construisez un index de numéros de téléphone. Interroger l’API de V2 avec des recherches génériques à chaque appel est lent. Nous maintenons un cache de recherche léger (Redis sur BTP) qui mappe les numéros de téléphone normalisés aux identifiants d’entités V2. Le cache se rafraîchit toutes les 15 minutes et lors des événements de mise à jour d’entité.

Authentification

Le middleware doit appeler les API Sales Cloud V2 au nom des utilisateurs. Nous utilisons OAuth 2.0 avec SAP IAS (Identity Authentication Service) comme fournisseur d’identité. Le widget gère le flux OAuth initial ; le middleware utilise des jetons de rafraîchissement pour les appels API.

Pour l’authentification téléphonie-middleware, cela dépend du fournisseur. Cisco et Genesys utilisent des clés API. Les fournisseurs cloud comme RingCentral et Teams utilisent OAuth. Le middleware abstrait cela — ajouter un nouveau fournisseur de téléphonie signifie implémenter une interface d’adaptateur.

Journalisation des appels

Chaque appel crée une activité d’appel téléphonique dans Sales Cloud V2. Nous journalisons :

• Direction : entrant, sortant, manqué
• Durée : heure de début, heure de fin, temps de conversation
• Participants : appelant, appelé, parties transférées
• Contexte du compte : quel compte/contact a été identifié
• Notes : les commerciaux peuvent ajouter des notes pendant ou après l’appel via le widget
• Lien d’enregistrement : si le système de téléphonie enregistre les appels, nous stockons l’URL de l’enregistrement (pas le fichier)

L’activité est créée via POST /sap/c4c/api/v1/phone-call-collection. L’API de V2 accepte tous ces champs nativement — aucun objet personnalisé n’est nécessaire.

Fournisseurs de téléphonie supportés

Notre produit Engage CTI supporte actuellement :

L’ajout d’un nouveau fournisseur prend typiquement 2 à 4 semaines de développement.

Pièges courants

La latence tue l’adoption. Si l’affichage contextuel apparaît après que le commercial a déjà demandé « qui est à l’appareil ? », personne ne l’utilisera. Visez moins de 2 secondes. Testez avec des volumes d’appels réels, pas seulement en démo.

Qualité des données de numéros de téléphone. Si vos données V2 contiennent des numéros de téléphone dans 15 formats différents, la correspondance échoue. Nettoyez vos données avant la mise en production. Exécutez un script de normalisation sur tous les comptes et contacts.

Stabilité des WebSocket. Les connexions WebSocket se coupent. Les proxies d’entreprise, les VPN et les commutateurs réseau les interrompent. Implémentez une reconnexion automatique avec un backoff exponentiel. Affichez un indicateur « déconnecté » clair dans le widget pour que les commerciaux sachent quand le CTI n’est pas actif.

Gestion multi-onglets. Les commerciaux ouvrent plusieurs onglets de navigateur. Le widget CTI ne doit être actif que dans un seul onglet. Nous utilisons un modèle d’élection de leader (API BroadcastChannel) pour garantir que l’affichage contextuel se produit dans exactement un onglet.

Contexte de transfert d’appel. Lorsqu’un appel est transféré, le contexte doit suivre. Le deuxième agent doit voir le même affichage contextuel. Cela nécessite de suivre les sessions d’appel, pas seulement les segments d’appel individuels.

Conformité. L’enregistrement et la journalisation des appels sont soumis à des exigences légales qui varient selon la juridiction. En Suisse, les deux parties doivent consentir à l’enregistrement. Votre solution CTI a besoin de contrôles d’enregistrement configurables.

Déploiement sur BTP

Notre middleware CTI s’exécute sur SAP BTP Cloud Foundry :

• Application Node.js avec Express pour l’API REST et le serveur WebSocket
• Redis pour le cache de recherche de numéros de téléphone et la gestion des sessions
• SAP Integration Suite pour la livraison fiable des événements depuis les systèmes de téléphonie on-premise
• XSUAA pour l’authentification et l’isolation des tenants

Le widget est déployé comme plug-in du shell Sales Cloud V2 — une petite application JavaScript qui se charge dans le cadre du shell V2.

Pour les déploiements multi-tenants (plusieurs clients sur une seule instance de middleware), nous utilisons l’isolation des tenants XSUAA. Les événements téléphoniques de chaque client sont acheminés vers leur tenant uniquement.

Pour commencer

L’intégration CTI est un projet à fort impact. Quand cela fonctionne, cela transforme la manière dont votre équipe commerciale gère chaque contact téléphonique. La mise en oeuvre technique est faisable si vous planifiez les détails : qualité des numéros de téléphone, objectifs de latence et fiabilité des WebSocket.

Prêt à connecter votre système téléphonique à SAP Sales Cloud V2 ? Notre produit Engage CTI est prêt pour la production. Contactez-nous.