Conception d’un site web — l’ordre dans lequel changer d’avis est encore gratuit

Les étapes d’un projet ressemblent à une façon d’ordonner le travail : d’abord ceci, ensuite cela. Elles ordonnent autre chose : le prix d’un changement d’avis. La même décision prise au moment du brief est une phrase dans un document ; au moment du wireframe, c’est un rectangle déplacé ; sur un site terminé, c’est une refonte que quelqu’un vous facture.

Cette rubrique n’est donc pas un guide à lire du début à la fin. C’est un aiguillage : quatre textes, un par tronçon du projet où les gens se bloquent réellement.

Ce que cette rubrique tranche

Deux choses, et toutes deux n’apparaissent qu’après coup.

Le moment où chaque décision est encore bon marché. L’ordre des étapes n’est pas une convention du métier : il découle du fait que chaque étape fige les décisions de la précédente. La structure d’un site est bon marché tant qu’elle est une liste, moyennement coûteuse tant qu’elle est un croquis, et chère une fois qu’elle est du code branché sur un système de gestion de contenu. Tout le processus de création d’un site tient en une phrase : plus la question est posée tôt, moins la réponse coûte.

Ce qui bloque réellement les projets. Ni la technologie, ni le périmètre. Les projets s’arrêtent parce que les photos ne sont jamais arrivées, parce qu’une validation circule entre trois personnes, ou parce que personne ne sait qui détient le mot de passe du panneau de gestion du domaine. Aucun de ces points n’est une étape — ils se situent tous entre les étapes, et c’est précisément pour cela qu’aucun planning ne les montre.

Ce que cette rubrique ne fait pas : elle ne promet pas qu’un processus raccourcit un projet. Il raccourcit la liste des choses à faire deux fois, ce qui n’est pas la même affirmation.

Pourquoi cet ordre et pas un autre

La planification d’un site ressemble à une convention figée, alors il vaut la peine de montrer qu’elle ne l’est pas. Chaque étape répond à une question qui ne peut être tranchée tant que la précédente n’a pas de réponse.

Le brief avant le wireframe, parce que la mise en page est la réponse à « que doit-il se passer ici ». Sans objectif, toutes les mises en page se valent, et la conversation se transforme en conversation sur les goûts — or les goûts ne se tranchent pas.

Le wireframe avant le design, parce qu’une hiérarchie se discute plus facilement sur des rectangles gris que sur une image finie. Mettez un visuel complet devant des gens et l’attention se déplace vers la couleur et la photo, tandis que la question « cette section doit-elle exister » cesse d’être posée.

Le design avant le développement, parce que faire passer une décision visuelle dans le code n’est bon marché qu’une seule fois. La deuxième, c’est du travail dans le composant, dans les styles et dans les tests en même temps.

Deux inversions reviennent régulièrement et coûtent la même chose — un tour de reprise :

Commencer par le visuel. « Nous avons déjà la maquette, il ne reste qu’à développer » signifie généralement que la mise en page a été faite sans objectif et sans contenu. Soit le contenu se plie à des cases vides, soit la maquette repart en correction — le plus souvent les deux.

Commencer par la technologie. Choisir un système avant d’avoir établi qui modifie le contenu et à quelle fréquence, c’est trancher à l’aveugle. Cette décision relève de l’architecture et possède sa propre rubrique, mais son moment est bien une question de processus : après le brief, pas avant.

L’ordre peut être resserré. Il ne peut pas être inversé sans le payer deux fois.

Où vous en êtes dans ce processus

Quatre entrées. Reconnaissez votre situation et laissez le reste. Les textes se recouvrent volontairement en un point : celui qui couvre tout le chemin résume ce que les trois autres développent, donc si vous n’en lisez qu’un, lisez celui-là.

Vous ne savez pas quoi écrire pour qu’on puisse vous faire un devis. C’est le moment où changer d’avis ne coûte rien, et le seul de tout le projet. Six informations sans lesquelles l’agence devine, chacune avec la conséquence de son omission — y compris ce qu’il faut faire quand vous n’avez honnêtement pas la réponse : le brief du site web.

Vous avez un périmètre validé mais pas de mise en page. C’est ici que se décide la hiérarchie : ce qu’on voit en premier, ce qu’on peut sauter, où l’écran s’arrête. Sur un croquis, une modification prend un quart d’heure ; sur un site en ligne, le même geste touche un composant, des champs, des styles et des tests. Cet écart, c’est toute la différence entre ces deux étapes : wireframe et mise en page.

