Une interface riche, posée dans ce que vous avez déjà
React n’est pas un framework de site : c’est une bibliothèque d’interface. Son terrain, c’est l’écran complexe — un back-office, un configurateur, un tableau de bord — pas forcément le site entier.
- Un écran riche sans réécrire l’application qui l’accueille
- Adossé à vos API existantes, en REST ou GraphQL
- Le vivier de développeurs le plus large du marché
- Développé et hébergé en France, sur notre infrastructure
Le principe
Ce que React est, et ce qu’il n’est pas
Une bibliothèque, pas un framework
React ne sait faire qu’une chose : tenir une interface à jour quand les données changent. Il ne gère ni les URL, ni le rendu côté serveur, ni la récupération des données. Ce sont des outils construits par-dessus qui s’en chargent — Next.js pour l’essentiel.
Cette étroitesse est un défaut quand on veut un site, et une qualité quand on veut un écran. Un configurateur de produit, un back-office, un tableau de bord : autant de cas où l’interface est complexe mais où l’application qui l’entoure existe déjà, en PHP, en Python ou en Java.
Le cas qui revient le plus souvent
Une application métier fonctionne, elle rend service, et un seul de ses écrans est devenu insupportable — trop d’états à tenir, trop d’allers-retours avec le serveur. Réécrire l’ensemble serait absurde. Poser React sur ce seul écran, en le branchant sur les API existantes, coûte une fraction du prix et se livre en semaines.
C’est aussi ce qui rend la décision réversible : si l’écran ne convient pas, on le remplace sans toucher au reste.
Ce qu’il faut savoir avant de choisir
Une interface React construite dans le navigateur n’est pas indexable simplement — c’est très complexe, souvent impossible. Pour un back-office, la question ne se pose pas : on ne référence pas un espace connecté. Pour une page publique, elle décide de l’architecture, et la réponse s’appelle alors Next.js.
L’autre question est humaine. React est la bibliothèque d’interface la plus répandue : le vivier de développeurs est large, et vos équipes ont des chances de la pratiquer. C’est un argument de reprise, et il pèse souvent plus lourd que les mérites techniques.
Les usages
Ce que nous construisons avec
-
Back-offices et tableaux de bord
Beaucoup d’états à tenir entre écrans, des données qui changent sous les yeux de l’utilisateur. C’est là que React gagne vraiment.
-
Configurateurs et simulateurs
Un formulaire dont chaque réponse change les suivantes. Recharger la page à chaque étape rend l’outil pénible ; React l’évite.
-
Un écran dans un existant
Posé sur une application Symfony, Laravel, Python ou Java qui reste en place. Le reste de l’application ne bouge pas.
-
Adossé à vos API
REST ou GraphQL, sur vos systèmes existants — que nous pouvons aussi construire, en Symfony, Python, Java, Go ou Node.js.
-
Repris par vos équipes
Le vivier React est le plus large du marché. Si votre équipe le pratique déjà, c’est un argument que nous prenons au sérieux.
-
Développé et hébergé ici
Sur notre infrastructure nantaise, sans dépendre d’une plateforme dont la facture suit le trafic.
Questions fréquentes
React : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
React ou Next.js ?
React seul quand l’interface s’insère dans une application qui existe déjà et qui garde ses URL. Next.js quand le projet EST le site : il ajoute le routage et le rendu côté serveur, donc l’indexation. La question à poser d’abord est celle-là — construisez-vous un écran, ou un site ?
React ou Vue ?
Techniquement, les deux font le même travail et le choix se joue ailleurs. React a le vivier le plus large ; Vue s’adopte plus progressivement, page par page, sans réécrire l’existant. Si vos équipes en pratiquent une, c’est celle-là.
Mon écran React sera-t-il référencé ?
Non, s’il est construit dans le navigateur : c’est très complexe à indexer, souvent impossible. Pour un espace connecté, cela n’a aucune importance. Pour une page publique, il faut un rendu côté serveur, et l’outil s’appelle alors Next.js.
Faut-il tout réécrire pour commencer ?
Non, et c’est l’intérêt principal de cette approche. React s’installe sur un seul écran, branché sur vos API existantes. Le reste de l’application continue de tourner comme avant, et la décision reste réversible.
Qui pourra reprendre le code ensuite ?
C’est la question à se poser avant de choisir, et elle pèse plus que les mérites techniques. Le meilleur outil est celui que ceux qui reprendront le projet savent lire. Nous documentons le code et nous le remettons ; s’il doit vivre chez vous, autant qu’il soit écrit dans ce que vous pratiquez.
Un écran, ou toute l’application ?
La réponse décide de l’outil, du budget et de ce qu’il faudra reprendre plus tard. Elle se tranche en une conversation.