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

Un client appelle. Avant même que votre collègue ne dise bonjour, le nom, l’entreprise et les sujets en cours de l’appelant devraient déjà s’afficher à l’écran, et à la fin de l’appel, la conversation devrait être enregistrée dans le CRM sans que personne ne tape quoi que ce soit. C’est cela, le CTI (couplage téléphonie-informatique). Le principe est simple ; la mise en œuvre comporte plus de pièces mobiles que la plupart des gens ne l’imaginent.

SAP Sales Cloud V2 et Service Cloud V2 partagent un Agent Desktop capable d’accueillir le widget CTI d’un fournisseur tiers. SAP décrit ce cadre dans le guide SAP Service Cloud Version 2 integration with Third-Party CTI Providers. Ce que SAP ne fournit pas, c’est la connexion à votre système téléphonique : cette couche, vous la construisez ou vous l’achetez. Nous avons fait les deux, et notre produit Engage CTI en est le résultat. Ce guide décrit l’architecture et les endroits où les projets ont tendance à coincer.

En bref : une intégration CTI avec SAP Sales Cloud V2 comporte quatre éléments : le système téléphonique, un middleware (chez nous sur SAP BTP), les API de V2 pour l’identification de l’appelant et la journalisation des appels, et un widget dans l’Agent Desktop qui communique avec le shell par des messages XML. Les décisions les plus importantes : pousser les événements par WebSocket plutôt que par interrogation périodique, normaliser les numéros de téléphone au format E.164 des deux côtés, tenir un cache de recherche pour que l’affichage contextuel arrive en deux secondes environ, et gérer le consentement à l’enregistrement selon le droit suisse.

Qu’est-ce que le CTI et pourquoi compte-t-il pour Sales Cloud V2 ?

Sans CTI, chaque appel commence par une recherche : qui est-ce, quel compte, y a-t-il un dossier ouvert ? Après l’appel, quelqu’un doit créer l’activité téléphonique à la main, et souvent personne ne le fait. Le CTI supprime ces deux étapes. L’appelant est identifié avant que l’on décroche, et l’activité est journalisée automatiquement.

Une intégration CTI avec SAP Sales Cloud V2 comporte quatre composants.

Système téléphonique. Votre autocommutateur ou votre téléphonie cloud, par exemple Microsoft Teams Phone, un softphone dans le navigateur comme Twilio Voice, ou un autocommutateur SIP. C’est là que les appels ont lieu.

Middleware CTI. Un composant côté serveur qui relie la téléphonie et le CRM. Il traduit les événements téléphoniques (appel entrant, connecté, terminé) en actions CRM (affichage contextuel, création d’activité). Dans notre architecture, il tourne sur SAP BTP.

API de Sales Cloud V2. Les API REST qui permettent de retrouver contacts, clients particuliers et comptes par numéro de téléphone, de lire le contexte du compte et de créer des activités téléphoniques.

Widget dans l’Agent Desktop. Un composant d’interface dans l’Agent Desktop, avec les commandes d’appel (répondre, mettre en attente, transférer, raccrocher) et les informations sur l’appelant. Il s’exécute dans un cadre et communique avec le shell via l’API du navigateur postMessage.

Comment un appel entrant traverse-t-il le système ?

L’objectif pour l’ensemble du parcours, de la sonnerie au contexte de l’appelant à l’écran, est de moins de deux secondes. Au-delà, les utilisateurs perdent confiance.

1. L’appel arrive dans le système téléphonique, qui envoie un événement au middleware par webhook ou WebSocket.
2. Le middleware recherche le numéro de l’appelant dans Sales Cloud V2. Engage CTI cherche sur trois niveaux, la première correspondance l’emporte : contacts, puis clients particuliers, puis comptes.
3. Le middleware pousse le contexte de l’appelant (nom, compte, dossiers ouverts, interactions récentes) vers le widget par WebSocket.
4. Le widget avertit le shell de l’Agent Desktop, qui affiche la fenêtre contextuelle et ouvre la fiche correspondante.
5. À la fin de l’appel, le middleware crée dans V2 une activité téléphonique avec le sens, la durée, les participants et les notes.

Les deux secondes ne sont pas arbitraires. Elles correspondent à peu près au moment où votre collègue demanderait sinon qui est à l’appareil. Un affichage contextuel qui arrive après ce moment est ignoré.

Le côté Agent Desktop de l’étape 4 obéit à des règles que le guide public ne rend pas évidentes : le shell n’analyse que du XML, ne reconnaît que les actions NOTIFY et END et n’identifie une session que par son identifiant de référence. Nous les avons documentées dans l’affichage contextuel natif dans l’Agent Desktop SSCV2.

Quelles sont les décisions techniques clés ?

WebSocket ou interrogation périodique ?

Le widget a besoin des événements d’appel en temps réel. Interroger le middleware chaque seconde crée de la charge et ajoute malgré tout du retard. Une connexion WebSocket livre les événements au moment où ils se produisent.

