Question 1

Sur quels appareils faut-il tester une application mobile avant de la publier ?

Accepted Answer

Sur trois appareils physiques bien choisis plutôt que sur vingt simulateurs : le modèle le plus répandu chez vos utilisateurs, un appareil ancien de milieu de gamme, et le plus récent. Les simulateurs conviennent au développement mais ne reproduisent ni les performances réelles, ni la caméra, ni le comportement du réseau, ni les stratégies d'économie d'énergie propres à chaque constructeur — qui sont la première cause d'incidents inexplicables sur Android.

Question 2

Faut-il faire tourner l'IA sur le téléphone ou côté serveur dans une application mobile ?

Accepted Answer

Côté serveur par défaut, sur l'appareil pour les cas où la latence, le hors-ligne ou la confidentialité l'imposent. Un traitement local évite l'aller-retour réseau et ne coûte rien à l'usage, mais il alourdit l'application, consomme la batterie et fige le modèle dans une version publiée. Le choix se fait tâche par tâche, pas une fois pour toute l'application.

Question 3

Comment utiliser les notifications push sans faire fuir les utilisateurs d'une application mobile ?

Accepted Answer

En n'envoyant que ce qui concerne personnellement l'utilisateur et appelle une action de sa part. Trois règles gouvernent le reste : ne demander l'autorisation qu'après avoir montré à quoi elle sert, laisser un réglage fin par type de notification plutôt qu'un interrupteur unique, et respecter le fuseau horaire ainsi que les heures de repos. Une autorisation refusée est très difficile à récupérer — la demander au premier lancement est l'erreur la plus coûteuse et la plus fréquente.

Question 4

Que coûte l'entretien d'une application mobile après sa mise en production ?

Accepted Answer

Entre quelques jours et quelques semaines par an et par plateforme, même sans ajouter la moindre fonctionnalité. Ce budget couvre trois obligations subies : les versions annuelles d'iOS et d'Android à tester, les exigences des magasins qui évoluent avec des échéances fermes, et les dépendances techniques qu'il faut suivre pour rester à jour. Une application mobile laissée sans entretien pendant deux ans ne dégrade pas progressivement — elle devient impubliable d'un coup, et la remise à niveau coûte alors bien plus cher que l'entretien évité.

Question 5

Pourquoi les utilisateurs désinstallent-ils une application mobile, et comment l'éviter ?

Accepted Answer

Trois causes dominent : un démarrage trop long, une interface qui saccade, et une consommation de batterie perçue comme anormale. Les deux premières se corrigent en déplaçant le travail hors du démarrage et hors du fil d'affichage. La troisième vient presque toujours de la position en continu, de la synchronisation trop fréquente ou d'un travail en arrière-plan mal borné. Ces trois causes se mesurent avec l'outillage fourni par les plateformes, sur un appareil ancien plutôt que sur le téléphone du développeur.

Question 6

Comment concevoir une application mobile qui fonctionne hors ligne ?

Accepted Answer

En considérant l'appareil comme la source de vérité temporaire et le serveur comme un point de synchronisation, pas l'inverse. Concrètement : une base locale sur le téléphone, une file d'opérations en attente rejouées à la reconnexion, un identifiant généré côté appareil pour ne pas dépendre du serveur, et une règle de résolution de conflits décidée avec le métier. Le hors ligne n'est pas une option qu'on ajoute — c'est une décision d'architecture qui doit être prise au début du projet.

Question 7

Combien de temps et quelles contraintes pour publier une application sur les magasins iOS et Android ?

Accepted Answer

Comptez deux à quatre semaines entre l'application finie et sa disponibilité publique, dont la moitié en préparation administrative. Apple relit chaque version manuellement — de quelques heures à plusieurs jours — et refuse pour des motifs souvent non fonctionnels : formulaire de confidentialité incomplet, connexion imposée sans justification, mécanisme de paiement hors du sien. Google publie plus vite mais impose une validation d'identité et des phases de déploiement progressif. Les comptes développeur, les certificats et les fiches produit doivent être créés au nom de l'entreprise, jamais d'une personne.

Question 8

Faut-il développer une application mobile en natif, en multiplateforme, ou faire un site web mobile ?

Accepted Answer

Un site web responsive suffit si l'usage est occasionnel et ne demande ni fonctionnement hors ligne, ni notifications, ni accès au matériel. Le multiplateforme est le meilleur compromis pour une application métier : une seule base de code pour iOS et Android, avec 80 à 90 % du code partagé. Le natif se justifie quand la performance graphique, l'accès fin au matériel ou l'intégration système sont au cœur du produit — sinon il double le coût de développement et de maintenance.

mobile

Tester une application mobile : sur quels appareils, et comment

L'IA sur mobile : ce qui tourne sur l'appareil, ce qui part au serveur

Notifications push : ce qui marche, et ce qui fait désinstaller

Maintenir une application mobile : le budget qu'on oublie toujours

Performance et batterie : ce qui fait désinstaller une application

Une application mobile qui marche sans réseau : ce que ça change

Publier sur l'App Store et Google Play : ce que personne ne dit avant

Application mobile : natif, multiplateforme ou web ?

Un projet à cadrer ?