Un planning de refonte de site web réaliste tient sur une page : des semaines numérotées, un livrable à chaque étape, et une date de mise en ligne que vous connaissez avant même le premier écran de maquette. Pour un site de PME de quelques dizaines de pages, ce planning se lit en trois mois. Après dix ans à piloter des projets web, refontes de site web comprises, je vous le dis franchement : ce n'est pas le développement qui fixe la date de mise en ligne. C'est l'état de votre site actuel, et le temps que prennent vos validations. Le code, lui, avance vite une fois les décisions prises. Voilà pourquoi je commence toujours par regarder ce qui existe déjà, avant de parler de ce qui va se construire.
Pourquoi le planning d'une refonte part du site actuel
Une création de site part d'une page blanche. Une refonte, non : elle hérite d'adresses déjà indexées, de pages qui amènent du trafic tous les jours, de contenus qu'il faut reprendre ou réécrire. Ignorer ce passif, c'est le meilleur moyen de perdre à la bascule ce que le site a mis des années à construire.
Concrètement, ça change l'ordre des tâches. Chez moi, l'audit et l'inventaire des URL démarrent en semaine 1, avant même que la designer touche à une maquette. Et la table de correspondance entre ancienne et nouvelle adresse avance pendant la conception des maquettes, des semaines avant la mise en ligne. Donc quand j'arrive à la recette, les redirections 301 sont déjà écrites : il ne reste plus qu'à les tester.
C'est là que la plupart des plannings que je lis se cassent la figure. Ils posent les redirections en tout dernier, ou pire, ils ne les posent nulle part dans le déroulé. Résultat : le trafic se perd au moment de la bascule, et personne ne l'avait vu venir. Ad Majoris comptait plus de 1000 pages au moment de sa migration WooCommerce ; un volume pareil se mesure en semaine 1, sinon il fait exploser le planning en fin de course.
Le planning type d'une refonte de site web sur 3 mois
Voici un exemple pour un site vitrine ou institutionnel de quelques dizaines de pages, avec une designer, un CMS classique, et des contenus repris en partie. À ajuster selon votre cas, mais utile pour visualiser l'ordre des choses.
| Semaines | Phase | Ce que je fais | Ce que fait la designer | Ce que vous faites |
|---|---|---|---|---|
| 1 à 2 | Audit et inventaire des URL | Audit technique, liste des adresses | - | Accès au site, aux statistiques |
| 3 | Cadrage et arborescence | Cadrage, plan du site | Arborescence avec moi | Objectifs, arbitrages |
| 4 à 6 | Maquettes et contenus | Table de correspondance des URL | Maquettes des pages clés | Rédaction des contenus neufs |
| 7 à 10 | Développement | Développement en préproduction | Retours sur les écrans | Validation des contenus repris |
| 11 | Recette | Test des pages et des redirections | Vérification visuelle | Recette et retours |
| 12 | Mise en ligne | Checklist de mise en production | - | Disponibilité le jour J |
| 13 | Suivi | Suivi Search Console, corrections | - | Retours des équipes |
Chaque ligne se termine par un jalon que vous validez avant que je passe à la suivante. La règle tient en une phrase : une maquette, un texte ou une question envoyés d'un côté reçoivent leur réponse sous 48 heures. Ça évite les silences qui s'installent sans que personne ne s'en rende compte.
Ce calendrier reste un exemple. Il s'allonge quand votre site actuel compte beaucoup plus d'adresses que prévu, ou quand les contenus sont entièrement à écrire plutôt qu'à reprendre. Et dans mes devis, chaque phase de ce planning correspond à un lot facturé à part : vous savez ce que coûte chaque étape.
Qui fait quoi pendant la refonte
Ce que je tiens
Le cadrage part de moi. Je rédige le document qui fixe le périmètre, je le négocie avec vous, et c'est sur cette base que je pose le rétroplanning daté ; sur un projet à plusieurs décideurs, ce document devient un cahier des charges à part entière. Je tiens aussi la partie technique : développement, recette, mise en production, et la relation avec votre hébergeur si besoin. Vous avez une seule personne à relancer côté prestataire, qui connaît chaque ligne du planning et qui répond, quelle que soit la question.
Ce que tient la designer
Le design et l'arborescence du site se construisent avec elle, en lien direct avec moi. Elle livre les maquettes selon le calendrier fixé au cadrage, elle intègre vos retours de validation, et elle reste jusqu'au bout sur les écrans qui posent question.
Ce que vous tenez
Trois choses, et elles pèsent lourd sur la date de mise en ligne. D'abord les accès : hébergeur, CMS, Search Console, sans eux rien ne démarre vraiment. Ensuite les contenus, textes et images, à fournir aux dates convenues. Enfin les validations : chaque maquette, chaque texte, chaque arbitrage attend votre réponse. Je vous demande une chose : une seule personne chez vous qui tranche. Sans ça, un même sujet se rediscute d'une réunion à l'autre et le planning en paie le prix.
Ce qui fait glisser un planning de refonte
Dans l'ordre où ça coûte réellement du temps. D'abord les contenus qui arrivent en retard : une page sans texte ne peut pas être recettée, donc tout ce qui suit attend. Un retard apparaît tout de suite dans la colonne « bloqué, en attente client » de mon outil de pilotage ; je le vois, vous le voyez, personne ne le découvre à la réunion suivante.
Ensuite une validation qui reste en suspens. Un compte rendu part sous 48 heures après chaque point, avec ce qui est attendu et pour quand ; une maquette ne dort donc pas dans une boîte mail.
Puis un site actuel qui compte plus d'adresses que prévu. Skinobs comptait plus de 5000 articles WordPress à migrer ; un tel stock, découvert tard, tombe au pire moment, juste avant la bascule.
Enfin un arbitrage qui change le périmètre en cours de route : une page en plus, une fonctionnalité ajoutée après coup. Je le chiffre en délai avant de l'accepter. Et si le délai demandé au départ n'est tout simplement pas tenable, je vous le dis avant que vous signiez : mieux vaut une date juste qu'une date qui casse en semaine 10.
Avant la semaine 1, et après la mise en ligne
La semaine 0 ne figure dans aucun des plannings que j'ai lus en ligne, et pourtant elle conditionne tout le reste. J'ouvre les accès, je vérifie que Search Console est bien en place, je relève ce qui amène du trafic aujourd'hui, et je fais une sauvegarde complète du site actuel. Rien de tout ça ne se traite après coup.
Le jour de la mise en ligne, je passe une checklist fixe : sauvegarde, redirections 301, SSL, robots.txt, sitemap envoyé dans Search Console. Puis je contrôle le lendemain que tout tient. Vient ensuite une semaine de suivi, où je corrige ce que Search Console remonte comme erreurs.
Un planning qui s'arrête le jour de la mise en ligne laisse au client la période la plus risquée sans personne pour la tenir. Le mien continue après.
Caler ce planning sur votre propre site
Trois questions suffisent pour savoir si trois mois vous conviennent ou pas. Combien d'adresses votre site actuel compte réellement dans Search Console. Qui écrit les contenus neufs chez vous, et pour quelle date réaliste. Qui valide de votre côté, et en combien de jours cette personne répond vraiment.
Envoyez-moi l'adresse de votre site actuel. Je regarde ce qu'il contient, et on pose ensemble un planning daté à partir de votre propre site.