Salesforce met fin à Open CTI. Si votre organisation l’utilise dans le cadre de sa stratégie voix/téléphonie, la fenêtre de planification est ouverte… et plus courte qu’elle n’en a l’air.
En février 2026, Salesforce a annoncé que Open CTI, le populaire mais très vieillissant framework d’intégration téléphonique basé sur JavaScript qui alimente discrètement les intégrations vocales Salesforce depuis 2012, sera officiellement retiré le 28 février 2028. Après cette date, les implémentations Open CTI ne fonctionneront plus. Pas « pourraient subir une baisse de performance ». Pas « entreront dans un état non pris en charge ». Elles ne fonctionneront plus.
Si votre organisation compte des dizaines, des centaines… voire des milliers d’utilisateurs Salesforce qui utilisent le CTI pour intégrer la téléphonie à Salesforce (par exemple votre équipe de ventes sortantes ou un centre de contact entrant), cette annonce vous concerne probablement directement, et il y a de fortes chances qu’elle n’ait pas encore été traitée avec l’urgence qu’elle mérite.
C’est précisément l’objectif de cet article : aider à combler cet écart.
Ce qu’est réellement Salesforce Open CTI — et pourquoi c’est important en entreprise
Open CTI est le mécanisme qui permet à votre plateforme téléphonique de vivre à l’intérieur de Salesforce. Chaque fenêtre contextuelle qui s’affiche lorsqu’un appel arrive, chaque fonction click-to-dial utilisée par vos agents, chaque journal d’appel enregistré automatiquement dans la fiche contact : tout cela repose probablement sur Open CTI.
Si vous utilisez Genesys, Five9, Amazon Connect, NICE, Talkdesk, Vonage, Cisco ou la plupart des autres plateformes CCaaS dans un environnement Salesforce et que vous n’avez pas SCV, Open CTI est probablement l’infrastructure invisible qui soutient le tout.
Open CTI est maintenant en mode maintenance uniquement. Salesforce ne développe plus de nouvelles fonctionnalités pour cette technologie. Les nouvelles organisations Agentforce Service ne peuvent même plus l’activer. Le framework arrive en fin de vie, et son remplaçant, Service Cloud Voice, repose sur une architecture différente à plusieurs niveaux importants.
Le nombre de déploiements touchés est énorme, puisque Open CTI est devenu un standard il y a plus de dix ans. Ça fonctionnait. Les organisations ont bâti autour de cette technologie. Dispositions personnalisées de softphone, logique de screen pop liée aux IVR, automatisations post-appel, pipelines de rapports : quatorze années d’intégrations construites sur un framework aujourd’hui dans son dernier chapitre.
Pourquoi 24 mois, ce n’est pas aussi généreux que ça en a l’air
Le réflexe naturel est de voir une échéance en 2028 comme un problème à régler en 2027. C’est précisément là le risque.
Les migrations de centres de contact en entreprise impliquent des cycles d’approvisionnement qui réduisent considérablement le temps réellement disponible. Une séquence réaliste ressemble à ceci : trois à six mois pour l’évaluation des fournisseurs et les décisions d’architecture, deux à quatre mois pour la conception et la configuration, puis six à dix-huit mois pour un déploiement progressif dans des environnements complexes multi-CCaaS ou multi-régions. Ajoutez à cela la gestion du changement et la reformation d’agents à grande échelle, et vous obtenez facilement un minimum de douze mois entre la décision et la mise en production, en supposant qu’aucune complication classique de déploiement en entreprise ne survienne.
Les organisations qui commenceront à planifier en 2027 effectueront leurs migrations sous pression, en compétition pour les ressources partenaires pendant une période où la demande sera à son maximum dans tout l’écosystème, tout en prenant des décisions d’architecture dans des délais compressés. Les organisations qui commencent maintenant bénéficient d’un avantage que celles de 2027 n’auront pas : le luxe d’en faire une véritable décision d’architecture plutôt qu’un exercice de gestion de crise.
Il existe un deuxième risque dont on parle moins. À mesure que l’échéance approchera, les partenaires Salesforce ayant une réelle expertise en Service Cloud Voice auront des calendriers complets. Les organisations qui bougent tôt obtiennent des échanges stratégiques réfléchis. Celles qui attendent trop tard héritent des ressources restantes.
Les trois chemins possibles
Passer d’Open CTI à Service Cloud Voice n’est pas une seule trajectoire de migration. Il s’agit plutôt d’une catégorie architecturale comprenant trois modèles de déploiement distincts, et le choix entre eux est déterminant à l’échelle entreprise.
Service Cloud Voice avec Amazon Connect (bundle natif) Il s’agit de l’option privilégiée par Salesforce et de la solution la plus intégrée. Amazon Connect agit comme infrastructure téléphonique; Salesforce gère le provisionnement et l’expérience agent. La transcription en temps réel, l’analyse de sentiment Contact Lens, les fonctionnalités Einstein AI et les capacités Agentforce atteignent leur plus haut niveau d’intégration dans ce modèle. Pour les organisations qui n’ont pas déjà investi dans une solution CCaaS, c’est le choix architectural le plus simple.
Le modèle de coûts mérite toutefois d’être bien compris avant signature. Les licences Service Cloud Voice se situent à l’intersection des licences Salesforce et de la tarification à l’utilisation d’Amazon Connect. Amazon Connect facture à la minute utilisée ainsi qu’en fonction des fonctionnalités activées. Pour les organisations qui gèrent des centaines de minutes agents simultanées, le modèle Bring Your Own AWS Account (BYOA) mérite considération. Pour les plus petits déploiements, la surcharge opérationnelle liée au BYOA dépasse généralement les économies potentielles; le modèle natif devient alors plus avantageux en matière de coûts de déploiement et de coût total de possession à long terme (LTCO).
Un autre point concernant Amazon Connect et Agentforce : si vous licenciez Agentforce pour votre centre de contact en parallèle d’Amazon Connect, assurez-vous de bien comprendre votre structure de coûts globale : licences SCV, consommation Amazon, utilisation Agentforce, et potentiellement aussi l’utilisation de Data Cloud (harmonisation des appels vocaux avec les comportements web, le suivi eCommerce, etc. pour alimenter les agents IA).
Service Cloud Voice avec Bring Your Own Telephony (BYOT) Ce modèle permet aux organisations de conserver leur investissement CCaaS existant — Genesys Cloud, NICE, Five9, RingCentral, Vonage, Talkdesk et autres — tout en migrant l’expérience agent côté Salesforce vers Service Cloud Voice. L’infrastructure téléphonique demeure en place. L’espace de travail Salesforce, lui, est modernisé.
Pour les grandes entreprises ayant des déploiements CCaaS matures, des contrats actifs et des logiques de routage complexes, il s’agit souvent du bon choix intermédiaire. Cette approche dissocie le problème de migration du problème de réarchitecture téléphonique. Le compromis se situe principalement au niveau de l’intégration IA : les configurations BYOT nécessitent généralement davantage de configuration pour atteindre une parité de reporting avec le modèle natif Amazon Connect, et certaines fonctionnalités automatiques dans le modèle natif demandent une implantation manuelle en BYOT. Des considérations de licences avec le fournisseur actuel peuvent également entrer en jeu.
Point critique : BYOT n’offre pas une expérience uniforme. La qualité de l’intégration Service Cloud Voice varie énormément d’un fournisseur téléphonique à l’autre, et tous n’ont pas investi de façon équivalente dans leurs connecteurs SCV. Certains, comme Genesys Cloud, sont en tête du peloton, mais ce n’est pas généralisé. Avant de vous engager, validez l’implantation BYOT de votre fournisseur CCaaS spécifique par rapport à vos besoins, particulièrement pour le routage omnicanal, la transcription en temps réel (afin de mieux activer Agentforce) et la capture de données post-appel.
Agentforce Contact Center (émergent) Lancé lors d’Enterprise Connect en mars 2026, Agentforce Contact Center repose sur une architecture complètement différente des deux options précédentes. Il s’agit d’une plateforme CCaaS entièrement native construite sur l’infrastructure Hyperforce de Salesforce. La pile téléphonique, le routage, la transcription, les agents IA et la couche omnicanale fonctionnent tous nativement dans Salesforce. Aucune intégration nécessaire, et un seul fournisseur responsable si quelque chose ne fonctionne pas correctement.
Commencez par comprendre ce que vous possédez : l’audit CTI
Avant de pouvoir prendre intelligemment l’une des décisions ci-dessus, l’organisation doit disposer d’un inventaire honnête de sa dépendance actuelle au CTI. Très peu d’organisations ont déjà produit cet inventaire dans un seul document. Et il est presque toujours plus vaste que prévu.
L’audit comporte quatre composantes : Cartographie des intégrations. Identifier tous les endroits où Open CTI est utilisé : dispositions softphone, adaptateurs CTI personnalisés, configurations de screen pop, implémentations click-to-dial, automatisations de journalisation des appels, transmission de données IVR. Pour les organisations fortement personnalisées — et la majorité des grandes entreprises le sont — ce n’est pas un exercice trivial.
Évaluation du couplage. Déterminer quelles intégrations sont modulaires et lesquelles dépendent fortement de comportements spécifiques au CTI. Les intégrations modulaires se migrent relativement bien. La logique personnalisée fortement couplée nécessite une refonte, pas seulement une migration.
Cartographie des dépendances en aval. Les intégrations CTI existent rarement de façon isolée. Les données d’appels alimentent des pipelines de reporting. Les logiques de screen pop déclenchent des workflows. Les automatisations post-appel écrivent dans des objets utilisés par des tableaux de bord. Identifiez tous les systèmes en aval dépendant actuellement des données CTI et validez que Service Cloud Voice produit des données équivalentes sous une forme équivalente.
Révision des licences et contrats. Que dit votre contrat CCaaS actuel concernant l’intégration Salesforce? Quelles sont les modalités de sortie? Si vous évaluez un changement de plateforme CCaaS en parallèle de votre migration CTI, quelles sont les implications pour vos engagements actuels?
Cet audit constitue la phase 1. Aucune décision d’architecture ne devrait être prise avant sa réalisation. Les organisations qui sautent cette étape découvrent souvent en pleine migration qu’une intégration personnalisée oubliée était en fait critique au fonctionnement de l’ensemble.
Le vrai risque n’est pas de manquer l’échéance
La date de février 2028 entraînera presque certainement une pression importante sur la capacité des partenaires dans la deuxième moitié de 2027, comme ce fut le cas avec Process Builder, Lightning et d’autres dépréciations majeures Salesforce. Mais pour les organisations opérant à l’échelle entreprise, le risque réel n’est pas de manquer l’échéance. C’est le coût d’opportunité de ne pas traiter cette migration comme une décision d’architecture.
Open CTI était un connecteur. Service Cloud Voice est une plateforme. Les organisations qui abordent cette migration comme un simple lift-and-shift — reproduire les comportements téléphoniques actuels dans le nouveau framework, cocher la case et passer à autre chose — respecteront peut-être l’échéance, mais manqueront complètement l’enjeu. Celles qui utilisent cette transition forcée pour prendre des décisions réfléchies sur l’emplacement architectural de leur téléphonie, sur les capacités IA (Agentforce) qu’elles souhaitent développer, et sur la façon de répartir la responsabilité entre l’infrastructure CCaaS et l’intelligence CRM, se retrouveront dans une position structurellement différente en 2028 par rapport à leurs pairs qui auront simplement gardé les téléphones opérationnels. Ces décisions dépassent largement la simple gestion des screen pops pour les appels entrants; elles concernent la manière dont les agents IA réduiront les coûts et amélioreront l’expérience client à long terme.
L’échéance est réelle. La fenêtre de planification est maintenant ouverte. La question à poser avant votre prochaine conversation avec un fournisseur n’est pas « comment migrer du CTI vers SCV », mais plutôt : « quelle architecture de centre de contact voulons-nous bâtir, et cette migration accélère-t-elle cette vision ou ne fait-elle que prolonger l’état actuel? »
Ateko est le seul partenaire dans cette conversation à intervenir des deux côtés de la matrice de propriété. Notre pratique Salesforce implémente des architectures post-CTI depuis la sortie de SCV. Bell, notre société mère, est un fournisseur national de télécommunications avec des décennies d’expérience en déploiement d’infrastructures de centres de contact en 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 le lancement du processus d’appel d’offres.
Parlez à quelqu’un chez Ateko et contactez-nous dès aujourd’hui.
