Un renfort qu’il ne faut pas piloter
Un projet React ou Next.js à sortir, pas la ressource en interne. Je reprends vos conventions, vos outils et votre rythme de livraison, et je travaille en asynchrone.
Développeur freelance en remote, pour les agences, les éditeurs et les équipes produit. Renfort sur un projet en cours, fonctionnalité complexe à absorber, migration ou reprise de codebase.
Un projet React ou Next.js à sortir, pas la ressource en interne. Je reprends vos conventions, vos outils et votre rythme de livraison, et je travaille en asynchrone.
Architecture, comptes, encaissement, mise en production. Deux SaaS conçus et développés entièrement de cette manière, sans équipe autour.
Une fonctionnalité complexe à absorber, un passage à l’App Router à mener, une architecture à remettre à plat. Périmètre borné, restitution écrite.
Le forfait quand le périmètre est écrit, la régie quand les spécifications bougent encore. On tranche au premier échange, pas après la signature.
De l’architecture à l’exploitation : comptes et rôles, abonnements, tableaux de bord, déploiement. Le produit complet, pas la vitrine qui le présente.
Tableaux de bord, outils internes, portails clients. Composants réutilisables et conventions explicites, pour que votre équipe reprenne le code sans avoir à le déchiffrer.
Connexion à des services tiers et à des API métier, synchronisations entre plateformes, traitements planifiés. Les cas d’erreur sont traités avant la mise en service, pas après le premier incident.
Revue du code existant, relevé de la dette et des goulots de performance, feuille de route priorisée. Livrable écrit, chiffré, exploitable par quelqu’un d’autre que moi.
Les pages sont rendues côté serveur : leur contenu existe dans le HTML, avant tout script. Un moteur de recherche le lit sans avoir à exécuter l’application.
Les Server Components restent sur le serveur. Le navigateur ne reçoit que ce qui a besoin d’être interactif, ce qui se voit directement sur l’affichage des premières pages.
Server Actions, route handlers et middleware vivent dans le même projet que l’interface. Plus de frontière à maintenir entre deux dépôts qui doivent rester d’accord.
Clés d’API, requêtes en base et vérification des droits ne descendent jamais dans le navigateur. La surface exposée est réduite par construction, pas par vigilance.
Bibliothèques, composants, outillage et documentation sont abondants et à jour. Ce n’est pas un pari technique : c’est ce que la majorité des équipes front pratiquent déjà.
Conventions stables, documentation officielle exhaustive, montées de version documentées. Le jour où vous reprenez la main, vous trouvez des développeurs qui connaissent déjà le terrain.
Workflow Git, nommage, structure de dossiers, outils de suivi : je m’aligne sur l’existant. Une mission n’est pas le bon moment pour imposer ses habitudes.
Chaque contribution passe par ma propre relecture avant d’arriver chez vous : périmètre lisible, message de commit explicite, rien qui ne casse la CI.
L’écrit sert de trace, les points en visio servent aux décisions. Je m’adapte à vos rituels quand vous en avez, sans en ajouter quand vous n’en avez pas.
Documentation technique, décisions d’architecture consignées, environnements reproductibles. L’objectif est que la mission puisse s’arrêter sans que le projet s’arrête.
Dans le doute, le premier échange sert exactement à ça. Je vous dirai si Next.js est surdimensionné pour votre cas — c’est arrivé, et ça fait gagner du temps aux deux.
React est une bibliothèque d’interface : elle dessine des composants dans un navigateur. Next.js est un cadre applicatif construit dessus, qui ajoute le rendu côté serveur, le routage, les Server Components, les Server Actions et le déploiement. En pratique : React seul livre une page vide que le navigateur remplit ; Next.js livre une page déjà écrite.
Les deux, et la reprise est le cas le plus fréquent. Une codebase Next.js ou React déjà en place peut être auditée, corrigée et étendue — la première semaine sert alors à lire le code et à écrire ce que j’y ai compris, avant de proposer quoi que ce soit.
Les deux. Le forfait suppose un périmètre écrit et stable : il protège autant votre budget que mon planning. La régie convient quand les spécifications évoluent encore, ou pour un renfort continu dans une équipe. Le mode est tranché au cadrage, avant le devis.
Je m’aligne sur vos conventions plutôt que d’imposer les miennes : workflow Git, nommage, outils de suivi, rituels. Chaque contribution arrive en pull request relue, avec un périmètre lisible. La communication se fait à l’écrit, les points en visio servant aux décisions.
La Réunion est en avance de deux heures sur la France métropolitaine l’été, de trois heures l’hiver. Concrètement, mes matinées recouvrent vos débuts de journée et je réserve ce créneau aux échanges en direct. Le reste tient à l’écrit, ce qui est de toute façon la bonne pratique en remote.
Cela dépend des missions en cours — c’est la question à poser au premier échange plutôt qu’à lire sur une page, où la réponse serait périmée le lendemain. Pour un engagement long, prévoir deux semaines entre l’accord et le démarrage effectif reste le plus confortable.
Décrivez le contexte et le périmètre : je vous dis sous 48 h si je suis disponible, à quel format, et si je suis la bonne personne pour ce que vous avez à faire.