Salesforce Release Spring '26

La Salesforce Release Spring '26 (disponible à partir de janvier 2026) marque une transition notable dans la maturité de la plateforme Salesforce, où l'accent passe d'une accumulation rapide de fonctionnalités IA à une consolidation réfléchie et à la préparation des organisations pour une transformation à grande échelle. Bien qu'Agentforce et Data 360 restent les piliers stratégiques, Spring '26 se distingue par un focus sur les fondations d'exploitation : amélioration de l'expérience développeur, renforcement de la sécurité, modernisation des outils administrateur, et migration forcée vers de nouvelles pratiques d'intégration. Ce qui peut sembler être une mise à jour technique mineure aux yeux du marketing Salesforce optimiste représente en réalité une dette technique majeure que chaque organisation devra absorber.

10 Points Clés à Retenir

1. Instance URL API : Un changement architectural critique et non-négociable — Les organisations doivent remplacer les références d'instance dans leurs intégrations API par des My Domain URLs d'ici la prise en force en Spring '26. C'est une rupture de compatibilité réelle, pas une simple recommandation.​
2. Editable Data Table en Flow : Longtemps attendu, mais encore instable — Le composant tant demandé fait ses débuts en Spring '26, mais avec un statut « expérimental » : il a d'ailleurs disparu lors de tests initiaux. À utiliser prudemment en production.​
3. Salesforce Shield devient une application dédiée — La consolidation des outils de sécurité (Data Detect, Field Audit Trail, Event Monitoring, Platform Encryption) dans une application UI est une victoire pour la gouvernance, mais révèle aussi que Shield était trop dispersé pour être vraiment utilisé.​
4. External Client Apps remplacent progressivement Connected Apps — Salesforce retire progressivement l'accès à la création de nouvelles Connected Apps. Pour les architectes et les éditeurs ISV, c'est une migration complexe vers une stack 2GP. C'est aussi un signal fort : Salesforce standardise sur la metadata-compliance et abandonne les chemins « legacy ».​
5. Flow Logging dans Data 360 : Observer devient traçable — L'intégration du logging automatique des exécutions de Flow dans Data 360 transforme la visibilité mais augmente aussi la facturation de Data 360. À budgétiser sérieusement.​
6. Kanban Board native en Flow : Enfin une vraie alternative aux custom components — Après des années de demandes communautaires, Salesforce livre un composant prêt à la production pour gérer visuellement les workflows. C'est productif, mais repose encore sur une architecture restrictive.​
7. Custom Styling pour Screen Flows : Plus d'alignement marque, moins de bricolage — Le Theme Picker et les options de styling réduisent le besoin de composants LWC personnalisés pour la conformité visuelle. Cependant, pas d'accès à des formules ou variables pour les couleurs dynamiques — une limitation qui persistera.​
8. Multi-Page Experience Flows et LWR File Upload : Support amélioré pour Experience Cloud, mais encore expérimental — Les portails clients deviennent plus flexibles, mais le test révèle des lacunes dans l'intégration avec les expériences existantes.​
9. Data 360 Limits tightened, performance redefined — Batch transforms limités à 1 000 par org, real-time graphs limités à 200 KB, insights limités à 300 par tenant : ces chiffres reflètent une plateforme qui optimise pour la scalabilité, pas pour l'expérimentation. Les orgs vont buter sur ces plafonds bien avant Spring '26.​
10. Agentforce Builder (Beta) : Un moteur de raisonnement plus structuré, mais risques de disruption — La nouvelle architecture « graph-based » du builder offre plus de déterminisme et de contrôle, mais c'est une rupture pour les agents existants. Les adoptants précoces devront revalider leurs agents pour la production.​

Les 5 à 8 Évolutions Réellement Stratégiques de Spring '26

1. Migration Forcée : Instance URLs vers My Domain (Impact Critique, Obligatoire)

Le problème métier : Depuis des années, Salesforce encourage les bonnes pratiques d'intégration. Spring '26 cesse de suggérer et commence à appliquer. À partir de la prise en force en production, les redirections automatiques d'instance URLs (par ex., cs123.salesforce.com → monorg.my.salesforce.com) disparaîtront. Toute intégration API exploitant les anciens chemins cassera silencieusement.​

Maturité réelle : Enforced — Ce n'est pas une fonctionnalité, c'est un changement de rupture. Aucune période de grace significative ne sera accordée en production.

Impacts concrets :

