Les projets web dérapent avec une régularité remarquable, et l'explication est presque toujours la même — quoique rarement celle qu'on donne.
Ce n'est pas le développement. Le code est la partie la plus prévisible d'un projet web. Les retards viennent d'ailleurs, et une bonne partie de « l'ailleurs » se trouve du côté du client.
Voici les délais réalistes, les vraies causes de dérapage, et ce que chacun contrôle.
Des délais réalistes
Pour une équipe qui travaille correctement, sur un projet cadré :
Une page d'atterrissage unique : une à deux semaines.
Un site vitrine de cinq à dix pages : quatre à huit semaines.
Un site de services avec architecture de recherche — quinze à trente pages, grappes de contenu, structure SEO planifiée : huit à quatorze semaines.
Une boutique en ligne : six à douze semaines selon le catalogue. Les fiches produits dominent le calendrier, pas la construction.
Un site bilingue : ajoutez trente à cinquante pour cent, pas cent. La structure se construit une fois ; c'est la rédaction qui double. Si quelqu'un vous annonce le même délai en bilingue qu'en unilingue, le français sera une traduction automatique.
Une application sur mesure : hors barème. Tout devis de moins de trois mois pour un logiciel réel mérite des questions.
Ces chiffres supposent que le contenu existe ou que quelqu'un est explicitement chargé de l'écrire. C'est rarement le cas, et c'est la source principale de dépassement.
Les cinq vraies causes de retard
1. Le contenu n'arrive pas
De loin la première. Le projet est lancé, la structure est prête, et tout attend les textes, les photos, les logos, les informations légales.
Le client suppose que l'agence écrira. L'agence suppose que le client fournira. Personne ne l'a écrit dans le devis.
C'est aussi la raison pour laquelle « qui écrit les textes ? » est la question la plus importante à régler avant de signer.
2. Les validations sont dispersées
Chaque cycle de révision ajoute du délai — pas seulement le temps de faire les changements, mais le temps d'attendre la réponse.
Le pire scénario : trois personnes valident séparément, à des moments différents, avec des avis contradictoires. L'équipe fait des allers-retours pendant que les décideurs ne se sont jamais parlé entre eux.
Une personne responsable de la décision finale change complètement un calendrier.
3. La portée grandit sans que la date bouge
« Tant qu'à y être, pourrait-on ajouter… » Chaque ajout est légitime individuellement. Ensemble, ils ajoutent des semaines.
Ce n'est pas un problème si l'échéance bouge en conséquence. Ça devient un problème quand la portée grandit et que la date reste.
4. Les accès manquent
Le domaine, l'hébergement, les analytiques, la plateforme de courriel, le compte publicitaire. Chacun appartient à quelqu'un de différent, et parfois personne ne sait à qui.
Ça bloque typiquement à la fin, au pire moment — au moment de la mise en ligne.
Réglez les accès la première semaine, pas la dernière.
5. Les dépendances externes
Un fournisseur de paiement à configurer, un logiciel de gestion à intégrer, un traducteur, un photographe. Chacun a son propre calendrier, et aucun n'est aligné sur le vôtre.
Ce que le client contrôle réellement
Beaucoup, en fait — plus que la plupart des clients ne le pensent.
Nommer un décideur unique. Une personne qui tranche. Les autres conseillent.
Fournir le contenu avant le début, ou payer pour qu'il soit écrit. Ce sont les deux seules options. « On vous l'enverra en cours de route » est la troisième, et c'est celle qui fait déraper les projets.
Regrouper les commentaires. Un document de retours consolidé par étape, pas quinze courriels sur trois jours.
Régler les accès la première semaine.
Décider tôt si la date ou la portée est fixe. Les deux ne peuvent pas l'être.
Ce que le fournisseur devrait garantir
Un échéancier avec les dépendances explicites. « Livraison le 15 » ne vaut rien. « Livraison le 15 si le contenu est reçu le 3 » est un engagement réel.
Des points de contrôle, pas une grande révélation à la fin. Un projet où vous ne voyez rien pendant six semaines est un projet à risque.
Un avertissement dès qu'un retard devient probable, pas la veille de l'échéance.
Une portée écrite — nombre de pages, cycles de révision inclus, ce qui est hors portée.
Le déroulement type
Semaine 1 — Cadrage. Objectifs, audience, arborescence, intentions de recherche par page, accès. Cette semaine détermine le reste ; la sauter coûte plus cher que de la faire.
Semaines 2-3 — Contenu et structure. Rédaction, ou collecte. C'est ici que la plupart des projets prennent leur retard.
Semaines 3-5 — Design. Les gabarits clés, pas chaque page.
Semaines 5-8 — Construction. La partie la plus prévisible.
Semaine avant la mise en ligne — Vérifications. Redirections, métadonnées, formulaires testés depuis l'extérieur, courriels transactionnels, hreflang si bilingue, analytiques.
Mise en ligne, puis deux semaines de surveillance. Erreurs 404, indexation, formulaires. Le lancement n'est pas la fin.
Le point le plus souvent sauté est l'avant-dernier. Un site mis en ligne sans vérifier que les formulaires arrivent et que les anciennes URL redirigent produit des dégâts silencieux — le sujet est traité dans le plan de redirections et dans l'article sur la délivrabilité.
Les signaux d'un projet qui va mal
- Trois semaines sans rien voir.
- Une portée jamais écrite.
- Des retours donnés verbalement, jamais consignés.
- Un « on verra ça plus tard » sur le contenu.
- Une date de lancement fixée par un événement externe sans marge.
- Personne ne sait qui possède le domaine.
Chacun se corrige facilement s'il est nommé tôt.
Ce qu'il faut retenir
Un site web ne dérape presque jamais pour des raisons techniques. Il dérape parce que le contenu n'existe pas, que trop de gens valident, ou que la portée grandit pendant que la date reste.
Ces trois choses sont majoritairement sous le contrôle du client. Le meilleur investissement avant de démarrer n'est pas de choisir un fournisseur — c'est de décider qui tranche, et d'avoir le contenu prêt.
Si vous préférez que ce soit fait plutôt qu'expliqué, voyez nos tarifs affichés.