Comment planifier un site web : le guide complet
La plupart des projets de développement web ne prennent pas de retard parce que le code était difficile. Ils prennent du retard parce que le plan était mince : personne n'avait convenu de ce que le site devait accomplir, de qui écrirait les textes, ni de ce que « terminé » voulait dire.
Ce guide couvre le travail de planification qui précède la conception et la réalisation, dans l'ordre où il est réellement utile, et les décisions coûteuses à changer plus tard.
Commencez par une tâche que le site doit accomplir#
Un site qui doit tout faire n'accomplit généralement rien de mesurable. Avant toute chose, notez l'action unique qui compte le plus : un formulaire envoyé, un appel, un achat, une réservation, un téléchargement.
Tout le reste — structure des pages, navigation, ce qui figure en haut de page, combien dépenser — découle de cette réponse. Un site dont la mission principale est de générer des demandes est un projet différent d'un site dont la mission est de vendre 4 000 produits.
- Objectif principal : l'action unique que vous garderiez si vous ne pouviez en garder qu'une.
- Objectifs secondaires : utiles, mais pas au point de sacrifier le principal.
- Comment vous le mesurerez : un chiffre vérifiable au prochain trimestre, pas « plus de trafic ».
- Ce que le site n'a pas à faire : écrit noir sur blanc, pour rester hors périmètre.
Si deux personnes de votre organisation citeraient des objectifs principaux différents, ce désaccord ressurgira en semaine six de la réalisation. Réglez-le en semaine zéro, quand il coûte une réunion et non une reconstruction.
Sachez qui arrive et pourquoi#
L'étude d'audience n'a pas besoin d'être un exercice formel. Ce qu'il vous faut, c'est une description courte et honnête des deux ou trois groupes qui visitent réellement, la question avec laquelle chacun arrive et ce qui les ferait partir.
| Visiteur | Arrive en se demandant | Repart parce que |
|---|---|---|
| Premier acheteur | Ces gens savent-ils faire ce dont j'ai besoin ? | Aucune preuve, aucun prix, aucune clarté |
| Client fidèle | Où est ce dont j'ai besoin maintenant ? | La tâche est enfouie à trois clics |
| Quelqu'un qui compare | En quoi est-ce différent des autres ? | Des textes génériques qui pourraient être ceux de n'importe quel concurrent |
| Un candidat | Comment est-ce de travailler ici ? | Pas de page carrières, ou une page obsolète |
Décidez les pages avant le design#
La structure des pages est ce qu'il y a de moins cher à changer sur le papier et parmi les plus chers à changer une fois un design validé. Listez chaque page, regroupez-les en sections et marquez celles qui sont indispensables au lancement et celles qui peuvent attendre.
L'échec classique est une structure qui reflète votre organigramme plutôt que la tâche du visiteur. Personne n'arrive en cherchant votre « division Solutions » ; les gens arrivent en cherchant ce dont ils ont besoin.
- Listez chaque page que vous pensez nécessaire, une par ligne, sans regrouper.
- Marquez chacune comme critique pour le lancement ou ultérieure. Soyez strict : la plupart des sites se lancent avec moins de pages que prévu.
- Regroupez les pages critiques en cinq ou six sections de premier niveau au maximum.
- Écrivez la phrase unique que chaque page doit transmettre. Si vous n'y arrivez pas, cette page ne devrait probablement pas exister.
- Vérifiez que l'objectif principal est atteignable en un clic depuis chaque page de premier niveau.
Le contenu est le chemin critique : planifiez-le en premier#
Les textes, les photographies et les données produits retardent plus de lancements que n'importe quel problème technique. La réalisation se termine et le site attend six semaines en préproduction une page « À propos ».
Décidez maintenant qui écrit chaque page, qui la valide et pour quand, et traitez ces dates aussi sérieusement que les jalons de développement. Si personne n'a le temps en interne, budgétez un rédacteur : c'est moins cher qu'une équipe de développement à l'arrêt.
- Nommez un responsable et une date pour chaque page de texte, pas « le marketing ».
- Décidez du sort du contenu existant : migrer, réécrire ou supprimer. L'essentiel devrait être supprimé.
- Réservez la photographie tôt : c'est le délai le plus long de toute la liste.
- Pour une boutique, exportez et nettoyez les données produits avant le début, pas pendant.
- Convenez de qui donne la validation finale. Deux valideurs de même autorité, c'est un risque de calendrier.
Un test utile : si le site était terminé demain, pourriez-vous le remplir ? Si la réponse est non, le contenu est votre vraie échéance.
Fixez une fourchette de budget et tranchez l'approche de réalisation#
La planification se termine par deux chiffres et un choix : ce que vous pouvez dépenser, quand vous en avez besoin en ligne, et s'il s'agit d'un gabarit, d'un CMS ou d'un développement sur mesure. Ces trois points décident à qui vous devriez même parler.
| Approche | Convient quand | Risque principal |
|---|---|---|
| Créateur de site | Petit site vitrine, aucune exigence inhabituelle | Vous butez sur un plafond et devez tout recommencer |
| CMS (ex. WordPress) | Site éditorial, mises à jour fréquentes par des non-développeurs | Prolifération d'extensions et maintenance continue |
| Plateforme e-commerce | Vente de produits, besoins de paiement standards | Frais de plateforme et personnalisation limitée |
| Développement sur mesure | Le site est le produit, ou les intégrations excluent le reste | Coût le plus élevé, et la maintenance vous appartient |
Questions fréquentes
Combien de temps devrait durer la planification ?
Pour un site de petite entreprise, une à deux semaines de travail réel, pas de temps écoulé. Pour une boutique ou une application, trois à six semaines, consacrées surtout à l'inventaire du contenu et aux données produits plutôt qu'à des documents. Si la planification s'étire sur des mois, c'est en général que l'objectif principal n'est pas tranché et que la discussion tourne en rond.
Ai-je besoin d'un cahier des charges formel ?
Il vous faut un écrit que les deux parties peuvent invoquer, mais il n'a pas besoin d'être long. Une structure de pages, une liste de fonctionnalités dans le périmètre, une liste de ce qui en est explicitement exclu et un responsable de contenu par page éviteront plus de litiges qu'une spécification de cinquante pages que personne ne lit. La liste des exclusions est la partie que l'on saute et celle qui sauve le projet.
Dois-je planifier le design à ce stade ?
Planifiez la structure, pas l'apparence. Décider quelles pages existent et ce que chacune doit accomplir, c'est de la planification ; choisir des couleurs et des typographies, c'est du design, et le faire avant que la structure existe signifie que le design sera remanié dès l'arrivée du vrai contenu. Les wireframes sont l'entre-deux utile.
Et si les exigences changent en cours de projet ?
Elles changeront. Ce qui compte, c'est d'avoir convenu à l'avance de la façon de traiter les changements : qui peut en demander un, qui le chiffre, et s'il décale la date de lancement. Un projet avec un processus de changement prend du retard de façon maîtrisée ; un projet sans en prend dans une dispute.
planifier un site webplanification site webplan de projet webcahier des charges site webstructure site webplanification développement web
