🪪 2.1 Typologie des applications mobiles

Module 335 – Réaliser une application pour mobile

🎯 Objectif d’apprentissage

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

• Comprendre pourquoi il existe plusieurs types d’applications mobiles
• Distinguer les approches natives, web, hybrides et cross-plateformes
• Identifier les forces, limites et contextes d’usage de chacune
• Expliquer comment le choix d’une technologie influence la performance, la maintenance et le coût

ℹ️ Les 4 grands types d’applications (référentiel module)

Selon le référentiel du module, on distingue 4 grands types d’applications :

1. Natives – développées spécifiquement pour Android ou iOS
2. Web – accessibles via un navigateur, sans installation
3. Hybrides – applications web encapsulées dans un conteneur natif (WebView)
4. Cross-plateformes – un seul code source compilé pour plusieurs systèmes (Flutter, React Native, …)

🔁 Hybride vs Cross-plateforme : vision moderne

• Les approches hybrides ont servi de transition historique vers les solutions cross-plateformes modernes

• Aujourd’hui, des frameworks comme Ionic utilisent :

  • une base web (héritée de l’hybride)
  • combinée à des capacités natives via Capacitor

👉 On parle désormais plus volontiers de “cross-plateforme à base web” que d’hybride classique.

🤔 2.1.1 Pourquoi plusieurs types d’applications ?

L’univers mobile repose sur plusieurs plateformes :

• iOS, Android
• et, plus globalement, le Web mobile

Chaque environnement a :

• ses outils
• ses langages
• ses règles de sécurité
• ses méthodes de publication

2.1.1 La question centrale

Les entreprises et développeurs se demandent :

Comment atteindre tous les utilisateurs sans exploser les coûts, les efforts et les délais ?

D’où la recherche d’un équilibre entre :

• Performance
• Coût
• Accessibilité / portée

2.1.1 Les grandes approches techniques

Pour répondre à ces enjeux, plusieurs approches sont apparues :

• Natif
  → performance maximale, intégration profonde au système
• Web
  → compatibilité universelle, mises à jour instantanées
• Hybride
  → application web encapsulée dans un conteneur natif
• Cross-plateforme
  → un seul code compilé pour plusieurs OS (Flutter, React Native, …)

💡 Il n’existe pas de “meilleure” approche universelle :
le bon choix dépend du contexte du projet, du budget et du public cible.

📱 2.1.2 Les applications natives – Définition

Les applications natives sont développées spécifiquement pour un système d’exploitation :

• Pour Android :
  • Langages : Java, Kotlin
  • IDE : Android Studio
• Pour iOS :
  • Langages : Swift, Objective-C
  • IDE : Xcode

Elles sont compilées pour chaque OS et publiées sur :

• Google Play Store
• Apple App Store

2.1.2 Intégration et capacités des apps natives

Les apps natives :

• Interagissent directement avec les API du système
• Exploitent pleinement les capacités matérielles :
  • appareil photo
  • GPS
  • Bluetooth
  • gyroscope
  • notifications
  • biométrie (Face ID, Touch ID)
• Offrent :
  • performance maximale
  • fluidité
  • cohérence visuelle avec le système

2.1.2 Exemples d’applications natives

Exemples typiques :

• WhatsApp
• TikTok
• Instagram

Points communs :

• usage intensif de la caméra et du micro
• animations et transitions complexes
• besoin d’une réactivité très élevée

2.1.2 Limites du natif

Inconvénients principaux :

• Deux bases de code si on vise Android + iOS
• Nécessite souvent deux équipes (ou au moins deux compétences)
• Tests séparés, pipeline de build plus complexe
• Coûts de développement et de maintenance plus élevés

✅ Choix privilégié quand la performance, la stabilité et l’intégration système sont prioritaires.

🌐 2.1.3 Les applications web mobiles – Définition

Les applications web mobiles :

• Ne s’installent pas depuis un store
• S’exécutent dans un navigateur (Chrome, Safari, Firefox, Edge…)
• Sont développées en :
  • HTML
  • CSS
  • JavaScript

En pratique, ce sont des sites web optimisés pour l’affichage mobile.

2.1.3 Forces des applications web

Principaux avantages :

• Universalité : un seul site pour tous les appareils
• Développement rapide et coûts réduits
• Mises à jour instantanées (pas de store, pas de téléchargement)
• Multi-appareils : ordinateur, tablette, smartphone

2.1.3 Limites des applications web

Limitations :

• Dépendent d’une connexion Internet stable
• Accès aux capteurs limité, même si :
  • Web Bluetooth
  • WebUSB
  • WebRTC
  • Geolocation API
    élargissent progressivement les possibilités
• Performance généralement inférieure au natif, surtout pour :
  • animations complexes
  • jeux
  • traitements lourds

2.1.3 Exemples d’applications web

Quelques exemples :

