🗃️ 2.3 Architecture et composants d'une application mobile

Module 335 – Réaliser une application pour mobile

🎯 Objectif d'apprentissage

À la fin de ce chapitre, vous serez capable de :

  • Comprendre la structure interne d'une application mobile
  • Identifier les modèles d'architectures les plus utilisés (MVC, MVVM, Clean Architecture)
  • Expliquer le rôle et la communication entre les différentes couches d'une application
  • Appréhender les principes de gestion d'état et de modularité

🧱 2.3.1 Introduction : pourquoi une architecture ?

Une application mobile n'est pas un simple enchaînement d'écrans et de boutons.

C’est un ensemble de composants interconnectés, chacun avec un rôle :

  • afficher des informations
  • exécuter une logique
  • stocker ou échanger des données

L’architecture définit comment ces composants s’organisent et communiquent.

2.3.1 Pourquoi une architecture ?

Une bonne architecture permet de construire une application :

  • plus claire → rôle de chaque fichier identifiable
  • plus maintenable → les évolutions n’impactent pas tout le code
  • plus testable → chaque couche peut être validée indépendamment

🎯 But : concevoir des apps structurées, performantes et faciles à faire évoluer.

2.3.1 Exemple concret – App météo

Une application météo comporte :

  • une interface (View) → affiche la température
  • une logique (Controller / ViewModel) → interroge le service météo
  • un modèle (Model) → représente les données reçues de l’API

👉 On retrouve déjà les 3 rôles : afficher, décider, représenter les données.

🧱 2.3.1bis Les 3 couches universelles d’une application

Avant de parler de MVC ou MVVM, retenez qu’une application est presque toujours organisée en 3 grandes couches :

  1. Interface (UI)
    → ce que l’utilisateur voit et manipule (écrans, boutons, formulaires).

  2. Logique / État
    → ce qui décide quoi faire quand l’utilisateur agit (règles métier, état de l’app).

  3. Données
    → où sont stockées les informations (API, base de données, localStorage, fichiers…).

2.3.1bis Exemple – App Ionic-Vue “TaskIonic”

Imaginons une petite app de liste de tâches en Ionic-Vue.

Couche Rôle Exemple dans TaskIonic
Interface (UI) Afficher les infos, gérer les clics TasksPage.vue, TaskItem.vue
Logique / État Gérer l’état et la logique métier useTasksStore.ts (Pinia)
Données Lire / écrire les données tasksApi.ts, Task.ts

2.3.1bis Réflexe à adopter

Quand vous ne savez pas où mettre un morceau de code, demandez-vous :

  • Est-ce que ça affiche quelque chose ou réagit à un clic ?
    → Interface (UI)

  • Est-ce que ça décide quoi faire (validation, règles métier, calcul) ?
    → Logique / État

  • Est-ce que ça lit / écrit des données “persistantes” (API, storage, BDD) ?
    → Données

💡 MVC, MVVM, Clean = différentes façons d’organiser ces 3 couches.

🗃️ 2.3.2 Les modèles d’architectures les plus utilisés

Les architectures (MVC, MVVM, Clean…) définissent comment organiser :

  • la UI
  • la logique / état
  • les données

Objectifs communs :

  • séparer les responsabilités
  • rendre le code lisible, testable, maintenable
  • permettre à plusieurs devs de travailler en parallèle

2.3.2 Architectures ≠ Android uniquement

Ces architectures ne sont pas propres à Android :

  • présentes en desktop, web, mobile
  • utilisées avec :
    • Android, iOS
    • Flutter, React Native
    • Ionic + Vue + Capacitor

Questions récurrentes :

  • Où mettre la logique métier ?
  • Où gérer l’état ?
  • Où accéder aux données ?
  • Comment éviter le “gros fichier unique” ?

2.3.2 Lien avec TaskIonic

Dans notre app Ionic-Vue “TaskIonic” :

  • Model / Données : Task.ts, tasksApi.ts
  • View / UI : TasksPage.vue, TaskItem.vue
  • Controller / ViewModel : useTasksStore.ts (Pinia, logique + état)

🧩 Idée clé :
ce qui affiche ≠ ce qui décide ≠ ce qui stocke.

🔹 MVC (Model – View – Controller) – Principe

