Les organisations qui tirent le meilleur parti de la migration de CTI vers SCV sont celles qui ont compris, avant même de commencer, qu’elles prenaient une décision d’architecture, et non qu’elles effectuaient simplement une mise à niveau technologique.
Il existe une façon courante pour les grandes organisations d’aborder l’annonce du retrait d’Open CTI: trouver le parcours de migration qui reproduit le plus fidèlement le fonctionnement actuel de leur téléphonie dans Service Cloud Voice, effectuer la migration avant février 2028, puis reprendre les activités comme si de rien n’était. C’est une réaction raisonnable face à une échéance. C’est aussi une occasion importante qui risque d’être manquée.
Les organisations que j’ai vues tirer un véritable avantage concurrentiel de cette transition ont adopté une approche différente : elles ont profité de cette migration imposée pour répondre à une question qu’elles repoussaient depuis longtemps : où la téléphonie devrait-elle réellement s’intégrer dans notre architecture omnicanale Salesforce, et quelles possibilités cela ouvre-t-il lorsqu’elle est bien intégrée?
C’est une question bien différente de : « Comment continuer à gérer les appels dans Salesforce? » La réponse à la première rend la réponse à la seconde beaucoup plus pertinente.
L’ère des connecteurs versus l’ère des plateformes
Open CTI était un pont d’intégration. Il était bien conçu pour son époque, mais cette époque est révolue. Il permettait aux fournisseurs de CCaaS d’intégrer l’interface de leur téléphone logiciel directement dans la console Salesforce, sans nécessiter l’installation d’un logiciel sur les postes de travail. Il donnait également à Salesforce accès aux événements liés aux appels — sonnerie, réponse, fin d’appel, transfert — afin de déclencher des automatisations en fonction de ces événements.
En revanche, il ne permettait pas de faire des données vocales des données CRM de première classe. Les enregistrements d’appels, les transcriptions, les indicateurs de sentiment et l’analyse des silences demeuraient dans la plateforme CCaaS. Les intégrer à Salesforce nécessitait un important travail d’extraction, de transformation et de synchronisation. La latence était acceptable. Le véritable problème, c’était le manque d’exhaustivité.
Service Cloud Voice change la donne au niveau de la couche de données, et pas seulement de l’interface utilisateur. Avec SCV, chaque interaction vocale génère nativement un objet Voice Call dans Salesforce. La transcription en temps réel s’ajoute au dossier CRM pendant que l’appel est en cours. Les résumés d’appel sont enregistrés directement dans le dossier. Les données de sentiment, l’analyse des silences et les indicateurs acoustiques deviennent des attributs CRM, plutôt que de simples exportations provenant de la plateforme CCaaS.
L’incidence sur l’IA est l’élément le plus important à l’échelle de l’entreprise. Agentforce fonctionne à partir des données Salesforce. Un modèle d’IA qui propose la meilleure action suivante (Next Best Action), rédige des résumés de dossiers ou effectue un routage intelligent selon l’historique du client ne peut le faire efficacement que si l’interaction vocale est entièrement représentée dans le modèle de données sur lequel il s’appuie. Avec Open CTI, les données vocales étaient des données de second ordre : elles étaient présentes, mais seulement en partie. Avec SCV, elles deviennent des données de première classe dès leur ingestion.
C’est pourquoi Salesforce ne retire pas simplement une API. L’entreprise abandonne l’hypothèse architecturale selon laquelle la voix est une capacité externe connectée au CRM. Désormais, la voix fait partie intégrante du CRM.
Ce que SCV offre réellement… et ce qu’il n’offre pas
Évaluer Service Cloud Voice de façon objective exige de distinguer ce qui est disponible aujourd’hui de ce qui figure sur la feuille de route, ainsi que ce qui fonctionne à l’échelle d’une grande entreprise de ce qui fonctionne seulement dans un environnement de démonstration.
Ce qui est prêt pour la production et apporte une réelle valeur :
La transcription en temps réel est le bénéfice opérationnel le plus immédiat que nos clients constatent. Lorsque les agents n’ont plus à prendre des notes manuellement pendant un appel, deux choses se produisent : la qualité de la conversation s’améliore parce que l’agent est pleinement présent, et la qualité de la documentation augmente parce que le système capture l’ensemble de l’échange. Les gains de productivité liés au travail après appel (After Call Work – ACW) ne sont pas théoriques : les organisations qui déploient des résumés d’appels générés par l’IA rapportent régulièrement une réduction de l’ACW de 50 % ou plus. Dans un centre de contact à fort volume, ce temps récupéré représente une capacité réelle, sans avoir à embaucher une seule personne de plus.
Le modèle de données unifié permet également d’obtenir de meilleurs rapports et d’améliorer les performances de l’IA au fil du temps. Les organisations qui utilisent SCV depuis douze mois ou plus constatent que les recommandations d’Agentforce gagnent en pertinence parce que les données d’entraînement sont plus complètes. Les interactions vocales qui existaient auparavant sous forme d’exportations CCaaS — résumées, retardées et partiellement structurées — deviennent désormais des enregistrements complets et fidèles.
Lorsqu’Einstein Next Best Action a accès à l’interaction vocale en temps réel, il peut proposer des recommandations au moment où elles sont utiles, plutôt qu’après l’appel. Un agent qui traite une demande liée à la facturation et voit immédiatement apparaître une offre de fidélisation pertinente agit plus rapidement et plus efficacement. Les études sont constantes à ce sujet : les environnements de travail unifiés pour les agents permettent de réduire de 20 à 30 % le temps moyen de traitement des appels et d’améliorer de 10 à 15 % la satisfaction client. Comme la plupart des organisations suivent de près le volume d’appels et les coûts, le calcul du retour sur investissement (ROI) est relativement simple.
Là où certaines nuances s’imposent :
Les déploiements Bring Your Own Telephony (BYOT) ne se valent pas tous. Le niveau d’intégration de Service Cloud Voice varie considérablement d’un fournisseur de téléphonie à l’autre. Certains fournisseurs, comme Genesys et Amazon, ont investi beaucoup plus que d’autres dans leur connecteur SCV. Avant de vous engager dans une approche BYOT avec votre fournisseur CCaaS actuel, exigez une démonstration technique basée sur vos cas d’utilisation réels, en particulier le routage omnicanal, la capture des données après appel et la compatibilité avec Agentforce. La mention « SCV-certified » sur AppExchange ne vous indique pas à quel point l’intégration est complète.
Gardez également à l’esprit qu’une migration entraînera inévitablement une baisse temporaire de la productivité pendant que les équipes apprendront à utiliser SCV. L’efficacité globale s’améliorera avec le temps, mais les employés auront besoin d’une période d’adaptation avant d’être aussi à l’aise avec une nouvelle interface qu’ils le sont avec celle qu’ils utilisent actuellement.
N’oubliez pas non plus qu’Agentforce Contact Center est fondamentalement différent de Service Cloud Voice, et cette distinction est importante dans votre planification de migration. Avec SCV, le modèle demeure le même : une plateforme CCaaS externe prend en charge les appels, tandis que Salesforce reçoit les données. Agentforce Contact Center, lancé en mars 2026, exécute l’ensemble de la pile téléphonique directement dans Salesforce, sur Hyperforce. Pour certains cas d’utilisation, il élimine complètement le besoin d’une plateforme CCaaS externe. En date de mai 2026, la solution n’est toutefois pas encore adaptée aux centres de contact complexes à l’échelle de l’entreprise, mais la direction que prend la plateforme est claire. Votre architecture de migration vers SCV devrait donc être conçue de manière à vous offrir la possibilité d’adopter Agentforce Contact Center plus tard, sans devoir revoir entièrement votre architecture lorsque vous serez prêt à l’évaluer sérieusement.
La question de la responsabilité que personne ne pose à ses fournisseurs
C’est à ce moment que la décision d’architecture devient stratégique plutôt que technique.
Aujourd’hui, votre fournisseur de CCaaS et Salesforce vendent tous deux des capacités d’IA, d’analytique, d’optimisation des effectifs et d’automatisation. Là où ces capacités se chevauchent, vous risquez d’acheter la même fonctionnalité deux fois, de l’implanter à deux endroits différents et d’obtenir des résultats fragmentés de chaque côté. Le routage en est un excellent exemple. Selon Gartner, les organisations qui ne disposent pas d’une gouvernance centralisée dépensent au minimum 25 % de trop en solutions SaaS en raison de fonctionnalités en double.
Avant même votre première discussion avec un fournisseur après votre audit CTI, votre organisation devrait s’entendre à l’interne sur une question essentielle : à qui appartient quoi?
- Évidemment, nous ne sommes pas impartiaux, mais voici le cadre que nous avons vu fonctionner chez plusieurs clients. La couche CCaaS est responsable de l’infrastructure qui permet d’acheminer les appels : les liaisons SIP de niveau opérateur, la connectivité au RTPC (PSTN), le respect des ententes de niveau de service (SLA), la gestion de la qualité vocale, la conformité des enregistrements d’appels et l’authentification STIR/SHAKEN. Il s’agit d’un travail opérationnel complexe qui exige une expertise spécialisée, des relations avec les opérateurs et une infrastructure robuste qu’aucun fournisseur de CRM ne devrait avoir à reproduire. Dans un centre de contact comptant 1 000 agents, une seule heure d’interruption peut coûter plus de 100 000 $. Ce n’est pas un détail.
- La couche CRM, quant à elle, est responsable de l’intelligence qui donne de la valeur à chaque interaction : le dossier client, l’historique des cas, la logique de routage fondée sur le contexte du client, une IA qui résout les demandes plutôt que de simplement les rediriger, la piste d’audit et les données de conformité. Dans un écosystème entièrement connecté (à noter que Data Cloud et d’autres coûts liés à la consommation s’appliquent), Agentforce peut traiter un remboursement, mettre à jour une admissibilité ou planifier l’intervention d’un technicien, mais uniquement parce qu’il a accès aux données et aux règles d’affaires qui autorisent ces actions. Ces données résident dans Salesforce (souvent dans Data Cloud), et non dans la plateforme de téléphonie.
Le point de jonction entre ces deux couches, soit le routage omnicanal, est l’endroit où Service Cloud Voice s’intègre sur le plan architectural. La plateforme CCaaS gère le transport des appels et les mécanismes de mise en file d’attente. Le CRM fournit l’intelligence de routage fondée sur les données qui détermine quel agent — humain ou IA — recevra l’interaction en fonction du contexte du client. C’est ce point d’intégration qui doit être conçu avec soin, et il constitue la principale décision de conception dans toute implantation de SCV à l’échelle de l’entreprise.
Définir clairement cette répartition des responsabilités à l’interne transforme considérablement la façon d’aborder la planification et l’architecture. Les fournisseurs des deux côtés vous proposeront des fonctionnalités qui empiètent sur l’autre couche. Si vous savez précisément ce que vous souhaitez gérer dans chaque système, il devient beaucoup plus facile d’évaluer ces propositions selon leur valeur réelle plutôt que selon le pouvoir de persuasion du fournisseur.
Un autre aspect important à considérer est que vous allez très probablement modifier les données stockées dans Salesforce. Cela soulève des enjeux de conformité et de protection des renseignements personnels. Par exemple, si une transcription d’appel contient des informations permettant de valider l’identité d’une personne ou des renseignements liés à sa santé, quelle quantité de ces données souhaitez-vous conserver dans Salesforce, pendant combien de temps et à quelles personnes — ou quelles IA — seront-elles accessibles? Au moment de planifier votre migration, c’est le bon moment pour avoir ces discussions avec vos équipes des affaires juridiques et de la conformité.
Une séquence de migration qui fonctionne réellement
Pour les grands centres de contact, une migration réussie est réalisée par étapes et planifiée en fonction des risques, et non de la rapidité.
Commencez par l’audit, pas par l’architecture. L’audit des dépendances CTI décrit dans l’article complémentaire à celui-ci (https://ateko.com/en/blog/salesforce-cti-to-scv-deadline-nobody-is-talking-about-enough/) constitue la première étape incontournable. Vous ne devriez pas concevoir votre architecture avant de savoir exactement ce que vous devez migrer. Les logiques personnalisées étroitement liées aux événements CTI se comportent différemment dans le modèle de données de Service Cloud Voice, et découvrir ces différences en plein milieu de la migration peut coûter très cher.
Réalisez un projet pilote avant de passer à grande échelle. Choisissez une seule équipe ou un seul cas d’utilisation pour votre premier déploiement de SCV, idéalement avec des flux d’appels relativement simples, une seule langue et des exigences post-appel limitées. Servez-vous de ce projet pilote pour valider votre configuration SCV dans des conditions réelles, repérer les écarts entre le fonctionnement actuel et celui de SCV, puis développer l’expertise opérationnelle de vos équipes avant le déploiement à grande échelle. Les organisations qui sautent l’étape du projet pilote et passent directement à un déploiement complet enregistrent systématiquement des coûts plus élevés et des périodes de stabilisation plus longues.
Traitez l’activation de l’IA comme une étape distincte. Il est tentant d’activer simultanément la transcription en temps réel, Einstein Next Best Action et les capacités d’Agentforce au moment de la mise en production de SCV. Résistez à cette tentation. Stabilisez d’abord votre fondation téléphonique. Assurez-vous que les données vocales sont correctement enregistrées dans Salesforce, que le routage des appels fonctionne comme prévu et que vos rapports sont validés — tout cela demande du temps. Ensuite seulement, ajoutez les fonctionnalités d’IA sur une base solide. Une IA qui s’appuie sur des données téléphoniques mal configurées produit de moins bons résultats que l’absence d’IA.
Le véritable enjeu
Chaque grande transition technologique crée deux catégories d’organisations : celles qui la considèrent comme un simple exercice de conformité et celles qui y voient un véritable tournant stratégique. Le retrait de CTI impose une migration. Les organisations qui profiteront de cette migration forcée pour prendre des décisions réfléchies concernant l’architecture de leur centre de contact, l’emplacement des données vocales, la gouvernance de l’IA et la répartition des responsabilités entre les différentes couches sortiront de cette transition dans une position fondamentalement différente de celles qui se seront contentées de maintenir leur système téléphonique en fonction.
Pour ceux qui, comme moi, sont dans l’écosystème depuis… un certain temps, repensez à la migration vers Lightning. Certaines organisations ont simplement effectué un « lift and shift » sans réellement tirer parti de la nouvelle interface utilisateur. Plus récemment, plusieurs ont migré de Workflows vers Flows de la même façon. Certaines ont su exploiter toute la puissance des Flows, tandis que d’autres se sont contentées d’un simple remplacement, sans obtenir de valeur supplémentaire.
L’échéance est fixée à février 2028. La période de planification, c’est maintenant. Alors, quel type d’organisation serez-vous? Celle qui profitera pleinement des nouvelles capacités de SCV, ou celle qui continuera en 2027 à travailler exactement comme elle le faisait en 2015?
Ateko est le seul partenaire de cette discussion qui intervient des deux côtés de la matrice de responsabilités. Notre pratique Salesforce conçoit des architectures post-CTI depuis le lancement de SCV. Bell, notre société mère, est un fournisseur national de services de télécommunications qui déploie depuis des décennies des infrastructures de centres de contact à l’échelle de l’entreprise. Les infrastructures réseau et la plateforme sont réunies sous un même toit. Si vous souhaitez obtenir un avis indépendant avant que les fournisseurs de plateformes commencent à influencer votre architecture, c’est une conversation qui mérite d’avoir lieu avant le lancement de votre appel d’offres (RFP).
Si votre organisation revoit actuellement l’emplacement idéal pour héberger la voix, l’IA et les données clients, c’est le moment d’entamer cette réflexion avant que votre stratégie de migration ne soit choisie à votre place.
