Des applications web construites avec Next.js.

Un site vitrine, c'est du contenu que l'on publie. Une application web est un système dans lequel on se connecte et on travaille : des comptes et des rôles, des données qui changent d'heure en heure, des règles qui déterminent qui peut voir et modifier quoi, et une trace de ce qui s'est passé. Les pages sont la partie visible. L'essentiel de la construction se trouve derrière.

Ce qui fait partie du périmètre et figure rarement dans le brief

• Les comptes : inscription, connexion, réinitialisation du mot de passe, vérification de l'adresse e-mail, invitations, et des rôles qui déterminent ce que chaque utilisateur peut atteindre.
• Un modèle de données qui résiste au contact avec la réalité — les entités, leurs relations, et les états par lesquels passe un enregistrement.
• Un back-office pour vos propres équipes : retrouver un enregistrement, corriger une donnée fausse, rembourser, suspendre, exporter. Quelqu'un en a toujours besoin dès le deuxième jour.
• Les traitements en arrière-plan : tâches planifiées, imports, exports, génération de documents — tout ce qui est trop lent pour tenir dans une requête.
• Les e-mails transactionnels et les notifications, envoyés depuis un domaine authentifié assez correctement pour que le courrier arrive vraiment.
• L'envoi et le stockage de fichiers, avec des limites de taille, un contrôle du type et des règles d'accès qui s'appliquent au fichier lui-même, pas seulement à la page qui pointe vers lui.
• Les paiements, si de l'argent circule : écritures idempotentes, gestion des webhooks, remboursements, et un journal que l'on peut rapprocher.
• Les environnements, les déploiements, les sauvegardes, les logs et le suivi des erreurs — la partie que personne ne demande en démonstration et dont tout le monde a besoin à deux heures du matin.

Nous écrivons cette liste avant l'estimation, parce que c'est là que les estimations dérapent. Un nombre d'écrans ne dit presque rien de la taille d'une application web. Le nombre de rôles, le nombre d'états que peut prendre un enregistrement et le nombre de systèmes avec lesquels elle doit échanger des données en disent l'essentiel.

React peut être rendu sur un serveur au moment de la requête, au moment du build, ou dans le navigateur. L'App Router de Next.js permet de choisir route par route, et ce choix fixe la vitesse du premier chargement, la visibilité du contenu pour les moteurs de recherche, la qualité de la mise en cache et le prix que vous payez pour servir la page.

Les quatre options, et le cas où chacune convient

• Statique : rendu au build, servi depuis un CDN. Le plus rapide et le moins cher. Adapté aux pages marketing, à la documentation, aux articles — tout ce qui est identique pour chaque visiteur.
• Régénération incrémentale : du statique, avec des pages régénérées en arrière-plan, à intervalle régulier ou à la demande. Adapté aux pages de catalogue et de contenu qui changent souvent mais pas selon l'utilisateur.
• Rendu serveur à chaque requête : le HTML est construit sur le serveur avec les données propres à l'utilisateur. Adapté aux tableaux de bord et à tout contenu personnalisé qui doit malgré tout arriver sous forme de vrai HTML.
• Rendu client : le navigateur récupère les données et dessine la page. Adapté derrière une authentification, sur des écrans très interactifs où la visibilité dans les moteurs n'a aucune importance et où la fraîcheur compte plus que le premier affichage.

Les React Server Components ont déplacé la valeur par défaut dans la bonne direction. La récupération des données et les dépendances lourdes restent sur le serveur, et seuls les composants qui ont réellement besoin d'interactivité envoient du JavaScript au navigateur. L'effet pratique est un bundle plus petit, et c'est le levier unique qui règle la majorité des problèmes de performance.

Pour le référencement, la règle est brutale. Si une page doit se positionner, elle est rendue sur le serveur ou au build, avec son contenu dans le HTML initial — titre, corps de texte, URL canonique, données structurées. Un contenu qui n'apparaît qu'après un appel côté client est un pari, et ce n'est pas un pari à prendre sur les pages qui vous apportent des affaires.

Authentification

