Faut-il retirer React en 2026 ? Guide de simplification du front-end pour CTO

« React partout » n’est pas une loi de la physique. Cela a été un choix par défaut intelligent pour une décennie d’UX web, mais cela ne signifie pas que votre SaaS doive être une application unique, perpétuellement hydratée, en 2026. La nouvelle vague d’équipes qui retirent React au profit de htmx et de MPAs rendues côté serveur n’est pas de la nostalgie ; c’est une comptabilité lucide de la complexité et des coûts. Un post HN qui circule détaille une entreprise retirant React et le remplaçant par htmx pour l’interactivité. C’est un tir de semonce pour quiconque paye des coûts d’astreinte à cause de bugs d’hydratation sans livrer une UX à la hauteur.

Qu’est-ce qui a changé depuis que nous avons tous misé sur les SPA ?

• Le navigateur est devenu rapide, votre app est liée au CPU. Les moteurs modernes et HTTP/2+ rendent les navigations multipage peu coûteuses. Vos vrais goulots d’étranglement sont le parsing JS, l’hydratation et la saturation du thread principal.
• La plupart des surfaces B2B restent du CRUD. Si 70–80 % de vos écrans sont des formulaires, des tableaux et de la pagination, une bibliothèque de 14 Ko qui échange des fragments HTML suffit. React + react-dom + router + couche de données atterrit typiquement à 150–300 Ko gzippés avant votre code.
• Core Web Vitals a monétisé la performance. Vous le sentez sur le SEO et les parcours d’activation. Réduire l’hydratation est le gain INP/LCP le plus rapide qui reste à beaucoup d’équipes.
• Les frameworks serveur ont énormément progressé. Rails 7 + Hotwire, Django + htmx, Phoenix LiveView, Laravel Livewire, Astro Islands — nous ne sommes plus en 2013. MPA + îlots sélectifs est une voie de premier plan.

React est excellent — jusqu’à ce qu’il ne le soit plus

React reste un excellent choix lorsque votre produit est un canvas collaboratif riche en état (pensez à Figma, à l’éditeur de blocs de Notion, à des tableaux de bord très interactifs) ou exige des garanties offline‑first. Mais pour des workflows de saisie de données, des panneaux d’administration, des parcours marketing/cycle de vie utilisateur, des bases de connaissance, des pages de paramètres, vous payez un surcoût de plateforme permanent pour un problème que vous n’avez pas.

Si vous suspectez être dans ce cas, arrêtez le débat de goûts et faites parler les chiffres.

Le cadre de décision d’un CTO : faut‑il retirer React ?

Scorez votre produit sur cinq axes (0–5 chacun)

1. Densité d’interactivité. Combien de contrôles à état concurrents par vue ? 0 = formulaires/tableaux simples, 5 = composants imbriqués et déplaçables, éditeurs, widgets synchronisés. Seuil : si la moyenne par écran ≤ 2, score ≤ 2.
2. Collaboration temps réel. Multi‑curseur, présence, résolution de conflits. 0 = aucune, 5 = au cœur du produit. Seuil : toute valeur ≥ 3 vous maintient en mode SPA pour cette surface.
3. Offline/Sync en arrière‑plan. Doit‑il fonctionner avec une connectivité instable ? 0 = non, 5 = oui, avec un état local robuste. Offline ≥ 3 plaide pour une SPA ou du natif.
4. Modèle de navigation. Les vues sont‑elles autonomes avec des URL propres, ou s’agit‑il d’une grande scène unique ? 0 = compatible MPA, 5 = centré SPA avec état de scène partagé.
5. Pression réglementaire/SEO. Crawlabilité, déterminisme du rendu et confidentialité (pas de PII client dans le JS). 0 = faible, 5 = forte. Des valeurs élevées favorisent SSR/MPA.

Heuristique : Si votre moyenne pondérée ≤ 2,5, vous livrerez probablement plus vite, avec moins de crashs et de meilleurs scores avec une pile MPA + amélioration progressive. Si ≥ 3,5, gardez React là où il apporte un vrai levier. Si vous êtes au milieu, mixez : une coque MPA avec quelques îlots React ou Web Components.

Le cas financier : ce que vous cessez de payer

• La taxe bundle et hydratation. htmx fait ~14 Ko gzippés. Une pile React typique (react + react‑dom + router + query + votre colle) atterrit à 150–300 Ko gzippés. Élaguer 200 Ko et sauter l’hydratation apporte couramment 15–30 % de mieux en LCP et des gains marqués en INP sur des appareils milieu de gamme.
• Bugs d’état et temps d’astreinte. Incohérences d’hydratation, caches périmés, boucles d’effets — si vos rotations d’astreinte les connaissent par cœur, vous financez une machine de Rube Goldberg. Les équipes que nous avons sorties des patterns SPA réduisent régulièrement le volume d’incidents UI de 20–40 % en trois mois.
• Frein à la vélocité dev. Livrer un flux CRUD en React signifie souvent écrire le même schéma trois fois (serveur, client, validateur) et enfiler l’état à travers les couches query/mutation. Avec SSR + htmx, vous rendez une fois, vous améliorez progressivement où nécessaire, et vous vous appuyez sur des validations et transactions serveur éprouvées.

