Glossaire du développement d’apps : 64 termes clés

Lancer une application mobile, c’est souvent découvrir un vocabulaire inconnu dès le premier rendez-vous avec une agence : natif, cross-platform, back-end, API, MVP, recette, TMA… Mal compris, ces termes rendent les devis difficiles à comparer et les arbitrages impossibles à challenger. Ce glossaire réunit les 64 termes clés du développement d’applications, classés par étape de projet, avec une définition courte pour chacun, puis les langages utilisés et les questions à poser à un prestataire.

Réponse courte : les termes indispensables pour piloter un projet d’application sont d’abord technologiques (natif, cross-platform, PWA, Swift pour iOS, Kotlin pour Android, Flutter et React Native pour un code commun), puis d’architecture (front-end, back-end, API, base de données, cloud), de méthode (agile, sprint, backlog, MVP) et de publication (recette, bêta-test, App Store, Google Play, ASO). En France, où Android pèse environ 65 % du trafic web mobile et iOS 35 % selon StatCounter, une application grand public doit en pratique viser les deux systèmes.

Ces chiffres de StatCounter mesurent la part de chaque système dans les pages web consultées sur mobile en France (Android 65,39 %, iOS 34,59 % en septembre 2026). Ils expliquent pourquoi la question « natif ou cross-platform ? » arrive si tôt dans un projet : viser les deux systèmes est la norme pour une application grand public.

Le glossaire du développement d’applications : 64 termes

Technologies et approches de développement

• Application native : application écrite spécifiquement pour un système (iOS ou Android) dans son langage officiel. Elle accède à toutes les fonctions du téléphone et offre les meilleures performances, mais demande deux bases de code pour couvrir les deux systèmes.
• Cross-platform (multiplateforme) : approche où une seule base de code produit l’application iOS et l’application Android, avec des frameworks comme Flutter ou React Native.
• Application hybride : au sens strict, application web encapsulée dans une coquille native. Le terme est souvent employé, par abus de langage, pour désigner le cross-platform.
• Web app : application qui s’exécute dans le navigateur, sans passer par les stores.
• PWA (Progressive Web App) : web app installable sur l’écran d’accueil, capable de fonctionner en partie hors ligne et d’envoyer des notifications. Sur iPhone, les notifications web des applications ajoutées à l’écran d’accueil sont prises en charge depuis iOS 16.4, selon l’équipe WebKit d’Apple.
• iOS : système d’exploitation des iPhone, édité par Apple.
• Android : système d’exploitation mobile de Google, utilisé par la plupart des autres fabricants de smartphones.
• Swift : langage de programmation d’Apple pour développer sur ses plateformes, successeur d’Objective-C.
• Kotlin : langage recommandé par Google pour Android, qui a annoncé en 2019 un développement Android « Kotlin-first » ; Java reste utilisé sur les projets plus anciens.
• Flutter : framework cross-platform de Google, qui utilise le langage Dart.
• React Native : framework cross-platform créé par Meta (ex-Facebook), qui utilise JavaScript ou TypeScript.
• SDK (Software Development Kit) : boîte à outils fournie par un éditeur pour intégrer un service (paiement, cartographie, analytics) sans le recoder.

Outils du développeur

• IDE (environnement de développement intégré) : logiciel dans lequel les développeurs écrivent, testent et compilent leur code.
• Xcode : l’IDE d’Apple, indispensable pour compiler et publier une application iOS. Il ne fonctionne que sur Mac, d’où le besoin d’un Mac pour développer pour l’iPhone.
• Android Studio : l’IDE officiel de Google pour le développement Android.
• Framework : ensemble de composants et de règles qui structure le développement et évite de repartir de zéro (Flutter, React Native, SwiftUI…).

Architecture et données