MVC = un des modèles les plus anciens et les plus répandus.

Élément Rôle
Model Données + logique métier
View Affichage (ce que voit l’utilisateur)
Controller Lien entre View et Model

2.3.2 MVC – Exemple météo

Dans une app météo :

  • Controller récupère les données depuis une API
  • les transforme en objets Model
  • met à jour la View avec la température et les icônes

Avantages :

  • simple à comprendre
  • structure claire

Limite :

  • le contrôleur peut devenir trop gros (“fat controller”).

2.3.2 MVC – Où le trouve-t-on ?

On le retrouve (explicitement ou non) dans :

  • Android : Activities / Fragments + XML
  • iOS : ViewControllers
  • Ionic / Vue : Composants + services

🔸 MVVM (Model – View – ViewModel) – Principe

MVVM = évolution de MVC pour mieux gérer l’état et la réactivité.

Élément Rôle
Model Données + logique métier
View Interface graphique
ViewModel Gère l’état de la vue + réagit aux interactions

La ViewModel observe le Model :
dès qu’une donnée change, la View se met à jour (data binding).

2.3.2 MVVM – Exemple app de notes

Dans une app de notes :

  • la ViewModel contient une liste réactive de notes
  • quand une note est ajoutée, la liste change
  • la View se met automatiquement à jour (binding / réactivité)

Avantages :

  • meilleure gestion de l’état
  • moins de “code colle” entre logique et vue
  • très utilisé avec :
    • Android (Jetpack)
    • Flutter
    • Vue / React Native

Limites :

  • plus complexe au début
  • nécessite de bien comprendre la réactivité.

2.3.2 MVVM – Illustration

▫️ Clean Architecture – Principe

La Clean Architecture (Uncle Bob) sépare fortement les couches :

Couche Contenu
Présentation (UI) Écrans, widgets, interactions utilisateur
Domaine Logique métier pure, cas d’usage
Données Accès API, BDD, fichiers, cache

2.3.2 Clean Architecture – Exemple

Exemple e-commerce :

  • Domaine : calcul de panier, règles de remise, validation commande
  • Données : API produits, BDD commandes, cache local
  • Présentation : liste des produits, formulaire de commande

Avantages :

  • très modulaire
  • idéale pour projets long terme / en équipe

Limites :

  • plus lourde à mettre en place
  • plus de dossiers, d’abstractions

2.3.2 Clean Architecture – Schéma

📱 2.3.2bis Architecture dans une app Ionic-Vue

Avec Ionic + Vue + Pinia, on utilise une architecture proche de :

  • MVVM (UI + ViewModel/store + Model)
  • Clean Architecture simplifiée (UI / domaine / données)

2.3.2bis Rôle des dossiers dans un projet Ionic-Vue

Dossier / fichier Couche Rôle principal
views/ (*.vue) Interface (UI) Écrans, navigation, mise en forme
components/ (*.vue) Interface (UI) Blocs réutilisables (card, liste, bouton…)
stores/ (Pinia) Logique / État État global, règles métier, actions
models/ (*.ts) Modèle / Domaine Types, interfaces, petites fonctions métier
services/ (*Api.ts) Données Accès aux APIs, localStorage, SQLite, etc.

2.3.2bis Scénario “Ajouter une tâche” – Vue d’ensemble

Exemple TaskIonic :

  1. L’utilisateur clique sur “Ajouter” (TasksPage.vue)
  2. La vue appelle une action Pinia : tasksStore.addTask(title)
  3. Le store met à jour la liste en mémoire et appelle tasksApi.saveTasks(...)
  4. Le service persiste les données (localStorage / API)
  5. Vue se met à jour automatiquement (réactivité)

2.3.2bis Schéma – Architecture “TaskIonic”

UI → Store (logique + état) → Service (données) → Storage / API

2.3.2bis Lecture du diagramme

  • UI (Vue / Ionic – TasksPage.vue)
    → récupère les clics, affiche la liste

  • Store Pinia – useTasksStore
    → gère l’état + la logique métier (“que faire quand…”)

  • Service – tasksApi
    → lit / écrit les données (localStorage, API, etc.)

🎯 Vue ne sait pas “où” les données sont stockées → découplage.