Architectures gagnantes en 2026

1) MPA + htmx (ou Turbo) + petites touches

Gardez votre framework serveur aux commandes. Rendez du HTML ; échangez des fragments via htmx ; ajoutez de petites touches alpine.js ou vanilla pour l’état UI local. Votre modèle mental est simple : l’URL correspond à une action serveur qui renvoie du HTML. L’amélioration progressive couvre 80 % de l’interactivité sans runtime d’état côté client complet.

2) MPA + îlots

Utilisez un framework à îlots (Astro, Marko, Qwik) pour livrer 90 % de HTML et réveiller des composants interactifs discrets à la demande. Pour des widgets complexes — grille de données avec virtualisation, éditeur WYSIWYG — montez un îlot React/Vue/Svelte dans une page autrement rendue côté serveur. Vous gardez React là où il se rentabilise.

3) SSR façon LiveView via websockets

Phoenix LiveView et des patterns similaires laissent le serveur posséder l’état tout en poussant des diffs au client. Ce modèle excelle pour une large gamme d’outils back‑office et de tableaux de bord avec un JS client minimal, de solides frontières de sécurité et d’excellentes performances.

Risques et arbitrages (ne prétendez pas qu’il n’y en a pas)

• Bassin de recrutement et momentum. React dispose du plus grand vivier de candidats et de l’écosystème le plus vaste. htmx et LiveView sont plus simples mais moins présents sur les CV. Atténuation : faites monter en compétences un pod nearshore pour poser les patterns et faire du pair avec votre équipe cœur pendant 8–12 semaines.
• Écosystème de composants. Les composants « React‑first » vous manqueront. Prévoyez des Web Components, du headless UI, ou construisez les quelques widgets à forte valeur une fois en îlots.
• Attentes en matière de routage client. Les transitions SPA peuvent paraître plus vives. Utilisez le préchargement piloté par le serveur, des alternatives à HTTP/2 push, et des échanges partiels pour obtenir 95 % de la sensation avec 5 % du code.
• Feature flags et infra d’A/B. Si votre outillage d’expérimentation est « JS‑first », vous aurez besoin de variantes côté serveur et d’un rendu déterministe. Bilan positif pour l’observabilité, mais un peu de plomberie au départ.

Migrer sans réécrire l’entreprise

Les réécritures complètes échouent. Étranglez la SPA à la place.

Phase 0 : instrumenter la douleur

• Mesurez l’existant. Core Web Vitals par chemin, octets JS par route, taux de crash, nombre d’erreurs d’hydratation, INP p95 sur Android milieu de gamme.
• Taguez vos surfaces. Étiquetez les routes en CRUD, marketing, paramètres, éditeur, dashboard, etc. Vous ne les migrerez pas toutes au même rythme.

Phase 1 : prouvez‑le sur des surfaces à faible risque (2–4 semaines)

• Parcours marketing et auth. Passez login, signup, reset mot de passe, vérification d’email en SSR. Ils bénéficient de toute façon d’un rendu déterministe et du SEO.
• Paramètres et profils. Remplacez l’état client par des formulaires serveur et des échanges de fragments htmx. Attendez‑vous à des gains immédiats de bundle et à moins de bugs de cas limites.
• Mesurez à nouveau. Si vous ne voyez pas des améliorations à deux chiffres sur LCP/INP et une baisse des incidents UI sur ces chemins, stoppez. Votre SPA est peut‑être justifiée.

Phase 2 : extraire une coque rendue côté serveur (4–8 semaines)

• Route par route, déplacez navigation, en‑têtes, pieds de page et la plupart des pages vers le rendu serveur. Gardez vos widgets complexes montés en îlots React à l’intérieur de ces pages. Vous obtenez 80 % des bénéfices sans toucher à votre UI la plus dure.
• Adoptez une API de fragments. Standardisez des endpoints qui renvoient du HTML partiel pour les listes, la pagination et le contenu des modales. Elles deviennent vos nouvelles primitives d’UI.
• Validations partagées. Centralisez schéma et validation côté serveur. Le client fait de l’amélioration progressive, pas de la logique métier.

Phase 3 : décider du sort de vos widgets complexes (8–16 semaines)

• Gardez React là où il paie. Éditeurs, grilles de données lourdes, collab temps réel : laissez‑les en îlots. Utilisez l’hydratation paresseuse et ne shippez du code que là où c’est nécessaire.
• Simplifiez quand c’est possible. Beaucoup de widgets « complexes » ne sont pas au cœur de la valeur. Une table paginée et un formulaire en modale peuvent remplacer un combo grille+édition inline sans dégrader l’UX.

Gouvernance et garde‑fous de performance

