Un wireframe SaaS est une version brute de l’écran, sans couleurs ni finitions, qui sert à décider de la structure avant d’investir dans le design et le développement. Commencer par ce « brut » permet de tester les parcours avec de vrais utilisateurs tant qu’une erreur ne coûte presque rien à corriger. Aujourd’hui, ce brut prend souvent la forme d’un prototype rapide réalisé avec l’IA, mais le principe ne change pas : on valide la structure avant de soigner l’apparence.
Beaucoup de projets SaaS sautent cette étape pour montrer vite quelque chose de beau. Le résultat arrive plus tôt, et les problèmes aussi, mais au moment où ils coûtent le plus cher. Voici pourquoi le brut fait gagner du temps, ce qu’il faut y trancher, comment le tester et ce que l’IA y a changé.
Pourquoi commencer un SaaS par le « brut » plutôt que par l’interface finale ?
Une interface finale répond à deux questions à la fois : est-ce le bon écran, et est-il beau ? Les réponses se mélangent. En réunion, on discute d’un bleu ou d’une icône alors que la vraie question porte sur l’ordre des informations ou sur une étape en trop.
Le brut retire la seconde question. Il ne reste que la structure : ce que l’utilisateur voit en premier, ce qu’il peut faire, où il va ensuite. C’est sur cette base que se joue l’adoption d’un logiciel métier.
Le brut sert à décider, pas à présenter
Un wireframe n’est pas un livrable à montrer au comité de direction. C’est un outil de travail, qui permet de comparer deux ou trois organisations d’un même écran et d’en éliminer vite.
Le Nielsen Norman Group observe que les designers s’attachent moins à un prototype basse fidélité, et que les utilisateurs se sentent plus libres de le critiquer (Nielsen Norman Group). Ces deux effets comptent.
Une équipe qui tient à son écran défend sa solution au lieu d’écouter. Un utilisateur intimidé par une interface léchée garde ses remarques pour lui.
Les parties prenantes réagissent de la même façon. Devant une version brute, elles comprennent que le travail n’est pas fini. Devant une maquette soignée, elles croient souvent qu’il ne reste qu’à développer.
Ce que coûte une erreur, selon le moment où on la trouve
Le même article du Nielsen Norman Group rappelle que reprendre un produit après son lancement coûte bien plus que de jeter un prototype (Nielsen Norman Group). Sur un croquis, déplacer un bloc prend une minute.
Dans un logiciel en production, le même déplacement touche le code, les tests, la documentation et les habitudes des utilisateurs.
Le manuel des services publics britanniques demande d’ailleurs de prototyper pour explorer, partager et tester différentes options « avant de s’engager à construire quoi que ce soit » (GOV.UK Service Manual). Le gouvernement du Québec fixe la même règle : une phase dédiée à mettre les hypothèses à l’essai, avec des solutions fondées sur des observations plutôt que sur des hypothèses (Gouvernement du Québec).
Pour un éditeur de SaaS, l’enjeu est le même. Une fonctionnalité mal structurée génère des tickets, des contournements et des exports vers Excel pendant des années.
Une heure de plus passée sur le brut évite souvent des semaines de reprise.
Du brut au produit : la structure est validée avant le design et le code.
Wireframe, maquette, prototype : quelle différence pour un SaaS B2B ?
Les trois termes sont souvent employés l’un pour l’autre. Ils désignent pourtant trois niveaux de détail, qui ne répondent pas aux mêmes questions.
Le Nielsen Norman Group propose de juger la fidélité d’un prototype sur trois dimensions : l’interactivité, le rendu visuel, et le contenu (Nielsen Norman Group). Un prototype peut être brut sur l’une et précis sur une autre. Cette grille aide à choisir le bon niveau pour chaque question.
| Niveau | Ce qu’il montre | La question à laquelle il répond |
|---|---|---|
| Wireframe | La structure, les blocs, les priorités | Est-ce le bon écran, dans le bon ordre ? |
| Maquette | L’apparence finale, statique | Est-ce lisible et cohérent avec la marque ? |
| Prototype | Un parcours qu’on peut parcourir | L’utilisateur va-t-il au bout de sa tâche ? |
Le wireframe : la structure et les priorités
Le wireframe répond à la question de l’ordre. Qu’est-ce qui apparaît en haut d’un tableau de bord ? Quelles colonnes affiche une liste ?
Il tranche aussi entre les actions : laquelle est mise en avant, laquelle est rangée dans un menu, laquelle disparaît.
Sur le tableau de bord B2B de MSC, Victor Michel, fondateur du studio, a d’abord posé un zoning, puis des wireframes appuyés sur ce que l’observation des clients au travail avait montré. Chaque bloc d’information devait correspondre à un usage constaté sur le terrain, pas à une idée née en réunion.
La maquette : l’apparence, une fois la structure validée
La maquette ajoute les couleurs, la typographie, les icônes et les états visuels. Elle vient une fois la structure stabilisée, pour ne pas habiller un écran qui va encore changer.
C’est aussi le moment de vérifier les contrastes et la taille des textes, pour que l’écran reste lisible sur un poste de bureau comme en plein jour.
C’est aussi à ce stade que le design system prend le relais : les composants réutilisés évitent de redessiner chaque bouton et chaque tableau. Notre article sur le design system d’un SaaS détaille quand le construire.
Le prototype : ce qu’on teste avec de vrais utilisateurs
Le prototype enchaîne les écrans pour qu’on puisse les parcourir comme le produit final. Il peut rester brut visuellement, tant que le parcours est réaliste.
Pour Invest Easy, le robo-advisor de Swissquote, Victor Michel a fait passer plusieurs scénarios en wireframes basse fidélité, éprouvés lors de tests guerrilla rapides, avant de passer aux maquettes haute fidélité. Tester sur des esquisses permettait de jeter une idée sans regret.
Comment l’IA a-t-elle changé l’étape du « brut » ?
Il y a encore peu, le brut se dessinait à la main ou dans un outil de maquettage, écran par écran. Les outils d’IA permettent désormais de produire en peu de temps un prototype cliquable à partir d’une description ou d’un croquis.
Au studio, c’est devenu la façon principale d’itérer : plutôt que des séries de wireframes statiques, on construit vite un prototype qu’on peut faire essayer, puis on le corrige. Le principe du brut reste intact. Seul l’outil a changé.
Un prototype testable plus vite
Le Nielsen Norman Group a évalué plusieurs familles d’outils : générateurs de maquettes, outils qui produisent des prototypes interactifs en code, assistants conversationnels (Nielsen Norman Group). Ses conclusions sont nettes sur les usages utiles : explorer des pistes en début de projet, produire des preuves de concept, et transformer rapidement une maquette en prototype testable.
Pour un SaaS B2B, ce gain de vitesse change le rythme.
On peut confronter deux organisations d’un écran à de vrais utilisateurs dans la même semaine, au lieu d’en choisir une sur intuition parce que la seconde prendrait trop de temps à dessiner.
Ce que les outils d’IA ratent encore
La même étude résume les résultats d’une formule : beaux de loin, mais loin d’être bons (Nielsen Norman Group). Même les meilleurs résultats ratent des questions d’espacement, de regroupement, de hiérarchie et de contraste. Sans indications visuelles précises, le style est générique et interchangeable.
Plus grave pour un logiciel métier, un outil peut mal interpréter le besoin : dans l’étude, une demande vague de « page de profil » a été comprise comme un profil de réseau social, avec l’information secondaire en premier. L’outil exécute bien une consigne, il ne sait pas ce qui compte pour vos utilisateurs.
C’est pourquoi le brut produit avec l’IA doit être piloté par quelqu’un qui connaît le métier et les utilisateurs. La demande est précise, les références sont fournies, et chaque écran généré est relu avec un œil critique avant d’être montré.
Un prototype est jetable par défaut
Un prototype réalisé avec l’IA peut ressembler à un produit fini. C’est un piège. Le manuel britannique rappelle que le code d’un prototype n’a pas à respecter les standards de la production, et qu’il ne faut pas le copier tel quel dans le produit (GOV.UK Service Manual).
Le même texte recommande de faire plusieurs prototypes et d’abandonner ceux qui ne passent pas les tests. Ce qui a été validé est ensuite reconstruit proprement, avec une architecture, des tests et une gestion des données dignes d’un logiciel en production.
Que faut-il trancher au stade du « brut » ?
Le brut n’est utile que s’il sert à prendre des décisions. Voici les sujets à régler avant de passer à la maquette, dans l’ordre où ils pèsent sur l’adoption.
À trancher sur le brut, avant de soigner l’apparence.
Les trois parcours qui comptent vraiment
Un SaaS compte des dizaines d’écrans, mais ses utilisateurs passent l’essentiel de leur temps sur trois ou quatre parcours. Le brut se concentre sur eux : créer un dossier, valider une demande, retrouver une information, selon votre métier.
Pour les choisir, partez de ce que vos utilisateurs font chaque jour, pas de la liste des fonctionnalités prévues.
Les autres écrans peuvent attendre. Les dessiner tous au même niveau de détail dilue l’attention, et retarde le moment où l’on teste ce qui compte.
La hiérarchie de l’information
Sur chaque écran, une seule information doit se lire en premier. Sur un tableau de bord, c’est souvent ce qui demande une action aujourd’hui. Sur une liste, ce sont les colonnes qui servent à décider, pas toutes celles que la base de données contient.
Le brut est le bon moment pour retirer. Une colonne supprimée sur un wireframe ne coûte rien. La même colonne retirée d’un produit en service déclenche des demandes de clients habitués à la voir.
Les états oubliés : vide, erreur, attente
Les maquettes montrent presque toujours l’écran idéal, rempli de données propres. La réalité est différente : le premier jour, tout est vide ; certaines actions échouent ; certains traitements prennent du temps.
Prévoir ces états sur le brut évite de les improviser pendant le développement.
Un écran vide qui explique quoi faire, un message d’erreur placé au bon endroit, un indicateur de chargement clair : ce sont souvent eux qui font la différence au quotidien. Notre article sur l’audit UX d’un SaaS montre ce qu’ils pèsent dans un produit existant.
Comment tester un wireframe SaaS sans y passer des semaines ?
Tester le brut ne demande ni laboratoire ni panel de centaines de personnes. Il faut surtout de vrais utilisateurs, de vraies tâches et un peu de rigueur dans la façon de regarder.
Le Nielsen Norman Group le dit sans détour : il faut tester les prototypes, cliquables ou statiques, basse ou haute fidélité, pour apprendre comment améliorer le design (Nielsen Norman Group). Le niveau de finition compte moins que la régularité.
Quelques utilisateurs, des tâches réelles
Donnez une tâche précise, tirée de leur travail : « retrouvez la commande du client X et signalez un retard ». Ne montrez pas le chemin. Observez où la personne hésite, revient en arrière ou cherche un bouton qui n’existe pas.
Notez ce que la personne fait, pas seulement ce qu’elle dit. Un utilisateur qui affirme que tout est clair peut avoir cherché trois fois le même bouton.
Quelques séances suffisent souvent à voir les mêmes blocages se répéter. On corrige, puis on teste à nouveau. Le cycle court compte plus que le nombre de personnes vues à chaque fois.
Tester là où le travail se fait
Un logiciel métier s’utilise dans un bureau bruyant, entre deux appels, sur un écran partagé ou dans un atelier. C’est là qu’il faut le tester. Pour le tableau de bord de MSC, le prototype haute fidélité a été testé sur place, en situation de travail, et ces tests ont révélé quelles informations devaient se lire d’un coup d’œil.
Les données comptent aussi. Pour Metroscope, l’IA de maintenance prédictive des centrales EDF, les prototypes ont été construits sur de vraies données de centrale avant d’être testés sur site par des techniciens. Une démonstration sur des données fictives n’aurait rien révélé des vrais problèmes de densité.
Enfin, faites relire le brut par ceux qui portent les contraintes. Sur la digitalisation de procédures judiciaires pour un service public suisse, les wireframes ont d’abord été relus par des juristes, garants de la conformité, puis les prototypes testés par les greffiers qui utiliseraient les écrans chaque jour.
Les erreurs à éviter
Quatre erreurs reviennent souvent :
- Peaufiner trop tôt. Une maquette léchée avant la validation de la structure verrouille des choix qui n’ont pas été testés.
- Prendre un prototype pour un produit. Ce qui fonctionne en démonstration n’a ni la sécurité, ni la robustesse, ni la maintenance d’un logiciel en production.
- Tester sur des données fictives. Des noms propres et des montants ronds cachent les libellés trop longs, les cas rares et les écrans surchargés.
- Montrer le brut sans cadrer la discussion. Rappelez à chaque séance ce qui est en question, la structure, pour que personne ne débatte d’une couleur provisoire.
Un prototype abouti a aussi sa place, mais plus tard.
Pour EPItrack, un SaaS de gestion des équipements de protection, le studio a conçu un prototype interactif haute fidélité qui sert de support de démonstration face à des clients et des investisseurs, et de base de travail pour les développeurs. Ce niveau de finition vient après la validation des parcours, pas avant.
Le brut n’est pas une étape de plus dans le projet. C’est celle qui rend les suivantes plus courtes : la maquette part d’une structure validée, le développement part d’un parcours testé, et les premiers clients découvrent un produit qui répond à leur travail réel.
Notre méthode CRAFT place cette validation avant chaque investissement important, et nous l’appliquons pour des éditeurs de la région comme pour des entreprises de Genève, où le studio conçoit des SaaS B2B.
Sources
- Nielsen Norman Group, UX Prototypes: Low Fidelity vs. High Fidelity : dimensions de la fidélité, effets du brut sur les designers, les utilisateurs et les parties prenantes.
- Nielsen Norman Group, AI Prototyping : ce que les outils de prototypage par IA font bien et ce qu’ils ratent.
- GOV.UK Service Manual, Making prototypes : prototyper avant de construire, jeter ce qui ne passe pas les tests, ne pas copier le code d’un prototype en production.
- Gouvernement du Québec, Démarche de conception de services numériques : prototypes du croquis à la maquette interactive, hypothèses mises à l’essai avant le développement.