2.3.2bis À retenir pour vos projets Ionic

  • Composants Vue/Ionic :

    • affichage
    • gestion d’événements (clic, submit)
    • appels aux actions (stores / services)

  • Stores Pinia :

    • état
    • logique métier (règles, validations, calculs)
    • appels aux services de données

  • Services :

    • tout ce qui touche aux APIs et au stockage

🔄 2.3.3 Gestion de l’état – Définition

Une application doit gérer des données qui changent dans le temps :

  • utilisateur connecté
  • panier
  • liste de tâches ou favoris
  • onglet actif, filtres, etc.

Ces informations constituent l’état de l’application.

Gestion d’état = maintenir et synchroniser ces données entre les différentes parties de l’app.

2.3.3 Gestion de l’état – Exemple

Exemple : panier e-commerce

  • L’utilisateur ajoute un article
  • Le panier doit être mis à jour :
    • dans la page panier
    • dans l’icône du menu
    • dans le résumé commande

💡 Toutes ces vues lisent le même état partagé.

2.3.3 Outils de gestion d’état

Environnement Outil de gestion d’état Particularité
Vue / Ionic Pinia, Vuex Données réactives centralisées
React Native Redux, Zustand Flux unidirectionnel, prédictible
Flutter Provider, Riverpod, Bloc Widgets qui observent l’état
Android LiveData, ViewModel Persistance d’état entre les écrans

2.3.3 Exemple – Pinia dans Vue

Dans Vue + Pinia :

  • Une variable isLoggedIn est stockée dans un store central
  • Tous les composants qui l’utilisent se mettent à jour automatiquement :
    • affichage du menu utilisateur
    • affichage / masquage de certaines pages

🎯 Une bonne gestion d’état = app fluide, cohérente, plus facile à déboguer.

☎️ 2.3.4 Communication entre couches

Une application bien structurée repose sur une communication claire entre les couches.

Flux typique :

  1. L’utilisateur interagit avec la Vue (UI)
  2. La logique (Controller / ViewModel / Store) traite la demande
  3. La couche données (API / BDD) fournit ou enregistre l’info
  4. Le résultat remonte vers la vue

2.3.4 Exemple – App météo

Scénario “Actualiser la météo” :

  • Clic sur “Actualiser” dans la vue
  • Le ViewModel / store appelle un service API
  • L’API renvoie un JSON
  • Le modèle est mis à jour
  • La vue affiche la nouvelle température

2.3.4 Principes de modularité

  • Responsabilité unique
    → chaque module fait une seule chose (Single Responsibility)

  • Réutilisabilité
    → une logique métier peut servir à plusieurs vues

  • Évolutivité
    → on peut changer une source de données (API, BDD…)
    sans toucher aux écrans

💡 Résultat : plus facile à faire évoluer, plus simple à travailler en équipe.

2.3.4 Schéma de communication recommandé

UI ↔ Logique / État ↔ Données
Chacun son rôle, chacun sa responsabilité.

🧩 2.3.5 Activités pédagogiques – Exercice 1

🧠 Exercice 1 – Identifier l’architecture

Observez une application simple (ex : app météo ou todo list).

➡️ Identifiez les 3 grandes couches : Données, Logique, Interface
➡️ Classez les fichiers / fonctions selon MVC ou MVVM
➡️ Expliquez la responsabilité de chaque partie :

  • où se trouve la logique métier ?
  • où sont stockées les données ?

2.3.5 Activités – Exercice 2

🔄 Exercice 2 – Gestion de l’état

Concevez une mini-app :

  • compteur
  • panier
  • liste de tâches

➡️ Décrivez ce qui constitue l’état de votre app
➡️ Expliquez comment cet état évolue (ajout, suppression, reset…)
➡️ Indiquez où et comment vous le stockeriez :

  • Pinia / Redux / Provider…
  • ou simple variable réactive

2.3.5 Activités – Exercice bonus

💡 Exercice bonus – Simplifier un code “spaghetti”

On vous donne un code “tout dans un fichier”.

➡️ Réorganisez-le selon MVC ou MVVM
➡️ Identifiez :

  • ce qui relève du Model
  • ce qui relève de la View
  • ce qui relève du Controller / ViewModel

🎯 Objectif : expérimenter la refactorisation vers une architecture claire.

🔗 2.3.6 Références et ressources