Des sessions dans un cookie HTTP-only pour la plupart des applications ; des tokens lorsqu'un client mobile distinct ou un tiers doit accéder à l'API. Une connexion sociale ou d'entreprise par OAuth ou SAML quand vos acheteurs travaillent dans des sociétés qui l'exigent. La réinitialisation du mot de passe, la vérification de l'e-mail, les invitations et un second facteur sont des fonctionnalités avec du vrai travail dedans : elles sont cadrées et estimées, pas supposées acquises. L'autorisation est la moitié la plus difficile : la permission est vérifiée sur le serveur à chaque action, pas en masquant un bouton.

Données

PostgreSQL par défaut. Il gère le relationnel, le JSON, la recherche plein texte et les files de tâches assez bien pour que la plupart des produits n'aient jamais besoin d'une seconde base. Les changements de schéma sont livrés sous forme de migrations versionnées exécutées pendant le déploiement, pour que chaque environnement reçoive la même structure dans le même ordre et qu'un retour en arrière soit une manœuvre connue plutôt qu'une improvisation. Les contraintes vivent dans la base — not null, unique, clés étrangères — parce que le code applicatif n'est pas la dernière ligne de défense.

Le back-office

Tout produit a besoin d'outils internes : un moyen de retrouver un client, de voir son état et de corriger quelque chose sans qu'un développeur ouvre un client SQL. Ce n'est pas obligé d'être beau, et au début une interface d'administration générée suffit. En revanche il doit exister, être protégé par des droits, et enregistrer qui a fait quoi. L'omettre n'économise rien : cela déplace le coût sur vos propres équipes, chaque semaine, indéfiniment.

Trois métriques de terrain déterminent le score que Google utilise réellement : le Largest Contentful Paint pour le chargement, l'Interaction to Next Paint pour la réactivité, et le Cumulative Layout Shift pour la stabilité visuelle. Les seuils publiés sont de 2,5 secondes, 200 millisecondes et 0,1, évalués au 75e centile des visites réelles. Un score obtenu en laboratoire sur un portable de développeur est un outil de débogage. Les données de terrain, sur de vrais appareils et de vrais réseaux, sont le chiffre qui compte.

Ce qui casse réellement chacune d'elles

• LCP : une image d'en-tête non optimisée, une réponse serveur lente, du CSS bloquant le rendu, ou une police web qui retient le texte. Il faut servir la bonne taille d'image dans un format moderne, précharger celle qui compte, et laisser le texte s'afficher pendant le chargement de la police.
• INP : trop de JavaScript exécuté sur le thread principal au moment précis où quelqu'un appuie. Le remède est en général moins de JavaScript plutôt que du JavaScript plus rapide — moins de composants client, moins d'état stocké haut dans l'arbre, des dépendances plus légères.
• CLS : des images et des intégrations sans espace réservé, des bandeaux insérés au-dessus du contenu, des polices dont la substitution change les métriques. Tout cela s'évite dans le balisage.

Nous fixons un budget dès le départ — un poids de page et un plafond de JavaScript — et nous le vérifions dans le build, pour qu'une régression soit détectée dans une pull request plutôt que trois versions plus tard. La vitesse est aussi une ligne de coût : des pages qui se mettent bien en cache coûtent moins cher à servir que des pages rendues à chaque requête, et l'écart apparaît sur la facture d'hébergement à mesure que le trafic augmente.

Une application qui ne peut pas être pilotée au clavier exclut les personnes qui n'utilisent pas de souris, et elle est en général un peu cassée pour tout le monde. C'est aussi de plus en plus une obligation légale plutôt qu'une préférence : l'Acte européen sur l'accessibilité s'applique depuis juin 2025 à de nombreux services numériques grand public vendus dans l'Union européenne, et la norme sur laquelle il s'appuie, EN 301 549, renvoie aux WCAG.

Ce que nous faisons systématiquement

• Du HTML sémantique d'abord — de vrais boutons, de vrais liens, de vrais titres, de vraies listes — parce qu'il apporte gratuitement le comportement et le sens.
• Chaque élément interactif atteignable au clavier, dans un ordre logique, avec un style de focus visible que personne ne supprime au motif qu'il fait désordre.
• Des champs de formulaire avec des libellés, des erreurs rattachées au champ concerné et annoncées, et un texte d'erreur qui dit quoi faire ensuite.
• Des contrastes vérifiés selon le niveau AA des WCAG, y compris sur les états survolé, focus et désactivé.
• Un texte alternatif qui porte l'information, ou un alt vide quand l'image est décorative.
• Des boîtes de dialogue, menus et contrôles personnalisés construits sur des primitives éprouvées, avec piégeage du focus et gestion de la touche Échap, plutôt qu'un div doté d'un gestionnaire de clic.

