Fin de Salesforce to Salesforce : votre plan avant Spring '27

Si votre entreprise partage des leads, des opportunités ou des requêtes avec un distributeur, un revendeur ou une société sœur qui utilise aussi Salesforce, il y a de bonnes chances que le lien entre les deux organisations repose sur Salesforce to Salesforce (S2S). La fin de Salesforce to Salesforce a désormais une échéance claire : avec la version Spring '27, S2S cessera de fonctionner dans toutes les organisations. Aucune migration automatique n'est prévue, et chaque solution de remplacement suppose un choix d'architecture et, souvent, une nouvelle licence. Ce guide explique ce qui change, qui est concerné, les quatre options de remplacement et un plan d'action concret pour les semaines à venir.

Fin de Salesforce to Salesforce : ce qui change

S2S est l'une des plus anciennes fonctionnalités de la plateforme. Il permet à deux organisations de publier des enregistrements et de s'y abonner : un lead ou une opportunité créé dans une organisation apparaît dans l'autre. Dans la documentation développeur, l'objet PartnerNetworkRecordConnection (en anglais) représente précisément cela : un enregistrement partagé entre organisations Salesforce via S2S.

L'article officiel de l'aide Salesforce sur le retrait de S2S, publié en octobre 2026, décrit un calendrier en trois temps :

1. Spring '26 : les administrateurs ne peuvent plus activer S2S dans une organisation. Celles qui l'avaient déjà activé le conservent.
2. Après Summer '26 : le support officiel a pris fin. Plus de correctifs ni d'évolutions, même s'il reste possible d'ouvrir un ticket.
3. Spring '27 : S2S est entièrement retiré de toutes les organisations et ne fonctionne plus.

La page Salesforce des retraits de fonctionnalités situe ce retrait dans Spring '27, en février 2027. Les versions majeures sont déployées par vagues selon les instances : vérifiez la vôtre dans le calendrier de maintenance de Salesforce Trust, car votre échéance réelle peut tomber quelques semaines avant ou après celle d'un confrère.

Pour Salesforce, la vente indirecte et les architectures multi-organisations demandent plus qu'une simple copie d'enregistrements entre deux bases. Les points clés Summer '26 pour les architectes, sur le blog Salesforce (en anglais), présentent S2S comme un raccourci commode pour des besoins qui appellent en réalité un modèle plus structuré, et préviennent que ce changement demandera une vraie préparation.

Qui est concerné

Si S2S est activé dans votre organisation, partez du principe que vous êtes concerné tant que vous n'avez pas prouvé le contraire. Concrètement :

• Responsables de la vente indirecte et des partenaires : équipes qui transmettent des leads à des revendeurs, ou reçoivent en retour des mises à jour d'opportunités, via des connexions S2S.
• Groupes multi-organisations : filiales ou business units qui ont chacune leur organisation et échangent comptes, contacts ou requêtes.
• Administrateurs : responsables de la liste des connexions, des objets publiés et souscrits, des correspondances de champs et des automatisations qui s'exécutent sur les enregistrements reçus.
• Développeurs et responsables d'intégration : tout code Apex, flow, rapport ou requête SOQL qui lit PartnerNetworkRecordConnection ou d'autres données S2S devra être réécrit ou supprimé.
• Managers commerciaux et service client : les rapports et tableaux de bord fondés sur des enregistrements partagés afficheront des données figées dès que le lien s'arrêtera.

Un point passe souvent inaperçu : l'organisation du partenaire est touchée au même moment. Une connexion a deux extrémités, et la solution de remplacement doit être décidée avec l'administrateur de l'autre entreprise, pas conçue seul. Les enregistrements déjà copiés dans l'autre organisation y restent comme des enregistrements ordinaires : le retrait arrête le flux de mises à jour, il ne nettoie rien.

Les quatre options de remplacement

L'article de l'aide et les points clés pour les architectes indiquent quatre options. Chacune répond à un besoin différent, et aucune ne reproduit S2S à l'identique.

1. Partner Cloud : pour les entreprises qui partagent des informations avec des partenaires revendant leurs offres. Les partenaires travaillent dans un portail à vos couleurs plutôt que dans leur propre organisation. Selon la page tarifs de Partner Cloud (en anglais), l'édition PRM est affichée à 25 € par membre et par mois et l'édition Partner Ecosystem Management à 50 €, avec facturation annuelle, en achat distinct de Sales Cloud.
2. Data Cloud One : pour les groupes qui ont plusieurs organisations et veulent une vue client unifiée. Le module Trailhead Connect Multiple Orgs with Data Cloud One (en anglais) en décrit le modèle : une organisation principale où Data 360 est provisionné, des organisations associées reliées par une connexion sans code, et seules les métadonnées des espaces de données choisis sont partagées. Toutes les fonctionnalités de Data 360 ne sont pas disponibles dans les organisations associées.
3. MuleSoft Anypoint Platform : pour les intégrations complexes ou bidirectionnelles qui exigent transformation, routage, gestion des erreurs ou orchestration entre plusieurs systèmes.
4. MuleSoft for Flow : pour les équipes qui privilégient le déclaratif et ont des besoins au niveau des processus. L'annonce de MuleSoft for Flow: Integration (en anglais) décrit un outil low-code, utilisé depuis Salesforce, avec plus de 40 connecteurs prêts à l'emploi et un mappage visuel des champs.

