L’architecture frontale de Salesforce a évolué de Visualforce à Aura Components, puis à Lightning Web Components. Cependant, historiquement, l’intégration de frameworks JavaScript standards de l’industrie comme React, Angular, etc., dans Salesforce nécessitait des solutions de contournement complexes. Les développeurs devaient compiler leur code, le compresser dans des ressources statiques (fichiers zip stockés dans Salesforce) et l’exposer à l’aide de pages Visualforce ou de Lightning Out. L’alternative consistait à héberger l’application à l’extérieur de la plateforme sur Heroku ou AWS, ce qui nécessitait la mise en place de flux OAuth complexes. Cela entraînait des modèles de sécurité fragmentés, une mauvaise gestion des sessions et une expérience développeur médiocre.

Le changement : Salesforce Multi-Framework

Ce compromis appartient désormais au passé. Salesforce Multi-Framework est un environnement d’exécution indépendant du framework qui permet aux développeurs de créer et d’exécuter des applications Salesforce natives à l’aide de frameworks d’interface utilisateur standards de l’industrie comme React, présenté lors du TrailblazerDX (TDX) 2026. Il comble l’écart entre l’environnement de développement propriétaire de Salesforce et l’écosystème plus vaste du développement Web. Comme il fonctionne directement sur la plateforme Agentforce 360, il intègre nativement les capacités d’authentification, de sécurité, de gouvernance et d’intégration de données de Salesforce, éliminant complètement le besoin de configurer des iFrames ou des applications Canvas. Il constitue un pilier frontal essentiel de l’initiative plus large Headless 360.

Le cycle de développement : exécuter React nativement sur Salesforce

Avec Multi-Framework exécuté nativement sur la plateforme, l’expérience développeur comble l’écart entre la conception d’applications React standard et les flux de travail natifs de Salesforce DX.

1. Comprendre la structure des métadonnées (UI Bundles)

Salesforce traite l’ensemble du projet React comme un nouveau type de métadonnées appelé UI Bundle.

Lors de la création d’une application Multi-Framework, celle-ci réside nativement dans le répertoire du projet Salesforce DX sous une structure de dossiers dédiée. Voici à quoi ressemble cette structure en utilisant une simple application de catalogue de produits comme exemple :

productCatalog.app-meta.xml : Ce fichier de configuration indique à la plateforme Salesforce que ce dossier précis est une application React native plutôt qu’un composant LWC, ce qui lui permet de s’enregistrer de manière sécurisée auprès de l’environnement d’exécution Salesforce.
package.json : Fichier Node.js standard répertoriant les bibliothèques open source dont dépend l’application React (comme Tailwind CSS ou des moteurs de graphiques externes). Salesforce le lit afin de construire l’application sur ses serveurs principaux.
src/apis/client.ts : La passerelle fondamentale où le frontal établit sa connexion. En important le package natif de plateforme @salesforce/sdk-data, il identifie automatiquement la session utilisateur active et établit un contexte authentifié sans gestion de jetons.
src/apis/productQueries.graphql : Un fichier texte brut contenant les requêtes GraphQL standard. Par exemple, pour récupérer des données en temps réel à partir d’un objet personnalisé directement dans les vues React.

2. Comment cela fonctionne sur la plateforme

Multi-Framework héberge et affiche les applications React directement sur les serveurs applicatifs principaux de Salesforce. Une fois déployée, l’application React se retrouve côte à côte avec les Lightning Web Components (LWC) et peut être lancée directement à partir du Salesforce App Launcher. Cela élimine complètement le besoin d’hébergement externe, de middleware ou de configurations d’API fragiles.

3. Flux de travail de création, de test et de déploiement

Les processus de développement local et de déploiement sont conçus pour être intuitifs autant pour les vétérans de Salesforce que pour les développeurs Web traditionnels :

La couche GraphQL : Multi-Framework exploite GraphQL natif à la plateforme pour l’orchestration des données. Plutôt que d’écrire des contrôleurs Apex personnalisés pour les opérations CRUD de base, les développeurs utilisent l’API GraphQL pour interroger et modifier les enregistrements directement à partir du frontal.
Authentification sans jeton : En appelant createDataSDK() à partir de la bibliothèque native, l’application hérite automatiquement du contexte de session de l’utilisateur Salesforce actif et connecté. Aucune gestion de jetons OAuth, configuration d’application connectée ou logique de rafraîchissement de session n’est requise de la part du développeur.
Gouvernance appliquée : Comme l’environnement d’exécution React est intégré nativement à la couche principale de la plateforme, chaque requête et mutation GraphQL respecte rigoureusement les règles de partage de l’organisation, la sécurité au niveau des objets (CRUD) et la sécurité au niveau des champs (FLS).

