Construire une application web avec Claude — le guide complet

Le processus de A à Z pour créer et publier une application web avec une IA comme Claude, sans être développeur — illustré par un cas 100 % réel : le site que vous êtes en train de lire. Chaque étape dit ce que vous déléguez à l'IA, ce que vous supervisez, et ce qui reste votre décision d'humain.

À propos de ce guide

On appelle ça le « vibe coding » : vous décrivez ce que vous voulez en langage humain, l'IA écrit le code. C'est vrai — et c'est là que la plupart des gens s'arrêtent, publient une application fragile, et se font pirater ou abandonnent. Ce guide enseigne le vibe coding avec discipline, selon les trois gestes Lojik360 : déléguer le code à l'IA, superviser chaque résultat, renforcer ce qui reste à vous — la vision, les décisions, la langue, la relation avec vos utilisateurs.

Le fil rouge est un cas réel, vérifiable en ligne : lojik360.atmart.ltd — 36 pages en 4 langues, un assistant IA intégré, une newsletter, une interface d'administration, un podcast — construit avec Claude par un analyste de données qui n'est pas développeur web, pour un coût d'hébergement de 0 $/mois (plus ~12 $/an de nom de domaine).

Ce qu'il vous faut. Un ordinateur avec un navigateur, un compte Claude (claude.ai — l'outil Claude Code est encore plus puissant pour ce travail), 2 à 3 heures par étape, et un vrai problème à résoudre. Aucune ligne de code à connaître — mais l'envie de comprendre ce que l'IA produit.

⚠️ La règle d'or du guide. Ne publiez jamais ce que vous ne comprenez pas au moins dans les grandes lignes. À chaque étape, demandez à Claude : « Explique-moi ce que fait ce code, comme à un débutant. » C'est la différence entre un architecte et quelqu'un qui empile des briques les yeux fermés.

Choisissez une étape dans le menu — une seule s'affiche à la fois.

Étape 1 — Clarifier le problème avant l'outil

⏱ 1 à 2 heures · 🎯 Vous allez produire : une fiche projet d'une page

Le principe

Une idée sans exécution ne vaut rien ; mais une exécution sans problème clair ne vaut pas mieux. Avant d'ouvrir Claude, répondez par écrit à quatre questions : Qui a un problème ? Quel problème, en une phrase ? Quelle preuve avez-vous que ce problème existe (des gens vous le demandent, vous l'avez vécu, un marché mal servi) ? Quelle est la plus petite version utile — le MVP — livrable en semaines, pas en mois ?

Le cas Lojik360

Qui : les apprenants haïtiens et francophones. Problème : aucune formation à l'IA, à la pensée critique et aux données n'existe en kreyòl. Preuve : le créateur travaille dans la formation en Haïti et voit le vide chaque semaine ; les contenus français existants (France) ignorent ce public. MVP : un site statique avec UN tutoriel gratuit et une page d'accueil qui pose le manifeste — pas de comptes, pas de paiement, pas d'application mobile.

Déléguer / Superviser

Claude est excellent pour challenger votre idée avant d'écrire du code. Utilisez ce prompt :

Voici mon idée d'application : [décrire en 5 lignes : qui, problème, preuve, MVP]. Joue le rôle d'un investisseur sceptique : pose-moi les 5 questions qui fâchent, identifie ce qui existe déjà sur ce marché, et propose une version PLUS PETITE de mon MVP livrable en 2 semaines.

✅ Vous avez fini quand votre fiche projet tient sur une page et qu'une personne extérieure comprend en 30 secondes qui vous servez et pourquoi.

Étape 2 — Choisir l'architecture la plus simple qui marche

⏱ 1 heure · 🎯 Vous allez produire : un schéma de 3 briques et un budget

Le principe

L'erreur classique du débutant conseillé par des vidéos : démarrer avec une « vraie » stack de startup (base de données, framework, serveurs) pour un projet qui n'a encore aucun utilisateur. Chaque brique ajoutée est une chose à sécuriser, payer et maintenir. La règle : statique d'abord, dynamique seulement où c'est indispensable.