Pour choisir, répondez à trois questions. L'autre partie est-elle un partenaire externe ou une autre organisation de votre groupe ? Avez-vous besoin d'une synchronisation enregistrement par enregistrement, ou d'une vue partagée du client ? Qui portera l'intégration dans deux ans : un administrateur ou une équipe intégration ? Un revendeur externe oriente plutôt vers Partner Cloud ; un groupe multi-organisations visant une vue client 360 vers Data Cloud One ; une synchronisation fine avec règles métier vers MuleSoft. Salesforce précise que chaque option a un impact en licences ou en coûts : impliquez tôt votre interlocuteur commercial et budgétez-le avant la fin de l'année.

Que faire maintenant : un plan de migration en six étapes

1. Confirmer le périmètre. Dans Configuration, ouvrez les connexions Salesforce to Salesforce et listez chaque connexion active : organisation partenaire, statut, responsable métier et dernière activité. Exportez l'historique des connexions avant toute modification.
2. Cartographier ce qui est partagé. Pour chaque connexion, notez les objets publiés et souscrits, les correspondances de champs, les filtres et les réglages d'acceptation automatique, ainsi que le volume d'enregistrements et la fréquence des mises à jour.
3. Repérer les dépendances. Recherchez dans l'Apex, les flows, les règles de validation, les rapports et les packages gérés les références à PartnerNetworkRecordConnection et aux champs S2S. Notre guide des mises à jour de version Salesforce avant Spring '27 applique la même méthode de revue.
4. Choisir une option par connexion. Une même organisation peut avoir besoin de deux réponses : Partner Cloud pour les revendeurs, MuleSoft pour une société sœur. Validez la cible avec l'administrateur du partenaire et avec la personne qui approuve la licence.
5. Construire et tester dans une sandbox sans S2S configuré. C'est la recommandation de Salesforce. Utilisez des identifiants externes stables pour rapprocher les enregistrements entre organisations, et des règles de duplication pour repérer les copies, comme dans notre guide des règles de duplication Salesforce.
6. Basculer, puis désactiver S2S. Faire tourner les deux en parallèle peut créer des doublons dans l'une ou les deux organisations : gardez une période de recouvrement courte, rapprochez les volumes et arrêtez le partage une fois la nouvelle solution validée.

Avant et après, en bref :

• Avant : deux organisations qui se copient des enregistrements via une connexion que personne n'a vraiment documentée, avec des automatisations sur les enregistrements reçus et des rapports qui supposent que le lien fonctionne.
• Après : une intégration identifiée avec un responsable, une source de vérité claire pour chaque champ, une gestion des erreurs que l'on peut surveiller, et plus aucune dépendance à une fonctionnalité retirée.

Si la solution retenue est une nouvelle intégration par API, sécurisez son authentification dès le départ : notre article sur les échéances d'authentification des intégrations Salesforce détaille les règles actuelles pour les utilisateurs d'intégration.

Intégrer ce chantier à votre calendrier Spring '27

L'échéance est proche. D'ici février 2027, il faudra aussi composer avec les congés de fin d'année, la préversion Spring '27 en sandbox et, pour beaucoup d'équipes, d'autres retraits comme la fin de Salesforce for Outlook. Une décision de licence et l'accord d'un partenaire peuvent chacun prendre plusieurs semaines. Un objectif réaliste : terminer l'inventaire en novembre, arrêter l'option et le budget en décembre, construire et tester en janvier.

Une liste de contrôle rapide pour votre prochain comité de pilotage :

• S2S est-il activé dans notre organisation, et combien de connexions sont actives ?
• Quels processus métier s'arrêtent si la connexion tombe demain ?
• L'administrateur du partenaire est-il prévenu, et qui est notre contact chez lui ?
• Quelle option de remplacement, et qui valide le coût ?
• Quels rapports et automatisations faut-il reconstruire ?

Conclusion

La fin de Salesforce to Salesforce est un arrêt net : avec Spring '27, les enregistrements cessent de circuler entre organisations connectées. La solution n'est pas un simple paramètre mais un petit projet d'intégration, avec un partenaire de l'autre côté et, le plus souvent, une nouvelle licence. Lancez l'inventaire ce mois-ci, choisissez une option par connexion et testez sans S2S dans une sandbox. Pour cartographier vos connexions et construire la solution de remplacement, notre équipe migration CRM, nos consultants Salesforce Data Cloud et nos spécialistes Sales Cloud peuvent mener ce chantier avec vous et vos partenaires.