KaptiMéthode
Du croquis au code : les outils qu’on utilise vraiment, et pourquoi
On nous demande souvent « vous travaillez avec quoi ? ». La réponse honnête : avec ce que l’équipe du client sait maintenir après notre départ. Mais d’une mission à l’autre, certains outils reviennent, parce qu’ils réduisent la distance entre la maquette et le produit livré. Voici lesquels, étape par étape.
Un outil ne fait pas un bon produit. En revanche, un mauvais enchaînement d’outils en abîme beaucoup : une maquette qu’on redessine dans le code, un composant qui existe trois fois sous trois noms, une démo IA impossible à reproduire. Nos choix suivent tous la même idée : que le design, le code et l’IA parlent le même langage, du premier entretien à la mise en production.
Comprendre : la recherche avant les écrans
Les premiers outils d’une mission sont les plus simples : un guide d’entretien, un enregistreur, un tableau partagé. On interroge les utilisateurs et les équipes métier, on observe sur le terrain quand c’est possible, et on range ce qu’on apprend dans une synthèse que tout le monde peut relire.
L’IA nous fait gagner du temps ici, avec une limite claire : elle aide à transcrire et à regrouper, elle ne décide pas de ce qui compte. Les citations qui finissent dans la synthèse ont toutes été relues par la personne qui a mené l’entretien.
Concevoir : Figma, et des décisions écrites
On conçoit dans Figma, parce que c’est là que travaillent la plupart des équipes produit et qu’il permet de commenter un écran avec le client au lieu d’échanger des captures. Trois habitudes comptent plus que l’outil lui-même :
- Des composants dès le premier écran. Même pour une maquette de deux semaines, chaque bouton et chaque champ est un composant. C’est ce qui permet ensuite de passer au code sans tout redessiner.
- Des design tokens. Couleurs, typographies, espacements et rayons sont nommés une fois (« texte secondaire », « surface », « accent ») et réutilisés partout. Le mode sombre de ce site, par exemple, n’est qu’un deuxième jeu de valeurs pour les mêmes noms.
- Les états qu’on oublie. Chargement, erreur, liste vide, réponse incertaine d’une IA : chaque écran clé est dessiné dans ces états-là, pas seulement dans le cas idéal.
Tester : un prototype qui marche vraiment
Pour une fonctionnalité IA, une maquette statique ment : elle montre une réponse parfaite à chaque fois. On teste donc avec une version fonctionnelle, branchée sur un vrai modèle et des données réalistes, que cinq à sept utilisateurs prennent en main. Les démos de nos projets internes sont construites de cette façon : du code qui tourne dans le navigateur, avec des données de démonstration.
Développer : React, des composants documentés, et Webflow quand il le faut
Côté produit, on développe surtout en React (et React Native pour le mobile), parfois en Angular quand c’est la base existante du client. Côté serveur, on s’adapte au contexte : Java dans les systèmes d’information établis, Node et PostgreSQL pour les produits plus récents, comme Swing, l’extension née de notre hackathon.
Le lien entre design et code passe par Storybook : chaque composant y est documenté avec ses variantes, ses états et ses règles d’accessibilité. Designers et développeurs regardent le même catalogue, et l’équipe du client sait où chercher après notre départ.
Pour un site vitrine que l’équipe marketing doit faire vivre seule, on préfère Webflow : c’est ce qu’on a livré à Moofize, dont l’équipe modifie ses pages sans développeur.
Intégrer l’IA : le modèle adapté au problème
On ne choisit pas un modèle par habitude. Selon le besoin :
- Un modèle de langage pour résumer, classer ou rédiger un brouillon.
- Une recherche dans vos documents (RAG) quand la réponse doit venir de vos sources et les citer : fiches produits, contrats, documentation interne.
- Un modèle de vision pour vérifier une photo ou lire un document scanné.
Le choix final dépend de trois contraintes qu’on pose dès le cadrage : où les données ont le droit d’aller (hébergement, confidentialité), combien coûte chaque appel à l’échelle, et ce qui se passe quand le modèle se trompe. La troisième question est une question de design autant que de technique.
Notre veille. Les modèles, les outils et la réglementation changent tous les trimestres. On les teste en continu sur nos projets internes, et on écrit ce qu’on en retient sur ce blog, comme notre lecture de l’article 50 de l’AI Act.
Vérifier : l’accessibilité testée à la main
Les outils automatiques repèrent une partie des problèmes d’accessibilité, pas tous. On les complète par des tests au clavier, au lecteur d’écran (VoiceOver, TalkBack, NVDA) et en zoom à 200 %, puis par une grille RGAA quand le client doit publier une déclaration d’accessibilité.
Transmettre : ce qui reste après la mission
Le meilleur test d’une stack, c’est le jour où l’équipe du client reprend la main. On laisse donc un fichier Figma rangé, des tokens partagés entre design et code, un Storybook à jour et une documentation courte qui explique les choix. Si l’équipe n’a pas besoin de nous rappeler pour ajouter un écran, la mission est réussie.
Questions fréquentes
Vous imposez vos outils ?
Non. On part de ce que votre équipe sait maintenir. Si vous êtes sur Angular ou sur une autre plateforme, on travaille dedans.
Quel modèle d’IA utilisez-vous ?
Celui qui convient au cas d’usage et à vos contraintes de confidentialité, de coût et d’hébergement. On le justifie par écrit pendant le cadrage.
Le design system est-il livré en code ?
Oui, quand la mission le prévoit : composants en React documentés dans Storybook, avec les mêmes tokens que la librairie Figma.