Quels écrans devraient être prioritaires sur mobile ? Une liste de décision simple

Ce que « mobile-first » signifie pour les écrans de travail

Mobile-first signifie que vous concevez l’écran pour téléphone en premier, puis vous l’adaptez pour tablette et desktop. La version téléphone n’est pas une « page desktop réduite ». C’est la version principale, pensée pour un petit écran, une saisie tactile et des sessions courtes.

Pour les écrans de travail réels, l’objectif est simple : aider quelqu’un à terminer une tâche plus vite avec moins d’erreurs. Quand un écran correspond à la façon dont les gens travaillent réellement, vous obtenez moins de « je le ferai plus tard », moins de champs manquants et moins d’allers-retours avec le bureau.

Mobile-first suppose aussi une réalité désordonnée. Les gens se tiennent debout, marchent, portent des gants, tiennent un café ou jonglent avec du matériel. L’attention est partagée. Ils ont parfois une seule main de libre. Le signal peut être faible. Un écran mobile-first respecte cela en gardant les actions évidentes, en réduisant la saisie et en rendant l’étape suivante difficile à manquer.

Il ne s’agit pas de repenser tout votre produit. Il s’agit de décider des priorités : quels écrans doivent très bien fonctionner sur téléphone parce qu’ils ont lieu sur le terrain, et lesquels peuvent être desktop-first parce qu’ils se font à un bureau.

Une façon rapide de le voir : si une tâche se fait sur site (check-ins, prise de photos, mises à jour rapides), le téléphone est généralement le vrai appareil. Si une tâche demande une longue concentration (reporting, modifications en masse, configuration approfondie), le téléphone est souvent seulement un secours.

Une manière simple de trier les écrans avant de débattre de l’UI

Avant de débattre des mises en page, triez vos écrans selon ce que les gens essaient d’accomplir. La plupart des apps ont la même poignée de types d’écrans, même si les étiquettes changent :

• Capture : ajouter des infos rapidement (check-ins, photos, notes)
• Revue : lire et confirmer (tâches du jour, profil client)
• Gestion : modifier de nombreux éléments (approbations, files, plannings)
• Configuration : définir règles et options (templates, rôles, paramètres)
• Reporting : analyser (totaux, tendances, exports)

Ensuite, utilisez une séparation qui règle la plupart des débats : « sur le terrain » vs « au bureau ». Sur le terrain signifie généralement debout, en marche, gants, signal faible, une main, attention courte. Au bureau signifie grand écran, internet stable, sessions longues et plus de tolérance pour des contrôles complexes.

Ajoutez une métrique : le temps pour agir. Demandez-vous : « À quelle vitesse la personne doit terminer cet écran pour que le travail avance ? » Si la tâche bloque à moins d’être faite en 10 à 30 secondes, c’est un bon candidat pour le téléphone en priorité. Si elle peut attendre, elle peut être desktop-first ou partagée.

Règle pratique : faites du téléphone le cœur pour tout ce qui est fréquent, urgent et fait loin d’un bureau. Traitez le desktop comme un support pour le même flux, pas comme un produit séparé.

Par exemple, un technicien peut effectuer un check-in en deux tapes sur un téléphone (temps : 5 secondes), joindre une photo rapide et ajouter une note courte. Plus tard, un superviseur consulte l’historique complet et corrige les détails sur desktop.

Si vous construisez dans un outil comme AppMaster, cette idée de « cœur mobile, support desktop » se traduit bien : gardez l’écran mobile focalisé sur le plus petit ensemble d’entrées et réservez l’édition en masse et la configuration pour le web.

La liste de décision : signes qu’un écran doit être mobile-first

Quand on demande quels écrans doivent être mobile-first, la réponse la plus simple est : ceux qui se passent dans le monde réel, pas au bureau. Si une tâche se fait en mouvement, dans un endroit bruyant ou sous pression temporelle, le téléphone est généralement l’ordinateur par défaut.

Utilisez cette liste de décision. Vous n’avez pas besoin que tous les points correspondent. Si 2 à 3 correspondent, traitez l’écran comme mobile-first et concevez-le pour une utilisation à une main, des cibles de tap larges et des flux courts.

• Il est utilisé en position debout, en marche, en transportant quelque chose ou en portant des gants.
• Il s’appuie sur le matériel du téléphone comme la caméra, le GPS, le scan de code-barres/QR ou les notifications push.
• Il doit fonctionner malgré une connexion intermittente, des moments hors-ligne ou une synchronisation retardée.
• La plupart du temps, il doit être terminé en moins de 60 secondes.
• C’est un travail « dans l’instant » où les retards causent des erreurs (par exemple, confirmer une livraison à la porte).