4. Accès aux données, sécurité et gouvernance

L’avantage architectural le plus marquant de Multi-Framework réside dans la manière dont un composant React gère les données sans middleware personnalisé.

The GraphQL Layer: Multi-Framework leverages platform-native GraphQL for data orchestration. Rather than writing custom Apex controllers for basic CRUD, developers use the GraphQL API to query and mutate records directly from the frontend.
Zero-Token Authentication: By invoking createDataSDK() from the native library, the application automatically inherits the session context of the active, logged-in Salesforce user. There is absolutely no OAuth token management, connected app configuration, or session refresh logic required from the developer.
Enforced Governance: Because the React runtime is embedded natively within the core platform layer, every single GraphQL query and mutation strictly adheres to the org’s sharing rules, Object-Level Security (CRUD), and Field-Level Security (FLS).

Adapter React pour les développeurs LWC

Si votre expérience se limite aux Lightning Web Components, l’adoption de Multi-Framework consiste essentiellement à associer des concepts de conception familiers à la syntaxe propre à React :

Concept	Lightning Web Components (LWC)	Multi-Framework (React)
Structure des composants	Séparée en fichiers .js, .html et .css distincts.	Regroupée dans un seul fichier utilisant JSX (HTML intégré au JS).
Réactivité des données	Gérée via l’adaptateur de service déclaratif @wire.	Gérée à l’aide du hook d’état personnalisé React : useState.
Logique au chargement de la page	Exécutée dans le hook de cycle de vie natif connectedCallback().	Exécutée dans un hook useEffect() avec un tableau de dépendances vide.
Importation de la couche de données	Importée directement via @salesforce/apex ou lightning/uiRecordApi.	Importée via la bibliothèque native @salesforce/sdk-data.

LWC ou React : matrice décisionnelle

Multi-Framework ne remplace pas LWC; il élargit plutôt la boîte à outils. Savoir quand utiliser chaque framework constitue une décision architecturale importante.

Quand choisir React

Exploiter les talents existants : Lorsque l’équipe d’ingénierie possède déjà une expertise approfondie et spécialisée en React, lui permettant de créer immédiatement des applications Salesforce sans devoir apprendre un framework propriétaire.
Besoins liés à un riche écosystème : Lorsque l’interface utilisateur nécessite des packages npm open source très complexes, des bibliothèques spécialisées de visualisation de données ou des systèmes sophistiqués de composants React.
Portabilité multiplateforme : Lorsque les composants ou micro-frontaux conçus doivent être partagés nativement entre Salesforce et d’autres applications Web non Salesforce.

Quand choisir LWC

Maîtrise native de Salesforce : Lorsque les équipes internes sont déjà très compétentes avec les paradigmes de développement natifs de Salesforce.
Rapidité déclarative : Lorsque la conception repose fortement sur Lightning Data Services, des mises en page d’enregistrements rapides ou les composants Lightning de base prêts à l’emploi.
Personnalisation par les administrateurs : Lorsque les composants doivent être exposés directement dans le Lightning App Builder. (Puisque les composants React ne prennent pas encore cela en charge.)

Considérations et limites actuelles

Multi-Framework est actuellement dans sa phase bêta ouverte. Voici les limites actuelles de la plateforme :

Contraintes d’environnement : Les fonctionnalités Multi-Framework sont uniquement disponibles dans les Scratch Orgs et Sandboxes où l’anglais est défini comme langue par défaut. Les applications bêta ne peuvent pas encore être déployées dans des environnements de production, des organisations Developer Edition ou des Trailhead Playgrounds.
Couverture des frameworks : React est actuellement le seul framework tiers pris en charge.
Architecture des composants : La prise en charge complète des micro-frontaux — qui permettra aux développeurs d’intégrer directement ces composants React personnalisés dans un conteneur LWC existant — est toujours en phase Developer Preview.

Conclusion : une nouvelle ère pour l’architecture frontale Salesforce

L’introduction de Salesforce Multi-Framework représente un changement fondamental dans la manière dont les architectes de systèmes et les équipes de développement abordent la conception d’applications d’entreprise. En éliminant le cloisonnement entre les langages propriétaires de Salesforce et l’écosystème plus large du développement Web, Salesforce réduit considérablement les barrières à l’entrée pour les développeurs Web modernes.

Les organisations n’ont plus à choisir entre l’agilité exceptionnelle de l’écosystème React et la gouvernance rigoureuse des données de la plateforme Salesforce. Bien que LWC demeure la pierre angulaire des composants fortement déclaratifs et configurés par les administrateurs, Multi-Framework ouvre la voie à la création d’interfaces utilisateur

Le virage multi-framework : ReactJS sur la plateforme Salesforce