Aller au contenu

Pourquoi je ne sépare plus design et développement.

Note de studio. Sur les projets que je mène, la maquette et le code ne se succèdent pas : ils se répondent. Voici pourquoi, et ce que ça change concrètement.

Publié le
Format
Processus
Lecture
04 min
Référence
FSJ-S01
Photo du poste de travail du studio : écran avec du code, carnet de croquis ouvert à côté

Le découpage classique et sa limite

Le modèle habituel est simple : on dessine, on valide, on intègre. Il a une vertu — chaque étape est claire — et un présupposé : que tout peut être décidé sur une image fixe.

Or une part importante de l’expérience est temporelle. Ce qui arrive, dans quel ordre, à quelle vitesse, comment ça répond au doigt ou à la souris, ce qui se passe pendant le chargement, ce qui se passe quand le texte est deux fois plus long que prévu. Rien de tout cela ne se voit sur une maquette.

Le prototype vivant

Travailler tôt dans le navigateur, même sur une version grossière, permet de juger ce qui ne se voit pas ailleurs : la fluidité réelle, la densité des textes une fois écrits, le comportement sur un petit écran, la tenue d’une animation sur un appareil modeste, la lisibilité en plein soleil.

Cela ne supprime pas la phase de dessin : on croque toujours, on compose toujours. Mais la maquette devient une intention à vérifier plutôt qu’un contrat à exécuter — et la vérification arrive assez tôt pour que corriger ne coûte rien.

Ce que le code apporte au design

Le code impose ses contraintes, et les contraintes sont une matière de création. Elles écartent les intentions qui ne tiennent pas et renforcent celles qui tiennent. Elles ouvrent aussi des possibilités qu’aucune maquette ne suggère : un mouvement qui réagit au défilement, une composition qui s’adapte au contenu réel, une transition qui relie deux pages.

C’est enfin ce qui permet de montrer un projet dans son état réel, plutôt que dans sa version idéalisée. Le client ne découvre pas à la livraison que « ça ne rend pas tout à fait comme sur l’image ».

Ce que le client voit pendant le projet est déjà ce qu’il aura à la fin.

Ce que ça change pour un projet

  1. 01Moins d’écartCe qui est présenté est ce qui sera livré, sur vos contenus et vos appareils.
  2. 02Décisions plus tôtLes problèmes de densité, de longueur de texte et de performance apparaissent pendant la conception.
  3. 03Moins d’allers-retoursOn discute d’un objet qui fonctionne, pas d’une image à interpréter.
  4. 04Un site cohérentLe mouvement, la structure et le graphisme sont décidés ensemble, par la même personne.

Comment ça se passe concrètement

Le projet commence toujours par du cadrage et du dessin : structure, intentions, références, croquis. Puis, très vite — souvent dès la première semaine — une version navigable existe, même moche, même incomplète. Elle sert de terrain commun : on y teste la densité des textes, les tailles réelles, les respirations, les enchaînements.

Les maquettes ne disparaissent pas pour autant. Elles servent à explorer vite, à comparer des directions, à trancher un parti pris graphique. Simplement, elles ne sont plus le point d’arrivée : le point d’arrivée est le site lui-même, et il existe dès le début.

Ce que ça demande au client

Une seule chose, mais elle n’est pas anodine : accepter de voir un projet inachevé. Une version de travail est toujours plus rugueuse qu’une belle image figée, et il faut une certaine confiance pour juger une intention plutôt qu’une vitrine.

En échange, il n’y a pas de mauvaise surprise à la livraison, et les décisions se prennent sur ce qui existera vraiment — avec vos textes, vos images, sur votre téléphone.

À retenir

L’essentiel en 4 points.

  • 01Le navigateur est un outil de design, pas seulement un outil de production.
  • 02Certaines décisions ne se prennent qu’une fois le projet en mouvement.
  • 03Les contraintes techniques sont une matière de création, pas un obstacle.
  • 04Cette pratique réduit l’écart entre ce qui est présenté et ce qui est livré.
Tout le Journal →