Nous exploitons sur BTP un serveur WebSocket (Node.js) qui maintient une connexion avec chaque session active de l’Agent Desktop. Lorsqu’un événement arrive du système téléphonique, il est poussé immédiatement vers la connexion de la bonne personne.

Pourquoi pas les Server-Sent Events ? Ils conviennent à un flux dans un seul sens, mais le CTI est bidirectionnel : le widget renvoie des commandes (attente, transfert, fin d’appel). WebSocket gère les deux sens sur une seule connexion.

Comment faire correspondre les numéros de téléphone ?

Cela paraît simple et ne l’est pas. Le même numéro arrive sous la forme +41 44 123 45 67, 044 123 45 67 ou 0041441234567. Le middleware doit normaliser avant de chercher.

Nous normalisons au format international E.164 (+41441234567). Sales Cloud V2 enregistre les numéros tels que les utilisateurs les ont saisis ; les formats dans le CRM sont donc hétérogènes. Normalisez les deux côtés : le numéro entrant et les numéros enregistrés auxquels vous le comparez. Si vous oubliez le côté enregistré, vous obtenez des correspondances qui échouent sans raison apparente, et votre support passera longtemps à les chercher.

Tenez un index de recherche. Interroger l’API de V2 avec des recherches génériques sur les numéros à chaque appel est trop lent pour un budget de deux secondes. Notre middleware tient une table de recherche qui associe les numéros normalisés aux fiches de V2 et la met à jour quand les fiches changent.

Comment fonctionne l’authentification ?

Le widget s’exécute dans la session Agent Desktop de l’utilisateur ; le middleware appelle les API de Sales Cloud V2 pour son compte. Nous utilisons les services d’identité de SAP sur BTP (l’AppRouter avec XSUAA) et le fournisseur d’identité du client, de sorte que personne n’a à se connecter une deuxième fois.

L’authentification entre téléphonie et middleware dépend du fournisseur : clés API pour certains, OAuth pour les services cloud comme Microsoft Teams. Le middleware masque cela derrière une seule interface d’adaptateur : connecter un autre système téléphonique revient à écrire un adaptateur. Le côté V2 reste identique.

Qu’est-ce qui est journalisé à la fin d’un appel ?

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

• Le sens : entrant, sortant, manqué
• La durée : début, fin, temps de conversation
• Les participants : appelant, appelé, éventuelles personnes vers qui l’appel a été transféré
• Le contexte du compte : quel compte ou contact a été identifié
• Les notes : saisies par l’utilisateur dans le widget pendant ou après l’appel
• Le lien vers l’enregistrement : si le système téléphonique enregistre les appels, nous stockons le lien, pas le fichier

L’activité porte le même identifiant de référence que celui utilisé par le widget pour la session dans l’Agent Desktop. Cet identifiant unique doit être identique dans chaque message concernant l’appel ; si deux composants génèrent chacun le leur, la partie visible fonctionne, mais pas le nettoyage.

Quels systèmes téléphoniques peut-on connecter ?

Engage CTI prend aujourd’hui en charge ces configurations :

Téléphonie	Connexion	Remarques
Microsoft Teams Phone	Intégration Teams	Configuration la plus courante : les utilisateurs gardent leur numéro et leur client Teams ; attente, transfert et interception passent par le widget
Appels dans le navigateur (Twilio Voice)	Twilio Voice SDK	Appels dans le navigateur, au sein de l’Agent Desktop, casque à la place du téléphone de bureau
Autocommutateur SIP	Adaptateur fournisseur	L’installation existante se connecte via un adaptateur ; le côté SSCV2 reste identique

D’autres systèmes, par exemple des plateformes de centre de contact dotées de leurs propres API d’événements, se connectent selon le même modèle d’adaptateur. L’effort dépend surtout de la qualité de la documentation du modèle d’événements du fournisseur ; c’est pourquoi nous examinons son API avant de faire une estimation.

Quels sont les pièges les plus courants du CTI ?

La latence. Si l’affichage contextuel apparaît après que l’utilisateur a déjà demandé qui appelle, personne ne s’en servira. Visez moins de deux secondes et testez avec des volumes d’appels réels, pas avec des appels de démonstration.

La qualité des numéros de téléphone. Si le CRM contient des numéros dans quinze formats différents, la correspondance échoue. Nettoyez et normalisez les numéros de tous les comptes et contacts avant la mise en production. Un travail fastidieux, et pas facultatif.

Des connexions WebSocket instables. Les proxys d’entreprise, les VPN et les changements de réseau les interrompent. Reconnectez automatiquement avec un délai exponentiel et affichez clairement dans le widget quand la connexion est coupée, pour que les utilisateurs sachent quand le CTI n’est pas actif.

Plusieurs onglets de navigateur. Les utilisateurs ouvrent plusieurs onglets, mais un seul doit traiter l’appel. Nous utilisons une élection de leader via l’API BroadcastChannel, afin que l’affichage contextuel n’apparaisse que dans un seul onglet. Sans cela, on obtient des fenêtres en double, ou aucune.