• Fixez des budgets. Budget JS par route (par ex., ≤ 50 Ko gz pour les pages sans îlot), seuils INP p75, budgets d’erreurs pour les incohérences d’hydratation (objectif : zéro sur les routes MPA).
• Codeowners et ADR. Toute nouvelle surface SPA requiert un Architecture Decision Record avec justification explicite au regard des cinq axes. Par défaut : MPA + amélioration.

Sécurité, confidentialité et conformité s’en trouvent simplifiées

• Moins de PII côté client. Rendre côté serveur permet d’éviter d’envoyer des champs sensibles au navigateur avant que ce soit absolument nécessaire. Vous réduisez votre surface d’exposition.
• Moins d’effets de bord transverses. Pas de caches client tentaculaires ni de stores globaux qui fuient l’état entre locataires ou sessions.
• Audit déterministe. Ce que le serveur a rendu est ce que l’utilisateur a vu. C’est essentiel pour des parcours réglementés et les obligations légales.

Exemples concrets pour caler votre intuition

• Basecamp/HEY a popularisé Hotwire/Turbo pour alimenter un SaaS complexe sans runtime SPA, avec de gros gains de performance et de complexité à la clé.
• GitHub utilise depuis longtemps des techniques type PJAX/Turbo avec HTML rendu serveur et petites touches. Personne ne traite GitHub de lent.
• Des équipes Django + htmx livrent des produits riches en admin en semaines, pas en mois, en s’appuyant sur des formulaires serveur, des transactions et une UI optimiste via des échanges de fragments.

Ce ne sont pas des jouets. Ils prouvent que si votre proposition de valeur est le workflow et la justesse des données — pas un canvas multi‑utilisateur au pixel près — l’approche server‑first fonctionne et passe à l’échelle.

Comment nous menons cela en engagement nearshore

Si vous n’avez pas la bande passante pour livrer ce chantier seul, amorcez‑le avec un pod qui a déjà expédié ce pattern à répétition. Nos équipes basées au Brazil travaillent sur vos horaires (6–8 heures de recouvrement avec le fuseau U.S.) et commencent par une preuve en deux sprints sur des flux à faible risque. Nous codifions les patterns, construisons votre API de fragments et vous laissons avec des budgets, des règles de lint et une trajectoire de migration. Vous gardez React là où il a du sens ; vous cessez d’hydrater le reste.

FAQ pour CTO sceptiques

« Nous avons investi dans un design system construit sur React. Allons‑nous le jeter ? »

Non. Traitez‑le comme une bibliothèque d’îlots. Exportez des primitives headless en Web Components quand c’est pertinent. La plupart des tokens visuels, du CSS et du travail d’accessibilité se transfèrent proprement.

« Quid du cache client complexe et des mises à jour optimistes ? »

Mettez la cohérence en premier : mutations autoritatives côté serveur, emballées dans des transactions. Pour la vitesse perçue, streamez des partiels, utilisez agressivement le cache HTTP et appliquez une UI optimiste sur la poignée d’interactions qui le justifient. Vous n’avez pas besoin d’un cache client global pour une page de paramètres.

« Allons‑nous perdre des transitions nerveuses ? »

Utilisez le préchargement côté client au survol, les liens « boosted » htmx et les échanges partiels. La différence vs SPA est négligeable quand vous n’exigez pas d’un téléphone milieu de gamme qu’il parse 300 Ko de JS au préalable.

« N’est‑ce pas échanger une complexité contre une autre ? »

Si — sauf que la nouvelle complexité est plus proche de vos données et invariants, là où vous avez déjà tests, transactions et observabilité. C’est un meilleur endroit pour dépenser votre budget de complexité limité.

Une règle simple que vous pouvez défendre auprès de votre CEO

Si un écran peut se résumer à « charger des données, rendre un formulaire/tableau, soumettre et afficher le résultat », il est coupable jusqu’à preuve du contraire de nécessiter un runtime SPA. Utilisez React lorsque la collaboration, l’offline ou un calcul client lourd le rendent clairement moins cher. Partout ailleurs, cessez de payer la taxe d’hydratation.

Points clés

• Par défaut, MPA + amélioration progressive ; ajoutez React en îlot là où il se rentabilise.
• Scorez chaque surface sur la densité d’interactivité, la collaboration, les besoins offline, le modèle de navigation et la pression SEO/réglementaire.
• Attendez‑vous à 15–30 % de gains LCP/INP et 20–40 % d’incidents UI en moins lorsque vous déshydratez les surfaces CRUD.
• Migrez en étranglant la SPA : commencez par l’auth, le marketing et les paramètres ; puis extrayez une coque rendue côté serveur ; gardez les widgets complexes en îlots.
• Fixez des budgets JS par route et exigez des ADR pour toute nouvelle surface SPA.
• La sécurité et la conformité s’améliorent avec un rendu déterministe côté serveur et moins de PII côté client.
• Faites intervenir un pod nearshore aguerri pour poser les patterns, faire du pair avec votre équipe, et sortir avec des garde‑fous en 8–12 semaines.

Auteur : Diogo Hudson Dias