Un contrôle de bon sens : imaginez l’utilisateur tenant une boîte d’une main et le téléphone de l’autre. Si l’écran exige une longue saisie, des contrôles minuscules ou trois pages séparées, il n’est pas prêt.

Exemple concret : un technicien arrive sur site, prend deux photos, ajoute une note courte et appuie sur « Terminer ». C’est un flux mobile-first. L’historique complet du client, un long catalogue de pièces ou un éditeur de rapports détaillé peuvent toujours exister, mais appartiennent généralement à des écrans desktop-first séparés.

Si vous construisez ces écrans dans AppMaster, visez l’écran de capture le plus petit possible sur mobile, puis laissez le desktop gérer la revue, les éditions et la navigation approfondie.

Exemple 1 : écrans de check-in (rapides, fréquents, en mouvement)

Les check-ins sont une des réponses les plus claires à la question de ce qui doit être mobile-first. On les fait à l’entrée d’un chantier, sur un parking ou en marchant entre les tâches. Ils exigent de la rapidité, pas des options.

Un bon écran de check-in est principalement une grosse action : « Commencer le service » ou « Arrivé sur site ». Ajoutez juste assez de contexte pour que l’enregistrement soit utile : heure capturée automatiquement, position, et une note courte optionnelle comme « Retard 10 min ».

Ce que doit ressentir la version téléphone

La meilleure UI de check-in est difficile à mal utiliser. Utilisez de gros boutons, des étiquettes claires et un état de succès impossible à manquer (par exemple : confirmation plein écran avec le nom du site et l’heure).

Gardez les entrées minimales :

• Une tape principale pour enregistrer l’arrivée
• Position capturée automatiquement, avec un avertissement simple « Localisation désactivée »
• Note optionnelle (une ligne, pas un grand formulaire)
• Une option « Annuler » pendant une courte fenêtre (10–30 secondes)

Cas limites qui comptent

La plupart des problèmes de check-in ne sont pas des problèmes de design mais des problèmes réels. Prévoyez une sélection de site erronée, des check-ins tardifs qui nécessitent une raison et l’absence de signal.

Si le téléphone est hors ligne, enregistrez le check-in localement et affichez « Enregistré, synchronisera à la connexion » pour éviter que les gens tapent cinq fois.

Si vous construisez ça dans AppMaster, c’est un bon cas pour un écran mobile simple soutenu par un workflow qui valide le site, stocke le GPS quand disponible et journalise les exceptions (tard, mauvais site) sans transformer le check-in en formulaire.

Exemple 2 : écrans photo sur site (caméra d’abord, formulaires ensuite)

Les écrans photo sur site sont naturellement mobile-first. Si le travail se fait dans le monde réel, la caméra est l’entrée principale, pas un long formulaire.

Imaginez un gestionnaire immobilier documentant des dégâts d’eau. Il parcourt les pièces, prend 6 à 10 photos, ajoute une brève note comme « tache au plafond près de la ventilation » et envoie avant le rendez-vous suivant. Si l’écran commence par des champs, ils sauteront des étapes, taperont moins ou oublieront des détails.

Un écran photo pensé pour le téléphone doit s’ouvrir sur une action claire : prendre une photo (ou choisir dans la pellicule). Après cela, gardez le formulaire petit et optionnel quand c’est possible. Un modèle fiable : photo d’abord, puis légende, puis une tape pour choisir une catégorie (Dommage, Avancement, Terminé), et seulement ensuite les extras.

Astuces UX qui rendent la capture photo efficace

Quelques détails font une grande différence sur le terrain :

• Par défaut, ouvrir la capture caméra, pas un formulaire vide
• Sauvegarder automatiquement un brouillon après chaque photo et légende
• Rendre la saisie facultative (catégories rapides et invites courtes)
• Autoriser un marquage basique (encercler, flèche, flouter) sans quitter l’écran
• Confirmer clairement le statut d’upload (sauvé, synchronisation, envoyé)

La qualité compte aussi. Si les photos servent de preuve, votre écran doit aider les gens à faire bien sans être strict.

Vérifications légères de qualité

Au lieu de longues règles, utilisez des rappels simples et des garde-fous :

• Exiger des angles clés quand nécessaire (par ex. : « vue large + gros plan »)
• Avertir si un fichier est trop volumineux avant l’upload
• Suggérer une meilleure luminosité si l’image est très sombre
• Inciter à placer un élément d’échelle (pièce, règle, main) pour les dégâts

