React chez Digitz
Il y a un moment précis où une page web cesse d'être une page et devient un outil. Tant que l'écran affiche du contenu, qu'on lit et qu'on parcourt, la question React ne se pose pas. Elle arrive quand l'utilisateur se met à manipuler : il filtre une liste de huit cents lignes sans recharger, il fait glisser une carte sur un planning, il voit un total se recalculer pendant qu'il tape, il bascule entre quatre vues d'un même jeu de données. À ce stade, le navigateur ne sert plus à montrer, il sert à travailler. C'est là que le front applicatif prend la main, et React est l'outil qu'on sort pour ça.
On documente ce qu'on produit. Pas l'inverse.
Le réflexe du marché va dans l'autre sens. React est devenu la réponse par défaut, y compris pour des sites qui n'en ont aucun besoin. On a vu des pages de présentation, trois rubriques et un formulaire de contact, livrées en single page application avec un bundle JavaScript de plusieurs centaines de kilo-octets, un écran blanc le temps que tout se charge, et un référencement qui peine parce que le contenu n'existe qu'une fois le script exécuté. Le résultat est plus lent à afficher, plus lourd à maintenir et plus fragile qu'une page rendue côté serveur. Sortir React pour un site de contenu, c'est mettre un moteur de course dans une voiture de ville : la puissance ne sert à rien et la facture d'entretien grimpe.
Notre ligne tient en une phrase. React quand l'interactivité est le sujet, autre chose quand elle ne l'est pas. Un site éditorial, une vitrine, un catalogue qu'on consulte, ça vit très bien sur un CMS ou sur un front statique comme Astro, qui envoie au visiteur du HTML déjà prêt et n'embarque du JavaScript que sur les rares zones qui en demandent. La page s'affiche tout de suite, les moteurs lisent le contenu sans exécuter quoi que ce soit, et il n'y a pas une couche d'application à entretenir pour rien. On choisit la stack pour ce que l'écran doit faire une fois qu'il est devant l'utilisateur.
Quand le besoin franchit le seuil applicatif, en revanche, React tient ses promesses et on ne lui cherche pas de remplaçant. Le cas le plus net, c'est l'espace connecté. Un client se logue, retrouve ses données, agit dessus : il suit ses commandes, télécharge ses documents, met à jour son dossier, déclenche une demande et en voit l'avancement. Rien de tout ça ne se range dans des pages de contenu. C'est une application, avec des états, des droits, des écrans qui dépendent de qui regarde et de ce qu'il a déjà fait. React gère cette mécanique : l'interface se met à jour quand la donnée change, sans que la page entière se recharge, et le code reste organisé par composant, lisible et reprenable.
Les tableaux de bord relèvent de la même logique. Une direction veut suivre son activité en temps réel, croiser des indicateurs, filtrer par période, par site, par équipe, exporter une vue. Tout se joue dans l'écran, sans aller-retour serveur à chaque clic. L'utilisateur déplace un curseur et la courbe répond, il coche un filtre et le tableau se réordonne, il ouvre un détail sans perdre le contexte autour. Construire ça en pages classiques mènerait à un rechargement permanent et à une lenteur qui décourage l'usage. React maintient l'état à l'écran et ne redessine que ce qui bouge. Pour un outil que des gens ouvrent toute la journée, cette réactivité fait la différence entre un tableau qu'on consulte et un tableau qu'on délaisse.
Vient ensuite la famille des outils métier internes. Le logiciel maison qu'une équipe utilise pour saisir, valider, router, le back-office d'une plateforme, l'écran de gestion qui remplace un tableur devenu ingérable. Ces interfaces ne se voient pas du public, mais ce sont elles qui portent le travail quotidien. Elles ont besoin de formulaires qui réagissent, de validations qui s'affichent au bon moment, d'enchaînements d'écrans qui suivent un processus réel. React s'y prête parce qu'il rend ces interactions naturelles à écrire et lisibles à reprendre. Un outil interne mal fichu fait perdre du temps à chaque manipulation, et ce temps se paie tous les jours. Un outil bien construit se range, et celui qui le reprend dans deux ans comprend comment il tient.
Reste le morceau d'interface riche posé dans un site qui, lui, n'a pas besoin d'être une application. Un configurateur de produit où l'utilisateur compose et voit le rendu changer, un simulateur qui calcule à mesure qu'on remplit, une carte interactive, un parcours en plusieurs étapes avec sa logique conditionnelle. Là, on ne refait pas tout le site en React. On garde le site sur sa base de contenu, rapide à servir et simple à éditer, et on greffe le composant React juste sur la zone qui le réclame. Le reste de la page reste statique. C'est cette précision qui évite la dérive : on pose la couche applicative exactement où l'interaction l'exige, et seulement là.
Entre React seul et Next, la frontière se décide au cadrage. Une application qui vit derrière un login, dont les écrans n'ont aucune raison d'être indexés, tourne très bien en single page application servie au navigateur : personne ne cherche un tableau de bord sur un moteur de recherche. Mais dès qu'une interface riche doit aussi être trouvée et lue par les moteurs, ou s'afficher vite sur un premier accès, on passe à Next, qui rend les pages côté serveur et garde l'interactivité de React par-dessus. Le contenu part déjà prêt, le référencement suit, et l'application reste réactive une fois chargée. Ce choix se tranche sur des critères concrets. Selon que les écrans doivent être publics ou non, rapides au premier affichage ou non, l'un ou l'autre s'impose.
Au-delà de la stack, ce qui distingue un front applicatif qui tient d'un autre qui se dégrade, c'est l'état. Une application, c'est de la donnée qui vit à l'écran : ce que l'utilisateur a saisi, ce qu'il a sélectionné, ce que le serveur vient de renvoyer, ce qui est en cours de chargement. Mal géré, cet état devient le point où tout casse : des écrans qui se désynchronisent, un bouton qui reste actif alors qu'il ne devrait plus, une donnée affichée qui ne correspond plus à la réalité. On traite ce sujet de front dès la conception de l'interface, parce qu'une application se juge moins sur sa première démo que sur sa tenue après six mois d'évolutions et de cas particuliers ajoutés un à un.
Le même soin vaut pour la performance, qui ne se mesure pas comme sur un site de contenu. Sur une vitrine, ce qui compte, c'est la vitesse du premier affichage. Sur une application, l'utilisateur passe des minutes ou des heures dans l'écran, et ce qui compte, c'est que chaque interaction réponde sans accroc, que l'interface ne rame pas quand la liste grossit, que le navigateur ne sature pas au fil de la session. Ça se construit délibérément : ne recalculer que ce qui change, ne charger les écrans lourds qu'au moment où on y arrive, garder un volume de code raisonnable et trié. Un front applicatif lent finit délaissé, et l'outil qu'on a payé ne sert plus.
On écrit ce code pour qu'une autre équipe le reprenne, comme sur le reste de notre développement. React rend la chose plus exigeante qu'un site classique, parce qu'une application a une logique interne qu'il faut pouvoir relire. On organise par composant, on nomme clairement, on isole la logique des données de l'affichage, on documente les choix qui ne sont pas évidents. L'objectif ne change pas : qu'une équipe interne qui grandit ou un autre prestataire après un appel d'offres puisse ouvrir le projet et avancer, sans avoir à le réécrire pour le comprendre. Une application qu'on ne peut confier à personne d'autre reste une dépendance qui vous pèse.
L'IA, quand elle a sa place, se branche sur cette base sans la commander. Une zone de recherche qui comprend la question en langage naturel, un assistant intégré à un espace connecté, une suggestion qui s'affiche au bon endroit d'un parcours : ce sont des fonctions qui se posent dans l'interface React une fois que le socle tient. Elles ne dictent pas l'architecture et ne justifient pas à elles seules de partir sur du front applicatif. Quand l'interactivité appelle React et que l'IA apporte un gain réel par-dessus, les deux se rejoignent proprement. Quand l'IA sert d'argument pour habiller un projet qui n'en a pas besoin, on l'écarte avant de commencer.
Au fond, le choix de React se ramène à une question simple, qu'on pose dès le cadrage. L'écran doit-il réagir, garder un état, faire travailler l'utilisateur dans le navigateur ? Si oui, on est sur du front applicatif et React, ou Next quand le rendu serveur compte, est le bon outil. Si l'écran sert à lire et à parcourir, un CMS ou un front statique fait mieux le travail, pour moins cher et avec moins à entretenir. La plupart des projets se rangent clairement d'un côté ou de l'autre. Pour les rares cas mixtes, un site de contenu avec un morceau d'interface vivante, on assemble les deux et chacun joue son rôle. La vraie compétence, c'est de savoir quand React s'impose et quand un outil plus léger suffit.