• Twitter Web
• Wikipedia Mobile
• Certains portails bancaires consultables uniquement depuis un navigateur

Adaptés pour :

• la consultation d’informations
• de la saisie simple
• des scénarios peu intensifs en ressources

🚀 Focus : les Progressive Web Apps (PWA) – Concept

Les Progressive Web Apps (PWA) cherchent à dépasser les limites du web classique.

Caractéristiques :

• Utilisent HTML / CSS / JS
• Ajoutent :
  • Service Workers (cache, offline)
  • Manifest (icône, nom, écran d’accueil)
• Combinent les avantages du web et du mobile

PWA – Capacités

Une PWA peut :

• Être ajoutée à l’écran d’accueil
• Fonctionner hors-ligne (grâce au cache local)
• Envoyer des notifications push (dans certains contextes)
• S’exécuter en plein écran, sans barre d’adresse

🎯 Objectif : offrir une expérience proche d’une app,
tout en restant plus simple et moins coûteuse à développer.

PWA – Exemple Starbucks

Exemple concret :

• Starbucks propose une PWA permettant de :
  • consulter le menu
  • passer commande
  • gérer la fidélité
  • fonctionner en connexion intermittente

Fait intéressant :

• La PWA pèse ~99 % de moins que l’app native
• L’expérience reste très proche de l’app installée

PWA – À tester en classe

🧪 Mini-expérience (si le service est disponible) :

1. Ouvrez le navigateur de votre smartphone
2. Allez sur un site proposant une PWA
3. Utilisez la fonction :
   “Partager” → “Ajouter à l’écran d’accueil”
4. Lancez l’icône depuis l’écran d’accueil

Vous venez de “installer” une PWA 😉

💻 2.1.4 Les applications hybrides – Concept

Les applications hybrides :

• Mélangent technologies web et enveloppe native
• Reposent sur :
  • une base HTML / CSS / JS
  • encapsulée dans un conteneur natif

Elles peuvent être installées :

• depuis les stores (Play Store, App Store)
• comme des apps classiques

2.1.4 WebView et ponts natifs

Fonctionnement :

• Le cœur de l’app tourne dans une WebView
  → un navigateur intégré à l’app
• Des ponts natifs (plugins) permettent :
  • d’accéder à la caméra
  • au GPS
  • aux notifications
  • au stockage local
• Sans écrire (ou presque) de code natif côté développeur web

2.1.4 Exemple : Ionic + Capacitor

Ionic illustre très bien le modèle hybride moderne :

• Interface en technos web (HTML, CSS, JS/TS)
• Utilisation de Capacitor pour :
  • empaqueter l’app pour Android / iOS
  • accéder aux capteurs et fonctionnalités natives
• Déploiement possible :
  • Android
  • iOS
  • Web

👉 Avec Ionic + Capacitor, on parle souvent d’approche “cross-plateforme à base web”.

2.1.4 Avantages des apps hybrides

• Un seul code pour plusieurs plateformes
• Réutilisation des compétences web
• Publication simplifiée sur les stores
• Idéales pour :
  • prototypes
  • apps internes
  • outils éducatifs

2.1.4 Limites des apps hybrides

• Performance parfois inférieure, en particulier :
  • animations complexes
  • rendus 3D
• Expérience utilisateur parfois moins homogène
• Dépendance aux plugins pour accéder aux fonctionnalités natives :
  • qualité variable
  • maintenance à suivre

💬 Bon compromis pour des projets à budget limité ou des apps métiers.

2.1.4 Exemples d’usage hybride

Historiquement, plusieurs grandes apps ont commencé en hybride :

• Instagram (premières versions)
• Uber
• Twitter

Elles ont ensuite migré :

• vers le natif pour gagner en performance
• avec l’augmentation du nombre d’utilisateurs et des exigences UX

Aujourd’hui, beaucoup d’applications métiers restent hybrides :

• coût maîtrisé
• mise en production rapide

2.1.4 Architecture hybride – Schéma

Schéma simplifié d’une architecture hybride :
Code web → rendu dans une WebView → communique avec les APIs natives via des plugins.

⚛️ 2.1.5 Les applications cross-plateformes – Concept

Les applications cross-plateformes (multiplateformes) :

• représentent aujourd’hui l’une des approches les plus répandues
• cherchent à combiner :
  • la performance du natif
  • la productivité d’un code unique

Principe :

• une seule base de code
• compilée pour produire de vraies apps Android et iOS
• sans passer par une simple WebView

2.1.5 Cross-plateforme vs hybride

Contrairement à l’hybride classique :

• les frameworks cross-plateformes modernes :

  • n’utilisent pas (ou plus vraiment) une WebView centrale
  • affichent des composants natifs ou quasi-natifs
  • gèrent eux-mêmes le rendu (ex. Flutter + moteur Skia)