Si vous construisez cela dans AppMaster, vous pouvez modéliser l’enregistrement photo dans le Data Designer, ajouter la logique de brouillon dans le Business Process Editor et garder l’UI mobile sur les quelques contrôles réellement utilisés sur site.

Exemple 3 : écrans de mise à jour rapide (petites saisies, grand impact)

Les écrans de mise à jour rapide sont un succès classique du mobile-first. Ils servent quand quelqu’un a 10 secondes, pas 10 minutes : un livreur marquant une livraison comme faite, un technicien signalant « bloqué », ou un coordinateur demandant de l’aide entre deux sites.

La clé est de garder l’entrée minime et le résultat clair. Un bon écran de mise à jour rapide contient souvent trois éléments : un statut, une note courte et (optionnel) à qui taguer ou assigner. Si l’écran devient un formulaire complet, les gens le sauteront ou taperont des notes de mauvaise qualité.

Détails UX qui rendent l’écran utilisable sur téléphone

Visez l’utilisation au pouce et des choix à faible effort :

• Boutons de statut larges (Terminé, Bloqué, Besoin d’aide) plutôt qu’un menu déroulant
• Afficher d’abord 3–5 choix récents ou courants
• Limiter la note à une ligne avec un « ajouter des détails » optionnel
• Placer le bouton d’action principal en bas, à portée du pouce
• Confirmer le succès par un message clair et un horodatage visible

Notifications : qui est alerté, et que voient-ils

Une mise à jour rapide n’aide que si elle atteint la bonne personne. Décidez qui doit être notifié pour chaque statut et quel message ils recevront. Par exemple, « Bloqué » peut avertir un superviseur et inclure la courte note, tandis que « Terminé » peut simplement mettre à jour le dossier.

Dans un outil comme AppMaster, vous pouvez associer l’écran à des règles simples dans un flux logique visuel et envoyer des alertes par email/SMS ou Telegram, afin que la mise à jour devienne une action, pas seulement une donnée.

Ce qui doit généralement rester desktop-first (et pourquoi)

Certains écrans fonctionnent mieux sur un grand écran avec clavier et temps de réflexion. Si le travail est lent, minutieux et fait au bureau, le forcer sur un téléphone peut faire scroller, faire manquer des détails et provoquer des erreurs.

Un bon indice est la lecture et la comparaison. Si quelqu’un doit parcourir de longs textes, consulter l’historique ou comparer plusieurs éléments, desktop-first gagne habituellement. Les téléphones sont excellents pour les actions rapides, mais moins pour le contexte côte-à-côte.

Écrans courants généralement desktop-first :

• Tableaux de bord avec multiples graphiques, filtres et tendances
• Plannings et vues de planification (semaine, mois, couverture d’équipe)
• Files d’approbation demandant lecture des détails et pièces jointes
• Modifications en masse (mise à jour de nombreux enregistrements)
• Paramètres admin et configuration complexe

Les approbations provoquent souvent débat. Si les approbations sont routinières et nécessitent une lecture attentive, desktop-first est plus sûr. Mais si une approbation doit être instantanée pour que le travail avance (par ex. : valider un achat d’urgence sur place), cette action spécifique peut appartenir au mobile. L’astuce est de séparer « approuver maintenant » de la revue approfondie.

Règle simple : si un écran exige du contexte côte-à-côte, privilégiez le desktop. Cela inclut comparer deux demandes, consulter un dossier client en lisant un ticket, ou éditer un tableau en se référant à une politique.

Exemple : un manager révise un planning hebdomadaire, voit deux chevauchements, consulte les notes des employés et réaffecte des quarts. Sur téléphone, cela devient un jeu de bascule et de défilement sans fin. Sur desktop, c’est plus rapide et clair.

Si vous décidez quels écrans doivent être mobile-first, commencez par marquer vos écrans de « comparaison et planification » comme desktop-first, puis extrayez une ou deux actions qui doivent vraiment se faire en déplacement. Dans AppMaster, cela devient souvent un petit écran mobile pour l’action urgente et un écran web plus complet pour la revue.

Comment alléger un écran pour qu’il marche vraiment sur téléphone

Les écrans mobiles punissent le désordre. Si vous voulez que l’app paraisse rapide, traitez chaque champ, bouton et phrase comme s’il devait gagner sa place.

Commencez par décider ce que l’utilisateur doit finir en moins de 30 secondes. Cette question clarifie souvent ce qui appartient au mobile et ce que doit contenir la version téléphone.

Coupez jusqu’au parcours indispensable

