Le code est un matériau

Connaître son bois

Un menuisier ne dessine pas un meuble sans connaître le bois qu'il va travailler. Le chêne, le pin ou le hêtre n'ont ni la même résistance ni le même fil, et un nœud mal placé peut changer tout le plan. Le dessin compte, mais c'est la matière qui décide de ce qui tient.

Un produit qui a vécu a lui aussi ses propriétés : des composants, des conventions, des données réelles, des comportements que personne n'a documentés. Une maquette les ignore. C'est pourquoi je prototype de plus en plus directement dans le code du produit, avec l'IA : le matériau répond tout de suite.

Ce qui l'a rendu possible

Deux évolutions ont changé la donne.

Le design system est dans la codebase. Dans le produit sur lequel je travaille, les composants, les espacements, les couleurs, les traductions et les vraies données sont déjà disponibles. Prototyper dans le code permet d'en hériter directement, sans redessiner un tableau ou un bouton.

L'IA a réduit le coût d'un essai. Avec des règles écrites pour qu'elle respecte les conventions de la maison, un prototype qui demandait plusieurs jours en prend quelques heures. Le prototype de recherche globale m'a pris une demi-journée ; l'exploration d'un module complet de gestion des salles, environ trois jours.

Ce qu'un prototype révèle

Une maquette montre ce qu'on imagine. Un prototype dans le vrai code montre aussi ce qui existe déjà, y compris ce qu'on ne soupçonnait pas.

En prototypant la recherche globale, j'ai découvert que la recherche existante portait aussi sur des champs que la liste n'affiche pas. Certains résultats étaient donc incompréhensibles pour l'utilisateur, et cela posait une question de confidentialité. Le prototype, lui, ne cherche que dans les informations affichées.

Le même jour, un autre prototype revoyait les filtres d'une liste d'utilisateurs : des interrupteurs fixes deviennent des blocs qu'on ajoute, qu'on ordonne et qu'on nomme.

Un support de discussion

Le prototype ouvre la discussion plus qu'il ne la conclut. Dans le pitch de la recherche globale, j'ai précisé ses limites (tout est chargé dans le navigateur, ce qui suffit pour un jeu de test mais pas pour la production), puis proposé trois options pour la version finale, avec leurs compromis en matière de volume, de confidentialité et de coût. Le choix revenait à l'équipe.

Le menuisier ne fait pas la charpente

Connaître le matériau ne fait pas de moi un développeur backend. Je code l'interface et le front-end : ce que l'utilisateur voit, touche et comprend. La structure qui porte le tout, la qualité du code serveur, la performance quand une liste passe de cent à cent mille utilisateurs, l'infrastructure, demandent une connaissance technique que les développeurs ont et que je n'ai pas.

Ce partage tient grâce aux garde-fous du produit. La CI et les tests automatisés vérifient chaque changement, y compris les miens : une régression, une convention oubliée ou une requête trop lourde sont repérées avant d'arriver en production. Puis la revue d'un développeur valide ce qui touche aux données et aux performances. Ces outils me permettent de prototyper vite dans le vrai code sans fragiliser ce que d'autres ont construit.

Savoir jeter

La plupart de mes prototypes sont fermés sans être fusionnés, et c'est voulu. J'essaie d'éviter deux écueils :

• le prototype qui convainc trop tôt : il n'a pas été conçu pour durer et ne doit pas partir en production tel quel
• court-circuiter les développeurs : le prototype sert à leur poser la bonne question, pas à décider de l'architecture à leur place

Pour moi, être un designer qui code, c'est avant tout réduire la distance entre une idée et une décision : une hypothèse devient un objet que l'équipe peut essayer, critiquer et, si besoin, abandonner.