Résultat :
une expérience fluide, souvent très proche du natif pur.

2.1.5 Principaux frameworks cross-plateformes

2.1.5 Points forts des frameworks cross-plateformes

• Un seul code source pour plusieurs OS
• Performance proche du natif
• UX fluide et cohérente
• Maintenance simplifiée (une base de code)
• Grandes communautés (Flutter, React Native, …)
• Bon choix pour :
  • startups
  • produits à forte évolution
  • projets multisystèmes

2.1.5 Limites du cross-plateforme

• Dépendance au framework :
  • nécessité de suivre les évolutions
• Taille de l’app parfois plus importante qu’en natif pur
• Certaines APIs récentes accessibles plus tardivement
• Besoin parfois de code natif complémentaire
• Courbe d’apprentissage propre à chaque framework

💬 Globalement, c’est un excellent compromis entre performance, rapidité et coût.

2.1.5 Hybrid / Cross – Illustration

Schéma comparant les approches Hybrides et Natives

🧮 2.1.6 Comparatif global – Vue d’ensemble

Type                          Langages                    Performance           Accès matériel       Publication

2.1.6 Comparatif global – Coût & maintenance

2.1.6 Lecture du tableau

• Native
  → priorité à la performance et à la qualité d’intégration

• Web
  → priorité à la portée et à la vitesse de développement

• Hybride
  → bon compromis pour des projets internes ou à budget limité

• Cross-plateforme
  → excellent ratio performance / coût / maintenance pour la plupart des projets modernes

2.1.6 Comparatif – Schéma visuel

Illustration des compromis entre coût, performance et portée selon les approches.

🤔 2.1.7 Comment choisir la bonne approche ? (1/2)

Critères principaux :

1. Public cible

   • Utilisateurs uniquement sur un OS (ex. iOS en entreprise) → natif possible
   • Public mixte Android + iOS → cross-plateforme souvent plus rentable

2. Objectifs du projet

   • Priorité performance / UX → Natif
   • Priorité rapidité de déploiement → Web ou Hybride
   • Priorité multi-OS → Cross-plateforme

2.1.7 Comment choisir la bonne approche ? (2/2)

1. Budget et délais

   • Natif = plus cher, plus long (2 codes)
   • Cross / Hybride = mutualisation des coûts

2. Compétences disponibles

   • Équipe à dominante web → Hybride ou PWA
   • Équipe logicielle / mobile → Natif ou Cross-plateforme

3. Maintenance à long terme

   • Une seule base de code → mises à jour plus simples
   • Moins de risques d’incohérences entre plateformes

2.1.7 Exemple de choix – Cas concret

💡 Cas : une application de covoiturage locale à budget limité

• Besoin :
  • multi-plateforme
  • bonne performance
  • UX moderne

Choix typique :
→ Framework cross-plateforme (par ex. Flutter) :

• un seul code source
• rendu fluide
• maintenance simplifiée

🧩 2.1.8 Activités pédagogiques – Exercice 1

🧠 Exercice 1 – Identifier les types d’applications

Choisissez 3 applications connues
(ex : Duolingo, YouTube, Instagram).

Pour chacune :

• Déterminez le type : native, web, hybride ou cross-plateforme
• Justifiez votre choix en observant :
  • mode d’installation
  • fluidité
  • fonctionnement hors-ligne
  • compatibilité multi-appareils

2.1.8 Activités – Exercice 2

⚖️ Exercice 2 – Comparatif de solutions

Contexte : application pour un festival de musique :

• agenda
• billetterie
• carte interactive

Tâches :

• Comparez Native, Web, et Cross-plateforme
• Recommandez une approche en fonction :
  • des objectifs
  • du budget
  • du public cible

2.1.8 Activités – Exercice 3

💡 Exercice 3 – Étude de cas client

Vous êtes en charge d'étudier l'un de ces trois cas clients. Pour chacun, déterminez la meilleure approche technique (native, web, hybride, cross-plateforme) en justifiant votre choix. Répondez aussi aux questions à la fin du cas.

• HelvBank Mobile

• AgendaCulturel

• TechServ Mobile

L’exercice sera discuté en petits groupes, puis présenté à l’oral.

🔗 2.1.9 Références et ressources

• Google Developers – Android Studio
  https://developer.android.com/studio

• Apple Developer – Xcode & Swift
  https://developer.apple.com/xcode/

• Ionic Framework (v8)
  https://ionicframework.com/docs

• Capacitor (v7)
  https://capacitorjs.com/docs

• Flutter (Google)
  https://flutter.dev

• React Native (Meta)
  https://reactnative.dev

• .NET MAUI (Microsoft)
  https://learn.microsoft.com/en-us/dotnet/maui/

• Mozilla MDN – Progressive Web Apps
  https://developer.mozilla.org/docs/Web/Progressive_web_apps