Séparez ce qui est nécessaire pour terminer l’action de ce qui est juste utile plus tard. Pour un check-in, le parcours indispensable peut être : position, statut et une note. « Détails équipement » et « tâches de suivi » peuvent attendre.

Un moyen rapide de repérer le gonflement : si ce champ vide est accepté, il ne devrait probablement pas être sur la première vue.

Gardez simple :

• Conserver seulement 3–5 entrées qui finissent la tâche
• Mettre le reste derrière un « Ajouter des détails »
• Remplacer un paragraphe d’aide par un court indice
• Supprimer les écrans de confirmation redondants sauf risque réel

Faites faire le travail au téléphone

Plutôt que de forcer la saisie longue, utilisez des choix et des valeurs par défaut intelligentes. Transformez le texte répété en templates, sélecteurs et réponses rapides comme « Arrivé », « Retard 15 min », ou « Nécessite suivi ». Quand une valeur peut être devinée en toute sécurité, pré-remplissez-la. Si l’utilisateur la modifie une fois, mémorisez ce choix.

La divulgation progressive garde l’écran calme. Montrez la caméra et une légende requise pour les photos sur site, puis révélez les tags, catégories et notes optionnelles après la prise.

Si vous construisez dans AppMaster, vous pouvez modéliser les champs « obligatoires » vs « optionnels » dans le Data Designer et garder le premier écran minimal, puis utiliser une seconde étape pour les champs avancés sans dupliquer la logique.

Pièges fréquents qui rendent les écrans mobiles frustrants

La plupart des « mauvais écrans mobiles » échouent pour les mêmes raisons : ils collent des habitudes desktop sur un téléphone et exigent la patience des gens sur le terrain.

La manière la plus rapide de ruiner un écran phone-first est d’y entasser un grand formulaire desktop. Les utilisateurs finissent par défiler, perdre leur place et manquer des champs requis. Sur mobile, visez moins de champs par étape, des valeurs par défaut intelligentes et seulement les champs nécessaires au moment.

Un autre problème fréquent est de cacher l’action principale pour « gagner de la place ». Si l’objectif de l’écran est Check in, Upload photo ou Save update, le bouton doit être évident et facile à atteindre d’un pouce. Un menu est pour les actions secondaires, pas pour la raison principale d’être de l’écran.

Le travail sur le terrain révèle aussi la douleur de l’authentification. Si un technicien doit se reconnecter souvent (ou retaper un code) entre de courtes tâches, il retardera les mises à jour ou notera à part. Utilisez des sessions plus longues quand c’est sûr et réauthentifiez seulement pour les actions vraiment sensibles.

Cinq pièges à surveiller et une bonne première correction :

• Formulaires taille desktop : découpez-les en étapes courtes et pré-remplissez ce que vous savez déjà.
• Actions principales cachées : gardez l’action principale visible en permanence.
• Ré-authentifications fréquentes : réduisez les interruptions pendant un quart et vérifiez l’identité seulement si nécessaire.
• Pas de signal « fait » : affichez un message de succès clair et mettez à jour l’état de l’écran pour éviter les envois doublons.
• Pas de plan de retry : gérez le signal faible avec des files d’attente et un statut « envoi / envoyé / échoué » clairement affiché.

Exemple : quelqu’un envoie des photos depuis une cave avec mauvaise réception. Si l’app n’affiche pas la progression ou les nouvelles tentatives automatiques, il appuiera « Soumettre » trois fois puis appellera le support. Même un simple statut plus une reprise automatique évitent les doublons et la frustration.

Si vous construisez dans AppMaster, concevez l’état de succès comme partie intégrante du flux (pas une réflexion après coup) et prévoyez l’hors-ligne ou la connectivité instable dès le début.

Une checklist rapide pour valider un écran mobile-first

Quand vous décidez lesquels écrans doivent être mobile-first, ne devinez pas. Faites un rapide contrôle « réalité téléphone » sur un vrai appareil, à une main, dans un environnement un peu gênant (debout, en marche, forte lumière). Si l’écran survit, il est probablement un bon candidat mobile-first.

Utilisez cette checklist courte avant la finition :

