Aller au contenu
Blaze

Mobile · Monaco

Une application mobile commence par un geste utile.

Une saisie qui peut reprendre

Schéma du parcours proposé, à construire et vérifier. Aucun dossier client ni service de production n’est représenté.

  1. Brouillon

    Commencer un exemple synthétique sur téléphone

  2. Interruption

    Indiquer ce qui reste à envoyer

  3. Reprise

    Vérifier session et version du document

  4. Confirmation

    Afficher l’état réellement reçu par le serveur

Photographier une pièce, consulter une information pendant une visite ou reprendre une saisie interrompue : le mobile doit servir une situation précise. Blaze propose de concevoir ce prolongement de votre système avec les mêmes règles métier et une attention particulière aux appareils personnels. Cette page décrit le périmètre à étudier ; elle ne présente pas une application client déjà publiée.

Observer le moment d’usage

Une application se justifie lorsque le contexte d’usage demande une capacité que le site mobile ne fournit pas correctement. Il faut observer le geste : ce que l’utilisateur tient en main, ce qu’il peut lire, le temps disponible et la qualité du réseau. Une application supplémentaire impose aussi une installation, des mises à jour et un accompagnement.

Le premier essai peut donc être un parcours web amélioré, comparé à un prototype mobile synthétique. On vérifie la taille des commandes, les messages d’erreur et la reprise après interruption. Le choix ne dépend pas d’une proportion supposée d’utilisateurs sur iPhone, mais des appareils effectivement concernés et des fonctionnalités nécessaires.

Garder des règles métier cohérentes

Une interface native iOS et une base multiplateforme présentent des arbitrages différents : intégration au système, maintenance, couverture des appareils et disponibilité des compétences. Aucun choix ne garantit à lui seul fluidité ou économie. Le cadrage doit tester les fonctions sensibles, par exemple la capture documentaire, avant de retenir une technologie.

Les règles d’autorisation doivent rester appliquées côté serveur, même si l’application masque les opérations interdites. Une session expirée, un changement de rôle et un appareil partagé font partie du parcours. Le téléphone ne doit pas devenir une seconde base métier dont les décisions divergent de celles de la plateforme.

Décider ce qui reste sur l’appareil

Un appareil peut être perdu, prêté ou compromis. Il faut déterminer quelles informations peuvent y être conservées, pendant combien de temps et sous quelles protections. La biométrie peut faciliter le déverrouillage local ; elle ne remplace pas la vérification des droits côté serveur. Révoquer une session ne garantit pas l’effacement immédiat d’un appareil déconnecté.

Le mode hors connexion demande un travail spécifique : brouillons autorisés, chiffrement local, conflits de synchronisation et comportement après une révocation. Des documents personnels ne doivent pas être mis en cache par défaut. Les essais synthétiques doivent reproduire une coupure pendant l’envoi, une pièce volumineuse et deux modifications concurrentes.

Préparer distribution et exploitation

La publication peut être préparée sous le compte développeur de l’organisation, selon les droits et les contrats définis. Elle implique des fiches, des captures, des déclarations de confidentialité et la revue des magasins concernés. Leur acceptation et leur calendrier ne sont pas sous le contrôle de Blaze ; une soumission n’est pas une promesse de disponibilité.

L’exploitation doit prévoir les versions encore utilisées, les dépendances de sécurité et les évolutions des systèmes mobiles. Une ancienne application peut rester installée après une mise à jour du serveur. La compatibilité, le retrait d’une fonction et le support utilisateur doivent donc être définis avant la mise en service, avec une procédure réaliste pour les données non synchronisées.

Examiner le périmètre

Proposition de service

Périmètre de service proposé

Découvrez comment nous choisissons les fonctions mobiles utiles et concevons le parcours, de l’écran aux essais et à la distribution.

Consulter la présentation

Texte revu le

Questions fréquentes

Combien coûte une application mobile par rapport à la plateforme web ?
Le coût dépend des gestes à prendre en charge, des systèmes visés, des intégrations et du support attendu. Réutiliser un serveur existant peut réduire certains travaux, mais ne supprime pas les essais sur appareils ni les contraintes de publication. Le devis suit ce périmètre.
Faut-il une application pour iOS et pour Android ?
La réponse vient des utilisateurs et de leurs appareils, pas d’une hypothèse sur la clientèle monégasque. Un parc connu peut permettre une première cible restreinte ; une clientèle ouverte demande une étude plus large. Cette décision doit être écrite avec les limites de prise en charge.
L'application fonctionne-t-elle sans connexion ?
Seulement si ce fonctionnement fait partie du périmètre et a été testé. Il faut préciser les informations disponibles, les actions interdites et la résolution des conflits au retour du réseau. Une page rapide sur réseau faible n’est pas, à elle seule, une application hors connexion.
Comment se passe la validation par Apple et Google ?
Le projet doit préparer les éléments demandés et prévoir les corrections éventuelles après examen. Les comptes, les conditions de distribution et les responsabilités sont définis avec vous. Aucun délai d’approbation fixe ni résultat favorable des magasins n’est annoncé avant leur propre décision.

Poursuivre la lecture

Définir le bon périmètre

Un parcours, ses utilisateurs et les informations nécessaires : le point de départ d’un projet précis.

Contacter Blaze