Utilisez cette checklist de parité UI multiplateforme pour garder la typographie, l'espacement, les états vides et le comportement des composants cohérents entre web et applications natives.
La parité UI signifie que votre application web et votre application mobile native donnent l'impression d'être le même produit. Pas des pixels identiques, mais le même sens, les mêmes attentes et les mêmes résultats quand quelqu'un tape, appuie ou attend.
Un test simple : si un utilisateur apprend quelque chose sur un écran, cet apprentissage doit se transférer à l'écran équivalent sur l'autre plateforme.
Ce sont généralement de petites différences qui perturbent les gens. Si un bouton s'appelle « Save » sur le web et « Done » sur mobile, les utilisateurs hésitent. Si l'espacement est plus serré sur une plateforme, l'écran paraît plus stressant même si les fonctionnalités sont les mêmes. Si appuyer sur une ligne de liste ouvre le détail sur mobile mais affiche une case à cocher sur le web, les utilisateurs commencent à deviner au lieu de faire confiance à l'UI.
Que doit-on faire correspondre exactement ? Tout ce qui affecte la compréhension et la confiance. Pour la plupart des produits, cela signifie :
Ce qui peut s'adapter ? Les choses qui concernent surtout le confort sur chaque plateforme. Le rendu des polices, les safe areas et les patterns natifs comme le geste de retour iOS ou les boutons système Android peuvent différer, tant que les utilisateurs atteignent le même objectif et comprennent ce qui a changé.
Un objectif pratique est d'avoir des « patterns prévisibles ». Si quelqu'un met à jour un profil sur le web, il doit reconnaître les mêmes champs, les mêmes règles de validation et le même message de succès sur mobile. Même si vous développez rapidement avec un outil comme AppMaster (UI web plus UI native iOS/Android), la parité nécessite des règles explicites pour que les apps évoluent dans la même direction et ne deviennent pas deux produits similaires mais divergents.
Les revues de parité échouent quand chaque plateforme est mesurée selon une idée différente du « correct ». Avant de comparer les écrans web et natifs, mettez-vous d'accord sur ce qui compte comme « identique » et notez-le. Ce n'est pas excitant, mais ça évite des heures de retouches.
Vous n'avez pas besoin d'une spécification massive. Il faut quelques règles qui empêchent la dérive la plus fréquente :
Ensuite, choisissez une source de vérité. Certaines équipes utilisent un fichier de design ; d'autres s'appuient sur des tokens plus un guide court. L'important est que les règles vivent au même endroit et que les changements soient tracés. Si vous construisez avec AppMaster, il est utile d'aligner les tokens et les composants réutilisables entre les builders web et mobile pour que les mêmes choix apparaissent partout.
Enfin, définissez la cadence et la responsabilité. Considérez la parité comme des tests, pas comme une finition de dernière minute. Décidez quand les revues ont lieu (avant les releases et après des changements de composants partagés), qui approuve (design pour le visuel, produit pour l'intention, QA pour les cas limites et la couverture d'appareils), et ce que signifie « terminé » (les divergences sont corrigées ou explicitement acceptées avec une raison).
Exemple : si votre portail client ajoute une nouvelle page « Invoices », décidez en amont comment les tableaux se contractent sur mobile, comment les états vides expliquent l'absence de factures, et ce que fait le bouton « Pay now » quand l'appareil est hors ligne. Avec cette baseline, la revue devient une vérification rapide de dérive, pas un débat de goût.
La typographie est là où le « presque pareil » devient vite « ça ressemble à un produit différent ». Commencez par nommer vos styles avec des tokens simples (H1, H2, Body, Caption) et appliquez-les de la même façon sur le web et le natif.
Choisissez des familles adaptées à chaque plateforme. Utilisez une famille principale par plateforme qui a la même personnalité et densité, puis définissez des fallbacks. Par exemple : police système sur iOS (SF), police système sur Android (Roboto) et une police web qui s'en rapproche, avec un fallback system-ui. L'objectif n'est pas des lettres identiques, mais le même ton et la même lisibilité.
Définissez une échelle typographique une fois, puis gardez-la assez restreinte pour que personne n'invente de nouvelles tailles. Par exemple :
Le comportement du texte compte autant que la taille. Décidez comment gérer les titres longs et les données imprévisibles (noms, adresses, sujets de tickets) pour que le web et le mobile ne dérivent pas :
L'alignement est une autre source fréquente de divergence. Par défaut, alignez à gauche la plupart des textes, surtout pour les formulaires et les listes. Centrez seulement pour des moments courts et ciblés comme un message de succès ou le titre d'un état vide.
Définissez des minima d'accessibilité et considérez-les non négociables. Visez au moins 16px pour le texte principal sur mobile, évitez des graisses très fines à petite taille, et conservez un contraste suffisant pour lire en lumière vive. Si vous utilisez AppMaster, rendez ces tokens de design partagés pour que le même écran soit lisible de façon cohérente sur web et natif.
L'espacement est là où le « presque le même » devient « on sent la différence ». Si votre écran web respire et que l'écran mobile est serré, les utilisateurs le remarquent même si les couleurs et les polices correspondent.
Commencez par une échelle d'espacement commune que les deux plateformes utilisent. Une échelle basée sur 4 se mappe proprement au CSS et aux grilles natives. Gardez les règles simples : les éléments liés ont des gaps plus petits que les sections séparées, un padding d'écran par défaut est fixé, et les exceptions sont rares et documentées.
Un baseline typique ressemble à ceci :
Standardisez ensuite les safe areas sur mobile. Le contenu ne doit pas se trouver sous l'encoche, l'indicateur home ou les barres système. Une règle claire aide : « Tout contenu principal respecte la safe area + le padding de base. » Si vous avez une barre en bas, incluez sa hauteur dans l'inset de contenu pour que la dernière ligne d'une liste reste atteignable.
La densité des listes nécessite aussi un choix explicite. Choisissez deux options et nommez-les (compact et comfortable). Définissez la hauteur de ligne, le padding vertical et l'usage des séparateurs. Appliquez la même option sur web et mobile pour un même type d'écran, afin que la « liste Invoices » ne paraisse pas être deux designs différents.
Les cibles tactiles font partie de l'espacement. Sur mobile, les contrôles doivent être faciles à atteindre même quand le layout est dense. Un minimum solide est 44x44 pour les taps, avec suffisamment d'espace entre actions pour éviter les erreurs de saisie.
Pour le web, consignez le comportement responsive aux breakpoints clés : nombre de colonnes, comportement de la sidebar et moment où les listes deviennent des cartes. Lors d'une revue de parité, comparez l'intention, pas les pixels. Le web peut montrer plus d'éléments à la fois, mais il ne doit pas changer la hiérarchie ou cacher les actions clés.
Si vous construisez dans AppMaster, garder les mêmes tokens d'espacement dans vos builders web et mobile aide les écrans à être cohérents par défaut.
La cohérence casse souvent dans les états, pas dans le chemin heureux. Traitez l'UI d'état comme une première classe, avec la même structure, le même ton et les mêmes actions sur web et natif.
Commencez par les actions. Les actions primaires doivent être évidentes et placées de façon cohérente (par exemple, en bas à droite dans les dialogues web et en bouton sticky en bas sur mobile). Les actions secondaires ne doivent pas concurrencer la primaire. Les actions destructrices nécessitent une friction supplémentaire : un libellé clair (« Delete project »), une étape de confirmation et une sortie sûre (« Cancel »).
Les contrôles désactivés ne doivent pas ressembler à des bugs. N'utilisez le désactivé que quand une action ne peut vraiment pas être exécutée, et expliquez pourquoi près du contrôle. Un texte d'aide vaut mieux qu'un tooltip que les utilisateurs mobiles ne voient jamais. Si l'utilisateur peut corriger, dites comment (« Add a payment method to enable Checkout »). S'il ne peut pas, dites quand cela se débloquera (« Available after approval »).
Choisissez un pattern de chargement par contexte et conservez-le sur les deux plateformes :
Les erreurs doivent être spécifiques, calmes et récupérables. Placez le message près du problème quand c'est possible (niveau champ). Sinon, utilisez une bannière ou une boîte de dialogue avec une seule action de récupération claire : « Try again », « Edit details » ou « Contact support ». Évitez de blâmer l'utilisateur.
Les états vides fonctionnent mieux avec un template répétable : un titre court, une phrase d'orientation et une action primaire unique qui correspond à ce que l'utilisateur attend de faire ensuite. Exemple : dans un portail client construit avec AppMaster, un onglet « Invoices » vide peut afficher « No invoices yet » avec « Create invoice » comme CTA, en gardant la même formulation et le même comportement sur web et mobile.
Deux écrans peuvent se ressembler et pourtant donner une sensation différente. Le comportement est ce que les utilisateurs remarquent en premier : ce qui se passe quand ils tapent deux fois, comment les erreurs apparaissent, si « retour » les ramène à l'endroit attendu. Votre checklist de parité doit couvrir les règles d'interaction, pas seulement les couleurs et les polices.
Écrivez une vérité unique pour chaque composant, puis mappez-la aux patterns de chaque plateforme sans changer le résultat.
Imaginez un portail client où les utilisateurs cherchent des factures, ouvrent le détail et paient. Sur mobile, un double-tap rapide sur « Pay » peut créer deux prélèvements si vous affichez un spinner mais ne bloquez pas l'action. Sur le web, appuyer sur Entrée peut soumettre même quand un champ est invalide.
Si vous construisez ceci dans AppMaster, définissez les mêmes règles dans votre logique Business Process (une seule requête de paiement en cours, déclencheurs de validation cohérents) et alignez les comportements UI dans les builders web et mobile.
Décidez une fois, puis vérifiez à chaque release : taper deux fois, soumettre avec des erreurs, rafraîchir, revenir en arrière, effacer la recherche.
Les revues de parité fonctionnent mieux comme un rituel répétable. L'objectif est d'attraper les « même fonctionnalité, expérience différente » avant les utilisateurs.
Commencez par choisir un ensemble de comparaison côte à côte : connexion, recherche, vue détail, soumission de formulaire et paramètres. Utilisez les mêmes données de test sur web et mobile pour comparer le comportement, pas le contenu.
Exécutez la revue dans un ordre cohérent :
Une fiche d'évaluation accélère les décisions. Pour chaque écran ou composant, marquez-le : match (même intention et comportement, seules les différences natives), différence acceptable (UI différente, même résultat, documentée) ou mismatch (change le sens, ajoute des étapes ou enfreint une règle).
Quand vous loggez une divergence, incluez deux captures d'écran, la règle exacte enfreinte (par ex. « placement action primaire » ou « ton état vide ») et l'impact utilisateur en une phrase. Si vous travaillez avec AppMaster où le web et le natif peuvent partager la logique, notez si le problème vient d'un réglage du builder UI, d'une règle de composant partagé ou du process lui-même.
Soyez prêt à corriger aussi les règles. Si la même « divergence » réapparaît, votre guideline est probablement floue ou irréaliste. Mettez à jour le système au lieu de patcher les écrans un par un.
La plupart des problèmes de parité ne sont pas de grandes décisions. Ce sont de petits changements qui glissent pendant l'implémentation, la correction de bugs et les ajustements de dernière minute. Une checklist aide, mais seulement si vous savez où la dérive commence.
La dérive de copy est classique. Le web peut afficher « Save changes » alors que le mobile dit « Update », alors qu'ils font la même chose. Les utilisateurs le ressentent comme une friction, surtout lors des réinitialisations de mot de passe, des modifications de profil et des confirmations de paiement.
La dérive d'espacement est plus discrète. Quelqu'un ajoute 6px de padding pour corriger un écran, et ce one-off se propage. Après quelques sprints, le layout web paraît aéré tandis que la version mobile est serrée, même si les deux sont supposés « utiliser le même design ».
Les écarts d'état causent le plus de confusion. Le web peut montrer des états vides et des messages d'erreur clairs, tandis que le mobile se retrouve parfois sur une liste vide, un spinner sans fin ou une erreur silencieuse. Cela arrive souvent quand les états sont gérés à des endroits différents (frontend web vs logique de vue native).
Pendant les revues, surveillez :
Un exemple simple : dans un portail client, le web affiche « No invoices yet » avec un indice et un bouton pour ajouter un moyen de paiement, mais le mobile montre une liste vide. La correction n'est pas un coup de polish. C'est de se mettre d'accord sur le contenu exact de l'état vide et le comportement attendu du bouton, puis de l'appliquer partout.
Même si vous construisez web et natif dans AppMaster, la parité a toujours besoin de règles pour le texte, les tokens d'espacement et la gestion des états afin que chaque écran ne devienne pas sa propre exception.
Une passe rapide de parité attrape ce que les utilisateurs remarquent en premier : du texte qui sonne faux, des boutons qui se comportent différemment et des écrans qui semblent inachevés.
Gardez un écran de référence ouvert sur le web et sur un téléphone. Choisissez votre flux le plus utilisé (login, recherche, checkout, formulaire), puis faites un scan rapide :
Si quelque chose échoue, posez-vous une question : « L'utilisateur aurait-il l'impression d'avoir changé de produit ? » Corrigez la plus grosse divergence en premier.
Exemple : dans un portail client construit avec AppMaster, vous pouvez voir le même formulaire sur web et natif, mais la version mobile permet de taper « Submit » deux fois sur un réseau lent. Ajoutez un état de chargement clair et désactivez le bouton jusqu'au retour de la requête pour aligner les comportements et éviter les doublons.
Imaginez un portail client simple avec trois écrans : Login, Profile et une liste Orders. L'app web est utilisée sur ordinateur par des agents support. L'app mobile est utilisée par les clients en déplacement. Vous voulez le même flux et le même sens partout, même si les détails UI diffèrent.
Une divergence fréquente apparaît quand un client n'a encore aucune commande. Sur le web, la page Orders peut montrer un état vide convivial avec une icône, un court message et un bouton primaire « Browse products ». Sur mobile, le même écran finit parfois par une liste vide sans indication. Les utilisateurs pensent que l'app est cassée.
La correction consiste à traiter la parité comme des règles, pas comme une devinette visuelle. Voici comment appliquer ces règles :
Le comportement est là où la parité casse le plus, donc définissez-le explicitement :
Le résultat compte : les utilisateurs comprennent ce qui se passe et que faire ensuite. L'UI respecte chaque plateforme (safe areas, comportement clavier, hover vs tap), mais le portail donne l'impression d'être un seul produit cohérent.
La parité est facile à bien faire une fois et facile à perdre quand le produit évolue. Les nouvelles fonctionnalités, les corrections rapides et les demandes spécifiques à une plateforme s'accumulent. L'objectif est de faire de la « cohérence » le chemin par défaut.
Traitez votre checklist comme un document vivant. Après chaque release, capturez ce qui a changé et ce qui vous a surpris. Si un écran est sorti avec un état vide différent sur mobile, transformez cela en règle ou en exemple pour que ça ne se reproduise pas.
Plus vous réutilisez, moins vous devez redécider. Construisez un petit ensemble de composants réutilisables et de templates de pages pour les patterns communs : écrans de liste, écrans de détail, formulaires et vues « no results ». Gardez une source de vérité pour les copies communes (libellés de boutons, messages d'état vide) pour éviter que web et mobile développent des tons différents.
Une routine simple aide les équipes à rester honnêtes :
Quels que soient vos outils, visez des tokens partagés, des templates partagés et des règles de comportement partagées. Si vous utilisez AppMaster, traitez vos tokens et patterns UI réutilisables comme des assets partagés entre les builders web et mobile, et conservez la logique clé dans le Business Process Editor. Ainsi, la parité est soutenue par la façon dont le produit est construit, pas imposée par des revues de dernière minute.
Si vous voulez que cela dure, prenez une fonctionnalité à venir et ajoutez des vérifications de parité à sa définition de done. C'est une façon simple de transformer « rester cohérent » en tâche vérifiable par l'équipe.
What does “UI parity” actually mean for web and native apps?La parité UI signifie que les utilisateurs peuvent passer de votre application web à votre application mobile native sans réapprendre le fonctionnement des écrans clés. La formulation, la hiérarchie, les états et les résultats doivent correspondre, même si des détails natifs comme les safe areas ou la navigation système diffèrent.
What should match exactly between web and mobile?Commencez par tout ce qui touche à la compréhension et à la confiance : les libellés d'action, l'emplacement des actions principales, les mises en page des écrans clés, les états (chargement/erreur/vide/désactivé) et le comportement des composants principaux. Si une différence change ce que l'utilisateur s'attend à obtenir, elle doit être cohérente.
What’s okay to let differ across platforms without breaking parity?Laissez s'adapter le confort propre à chaque plateforme, mais conservez les mêmes résultats. Les polices peuvent être natives (system), l'espacement peut tenir compte des safe areas, et la navigation peut suivre les conventions iOS/Android, tant que l'utilisateur reconnaît l'écran, l'action principale et le résultat.
How do we set a shared baseline before comparing screens?Choisissez une source de vérité et explicitez-la. Rédigez une baseline courte pour la typographie, l'espacement, les rôles de couleur, les composants approuvés et les modèles d'états, puis traitez les modifications comme des règles versionnées plutôt que des ajustements ponctuels.
What typography decisions prevent “same screen, different feel”?Utilisez un petit jeu de tokens que personne n'a besoin d'inventer à nouveau. Définissez une échelle typographique cohérente, précisez comment le texte se coupe ou se tronque, et imposez des tailles minimales lisibles sur mobile pour que les titres longs, les valeurs de tableau et les erreurs de formulaire se comportent de façon prévisible partout.
How do we keep spacing consistent, especially with mobile safe areas?Adoptez une seule échelle d'espacement pour toutes les plateformes et évitez les marges “juste pour cette fois”. Définissez le padding par défaut des écrans, les écarts entre éléments liés vs sections, et des règles claires pour les safe areas afin que le contenu ne se retrouve jamais sous l'UI système ni hors de portée.
Which screen states usually cause parity issues (loading, error, empty, disabled)?Standardisez les templates d'états plutôt que de les créer au coup par coup. Utilisez un positionnement et un ton cohérents pour les indicateurs de chargement, les erreurs de champ, les messages d'écran vide et les explications des contrôles désactivés afin qu'aucune plateforme ne semble cassée ou incomplète quand on n'est pas dans le chemin heureux.
What component behaviors should we define to avoid mismatched interactions?Rédigez des règles d'interaction, pas seulement des visuels. Décidez comment éviter les double-soumissions, quand la validation se déclenche, ce que fait le retour arrière, comment fonctionne l'actualisation et comment la recherche réinitialise les résultats pour que les taps, les actions clavier et la navigation donnent les mêmes résultats sur web et mobile.
What’s a simple process for running a parity review before release?Faites une courte vérification côte à côte sur un ensemble fixe de flux principaux en utilisant les mêmes données de test. Vérifiez d'abord les libellés et les résultats, puis les états et le comportement, et enfin la finition visuelle ; enregistrez les divergences avec la règle enfreinte et l'impact utilisateur pour que les corrections aillent vite.
How can AppMaster help maintain parity as the product grows?Mutualisez les tokens et les patterns réutilisables, et centralisez la logique importante. Dans AppMaster, alignez les tokens de design et les composants réutilisables entre les builders web et mobile, et gardez la logique critique dans le Business Process Editor pour que les corrections s'appliquent partout.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
