Les organisations qui tirent le meilleur parti de la migration 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 entreprises d’aborder l’annonce de la fin de vie d’Open CTI : trouver le parcours de migration qui reproduit le plus fidèlement possible le comportement téléphonique existant dans Service Cloud Voice, exécuter la migration avant février 2028, puis reprendre les opérations normales. C’est une réponse raisonnable à une échéance. C’est aussi une occasion importante manquée.
Les organisations que j’ai vues tirer un véritable avantage concurrentiel de cette transition partagent une perspective différente : elles ont utilisé cette migration forcée comme le moment idéal pour répondre à une question qu’elles repoussaient depuis longtemps : où la téléphonie doit-elle réellement s’intégrer dans notre architecture omnicanale Salesforce, et qu’est-ce que le fait de bien faire les choses nous permet de débloquer?
C’est une question bien différente de « comment continuer à faire sonner le téléphone dans Salesforce ». La réponse à la première question rend la réponse à la seconde beaucoup plus précieuse.
L’ère des connecteurs versus l’ère de la plateforme
Open CTI était un pont d’intégration. Un pont bien conçu pour son époque, mais il est maintenant vieillissant et cette époque est révolue. Il permettait aux fournisseurs de CCaaS d’intégrer leurs interfaces de téléphonie logicielle directement dans la console Salesforce sans nécessiter l’installation de logiciels sur les postes de travail, tout en donnant à Salesforce accès aux événements d’appel : sonnerie, réponse, raccrochage, transfert, afin que des automatisations puissent être déclenchées à partir de ces événements.
Ce qu’il ne pouvait pas faire, c’était transformer les données vocales en véritables données CRM de première classe. Les enregistrements d’appels, les transcriptions, les signaux de sentiment et les analyses de silence 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. L’incomplétude était le véritable problème.
Service Cloud Voice change cette réalité 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 est associée à l’enregistrement CRM pendant que l’appel est en cours. Les résumés post-appel sont directement enregistrés dans le dossier. Les données de sentiment, les analyses de silence et les indicateurs acoustiques deviennent des attributs CRM plutôt que des exportations CCaaS.
L’implication pour l’IA est celle qui compte le plus à l’échelle de l’entreprise. Agentforce fonctionne à partir des données Salesforce. Un modèle d’IA qui suggère la meilleure action suivante, rédige des résumés de dossiers ou effectue un routage intelligent basé sur l’historique du client ne peut bien fonctionner que si l’interaction vocale est entièrement représentée dans le modèle de données sur lequel il opère. Sous Open CTI, les données vocales étaient des citoyennes de seconde classe : présentes, mais seulement partiellement. 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 retire l’hypothèse architecturale selon laquelle la voix est une capacité externe connectée au CRM. La nouvelle hypothèse est que la voix fait partie intégrante du CRM.
Ce que SCV offre réellement… et ce qu’il n’offre pas
Une évaluation honnête de Service Cloud Voice 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 de l’entreprise de ce qui fonctionne uniquement 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 cessent de prendre des notes manuellement pendant les appels, 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 s’améliore parce que le système capture tout. Les gains de productivité liés au travail post-appel ne sont pas hypothétiques : les organisations qui déploient des résumés d’appels générés par l’IA rapportent systématiquement des réductions de plus de 50 % du temps consacré à l’After Call Work (ACW). Dans un centre de contact à fort volume, ce temps récupéré représente une capacité opérationnelle significative sans ajouter une seule embauche.
Le modèle de données unifié améliore à la fois les rapports et les performances de l’IA au fil du temps. Les organisations qui ont migré vers SCV et l’utilisent depuis douze mois ou plus constatent que la qualité des recommandations Agentforce s’améliore 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.
Einstein Next Best Action, lorsqu’il a accès à l’interaction vocale en temps réel, fournit des recommandations au moment où elles sont nécessaires plutôt qu’après l’appel. L’agent qui gère une escalade de facturation et voit immédiatement apparaître une offre de rétention pertinente agit plus rapidement et plus efficacement. Les études sur le sujet sont cohérentes : les environnements de bureau unifié pour agents permettent généralement de réduire le temps moyen de traitement de 20 à 30 % et d’augmenter la satisfaction client de 10 à 15 %. Comme la plupart des organisations suivent déjà de près les volumes d’appels et les coûts associés, les calculs de ROI sont relativement simples à effectuer.
Là où une mise en garde s’impose
Les implémentations Bring Your Own Telephony (BYOT) ne se valent pas toutes. La profondeur de l’intégration Service Cloud Voice varie considérablement selon le fournisseur téléphonique, et certains fournisseurs comme Genesys et Amazon ont investi beaucoup plus dans leur connecteur SCV que d’autres. Avant de vous engager dans une stratégie BYOT avec votre fournisseur CCaaS actuel, exigez une démonstration technique basée sur vos cas d’usage réels, particulièrement en ce qui concerne le routage omnicanal, la capture de données post-appel et la compatibilité avec Agentforce. La mention « certifié SCV » dans AppExchange ne vous indique pas à quel point l’intégration est complète.
Gardez également à l’esprit que toute migration s’accompagne d’une baisse temporaire de productivité pendant que les équipes apprennent à utiliser SCV. L’efficacité globale s’améliore avec le temps, mais il faut un certain délai avant que les employés deviennent aussi instinctifs avec une nouvelle interface qu’ils l’étaient avec l’ancienne.
Gardez aussi en tête qu’Agentforce Contact Center est véritablement différent de Service Cloud Voice, et que cette distinction est importante pour votre planification. SCV repose toujours sur un modèle où une plateforme CCaaS externe transporte l’appel et 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’usage admissibles, cela élimine complètement la plateforme CCaaS externe. En mai 2026, la solution n’est pas encore prête pour les opérations complexes de centres de contact à l’échelle de l’entreprise, mais la trajectoire est claire. Votre architecture de migration SCV devrait être conçue de manière à préserver l’option Agentforce Contact Center sans nécessiter une réarchitecture complète lorsque vous serez prêts à l’évaluer sérieusement.
La question de la responsabilité que personne ne pose à ses fournisseurs
C’est ici que la décision d’architecture devient stratégique plutôt que technique.
Votre fournisseur CCaaS et Salesforce vendent désormais tous deux des capacités d’IA, d’analytique, d’optimisation de la main-d’œuvre et d’automatisation. Dans les zones où ces capacités se chevauchent, vous risquez d’acheter deux fois la même chose, de l’implémenter à deux endroits différents et d’obtenir des résultats fragmentés de chaque côté. Le routage est un excellent exemple de cette situation. Les recherches de Gartner estiment que les organisations sans gouvernance centralisée dépensent au minimum 25 % de trop en SaaS à cause de capacités dupliquées.
Avant même votre première discussion avec un fournisseur après votre audit CTI, votre organisation devrait être alignée sur une question fondamentale : que possède chaque couche?
- Évidemment, nous ne sommes pas totalement impartiaux, mais voici le cadre qui a fonctionné pour plusieurs de nos clients. La couche CCaaS possède l’infrastructure qui mérite de transporter l’appel : les trunks SIP de qualité opérateur, la connectivité PSTN, le respect des SLA de disponibilité, la gestion de la qualité vocale, la conformité des enregistrements d’appels et l’authentification STIR/SHAKEN. C’est un travail opérationnel complexe qui exige une expertise, des relations avec les opérateurs et une profondeur d’infrastructure qu’aucun fournisseur CRM ne devrait avoir à reproduire. Dans un centre de contact de 1 000 agents, une seule heure d’interruption peut coûter plus de 100 000 $. Ce sujet est important.
- La couche CRM possède l’intelligence qui donne de la valeur à chaque interaction : le dossier client, l’historique des cas, la logique de routage basée sur le contexte client, l’IA qui résout les problèmes plutôt que de simplement les détourner, la piste d’audit et les données de conformité. Dans un écosystème pleinement connecté (à noter que Data Cloud et d’autres coûts de consommation s’appliqueront), Agentforce peut traiter un remboursement, mettre à jour un droit de service 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 téléphonique.
La jonction entre ces deux couches, le routage omnicanal, est l’endroit où Service Cloud Voice se situe sur le plan architectural. La plateforme CCaaS gère le transport et la mécanique des files d’attente. Le CRM fournit l’intelligence de routage alimentée par les données qui détermine quel agent humain ou agent IA recevra l’interaction selon le contexte du client. C’est ce point d’intégration qui doit être soigneusement conçu, et c’est la principale décision d’architecture dans toute implémentation SCV à l’échelle de l’entreprise.
Tracer cette ligne de responsabilité à l’interne transforme profondément la planification et l’architecture. Les fournisseurs des deux côtés proposeront des fonctionnalités qui débordent sur l’autre couche. Avoir une réponse claire sur ce que vous souhaitez gérer dans chaque système rend l’évaluation de ces propositions beaucoup plus simple et objective.
Un autre élément important à considérer est que vous allez presque certainement modifier le type de données stockées dans Salesforce. Cela soulève des enjeux de conformité et de confidentialité. 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 accessibles à quels humains ou systèmes d’IA? Si vous commencez à planifier votre migration, c’est maintenant qu’il faut avoir ces discussions avec vos équipes juridiques et de conformité.
La séquence de migration qui fonctionne réellement
Pour les grands environnements de centres de contact, les migrations réussies sont progressives et organisées autour du risque, et non de la vitesse.
Commencez par l’audit, pas par l’architecture.L’audit des dépendances CTI décrit dans l’article complémentaire à celui-ci constitue une étape obligatoire. L’architecture ne devrait jamais être conçue avant que vous sachiez exactement ce que vous migrez. Les logiques personnalisées fortement couplées aux événements CTI se comportent différemment dans le modèle de données de Service Cloud Voice, et découvrir cela en pleine migration coûte cher.
Faites un projet pilote avant de déployer à grande échelle.Choisissez une seule équipe ou un seul cas d’usage pour le premier déploiement SCV, idéalement avec des flux d’appels relativement simples, une seule langue et des exigences post-appel limitées. Utilisez ce projet pilote pour valider votre configuration SCV avec de vrais volumes d’appels, identifier les écarts entre le comportement actuel et le comportement SCV, et développer une expertise opérationnelle interne avant le déploiement à grande échelle. Les organisations qui sautent cette étape 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 phase distincte. La tentation est forte d’activer simultanément la transcription en temps réel, Next Best Action et les capacités Agentforce lors de la mise en production de SCV. Résistez à cette tentation. Stabilisez d’abord la fondation téléphonique. Assurez-vous que les données vocales sont correctement enregistrées dans Salesforce, que le routage fonctionne comme prévu et que les rapports sont validés. Tout cela prend du temps. Ensuite seulement, ajoutez les capacités d’IA. Une IA qui s’appuie sur des données téléphoniques mal configurées produit de pires résultats que l’absence totale d’IA.
Le point plus large
Chaque transition technologique majeure crée deux catégories d’organisations : celles qui la traitent comme un simple exercice de conformité et celles qui la considèrent comme un point d’inflexion stratégique.
La fin de vie du CTI impose une migration. Les organisations qui utilisent cette migration forcée pour prendre des décisions réfléchies concernant l’architecture de leur centre de contact, l’emplacement de leurs données vocales, la gouvernance de leur IA et la répartition des responsabilités entre les différentes couches sortiront de cette transition dans une position structurellement différente de celles qui se sont simplement assurées que le téléphone continue de sonner.
Pour ceux d’entre vous qui, comme moi, sont dans l’écosystème depuis un certain temps… repensez à la migration Lightning. Certaines organisations ont effectué un simple lift-and-shift et n’ont tiré aucun bénéfice réel de l’amélioration de l’interface utilisateur. Plus récemment, plusieurs organisations ont effectué une migration lift-and-shift des Workflows vers les Flows. Certaines ont profité de toute la puissance des Flows. D’autres ont simplement remplacé l’ancien par le nouveau sans en retirer de valeur supplémentaire.
L’échéance est fixée à février 2028. La période de planification est maintenant. Alors, quel type d’organisation allez-vous être : celle qui profite pleinement de la puissance de SCV ou celle qui, en 2027, continue de travailler exactement comme elle le faisait en 2015?
Ateko est le seul partenaire dans cette discussion qui intervient des deux côtés de la matrice de responsabilité. Notre pratique Salesforce implémente des architectures post-CTI depuis la sortie de SCV. Bell, notre société mère, est un opérateur national qui déploie depuis des décennies des infrastructures de centres de contact à l’échelle de l’entreprise. Les tuyaux et la plateforme, sous un même toit. Si vous souhaitez obtenir une opinion indépendante avant que les fournisseurs de plateformes commencent à influencer votre architecture, c’est une conversation qui mérite d’avoir lieu avant même la publication de votre appel d’offres.
Si votre organisation réévalue actuellement l’endroit où devraient réellement résider la voix, l’IA et les données clients, le moment est venu d’amorcer cette réflexion avant que votre trajectoire de migration ne soit décidée à votre place.