Les tests automatisés en attrapent une partie. Le reste est une passe au clavier et une passe au lecteur d'écran sur les parcours principaux, faites avant la mise en production plutôt qu'après une réclamation.

Une application web n'est pas livrée quand le code est écrit. Elle doit tourner quelque part, rester disponible, et pouvoir être restaurée. Il existe deux formes raisonnables, et le choix tient surtout à qui porte le travail d'exploitation.

• Une plateforme gérée : déploiement à chaque push, un environnement de prévisualisation par branche, un CDN mondial, une mise à l'échelle que l'on ne configure pas. Le moins de charge d'exploitation, une facturation à l'usage, et le moyen le plus rapide de faire tourner correctement une application Next.js.
• Des conteneurs sur un cloud ou un VPS européen : plus de mise en place et davantage de supervision à votre charge, mais des prix prévisibles — et la bonne réponse quand la résidence des données, une intégration sur site ou une équipe plateforme existante l'imposent.

Autour de l'un comme de l'autre, la même liste : un PostgreSQL géré avec sauvegardes automatiques, un stockage objet pour les fichiers, un domaine et des certificats, un fournisseur d'e-mail transactionnel, le suivi des erreurs, la supervision de disponibilité et la conservation des logs. Pris isolément, la plupart de ces postes sont petits. Ensemble, ils constituent le coût de fonctionnement du produit, et ils ont leur place dans la première conversation plutôt que dans la première facture.

Mis en place sur chaque projet

• Des environnements de production et de préproduction séparés, la préproduction pointant vers le bac à sable de chaque service tiers.
• Des sauvegardes automatiques, et une restauration répétée au moins une fois — une sauvegarde jamais testée est une croyance, pas une sauvegarde.
• Un suivi des erreurs avec les versions étiquetées, pour qu'une nouvelle exception soit rattachée au déploiement qui l'a introduite.
• Des déploiements depuis la branche principale par la CI, avec un chemin de retour, parce que revenir en arrière est une question de quand et non de si.

Le dépôt, les comptes cloud et les domaines sont à vous dès le premier commit. Rien d'important n'est conservé dans un compte qui nous appartient.

Un système de gestion de contenu vaut sa complexité quand des personnes qui n'écrivent pas de code modifient souvent le contenu, et il n'est que du poids mort quand ce n'est pas le cas. La question n'est jamais de savoir si un CMS est une bonne chose. Elle est de savoir qui édite, à quelle fréquence, et quels dégâts une mauvaise modification peut causer.

Un CMS est le bon choix quand

• Le marketing doit publier sans attendre une mise en production.
• Le même contenu est servi en plusieurs langues, ou à la fois à un site et à une application.
• Le contenu a une structure qui mérite d'être modélisée — produits, articles, offres, pages — et il est réutilisé à plus d'un endroit.
• Quelqu'un a réellement besoin de brouillons, de prévisualisations et d'une date de publication.

C'est le mauvais choix quand

• Les pages changent quelques fois par an et un développeur est de toute façon dans le code toutes les semaines.
• Ce dont vous avez besoin est en fait un écran applicatif, et le modéliser comme du contenu ne fera qu'aggraver les choses.
• Personne n'a été désigné pour faire l'édition. Un CMS sans propriétaire devient un CMS vide.

Quand c'est le bon choix, nous le construisons en headless : le contenu vit dans son propre service derrière une API typée, et le front reste une application Next.js qui met en cache et revalide. Ce site fonctionne ainsi — chaque page de texte est modifiable sans déploiement — ce qui est aussi la raison pour laquelle nous en connaissons les angles vifs : modéliser du contenu comme des pages au lieu de le modéliser comme des données, et oublier que la prévisualisation a besoin de son propre chemin à travers le cache.