Les 3 briques de Lojik360 (coût : ~0 $/mois)

Un site statique sur GitHub Pages (gratuit) : des fichiers HTML/CSS/JS servis tels quels. Pas de serveur à pirater, pas de base à fuiter, rapidité maximale. C'est suffisant pour 90 % des sites de contenu, vitrines et outils simples.
Un nom de domaine (~12 $/an, ex. Porkbun) : votre adresse à vous, indépendante de tout hébergeur.
Un « worker » Cloudflare (gratuit jusqu'à 100 000 requêtes/jour) : un petit programme serveur pour les RARES choses qui exigent un secret ou un stockage — chez Lojik360 : l'assistant IA (la clé API doit rester cachée) et la newsletter (stocker les e-mails).

Quand passer à une vraie base de données ?

Seulement quand votre application a des comptes utilisateurs avec des données privées (un SaaS de gestion, par exemple). À ce moment-là, prenez un modèle éprouvé (template Open SaaS, Supabase…) — et lisez d'abord l'étape 9 de ce guide, deux fois.

Voici mon projet : [fiche de l'étape 1]. Propose-moi l'architecture LA PLUS SIMPLE possible, en privilégiant un site statique gratuit. Pour chaque brique, dis-moi : à quoi elle sert, ce qu'elle coûte, et ce qui se passerait si je m'en passais. Ne me propose ni framework ni base de données sauf nécessité absolue — justifie chaque ajout.

Étape 3 — Préparer les trois comptes

⏱ 1 heure · 🎯 Vous allez produire : un dépôt GitHub vivant, prêt à publier

Les comptes

GitHub (gratuit) : c'est à la fois votre sauvegarde, votre historique (chaque version est conservée — le filet de sécurité qui permet d'oser), et votre hébergeur via GitHub Pages. Créez un « repository » (dépôt) pour votre projet.
Claude : claude.ai suffit pour commencer (vous copiez-collez les fichiers) ; Claude Code est le niveau supérieur — il lit et écrit directement vos fichiers, exécute les commandes et publie pour vous. Lojik360 est entièrement construit ainsi.
Cloudflare (gratuit) : seulement quand vous atteindrez l'étape 7.

Le geste fondamental : publier = pousser

Avec GitHub Pages activé sur votre dépôt (Settings → Pages → branche main), chaque modification « poussée » est en ligne en une minute. Pas de FTP, pas de panneau d'hébergement : votre historique Git EST votre déploiement. Un domaine personnalisé se branche avec 4 lignes de DNS.

Guide-moi pas à pas, comme un débutant complet sous [Windows/Mac] : créer mon dépôt GitHub « mon-projet », y mettre un fichier index.html minimal, activer GitHub Pages, et vérifier que la page est en ligne. Donne-moi les commandes exactes et dis-moi à quoi ressemble le succès à chaque étape.

⚠️ Dès le premier jour : activez la double authentification (2FA) sur GitHub. C'est le compte qui contrôle tout le reste.

Étape 4 — La première page avec Claude : l'art du prompt de construction

⏱ 2 à 3 heures · 🎯 Vous allez produire : votre page d'accueil, en ligne

L'anatomie d'un bon prompt de construction

La qualité de ce que Claude produit dépend directement de ce que vous précisez. Un bon prompt de construction contient quatre blocs — exactement comme dans notre tutoriel Prompting :

Le contexte : qui vous êtes, pour qui est le site, ce qui existe déjà ;
Le résultat attendu : les sections de la page, dans l'ordre, avec le vrai contenu (pas de « lorem ipsum » — donnez vos vrais textes) ;
Les contraintes : HTML/CSS/JS purs sans framework, couleurs et polices imposées, mobile d'abord, léger ;
Le critère de succès : « je dois pouvoir ouvrir le fichier et voir la page finie ».

Le prompt qui a lancé Lojik360 (à adapter)

Crée la page d'accueil statique d'un site éducatif nommé [NOM]. Public : [décrire]. Structure : barre de navigation (Accueil, Tutoriels, Contact), un bandeau principal avec ce slogan : « [slogan] », une section manifeste avec ce texte : [coller], trois cartes présentant [vos 3 piliers], un pied de page. Contraintes : un seul fichier index.html + un fichier assets/style.css, AUCUN framework, couleurs : fond [X], accent [Y], responsive mobile. Écris du HTML propre et commente le CSS pour que je puisse apprendre en le lisant.

Itérer petit, vérifier à chaque pas

Ne demandez jamais « tout le site » d'un coup. Une page, vous regardez dans le navigateur, vous corrigez (« le titre est trop gros sur mobile », « mets le bouton en haut »), puis la suivante. Chaque itération publiée = un commit — si une modification casse tout, l'historique vous ramène en arrière en une commande.

✅ Vous avez fini quand votre page d'accueil est en ligne à votre adresse, s'affiche bien sur votre téléphone, et que vous savez expliquer ses 3 fichiers.

Étape 5 — Un design cohérent… et multilingue si votre public l'exige

⏱ 2 à 4 heures · 🎯 Vous allez produire : une feuille de style unique + (option) un site en plusieurs langues

Le design system du pauvre (qui est en fait très riche)

Toute la cohérence visuelle de Lojik360 tient dans une seule feuille CSS avec des variables : les couleurs et polices sont définies UNE fois (--navy, --teal, --amber…), toutes les pages les réutilisent. Demandez ça explicitement à Claude — sinon chaque page réinvente ses styles et le site devient un patchwork.

Refactorise mon CSS : extrais toutes les couleurs, polices et arrondis en variables CSS dans :root. Toutes les pages doivent partager assets/style.css. Ajoute les classes réutilisables .card, .btn, .banner avec le même langage visuel. Ne change pas l'apparence actuelle.

Le multilingue à la Lojik360 (4 langues, zéro framework)

Deux mécanismes selon la taille du texte : pour l'interface (menus, boutons, cartes), chaque élément porte un attribut data-i18n="cle" et un petit script charge un dictionnaire JSON par langue ; pour les pages longues (tutoriels), une page complète par langue (page.html, page.ht.html…) avec un sélecteur — jamais de langues mélangées sur une même page.

⚠️ La leçon la plus importante du projet : l'IA traduit la mécanique, mais PAS l'autorité. Le kreyòl de Lojik360 est validé mot par mot par un locuteur natif, avec un glossaire qui s'enrichit de chaque correction (« prompt » se dit pronpt, jamais de traduction mot à mot…). Si votre langue compte pour votre public, VOUS êtes le contrôle qualité — l'IA propose, vous tranchez.

Étape 6 — Le contenu à l'échelle : le pipeline documents → pages

⏱ selon votre contenu · 🎯 Vous allez produire : vos contenus publiés en série, sans copier-coller

Le principe

Votre valeur est dans vos documents (cours, catalogues, fiches produits) — pas dans le HTML. Plutôt que de copier-coller 50 fois, faites écrire par Claude un générateur : un petit script qui lit vos documents Word et fabrique les pages web automatiquement, toujours dans le même gabarit.

Le cas Lojik360 : 27 sessions en une commande

Les 27 sessions de formation existaient en Word. Claude a écrit un script Python qui lit chaque document (titres, tableaux, listes), le transforme en page web avec sommaire interactif, et signale tout ce qui manque. Résultat : 6 pages complètes générées et vérifiées en une session de travail — et quand un document source change, on régénère au lieu de rééditer. Le même pipeline a servi pour les traductions : nouveau document kreyòl → mêmes pages en kreyòl.

Voici un de mes documents Word : [joindre]. Écris un script Python qui le lit et génère une page HTML dans mon gabarit [joindre une page existante], avec : titres → sections, tableaux → tableaux HTML, un sommaire cliquable. Le script doit VÉRIFIER qu'aucune section ne sort vide et me lister les anomalies au lieu de les cacher.

✅ Cette étape est la plus rentable du guide : elle transforme un travail de semaines en un travail d'heures, et c'est elle qui rend votre site vivant (publier du neuf devient trivial).

Étape 7 — Du dynamique sans serveur : votre premier worker

⏱ 2 à 3 heures · 🎯 Vous allez produire : une fonction serveur réelle (formulaire, chat IA…) — sans gérer de serveur

Pourquoi un worker ?

Deux choses sont impossibles dans un site statique : garder un secret (une clé API dans votre page serait visible par tous — c'est l'erreur n°1 des débutants) et stocker des données (e-mails d'une newsletter). Un worker Cloudflare est un mini-programme qui tourne chez Cloudflare : votre page lui parle, lui seul connaît la clé.

Les deux workers réels de Lojik360

L'assistant IA « Lojik » : la page envoie la question au worker → le worker appelle l'API Claude avec la clé (stockée en « secret » Cloudflare, jamais dans le code) → renvoie la réponse. Limité à 15 messages/jour par visiteur pour maîtriser le coût.
La newsletter : le formulaire envoie l'e-mail au worker → il le valide CÔTÉ SERVEUR (format, longueur, 5 inscriptions max/jour/IP) → le stocke. Le HTML valide aussi, mais seulement pour le confort : le serveur ne fait jamais confiance au navigateur.

Écris un worker Cloudflare en JavaScript pur avec une route POST /subscribe qui : valide un e-mail côté serveur (format + longueur max), limite à 5 requêtes/jour par adresse IP, stocke l'e-mail en KV, restreint le CORS à mon domaine [X]. Puis donne-moi les commandes wrangler pour créer le KV, poser le secret et déployer. Explique chaque protection.

⚠️ Trois règles absolues : tout secret vit dans les secrets de la plateforme (jamais dans le code, jamais dans Git) ; toute entrée utilisateur est validée côté serveur ; toute route qui coûte de l'argent (IA !) a une limite par visiteur.

Étape 8 — Superviser : tester et vérifier comme un pro

⏱ en continu · 🎯 Vous allez produire : une routine de vérification qui attrape les erreurs avant vos visiteurs

La discipline qui sépare l'amateur du professionnel

Prévisualiser en local avant de publier : demandez à Claude de vous installer un petit serveur local (une commande Python suffit) pour voir le site exactement comme en ligne.
Tester le parcours réel, pas juste « ça s'affiche » : cliquer chaque lien, soumettre le formulaire avec une adresse bidon ET une vraie, ouvrir sur téléphone, tester chaque langue.
Automatiser la relecture : pour tout ce qui se vérifie par une règle, faites écrire un vérificateur. Lojik360 a un scanner qui détecte les restes de français dans les pages kreyòl (accents interdits, mots-outils) — 36 pages relues en 2 secondes, l'humain ne relit que les blocs suspects. Cette « relecture par exception » a réduit un travail de jours à une heure.
Demander à Claude de vérifier Claude : « Relis ce que tu viens d'écrire comme un correcteur sévère : liste ce qui peut casser, ce qui manque, ce qui est incohérent. »

✅ Le réflexe : jamais de publication le soir sans avoir cliqué soi-même le parcours principal. Git permet de revenir en arrière, mais vos visiteurs, eux, ont vu la page cassée.

Étape 9 — Sécuriser avant d'ouvrir : les 5 erreurs qui tuent les apps « vibe codées »

⏱ une demi-journée · 🎯 Vous allez produire : un audit écrit de votre app, les 5 cases cochées

Les 5 erreurs (et comment Lojik360 les évite)

Clés API et secrets exposés. Tout ce qui atteint le navigateur est public. Vérifiez vos fichiers ET votre historique Git (une clé effacée reste dans l'historique !). Parade : secrets de plateforme + scan de l'historique avant chaque publication.
Données non cloisonnées (RLS manquant). Si votre app a des comptes : l'utilisateur A ne doit JAMAIS pouvoir lire les données de B, même en devinant une adresse. Chaque requête serveur vérifie l'identité PUIS filtre par propriétaire — et un test automatique le prouve. Sans base de données ? Vous êtes protégé par construction : c'est un argument de plus pour l'étape 2.
Validation seulement côté navigateur. Un attaquant n'utilise pas votre formulaire, il parle directement à votre serveur. Toute règle qui compte est appliquée côté serveur.
Packages inventés ou obsolètes. L'IA peut suggérer des librairies qui n'existent pas (et des pirates publient des faux packages à ces noms !). Vérifiez chaque dépendance sur le site officiel — ou mieux : moins de dépendances. Lojik360 en a zéro.
Routes sans authentification. Listez TOUTES vos routes et écrivez à côté de chacune qui y a droit et qu'est-ce qui le vérifie. Une route d'admin « cachée » n'est pas protégée — elle est juste pas encore trouvée.

Audite mon application contre ces 5 erreurs : secrets exposés (code + historique git), cloisonnement des données, validation serveur, dépendances douteuses, routes sans authentification. Pour chaque point : vérifie dans MON code réel (pas de généralités), montre-moi la preuve, propose le correctif, et classe par gravité.

Faites cet audit avant le premier utilisateur réel, puis à chaque ajout de fonctionnalité. Les hébergeurs sérieux (Cloudflare, Render, Aiven…) sécurisent la plomberie — ces 5 erreurs, elles, vivent dans votre code : aucun hébergeur ne les corrige à votre place.

Étape 10 — Publier, mesurer, itérer

⏱ en continu · 🎯 Vous allez produire : une boucle d'amélioration hebdomadaire

Le lancement n'est pas la fin — c'est le début de la boucle

Référencement de base : un sitemap.xml + robots.txt (Claude les génère en une minute), des titres et descriptions soignés par page. Sur une niche mal servie, c'est déjà décisif.
Capturez l'intérêt : un formulaire e-mail qui marche vraiment (étape 7) — chaque visiteur intéressé qui repart sans laisser de trace est une perte sèche.
Outillez les non-codeurs (vous dans 6 mois !) : Lojik360 a une page d'administration où l'on modifie le texte d'un tutoriel comme dans Word, et chaque « Publier » devient un commit Git. Demandez le même genre d'outil pour ce que vous modifierez souvent.
La boucle hebdo : un contenu ou une amélioration par semaine, poussée le même jour. La régularité bat la perfection — et chaque session avec Claude repart de l'historique Git, donc rien ne se perd entre deux sessions.

✅ Vous avez fini le guide quand : votre app est en ligne sur votre domaine, l'audit de l'étape 9 est écrit, un vrai utilisateur l'a utilisée devant vous, et vous savez publier une amélioration en moins de 15 minutes.

Erreurs courantes & ligne d'arrivée

Les pièges vus sur le terrain

Demander « tout le site » en un prompt — itérez page par page, fonctionnalité par fonctionnalité.
Accepter du code qu'on ne comprend pas — exigez l'explication, c'est votre formation gratuite.
Commencer par la base de données et les comptes utilisateurs « au cas où » — commencez statique.
Payer un abonnement poussé par un parcours d'inscription sans vérifier s'il est nécessaire — lisez ce que vous validez.
Croire qu'un hébergeur « sécurisé » dispense de l'audit des 5 erreurs — la sécurité vit dans votre code.
Laisser l'IA décider de ce qui touche votre langue, votre culture, votre réputation — elle propose, vous tranchez.

Et pour un vrai SaaS avec comptes et paiements ?

Le processus reste le même, la barre monte : partez d'un template éprouvé (Open SaaS…), appliquez l'étape 9 comme une loi, ajoutez sauvegardes testées et rôles utilisateurs. C'est exactement le chantier des produits Atmart (Arpentaj, Lojik360 Studio) — et le sujet d'un futur guide.

🏁 Ligne d'arrivée. Vous n'êtes plus un exécutant qui tape du code, ni un spectateur qui regarde l'IA faire : vous êtes l'architecte. Vous déléguez la construction, vous supervisez chaque brique, et vous renforcez ce que l'IA n'aura jamais — la connaissance de votre public et la responsabilité de ce que vous publiez. Maintenant, construisez le vôtre — et montrez-le nous.