Aller au contenu principal

Mobile Quality

Version : 1.0

Statut : Architecture cible

ADR : MOBILE-011

1. Objectif​

La qualité d'une application mobile ne se limite pas à l'absence de bugs.

Pour DMV, la qualité est la capacité de la plateforme à offrir une expérience :

  • fiable ;
  • rapide ;
  • stable ;
  • accessible ;
  • durable.

La qualité constitue une responsabilité transversale de toute l'architecture.

Elle ne doit jamais être considérée comme une phase finale du projet.

2. Principes​

La qualité repose sur cinq principes.

Fiabilité​

Une fonctionnalité doit fonctionner de manière prévisible.

L'utilisateur ne doit jamais avoir à "réessayer plusieurs fois".

Performance​

L'application doit répondre rapidement.

La perception utilisateur est plus importante que la performance théorique.

Robustesse​

Une erreur ne doit jamais provoquer :

  • un crash ;
  • une perte de données ;
  • un blocage de l'application.

Accessibilité​

Toutes les fonctionnalités doivent rester utilisables par le plus grand nombre.

Observabilité​

Un problème doit pouvoir être identifié et compris rapidement.

Une erreur invisible est une erreur impossible à corriger.

3. Performance​

La performance est une fonctionnalité.

Elle est donc conçue dès l'architecture.

Les principaux objectifs sont :

  • ouverture rapide ;
  • navigation fluide ;
  • faible consommation mémoire ;
  • faible consommation batterie.

4. Temps de démarrage​

Objectif :

Application utilisable en quelques secondes.

Le démarrage suit le principe :

Splash

↓

Initialisation minimale

↓

Affichage

↓

Chargements secondaires

L'utilisateur doit pouvoir commencer à utiliser l'application avant que tous les traitements secondaires soient terminés.

5. Fluidité​

L'interface doit rester fluide.

Les opérations longues doivent être :

  • asynchrones ;
  • annulables si possible ;
  • accompagnées d'un indicateur de progression.

Aucun écran ne doit sembler figé.

6. Consommation mémoire​

La plateforme doit surveiller son empreinte mémoire.

Les composants inutilisés doivent être libérés.

Le Cache Engine adapte automatiquement son comportement en cas de pression mémoire.

7. Batterie​

L'application ne doit pas devenir une source importante de consommation.

Les synchronisations sont regroupées.

Les traitements inutiles sont évités.

Les accès GPS continus sont interdits sauf besoin fonctionnel clairement identifié.

8. Réseau​

Les appels API doivent être optimisés.

Principes :

  • éviter les téléchargements redondants ;
  • utiliser le cache lorsque cela est pertinent ;
  • limiter les rafraîchissements automatiques.

9. Résilience​

Une erreur ne doit jamais provoquer un arrêt brutal de l'application.

Chaque erreur doit conduire à un comportement maîtrisé.

Exemples :

Serveur indisponible

↓

Message explicite

↓

Utilisation du cache

↓

Nouvelle tentative automatique

10. Gestion des erreurs​

Toutes les erreurs doivent être classifiées.

Erreurs utilisateur​

Exemple :

champ obligatoire oublié.

Erreurs réseau​

Connexion absente.

Serveur indisponible.

Erreurs métier​

Permission refusée.

Publication inexistante.

Erreurs système​

Crash.

Mémoire insuffisante.

Plugin indisponible.

Chaque catégorie possède une stratégie de traitement spécifique.

11. Crash Reporting​

Tous les crashs doivent être collectés automatiquement.

Les rapports doivent permettre d'identifier :

  • la version ;
  • le système ;
  • le contexte technique ;
  • la pile d'appel.

Aucune donnée personnelle ne doit être transmise.

12. Journalisation​

La plateforme produit des journaux techniques.

Exemples :

  • démarrage ;
  • synchronisation ;
  • erreur réseau ;
  • cache vidé.

Les logs ne doivent jamais contenir :

  • mot de passe ;
  • token ;
  • données personnelles.

13. Analytics​

Les métriques servent à améliorer DMV.

Elles ne servent pas à profiler les utilisateurs.

Exemples de métriques utiles :

  • temps de démarrage ;
  • temps moyen d'ouverture d'une page ;
  • fréquence des crashs ;
  • taux d'échec des synchronisations.

14. Accessibilité​

DMV Mobile doit respecter les recommandations d'accessibilité Android et iOS.

La plateforme doit notamment supporter :

  • VoiceOver ;
  • TalkBack ;
  • tailles de texte dynamiques ;
  • contraste élevé ;
  • navigation clavier lorsque disponible.

L'accessibilité n'est pas une fonctionnalité optionnelle.

15. Compatibilité​

La plateforme doit fonctionner sur un ensemble cohérent d'appareils.

Les versions minimales supportées seront définies dans la stratégie de publication.

Les nouvelles fonctionnalités doivent toujours prévoir une stratégie de repli pour les appareils plus anciens lorsque cela est possible.

16. Tests​

La qualité repose sur plusieurs niveaux de tests.

Tests unitaires​

Validation des composants isolés.

Tests d'intégration​

Validation des échanges entre composants.

Tests fonctionnels​

Validation des parcours utilisateur.

Tests de régression​

Garantie qu'une évolution ne casse pas une fonctionnalité existante.

Tests manuels​

Toujours réalisés avant une publication majeure.

17. CI/CD​

Chaque Pull Request doit exécuter automatiquement :

  • lint ;
  • type checking ;
  • tests unitaires ;
  • build.

Aucun code ne doit être fusionné si ces contrôles échouent.

18. Supervision​

La qualité est suivie dans le temps grâce à des indicateurs.

Exemples :

  • taux de crash ;
  • temps moyen de démarrage ;
  • durée moyenne des synchronisations ;
  • erreurs réseau ;
  • erreurs API.

Ces indicateurs permettent d'identifier rapidement une régression.

19. ADR​

Alternatives étudiées​

Qualité basée uniquement sur les tests​

Rejetée.

Les tests ne détectent pas tous les problèmes de performance ou de stabilité.

Approche globale (tests + observabilité + métriques)​

Retenue.

Elle permet de suivre la qualité tout au long du cycle de vie de l'application.

20. Décisions figées​

✅ La qualité est une responsabilité architecturale.

✅ Les performances sont suivies en continu.

✅ Les crashs sont collectés automatiquement.

✅ Les erreurs sont catégorisées.

✅ L'accessibilité est intégrée dès la conception.

✅ Les Pull Requests doivent passer les contrôles automatiques.

✅ Les métriques servent à améliorer la plateforme, pas à profiler les utilisateurs.

Conclusion​

La qualité de DMV Mobile ne repose pas uniquement sur des tests ou des revues de code.

Elle résulte d'une architecture pensée pour être robuste, observable, performante et accessible.

L'objectif est de garantir une expérience utilisateur constante dans le temps, quelles que soient les évolutions de la plateforme.