Vous voulez voir tout le chemin avant de vous engager. Quatre décisions prises avant que quiconque dessine un écran, ce qui doit réellement figurer sur le site, combien de temps cela prend et ce qui consomme ce temps — jusqu’au jour de la mise en ligne, propagation DNS comprise. Avec notre propre mesure du temps de chargement de deux de nos pages, plutôt que les statistiques de quelqu’un d’autre : comment créer un site internet, étape par étape.

Vous envisagez de le faire vous-même. Parfois une bonne décision, parfois une erreur coûteuse, et la limite entre les deux est mesurable. De quoi un site est fait, ce qui se fait sans système de gestion de contenu, et les trois seuils au-delà desquels l’entretenir soi-même cesse d’être rentable : les bases du HTML et la structure d’une page.

Trois choses qui bloquent un projet — aucune n’est technique

Elles méritent d’être nommées ici parce qu’elles traversent tout le processus plutôt qu’une seule étape, et parce que toutes trois se situent du côté du client. Ce n’est pas un reproche : c’est l’information qu’elles peuvent être levées à l’avance.

Des contenus qui ne sont jamais arrivés. Le projet atteint un état où tout est prêt et attend des photos ou des textes. Le retard le plus fréquent de tout le processus, et le seul qu’une phrase dans le brief supprime : qui fournit quoi, et qu’achetez-vous.

Une validation qui circule. Trois personnes de votre côté, deux en congé, et chaque tour de commentaires coûte une semaine. Le remède est organisationnel, pas créatif : un seul interlocuteur et une seule personne ayant le dernier mot, convenus avant le début du projet.

Des accès que personne n’a. Le panneau du domaine, le compte du système de vente, la clé d’un outil configuré il y a trois ans. Une mise en ligne peut se bloquer là, dans sa dernière semaine, alors que tout le reste est terminé.

La façon dont ces trois blocages se répartissent dans le temps, et pourquoi l’écart de durée vient d’eux et non du périmètre technique, est détaillée dans le texte qui couvre tout le chemin.

Ce que cette rubrique ne couvre pas

Quatre questions reviennent dans les conversations sur le processus et se tranchent ailleurs ; les liens ci-dessous y mènent directement.

Ce que cela coûte. Le processus n’est pas une ligne de devis ; un devis a sa propre structure, ses modèles de facturation et ses pièges. Le détail complet est dans la rubrique consacrée aux coûts.

À quoi cela doit ressembler. La couche visuelle, l’accessibilité, le design d’interface et les tests utilisateurs ont leur propre rubrique. Ici, c’est l’ordre du travail ; là, ce sont les décisions de conception.

D’où viennent les textes et les images. Les contenus, les visuels et la question de savoir qui les prépare relèvent de la rubrique contenus et médias — pour la même raison que « les contenus » figurent plus haut comme blocage et non comme étape.

Sur quoi le construire. Le choix du système, de la plateforme et de l’hébergement relève de l’architecture, pas du processus, et possède une rubrique à part. Ce qui se passe après la mise en ligne — mises à jour, sauvegardes, surveillance — en possède une autre.

Commencez par un outil, pas par la lecture

Trois choses de cette rubrique sont à votre disposition avant que vous ayez lu l’un des quatre textes — et c’est généralement le meilleur ordre, parce qu’elles vous montrent ce que vous ne savez pas encore.

Le générateur de brief parcourt les mêmes questions une par une, enregistre votre progression et vous laisse un document terminé — à nous envoyer ou à envoyer à n’importe quelle autre agence : remplir le brief en ligne. Sans compte et sans frais.

La checklist d’avant mise en ligne énumère ce qui se vérifie la dernière semaine et s’oublie le plus facilement, parce que chaque point pris isolément ressemble à un détail : ce qu’il faut vérifier avant de lancer.

La checklist de choix d’une agence sert plus tôt — quand vous avez trois propositions et que vous ne voyez pas ce qui les sépare au-delà du montant : comment choisir une agence web.

Aucune des trois ne remplace une conversation avec une agence, et aucune ne prétend le faire. Elles font quelque chose de plus étroit et de plus pratique : elles transforment « je ne sais pas quoi demander » en une liste de manques précis que vous pouvez apporter en réunion.