Se planter vite pour construire mieux.

Pendant longtemps, on a cru qu’une maquette partielle suffisait.

Pendant les premières années de LEADOFF, notre façon de concevoir les projets était assez classique. On écrivait des spécifications détaillées, on réalisait les maquettes des écrans principaux, on les faisait valider, puis on passait au développement en considérant que cette validation valait, plus ou moins implicitement, pour tout ce qui restait à concevoir.

Entre quelques maquettes et un produit complet, il reste pourtant énormément de décisions à prendre : des comportements d’interface, des cas particuliers, des enchaînements d’écrans ou simplement des détails qui paraissent secondaires lorsqu’on les décrit, mais deviennent très concrets lorsque le produit commence à fonctionner. Et c’est souvent à ce moment-là que le client les découvrait réellement.

Le développement avançait donc, puis arrivaient des demandes de modification sur des éléments que nous pensions validés. En interne, cela pouvait générer de la frustration : « Mais on l’avait validé !? ».

Avec le recul, ce raisonnement était un peu facile. Ce que le client avait validé, c’était ce qu’on lui avait réellement montré, pas forcément tout ce que nous avions déduit de cette validation. Et il y a quelque chose d’assez étrange à finir par être contrarié contre son propre client parce qu’il découvre trop tard quelque chose que nous aurions pu lui montrer plus tôt.

Le problème n’était pas forcément la validation. C’était ce qu’on lui demandait de valider.

Alors on a décidé de piloter par le design.

On a progressivement arrêté de chercher à tout décrire dans de longues spécifications pour pousser beaucoup plus loin la conception avant de développer.

Aujourd’hui, les écrans sont conçus dans Figma puis assemblés dans un prototype. On peut parcourir le produit, comprendre les enchaînements, tester les parcours et rendre beaucoup plus concrètes des choses qui seraient difficiles à expliquer dans un document. C’est ce prototype que nous faisons valider au client et, une fois validé, c’est aussi lui qui devient une grande partie de la spécification pour l’équipe de développement.

Le changement peut sembler assez simple, mais il modifie profondément ce que signifie « valider » un projet. On ne demande plus au client d’imaginer une partie du produit à partir d’un document ou de quelques écrans.

On lui donne quelque chose à parcourir, à questionner et à remettre en cause avant de commencer à le développer.

Les retours n’ont pas disparu. Ils ont changé de place.

Le client continue à faire des remarques, à préciser son besoin, à découvrir des cas auxquels personne n’avait pensé ou à nous dire qu’un parcours qui semblait évident ne l’est finalement pas. Et heureusement : c’est précisément à cela que sert la conception.

La différence, c’est qu’une grande partie de ces discussions a désormais lieu avant le développement. Modifier un parcours dans Figma coûte peu. Le modifier une fois développé, connecté aux données, testé et intégré au reste du produit coûte beaucoup plus cher.

Le gain n’est d’ailleurs pas seulement économique. Il y a moins d’incompréhensions, moins de frustration et moins de discussions pour déterminer ce qui était ou non supposé avoir été validé. La relation avec le client est plus saine parce que la validation est plus concrète.

Une objection pendant la conception n’est donc pas un problème à éviter. Une mauvaise idée découverte dans Figma est même plutôt une bonne nouvelle : elle vient d’être identifiée au moment où elle est encore facile à corriger.

On vient de se tromper au bon moment.

C’est probablement notre traduction la plus concrète de fail early, fail often, fail forward : tester, comprendre, corriger, puis avancer avec un peu moins d’incertitude qu’avant.

L’IA permet d’aller encore un peu plus loin.

Figma nous permet de confronter très tôt une interface et un parcours à la réalité. Aujourd’hui, l’IA ajoute une possibilité supplémentaire : dans certains cas, on peut aller au-delà du prototype visuel et construire rapidement un POC, une petite version fonctionnelle destinée non pas à devenir le produit final, mais à répondre à une question.

Une interaction fonctionne-t-elle réellement ? Une idée est-elle techniquement réaliste ? Un fonctionnement qui paraît intéressant sur le papier apporte-t-il vraiment quelque chose lorsqu’on peut le manipuler ? Là encore, l’objectif n’est pas nécessairement de produire quelque chose que l’on conservera, mais d’obtenir une réponse avant d’engager davantage de temps dans le développement.

Un POC généré rapidement n’est pas nécessairement du code destiné à partir en production, de la même manière qu’un prototype Figma n’est pas l’application finale. Ce sont d’abord des outils pour confronter une idée au réel et réduire l’incertitude.

L’intérêt de l’IA n’est donc pas seulement de produire plus vite. Elle permet aussi de tester plus tôt.

Et finalement, notre façon de travailler continue d’évoluer autour de la même idée : on ne cherche pas à avoir raison le plus tôt possible. On cherche à découvrir le plus tôt possible quand on a tort.