Application mobile sur mesure pour les entreprises en France et en Belgique

Flutter et comportements propres à chaque plateforme

Le développement d’une application mobile distingue la conception commune des comportements propres à chaque plateforme. Flutter permet de partager le code entre iOS et Android ; l’autorisation des notifications, le geste de retour, le clavier, la sélection de fichiers et l’exécution en arrière-plan restent toutefois à examiner séparément. Le choix technologique dépend des tâches réellement effectuées. Lire un document avec la caméra et maintenir une connexion Bluetooth permanente ne répondent pas aux mêmes exigences. La disponibilité d’une extension ne signifie pas que le comportement attendu a été validé sur les appareils ciblés.

Développement spécifique à la plateforme

Un développement distinct en Swift et en Kotlin peut être envisagé pour les projets qui sollicitent fortement le matériel. Avec Flutter, les parties qui le nécessitent peuvent également être écrites dans le code propre à la plateforme. Ce choix doit être expliqué en tenant compte de la charge de maintenance, des évolutions des systèmes d’exploitation et des dépendances aux extensions. Un prototype qui fonctionne sur un téléphone ne représente pas l’ensemble des appareils visés. Les versions prises en charge, le périmètre des téléphones et tablettes, l’orientation de l’écran et les besoins d’accessibilité sont consignés dès le départ dans le cahier des charges.

Recette sur appareils

Les critères de recette comprennent le maintien des boutons à l’écran lorsque la taille du texte augmente, la lecture des champs dans le bon ordre par le lecteur d’écran et la possibilité de terminer une opération avec le clavier ouvert. Lorsque la connexion est faible, l’application affiche des états de chargement, d’erreur et de nouvelle tentative plutôt qu’un écran vide. Si l’utilisateur passe à une autre application pendant le paiement ou si le système d’exploitation arrête le processus, la tâche peut rester inachevée. La réouverture de l’écran ne doit pas créer une deuxième opération par inadvertance.

La durée de session et la visibilité des écrans sensibles sont définies selon le contexte d’utilisation. La révocation de l’accès sur un appareil perdu, l’effacement des données locales du précédent utilisateur lors d’un changement de compte et la vérification des droits d’accès à la réouverture de l’application sont des points importants. La recette ne porte pas seulement sur une connexion réussie : elle couvre aussi les sessions expirées et les droits d’accès modifiés. La distinction entre ce que l’utilisateur voit à l’écran et l’opération que le serveur accepte est au cœur de la conception.

Application distribuée sur les stores ou PWA ?

Le besoin d’un canal mobile ne signifie pas que chaque visiteur doit installer une application. Si le premier contact passe par une recherche, que l’utilisation reste occasionnelle et que l’objectif consiste surtout à consulter des informations, un site web adapté aux mobiles peut convenir. Des sessions régulières, l’exploitation des capacités de l’appareil et des tâches de terrain quotidiennes peuvent, en revanche, justifier une application distribuée sur les stores. Le choix repose sur la valeur qui justifie de demander une installation à l’utilisateur.

Une PWA est une application web accessible dans un navigateur et qui peut, lorsque les conditions le permettent, être ajoutée à l’écran d’accueil. Son ouverture hors connexion, ses notifications et ses tâches en arrière-plan dépendent du navigateur et du système d’exploitation. Il ne faut pas présumer qu’elle offre, sur tous les appareils, l’ensemble des capacités d’une application distribuée sur les stores. La tâche attendue est testée sur les appareils ciblés ; la simplicité d’une distribution par adresse web est mise en balance avec les limites du navigateur.

Le fonctionnement hors connexion n’est pas une simple étiquette : il correspond à un périmètre précis de tâches. Consulter un catalogue et enregistrer une livraison n’exposent pas aux mêmes risques. La date de dernière mise à jour doit être visible ; l’utilisateur doit comprendre qu’un enregistrement créé localement n’a pas encore été accepté par le serveur. Au rétablissement de la connexion, comment traiter un produit supprimé, un droit d’accès modifié ou une tâche réaffectée à un autre salarié ? La fonction hors connexion ne peut pas être considérée comme achevée tant que ces décisions ne sont pas documentées.

La fréquence d’utilisation de l’application entre également en compte. Pour une opération effectuée une seule fois, la gestion d’un compte de store et la charge des mises à jour régulières peuvent être superflues. À l’inverse, pour des tâches récurrentes telles qu’un inventaire d’entrepôt ou une intervention de maintenance, la caméra et le stockage local de l’appareil peuvent avoir une réelle importance. Le choix repose sur la tâche de l’utilisateur, et non sur la technologie du moment.

Des règles différentes pour les commandes, les rendez-vous et les interventions terrain

Applications d’achat en ligne

