Le processus de développement web expliqué
Toutes les méthodologies de développement web organisent les mêmes phases différemment. Comprendre les phases elles-mêmes — ce que chacune produit et ce qui la clôt — est plus utile que le nom de la méthodologie, car cela vous dit si le projet est là où il devrait être.
Ce guide couvre les sept phases, des durées typiques pour un site de taille moyenne, et à quoi ressemble une vraie validation à chacune.
Les sept phases#
Les durées supposent un site sur mesure de taille moyenne avec une petite équipe. Elles s'allongent bien plus avec le volume de contenu et les intégrations qu'avec le nombre de pages.
| Phase | Produit | Durée typique |
|---|---|---|
| 1. Cadrage | Objectifs, public, périmètre, contraintes | 1–2 semaines |
| 2. Structure | Structure des pages, modèle de contenu, wireframes | 1–2 semaines |
| 3. Design | Gabarits, système de composants, règles adaptatives | 2–4 semaines |
| 4. Réalisation | Gabarits fonctionnels, CMS, intégrations | 4–10 semaines |
| 5. Contenu | Textes, images et données réels dans le système | En parallèle ; souvent la plus longue |
| 6. Tests | Fonctionnels, multi-navigateurs, performance, accessibilité | 1–2 semaines |
| 7. Mise en ligne | Site en ligne, redirections, supervision, passation | 2–5 jours |
La phase 5 est celle qui déborde. Elle est dessinée en parallèle parce qu'elle devrait commencer en phase 2, pas parce qu'elle est petite.
Ce qui clôt chaque phase#
Une phase ne se termine pas parce que le temps a passé. Elle se termine quand quelque chose de précis a été convenu, par écrit, par une personne ayant autorité. Sans cela, le travail continue sur des fondations qui peuvent encore bouger.
- Cadrage : un périmètre signé avec une liste explicite d'exclusions.
- Structure : une structure de pages et un modèle de contenu validés, avec des noms de champs que votre équipe comprend.
- Design : des gabarits validés pour chaque mise en page distincte, mobile et états vides compris.
- Réalisation : chaque gabarit démontré en préproduction avec du contenu réaliste.
- Contenu : chaque page critique remplie et relue par une personne nommée.
- Tests : une liste d'anomalies convenue et répartie entre bloquantes et correctifs post-lancement.
- Mise en ligne : une checklist de pré-lancement complétée et la passation des accès confirmée.
Cycle en V, agile, ou entre les deux#
La vraie différence, c'est le moment où le périmètre est figé. Les projets à périmètre fixe se chiffrent précisément et supportent mal le changement ; les projets itératifs supportent bien le changement et ne peuvent pas promettre un total fixe. L'essentiel du travail web se situe entre les deux : périmètre fixe jusqu'au lancement, itératif ensuite.
| Périmètre fixe | Itératif | |
|---|---|---|
| Prix | Connu d'avance | Tarif par sprint ou par mois |
| Changement | Demande formelle, rechiffrée | Absorbé en repriorisant le backlog |
| Convient à | Exigences claires et stables | Produits qui évoluent et exigences floues |
| Votre risque | Payer pour quelque chose qui ne convient plus | Un coût qui dérive sans butoir |
| Demande de vous | Des décisions en amont | Une disponibilité continue pour prioriser |
Méfiez-vous du prix ferme avec un périmètre flou. C'est la pire combinaison : le prestataire protège sa marge en interprétant l'ambiguïté de façon restrictive, et chaque clarification devient une négociation.
Où le processus déraille habituellement#
Les mêmes quatre échecs expliquent l'essentiel des dépassements, et aucun n'est technique.
- Design validé sur du contenu de remplissage. Le vrai texte arrive deux fois plus long et la mise en page est refaite.
- Intégrations découvertes tard. « Il faut aussi que ça parle à notre système de stock » en semaine huit est un nouveau projet, pas un changement.
- Aucun décideur unique. Les retours viennent de cinq personnes, deux se contredisent, et personne n'a l'autorité de trancher.
- Les tests traités comme une phase et non comme une habitude. Les anomalies trouvées en semaine dix mais introduites en semaine trois coûtent plusieurs fois plus cher.
Questions fréquentes
Combien de temps prend un site web typique ?
Un petit site à base de gabarits, deux à quatre semaines. Un site sur mesure de taille moyenne, généralement trois à cinq mois de bout en bout. Les boutiques et les applications prennent plus longtemps. La variable qui déplace le plus ces chiffres n'est pas la complexité du code mais la disponibilité du contenu et la vitesse de décision côté client.
Les phases peuvent-elles se chevaucher ?
Certaines devraient. Le contenu devrait démarrer pendant la structure, et les tests devraient accompagner toute la réalisation plutôt que d'arriver seulement à la fin. Ce qui ne devrait pas se chevaucher, c'est le design et la réalisation du même gabarit : construire contre un design qui bouge encore garantit du travail refait, et c'est la source la plus courante des disputes du type « on l'avait déjà construit ».
Et si nous devons changer quelque chose en cours de projet ?
Attendez-vous-y et convenez du mécanisme d'avance : qui peut demander un changement, qui le chiffre, et s'il décale la date de lancement. Les petits changements absorbés en silence sont la façon dont un projet dérive d'un mois sans que personne puisse dire quand. Un journal des changements écrit règle l'essentiel.
Dois-je payer par phase ?
Des paiements par jalons adossés à des livrables inspectables sont la structure la plus équitable pour les deux parties : typiquement un acompte, puis des paiements à la validation du design, à la fin de la réalisation et au lancement. Évitez de payer entièrement d'avance, et évitez de payer entièrement à la fin, ce qui reporte tout le risque de trésorerie sur le prestataire et vous coûte généralement plus cher.
processus développement webphases développement webétapes projet webdéveloppement web agileplanning projet webméthodologie développement web
