Next.js · Suisse

Développeur Next.js en Suisse.

Je construis des applications Next.js de production : App Router, composants serveur par défaut, server actions pour les formulaires, Postgres ou Supabase pour les données, Stripe pour les paiements, Resend pour les emails, cache et rendu adaptés à chaque page, SEO et données structurées intégrés, monitoring et déploiement sur Vercel. Sept de mes propres produits tournent sur cette stack ; ce site aussi.

Mis à jour le

En bref

Où
Zürich, Suisse — à distance dans toute la Suisse et en Europe
Version
Next.js 16, App Router, React 19, React Compiler, TypeScript strict
Données
Postgres (Supabase ou Neon), migrations versionnées, accès typé
Paiements · Emails
Stripe avec webhooks signés · Resend + React Email
Déploiement
Vercel — preview par branche, Fluid Compute, analytics
Construits et exploités
Atamatax · Horvera · Wabiro (en production) · SponsorsMetrics (bêta privée) · bynilson.ch

Next.js est le cadre le plus productif que je connaisse pour livrer un produit web complet avec une seule personne — à condition de l’utiliser comme un cadre de production, pas comme un générateur de démos. La différence tient à quelques décisions : ce qui se rend sur le serveur, où vit la logique métier, comment les données sont validées, ce qui est mis en cache et comment on sait que ça marche.

Cette page répond à une question commerciale : pourquoi me confier une application Next.js plutôt qu’à une agence ou à un généraliste. La réponse est dans les produits en bas de page — et dans la manière dont ils sont construits.

01 — Production

Ce qu’une application Next.js de production exige

Les décisions qui séparent un projet Next.js qui tient de celui qu’on réécrit au bout d’un an.

App Router et composants serveur
Le rendu par défaut se fait sur le serveur : moins de JavaScript envoyé, des pages lisibles par les moteurs sans exécution, des données lues directement là où elles s’affichent. Les composants clients sont l’exception, réservés à l’interactivité réelle.
Server actions pour les formulaires
Un formulaire est un `<form>` lié à une action serveur : il fonctionne sans JavaScript, se valide côté serveur avec Zod, redirige vers son état de résultat. Pas de couche API à maintenir pour chaque écran.
Routes API là où il le faut
Les webhooks Stripe, les intégrations tierces et les endpoints publics restent des route handlers — signés, idempotents, journalisés. Le reste passe par les actions.
Authentification et autorisation
Sessions côté serveur (Supabase Auth ou une implémentation directe), vérification à chaque lecture de données, permissions modélisées en base. La protection des routes vit dans le proxy et dans les requêtes, pas seulement dans l’interface.
Postgres et accès typé
Un schéma Postgres versionné, des requêtes typées, des transactions là où plusieurs écritures doivent réussir ensemble. Supabase quand ses briques gérées (auth, stockage, RLS) font gagner des semaines ; Postgres nu quand elles gêneraient.
Cache et rendu
Statique quand le contenu le permet, dynamique quand il dépend de l’utilisateur, revalidé quand une donnée change. Chaque page a une stratégie de rendu choisie, pas héritée.
SEO et données structurées
Métadonnées par page, canonical et hreflang, sitemap et robots générés depuis les données, JSON-LD cohérent avec le contenu visible, images Open Graph générées. Ce site est l’exemple.
Performance
Polices auto-hébergées, CSS inliné, images optimisées, pas de script tiers non nécessaire, animations en CSS. Les Core Web Vitals sont un résultat de l’architecture, pas une optimisation de fin de projet.
Observabilité et déploiement
Vercel avec preview par branche, variables d’environnement documentées, analytics et journaux d’erreurs branchés dès le premier déploiement, migrations dans le pipeline.

02 — Pourquoi

Pourquoi me confier un produit Next.js

Parce que j’en exploite plusieurs. Atamatax, Horvera, Wabiro et SponsorsMetrics sont des applications Next.js en production, avec des paiements réels, des utilisateurs réels et les problèmes réels qui vont avec — migrations, webhooks manqués, pages programmatiques à indexer, coûts à surveiller. Ce que je propose n’est pas une opinion sur Next.js ; c’est une pratique.

Parce que ce site est construit de la même manière : composants serveur partout, une couche interactive en JavaScript natif différé, formulaires en server actions qui fonctionnent sans JavaScript, Stripe et Supabase appelés par REST sans SDK, routage de locales dans le proxy, sitemap et JSON-LD dérivés des données. Vous pouvez l’inspecter.

Parce qu’une seule personne porte l’architecture, le modèle de données, l’interface et le déploiement : pas de perte entre un designer, un développeur front et un développeur back. Le repo est à vous, documenté, sans dépendance à moi.

03 — Choix

Quand Next.js est le bon choix — et quand non

Le bon choix
Un produit SaaS, un portail client, un site à fort enjeu de référencement, une application avec des formulaires, des tableaux de bord et des paiements. Tout ce qui bénéficie du rendu serveur, d’un déploiement simple et d’un seul langage de bout en bout.
À discuter
Une application très riche côté client (éditeur, canvas, temps réel intensif) — Next.js convient, mais la valeur du rendu serveur est moindre et l’architecture doit isoler la partie client.
Pas le bon choix
Un backend lourd de traitement de données ou de calcul long — Next.js reste le front, et le traitement vit dans un service dédié (Python, files de tâches). Une application mobile native. Un site vitrine de cinq pages sans évolution prévue, où un générateur statique suffit.

