Sites vitrines

Le problème à résoudre

Un artisan ébéniste, une marque de streetwear et un photographe événementiel n'ont presque rien en commun : pas la même clientèle, pas le même ton, pas les mêmes priorités. Un site vitrine générique — le même gabarit recoloré à chaque fois — ne sert aucun des trois correctement. L'objectif était de construire, pour chacun, une identité visuelle qui lui appartienne vraiment, tout en gardant la même structure derrière : une page unique, rapide, qui explique l'activité et pousse vers un contact WhatsApp ou un appel.

Le choix technique

Pas de framework pour ce type de site : HTML, CSS et JavaScript directement, sans couche supplémentaire à charger ni à maintenir. Pour un site vitrine d'une page, un framework front-end complet ajoute du poids et de la complexité sans bénéfice réel — alors qu'un site léger se charge plus vite, s'héberge n'importe où pour presque rien, et reste simple à modifier plus tard. Chaque site garde son propre style (néon et carrousel de drop pour le streetwear, bois et laiton pour l'ébénisterie, mise en scène cinéma pour le photographe), mais partage la même base : multilingue FR/AR/EN avec bascule automatique selon la langue du visiteur, mise en page adaptée à l'arabe (RTL), et un bouton de contact WhatsApp toujours visible.

Le détail qui a pris plus de temps que prévu

Les visuels. Trouver des photos qui correspondent vraiment à l'activité et au contexte du client — pas juste des photos de stock génériques — a demandé plusieurs passages : une première sélection qui correspondait au mot-clé recherché mais pas à la réalité du métier a dû être reprise entièrement. Un site vitrine vend une image autant qu'un service ; une photo qui sonne faux abîme la confiance plus vite qu'un texte mal tourné.

Côté effets visuels, la démo du photographe utilise un effet de projecteur qui suit le curseur — un détail qui devait rester contenu à l'intérieur de chaque section plutôt que de déborder sur la section suivante. Un oubli deoverflow: hiddensuffit à casser cet effet ; corrigé une fois repéré.

Ce que je referais différemment

Pour un client qui veut pouvoir changer ses textes ou ajouter un produit lui-même sans repasser par moi à chaque fois, un site 100 % statique montre vite ses limites. Pour ce profil-là, je passerais sur une base légèrement plus structurée (un petit CMS ou un contenu piloté par fichier) plutôt que du HTML entièrement codé en dur — tout en gardant la même légèreté et la même vitesse de chargement.