Six semaines, c'est notre delai standard pour amener un site marketing du brief a une beta utilisable. Pas un brief de geant SaaS avec dix langues, mais un site éditorial ou corporate de quinze a quarante pages. Voici comment nous structurons ces semaines.
Ce calendrier n'est pas une promesse magique. Il fonctionne lorsque le périmètre est clair, que les décideurs sont identifiés, que les contenus existent au moins en version brouillon, et que les validations ne s'empilent pas. Dans le cas contraire, le projet peut rester excellent, mais il ne sera probablement pas livré en six semaines.
Notre approche repose sur une idée simple : chaque semaine doit produire un livrable vérifiable. Pas seulement une réunion, pas seulement une intention. Un document, une maquette, un composant, une page intégrée, une liste de bugs priorisée. C'est ce qui évite l'effet tunnel classique des refontes web.
Les prérequis pour tenir six semaines
Avant même la semaine 1, nous vérifions trois conditions. D'abord, le projet doit avoir un objectif principal : générer des leads qualifiés, clarifier une offre, recruter, rassurer des investisseurs, ou repositionner une marque. Un site peut servir plusieurs objectifs, mais le design doit connaître sa priorité.
Ensuite, il faut un décideur final. Les retours d'une équipe marketing, commerciale ou produit sont précieux, mais une personne doit arbitrer. Sans arbitrage, chaque page devient un compromis entre préférences individuelles, et le planning se dilue.
Enfin, il faut savoir qui maintiendra le site après la bêta. Une PME avec une équipe marketing autonome n'a pas les mêmes besoins qu'une organisation qui passera par son agence pour chaque modification. Ce choix influence directement l'outil, la structure des composants et le niveau de documentation.
- Objectif business : savoir ce que le site doit améliorer en priorité.
- Décideur identifié : éviter les validations contradictoires.
- Contenus disponibles : textes, images, offres, preuves, cas clients.
- Stack assumé : Webflow, Framer, WordPress, Next.js ou autre selon l'équipe.
- Contraintes connues : CRM, formulaires, cookies, langues, hébergement, conformité.
Si ces points sont flous, nous préférons ajouter une phase de préparation plutôt que de lancer une fausse semaine 1. Pour les projets de refonte, cette préparation rejoint souvent les étapes décrites dans notre guide sur les erreurs à éviter lors d'une refonte de site web.
Semaine 1 — Cadrage et structure
Lundi : atelier de cadrage en presentiel ou visio, trois heures. Douze questions essentielles (cf notre article dedie), liste des pages, hierarchie éditoriale.
Dans cet atelier, nous ne cherchons pas encore la meilleure couleur ni le style du bouton principal. Nous cherchons la logique du site : qui arrive, avec quelle intention, quelles objections, quelles preuves, et quelle action doit sembler naturelle à la fin du parcours.
Les questions portent aussi sur ce qui ne doit plus être présent. Beaucoup de sites accumulent des pages historiques, des offres abandonnées, des actualités faibles, ou des contenus créés pour une ancienne stratégie. Supprimer, fusionner ou rétrograder une page est parfois aussi important que d'en créer une nouvelle.
Mardi-mercredi : audit du site actuel (analytics, hotjar/clarity, verbatims support), benchmark de trois concurrents, identification des pages qui doivent gagner ou perdre de l'importance.
Nous croisons les données quantitatives avec les retours terrain. Les analytics montrent les pages consultées, les parcours fréquents, les points de sortie. Les verbatims commerciaux et support montrent les questions réelles : prix, délai, garanties, cas d'usage, compatibilité, niveau d'accompagnement.
Comme le rappelle le Nielsen Norman Group, la recherche UX ne consiste pas seulement à demander aux utilisateurs ce qu'ils veulent, mais à observer leurs comportements, leurs blocages et leurs modèles mentaux. Même sur un site marketing simple, cette discipline évite de concevoir uniquement pour l'interne.
Jeudi-vendredi : arborescence finale validee avec le client, brief éditorial pour chaque page (intention, audience cible, indicateur de succes), choix du stack technique selon qui maintient.
Le brief éditorial d'une page tient en général sur une demi-page. Il précise le rôle de la page dans le parcours, la promesse principale, les objections à traiter, les preuves disponibles et le CTA attendu. Pour approfondir cette phase, nous utilisons souvent notre grille d'audit UX en 12 questions essentielles.
Livrable fin de semaine 1 : un document de huit a douze pages que toute l'équipe a relu et signe. Sans ce document, on ne passe pas en semaine 2.
Semaine 2 — Direction créative
Lundi-mardi : moodboards, deux directions creatives proposees, mises en context sur la home et une page intermediaire. Pas des Figmas finis : des references plus une page maquettee.
Une direction créative n'est pas seulement une ambiance visuelle. Elle traduit un positionnement : premium ou accessible, expert ou pédagogique, institutionnel ou challenger, sobre ou expressif. Deux directions bien construites doivent raconter deux stratégies possibles, pas deux variantes décoratives.
Nous testons rapidement les décisions structurantes : densité d'information, style iconographique, niveau d'animation, usage de la photo, tonalité des titres, présence ou non d'illustrations. Les choix de typographie et de couleur sont traités tôt, car ils influencent fortement la perception de crédibilité et de clarté. Sur ce sujet, notre article sur les palettes de couleurs qui convertissent détaille comment dépasser la simple logique de charte.
Mercredi : presentation au client. Choix d'une direction, ajustements demandes. Souvent un melange des deux propositions.
Le mélange des deux directions est acceptable si l'on fusionne des intentions compatibles. Il devient dangereux lorsqu'on prend la sobriété de l'une, l'énergie de l'autre, la typographie d'une troisième référence et les animations vues chez un concurrent. Le rôle de l'agence est de protéger la cohérence, pas d'empiler les préférences.
Jeudi-vendredi : finalisation de la direction choisie, palette finale, typo finale, premiers composants Figma (button, card, hero variants).
À ce stade, nous commençons à structurer le fichier Figma comme un produit de travail, pas comme une planche d'inspiration. Les composants sont nommés, les variantes sont limitées, les styles typographiques sont stabilisés. Les bonnes pratiques documentées par Figma Learn sont utiles pour maintenir un fichier lisible lorsque plusieurs designers et développeurs interviennent.
Livrable fin de semaine 2 : la home et une page intermediaire en design final, signees client. Plus une bibliotheque Figma de composants de base.
Comment nous organisons les validations
La validation est le vrai sujet caché d'un projet en six semaines. Ce n'est pas la production qui bloque le plus souvent, mais la multiplication des retours tardifs. Pour limiter ce risque, chaque validation a un périmètre précis.
- En semaine 1 : on valide la structure, pas le style graphique.
- En semaine 2 : on valide la direction créative, pas chaque micro-contenu.
- En semaines 3 et 4 : on valide les gabarits et les pages clés, pas une refonte de l'arborescence.
- En semaine 5 : on valide l'intégration des contenus réels et les ajustements nécessaires.
- En semaine 6 : on valide les corrections bloquantes avant la bêta.
Nous demandons aux clients de regrouper les retours dans un seul canal : commentaire Figma, document partagé ou outil de ticketing. Les retours dispersés entre e-mails, messages instantanés et appels créent des doublons, des contradictions et des oublis.
Un bon retour décrit un problème, pas forcément une solution. “Le bloc ne hiérarchise pas assez notre offre principale” est plus utile que “mettre ce titre en rouge”. Cela laisse au designer la responsabilité de proposer la meilleure réponse visuelle.
Semaines 3 et 4 — Production design
Le designer principal produit les pages restantes en s'appuyant sur les composants existants. Rythme typique : trois a quatre pages par jour pour un site simple, une a deux pour des pages complexes (pricing, calculateur, configurateur).
Les pages simples ne sont pas négligées pour autant. Une page “À propos”, “Carrières” ou “Contact” peut sembler secondaire, mais elle porte souvent une part importante de la confiance. Nous cherchons donc à éviter les pages de remplissage, même lorsque le gabarit est rapide à produire.
Les pages complexes sont traitées comme des mini-produits. Une page pricing, par exemple, doit clarifier les offres, réduire les comparaisons inutiles, mettre en avant les critères de choix et rassurer sur les prochaines étapes. Notre case study sur une page pricing SaaS montre pourquoi ce type de page mérite un traitement spécifique.
Le developpeur, en parallele, commence l'integration des composants de base (boutons, cards, header, footer) dans le stack choisi. Sur Webflow, c'est environ trois jours. Sur Next.js, environ une semaine.
Ce chevauchement design-développement est essentiel. Il permet d'identifier tôt les composants coûteux, les animations trop lourdes, les cas responsives oubliés ou les contraintes CMS. Le choix entre Figma, Webflow, Framer ou un framework plus technique doit être cohérent avec le niveau d'autonomie attendu ; nous détaillons ces arbitrages dans notre comparatif Figma vs Webflow vs Framer.
Reunions hebdo : un point lundi (advancement, blocages), un point jeudi (revue des pages produites, ajustements). Pas plus.
Entre ces points, le travail avance de manière asynchrone. Cela évite de transformer le projet en suite de réunions de validation. Les commentaires se font directement sur les maquettes ou sur l'environnement de préproduction, avec une règle simple : un commentaire doit être compréhensible sans réunion supplémentaire.
Livrable fin de semaine 4 : design termine sur quatre-vingt-dix pourcent des pages, integration commencee sur la home et les composants partages.
Semaine 5 — Integration et contenu
Integration des pages restantes au developpement. En parallele, integration des contenus reels (textes, photos, videos). C'est ici qu'on decouvre que la page presse n'a pas de photos clients exploitables, ou que le texte de la home depasse la maquette de quarante pourcent.
Ne pas paniquer : c'est la semaine normale ou les contenus reels confrontent le design. Mieux vaut adapter le design que de forcer le contenu a entrer dans une maquette ideale.
Nous vérifions alors trois choses : la lisibilité, la hiérarchie et la robustesse. La lisibilité concerne les titres, les paragraphes, les listes et les blocs longs. La hiérarchie vérifie que l'information importante reste visible. La robustesse garantit que le composant ne casse pas lorsqu'un titre est plus long, qu'une image manque, ou qu'un champ CMS est vide.
Le contenu réel met aussi en lumière les absences : pas assez de preuves, peu de cas clients, promesses trop génériques, photos incohérentes, témoignages non sourcés, offres difficiles à comparer. Plutôt que de maquiller ces faiblesses, nous préférons les traiter explicitement : reformuler, simplifier, ajouter une FAQ, créer un bloc preuve ou réduire une section trop ambitieuse.
À ce moment, nous préparons également les bases SEO : titres de pages, méta-descriptions, structure des H2/H3, maillage interne, textes alternatifs pertinents, slugs propres. L'objectif n'est pas de “faire du SEO” en surface, mais de rendre chaque page compréhensible pour les humains comme pour les moteurs.
Livrable fin de semaine 5 : site en preprod, navigable de bout en bout, avec contenus reels.
Le contenu, le tracking et la conformité
Un site marketing ne se limite pas à des pages visibles. Il contient aussi des formulaires, des scripts de mesure, des pixels publicitaires, des outils de session replay, parfois un CRM ou une newsletter. Ces éléments doivent être anticipés avant la mise en ligne.
Pour les cookies et autres traceurs, la CNIL publie des recommandations à consulter lorsqu'un site utilise des outils de mesure, de publicité ou de personnalisation. Nous pouvons préparer l'implémentation technique, mais la conformité finale doit être validée par les personnes compétentes côté client, notamment le DPO ou un conseil juridique si nécessaire.
Nous documentons aussi les événements utiles : envoi de formulaire, clic sur un CTA clé, téléchargement, demande de démo, inscription newsletter, changement de langue. Mieux vaut suivre peu d'événements bien nommés que multiplier des mesures impossibles à interpréter.
Cette semaine est également le bon moment pour vérifier les redirections prévues. Une refonte qui oublie les anciennes URL peut perdre une partie de son capital SEO et créer une mauvaise expérience utilisateur. Nous préparons donc une table simple : ancienne URL, nouvelle URL, type de redirection, statut.
Semaine 6 — QA, accessibilite, performance
Lundi-mardi : recette client. Liste des bugs et ajustements. On distingue les bloquants (a fixer avant beta), les non-bloquants (a fixer dans le mois apres beta), et les nice-to-have (a reporter en v2).
Cette distinction protège le lancement. Un formulaire qui ne fonctionne pas est bloquant. Une faute dans un titre important peut l'être aussi. Une animation qui pourrait être plus fluide, un pictogramme à remplacer ou une variation de padding sont rarement des raisons de repousser une bêta si le site est utilisable, compréhensible et mesurable.
Mercredi : audit accessibilite (WCAG AA minimum), audit performance (Lighthouse / WebPageTest), corrections seo (meta, robots, sitemap, structured data).
Les Web Content Accessibility Guidelines WCAG 2.2 constituent la référence internationale pour évaluer l'accessibilité numérique. Dans notre QA, cela se traduit par des vérifications concrètes : contrastes, navigation clavier, libellés de formulaires, textes alternatifs, ordre de lecture, états de focus, messages d'erreur.
Côté performance, nous nous appuyons sur les recommandations de Google web.dev pour surveiller les fondamentaux : poids des images, chargement des polices, scripts tiers, stabilité visuelle, temps de réponse serveur. La performance n'est pas seulement une note Lighthouse ; c'est une condition de confort, surtout sur mobile.
Jeudi-vendredi : derniers ajustements, tests cross-browser, mise en ligne, redirections du site actuel vers le nouveau.
Nous testons les principaux parcours : arriver sur la home, comprendre l'offre, consulter une page de service, lire une preuve, envoyer un formulaire, revenir à une page précédente, naviguer sur mobile, refuser ou accepter les cookies, ouvrir le site sur plusieurs navigateurs. Les tests sont répétitifs, mais ils évitent les surprises publiques.
Livrable fin de semaine 6 : beta en ligne sur le NDD client. Officielle mais clairement annoncee comme beta : les retours utilisateurs reels permettent les ajustements V1 sur le mois suivant.
Ce qui rallonge
Plus de quinze pages tres differentes. Multi-langue. Integration CRM complexe. Migration de site existant avec gestion de centaines d'URL. Contenus non disponibles. Validation par plusieurs comités. Reprise d'une identité de marque instable. Besoin d'illustrations sur mesure. Photographie à produire. Dépendance à une équipe IT externe.
Le multilingue est un bon exemple. Traduire les textes ne suffit pas : il faut gérer les slugs, les menus, les redirections, les champs CMS, les balises hreflang, parfois les différences culturelles dans les preuves et les CTA. Une version anglaise peut sembler “juste une duplication”, mais elle ajoute de vrais points de contrôle.
Les intégrations CRM rallongent aussi le projet lorsqu'elles exigent des règles métier : attribution commerciale, scoring, champs conditionnels, synchronisation avec un outil existant, notifications internes. Dans ce cas, nous isolons souvent l'intégration avancée dans un lot séparé afin de ne pas bloquer la bêta publique.
La marque peut également être un facteur de délai. Si le logo, la voix, les couleurs et les usages ne sont pas stabilisés, le site devient le lieu où tous les débats de marque ressortent. Pour éviter cela, il est préférable de clarifier la charte en amont ; notre guide sur la construction d'une charte de marque cohérente peut servir de base.
Ce qui ne doit pas être sacrifié
Tenir six semaines ne veut pas dire couper dans tout. Certains éléments doivent rester non négociables, car ils conditionnent la qualité du site dès la bêta.
- La clarté de l'offre : un visiteur doit comprendre rapidement ce que vous proposez, pour qui, et avec quelle valeur.
- La cohérence responsive : le mobile ne doit pas être une version compressée et confuse du desktop.
- L'accessibilité de base : contrastes, formulaires, clavier, textes alternatifs et structure sémantique.
- La performance : images optimisées, scripts maîtrisés, polices chargées proprement.
- La mesure : les conversions importantes doivent être traçables dès le lancement.
- Les redirections : les anciennes URL importantes doivent mener vers des pages pertinentes.
En revanche, certaines ambitions peuvent attendre : animations avancées, bibliothèque d'illustrations complète, pages secondaires très éditorialisées, personnalisation dynamique, A/B testing sophistiqué. La bêta sert justement à séparer ce qui est indispensable de ce qui semble séduisant en interne.
Le mois après la bêta
Nous ne considérons pas la mise en ligne comme la fin du projet. Le mois qui suit est une période d'observation et d'ajustement. Les utilisateurs réels vont révéler des points que ni l'agence ni le client ne peuvent entièrement anticiper.
Nous suivons les retours qualitatifs, les conversions, les recherches internes s'il y en a, les formulaires incomplets, les pages sans suite, les questions commerciales récurrentes. Les ajustements sont ensuite priorisés selon leur impact probable et leur effort.
Cette phase évite deux erreurs opposées : laisser le site figé alors qu'il vient d'être confronté au réel, ou relancer immédiatement une refonte de la refonte. L'idée est de stabiliser la V1 avec des interventions ciblées : clarifier un titre, déplacer une preuve, simplifier un formulaire, enrichir une FAQ, ajuster une page de service.
Au bout de ce mois, le site n'est plus seulement “livré”. Il commence à devenir un outil vivant, maintenable, aligné sur les retours du marché. C'est souvent là que la valeur du processus apparaît : moins de décisions subjectives, plus d'améliorations basées sur l'usage.
Questions fréquentes
Un site web peut-il vraiment être conçu en six semaines ?
Oui, si le périmètre est maîtrisé, les contenus sont disponibles et les validations sont rapides. Pour un site corporate ou marketing de taille raisonnable, six semaines permettent d'atteindre une bêta solide, pas une plateforme complexe entièrement sur mesure.
Que faut-il préparer avant le lancement du projet ?
Il faut préparer les objectifs du site, la liste des pages, les contenus existants, les accès techniques, les contraintes de marque et les personnes responsables des validations. Plus ces éléments sont clairs, moins le projet perd de temps en arbitrages tardifs.
Quelle est la différence entre une bêta et une version finale ?
Une bêta est une version publique, utilisable et mesurable, mais encore ouverte aux ajustements issus des retours réels. Une version finale suppose que les contenus, les parcours, les performances et les détails visuels ont été stabilisés après observation.
Qu'est-ce qui fait le plus souvent déraper le planning ?
Les causes les plus fréquentes sont les contenus manquants, les validations multiples, les changements d'arborescence en cours de route, les intégrations techniques sous-estimées et les débats de marque non tranchés avant le design.