• Entreprises : Toute intégration middleware, ETL, ou API externe qui utilise des instance URLs hardcodées cessera de fonctionner. Pour les grandes organisations avec des centaines d'intégrations, c'est un audit forcé et un projet de remédiation de plusieurs mois.
• Admins et Consultants Salesforce : Audit obligatoire de tout code Apex, Visualforce, et configurations Lightning qui référencent des instances. Risque élevé de régressions si un seul endpoint est manqué.
• Équipes Intégration : Modification systématique des configurations de Data Loader, Zapier, MuleSoft, Informatica, et autres outils. Les organisations avec des instances non-sandboxées n'ayant pas migré avant la prise en force verront des interruptions de service en production.

Ce que Salesforce ne dit pas clairement : La transition n'est pas innocente. Les organisations qui ont repoussé cette migration pendant plus de 2 ans sont maintenant face à un choix : mettre à jour tout en une seule fenêtre de maintenance (risqué), ou risquer des pannes partielles en production. Salesforce veut voir la fin de ce « technical debt », mais le coût de passage est externalisé vers les clients.

Zones grises : Comment les partenaires gérés et les managed packages se comportent-ils avec ce changement ? Salesforce a indiqué que les packages devraient utiliser My Domain URLs depuis longtemps, mais les vieux packages resteront fragiles.

2. Editable Data Table in Flow : Un Composant Attendu, Mais Instable en Preview