• Front-end : tout ce qui s’exécute sur le téléphone de l’utilisateur : écrans, navigation, animations.
• Back-end : la partie serveur invisible : base de données, logique métier, comptes utilisateurs, paiements.
• API (interface de programmation) : le point de passage par lequel l’application demande des données ou des actions au back-end ou à un service tiers.
• API REST : style d’API le plus répandu, où chaque ressource (un produit, une commande) a son adresse et se manipule par des requêtes HTTP standard.
• GraphQL : langage de requête d’API qui permet à l’application de demander précisément les données dont elle a besoin, en une seule requête.
• Base de données : système qui stocke les données de l’application (utilisateurs, contenus, transactions).
• SQL (base relationnelle) : base organisée en tables liées entre elles, interrogée avec le langage SQL ; adaptée aux données très structurées.
• NoSQL : famille de bases non relationnelles (documents, clé-valeur), plus souples pour des données hétérogènes ou très volumineuses.
• Serveur : machine, physique ou virtuelle, qui héberge le back-end et répond aux requêtes de l’application.
• Cloud : hébergement sur l’infrastructure d’un fournisseur, facturé à l’usage, plutôt que sur ses propres serveurs.
• Scalabilité : capacité d’une architecture à absorber une hausse de charge (plus d’utilisateurs, plus de données) sans dégrader les performances.
• BaaS (Backend as a Service) : back-end prêt à l’emploi (authentification, base de données, stockage, notifications) fourni par un service tiers, qui évite d’en développer un sur mesure pour les besoins standards.

Fonctionnalités mobiles

• Notification push : message envoyé par l’application sur l’écran du téléphone, même quand elle est fermée, avec l’accord de l’utilisateur.
• Mode hors ligne : capacité à fonctionner sans connexion, puis à synchroniser les données au retour du réseau. C’est l’une des fonctionnalités qui pèsent le plus sur un budget.
• Géolocalisation : utilisation de la position de l’appareil (GPS, réseau), soumise à l’autorisation de l’utilisateur.
• Deep link (lien profond) : lien qui ouvre directement un écran précis de l’application (une fiche produit, un panier) plutôt que son accueil.
• Achat intégré (in-app purchase) : paiement effectué dans l’application pour un contenu numérique ou un abonnement, via le système de paiement du store.
• Authentification : vérification de l’identité de l’utilisateur (mot de passe, connexion avec un compte Apple ou Google, double authentification).

Design et expérience utilisateur

• UX (expérience utilisateur) : facilité et fluidité d’usage, logique des parcours, réponse aux besoins réels de l’utilisateur.
• UI (interface utilisateur) : couche visuelle et interactive : typographies, couleurs, boutons, états. Les principes qui la guident sont détaillés dans nos règles d’or du design d’interface.
• Wireframe : schéma sans graphisme qui fixe la structure des écrans et l’emplacement des éléments.
• Maquette (mockup) : rendu visuel statique des écrans, avec la charte graphique appliquée.
• Prototype : maquettes rendues cliquables pour simuler la navigation et tester l’application avant tout développement.
• Design system : bibliothèque de composants et de règles de design réutilisables qui garantit la cohérence de l’application.
• Material Design : le système de design de Google, référence pour les interfaces Android.
• Human Interface Guidelines : les recommandations de design d’Apple pour ses plateformes, dont iOS.

Méthode et gestion de projet

• Cahier des charges : document qui décrit le besoin, les fonctionnalités, les contraintes et le budget ; base de comparaison des devis.
• Agile : famille de méthodes qui livrent le produit par petites itérations plutôt qu’en un seul bloc à la fin (méthode « en cascade »).
• Scrum : cadre agile le plus répandu, organisé en sprints avec des rôles et des rituels définis.
• Sprint : cycle court, souvent de deux semaines, à l’issue duquel une partie de l’application est livrée et testable.
• Product Owner : la personne qui porte la vision du produit et priorise les fonctionnalités ; souvent votre représentant côté client.
• Backlog : liste priorisée des fonctionnalités et tâches restant à réaliser.
• User story : description d’une fonctionnalité du point de vue de l’utilisateur (« en tant que client, je veux réinitialiser mon mot de passe pour… »).
• POC (preuve de concept) : réalisation sommaire destinée à vérifier qu’une idée est techniquement faisable, sans vocation à être commercialisée.
• MVP (produit minimum viable) : première version réduite aux fonctionnalités essentielles, publiée pour confronter le produit au marché le plus tôt possible.
• Roadmap : feuille de route des versions et fonctionnalités prévues dans le temps.
• Time-to-market : délai entre le lancement du projet et la mise sur le marché.

Qualité et publication

• Recette (tests d’acceptation) : phase où le client vérifie que l’application livrée correspond au cahier des charges avant la mise en ligne.
• Tests unitaires : tests automatisés qui vérifient chacun une petite partie du code.
• Bug : défaut de fonctionnement, classé par gravité (bloquant, majeur, mineur) pendant la recette.
• Crash reporting : outil qui remonte automatiquement les plantages de l’application en production, avec leur contexte technique.
• Bêta-test : diffusion d’une version de test à un groupe restreint d’utilisateurs avant la sortie publique.
• TestFlight : le service d’Apple pour distribuer les versions bêta d’une application iOS à des testeurs, hors App Store public.
• Stores (App Store, Google Play) : les boutiques officielles d’Apple et de Google. Publier impose un compte développeur : l’Apple Developer Program coûte 99 USD par an (le prix peut varier selon la région), et Google facture des frais d’inscription uniques à l’ouverture du compte Play Console. Chaque application passe une revue avant publication.
• ASO (App Store Optimization) : le référencement dans les stores : nom, mots-clés, description, captures, notes et avis.

