Pourquoi SharePoint Framework fonctionne toujours sur React 17

Quatorze versions consécutives de SharePoint Framework sont sorties avec React 17.0.1. Quatorze.

Cela ressemble à de la stagnation. Ce n'en est pas, et c'est rarement présenté autrement.

Les faits d'abord

Microsoft publie un tableau de compatibilité pour chaque version de SPFx. Voici ce qu'il dit de React, consulté le 5 août 2026 (compatibilité de la plateforme et de la chaîne d'outils SPFx) :

Trois versions majeures de React en dix ans de SPFx, et la version actuelle tient depuis quatorze versions consécutives. Celle qui a changé les choses est datée et explicite : SPFx 1.16.0, publiée le 15 novembre 2022, "SPFx prend désormais en charge React 17 par défaut" (notes de version 1.16.0).

Une comparaison rend cela plus net. React 18 est sorti en mars 2022, huit mois plus tôt. Microsoft n'a pas choisi la version la plus récente pour ensuite prendre du retard. Microsoft a livré une version qui avait déjà une génération de retard le jour de son arrivée.

Quoi que ce soit, cela n'a jamais été un pari sur la nouveauté.

Nous savons ce que coûte un changement majeur de React, parce que c'est déjà arrivé

La question évidente est de savoir pourquoi cela prend si longtemps. La réponse se trouve dans les notes de version de la dernière fois.

SPFx 1.16.0 est la version qui a fait passer SharePoint de React 16 à React 17. Pendant cette transition, Microsoft a corrigé des problèmes dont :

• des extensions de liste en échec à cause d'une incompatibilité de version de React (#8482)
• des erreurs d'invalid hook call dans des composants WebPart (#8487)
• le volet de propriétés qui ne s'affichait pas (#8496)
• une erreur React minifiée, la #321 (#8510)

Ce sont les notes de version de Microsoft elle-même. Pas une plainte de forum, pas une anecdote.

Changer une version majeure de React a cassé du code client en production, et les correctifs sont sortis en même temps que le changement qui les avait provoqués.

La phrase qui change l'histoire

La feuille de route SPFx liste des versions datées jusqu'en septembre 2026. React 18 ne figure dans aucune d'elles. Il se trouve dans une section à part appelée Top of Mind, sans version et sans date, avec ce texte (feuille de route SPFx, consultée le 5 août 2026) :

"Prise en charge de React 18 pour les solutions SPFx. Cette mise à jour dépend de la mise à jour des composants WebPart et des expériences fournis par Microsoft vers la version React 18. Ce travail est en cours."

Relisez la dépendance, car elle va dans le sens inverse de celui que l'on suppose habituellement.

Ce ne sont pas les clients qui attendent que Microsoft termine une mise à jour de framework. C'est Microsoft qui ne peut pas proposer la mise à jour tant que ses propres composants WebPart n'ont pas bougé.

La surface propre à Microsoft est le blocage.

Toute organisation possédant un composant WebPart sur mesure se trouve en aval d'une migration interne qu'elle ne voit pas, n'influence pas et ne planifie pas.

Lu avec la section précédente, le tableau devient clair. Si passer de 16 à 17 a cassé des extensions de liste, des volets de propriétés et des hooks en production, l'absence de date pour le passage de 17 à 18 cesse de ressembler à de la négligence et commence à ressembler à une estimation juste.

Il ne s'agit pas de npm

Vu de l'extérieur, cela ressemble à une mise à jour de dépendance. Ce n'en est pas une.

Ce qui doit réellement tenir au moment où React change :

• les composants WebPart de Microsoft, qui s'affichent sur des centaines de millions de pages que personne ne testera une par une ;
• Fluent UI, que les projets SPFx utilisent en v8 depuis la 1.18 (utiliser Fluent UI dans SPFx) ;
• toutes les solutions clientes jamais déployées, construites sur un contrat d'exécution qui était vrai au moment de leur écriture ;
• l'exécution elle-même, où le code de Microsoft et le vôtre partagent une page et une instance de React.

Ce dernier point est tout le problème. Une page SharePoint n'est pas une application avec un seul propriétaire. C'est un environnement d'exécution partagé où le code de Microsoft et le vôtre s'exécutent côte à côte, et une version majeure de React n'est pas un détail d'implémentation privé quand les deux moitiés doivent s'accorder dessus.

React 17 n'est plus seulement une version de framework dans SharePoint. C'est devenu une dépendance de plateforme. Les dépendances de plateforme ne bougent pas quand une partie est prête. Elles bougent quand toutes les parties le sont.

