Créer une web app : les étapes, les choix techniques, les pièges

Web app ou site : la question à se poser d’abord

Un site vitrine présente une activité. Une web app rend un service : elle a des comptes, des données, des règles métier. La différence compte parce qu’elle change tout le reste, du budget à l’hébergement.

Trois exemples tirés de nos projets :

• Votons aide à trouver son candidat à la présidentielle 2027 : un quiz d’affinité, des fiches, un comparateur, une API et des applications mobiles.
• Pocabase est la base de données des photocards K-pop : chaque fan coche les cartes de sa collection.
• Say Yes donne à un studio de design un back-office qui compose ses landing pages à partir de blocs.

Commencer par un seul parcours complet

L’erreur classique est de construire dix fonctions à moitié. On fait l’inverse : un parcours, de bout en bout, en production.

Pour une app de collection, ce parcours est « je crée mon compte, je trouve une carte, je la coche, je retrouve ma collection demain ». Tout le reste (niveau de fan, formule premium, traductions) vient après, quand ce premier parcours tient.

Dix fonctions à moitié

• Comptes
• Recherche
• Collection
• Niveau de fan
• Premium
• Traductions

Beaucoup de chantiers ouverts, aucun parcours utilisable.

Un parcours complet, en production

• Je crée mon compte
• Je trouve une carte
• Je la coche
• Je retrouve ma collection demain

Le reste vient après, quand ce parcours tient.

Choisir la stack

Le bon choix technique est ennuyeux : des outils répandus, documentés, que l’équipe connaît.

Brique	Ce qu’on utilise	Pourquoi
Interface et serveur	Next.js ou Remix, React, TypeScript	Le rendu côté serveur aide le référencement et la vitesse
Données	PostgreSQL	Fiable, relationnel, tient très longtemps
Accès aux données	Prisma ou Drizzle	Un schéma typé, des migrations versionnées
Paiement	Stripe	Cartes, abonnements, factures
Livraison	Docker, un VPS ou une plateforme gérée	La même image du poste du développeur à la production

Pocabase tourne sur Next.js, React, PostgreSQL, Drizzle et Docker. Say Yes sur Remix, React, Prisma et Tailwind.

Les quatre sujets qu’on sous-estime

1. Les comptes. Inscription, mot de passe oublié, connexion Google, suppression du compte. C’est long, et rien n’est optionnel.
2. Les droits. Qui voit quoi, qui modifie quoi. À écrire dès le schéma de données, pas après.
3. Les données personnelles. Collecter le minimum, dire ce qu’on en fait, pouvoir les exporter et les effacer.
4. Le back-office. Quelqu’un devra corriger une donnée ou rembourser un client. Sans écran d’administration, ce sera un développeur.

Penser au référencement dès le départ

Une web app publique vit aussi de Google. Les pages publiques doivent être rendues côté serveur, avoir une adresse propre, un titre et une description uniques, et des données structurées. Pocabase sert 46 langues avec un seul code et des adresses traduites. Notre guide du SEO multilingue détaille la méthode.

Mettre en production tôt, puis souvent

La première mise en production se fait la première semaine, avec une page presque vide. On règle ainsi le domaine, le certificat, la base, les sauvegardes et le déploiement pendant que les enjeux sont faibles. Ensuite chaque livraison part en ligne, derrière un accès restreint si besoin.

Avant d’ouvrir au public, on vérifie :

• les sauvegardes de la base, et une restauration réellement testée ;
• le suivi des erreurs et une alerte quand le site tombe ;
• les performances sur un téléphone moyen, en 4G ;
• les parcours critiques, couverts par des tests automatiques.

L’hébergement est détaillé dans notre guide Héberger un site ou une app sur un VPS.