Partenaire technologique — Paris & New York
Applications métier, interfaces de données et reprises de code existant — construites pour être maintenables dans deux ans, pas seulement livrables dans deux mois.
Réponse sous 24h.
React n'est pas un framework, c'est une bibliothèque d'interface. Elle résout un problème précis et le résout mieux que le reste : décrire une interface comme une fonction de son état, et laisser la bibliothèque se charger de mettre l'affichage à jour. Tout le reste — le routage, l'accès aux données, l'authentification, le rendu serveur — reste à votre charge.
C'est cette différence qui explique pourquoi la question « React ou Next.js » revient dans presque tous nos premiers échanges. La réponse dépend d'une seule chose : votre produit doit-il être trouvé sur Google et s'afficher instantanément pour un visiteur qui ne vous connaît pas ? Si oui, vous voulez un framework. Si votre produit vit derrière un écran de connexion, React seul est souvent le choix le plus sobre et le moins coûteux à maintenir.
Nous travaillons avec React sur la majorité des produits que nous livrons, seul ou à l'intérieur de Next.js. Deux situations nous sont confiées plus souvent que les autres : une application métier à construire de zéro, et un code React existant qu'il faut reprendre en main.
Savoir écrire du React n'est pas un différenciateur. Le vivier de développeurs React est le plus large de l'écosystème web, et des milliers de prestataires savent produire des composants qui fonctionnent. Ce qui sépare un projet qui tient d'un projet qui s'enlise, ce sont les décisions prises avant la première ligne de code : où vit l'état, comment les données arrivent, ce qui est un composant réellement réutilisable et ce qui ne le sera jamais.
Ces décisions ne se rattrapent pas facilement. Une application de dix-huit mois dont la gestion d'état a été improvisée devient un produit où chaque nouvelle fonctionnalité casse deux écrans ailleurs, et où plus personne n'ose déployer un vendredi. Nous rencontrons ce cas régulièrement : ce n'est presque jamais un problème de compétence des développeurs précédents, c'est un problème d'arbitrage que personne n'était en position de trancher.
C'est exactement le rôle que nous prenons. Loïc Guillebeau, fondateur de Beyond The Brackets, développe depuis ses 14 ans et a cofondé sa propre startup en 2021 : les arbitrages techniques avec de l'argent réel en jeu, il les a faits pour lui-même avant de les faire pour vous. Vous n'obtenez pas une équipe qui exécute un cahier des charges, vous obtenez quelqu'un qui vous dit quand le cahier des charges est le vrai problème.
Outils internes derrière authentification : gestion, suivi d'activité, administration. Aucun enjeu de référencement, donc aucune raison de payer la complexité d'un rendu serveur. React avec Vite, une API dédiée, et rien de plus.
Visualisations, filtres croisés, mises à jour temps réel via WebSocket. C'est le terrain où React est le plus clairement supérieur : beaucoup d'état, beaucoup d'interactions, peu de navigation entre pages.
Un code livré par un prestataire précédent, un développeur parti sans passation, une équipe qui n'ose plus déployer. Nous commençons par un audit technique d'une journée : ce qui est sain, ce qui doit être réécrit, ce qui peut attendre — hiérarchisé et chiffré.
Une base de composants partagée entre plusieurs produits, documentée dans Storybook et versionnée. L'investissement devient rentable dès le deuxième produit qui la consomme.
Un configurateur, un simulateur, un parcours de réservation à insérer dans un site WordPress ou Shopify sans le refondre. React se monte sur un conteneur isolé et cohabite avec l'existant.
Nous commençons par une journée de cadrage, pas par du code. Sur une application React, la question structurante est toujours la même : quelles données existent, qui les modifie, et où vit la vérité. Y répondre en amont détermine la moitié de la maintenabilité du produit final.
Notre outillage par défaut : TypeScript en mode strict, Vite pour la chaîne de build, TanStack Query pour tout ce qui vient du serveur, et un store léger — Zustand ou le contexte React — uniquement pour l'état réellement global. Nous ne déployons pas Redux par réflexe : dans la majorité des applications que nous reprenons, il porte de l'état qui n'aurait jamais dû y être.
Le développement avance par cycles courts, avec un environnement de préproduction accessible en permanence. Vous voyez le produit progresser chaque semaine — vous ne le découvrez pas le jour de la livraison.
Nous travaillons dans vos canaux : un Slack partagé, un point hebdomadaire, une roadmap visible. Le modèle inverse — prendre un brief et disparaître trois mois — est précisément celui que nous refusons.
Grace, notre pipeline multi-agents interne, absorbe une partie du travail répétitif : scaffolding, revue de code de premier niveau, couverture de tests. Cela nous permet d'aller plus vite sans réduire la qualité, et cela reste un outil interne — le code que vous recevez est relu par un humain.
| Langage | TypeScript |
|---|---|
| Nature | Bibliothèque d'interface, pas framework complet |
| Outillage | Vite, TanStack Query, Zustand, Vitest |
| Backend | NestJS ou Node.js, PostgreSQL |
| Rendu | Côté client (SPA) — pour du rendu serveur, voir Next.js |
| Délai d'un premier MVP | 5 à 9 semaines selon le périmètre |
Une application métier avec authentification, deux ou trois parcours principaux et un back-office se situe généralement entre 20 000 € et 50 000 €. Le facteur de coût dominant n'est presque jamais l'interface : ce sont les intégrations avec vos systèmes existants et le nombre de cas particuliers dans vos règles métier. Notre simulateur donne une première fourchette en une minute, et une journée de cadrage donne un chiffre sur lequel on peut s'engager.
Posez-vous une seule question : des visiteurs qui ne vous connaissent pas doivent-ils arriver sur ce produit depuis Google ? Si oui, Next.js — vous avez besoin du rendu serveur, du référencement et de la vitesse de premier affichage. Si votre produit vit derrière un écran de connexion, React seul suffit et restera plus simple à maintenir. Next.js contient React : ce ne sont pas deux options concurrentes, c'est un choix de niveau d'équipement.
Oui. Le nom officiel est React ; « React.js » et « ReactJS » sont des usages courants hérités de la convention de nommage JavaScript. Il n'existe qu'une seule bibliothèque. À ne pas confondre avec React Native, qui applique le même modèle de composants aux applications mobiles iOS et Android.
Oui, et c'est une part importante de ce que nous faisons. Nous commençons systématiquement par un audit technique d'une journée avant tout engagement : état des dépendances, couverture de tests, architecture de l'état, dette identifiée et hiérarchisée. Vous en ressortez avec un document exploitable, même si vous décidez ensuite de ne pas travailler avec nous.
Oui. C'est la bibliothèque d'interface la plus utilisée en production, avec l'écosystème le plus large et le vivier de développeurs le plus profond. Ce dernier point compte autant que la technique : vous devrez un jour recruter, ou faire reprendre ce code par quelqu'un d'autre. Les alternatives récentes sont bonnes techniquement, mais vous exposent à un marché de compétences plus étroit.
Vous, intégralement. Nous livrons le dépôt, la documentation technique et les accès d'infrastructure à votre nom. Aucune brique propriétaire de notre part n'est nécessaire pour faire tourner ou faire évoluer le produit. C'est vérifiable, et vous devriez le vérifier avec n'importe quel prestataire.
30 minutes avec Loïc pour auditer votre situation technique et identifier votre plus grande opportunité. Sans engagement.
Réserver un appel stratégique