Le calendrier ci-dessous suppose un client prêt à décider, un marché de lancement principal, un récit de produit défini et des commentaires d'un petit groupe d'approbateurs désignés. Plusieurs volets de travail se chevauchent. Les semaines sont des semaines civiles, et non une promesse que chaque tâche reçoit une semaine complète d'effort.
Semaines 1 à 2 : découverte et définition du lancement
La première étape est une portée signée, pas un tableau d'ambiance. L'équipe confirme le public, la date de lancement, l'action de conversion, les faits sur le produit, les responsables du contenu, les besoins d'analytique, les contraintes techniques et les appareils qui comptent.
Les livrables devraient comprendre un mandat, un registre des risques, un inventaire du contenu, un journal des décisions et une définition du succès du lancement. Si l'équipe ne peut pas expliquer ce que le visiteur doit faire après l'interaction du bandeau, le projet n'est pas prêt pour un travail 3D coûteux.
Semaines 2 à 4 : concept d'expérience et essai technique
L'agence transforme le récit en un petit nombre de concepts d'interaction et réalise un essai technique pour le plus risqué. C'est le moment de tester le comportement des shaders, le poids des ressources, la saisie tactile, le chargement et la solution de repli avant que la direction visuelle devienne coûteuse à modifier.
L'essai devrait s'exécuter sur au moins un ordinateur de bureau récent, un appareil mobile de milieu de gamme et un appareil à faible puissance. Ce n'est pas une page terminée. C'est la preuve que l'interaction choisie peut survivre hors de la machine de l'équipe de design.
Semaines 3 à 6 : direction artistique, UX et planification des ressources
Le concept approuvé devient une structure de page, un système de mouvement, un plan de composants et une liste de ressources. L'équipe décide ce qui est en 3D en direct, ce qui est de la vidéo, ce qui est une image fixe et ce qui est du simple HTML. Cette décision est importante. Chaque moment n'a pas besoin d'un canevas.
Pour un lancement d'entreprise, incluez les approbations de contenu dans cette phase. Les énoncés sur le produit, le texte juridique, les traductions, les textes d'accessibilité et le suivi de campagne ne devraient pas arriver après la construction de l'interface.
Semaines 5 à 9 : production des shaders et des ressources 3D
Les artistes et les développeurs produisent les modèles, les textures, les matériaux, les transitions et les états d'interaction. L'équipe devrait maintenir en parallèle une solution de repli peu coûteuse plutôt que d'attendre la fin pour découvrir qu'un téléphone ne peut pas afficher confortablement le bandeau.
Demandez une ressource révisable à chaque jalon. Une seule révision finale crée un risque évitable, car un changement de géométrie ou d'éclairage peut influer en même temps sur la taille des fichiers, la fréquence d'images, la mise en page et le comportement de chargement.
Semaines 6 à 11 : développement front-end et CMS
Le développement transforme les écrans et les ressources approuvés en site fonctionnel. L'équipe branche le CMS, les formulaires, les données de produits, l'analytique, le comportement du consentement et toute connexion CRM ou commerce. L'environnement de préproduction devrait être assez proche de la production pour que les constats de performance soient significatifs.
Gardez la saisie du contenu en avance sur la dernière passe d'assurance qualité. Le texte provisoire modifie les retours à la ligne, la hauteur de page, l'ordre de focus et parfois le moment d'une animation. On ne peut pas tester correctement la performance d'une page tant que ses vraies ressources manquent.
Semaines 9 à 13 : passe de performance et d'accessibilité
La performance est une contrainte de design, pas une tâche de nettoyage. Les directives Core Web Vitals de Google fixent de bons objectifs au 75e centile des chargements de page : Largest Contentful Paint en 2,5 secondes ou moins, Interaction to Next Paint à 200 millisecondes ou moins, et Cumulative Layout Shift à 0,1 ou moins.
Ces objectifs ne signifient pas que chaque scène WebGL doit se charger en 2,5 secondes. Ils signifient que le premier contenu utile doit arriver rapidement, que la page doit répondre aux interactions et que la mise en page doit demeurer stable pendant le chargement de la scène. Testez le HTML et le canevas séparément afin qu'un bandeau visuellement impressionnant ne masque pas une page lente ou inutilisable.
L'accessibilité nécessite sa propre révision. Prévoyez un parcours significatif sans WebGL, l'accès au clavier, un texte lisible, un focus visible, un comportement adapté à la réduction des animations, des textes de remplacement utiles et une façon de réaliser l'action de lancement sans dépendre d'un pointeur ou de l'accélération graphique.
Semaines 12 à 16 : préproduction, gel du contenu et révision par les parties prenantes
La préproduction est le moment de tester l'expérience complète avec le contenu final, les intégrations, le suivi et des hypothèses de trafic représentatives. Désignez un seul responsable des commentaires consolidés. Une longue chaîne de commentaires distincts est un risque pour l'échéancier, car l'équipe ne peut pas savoir quelle décision est finale.
Utilisez une courte liste d'acceptation :
- L'action de lancement fonctionne sur les navigateurs et appareils pris en charge.
- L'expérience de repli explique le produit sans la scène 3D.
- La page demeure utilisable lorsque la réduction des animations est activée.
- L'analytique enregistre les étapes importantes, pas seulement les pages vues.
- Les formulaires, l'acheminement CRM, le consentement et les messages de confirmation fonctionnent.
- Le contenu, la révision juridique, la localisation et les redirections sont terminés.
- La mise en production peut être annulée.
Semaines 16 à 20 : mise en production et stabilisation
Réservez les dernières semaines à une mise en production contrôlée, pas à une nouvelle direction créative. Publiez auprès d'un petit public ou derrière un interrupteur de mise en production lorsque la campagne le permet. Surveillez les erreurs, le comportement de chargement, les événements de conversion et les questions au soutien. Corrigez les problèmes avant le lancement public.
L'étude de cas Lightship de Locomotive est un bon exemple de complexité de lancement. Le site a soutenu le lancement officiel d'un prototype de véhicule récréatif électrique à SXSW, a combiné une expérience immersive et une expérience accessible, et comprenait un parcours de précommande avec Stripe.
Son étude de cas Webisoft montre un autre modèle pertinent, combinant animation fluide, ressources 3D, navigation optimisée et plateforme évolutive. Aucune des deux pages ne publie de prix de projet ni de durée de livraison. C'est pourquoi la proposition, plutôt que le titre d'une étude de cas, doit définir votre budget.