Dessiner avant de coder : méthode analogique pour penser une application
Dans notre quotidien numérique, tout semble pouvoir être prototypé en ligne, en drag and drop, en quelques clics. Mais chez Pem’s Projects, les meilleures idées sont nées ailleurs. Pas sur écran. Sur des carnets, des feuilles volantes, autour d’un café ou d’un besoin formulé à voix haute. Le sketch n’est pas une étape décorative, c’est un moment de conception. Il permet de matérialiser les questions avant même de penser à une interface.
On pose les bases avec ce qu’on a sous la main : un stylo, une table, une idée à formuler. Rien n’est figé. On rature, on recommence, on juxtapose. On cherche moins à dessiner un écran qu’à comprendre une logique. Le but n’est pas de représenter l’interface, mais de visualiser l’usage.
À qui s’adresse-t-on ? Que doit-il pouvoir faire, et dans quel ordre ? Quels éléments sont essentiels, et lesquels peuvent attendre ?
Avant de cliquer, on cherche à comprendre. Ce que l’on esquisse, c’est un chemin. Une situation concrète. Une articulation entre besoin et réponse. Ce n’est ni un raccourci, ni une perte de temps : c’est souvent ce qui nous évite de coder trop tôt ou dans la mauvaise direction.
Le sketch comme point d’entrée
Avant de coder quoi que ce soit, nous dessinons. Non pas pour illustrer, mais pour comprendre. Un croquis permet d’esquisser une hypothèse d’usage. On trace un parcours, on teste une logique, on visualise une hiérarchie. Ce n’est pas une maquette figée, c’est un outil de dialogue, souvent improvisé, parfois raturé, toujours utile. Le dessin permet de se poser des questions concrètes : que voit l’utilisateur en premier ? Qu’attend-il ? Que doit-il pouvoir faire ?
Nous utilisons des carnets simples, souvent des Zap Book à spirale, dans lesquels toutes les idées, les tâches, les listes ou les premières structures de projet sont notées pêle-mêle. Ce n’est pas organisé au départ. Mais tout y est. Ce désordre apparent devient un support de travail quotidien, consultable à tout moment, sans avoir besoin d’ouvrir un logiciel ou de retrouver un fichier.
La différence avec le digital, c’est le contact. On ne simule pas un trait, on le trace réellement. Il n’y a ni raccourci clavier, ni calque invisible, ni vectorisation automatique. Cela a ses inconvénients, et ils sont nombreux : pas de moteur de recherche, pas de duplication facile, pas de sauvegarde automatique, pas de versionnage, pas de synchronisation entre postes. Mais cela renforce la concentration, la mémoire, la clarté. On prend le temps de formuler, de réfléchir en dessinant, de construire une réponse au lieu d’assembler des composants visuels prédéfinis.
Le sketch analogique est aussi une façon d’exprimer sans contrainte. Pas besoin de savoir dessiner. Il suffit de poser les idées, sous forme de blocs, de flèches, de grilles brutes. Ce langage visuel primaire suffit largement à ouvrir la discussion, à tester un raisonnement, ou à vérifier qu’une idée tienne debout.
Des outils simples, une attention maximale
Nous utilisons des outils de base : crayons HB ou 2B, stylos à pointe fine, feutres Copic ou Promarker pour poser des repères visuels, papier layout ou calque pour ajouter des couches, et table lumineuse pour rejouer une séquence en isolant les variantes. Ces outils sont économiques, durables, et toujours disponibles, sans dépendre d’une mise à jour ou d’une batterie.
Chacun adopte ses préférences. Certains privilégient les crayons pour garder un trait hésitant, d’autres préfèrent l’encre pour figer les choix. Ce n’est pas une méthode unique. Mais tous ces outils ont un point commun : ils offrent une liberté immédiate. Aucun démarrage, aucun réglage, juste un geste et une surface.
Ce qui compte, c’est de disposer d’un support où l’on peut poser une idée sans contrainte, sans distraction. Le sketchbook devient un réceptacle de travail. Un croquis reste, se feuillette, se compare. Il n’a pas besoin d’être joli, il doit seulement permettre de rejouer une idée. Et souvent, on pose tout à plat sur une grande table ou on accroche au mur. On passe devant, on revient, on déplace une feuille. Et l’architecture du projet se construit à vue.
Concevoir sans écran, méthodiquement
On commence par les besoins : un utilisateur, une intention, une tâche à accomplir. Une feuille, un crayon, et on isole une situation concrète. Rien de graphique à ce stade, rien d’esthétique. On pose les blocs, on relie par des flèches, on note les conditions. Il s’agit d’un outil de travail, pas d’un rendu. Chaque feuille correspond à une unité de sens. Cela peut être une étape du parcours, une page logique, une interaction. Si c’est trop chargé, on scinde. Si c’est flou, on juxtapose. Ce qui compte, c’est que les informations circulent, que le regard puisse suivre un fil logique sans se perdre dans la mise en page.
Une fois cette structure posée, on questionne les enchaînements. Que se passe-t-il si l’utilisateur clique ici ? Est-ce qu’il revient en arrière ? Est-ce qu’un message s’affiche ? Et si le champ reste vide ? Et si le système est lent ? Ces scénarios sont dessinés à part. On y consacre une feuille, parfois un calque. Cela permet de garder la base intacte tout en explorant les cas limites.
On dessine les états : vierge, en cours, en erreur, validé. On peut les superposer avec du calque ou simplement aligner les feuilles sur une table. On suit le parcours avec le doigt, on joue les étapes comme on jouerait une scène. Le papier permet de tout poser sans risque, sans distraction, sans pression de production. Rien n’est figé, tout peut évoluer au fil des essais.
Au fil de ces itérations, on peut aussi introduire des repères visuels simples : un trait rouge pour une alerte, un fond gris pour une zone inactive, un encadré fluo pour signaler une action prioritaire. Ces codes couleur ne sont pas figés, mais ils facilitent la lecture rapide d’un ensemble de feuilles éparpillées. Cela reste du papier, mais cela anticipe déjà une hiérarchie visuelle, sans tomber dans le piège de la maquette esthétique.
Penser les parcours comme des scénarios
Plutôt que d’enchaîner des écrans, on imagine des histoires. On suit un utilisateur du début à la fin, comme si on déroulait une séquence vécue. Chaque feuille représente une étape. On les dispose dans l’ordre, au mur ou à plat, et on suit le fil : arrivée sur l’interface, saisie, validation, erreur, reprise, sortie. On peut matérialiser une bifurcation par une nouvelle colonne, un retour par une flèche inversée, une impasse par un fond barré.
Ce mode de lecture permet d’identifier les trous dans le parcours, les incohérences, les moments où rien ne se passe. Cela évite de penser en écrans isolés. On traite l’usage dans sa continuité, avec ses hésitations, ses retours en arrière, ses points de friction. Une simple feuille ajoutée au milieu d’une séquence peut révéler une faille ou une solution.
Ce travail peut être mené seul ou à plusieurs. On peut se répartir les rôles : l’un simule l’utilisateur, l’autre lit le scénario. On verbalise chaque action, on mime les gestes, on s’arrête quand ça bloque. C’est une forme de jeu sérieux, accessible, directe, sans équipement. Ce n’est pas une méthode académique, mais une manière pratique et tangible de rendre les usages visibles, vérifiables, adaptables. Et tout reste modifiable d’un simple coup de crayon.
Ce que cela change dans les projets
Dans le projet Allo Agri, une demande urgente a donné lieu à un croquis sur calque. Le besoin était clair : permettre à un agriculteur de déclarer un incident en moins de deux minutes. Le croquis a permis de réduire le formulaire à l’essentiel. Pas de menu déroulant inutile. Pas de multi-étapes. L’interface définitive est arrivée plus tard, mais le fonctionnement avait déjà été validé sur papier. Ce travail a permis d’aller vite sans précipitation.
Ce qui change, c’est la posture de départ. Plutôt que de partir d’un outil ou d’un modèle existant, on part de la contrainte réelle. Le terrain donne la forme. On esquisse en fonction du temps disponible, des usages connus, de la simplicité attendue. Et parce que tout est d’abord posé à la main, il est facile de montrer, d’expliquer, de faire valider. Pas besoin d’un prototype cliquable. Une photo du croquis annoté suffit souvent à engager la discussion.
Dans d’autres projets, ce sont les sketchs qui ont évité une dérive vers une sur-complexité. Une fonctionnalité qui semblait « indispensable » sur le papier disparaît d’elle-même lorsqu’on la joue en séquence. Ou au contraire, une absence criante devient évidente dès qu’on suit le parcours complet. Le croquis n’est pas là pour valider un design, mais pour questionner la logique fonctionnelle. C’est un outil de clarification, pas de validation esthétique.
Quand le code prend le relais
Le passage au code ne trahit pas le trait. Il le prolonge. Ce qui a été posé à la main devient structure HTML, style CSS, logique JavaScript. Une zone crayonnée devient une div. Une hiérarchie visuelle se traduit en classes. Une interaction dessinée sur calque se décline en fonction, en événement, en condition d’affichage.
<section class="module">
<!-- Titre principal de la section -->
<h2><!-- Titre ici --></h2>
<!-- Bloc de contenu ou description -->
<div class="content">
<!-- Texte, formulaire ou tout autre élément -->
</div>
<!-- Actions possibles -->
<div class="actions">
<!-- Boutons ou liens -->
</div>
</section>Le croquis contient déjà les règles. On y voit ce qui est visible ou caché, ce qui est accessible immédiatement ou déclenché plus tard. On peut anticiper l’état par défaut, l’état actif, l’état d’erreur. Le dessin est parfois plus explicite qu’un brief écrit. Il permet de discuter du comportement d’un élément, pas seulement de son apparence.
<div class="task" :class="task.status">
<h3>{{ task.title }}</h3>
<p>{{ task.description }}</p>
</div>Ce composant Vue correspond à un élément conçu sur papier, avec trois états identifiés dès l’étape de croquis : non commencé, en cours, terminé. L’usage est clair, le code n’invente rien. Il vient simplement traduire ce qui a été préparé ailleurs. Le gain, c’est une continuité. On ne change pas de logique entre l’idée et l’implémentation. On garde le même fil conducteur, du crayon à la ligne de code.
Revenir au trait pour mieux avancer
Ce n’est ni un geste nostalgique, ni un snobisme d’auteur. C’est une manière de garder le cap sur le besoin réel. D’éviter les interfaces vides. De construire depuis la main. N’importe qui peut commencer : un carnet, un crayon, quelques questions. Et surtout, du temps pour poser les choses avant de chercher à produire. Chez Pem’s Projects, ce détour par le trait n’est pas un luxe. C’est souvent ce qui nous a permis d’éviter les fausses pistes.
Revenir au trait, c’est se donner le droit d’explorer sans objectif immédiat de rendu. On observe, on teste, on revient en arrière. On montre à l’utilisateur un schéma, pas une maquette. On l’invite à réagir à une logique, pas à un style. Ce décalage volontaire avec les outils numériques permet de rester concentré sur l’essentiel : à quoi ça sert, comment on s’en sert, et qu’est-ce qui bloque.
Dans un contexte où tout pousse à accélérer, à standardiser, à produire vite, ce temps d’esquisse est un temps de compréhension. Ce n’est pas une perte de productivité, c’est un gain de clarté. Le dessin ne remplace pas le code, mais il prépare son terrain. Et il donne souvent aux projets ce petit degré de justesse fonctionnelle qui fait toute la différence.
Conclusion
Cette méthode n’a rien d’un retour en arrière. Elle n’oppose pas le papier au numérique, elle les articule. Le trait n’est pas un frein à la modernité, il en est parfois la condition. Chaque projet peut bénéficier d’un moment analogique, où les idées se posent sans filtre, sans habillage, sans distraction.
Il ne s’agit pas de ralentir pour ralentir. Il s’agit de ralentir pour mieux viser. Pour entendre le besoin, pour voir l’usage avant de le construire. Et si ce temps de croquis peut sembler désuet dans un environnement technologique pressé, il reste l’un des outils les plus robustes pour concevoir juste, et concevoir utile.