Screen pop natif dans l'Agent Desktop SSCV2 : ce que le PDF ne vous dit pas

En août 2026, nous avons remplacé le panneau latéral personnalisé de notre widget de téléphonie par le screen pop natif de l’Agent Desktop de SAP Sales and Service Cloud V2. Un appel arrive, l’agent voit l’appelant, le bon espace de travail s’ouvre et, quand l’appel se termine, la session se termine aussi. Simple sur le papier. L’intéressant, c’est tout ce que le guide d’intégration public ne dit pas.

En bref : le shell de l’Agent Desktop n’analyse que du XML, ne reconnaît que les actions NOTIFY et END et n’identifie une session que par son ExternalReferenceID (un UUID). Un END termine la session en interne, mais ne retire pas la carte de session. Pour retirer une carte, envoyez un payload OUTBOUND sans élément Action pour la référence de la carte, puis le END immédiatement après. Si vous attendez entre les deux, un onglet reste ouvert.

La première version de cet article conseillait d’« attendre que l’activité d’appel soit trouvable, puis de terminer ». Des mesures sur de vrais appels en septembre 2026 ont montré que c’était faux ; la section sur le timing ci-dessous remplace ce conseil.

Pourquoi l’Agent Desktop ignore-t-il les payloads CTI en JSON ?

Le widget CTI tourne dans un cadre de l’Agent Desktop et dialogue avec le shell par l’API postMessage du navigateur. SAP décrit l’approche par widget dans le guide SAP Service Cloud Version 2 integration with Third-Party CTI Providers. Ce que le guide ne rend pas évident : le shell que nous avons testé n’analyse que du XML. Envoyez le même contenu en JSON, comme certains exemples le suggèrent, et il ne se passe rien. Aucune erreur, aucune ligne de journal. Votre adaptateur se croit intégré ; le shell croit que personne n’a appelé.

Ce silence nous a coûté un après-midi qu’un seul message d’erreur aurait réduit à dix minutes. Une fois la règle connue, le contrat XML est stable et compact. Une notification minimale pour un appel entrant ressemble à ceci :

<payload>
  <Type>CALL</Type>
  <EventType>INBOUND</EventType>
  <Action>NOTIFY</Action>
  <ANI>+41410000000</ANI>
  <ExternalReferenceID>3f2b6c1e-8d4a-4f7e-9a51-2c0d7e9b4a10</ExternalReferenceID>
</payload>

Trois règles que nous avons vérifiées sur le shell :

• Seuls NOTIFY et END sont des actions. Toute autre valeur d’Action, ACCEPT compris, reste vide. Cela ressemble à une limite ; c’est en réalité le levier pour le problème des cartes plus bas.
• EventType est mis en majuscules et repris comme type de session. Les valeurs qui fonctionnent sont INBOUND, OUTBOUND, UPDATE_ACTIVITY, TRANSFER, PUSH, CALLENDED et CALL_ERROR.
• ExternalReferenceID doit être un UUID. C’est la seule clé par laquelle le shell reconnaît une session.

Quel ID doit être identique dans tous les messages CTI ?

Toute la session repose sur cet unique ExternalReferenceID. Il doit être identique dans chaque message de l’appel et dans l’activité téléphonique que le widget crée dans le CRM. Si deux composants génèrent chacun leur propre ID, vous obtenez le pire mode de défaillance qui soit : la partie visible fonctionne, le nettoyage non, et à midi l’agent a un bureau rempli de sessions orphelines.

La discipline des ID est ennuyeuse, et c’est précisément pour cela qu’elle se relâche. Générez l’UUID une seule fois à l’arrivée de l’appel, transmettez-le à chaque composant, ne le régénérez jamais.

Pourquoi les cartes de session du screen pop ne se ferment-elles pas ?

C’est là que le guide vous laisse seul. L’Agent Desktop affiche deux éléments différents, qui disparaissent de manière différente :

	Popover	Carte de session
Où	À côté de la barre CTI réduite	Au-dessus des onglets, même barre ouverte
Visible	Seulement tant que la barre CTI est réduite ; l’ouvrir la ferme	Jusqu’à ce que le shell la filtre par l’ID de référence
Retirée par	Confirmation depuis la vue dock	Un payload qui entre dans le bloc de démarrage de session du shell