Pourquoi cela vous concerne en dehors de Microsoft

Tout ce qui précède décrit le défi de Microsoft. Cette partie est la vôtre.

La contrainte ne reste pas à l'intérieur de la plateforme. Elle atterrit dans votre dépôt, dans la version que vous installez, et dans ce que votre composant WebPart fait sur une page que vous ne contrôlez pas.

Le mode de défaillance est le silence

La page de compatibilité de Microsoft porte cet avertissement :

"L'utilisation de versions incompatibles de React peut provoquer des défaillances silencieuses à l'exécution, sans messages d'erreur clairs pendant la compilation."

Et elle recommande d'épingler la version exacte :

npm install react@17.0.1 react-dom@17.0.1 --save-exact

Silencieuses est le mot qui compte. Une solution construite sur React 18 compile. Elle s'exécute en local. Elle passe la revue. Puis elle affiche une zone vide en production, sans rien dans la console pour l'expliquer.

Il n'y a pas d'erreur à chercher, parce qu'il n'y a pas d'erreur. Si vous ne retenez qu'une instruction de cet article : épinglez exactement la version de React indiquée par votre version de SPFx, et vérifiez-le en revue. Non parce qu'un React plus récent serait moins bon, mais parce que l'environnement dans lequel vous déployez a déjà tranché.

Ce que l'IA change ici, et c'est moins qu'on ne le croit

Un agent écrit votre composant WebPart en quelques secondes. Il écrit le JSX, les propriétés, les hooks et les tests, et il le fait bien.

Rien de tout cela n'est la contrainte. La contrainte, c'est qu'une page doit charger du code Microsoft et du code tiers dans un même environnement d'exécution et que les deux doivent fonctionner. Aucune quantité de code généré ne rend un écosystème compatible avec lui-même, parce que la compatibilité n'est pas un problème d'écriture de code. C'est un accord entre des parties qui livrent selon des calendriers différents, et l'une d'elles a des centaines de millions d'utilisateurs qui n'ont jamais rien accordé.

L'IA écrit des composants. Les plateformes doivent toujours s'accorder sur l'environnement d'exécution.

Ce que nous ne savons pas

Nous préférons un "nous ne savons pas" explicite à une supposition assurée qui sera fausse dans six mois.

• Quand React 18 arrivera. Microsoft dit que le travail est en cours et ne donne pas de date. Au moment où ces lignes sont écrites, la feuille de route officielle de SharePoint Framework n'associe la prise en charge de React 18 à aucune version de SPFx publiée ou planifiée.
• Si la prochaine étape est bien React 18. React a continué d'évoluer depuis la 17. Sauter une version est une stratégie légitime, et Microsoft ne s'est prononcé dans aucun sens. La question intéressante n'est pas ce que React a publié ensuite, mais ce qui doit changer avant que SharePoint Framework puisse suivre.
• Quelle part de Microsoft 365 a déjà migré. "En cours" est toute l'information publique.

La question qui se cache dessous

La question n'a jamais été de savoir pourquoi Microsoft utilise encore React 17.

Le problème de Microsoft n'est pas de mettre à jour React. Le problème de Microsoft est de mettre à jour un écosystème : une surface propre, une bibliothèque de composants, un environnement d'exécution partagé, et toutes les solutions qu'un client a pu déployer, et tous doivent s'accorder le même jour.

Beaucoup d'organisations découvrent qu'elles ont exactement le même problème. La dépendance est différente, l'environnement est plus petit et le public se mesure en milliers plutôt qu'en centaines de millions, mais la forme est identique. Quelque chose de fondamental doit changer, et la réponse à "qu'est-ce que cela casserait" n'est écrite nulle part.

Si cela prend plus de quatre ans à une organisation dotée des moyens de Microsoft, il vaut la peine de se demander ce qui devrait bouger, et qui devrait être d'accord, avant de pouvoir changer une dépendance fondamentale dans votre propre patrimoine.

La plupart des organisations ne l'ont jamais compté. C'est généralement la réponse.

Pourquoi cet article devrait vieillir. Nous nous attendons à ce que SharePoint Framework finisse par prendre en charge une version plus récente de React. Quand cela arrivera, cet article cessera de parler de React 17 et continuera de parler d'autre chose : pourquoi les dépendances de plateforme bougent plus lentement que les dépendances d'une application, et pourquoi c'est une propriété de la plateforme et non un échec de ceux qui la maintiennent.

Si ce type d'analyse technique vous est utile, le SharePoint Migration Field Guide suit la même approche : les décisions d'abord, la documentation ensuite, le marketing jamais. Rédigé en anglais.