Développement d’applications web : le guide complet

Un site marketing et une application web remplissent des fonctions différentes, et les traiter comme un seul et même projet est souvent là que les budgets de développement web dérapent. Un site marketing existe pour être trouvé et transformer une visite en prospect. Une application web existe pour être utilisée, de façon répétée, par des personnes qui ont déjà décidé de vous faire confiance. L’architecture, les objectifs de performance et même la stratégie SEO diffèrent entre les deux.

Côté marketing, les priorités sont les Core Web Vitals, un HTML sémantique propre, et un contenu indexable sans que le JavaScript ne fasse tout le travail — des pages statiques ou rendues côté serveur, pas une application côté client qui se fait passer pour un site web. Côté application, les priorités se déplacent vers la gestion d’état, l’authentification, la cohérence des données, et les parties de l’interface qui n’ont de sens que pour quelqu’un de connecté.

Next.js et les frameworks similaires existent précisément parce que la plupart des produits réels ont besoin des deux moitiés dans une même base de code : des pages marketing publiques et indexables, à côté d’une application authentifiée, partageant un design system mais pas une stratégie de rendu. Bien poser cette séparation dès l’architecture évite une réécriture plus tard, quand le site marketing doit se classer et l’application doit sembler instantanée.

La construction d’une application web passe généralement par la découverte et l’architecture de l’information, puis les flux principaux avant le polissage visuel, puis l’authentification et le modèle de données, puis l’administration et les cas limites qui n’apparaissent jamais dans le pitch deck mais qui atterrissent forcément dans la file de support. Sauter cette dernière étape est la raison la plus courante pour laquelle une app lancée paraît inachevée six semaines plus tard.

Le test pour savoir si une application web est vraiment terminée n’est pas de vérifier si le chemin heureux fonctionne en démo. C’est de vérifier si quelqu’un avec une connexion lente, un bloqueur de publicités et une tâche qui l’agace peut quand même terminer ce pour quoi il est venu. C’est une barre plus basse à décrire, et bien plus haute à atteindre que ce que la plupart des lancements admettent.

Un mode d'échec concret : une entreprise construit son site marketing comme une application monopage côté client parce que la même équipe construit aussi l'application produit, et réutiliser l'outillage semble efficace. Les moteurs de recherche peinent à l'indexer, la performance au premier chargement en souffre, et l'équipe marketing passe des mois à lutter contre un choix de framework fait pour la mauvaise moitié du produit.

L'erreur inverse est tout aussi courante — traiter l'application authentifiée comme un site de contenu et recourir à une génération statique lourde alors que les données diffèrent pour chaque utilisateur connecté. Cela produit un pipeline de build qui lutte contre la vraie forme du problème, avec des bugs d'invalidation de cache à la place de ce qui aurait dû être une simple page rendue côté serveur, à la demande.

Une règle pratique : si le contenu d'une page est identique pour chaque visiteur et compte pour le référencement, penchez vers le statique ou le rendu serveur. Si le contenu dépend de qui est connecté et change à chaque interaction, penchez vers l'état client et considérez le SEO comme non pertinent pour cette route. La plupart des produits réels ont besoin des deux règles, appliquées à des parties différentes de la même base de code.