Le problème métier : Les admins et développeurs demandent depuis la v4.0 du native Data Table (Spring '24) une fonctionnalité d'édition inline. Actuellement, chaque modification de ligne nécessite un passage par une forme modale ou un composant LWC personnalisé. Spring '26 promet de fermer cette lacune.

Maturité réelle : Experimental/Beta — Une première préversion a été retirée pendant la période preview initiale après avoir rencontré des bugs. Statut actuel : en travaux, activable mais instable.​

Impacts concrets :

• Admins et Consultants : Accès à un composant natif qui élimine le besoin de 40% des LWC personnalisés pour les Use Cases simples de bulk-editing. Réduction de la complexité technique et du support à long terme.
• Équipes Dev : Possibilité de fermer des tickets long-standing "nous avons besoin d'une table éditable". Mais attention : si le composant crashe en production, le fallback vers un LWC custom prend du temps.
• Responsables CRM : Réduction du coût total de propriété des solutions d'automatisation légères. Moins de dépendance à l'égard des développeurs pour chaque petit besoin d'UI.

Ce que Salesforce ne dit pas : La raison pour laquelle ce composant a d'abord disparu ? Problèmes de performance lors de très grands datasets, ou conflits de permissions. Salesforce attend probablement la Q1 2026 pour stabiliser. Les adoptants précoces s'exposent à des régressions.

Risques et points de vigilance : Les utilisateurs avec des permissions complexes ou des Field-Level Security actifs pourraient rencontrer des comportements inattendus. Il n'y a pas de support pour les champs formula ou les roll-ups (bien que cela soit une limitation attendue).

3. External Client Apps : La Nouvelle Ère de l'Intégration (Obligatoire pour 2GP)

Le problème métier : Salesforce a lancé External Client Apps comme la génération suivante de Connected Apps, avec meilleure support pour 2GP (Second-Generation Packaging), séparation des rôles admin/développeur, et metadata-compliance. Mais la plupart des organisations ont continué à utiliser Connected Apps par inertie.

Maturité réelle : Production-Ready, mais adoption encore immature dans l'écosystème. Spring '26 pousse le calendrier de migration en masquant l'option de créer de nouvelles Connected Apps derrière Salesforce Customer Support.​

Impacts concrets :

• Architectes et ISVs : Migration obligatoire de toutes les nouvelles intégrations vers External Client Apps. Pour les packages distribués, c'est non-négociable. Les orgs locales (non-packagées) peuvent continuer avec Connected Apps encore un peu, mais ce chemin se ferme.
• Consultants Salesforce : Nécessité de mettre à jour les templates d'intégration, les processus onboarding, et les checklists d'audit. Les clients avec des CRM complexes devront valider que leurs Connected Apps existantes restent compatibles pendant la période de transition.
• Équipes Sécurité : External Client Apps offrent un meilleur modèle d'audit (policy vs. settings), mais introduisent aussi de nouvelles surfaces d'attaque à valider. Les configurations de permissions devront être examinées à nouveau.

Ce que Salesforce ne dit pas clairement : Il n'y a pas d'outil de migration automatisée pour convertir une Connected App existante en External Client App. C'est un processus manuel, donc une friction réelle. De plus, quelques fonctionnalités (Canvas Apps, User Provisioning) ne sont encore disponibles que pour Connected Apps.

Zones grises : Quelle est la véritable timeline avant que Connected Apps soient complètement décommissionnées ? Salesforce n'a pas donné de date ferme. Les orgs devraient prévoir 18-24 mois avant un changement forcé.

4. Flow Logging in Data 360 : L'Observabilité des Workflows Devient Traçable (et Chère)

Le problème métier : Les admins ont toujours eu du mal à diagnostiquer pourquoi un Flow s'est mal exécuté ou pour auditer l'historique des exécutions en masse. Salesforce a intégré le logging des Flow exécutions directement dans Data 360, créant une single source of truth pour la visibilité opérationnelle.​

Maturité réelle : Production-Ready, mais tightly coupled avec Data 360 (qui n'est pas dans le budget de toutes les orgs).

Impacts concrets :

• Admins et DevOps : Visibilité détaillée des Flow exécutions (temps d'exécution, erreurs, variables de sortie) centralisée dans une Lightning Page. Réduit le besoin de logs personnalisés via Apex.
• Équipes Compliance et Audit : Possibilité de tracer chaque exécution d'un processus métier. Audit trails renforcés pour les secteurs régulés (Finance, Healthcare).
• Responsables CRM : Compréhension claire de qui lance quel Flow, quand et avec quels résultats. Meilleure prévention de la dérive de processus.

Ce que Salesforce ne dit pas : Chaque exécution stockée dans Data 360 consomme des crédits de Data 360. Une org avec 10 000 Flow exécutions par jour verra son coût Data 360 augmenter notablement. Il n'y a pas d'option pour « logger seulement les erreurs » — c'est tout ou rien.​

Risques et points de vigilance : Performance. Si une org lance des millions de Flows (batch processing automation-heavy), la volumétrie de logging pourrait créer une bottleneck. Salesforce n'a pas publié de lignes directrices sur les seuils de performance.

5. Agentforce Builder (Beta) : Un Moteur Déterministe, Mais Migrations Complexes

Le problème métier : L'Agentforce Builder original était tout-LLM : l'IA décidait essentiellement du comportement de l'agent. Spring '26 introduit une nouvelle architecture « graph-based » où les flux de conversation sont plus structurés et prévisibles, combinant natural language et scripting.​

Maturité réelle : Experimental/Beta — Disponible pour les orgs, mais recommandé d'abord en sandbox. Les agents existants construits avec l'ancienne architecture continueront à fonctionner, mais les nouveaux agents vont exploiter le nouveau moteur.

Impacts concrets :

• Développeurs Agentforce : Plus de contrôle sur la logique de l'agent. Meilleur debugging, traçage, et fiabilité. La capacité à écrire en Agent Script (langage de scripting dédié) offre des possibilités que natural language seul ne peut pas toujours couvrir.
• Responsables de Projet : Réduction du risque d'hallucinations ou de comportements inattendus. Les agents construits avec cette architecture sont plus prédictibles et plus adaptés aux usages critiques en production.
• Équipes IT et Gouvernance : Monitoring amélioré des agents grâce à Agentforce Observability. Possibilité de tracer chaque décision d'un agent et d'identifier où un agent s'égare.

Ce que Salesforce ne dit pas : La migration d'agents existants du legacy builder au nouveau builder n'est pas automatique. C'est un processus de re-validation. Les agents critiques devront passer par des tests complets. De plus, certaines fonctionnalités du legacy builder (ex : actions entièrement basées sur LLM) pourraient ne pas avoir d'équivalent direct dans la nouvelle architecture.

Risques et points de vigilance : Pour les orgs avec des agents Agentforce complexes déjà en production, cette transition représente un risque de régressions. Le timing de cette bêta est serré — il faudra valider rapidement que les nouveaux agents fonctionnent comme prévu avant la prise en force.

6. Salesforce Shield Dedicated App : Centralisation de la Sécurité, Mais Coûts d'Exploitation Croissants

Le problème métier : Salesforce Shield (Data Detect, Field Audit Trail, Event Monitoring, Platform Encryption) était dispersé dans Setup. Spring '26 consolide ces outils dans une application dédiée, réduisant la friction pour les admins de sécurité.​

Maturité réelle : Production-Ready — C'est une reorganisation UI, pas une nouvelle fonctionnalité.

Impacts concrets :

• Responsables Sécurité et Compliance : Une seule destination pour gérer toute la monitoring et l'audit. Meilleure UX, moins de clics pour configurer les audit trails ou activer l'encryption.
• Admins Salesforce : Accès plus fluide aux outils de sécurité. Réduction du temps de configuration et de la courbe d'apprentissage.
• Équipes Conformité : Audit trails plus accessibles et compréhensibles pour démontrer la compliance (RGPD, HIPAA, SOC 2).

Ce que Salesforce ne dit pas clairement : La création d'une application dédiée pour Shield indirectement reconnaît que ces outils étaient trop cachés pour être vraiment utilisés. Beaucoup d'orgs payant pour Shield n'exploitent pas à 10% de ses capacités. Maintenant que l'UX s'améliore, les orgs sans Shield vont faire la même réclamation auprès de leurs éditeurs.

Risques et points de vigilance : Coûts. Shield est un add-on premium. Plus les orgs accèdent facilement à Shield, plus elles comprennent ce qu'elles font manquer en n'ayant pas de license Shield. C'est un business driver pour Salesforce, mais un coût nouveau pour les clients.

7. Data 360 Limits Enforced : Scalabilité Redéfinie, Performance Compromise

Le problème métier : Data 360 est devenu central pour les stratégies de CDP et d'IA. Mais à mesure que l'adoption augmente, Salesforce doit protéger la performance du service pour tous.​

Maturité réelle : Enforced — Ces limites ne sont pas nouvelles, mais Spring '26 les rend plus visibles et plus strictement appliquées.

Impacts concrets :

• Architectes Data et Responsables BI :
  • Batch transforms : max 1 000 par org, 50 concurrents
  • Real-time graphs : max 200 KB de taille, 200M records en standard
  • Calculated insights : max 300 par tenant, 30 exécutions manuelles/jour
  • Les orgs devront optimiser leurs data models pour rester dans ces limites.
• Équipes Data Engineering : Besoins de re-architecture pour les pipelines complexes. Partitioning, segmentation, et pruning deviennent essentiels.
• Responsables CRM : Compréhension claire que Data 360 n'est pas une data lake illimitée. C'est une plateforme CDP hautement optimisée avec des frontières.

Ce que Salesforce ne dit pas clairement : Ces limites reflètent des choix d'ingénierie pour protéger la performance. Mais elles signifient aussi que les Use Cases très complexes (centaines de calculated insights, millions de données à unifier en temps réel) dépasseront rapidement les plafonds. Les orgs devront faire des choix : limiter la complexité, ou accepter une dégradation de performance.

Zones grises : Que se passe-t-il quand une org atteint ces limites ? Salesforce throttle ? Refuse la création ? Il n'y a pas de communication claire sur le comportement de fallback.

8. Connected Apps Deprecation Quietly Enforced : Un changement de paradigme pour les intégrateurs

Le problème métier : Salesforce retire progressivement l'accès à la création de nouvelles Connected Apps, les forçant vers External Client Apps.​

Maturité réelle : Enforced — La création de nouvelles Connected Apps est maintenant derrière Customer Support.

Impacts concrets :

• Architects et Consultants : Obligation de repenser chaque intégration nouvelle. Pour les ISVs, c'est une migration vers 2GP et une re-validation des packages.
• Équipes Sécurité : External Client Apps offrent un meilleur modèle de sécurité (séparation des rôles), mais nécessitent une re-validation des configurations.
• Partenaires Managés : Si un partenaire ISV distribue un package avec Connected Apps, ce package deviendra progressivement inutilisable. Pression pour migrer avant que l'option ne disparaisse complètement.

Ce que Salesforce ne dit pas : Timeline précise. Les existing Connected Apps continueront à fonctionner « indefinitely », mais sans support nouveau. C'est une mort lente, pas un kill-switch.

Ce Qui Change Concrètement par Rapport aux Versions Précédentes

vs. Winter '26

Aspect	Winter '26	Spring '26
Instance URL Enforcement	Recommandé en sandboxes	Enforced en production
Connected Apps	Toujours créables	Création restreinte, derrière Support
Flow Builder Debugging	Modern debugging en Canvas	Déboguer plus les Screen Flows aussi
Agentforce	Legacy builder par défaut	New graph-based builder (Beta)
Shield	Dispersé dans Setup	Dedicated app, meilleure UX
Data 360 Scale	Limites énoncées	Limites plus strictement appliquées

vs. Summer '25

Spring '26 consolide plutôt que d'ajouter. Moins de feature-mania, plus de stabilisation.

Ce Que Salesforce Ne Dit Pas Clairement : Zones Grises et Limites

1. Agentforce Builder : Discontinuité Cachée

Salesforce présente la new Agentforce Builder comme une « amélioration », mais c'est en fait une rupture architecturale. Les agents construits avec l'ancienne architecture continueront à tourner, mais tous les nouveaux agents utiliseront le moteur graph-based. Cela crée deux générations d'agents dans une même org — un risque de confusion et de maintenance fragmentée.​

Question non résolue : Seront tous les agents forcés de migrer à un moment donné ? Ou y a-t-il un vrai chemin long-terme pour coexistence ?

2. External Client Apps : Feature Parity Toujours Incomplète

Salesforce affirme que External Client Apps sont « la prochaine génération », mais plusieurs fonctionnalités clés sont encore manquantes (Canvas Apps, User Provisioning). C'est une pression pour migrer vers une technologie qui n'est pas encore complète.​

3. Data 360 Limits : Pas de Guidance sur le Fallback

Quand une org atteint 1 000 batch transforms, qu'arrive-t-il ? Salesforce ne le dit pas clairement. Refuse-t-on la 1001e ? Ou la performance se dégrade-t-elle silencieusement ?​

4. Editable Data Table : Vraiment Stable ?

Le composant a disparu pendant la preview. C'est un signal que Salesforce n'est pas entièrement confiant. Utiliser ce composant en production avant Q2 2026 représente un risque.​

5. Instance URL Change : Impact sur les Managed Packages

Pour les vieux packages qui hardcodent des instance URLs, Spring '26 risque de les casser. Salesforce n'a pas donné de guidance sur la responsabilité : le provider du package doit-il corriger ? Ou le client accepte-t-il que le package soit inadapté ?

Recommandations Pratiques

Pour une Entreprise Déjà sur Salesforce

Immédiatement (Avant janvier 2026) :

1. Audit des Instance URLs : Scanner tous les apex, flows, LWC, et configurations d'intégration pour les références à instance URLs. Lister tous les intégrations externes (Data Loader, Zapier, MuleSoft, etc.) et vérifier qu'elles utilisent My Domain URLs.
2. Préparation du Sandbox : Activer Spring '26 en preview dès que possible (le 9 janvier 2026). Tester systématiquement toutes les intégrations critiques pour s'assurer qu'elles ne cassent pas.
3. Planification du Changeover : Prévoir une fenêtre de maintenance en production pour déployer les correctifs d'intégration juste avant la prise en force en production. Ne pas attendre la date de sortie officielle pour votre instance.

Court terme (Q1 2026) :

1. Évaluer External Client Apps : Si vous avez des Connected Apps existantes ou si vous envisagez de nouvelles intégrations, commencer à évaluer External Client Apps. Pas urgent, mais la tendance est claire.
2. Pilot Agentforce Builder Beta : Pour les orgs avec des agents en production, commencer à tester la nouvelle architecture dans une sandbox. Cela ne doit pas être une urgence, mais une exploration proactive.
3. Optimiser Data 360 : Si vous utilisez Data 360, auditer vos data models pour s'assurer que vous n'allez pas buter sur les limites (1 000 batch transforms, 300 insights, 200 KB pour graphs réel-temps).

Moyen terme (Q2-Q3 2026) :

1. Consolider la Sécurité : Utiliser la nouvelle Salesforce Shield App pour auditer votre posture de sécurité. Comprendre ce que vous pouvez faire mais ne faites pas encore.
2. Composer avec les nouveaux Flow Components : Intégrer le Kanban Board et l'Editable Data Table (une fois stabilisés) dans les processus légers. Cela réduira votre dépendance à l'égard des LWC personnalisés.

Pour un Consultant / Admin Salesforce

Immédiatement :

1. Mettez à jour votre checklist de release readiness : Ajouter « Audit des instance URLs » et « Review des Connected Apps » comme étapes obligatoires.
2. Formez-vous sur External Client Apps : Lire la documentation complète, comprendre la comparaison feature-by-feature avec Connected Apps, et être prêt à conseiller les clients.​
3. Préparez un rapport de risque pour chaque client : Pour chaque org, identifier les intégrations non-conformes et les packages potentiellement affectés par les changements d'instance URLs.

Court terme :

1. Testez en preview : Pour vos plus grands clients, tester immédiatement Spring '26 en preview pour identifier tout problème avant qu'il ne touchent la production.
2. Lancez des pilots Agentforce : Pour les clients qui n'ont pas encore exploré Agentforce, utiliser Spring '26 comme point de trigger. La nouvelle architecture est plus stable et appropriée pour des cas d'usage en production.
3. Documentez les limites de Data 360 : Pour les clients planifiant des implementations Data 360, clarifier les limites d'upfront et concevoir les architectures en conséquence.

Moyen terme :

1. Devenez un expert External Client Apps : C'est le futur des intégrations. Les consultants qui peuvent guider les clients sur cette transition seront en demande.
2. Offrez un service d'optimisation Data 360 : Beaucoup d'orgs vont commencer à buter sur les limites. Une analyse proactive et une réarchitecture peuvent être une offre de service premium.

Projection : Ce Que Spring '26 Annonce pour l'Avenir (12-24 Mois)

Trajectoire Immédiate (H1 2026)

1. Instance URL change sera universellement appliqué. Toute org non-conforme verra des interruptions. Cela créera une vague de correction réactive (coûteuse).
2. Agentforce Builder Beta sortira de beta. La new architecture deviendra le standard. Les agents legacy continueront, mais les nouveaux agents exploiteront le moteur déterministe.
3. External Client Apps deviendront le standard de facto. Les ISVs auront migré la plupart des packages. Connected Apps seront vus comme un legacy.
4. Data 360 Limits commenceront à être un point douloureux. Les orgs avec des use cases complexes verront une dégradation de performance ou un refus de configurations supplémentaires.

Horizon Moyen Terme (H2 2026 – H1 2027)

1. Shield deviendra plus central : Avec l'app dédiée, la sécurité sera moins un « nice-to-have » et plus une attente de base. Les CSOs vont commencer à mandater des audits Shield.
2. Agentforce Grid et Observability mûriront : Ces outils (annoncés en Winter '26) vont se cristalliser. Les orgs verront Agentforce non plus comme un expériment, mais comme une partie centrale de leur opération.
3. Data 360 évoluera vers une CDP véritablement purpose-built. Les limites actuelles seront assouplies pour les clients premium, créant un modèle de pricing par échelon. Les small-to-mid market orgs découvriront que Data 360 coûte bien plus qu'annoncé.

Horizon Long Terme (2027+)

1. Flow Automation + Agentforce fusion : Ces deux piliers (automation low-code et AI agents) vont converger. Un seul « orchestration engine » pilotera à la fois la logique déterministe et la logique IA.
2. Connected Apps disparaîtront complètement : Timeline estimée : fin 2027 début 2028.
3. Data 360 devient un coût ligne de budget majeur pour les gros clients. L'unification des données à l'échelle, c'est cher. Les orgs découvriront que le coût total de propriété de Data 360 rivalise avec leurs data warehouse actuels.
4. Agentforce marketplace émergera : Des agents prédéfinis (« Lead Qualification Agent », « Customer Support Agent ») seront téléchargeables, configurables, et déployables en heures. Cela démocratisera Agentforce mais aussi créera une nouvelle dynamique de concurrence (agents commerciaux vs. agents propriétaires).

Conclusion

Salesforce Spring '26 n'est pas une release "sexy". Elle n'apporte pas de percées majeures en IA ou d'intégrations cloud radicalement nouvelles. À la place, elle consolide, elle mûrit, et elle force les organisations à nettoyer leur debt technique.

Pour les décideurs, c'est un signal que Salesforce se soucie de la stabilité du platform, pas juste de l'ajout de features. Mais c'est aussi un signal que le coût d'exploitation de Salesforce va augmenter : instance URL migrations, data 360 optimization, external client app migrations — tout cela a un coût d'implementation.

Pour les consultants et admins, c'est une opportunité. Les orgs vont avoir besoin de guidance, d'audits, et de projets de migration. Les consultants qui peuvent offrir des services autour de la préparation à Spring '26 seront en forte demande.

Pour les responsables CRM, c'est un appel à l'action. Utilisez la fenêtre avant janvier 2026 pour auditer votre landscape Salesforce, valider votre readiness, et planifier votre migration. L'inaction crée du risque.