[ Missions remote · Next.js et React ]

Next.js, React,TypeScript.Et personne entrevous et le code.

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.

Remote, France entière — depuis Saint-Joseph, La Réunion
[ Pour qui ]

Quatre façons de me faire intervenir.

[ Agences et studios ]

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.

[ Éditeurs et startups ]

Le produit de bout en bout

Architecture, comptes, encaissement, mise en production. Deux SaaS conçus et développés entièrement de cette manière, sans équipe autour.

[ Équipes produit ]

Une brique isolée, ou une migration

Une fonctionnalité complexe à absorber, un passage à l’App Router à mener, une architecture à remettre à plat. Périmètre borné, restitution écrite.

[ Projet déjà cadré ]

Au forfait ou en régie

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.

[ Ce que je fais ]

Quatre natures de mission.

  • Applications SaaS de bout en bout

    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.

    Le détail du développement SaaS ↗

  • Interfaces produit et back-offices

    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.

  • Intégrations et synchronisations

    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.

  • Reprise de codebase et audit d’architecture

    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.

    La revue de sécurité applicative ↗

[ La stack ]

  • Cœur
    • Next.js
    • React
    • TypeScript strict
  • Données
    • Node.js
    • PostgreSQL
    • Prisma
    • Supabase
  • Interface
    • Tailwind CSS
    • GSAP
  • Comptes et paiements
    • Auth.js
    • Supabase Auth
    • Stripe
  • Livraison
    • Git
    • GitHub Actions
    • Serveur dédié
  • Qualité
    • Vitest
    • Revue de sécurité OWASP
[ Pourquoi ce cadre-là ]

Ce que Next.js ajoute à React.

Indexable dès le premier octet

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.

Moins de JavaScript envoyé

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.

Une seule base de code

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.

Le sensible reste au serveur

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.

L’écosystème React

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à.

Un socle qu’on peut reprendre

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.

[ Travailler ensemble ]

M’intégrer ne doit rien
vous coûter en pilotage.

  1. Vos conventions, pas les miennes

    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.

  2. Des PR relues avant d’être soumises

    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.

  3. L’asynchrone par défaut

    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.

  4. Une passation, pas une dépendance

    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.

[ Est-ce le bon outil pour vous ]

Le bon choix si

  • Vos pages doivent être indexées et s’afficher vite
  • Votre produit a des utilisateurs, des rôles et des droits
  • Votre contenu bouge souvent et doit rester à jour dans l’index
  • Vous avez des données à croiser entre plusieurs services
  • Votre équipe pratique déjà React

Probablement surdimensionné si

  • Votre projet tient en une page statique sans logique : un générateur plus simple ira plus loin, plus vite
  • Personne chez vous ne pratique React — la maintenance retombera intégralement sur un prestataire
  • Votre back-end impose Laravel, Rails ou Django : je peux prendre l’interface, pas le reste

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.

[ Questions fréquentes ]
  • Quelle est la différence entre React et Next.js ?

    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.

  • Vous intervenez sur un projet existant, ou seulement depuis zéro ?

    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.

  • Vous travaillez au forfait ou en régie ?

    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.

  • Comment se passe l’intégration à une équipe déjà en place ?

    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.

  • Vous êtes à La Réunion : comment se gèrent les horaires ?

    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.

  • Sous quel délai peut-on démarrer ?

    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.

Un projet, ou une équipe à renforcer ?

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.

Parler de votre besoin ↗