Un jour, une lectrice m'écrit : « Mon app affiche "Erreur réseau" dès qu'il pleut. » Pas de chance avec la météo, évidemment. En réalité, son app appelait une API sans timeout ni gestion de reconnexion. À la moindre coupure, l'écran se figeait. Voilà le genre de détail qu'on ne découvre qu'en mettant les mains dedans.
Une API pour application mobile, c'est le tuyau qui relie votre écran à un serveur. Rien de plus, rien de moins. Mais quand ce tuyau se bouche, l'utilisateur ne voit pas un problème technique : il voit une app cassée. Et il la désinstalle.
Dans cet article, je vous explique comment fonctionne une API côté mobile, avec le détail que les tutos oublient souvent : ce qui se passe quand le réseau est mauvais, comment on sécurise les jetons d'accès, et pourquoi embarquer une clé secrète dans votre app est une très mauvaise idée.
Points clés à retenir
- Une API est une interface de programmation : votre app envoie une requête, le serveur renvoie une réponse, souvent en JSON.
- Le cycle complet tient en cinq étapes : requête HTTP, endpoint, réponse, parsing, affichage.
- Sur mobile, le vrai ennemi n'est pas le code, c'est la connectivité instable.
- Un jeton d'accès ne doit jamais être stocké en clair, ni une clé secrète embarquée dans le binaire.
- Le choix de la bibliothèque HTTP dépend de votre stack, pas de la mode.
Comment fonctionne une API pour application mobile, concrètement
Imaginez un restaurant. Vous (l'app) ne rentrez pas en cuisine. Vous parlez au serveur (l'API), qui transmet à la cuisine (le serveur distant) et vous rapporte le plat (la réponse). Vous n'avez pas besoin de savoir comment le four fonctionne.
Techniquement, votre application mobile est un client. Elle envoie une requête HTTP à une URL précise, appelée endpoint. Le serveur traite, puis répond — le plus souvent en JSON.
Le cycle d'un appel, en cinq étapes
Prenons un cas réel : un écran qui affiche une liste de produits. Voici ce qui se passe, dans l'ordre.
- L'app construit une requête
GET https://api.exemple.com/produits, avec un en-tête d'authentification. - La requête part sur le réseau. Sur mobile, c'est là que tout peut dérailler : 4G faible, tunnel, mode avion activé par erreur.
- Le serveur vérifie le jeton, interroge sa base, renvoie un JSON avec la liste.
- L'app parse ce JSON — c'est-à-dire qu'elle transforme le texte brut en objets utilisables dans son langage.
- L'interface affiche la liste. Si le JSON est mal formé, l'écran reste vide.
Cette cinquième étape, je l'ai vue échouer des dizaines de fois. Un champ renommé côté serveur, et l'app plante silencieusement. Le développeur ne le voit pas en test, parce que son serveur local est à jour. En production, c'est autre chose.
REST API : le standard de fait
La plupart des API mobiles suivent le style REST. Les ressources ont des URL, et les verbes HTTP indiquent l'action : GET pour lire, POST pour créer, PUT ou PATCH pour modifier, DELETE pour supprimer.
Un exemple de réponse typique ressemble à ceci :
{
"id": 42,
"nom": "Chaise pliante",
"prix": 29.90,
"stock": 3
}Simple, lisible, et c'est précisément pour ça que REST a gagné. GraphQL existe, et il a ses défenseurs — mais pour 90 % des apps mobiles, REST suffit largement. Mon avis tranché : ne complexifiez pas tant que vous n'avez pas un vrai problème de sur-fetching.
Comment intégrer une API dans une application ?
La question revient sans arrêt. La réponse courte : vous choisissez une bibliothèque HTTP adaptée à votre stack, vous centralisez les appels dans une couche dédiée, et vous traitez les erreurs comme des citoyens de première classe.
Quelle bibliothèque pour quelle stack ?
| Plateforme | Bibliothèque courante | Remarque |
|---|---|---|
| Android (Kotlin) | Retrofit + OkHttp | Le duo le plus répandu, très documenté |
| iOS (Swift) | URLSession natif, ou Alamofire | URLSession suffit souvent |
| React Native | fetch natif, ou Axios | fetch manque de gestion fine des timeouts |
| Flutter | package http, ou Dio | Dio gère les intercepteurs |
J'ai longtemps sous-estimé l'importance des intercepteurs. Ce sont des fonctions qui s'exécutent avant ou après chaque requête. On y glisse le jeton d'authentification, on y gère le rafraîchissement automatique, on y logue les erreurs. Sans eux, vous dupliquez ce code dans chaque écran.
Une erreur que j'ai commise au début : appeler l'API directement depuis l'interface. Résultat, 3 écrans à modifier quand le format de réponse a changé. Depuis, j'isole tout dans une couche repository. Une seule classe à corriger, et le reste de l'app ne bronche pas.
L'offline-first, le vrai sujet mobile
Voici l'angle que les tutoriels passent sous silence : sur mobile, le réseau n'est pas fiable. Jamais. Un utilisateur dans le métro, un autre en zone blanche — et votre app doit tenir debout.
Les parades qui fonctionnent :
- Un cache local (base SQLite, ou un simple stockage clé-valeur) pour afficher les dernières données connues.
- Un timeout court — j'utilise 10 secondes maximum, parfois 5 pour les appels critiques.
- Une politique de retry avec backoff exponentiel, pour ne pas marteler un serveur déjà en difficulté.
- Un indicateur visuel clair : l'utilisateur doit comprendre qu'il voit des données périmées.
Et là, surprise : la consommation de batterie entre en jeu. Chaque requête réveille la radio du téléphone, qui reste active quelques secondes après. Une app qui interroge l'API toutes les deux secondes vide la batterie en une matinée. Regroupez vos appels, espacez les rafraîchissements, et laissez le système gérer.
Comment se servir d'une API ?
Vous avez l'URL et la documentation. Par où commencer ? D'abord, testez l'API en dehors de votre app. Avec un simple outil comme Postman ou curl, vous vérifiez que l'endpoint répond, que le jeton fonctionne, et que le JSON ressemble à ce que la doc promet.
Quelles sont les principales étapes pour créer une application mobile ?
Une app qui consomme une API se construit dans un ordre précis. Sauter une étape se paie plus tard.
- Définir les écrans et les données dont chacun a besoin — pas plus.
- Identifier les endpoints correspondants dans la documentation.
- Tester chaque appel isolément, hors de l'app.
- Construire la couche d'accès aux données (le repository).
- Brancher l'interface, avec des états de chargement et d'erreur visibles.
- Tester avec un réseau dégradé : mode avion, 3G simulée, latence artificielle.
L'étape 6, personne ne la fait. Et pourtant, c'est celle qui m'a évité le plus d'incidents. Simuler une connexion lente sur un émulateur prend deux minutes et révèle tous les bugs de gestion d'état.
Sécurité : ce qu'il ne faut surtout pas faire
Vous ne pouvez pas cacher un secret dans une app mobile. C'est un fait, pas un conseil. Un binaire peut être décompilé, un trafic intercepté. Toute clé embarquée dans le code est publique.
Les bonnes pratiques tiennent en quelques règles :
- Utilisez OAuth2 ou des jetons JWT à durée de vie courte, avec un mécanisme de rafraîchissement.
- Stockez les jetons dans le Keychain (iOS) ou le Keystore (Android), jamais en clair dans les préférences.
- Passez en HTTPS systématiquement. Sans exception, même en développement.
- Envisagez le certificate pinning si votre app manipule des données sensibles : cela bloque les attaques de type homme-du-milieu.
- Ne stockez jamais de mots de passe, même hachés localement. Le serveur gère, l'app transporte.
Une anecdote pour illustrer : j'ai vu une app de e-commerce avec sa clé d'API de paiement directement dans le code source. Un utilisateur curieux l'a extraite et a passé commande gratuitement pendant deux semaines avant que quiconque ne s'en aperçoive. Le correctif a pris une heure. La honte, beaucoup plus longtemps.
Qu'est-ce qu'une API pour les nuls ?
Sans jargon : une API est un guichet. Vous tendez un papier avec une demande précise, on vous rend la réponse correspondante. Vous ne voyez pas ce qui se passe derrière le comptoir, et vous n'avez pas à le voir.
Ce guichet a des règles. Il faut frapper à la bonne porte (le bon endpoint), présenter une pièce d'identité (le jeton), et formuler sa demande dans le bon format. Si vous vous trompez, on vous renvoie une erreur avec un code — 404 pour une ressource introuvable, 401 pour un problème d'authentification, 500 pour un serveur en vrac.
Rien de magique là-dedans. Juste un contrat entre deux programmes qui se parlent.
Et si vous reteniez une seule chose de tout ça ? Une API mobile, ce n'est pas un tuyau qu'on branche une fois. C'est une relation à entretenir — avec ses pannes, ses lenteurs, ses changements de format imprévus. Les apps qui tiennent dans la durée sont celles dont les développeurs ont accepté que le réseau soit un adversaire, pas un décor. La prochaine fois que votre écran affiche « Erreur réseau », vous saurez au moins où regarder : côté timeout, ou côté cuisine.