Deux comportements nous ont surpris. Un END termine la session dans l’état interne du shell, mais ne retire pas la carte de session. Et la notification n’est jamais acquittée sur END. Les deux doivent être gérés par le widget lui-même.

Le payload qui retire une carte restée affichée est celui-ci, sans élément Action et avec la référence de la carte encore visible :

<payload>
  <Type>CALL</Type>
  <EventType>OUTBOUND</EventType>
  <ANI>+41410000000</ANI>
  <ExternalReferenceID>3f2b6c1e-8d4a-4f7e-9a51-2c0d7e9b4a10</ExternalReferenceID>
</payload>

Pourquoi cela fonctionne : le shell ne retire une carte qu’à l’intérieur du bloc qui traite un démarrage de session, et il saute ce bloc pour NOTIFY, END, UPDATE_ACTIVITY, CALLENDED et CALL_ERROR. Omettre Action est ce qui vous y fait entrer. OUTBOUND est le bon type d’événement, car le shell ne crée alors aucune interaction : aucun nouvel onglet d’espace de travail ne s’ouvre, tandis que le filtre qui retire la carte s’exécute quand même.

Envoyer le démarrage et le END l’un après l’autre

Le revers : ce payload démarre aussi une session. Le retrait de la carte est un effet secondaire du bloc, pas son but. Le END pour la même référence doit donc suivre immédiatement.

Nous l’avons mesuré sur de vrais appels en septembre 2026. Quand plusieurs secondes séparaient le démarrage du END (dans notre première version, parce que le END attendait que l’activité téléphonique soit créée et indexée), le shell ouvrait un onglet de l’Agent Desktop avec un chronomètre en marche et plaçait le badge vert de session sur l’icône CTI. Le END tardif ne le refermait plus. Notre conseil initial, « attendre que l’activité soit trouvable, puis terminer », produisait exactement cela.

La séquence qui fonctionne :

1. Fin de l’appel : créez ou mettez à jour l’activité téléphonique dans le CRM, avec le même ID de référence, à son propre rythme.
2. Retrait de la carte : envoyez le payload OUTBOUND sans Action pour la référence encore affichée.
3. Dans la foulée, envoyez le END pour cette référence.
4. Fermez la notification et le popover depuis le widget, car le shell ne le fait pas.

Quand on s’intègre à une boîte noire, il faut prévoir de l’observation, pas seulement de la lecture. Le contrat sur lequel on livre, c’est celui que l’on mesure.

Comment déployer le screen pop natif ?

Derrière un interrupteur, locataire par locataire. La téléphonie est la seule intégration où chaque agent remarque chaque régression en quelques minutes. Nous avons activé le mode natif un locataire à la fois, et c’est ce qui nous a permis d’apprendre sans que le téléphone du support ne chauffe. Avant d’activer un locataire, nous vérifions quatre points :

• Chaque payload est en XML et aucun chemin de code n’envoie encore du JSON.
• Un UUID par appel, réutilisé dans chaque message et dans l’activité téléphonique.
• Le retrait de la carte et le END partent ensemble, sans attente.
• Un appel de test entrant et sortant ne laisse ni carte, ni notification, ni onglet ouvert.

Le code du shell change avec les versions SAP ; nous refaisons donc cet appel de test après chaque version. Si vous développez vous-même sur l’Agent Desktop et observez un comportement qui contredit cet article, dites-le-nous.

Où cela s’inscrit

Le screen pop est la dernière étape d’une intégration CTI, pas la première. Pour l’architecture qui l’entoure (identification de l’appelant, activités téléphoniques, côté fournisseur de téléphonie), lisez notre guide technique de l’intégration CTI avec SAP Sales Cloud V2. Le widget lui-même est construit comme application personnalisée sur SAP BTP, et la façon dont nous utilisons Sales et Service Cloud V2 dans notre propre entreprise est décrite dans comment nous utilisons nous-mêmes SAP Sales Cloud et Service Cloud.

Le comportement de l’Agent Desktop décrit plus haut ne figure pas dans le guide d’intégration public ; la documentation SAP de Service Cloud V2 couvre l’interface CTI prise en charge. Nous construisons ces intégrations téléphoniques sur SAP BTP dans le cadre de Service Cloud V2. Écrivez-nous.