On vous demande un site pour le lancement, pour le salon ou pour la levée, et la date est déjà dans l'agenda. La question tombe vite : combien de temps pour créer un site internet, et est-ce que quatre semaines suffisent ? Les réponses qu'on trouve vont de « deux jours avec un modèle » à « six mois », ce qui ne vous aide pas beaucoup à décider.
Je construis des sites seul, en missions courtes, et j'ai construit celui-ci en Next.js, Sanity et Vercel. En mai 2026, j'ai aussi refait le site marketing de Moonworkers, mon entreprise, sur la même base. Ce que j'en retiens : un délai court tient rarement à la vitesse du code. Il tient aux décisions et aux contenus. Voici comment je découpe quatre semaines, ce que je coupe pour tenir la date, et ce qui se passe après la mise en ligne.
01Ce qui décide vraiment du délai
Quand un planning de site glisse, je regarde d'abord trois choses, et le code n'en fait pas partie.
La première, ce sont les contenus. Un site sans textes, sans visuels et sans preuves n'est pas fini, même s'il est beau. Les textes arrivent presque toujours en dernier, parce que personne n'a bloqué de temps pour les écrire. Sur une production de contenu, j'ai vu que le goulot n'était pas l'écriture mais la mise en ligne faite à la main ; sur un site, c'est souvent l'inverse : tout est prêt sauf les mots.
La deuxième, c'est la décision. Combien de personnes doivent valider une maquette, et à quelle fréquence se réunissent-elles ? Une validation qui attend le comité du mois suivant coûte plus cher que n'importe quelle difficulté technique.
La troisième, c'est le périmètre. Chaque fonction ajoutée en route (un deuxième formulaire, une version anglaise, un espace client) repousse la date, et elle s'ajoute rarement seule.
02Ce qui tient en quatre semaines, et ce qui n'y tient pas
Quatre semaines, c'est assez pour un site vitrine ou un site de lancement : une dizaine de pages, un formulaire de contact, un blog ou une page d'actualités, une mesure d'audience, un outil d'édition que l'équipe sait utiliser. C'est aussi assez pour une première version qu'on améliorera ensuite.
Ça ne suffit pas pour un site marchand complet, un espace client, une connexion à un ERP ou une migration de plusieurs centaines de pages avec leurs redirections. Pour comparer, le manuel de service du gouvernement britannique indique que la phase alpha d'un service public dure en général 6 à 8 semaines, et qu'elle sert à tester des prototypes, pas à livrer du code de production. Un site en quatre semaines est donc une première version assumée, pas un produit terminé.
Je préfère le dire au départ. Une date courte se tient en retirant des choses, pas en travaillant la nuit.
03Mon découpage, semaine par semaine
Ce découpage suppose une personne qui décide, disponible une heure par jour, et des contenus écrits en parallèle de la construction. Sans ces deux conditions, je ne promets pas la date.
Semaine 1 : cadrer et choisir une direction
Je commence par quelques jours de diagnostic : à qui parle le site, quelle action on attend du visiteur, quelles pages sont indispensables le jour du lancement. J'en sors une liste de pages, un plan de contenu avec un responsable par texte, et la liste de ce qui attendra la version suivante. J'ai décrit cette étape plus en détail dans un article sur le cadrage d'un projet digital en une semaine.
En fin de semaine, je montre deux ou trois directions de maquette au même niveau de finition. J'ai appris en mission que présenter une option soignée et deux esquisses revient à imposer la première. Au même niveau, la discussion porte sur le fond, et la décision se prend en une réunion.
Semaine 2 : construire la structure
Je monte le gabarit, les composants et le modèle de contenu dans l'outil choisi. Je prends des outils que je connais bien : un délai court n'est pas le moment de découvrir un framework. Pour un site en Next.js, la documentation de Next.js rappelle qu'il se déploie chez tout hébergeur qui accepte Node.js, ou par des adaptateurs vérifiés comme Vercel ; je mets en ligne une adresse de test dès le premier jour, pour que chacun voie le site avancer.
Si le parcours principal pose question, je le teste avec un prototype cliquable avant de le coder. Le Nielsen Norman Group recommande de tester avec 5 utilisateurs au plus et de multiplier les petits tests, en ajoutant des utilisateurs si le site a plusieurs publics très différents. Une demi-journée suffit souvent à trouver ce qui bloque.
Semaine 3 : remplir et brancher
Les contenus entrent dans le site, les formulaires sont reliés, la mesure d'audience est posée. Sur ce point, je vérifie la configuration avec la CNIL : certains outils de mesure d'audience peuvent être exemptés de consentement sous conditions, et d'autres non. Mieux vaut le savoir avant de dessiner le bandeau.
Quand la spécification bouge encore à chaque échange, je la versionne. Sur une intégration entre un ERP et un site marchand, c'est ce qui a permis que tout le monde parle du même document.
Semaine 4 : recetter et mettre en ligne
La dernière semaine sert à la recette, pas à ajouter des pages. Je teste chaque formulaire, chaque lien, chaque page sur mobile, et je mesure la vitesse. Google donne des seuils précis pour les Core Web Vitals : un affichage du contenu principal sous 2,5 secondes, une réponse aux interactions en 200 millisecondes ou moins, une mise en page qui ne saute pas au-delà de 0,1. Ma checklist de recette et de mise en production liste le reste.
Je vérifie enfin le site comme un visiteur, déconnecté, dans une fenêtre privée. J'ai vu un site paraître normal à l'équipe connectée et rester cassé pour le public à cause du cache.
04Les décisions qui font perdre des semaines
Avec le recul, les semaines perdues viennent presque toujours des mêmes endroits.
- Un texte qui « arrive la semaine prochaine » trois semaines de suite. Je fixe un responsable et une date par page dès le cadrage.
- Une maquette validée, puis rouverte par quelqu'un qui n'était pas là. La liste des personnes qui valident se décide le premier jour.
- Une fonction « simple » ajoutée en semaine trois. Elle va dans la liste de la version suivante, avec une date.
- Un outil choisi parce qu'il est à la mode. Je reste sur ce que je sais livrer, et je le dis quand un autre choix serait meilleur.
Mes débuts en production audiovisuelle m'ont appris à tenir un budget, un planning et une équipe avec une date qui ne bouge pas. La méthode est la même ici : la date est fixe, c'est le contenu du lot qui s'ajuste.
Une limite honnête : ce découpage ne marche pas quand personne ne peut décider vite, ou quand le site doit porter des fonctions métier. Dans ce cas, je préfère annoncer huit ou douze semaines plutôt que tenir quatre semaines en livrant un site à moitié vide.
05Après la mise en ligne, Google a son propre calendrier
Votre site est en ligne, mais il n'apparaît pas encore dans Google. C'est normal. La documentation de Google Search Central indique que l'exploration peut prendre de quelques jours à quelques semaines, et que la demander ne garantit pas l'inclusion dans les résultats. Elle conseille un sitemap pour un grand nombre d'URL, surtout juste après le lancement d'un site, et l'outil d'inspection d'URL pour quelques pages.
Dans une vidéo de la chaîne Google Search Central, John Mueller explique qu'une nouvelle page peut mettre jusqu'à plusieurs semaines à être indexée, et qu'à son avis la plupart des bons contenus le sont en une semaine environ. Il cite ce qui aide : un serveur qui répond vite, des liens bien visibles vers les nouvelles pages, et pas de milliers d'URL inutiles créées par des filtres ou des tris.
Concrètement, le jour du lancement, je déclare le site et son sitemap dans Search Console, je vérifie que les pages importantes sont liées depuis l'accueil, puis je regarde le rapport d'indexation la semaine suivante. Si le blog doit grossir ensuite, j'automatise la publication avant de produire plus, pour que la mise en ligne ne devienne pas le nouveau goulot.
06Par où commencer lundi
Si votre date est fixée, prenez une heure lundi pour écrire trois listes : les pages indispensables le jour du lancement, les contenus avec un nom et une date pour chacun, et tout ce qui attendra la version suivante. Si la première liste ne tient pas en une page, le délai ne tiendra pas non plus.
Ensuite, nommez la personne qui décide et bloquez-lui une heure par jour pendant quatre semaines. Le reste est de la construction, et c'est la partie la plus prévisible.
Si vous partez d'un site existant, mon article sur la migration d'un site vers Next.js et Sanity détaille ce qui change. Mes services et quelques exemples de missions montrent comment je travaille. Si votre calendrier vous inquiète, on peut en parler.