• Terminer en 60 s : Un nouvel utilisateur peut-il accomplir la tâche principale en moins de 60 secondes sans lire d’aide ? Sinon, supprimez des étapes, scindez le flux ou pré-remplissez plus de champs.
• Atteinte à une main : Les actions clés sont-elles accessibles au pouce sans gymnastique ? Placez les actions principales en bas.
• Visibilité extérieure : Reste-t-il lisible en plein soleil ? Vérifiez contraste, taille de police et cibles tactiles.
• Erreurs et reprises sûres : En cas d’erreur (pas de signal, saisie incorrecte, upload raté), le message indique-t-il quoi faire ensuite ? « Réessayer » ne doit pas effacer le travail.
• Résilience du flux de capture : Pour la caméra ou l’upload, montrez la progression, autorisez la mise en arrière-plan et sauvegardez les brouillons.

Test rapide : donnez le téléphone à quelqu’un de nouveau et chronométrez. S’il hésite deux fois de suite, c’est la prochaine correction. Dans AppMaster, validez le flux tôt avec une UI basique et des données réelles avant d’investir dans le polish.

Un scénario simple : journée de travail sur le terrain avec des écrans phone-first

Un superviseur arrive sur le site, café d’une main, téléphone de l’autre. Le premier écran est un check-in : sélectionner le projet, confirmer la position et ajouter une note courte comme « équipe sur site, portail fermé ». Ça prend 15 secondes et c’est important car ça fixe un horodatage fiable.

Dix minutes plus tard, il parcourt le site. L’écran photo pense caméra d’abord, pas formulaire. Il prend trois photos, ajoute une brève étiquette à chacune (« fissure mur nord », « livraison matos ») et sauvegarde. L’app récupère l’heure et le GPS automatiquement, donc pas besoin de taper avec des gants.

Avant de partir, il ouvre un écran de mise à jour rapide : deux bascules et un court champ texte. Il marque « inspection demandée » et écrit « électricien jeudi ». Cette mise à jour déclenche une notification pour l’équipe au bureau, sans forcer le superviseur à rédiger un long rapport sur un petit écran.

Ce qui reste sur le téléphone vs ce qui peut attendre :

• Téléphone maintenant : check-in, photos sur site, mises à jour rapides, notes courtes, confirmations
• Desktop plus tard : descriptions longues, changements de planning multi-équipes, rapports complets, revue des tendances, exportations

La clé est le flux de données. La capture se fait au moment sur le téléphone (rapide, peu de saisie). La revue et le reporting se font plus tard sur desktop, où l’on peut comparer des jours, repérer des tendances et nettoyer la formulation.

En milieu de semaine, quelqu’un demande d’ajouter un champ au flux photo : un simple menu déroulant “Type de problème”. Si vous utilisez une plateforme comme AppMaster, ce changement n’a pas à casser le workflow. Mettez à jour l’écran, régénérez l’app et le superviseur effectue toujours les mêmes trois taps sur site, avec juste un choix rapide en plus.

Étapes suivantes : choisissez vos premiers écrans mobile-first et avancez

Si vous êtes bloqué à débattre, arrêtez de deviner et faites un plan court et testable. Le but n’est pas de tout repenser, mais de choisir quelques écrans qui accélèrent visiblement les personnes en mouvement.

Commencez par lister vos 20 écrans les plus utilisés par jour. N’utilisez pas d’opinions : comptez combien chaque écran est ouvert et par quel rôle.

Faites un premier tri en marquant les écrans utilisés loin d’un bureau (entrepôt, chantier, magasin, voiture) et ceux dépendant du matériel du téléphone comme la caméra, le GPS, le scan ou les notifications. Ces deux signaux indiquent souvent où le mobile compte.

Choisissez 3–5 écrans comme premiers gains mobile-first. Gardez la sélection petite pour pouvoir livrer, apprendre et ajuster.

• Notez vos 20 écrans les plus utilisés et qui les utilise.
• Flaggez ceux utilisés en déplacement et ceux qui requièrent caméra, GPS ou scan.
• Choisissez 3–5 écrans à concevoir mobile-first et définissez ce que « fini » signifie (temps de complétion, taux d’erreur).
• Laissez les écrans desktop-first pour la revue : configuration admin, approbations, audits, reporting.
• PrototypEZ vite les flux, testez avec des utilisateurs réels et révisez.

Un schéma pratique : capture sur téléphone, revue sur desktop. Un intervenant enregistre, prend des photos et poste une mise à jour sur le téléphone. Un superviseur revoit l’historique complet, corrige et exporte un rapport sur desktop.

Si vous voulez tester vite sans vous enfermer dans des décisions précoces, AppMaster (appmaster.io) est une façon no-code de prototyper des workflows complets mobile et web, puis de régénérer du code source réel quand les besoins évoluent. Gardez la première tentative petite : construisez les 3 premiers écrans, testez-les sur un vrai téléphone et mesurez si le travail est plus rapide.