Réponse en bref
La conception d’un produit SaaS couvre les rôles et permissions qui décident qui voit quoi, les parcours que les gens répètent chaque jour, et chaque état que peut prendre un écran : vide, en chargement, en échec, en lecture seule, partiel, dense et débordant. Elle spécifie le comportement des composants plutôt que leur apparence, couvre le clavier et les technologies d’assistance, et se termine par une remise exploitable. Elle ne couvre pas les écrans hors périmètre.
Faits vérifiés
- Vérification des sources
- 7 septembre 2026
- Besoin du lecteur
- exigences de design d’un produit SaaS
Ce que la mission produit réellement
Demandez ce que livre un projet de conception SaaS et la réponse honnête n’est pas un nombre d’écrans. C’est un ensemble de situations tranchées : qui regarde, ce qu’il cherche à terminer, et ce que fait l’interface dans chaque condition où le système peut réellement se trouver. L’écran rempli, sur le chemin heureux, est celui que tout le monde revoit et celui qui pose ensuite le moins de problèmes.
L’essentiel du travail se trouve dans les sept états ci-dessous. Les énumérer est mécanique, et c’est là qu’une préparation en assistance IA est rapide et peu coûteuse. Décider de ce qui doit s’y passer ne l’est pas : la réponse dépend de la façon dont votre système échoue et de ce que vos utilisateurs peuvent se permettre de perdre. Cette part demande quelqu’un qui en répondra.
Vide
Ressemble à : l’écran avant toute donnée, portant l’unique action qui crée le premier enregistrement et une description simple de ce qui apparaîtra ensuite. Si on le saute : les nouveaux comptes s’ouvrent sur un tableau blanc et le support répond chaque semaine à la même question.
Chargement
Ressemble à : un comportement décidé pour les réponses lentes — lignes squelettes, remplissage progressif ou indicateur bloquant — et ce qui change au-delà d’un seuil annoncé. Si on le saute : chaque écran reçoit l’indicateur préféré de son développeur, et la lenteur se lit comme une panne.
Échec
Ressemble à : ce que voit la personne quand une action n’aboutit pas, ce qu’elle peut réessayer, et ce qui est conservé pendant ce temps. Si on le saute : un enregistrement raté jette en silence ce que quelqu’un venait de saisir, et c’est la plainte dont on se souvient le plus longtemps.
Lecture seule
Ressemble à : le même écran vu par quelqu’un qui peut consulter sans modifier, où masquer et désactiver sont choisis volontairement et non écran par écran. Si on le saute : les permissions tiennent côté serveur et fuient dans l’interface.
Partiel
Ressemble à : la façon dont l’écran admet qu’une source n’a pas répondu ou qu’un chiffre est plus ancien que les autres. Si on le saute : un écran à moitié chargé paraît aussi fiable qu’un écran complet, et les gens agissent dessus.
À grande échelle
Ressemble à : le même tableau à mille lignes — pagination ou virtualisation, tri, filtres, et quelles colonnes survivent à une fenêtre étroite. Si on le saute : la maquette tient en démo et pas au deuxième mois.
Débordement
Ressemble à : chaque libellé et chaque valeur à la plus grande longueur plausible, chaîne traduite comprise. Si on le saute : les boutons passent à la ligne, la troncature cache ce qui comptait, et la correction arrive après le lancement.
Les rôles et permissions passent avant les écrans
Un écran n’est pas une seule maquette si deux rôles le voient différemment. Listez chaque rôle — y compris les rôles d’exploitation et de support qui n’apparaissent jamais dans une présentation — et dites pour chacun ce qu’il peut voir, ce qu’il peut modifier et ce qu’il ne doit jamais atteindre. Ce tableau décide du nombre réel de maquettes, et l’écrire coûte bien moins que le découvrir.
Décidez volontairement si une action interdite est masquée ou visible mais désactivée. Masquer rend l’interface plus calme et empêche de découvrir ce qu’on pourrait demander ; désactiver explique la limite et admet que la capacité existe. Les deux se défendent. Choisir autrement sur chaque écran par accident, c’est ainsi qu’un produit finit par faire les deux.
Les données réelles cassent des maquettes que les données de test flattent
Demandez un export anonymisé avant la première maquette. Dix lignes inventées rendent n’importe quel tableau équilibré ; les enregistrements réels apportent des noms longs, des champs vides, des quasi-doublons, des langues mêlées et bien plus de lignes que n’importe quelle démo. Ce sont ces conditions que la maquette doit encaisser, et toutes sont connues dès le premier jour.
Deux nombres comptent plus que les autres : la valeur la plus longue qu’un champ peut réellement contenir, et le nombre de lignes qu’un compte normal accumule en un an. Concevez pour ceux-là et l’interface tient. Concevez pour la démo, et votre premier vrai client devient le premier rapport de bug.
Les parcours à concevoir sont ceux qu’on répète
L’essentiel d’une journée dans un outil, ce sont deux ou trois tâches faites encore et encore. Celles-là méritent le détail : chaque étape, chaque embranchement, ce qui arrive quand on est interrompu au milieu puis qu’on revient, et comment annuler ce qu’on vient de faire. Une page de réglages ouverte deux fois par an n’en demande pas autant, et prétendre le contraire double le périmètre en silence.
Dites à voix haute quels parcours ont été choisis pour cette profondeur et lesquels ont été volontairement laissés plus légers. Un écart de finition non annoncé se lit en revue comme un travail inachevé, alors qu’il s’agissait d’une décision sur l’endroit où mettre l’effort.
Spécifiez le comportement, pas seulement l’apparence
Un composant ne se décrit pas par son allure. Il se décrit par ce qu’il fait : où va le focus, ce que signifie désactivé, quand la validation se déclenche et ce qu’elle dit, ce qui se passe sur une réponse lente, et comment le clavier le traverse. L’apparence se recopie depuis une image. Le comportement s’invente dans le code si personne ne l’a écrit, et il diffère alors d’un écran à l’autre.
Ce n’est pas la même chose que construire un design system. Spécifier le comportement une fois et le réutiliser est un livrable de ce travail ; monter un système que plusieurs équipes maintiennent pendant des années est une autre décision, avec son coût et sa propre question de maturité, et elle mérite d’être posée à part plutôt que supposée incluse.
Clavier et technologies d’assistance sont ici des exigences fonctionnelles
Les gens travaillent dans l’outil toute la journée, ce qui change le calcul. L’usage au clavier cesse d’être une case de conformité pour devenir la voie rapide de quiconque saisit des données — et c’est aussi la première chose qui casse quand un composant maison remplace un composant natif. WebAIM documente le comportement clavier attendu des éléments interactifs et la façon de le tester.
Les composants maison ont besoin d’une sémantique déclarée, pas sous-entendue. Un div stylé qui se comporte comme une liste déroulante ne communique rien aux technologies d’assistance tant qu’on ne lui donne pas un rôle, un état et un libellé, et MDN documente ce qu’ARIA attend de chacun. Décidez-le pendant la conception, car l’ajouter après revient le plus souvent à refaire le composant.
Ce dont le développement a besoin à la remise
La remise est terminée quand quelqu’un qui n’était pas à la revue peut construire un écran sans poser de question. Cela veut dire chaque état dans son propre cadre, les vrais textes pour le cas vide et pour l’échec plutôt qu’un remplissage, les espacements et la typographie comme valeurs réutilisables et non comme nombres relevés sur une image, et les règles que l’interface doit faire respecter écrites comme des règles.
Incluez ce qui n’est volontairement pas spécifié, et nommez qui tranche. Les développeurs prendront ces décisions de toute façon à l’approche de la date ; la différence entre une bonne et une mauvaise remise, c’est qu’ils savaient les prendre.
Ce qu’un délai de 15–30 jours couvre, et ce qu’il ne couvre pas
Une mission de cette durée couvre le tableau des rôles, les parcours répétés de bout en bout, les états des écrans de ces parcours, le comportement des composants qu’ils emploient, et la remise. Elle ne couvre pas tous les écrans d’un produit mature, un design system complet, l’itération continue après le lancement, ni une recherche que personne n’a commandée.
La vraie question de périmètre n’est pas combien d’écrans, mais combien d’états pour combien de rôles. Deux rôles et huit écrans en sept états, ce n’est pas le même projet que cinq rôles et ces mêmes huit écrans — et le second n’est pas un peu plus de travail, c’est un autre devis.
Écrivez les exclusions
Listez ce qui est hors périmètre dans le même document, avant de commencer. Non comme une clause de style, mais comme une carte partagée de ce qui existe et n’est pas encore fait, avec la condition qui ramènerait chaque point dedans. La plupart des litiges en fin de mission de conception produit ne portent pas sur la qualité : ce sont deux souvenirs différents de ce qui était inclus.
Cette liste d’exclusions est en outre l’artefact de planification le moins cher que le projet vous donnera. C’est le backlog de la phase suivante, déjà débattu, avec les raisons jointes — ce que la plupart des backlogs ne portent pas.
Checklist pratique
- Chaque rôle listé avec ce qu’il peut voir, modifier, et ce qu’il ne doit jamais atteindre
- Chaque écran spécifié dans les sept états, pas seulement dans l’état rempli
- Maquettes confrontées à un export réel anonymisé plutôt qu’à dix lignes d’exemple
- Les deux ou trois parcours quotidiens conçus de bout en bout, interruptions comprises
- Comportement des composants écrit : focus, désactivé, validation, réponse lente, clavier
- Usage au clavier et sémantique d’assistance couverts pour chaque élément interactif
- La remise porte les états, des valeurs réutilisables, les vrais textes de vide et d’échec, et les règles
- Exclusions listées explicitement, chacune avec la condition qui la ramènerait au périmètre
Questions et réponses
Qu’est-ce qui est réellement livré à la fin d’un projet de conception SaaS ?
Les parcours du travail répété, chaque écran dans chacun de ses états, le comportement des composants écrit, les textes de vide et d’échec, et une remise à partir de laquelle le développement construit sans deviner. Le nombre de fichiers d’image compte bien moins que le fait que le comportement soit spécifié.
Pourquoi demande-t-on des données réelles avant de commencer ?
Parce que les données de test masquent les problèmes. Dix lignes bien rangées rendent tout tableau correct ; un export réel apporte des noms longs, des champs vides, des doublons et mille entrées, et ce sont eux qui décident de la maquette. Un export anonymisé suffit en général.
Combien d’écrans faut-il prévoir ?
Moins que vous ne croyez, dans plus d’états que vous ne croyez. Huit écrans en sept états font cinquante-six situations conçues, et c’est dans les états que se trouvent le travail et le risque. Compter les écrans sous-estime la mission de façon systématique.
Avons-nous besoin d’un design system pour cela ?
Pas nécessairement. Ce travail demande un comportement de composants spécifié une fois et réutilisé, ce qui diffère de construire et maintenir un design system. Si plusieurs équipes vont développer en parallèle pendant des années, c’est une question distincte, qui mérite d’être posée seule.
Que faut-il préparer avant le démarrage du projet ?
Un export de données anonymisé, la liste des rôles avec leurs permissions, les deux ou trois tâches quotidiennes, et quelqu’un capable de dire ce qui doit se passer quand une action échoue. Ces quatre éléments débloquent l’essentiel de la mission.