Web Assets, Polish & Launch (Actifs web, polissage et lancement)

Actifs web, polissage et lancement

Une routine courte pour le travail de finition d'un site qui existe déjà. Elle couvre les étapes visuelles et de mise en production de la compétence futuristic-web-design, regroupées pour pouvoir fonctionner seules.

Si ../futuristic-web-design/ se trouve à côté de cette compétence, ses fichiers de référence contiennent les détails : references/assets.md pour les prompts et les commandes ffmpeg, references/ship.md pour les passes, le formulaire, le déploiement, le domaine et la liste de contrôle complète du lancement.

Ne faites que la partie demandée par l'utilisateur. Chaque rubrique ci-dessous est autonome.

Préparer les fichiers pour le Web

Les sorties des générateurs et des appareils photo sont beaucoup trop lourdes pour être mises en ligne. Un visiteur utilisant des données mobiles attend chaque octet, tandis qu'un ordinateur portable lisant depuis son propre disque cache le problème.

Obtenez l'approbation avant d'installer des outils tels que ffmpeg ou sharp. Certaines versions de ffmpeg n'ont pas d'encodeur WebP ; cwebp ou sharp font le même travail si l'un d'eux est déjà installé.

Stockez les fichiers avec des noms descriptifs sous public/images/ dans Next.js. Dans un site HTML simple, conservez-les dans un dossier images/ à côté de la page : sur Vercel, un site sans framework ne sert que le dossier public/ lorsqu'il existe, ce qui cacherait la page elle-même.

Fichier	Cible
Image hero	WebP, au maximum 1920 px de large, environ 300 Ko
Autres images	WebP, au maximum environ 1000 px de large, environ 150 Ko
Vidéo hero (hero.mp4)	H.264 MP4, au maximum 1080p, audio supprimé, moins de 4 Mo
Poster (hero-poster.webp)	La première image de la vidéo

Terminez par un tableau des tailles avant et après, afin que l'économie soit montrée, pas seulement affirmée.

Rédiger des prompts pour les images et les vidéos

Ces prompts conviennent à Google Flow ou à tout autre générateur. Si vous pouvez générer directement, obtenez l'approbation avant de dépenser des crédits. Si vous ne le pouvez pas, remettez les prompts à l'utilisateur et continuez avec des espaces réservés clairement marqués.

• D'abord la liste des plans. Décidez des actifs et de leurs formats avant de générer : environ sept pour un site d'une seule page (vidéo hero, image fixe hero, trois offres, une image d'histoire, une image de partage).
• Le brief image, six parties dans l'ordre : sujet, décor, éclairage, caméra (hauteur, objectif, profondeur de champ), ambiance et palette, format (16:9 hero, 4:5 produit). Demandez des étiquettes vierges, car les générateurs déforment les lettres et le vrai texte appartient au HTML.
• La ligne de style. Reprenez les phrases d'éclairage, de caméra, d'ambiance et de palette de la première image approuvée et utilisez-les mot pour mot dans chaque prompt suivant. C'est ce qui donne l'impression d'un seul et même tournage.
• Vidéo hero. Animez l'image fixe approuvée, décrivez un petit mouvement et précisez que tout le reste reste figé avec une caméra fixe.
• Clip en vue éclatée. Image d'ouverture : le produit assemblé, petit et centré, avec un espace vide là où les pièces iront. Image de fermeture : construite à partir de l'image d'ouverture, jamais de zéro, avec les pièces espacées le long d'un seul axe droit et le même point de vue, éclairage et arrière-plan. Le clip passe de la première image à la seconde avec une caméra verrouillée.

Gardez les vraies personnes et les logos tiers hors des actifs générés, et montrez les vrais produits d'une vraie entreprise.

Téléphone, polissage et vitesse

• Passage téléphone à 390 px. Texte lisible, rien collé au bord, cibles tactiles d'environ 44 px, pas de défilement horizontal, un menu basculant fonctionnel. Corrigez sous forme de liste détaillée, puis faites défiler à nouveau. Un navigateur de bureau redimensionné n'est qu'une approximation d'un téléphone, demandez donc une vérification sur un vrai appareil et dites-le si ce n'est pas fait.
• Passage polissage. Espaces uniformes entre les sections, tailles égales pour les titres de même niveau, style de survol et de focus sur chaque élément interactif, pas de routes de prévisualisation oubliées.
• Vitesse. Profilez avec un préréglage mobile et nommez les trois améliorations les plus importantes, de la plus grande à la plus petite. Si l'une d'elles implique de supprimer quelque chose auquel l'utilisateur tient, signalez-la pour sa décision.

Listez ce que vous trouvez avant de modifier quoi que ce soit que l'utilisateur n'a pas demandé à modifier.

Clés

• .env.local contient les clés et est listé dans .gitignore.
• Le code du site n'utilise que des clés publiques. Les clés secrètes ou de service n'atteignent jamais le code client.
• Recherchez les secrets dans le code et dans l'historique Git, et signalez ce qui a été vérifié.
• Un secret qui a déjà été servi dans le code d'une page ou commité dans Git est exposé, même si le dépôt n'a jamais été poussé : les visiteurs pouvaient lire la page, et l'historique voyage avec chaque copie et chaque future poussée. Le supprimer du fichier n'annule pas cela. Dites à l'utilisateur de le faire tourner dans le tableau de bord du fournisseur, quelle que soit sa valeur apparente.

Recherche et partage

• Titre d'au maximum 60 caractères et description d'au maximum 155, indiquant ce qui est vendu et où. Le nom de la marque seul ne dit rien à un étranger.
• Image de partage de 1200x630 à public/images/share.webp, définie comme image Open Graph et Twitter.
• Favicon, sitemap et fichier robots.
• Définissez le domaine de production comme URL de base pour que l'image de partage et le sitemap soient résolus. Demandez-le s'il est inconnu.

Déploiement

Ne déployez que lorsque l'utilisateur le demande.

• Connectez le dépôt à Vercel. Chaque poussée vers la branche principale redéploie alors la production.
• Saisissez les valeurs de .env.local dans les paramètres du projet chez l'hébergeur. Un formulaire qui fonctionne en local et se casse en production est presque toujours dû à ces valeurs manquantes.
• En cas d'échec de la build, lisez le journal et corrigez la cause racine.
• Vérifiez sur l'URL de production depuis un téléphone en données mobiles : chargez la page, soumettez le formulaire et recherchez la ligne stockée.
• Collez le lien dans une application de messagerie pour vérifier la carte d'aperçu.

Signalez honnêtement : ce qui a été vérifié, ce qui n'a pas pu l'être (un téléphone physique, le domaine de production), et ce qui reste pour l'utilisateur.