Après le lancement

• Mise à jour (versionnage) : chaque nouvelle version publiée sur les stores, numérotée pour suivre les évolutions et les corrections.
• TMA (tierce maintenance applicative) : contrat de maintenance confié à un prestataire : corrections, compatibilité avec les nouvelles versions d’iOS et d’Android, petites évolutions.
• Privacy by design (RGPD) : principe qui impose de protéger les données personnelles dès la conception : collecte minimale, consentement, sécurité. Apple exige en plus le consentement explicite de l’utilisateur avant tout suivi publicitaire entre applications.

Quels langages pour développer une application mobile ?

Le choix du langage découle du choix d’approche. Voici les options les plus courantes, avec leurs pages officielles.

Ces sources officielles sont à jour : Swift chez Apple, l’approche Kotlin-first d’Android, Flutter et React Native. Pour comparer ces approches avec les outils sans code, voir notre comparatif no-code, low-code ou full-code.

Tendances du développement d’applications

Le cross-platform devient la norme pour viser deux systèmes

Avec deux systèmes qui se partagent le marché français, les frameworks cross-platform sont devenus un choix courant pour les applications grand public. Ils ne font pas forcément baisser la facture : sur les budgets publiés sur La Fabrique du Net, les projets cross-platform ont une médiane de 35 000 € contre 20 000 € en natif, parce qu’ils visent deux plateformes et embarquent plus de fonctionnalités (baromètre des tarifs d’application mobile, petits échantillons à lire comme une tendance).

Les PWA rattrapent une partie de leur retard

Depuis l’arrivée des notifications web sur iPhone avec iOS 16.4, une PWA peut couvrir davantage de besoins sans passer par les stores. Elle reste plus limitée qu’une application native pour l’accès au matériel et la visibilité dans les boutiques.

Le no-code et l’IA dans la production

Les outils sans code permettent de construire des MVP et des applications internes simples plus vite. Les assistants d’IA, désormais intégrés aux environnements de développement (Android Studio met par exemple en avant son assistant Gemini), accélèrent l’écriture du code ; ils ne remplacent ni la conception, ni la recette.

La confidentialité au cœur de la conception

RGPD en Europe, consentement exigé par Apple pour le suivi publicitaire, revues des stores de plus en plus attentives aux données collectées : la protection des données se traite dès les premiers échanges avec le prestataire.

Les erreurs les plus fréquentes

Vouloir tout mettre dans la première version

Ajouter sans cesse des fonctionnalités retarde la sortie et épuise le budget. Tenez-vous au MVP : ce qui n’est pas vital au lancement va dans le backlog de la version suivante.

Oublier la maintenance

Une application doit suivre les nouvelles versions d’iOS et d’Android, publiées chaque année, et les évolutions des services tiers qu’elle utilise. Prévoyez un budget annuel de TMA dès le départ.

Sous-estimer le back-end

Investir tout le budget dans les écrans au détriment du serveur produit une application belle mais lente ou fragile dès que le nombre d’utilisateurs augmente. Vérifiez la part du devis consacrée à l’architecture et aux API.

Comment bien choisir son agence pour une application mobile

• Le choix technologique est-il justifié par votre besoin ? Une bonne agence explique pourquoi natif ou cross-platform pour votre projet, pas seulement ce qu’elle sait faire.
• Qui est propriétaire du code source ? Faites-le écrire au contrat, avec les accès aux comptes développeur et aux serveurs.
• Comment la qualité est-elle assurée ? Demandez qui teste, sur quels appareils, et comment se déroule la recette.
• La publication sur les stores est-elle incluse ? C’est une étape à part entière, avec ses délais de revue.
• Que prévoit la maintenance ? Périmètre, délais d’intervention et coût annuel.

Méfiez-vous d’un chiffrage très précis sans phase de conception préalable : il se traduit souvent par des avenants. Pour comparer plusieurs agences de développement d’application mobile sur la même base, préparez votre demande avec la grille ci-dessous.

Checklist pour préparer votre demande