Site web
Présenter une offre, être trouvé sur Google, recevoir des demandes de contact ou de devis. Pas de comptes, peu de logique.
Build With Me / Web
Construisons votre produit web.
Un site qui reçoit des demandes, une application que votre équipe utilise, un SaaS que des clients paient : chaque produit a sa bonne façon d’être construit.
Pour construire un produit web, partez du problème et des utilisateurs, pas de la technologie. Un site de présentation se fait le plus souvent avec un éditeur de sites ; une boutique classique, avec une plateforme e-commerce hébergée ; le code sur mesure se justifie quand le produit a des comptes, des données propres à chaque utilisateur, des règles métier ou des intégrations qu’aucun outil ne gère. Ensuite, l’ordre compte : modèle de données, authentification, parcours principal, paiements, puis mise en production vérifiée.
Vérifié le
En bref
- Pour qui
- Fondateurs, indépendants, équipes et développeurs qui veulent construire un produit web.
- Couvre
- Sites, applications web, SaaS, PWA, marketplaces, boutiques, espaces clients, outils internes, réservation.
- Principe
- L’outil le plus simple qui tient le besoin — un éditeur de sites quand il suffit, du code quand il le faut.
- Ordre de construction
- Données → accès → parcours principal → paiements → production vérifiée.
- Ce que la page ne fait pas
- Pas de devis automatique, pas de prix inventé : le coût dépend du périmètre.
Trois façons de construire
Apprendre, construire ensemble, ou faire réaliser.
01 · Apprendre et construireOffre guidée — Un produit Bynilson existant, aux conditions publiées.
Apprendre et le construire vous-même
Build School est le programme payant de Bynilson pour construire un produit web avec un agent de code, et prouver qu’il est prêt pour la production : parcours en étapes, modèles, ShipCheck. Avant d’acheter quoi que ce soit, les ressources gratuites de cette page et la checklist SaaS Starter Kit suffisent pour démarrer.
Build School · Starter Module →CHF 249Le parcours complet pour construire un produit web avec un agent de code, à votre rythme.SaaS Starter Kit — checklist gratuite →Le guide de cette page, étape par étape →Les parcours d’apprentissage Build With Me →Guide « Créer avec l’IA ou déléguer ? » →CHF 39Pour décider ce que vous pouvez construire vous-même avec l’IA (en français).
02 · Construire ensembleOffre guidée — Un produit Bynilson existant, aux conditions publiées.
Le construire ensemble
Vous gardez la main sur votre code et votre dépôt ; Bynilson relit, débloque et priorise. Deux formats existent déjà dans Build School : Cohort Build (cohorte, feedback, revue de dépôt) et Premium Mentoring (revue d’architecture et de sécurité, debugging sur votre dépôt, sur candidature). La collaboration écrite — instructions, captures annotées, enregistrements sous-titrés — est un parcours à part entière : aucun appel n’est obligatoire.
Build School · Cohort Build →CHF 799Le même parcours en cohorte, avec relecture de votre projet et de votre dépôt.Build School · Premium Mentoring →dès CHF 2’000Revue d’architecture, de sécurité et de lancement sur votre projet réel — sur candidature.Décrire votre projet pour un accompagnement →Étudié au cas par cas. Collaboration écrite possible, sans appel obligatoire.
03 · Le faire réaliserOffre guidée — Un produit Bynilson existant, aux conditions publiées.
Le faire construire
Pour un produit à construire ou à reconstruire, la qualification de projet indique en six questions si votre projet correspond à un engagement Bynilson ; un montant minimum d’engagement s’applique, et la réponse le dit franchement si le projet est en dessous. Pour une application qui existe déjà et qui casse, Code Rescue ; pour vérifier avant un lancement, Launch Rescue.
Faire réaliser votre produit →dès CHF 20’000Engagements de réalisation à partir de CHF 20’000, prix fixe après cadrage.Diagnostic produit & architecture →CHF 2’400CHF 2’400, livré en 7 jours ouvrés, crédité sur une réalisation.Une application existante qui casse ? →Code Rescue répare, Launch Rescue vérifie avant le lancement.
Les produits
Quel produit web construisez-vous ?
Dix formes de produit, la façon raisonnable de construire chacune, et le piège classique. Le bon point de départ est souvent plus simple que prévu.
Application web
Des utilisateurs connectés, des données qui leur appartiennent, des règles métier : un logiciel qui tourne dans le navigateur.
SaaS
Des clients créent un compte et paient un abonnement pour utiliser votre logiciel. Le produit doit tourner sans vous.
Application web progressive (PWA)
Une application web installable sur l’écran d’accueil, qui peut fonctionner en partie hors ligne, sans passer par un store.
Marketplace
Deux types d’utilisateurs se rencontrent : des vendeurs ou prestataires publient, des clients achètent ou réservent.
Boutique en ligne
Vendre des produits : catalogue, panier, paiement, livraison, retours, TVA.
Espace client
Vos clients se connectent pour déposer des documents, suivre un dossier, retrouver leurs factures.
Outil interne
Remplacer des tableurs, des emails et des copier-coller par un outil d’équipe avec des rôles et un historique.
Plateforme de réservation
Des créneaux, des disponibilités, des confirmations, des rappels et des annulations.
Contenu réservé aux membres
Cours, leçons, modèles ou ressources accessibles après paiement, avec la progression de chacun.
Les approches
Éditeur de sites, no-code ou code sur mesure ?
Il n’y a pas de bonne réponse universelle. Il y a l’outil le plus simple qui tient votre besoin aujourd’hui, et les limites qui vous feront changer demain.
- Éditeur de sites (site builder)
- Pages, contenu, formulaires, hébergement inclus. Le bon choix pour un site de présentation ou un blog que vous voulez modifier vous-même. Limite : peu ou pas de logique propre, pas de données par utilisateur.
- No-code
- Des outils visuels pour construire une base de données, des formulaires, des automatisations, parfois une application complète. Excellent pour valider une idée ou outiller une équipe vite. Limites : règles complexes difficiles à tester, coûts qui montent avec l’usage, dépendance à la plateforme, export des données à vérifier avant de s’engager.
- Low-code
- Une plateforme visuelle dans laquelle on ajoute du code là où elle s’arrête. Utile pour des outils internes. Limite : vous cumulez les contraintes de la plateforme et la maintenance du code ajouté.
- Code sur mesure
- Vous possédez le code, le modèle de données et l’hébergement. Le bon choix quand le produit porte des règles métier, des données sensibles, des intégrations ou une échelle que les outils ne tiennent pas. Limite : il faut le construire, le tester et le maintenir — seul, accompagné ou en déléguant.
Ce qui pousse en général vers le sur-mesure : des règles que vous devez pouvoir tester et versionner, des données que vous devez contrôler (où elles sont hébergées, qui y accède), une intégration qu’aucun connecteur ne propose, ou un coût de plateforme qui dépasse celui d’un code maintenu. Ce qui doit vous retenir : un besoin encore flou. Valider avec un outil simple coûte moins cher que reconstruire un produit mal cadré.
Éditeur de sites ou développement sur mesure ?Comparer avant de choisir →
No-code ou développement sur mesure ?Comparer avant de choisir →
La technologie
Quelle technologie, pour quel besoin ?
La même stack n’est pas proposée à chaque projet. La technologie se choisit à partir des exigences — et de qui maintiendra le produit ensuite.
| Exigence | Options raisonnables | Quand ce n’est pas le bon choix |
|---|---|---|
| Interface riche et interactive | React avec TypeScript ; un framework comme Next.js pour le rendu serveur et le routage | Un site de contenu sans interaction : un éditeur de sites ou un générateur de site statique suffit |
| Pages trouvables sur Google | Rendu côté serveur ou pages statiques, métadonnées et sitemap générés | Une application entièrement privée derrière une connexion : le SEO ne compte que pour les pages publiques |
| Logique serveur et API | Node.js (routes d’API ou actions serveur du framework), ou un autre langage serveur que votre équipe maîtrise | Si votre équipe connaît bien Python, PHP ou un autre écosystème, la meilleure stack est celle qu’elle saura maintenir |
| Données relationnelles | PostgreSQL, en direct ou via un service géré comme Supabase (base, authentification, stockage) | Des données sans relations ni requêtes complexes, ou un volume qu’un outil no-code tient déjà |
| Paiements | Stripe (Checkout pour le paiement, webhooks pour la confirmation) | Une boutique classique : la plateforme e-commerce intègre déjà le paiement |
| Interface cohérente, vite | Tailwind CSS ou le système de design existant de l’équipe | Un système de design déjà en place dans une autre technologie |
| Données hébergées en Suisse ou dans l’UE | Hébergeur et région choisis pour la base et les fichiers, vérifiés dans la documentation du fournisseur | Si aucune exigence ne l’impose, le choix de région reste une décision de latence et de coût |
TypeScript
JavaScript avec des types vérifiés avant l’exécution.
Quand : Dès qu’un produit a plus de quelques fichiers ou plus d’une personne.
React
Une bibliothèque pour construire des interfaces en composants.
Quand : Interfaces interactives, réutilisation de composants.
Pas quand : Un site de contenu simple.
Next.js
Un framework React avec rendu serveur, routage et actions serveur.
Quand : Applications et SaaS qui ont aussi des pages publiques à référencer.
Pas quand : Une API pure sans interface, ou une équipe déjà productive sur un autre framework.
PostgreSQL
Une base de données relationnelle open source, éprouvée.
Quand : La plupart des produits avec des utilisateurs et des données liées.
Supabase
Postgres géré, avec authentification, stockage de fichiers et règles d’accès par ligne.
Quand : Démarrer vite sans administrer de serveur de base de données.
Pas quand : Une infrastructure déjà imposée par votre organisation.
Stripe
Un service de paiement en ligne : paiements uniques, abonnements, remboursements.
Quand : Encaisser dans une application ou un SaaS.
API et backend
Le serveur, l’API et ce qui tourne derrière
- API REST ou actions serveur
- Une API REST expose des URL que d’autres programmes appellent (une app mobile, un partenaire). Les actions serveur d’un framework comme Next.js suffisent quand seule votre propre interface appelle le serveur. Une API publique se justifie quand un autre client que votre site en a besoin.
- Validation
- Toute donnée qui arrive est validée côté serveur avec un schéma (types, longueurs, valeurs permises), même si le formulaire la vérifie déjà : le navigateur ne fait jamais foi.
- Versionnement
- Une API utilisée par d’autres ne change pas sans prévenir : nouveaux champs ajoutés sans casser les anciens, changements incompatibles publiés sous une nouvelle version.
- Tâches en arrière-plan
- Envoyer des emails, générer un document, synchroniser des données : ce qui est long ou peut échouer sort de la requête de l’utilisateur, dans une file ou une tâche planifiée, avec reprise après échec.
- Limitation de débit
- Un formulaire, une connexion ou une API sans limite par adresse ou par compte invite les abus. On limite, et on journalise sans enregistrer de données sensibles.
Base de données
Le modèle de données avant les écrans
Un produit est d’abord un modèle de données : quelles entités (un client, un dossier, une facture), quelles relations, qui possède quoi. Écrivez-le avant la première page ; c’est la décision la plus chère à changer plus tard.
- Choisir : une base relationnelle comme PostgreSQL convient à la grande majorité des produits ; une base orientée documents ou un outil no-code peut suffire pour des données simples et peu liées.
- Migrations : chaque changement de structure passe par une migration versionnée dans le dépôt, appliquée de la même façon en test et en production.
- Isolement : dans un produit multi-clients, chaque ligne porte son propriétaire et chaque requête filtre dessus — ou la base l’impose par des règles d’accès par ligne.
- Sauvegardes : vérifiez qu’elles existent, à quelle fréquence, et faites une restauration de test au moins une fois. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
Authentification
Qui est connecté, et qui a le droit de voir quoi
- Authentification
- Prouver qui est la personne : mot de passe, lien magique par email, connexion via un fournisseur. Utilisez un service ou une bibliothèque éprouvée plutôt que d’écrire la vôtre.
- Autorisation
- Décider ce que cette personne a le droit de faire, sur chaque donnée, à chaque requête. C’est là que se produisent la plupart des fuites de données.
- Sessions
- Un cookie sécurisé (HttpOnly, Secure, SameSite) qui identifie la session côté serveur ; une durée de vie limitée et une déconnexion qui invalide vraiment la session.
- Rôles et accès par ligne
- Administrateur, membre, client : les rôles se vérifient côté serveur. Les règles d’accès par ligne de la base (Row Level Security dans Postgres) ajoutent une seconde barrière.
Paiements
Encaisser, confirmer, rembourser
- Paiement unique ou abonnement
- Un paiement unique débloque un accès ou un produit ; un abonnement ajoute des renouvellements, des échecs de paiement, des changements d’offre et des résiliations à gérer.
- Stripe Checkout
- Une page de paiement hébergée par Stripe : vous n’avez pas à traiter les données de carte, et les moyens de paiement courants sont gérés.
- Le webhook fait foi
- Stripe notifie votre serveur quand un paiement est confirmé. C’est ce signal, vérifié par sa signature, qui débloque l’accès — pas la page de succès, que l’on peut atteindre sans avoir payé.
- Remboursements et litiges
- Prévoyez ce que devient l’accès après un remboursement ou un litige, et qui peut déclencher un remboursement.
Avant d’ouvrir les paiements
Intégrations
Relier vos outils sans fragilité
- Lisez la documentation officielle de l’API avant de promettre l’intégration : limites de débit, authentification, données réellement disponibles.
- Recevez les événements par webhook quand le service le propose, plutôt que d’interroger son API en boucle — et vérifiez la signature de chaque webhook.
- Prévoyez les échecs : nouvelles tentatives espacées, et une file des appels en erreur que quelqu’un peut relancer.
- Rendez chaque opération idempotente : rejouer un appel ou un événement ne doit pas créer de doublon.
- Gardez les clés d’API côté serveur, dans des variables d’environnement, jamais dans le code du navigateur ni dans le dépôt.
Mise en production
Ce qui sépare une démo d’un produit
- Sécurité
- Les risques les plus fréquents des applications web sont documentés par l’OWASP (contrôle d’accès défaillant, injections, mauvaise configuration). Vérifiez votre produit contre cette liste avant le lancement.
- SEO
- Pages publiques rendues côté serveur, titres et descriptions uniques, sitemap, données structurées honnêtes. Les pages privées n’ont pas à être indexées.
- Performance
- Mesurez sur un vrai téléphone et une connexion moyenne : images dimensionnées, peu de JavaScript côté client, pas de requêtes en cascade.
- Analytics
- Mesurez quelques événements qui comptent (inscription, activation, paiement), sans texte libre ni données personnelles, et avec le consentement lorsqu’il est requis.
- Emails
- Emails transactionnels (confirmation, réinitialisation) envoyés depuis un domaine authentifié, pour ne pas finir en spam.
- Fichiers
- Stockage privé par défaut, types et tailles vérifiés côté serveur, liens de téléchargement signés et temporaires.
- Déploiement
- Un déploiement reproductible depuis le dépôt, avec un environnement de prévisualisation, des variables d’environnement séparées par environnement et un retour arrière possible.
- Suivi des erreurs
- Les erreurs serveur et navigateur remontent quelque part où quelqu’un les lit, sans données sensibles dans les journaux.
- Itération
- Après le lancement, observez ce que les utilisateurs font vraiment, corrigez ce qui bloque, puis ajoutez — dans cet ordre.
Le parcours
Douze étapes, de l’idée au produit qui tourne
Chaque étape renvoie à une ressource qui existe. Le parcours détaillé, avec exercices et vérifications, est celui de Build School.
- 01
Valider le problème
Qui a ce problème, comment le résout-il aujourd’hui, et qu’est-ce qui prouverait qu’il paierait pour mieux ?
DisponiblePrototype ou v1 ?
- 02
Définir la v1
Un seul parcours principal, la liste de ce qui attendra, et ce qui rend la v1 « terminée ».
DisponibleSaaS Starter Kit (checklist gratuite)
- 03
Choisir l’approche
Éditeur de sites, no-code ou code ; le construire vous-même, accompagné, ou le déléguer.
DisponibleDiagnostic gratuit : construire, acheter ou déléguer
- 04
Écrire le modèle de données
Entités, relations, propriétaire de chaque donnée.
DisponibleDocumentation PostgreSQLPostgreSQL
- 05
Installer l’environnement
Dépôt Git, éditeur, variables d’environnement, premier déploiement vide.
DisponibleGitHub — premiers pasGitHub
- 06
Construire l’accès
Authentification, sessions, et autorisation vérifiée côté serveur.
- 07
Construire le parcours principal
De la connexion au résultat, de bout en bout, avant tout écran secondaire.
DisponibleDocumentation Next.jsVercel
- 08
Brancher les paiements
Checkout, webhook signé et idempotent, remboursement testé.
DisponibleWebhooks StripeStripe
- 09
Relier les intégrations et les emails
Services externes avec reprise sur erreur, emails transactionnels.
DisponibleCréer un SaaS avec Next.js : l’ordre qui évite les réécritures
- 10
Vérifier avant la production
Accès, données, paiements, erreurs : chaque point vérifié, pas déclaré.
DisponibleShipCheck — votre app est-elle prête pour la production ?
- 11
Mettre en production
Domaine, emails authentifiés, suivi des erreurs, sauvegardes.
DisponibleVérifier une application construite avec l’IA avant le lancement
- 12
Lancer et itérer
Premiers utilisateurs, mesures simples, corrections, puis nouvelles fonctions.
DisponibleBuild OS — les 22 étapes d’un produit, de l’idée à l’exploitation
Questions fréquentes
Comment construire un SaaS ?
Validez d’abord le problème avec de vrais utilisateurs, puis construisez dans l’ordre : modèle de données et isolement par client, authentification, un parcours principal complet, abonnement confirmé par webhook, emails, et mise en production vérifiée. L’article Créer un SaaS avec Next.js détaille chaque étape.
Comment lancer un MVP sans tout construire ?
Réduisez la v1 à un seul parcours qui résout le problème principal, et listez par écrit ce qui attendra. Souvent, un outil no-code ou une page avec un formulaire suffit pour vérifier que le problème vaut la peine d’être résolu. Voir Prototype ou v1 ?.
No-code ou développement sur mesure ?
Le no-code est excellent pour valider vite ou outiller une équipe. Le sur-mesure se justifie quand le produit porte des règles métier à tester, des données à contrôler, des intégrations sans connecteur ou des coûts de plateforme trop élevés. Le diagnostic gratuit construire, acheter ou déléguer aide à trancher.
Comment construire un espace client ?
Le cœur d’un espace client est l’autorisation : chaque requête vérifie côté serveur que la personne a le droit de voir ce dossier précis. Ajoutez un stockage de fichiers privé avec des liens signés, et gardez l’interface simple — liste, détail, actions, statuts.
Comment connecter des paiements Stripe ?
Créez une session Stripe Checkout côté serveur, redirigez la personne vers la page de paiement, puis accordez l’accès quand votre serveur reçoit le webhook signé qui confirme le paiement. Rendez ce webhook idempotent et testez un remboursement avant le lancement.
Combien coûte un produit web ?
Cela dépend du périmètre, pas de la technologie : le nombre de rôles, de règles, d’intégrations et de paiements. Le calculateur de coût SaaS donne une fourchette à partir de vos réponses ; pour un site vitrine, voir combien coûte un site web en Suisse.
Faut-il une application mobile ou une application web ?
Une application web qui fonctionne bien sur téléphone suffit pour la plupart des premières versions, et elle évite la validation des stores. Une app native se justifie quand l’accès au matériel, les notifications fiables ou la présence sur l’App Store sont essentiels — voir construire une app iOS.
Sources
- Le manuel TypeScriptMicrosoftVérifié le 23 oct. 2026
- React — apprendreMeta / ReactVérifié le 23 oct. 2026
- Documentation Next.jsVercelVérifié le 23 oct. 2026
- Documentation PostgreSQLPostgreSQLVérifié le 23 oct. 2026
- Documentation SupabaseSupabaseVérifié le 23 oct. 2026
- Documentation StripeStripeVérifié le 23 oct. 2026
- GitHub — premiers pasGitHubVérifié le 23 oct. 2026
- OWASP ASVS (vérification de sécurité)OWASPVérifié le 23 oct. 2026
- Webhooks StripeStripeVérifié le 23 oct. 2026