Des applications mobiles livrées à de vrais utilisateurs — et restées livrées — pendant plus de onze ans.

J’ai passé plus de onze ans à construire et livrer des applications mobiles à de vrais utilisateurs — et ce seul fait est celui qui rend chaque autre affirmation de cette page digne d’être lue.

N’importe qui peut lister des frameworks. Le titre qui compte, c’est la longévité : des applications que de vraies personnes ont installées, conservées et utilisées sur iOS, Android et Windows, pendant plus d’une décennie. La trajectoire de onze ans n’est pas une ligne sur un CV — c’est la preuve que les décisions ci-dessous ont été prises sous la pression d’un logiciel qui devait continuer à fonctionner après le lancement.

Je travaille natif d’abord. Sur iOS cela signifie Swift et Objective-C avec SwiftUI, Core Data, Core Animation et SiriKit ; sur Android cela signifie Kotlin et Java contre l’Android SDK sur de nombreuses versions d’OS. Cette fluidité native est exactement ce qui fait du travail multiplateforme — React Native et Flutter à un niveau avancé, Xamarin à un niveau opérationnel — un choix délibéré plutôt qu’un moyen d’éviter une plateforme.

Et une application mobile n’est jamais seulement le client. Derrière elle se trouvent des backends en Node, Spring Boot, Django, Flask, Rails et Go, exposant REST et GraphQL, soutenus par SQLite sur l’appareil et Redis sur le serveur, déployés sur Firebase, AWS et Google Cloud. La page qui suit est toute cette surface, racontée telle que je la construis vraiment.

La première décision sur tout projet mobile, c’est sur quoi construire, et c’est rarement la même réponse deux fois. La matrice ci-dessous est ma façon de raisonner : iOS et Android natifs chacun dans son propre langage, deux stacks multiplateformes que je maîtrise à un niveau avancé, et une surface Windows qui garde honnête la logique partagée. Le diagramme mappe les langages et frameworks sur les plateformes plutôt que de prétendre qu’un seul outil couvre tout.

Un panneau de code est plus honnête qu’une liste de fonctionnalités — c’est la forme du travail iOS, pas une description de celui-ci.

Sur iOS je m’appuie sur SwiftUI pour les nouvelles surfaces et Core Data pour le graphe d’objets derrière elles. L’extrait ci-dessous est du genre que j’écris quotidiennement : un modèle petit et typé, un fetch que la vue peut observer, et une mise en page qui reste déclarative. C’est délibérément ordinaire — l’intérêt de la fluidité native, c’est que le code de routine soit propre, pas malin.

Une application mobile est une pile de couches claires — et la discipline, c’est de les garder claires pour que chacune puisse être testée et remplacée seule.

Quelle que soit la plateforme, l’architecture vers laquelle je me tourne est la même dans l’esprit : une couche UI qui ne fait que rendre l’état, une couche domaine qui tient la logique, une couche données qui parle au réseau et au magasin de l’appareil, et une frontière de sync entre les deux. Le diagramme montre les couches et la direction unique vers laquelle pointent les dépendances.

Garder les flèches pointant dans un sens, c’est ce qui rend l’application maintenable un an plus tard — l’UI n’atteint pas le réseau, et le réseau ne connaît pas l’UI. La même forme tient que le client soit Swift, Kotlin, React Native ou Flutter.

Un téléphone traverse tunnels, ascenseurs et zones mortes. Une application qui suppose la connectivité est une application qui reste bloquée sur un spinner devant un vrai utilisateur.

Je construis des applications mobiles offline-first : l’appareil écrit immédiatement dans SQLite et met le changement en file pour sync, de sorte que l’utilisateur n’attend jamais le réseau pour voir sa propre action prendre effet. Quand la connectivité revient, la file se vide sur le contrat REST ou GraphQL, et les conflits sont résolus par une politique décidée par entité avant même d’en avoir besoin.

Le diagramme trace cette boucle — écriture locale, file, sync, réconciliation — et le mode de défaillance est la partie qui compte : l’application dégrade en lecture seule plutôt que de perdre une écriture en silence. C’est la différence entre une application en laquelle les utilisateurs ont confiance et une qu’ils abandonnent.

Les stacks multiplateformes permettent à une équipe de livrer les deux stores depuis une seule base de code, et je maîtrise React Native et Flutter à un niveau avancé. Mais la raison pour laquelle je leur fais confiance, c’est que j’ai livré natif d’abord : je sais exactement ce que le pont m’épargne et où il gêne. Quand un écran a besoin de Core Animation, d’un capteur que le pont n’expose pas proprement, ou d’un comportement de plateforme que l’abstraction masque, je descends à un module natif sans hésiter.

Xamarin se situe à un niveau opérationnel dans la boîte à outils, ce qui est la bonne réponse dans les organisations orientées .NET où le reste de la stack est déjà en C#. La décision entre eux n’est jamais une affaire de loyauté — c’est d’ajuster la stack à l’équipe et au produit, avec le natif toujours disponible en dessous.

Un produit mobile est rarement seulement l’application. Il y a des pages d’onboarding, des surfaces marketing, des web views embarquées et de la logique partagée qui veulent tous le même soin que le code natif. Je les construis en HTML5 et CSS3 propres, j’organise les styles avec SASS/SCSS pour que le design system reste un système, et j’écris la logique en JavaScript moderne — ES6+ et TypeScript partout où le projet tolère un système de types.

TypeScript en particulier se rembourse sur mobile : un contrat typé attrape le décalage entre client et serveur avant qu’un utilisateur ne le voie, et les mêmes types peuvent circuler du schéma GraphQL jusqu’au client React Native.

Les plateformes et frameworks changent avec le produit ; les principes, non. Voici les règles que j’applique que l’application soit Swift natif, Kotlin natif, React Native ou Flutter — la partie qui a transformé onze ans de travail mobile en applications qui ont continué à fonctionner plutôt qu’en un portfolio de lancements.