Le contexte lors des transferts. Quand un appel est transféré, le contexte doit suivre, et la deuxième personne doit voir le même affichage contextuel. Il faut pour cela suivre les sessions d’appel, et non les tronçons d’appel individuels.

L’enregistrement et la conformité. En Suisse, enregistrer une conversation non publique sans le consentement des participants est une infraction pénale (art. 179ter du Code pénal suisse), avec des exceptions étroites pour certains appels professionnels. Votre solution CTI doit offrir des réglages d’enregistrement configurables, et votre service juridique devrait valider la configuration.

Comment exploiter le CTI sur SAP BTP ?

Le middleware se place à côté du CRM, pas à l’intérieur. Sur SAP BTP, environnement Cloud Foundry, notre architecture se compose :

• d’une application Node.js qui fournit l’API REST et le serveur WebSocket
• d’une base de données pour la table de recherche des numéros et l’état des sessions
• de l’AppRouter avec XSUAA pour l’authentification et la séparation des locataires

Le widget est une petite application web qui se charge dans le cadre de l’Agent Desktop.

En exploitation multilocataire (plusieurs clients sur une même instance du middleware), les événements téléphoniques de chaque client sont acheminés uniquement vers son propre locataire. La séparation des données n’est pas négociable. La façon dont nous construisons en général ce type d’extension sur BTP est décrite dans étendre SAP Sales Cloud V2 avec des applications Cloud Foundry sur BTP.

Où cela tourne en pratique

Chez Nussbaum Matzingen, fabricant suisse d’emballages, Spadoom Engage était l’une des trois applications BTP sur mesure du projet Sales Cloud V2 : les appels entrants sont reconnus et la fiche client correspondante s’ouvre immédiatement. Le projet, de l’absence de CRM à la mise en production en cinq mois, est décrit dans comment Nussbaum a obtenu une visibilité complète sur son pipeline avec SAP Sales Cloud V2. Nous utilisons aussi le même widget dans notre propre CRM.

---

Vous souhaitez relier votre système téléphonique à SAP Sales Cloud V2 ou Service Cloud V2 ? Contactez-nous. Engage CTI existe aussi en produit prêt à l’emploi, avec ses tarifs et un essai gratuit de 10 jours sur spadoom.cloud.

Questions fréquentes

Combien de temps dure une intégration CTI ?

Cela dépend du système téléphonique. Engage CTI fonctionne en SaaS multilocataire sur SAP BTP ; avec Microsoft Teams Phone ou les appels dans le navigateur via Twilio, il n’y a donc rien à installer : nous configurons votre environnement et les utilisateurs téléphonent depuis l’Agent Desktop. Un développement sur mesure ou un nouvel adaptateur pour un autocommutateur prend plus de temps ; l’effort dépend surtout de l’API d’événements du fournisseur, que nous examinons avant toute estimation.

Le CTI fonctionne-t-il avec Sales Cloud V2 sur mobile ?

Le widget CTI est conçu pour l’Agent Desktop dans le navigateur, là où les utilisateurs téléphonent depuis leur poste de travail. Les utilisateurs mobiles voient les activités téléphoniques journalisées par le CTI, car ce sont des activités standard de V2. Si une équipe terrain a besoin de la téléphonie directement sur le smartphone, elle peut être intégrée à une application mobile sur BTP, comme nous l’avons fait avec la téléphonie intégrée aux applications de vente terrain d’intelligentfood.

Que se passe-t-il si le middleware CTI tombe en panne ?

Les appels continuent de fonctionner, car le système téléphonique ne dépend pas du middleware. Les utilisateurs n’ont simplement plus d’affichage contextuel ni de journalisation automatique jusqu’à son redémarrage. Sur BTP Cloud Foundry, le middleware tourne avec des redémarrages automatiques et des contrôles de santé, et la table de recherche est stockée dans une base de données : un redémarrage n’oblige donc pas à reconstruire l’index.

Le CTI supporte-t-il des volumes d’appels élevés ?

Oui, si la conception est bonne. Le middleware Engage CTI sur SAP BTP gère plus de 500 connexions WebSocket simultanées et traite un événement d’appel en moins de 50 ms (Engage CTI). Pour les centres de contact plus importants, il évolue horizontalement sur Cloud Foundry, avec une affinité de session pour que chaque connexion WebSocket reste sur son instance.

Les enregistrements d’appels sont-ils stockés dans Sales Cloud V2 ?

Non, et ils ne devraient pas l’être. Les enregistrements restent dans le stockage du système téléphonique ; nous ne stockons que le lien sur l’activité téléphonique dans V2. Cela évite des coûts de stockage, garde les données audio sensibles dans l’environnement conforme du système téléphonique et respecte les exigences de résidence des données. Les utilisateurs ouvrent l’enregistrement avec le lecteur du système téléphonique.