04 — Coût

Ce que coûte une application Next.js

Le cadre ne change pas le prix ; le périmètre le fait. Une application Next.js avec authentification, un flux principal, paiements et déploiement se situe en bas de la fourchette d’un v1 de SaaS — environ CHF 20’000 ; avec plusieurs rôles, un tableau de bord de données et des intégrations, jusqu’à CHF 45’000. En dessous de CHF 20’000 — un site vitrine, un thème — je ne prends pas le projet ; une refonte d’application Next.js existante se chiffre à part. Le calculateur de coût SaaS situe votre projet en cinq minutes ; le détail est dans Combien coûte un v1 de SaaS en Suisse.

Estimer le périmètre avec le calculateur

Cinq minutes. Une bande de complexité, pas un devis.

Est-ce le bon service ?

Ce service a du sens si

  • Vous lancez un produit web — SaaS, portail, outil — et vous voulez qu’il soit rapide, indexable et maintenable dès le premier jour.
  • Vous avez une application Next.js existante qui a besoin d’une architecture de production : auth, données, paiements, cache, SEO, monitoring.
  • Vous voulez une seule personne du schéma Postgres jusqu’au déploiement, avec un prix connu d’avance.

Ce n’est pas le bon service si

  • Vous cherchez un développeur front à intégrer dans une équipe existante à l’heure.
  • Le cœur du projet est un traitement de données lourd ou une application mobile native.
  • Vous voulez apprendre Next.js vous-même — la Build School est faite pour ça.
  • Vous cherchez à recruter un développeur Next.js salarié — le guide recruter ou externaliser vous aide à décider, sans rien vous vendre.

Méthode

Quatre étapes, scope fixe, prix convenu à l’avance.

  1. 01

    Diagnostic

    20 minutes, gratuit. Modèle économique, workflows, risques, périmètre produit. Si je ne suis pas la bonne personne, je le dis.

  2. 02

    Architecture et proposition

    Sous 48h : modèle de données, frontières du système, intégrations, UX — et un seul prix forfaitaire avec des jalons datés. Pas de « à partir de ».

  3. 03

    Construction

    4 à 6 semaines d’itérations contrôlées. Démo chaque vendredi sur une preview Vercel. Vous voyez le système grandir en direct — pas de boîte noire.

  4. 04

    Mise en production

    Paiements, analytics, déploiement, workflows opérationnels. Vous repartez avec le repo, les comptes, le pipeline — et 30 jours de réponses sous 24h.

  5. 05

    Amélioration

    Itération mesurée sur l’usage réel : un nouveau forfait par périmètre, ou rien si votre équipe reprend. Pas de dépendance cachée.

Le déroulé complet, les garanties et les prix →

Questions fréquentes

  • Combien coûte une application Next.js ?

    Le cadre ne fixe pas le prix, le périmètre le fait. Comptez environ CHF 20’000 pour une application avec authentification, un flux principal, paiements et déploiement, jusqu’à CHF 45’000 avec plusieurs rôles, un tableau de bord et des intégrations. Au forfait, prix convenu avant de commencer.

  • Faut-il Supabase avec Next.js ?

    Pas nécessairement. Supabase fait gagner des semaines quand il faut une authentification, un stockage de fichiers et des politiques d’accès gérés. Un Postgres nu (Neon, ou celui de Supabase sans ses services) convient mieux quand la logique d’accès est entièrement côté serveur. Le choix se fait au cadrage.

  • Server actions ou API routes ?

    Les deux, à leur place. Les formulaires et mutations déclenchés par l’utilisateur passent par des server actions — plus simples, fonctionnelles sans JavaScript. Les webhooks, les intégrations et tout ce qu’un tiers appelle restent des route handlers.

  • Next.js est-il bon pour le SEO ?

    Oui, quand les pages sont rendues sur le serveur et que les métadonnées, le sitemap, les canonicals et les données structurées sont générés depuis les données. Ce site et Horvera — avec ses pages programmatiques — en sont des exemples. Une application Next.js rendue uniquement côté client perd cet avantage.

  • Puis-je reprendre le code après la livraison ?

    C’est prévu pour. TypeScript strict, structure standard de l’App Router, aucune abstraction maison inutile, variables d’environnement et pipeline documentés. Un développeur Next.js s’y retrouve en une journée.

  • Recruter un développeur Next.js ou externaliser ?

    Recrutez si votre produit Next.js a une feuille de route continue et que quelqu’un en interne peut diriger le travail. Externalisez un périmètre défini — un v1, une refonte, une mise en production — quand il peut s’écrire en critères d’acceptation et qu’une équipe le reprendra. Le guide recruter ou externaliser chiffre les deux.

Une application Next.js à construire ou à remettre d’aplomb ?

Décrivez le produit, l’état actuel s’il existe, et la date qui compte. Appel de cadrage de 20 minutes, gratuit.

danilson.daveigaramos.pro@gmail.com · Réponse sous 24h, du lundi au vendredi.