Dans une application mobile d’achat en ligne, afficher le panier ne suffit pas : il faut aussi le valider avec les prix à jour. Lorsque l’utilisateur ouvre le panier d’une session précédente, les stocks et les conditions de livraison peuvent avoir changé. Le montant est calculé côté serveur et les modifications sont expliquées. Au retour du paiement, il ne faut pas supposer que l’application sera restée ouverte. Le résultat est rapproché de la confirmation du prestataire de paiement. La même commande peut être gérée avec votre solution e-commerce, mais le comportement des écrans lors des mises à jour et des erreurs doit être défini.

Applications de rendez-vous

Pour les cliniques et les entreprises de location de véhicules, une liste de disponibilités ne constitue pas une réservation confirmée. Le blocage temporaire de la ressource, son expiration et le résultat du paiement sont présentés comme des états distincts. La non-réception d’une notification de rappel n’invalide pas la réservation. L’annulation et le report suivent les règles de l’entreprise ; l’application les présente à l’utilisateur avant qu’il prenne sa décision.

Interventions terrain et opérations internes

Lors d’une intervention ou d’une tâche en entrepôt, les photos, signatures, codes-barres et données de localisation sont rattachés à la fiche de travail. Si l’autorisation de localisation est refusée, une autre méthode est-elle possible ou la tâche doit-elle s’arrêter ? Le suivi permanent du salarié n’est pas présumé. La taille des photos et leur ordre d’envoi sont importants lorsque la connexion est faible. Un transfert de fichiers inachevé ne doit pas conduire à afficher la tâche comme terminée par erreur.

Les ordres de travail hors connexion peuvent être conservés dans une file locale. Si le serveur a annulé la tâche ou l’a attribuée à une autre personne, un conflit apparaît avec l’enregistrement présent sur l’appareil. Il faut définir les champs qui font foi et les situations qui nécessitent un examen humain. Le renvoi d’une même tâche ne doit pas créer un deuxième enregistrement de livraison. L’utilisateur doit pouvoir distinguer les enregistrements en attente de ceux qui ont été refusés.

Une distribution interne n’équivaut pas à une publication accessible à tous sur les stores. Les conditions en vigueur des options proposées par Apple et Google, le type de compte et les utilisateurs visés sont examinés. La formation se déroule aussi sur appareil : le salarié apprend non seulement le nom des écrans, mais également la conduite à tenir en cas de perte de connexion, de changement d’autorisation ou de réouverture d’une tâche. L’équipe opérationnelle peut ainsi éviter de considérer à tort des opérations en attente comme terminées.

API, notifications et cycle de vie des versions de l’application

Le client mobile ne se connecte pas directement à la base de données ; il effectue les opérations métier par une API qui contrôle les autorisations. Côté serveur, Laravel et MySQL permettent de gérer l’accès aux enregistrements et les règles métier. La durée de validité des informations d’accès stockées sur le téléphone, leur renouvellement et leur révocation en cas de perte de l’appareil sont définis lors de la conception. L’écran de connexion n’est pas l’unique barrière de sécurité : chaque requête doit disposer des droits nécessaires pour l’opération concernée.

Lorsqu’une nouvelle version est publiée, tous les utilisateurs ne la mettent pas à jour en même temps. Une modification de l’API doit également tenir compte des anciens clients. Supprimer un champ, renommer un état ou ajouter une information obligatoire peut empêcher les versions installées de fonctionner. Les versions prises en charge, les conditions d’une mise à jour obligatoire et le message à afficher sont définis. Une modification du contenu est distinguée d’une modification de la version publiée de l’application.

Dans le service de notification, le jeton de l’appareil peut changer, l’utilisateur peut se déconnecter de son compte ou désactiver ses autorisations. Lorsqu’il touche une notification, l’écran ouvert vérifie à nouveau les droits d’accès. Un message général adapté peut remplacer l’affichage d’informations sensibles sur l’écran verrouillé. Les notifications transactionnelles sont examinées séparément des messages marketing. L’envoi d’une notification ne signifie pas qu’elle a été reçue ou lue.

Les règles spécifiques sont étudiées dans le cadre du développement de logiciels sur mesure, et les services externes dans celui de nos solutions d’intégration et d’interconnexion. Les projets web présentés sur la page de nos réalisations peuvent illustrer des domaines d’utilisation ; ils ne sont pas présentés comme la preuve d’applications mobiles publiées sur les stores. La recette mobile repose sur les tâches exécutées sur de vrais appareils, les scénarios d’autorisation et les résultats des transitions entre versions.

Les rapports d’erreur ne doivent pas collecter inutilement des données utilisateur. Les journaux de plantage, l’identifiant de l’opération et les informations de version permettent de rechercher l’origine du problème ; les valeurs secrètes de session ne sont pas enregistrées. Le traitement des données par les outils de suivi doit être cohérent avec les déclarations de confidentialité publiées sur les stores. Les erreurs du serveur et celles de l’application sont diagnostiquées séparément ; le temps d’attente d’une réponse réseau ne doit pas être confondu avec le coût de rendu de l’interface.