Des applications mobiles pour iOS et Android.

Presque tout projet mobile commence par cette question, et la plupart des réponses sont livrées comme une idéologie. C'est un choix technique avec un petit nombre de paramètres réels, et il se règle en général en un après-midi une fois ces paramètres posés sur la table.

Le cross-platform est le bon choix par défaut quand

• L'application est faite d'écrans, de formulaires, de listes, de médias et d'appels API — ce qui décrit la plupart des produits que l'on fait construire.
• iOS et Android doivent sortir ensemble, depuis une seule équipe et un seul backlog.
• Votre propre langage visuel compte davantage que la reproduction exacte des contrôles standards de chaque plateforme.
• Le budget doit couvrir deux plateformes, et une seconde équipe native n'est pas envisageable.

Le natif justifie son coût quand

• L'application vit sur le matériel : Bluetooth Low Energy en continu, chaînes de traitement de la caméra, capteurs, réalité augmentée, comportement précis en arrière-plan.
• Elle dépend d'un SDK fournisseur livré uniquement pour Swift et Kotlin, sans passerelle maintenue.
• Elle s'appuie sur des surfaces du système qui sont natives par définition — widgets d'écran d'accueil, activités en direct, applications de montre, extensions de partage, intégration profonde au système.
• Une plateforme est le produit et l'autre est une arrière-pensée.
• Une équipe maintient déjà un code natif que vous étendez plutôt que vous ne remplacez.

Ce n'est pas non plus tout ou rien. Une application cross-platform peut appeler du code natif là où elle en a besoin, et une application native peut héberger un écran cross-platform. Ce qui décide de la forme, c'est l'endroit où se situent les dix pour cent difficiles, pas les quatre-vingt-dix pour cent faciles.

La maquette montre les écrans. La construction, ce sont les écrans plus tout ce que les deux plateformes exigent autour, et c'est cette seconde liste qui fait déraper les projets mobiles.

• L'onboarding et les permissions : demander les notifications, la caméra, les photos ou la localisation à un moment où l'utilisateur comprend pourquoi — et se comporter correctement quand la réponse est non.
• La gestion du compte : connexion, réinitialisation du mot de passe, expiration de session sur un appareil que l'on garde des années, et suppression du compte depuis l'application, qu'Apple exige de toute application permettant de créer un compte.
• Sign in with Apple, qu'Apple exige dès que vous proposez d'autres connexions tierces.
• Les paiements : les biens physiques et les services du monde réel passent par un prestataire de paiement ordinaire. Les contenus numériques et les abonnements consommés dans l'application passent par la facturation de l'App Store et de Google Play, avec la commission de la plateforme et la validation des reçus qui vont avec.
• Le rapport de plantage et l'analytique produit branchés avant le lancement, parce que les plantages de la première semaine sont ceux qui fixent votre note.
• Une politique de confidentialité, la déclaration de confidentialité d'Apple et le formulaire de sécurité des données de Google — qui doivent tous deux correspondre à ce que l'application envoie réellement.
• Les éléments de store : icône, captures d'écran à chaque taille d'appareil exigée, descriptions et mots-clés dans chaque langue publiée.
• Le comportement hors connexion, les états vides, les états d'erreur, et ce que fait l'application sur une connexion lente dans un ascenseur.

Rien de tout cela n'est optionnel et rien n'apparaît dans un fichier de design. Nous le chiffrons explicitement, pour que ce soit payé une fois, au départ, au lieu d'arriver sous forme de petites surprises successives.

Les deux stores examinent les applications et les deux en rejettent. Les rejets sont en général procéduraux plutôt que fatals, mais chaque aller-retour coûte des jours. L'objectif est de soumettre une application qui a déjà répondu aux questions du relecteur.

Comptes et signature

Le compte Apple Developer Program et le compte Google Play Console vous appartiennent, au nom de votre société. Un compte d'organisation côté Apple demande un numéro D-U-N-S, dont l'obtention prend du temps : on l'entame donc tôt, et pas la semaine précédant le lancement. Nous travaillons dans vos comptes. Les clés de signature et les certificats sont à vous et le restent, parce que les perdre est l'une des rares erreurs vraiment douloureuses sur mobile.

Pourquoi les applications sont rejetées

• Un plantage sur l'appareil du relecteur — la raison la plus fréquente, et la plus facile à éviter en testant exactement le build qui est soumis.
• Pas de compte de démonstration fonctionnel, donc le relecteur ne peut pas franchir votre écran de connexion.
• Des textes de permission qui n'expliquent pas ce que l'application fait de la caméra, de la localisation ou des contacts.
• Des réponses de confidentialité qui ne correspondent pas à ce que l'application envoie, ou une politique de confidentialité absente ou inaccessible.
• Des achats numériques qui contournent la facturation du store.
• Trop peu de fonctionnalités pour justifier une application : une simple enveloppe autour d'un site web, qui ne fait rien qu'un navigateur ne faisait déjà.
• Des captures d'écran ou des descriptions montrant des fonctionnalités que l'application n'a pas.
• Un mur de connexion devant du contenu qui n'a rien à voir avec le fait d'avoir un compte.

Avant la production

Les builds passent d'abord par TestFlight et par la piste de test interne ou fermée de Google Play, sur de vrais appareils, avec les personnes qui assureront le support. Google impose en outre aux nouveaux comptes développeurs personnels de mener un test fermé avant de pouvoir publier au grand public, ce qui est un élément de planning et pas une formalité. Sur Android, les mises en production se déploient par paliers, pour qu'un mauvais build atteigne une fraction des utilisateurs au lieu de la totalité.

Notifications push

Les notifications passent par APNs sur iOS et FCM sur Android. Le travail est moins dans l'envoi que dans le cycle de vie autour : demander la permission à un moment qui obtient un oui, stocker et rafraîchir les tokens d'appareil, écarter ceux qui sont morts, gérer un appui qui doit ouvrir un écran précis depuis un démarrage à froid, et garder une trace de ce qui a été envoyé et à qui. Sur iOS, l'utilisateur doit accepter explicitement : la première demande est donc une décision produit avant d'être une décision technique.

Hors connexion

Un téléphone perd sa connexion en permanence. Décider de ce que fait l'application à ce moment-là est un travail de conception : quelles données sont mises en cache et pour combien de temps, quelles actions peuvent être mises en file et rejouées, et que se passe-t-il quand deux appareils ont modifié le même enregistrement. Nous faisons la version simple délibérément — un cache en lecture seule avec un indicateur honnête de fraîcheur — sauf si le produit a réellement besoin d'écritures hors connexion, auquel cas la résolution de conflits est chiffrée comme un lot de travail à part plutôt que découverte tard.

Liens profonds

Un lien dans un e-mail ou une publicité doit ouvrir le bon écran dans l'application quand elle est installée, et une page web sinon. Cela demande les Universal Links sur iOS et les App Links sur Android : un fichier d'association servi depuis votre domaine et vérifié par le système, plus un routage interne qui survit à un démarrage à froid. C'est minutieux, et cela mérite d'être fait correctement, parce que c'est la différence entre une campagne qui convertit et une campagne qui dépose les gens sur un écran d'accueil.

Une application est un client. Presque tout ce qu'elle affiche vient de quelque part, et ce quelque part fait partie du projet même quand le brief ne parle que d'écrans.

• Une API conçue pour un client mobile : peu d'allers-retours, des charges utiles réduites, et un versionnage pour qu'une ancienne application sur le téléphone de quelqu'un continue de fonctionner après un déploiement.
• Une authentification qui survit à un appareil gardé des années : tokens de rafraîchissement, révocation, et une réponse sensée à un mot de passe changé depuis un autre appareil.
• L'infrastructure de push : qui peut envoyer quoi, à qui, avec une trace — plutôt qu'une console que quelqu'un ouvre à la main un vendredi.
• La gestion des fichiers et des médias : envoi depuis un téléphone sur une mauvaise connexion, redimensionnement, stockage, et diffusion à la taille dont l'écran a réellement besoin.
• Un back-office pour vos équipes : retrouver un utilisateur, voir son état, le corriger, sans développeur.
• L'analytique et le suivi des plantages rattachés à de vrais comptes, pour qu'un rapport soit exploitable plutôt qu'un chiffre sur un graphique.

Nous construisons aussi le backend — en général Next.js et PostgreSQL — ou nous nous intégrons à ce que vous exploitez déjà. Dans les deux cas, l'application ne vaut que ce que vaut ce qui se trouve derrière, et une estimation mobile qui ignore le serveur n'est pas une estimation.

Décalage de versions

D'anciennes versions d'une application restent longtemps sur les téléphones, et vous ne pouvez pas forcer les gens à mettre à jour. L'API doit donc les tolérer, et l'application a besoin d'un moyen de dire qu'une version est trop ancienne pour continuer : une vérification au démarrage, un écran qui explique pourquoi, et un lien vers le store. Décider cela tard revient à choisir entre casser des utilisateurs et geler l'API.

Les plateformes mobiles bougent chaque année. Une application laissée intacte pendant un an et demi ne peut souvent même plus être compilée, encore moins publiée.

• Apple exige que les nouvelles soumissions soient compilées avec un SDK récent, ce qui suppose une version à jour de Xcode et les changements système qui l'accompagnent.
• Google Play exige des applications qu'elles ciblent un niveau d'API récent, révisé chaque année, faute de quoi les mises à jour cessent d'être acceptées.
• Chaque version du système change quelque chose de visible : permissions, exécution en arrière-plan, comportement des notifications, invites de confidentialité, mise en page aux bords des nouveaux appareils.
• Les certificats, les profils de provisionnement et les clés push expirent selon leur propre calendrier, en général à un moment inopportun.
• Les dépendances évoluent sous vos pieds, et un seul module natif abandonné peut bloquer une montée de version entière.

Il faut donc prévoir une version de maintenance quelques fois par an même quand le produit ne change pas, et traiter chaque version majeure du système comme un événement connu plutôt que comme une surprise. C'est moins cher que l'alternative, qui est un projet de réanimation le jour où quelque chose finit par casser.

• L'application est en ligne sur les deux stores, sous vos comptes développeurs, avec vos clés de signature en votre possession.
• Le taux de sessions sans plantage et les événements qui comptent sont visibles dans un tableau de bord que votre équipe ouvre sans nous le demander.
• Le processus de mise en production est écrit et reproductible — n'importe qui sur le projet peut produire un build et le publier.
• Le dépôt est à vous, avec son historique, sa configuration de CI et un README qui met un nouveau développeur en route.
• Le backend, les environnements et les comptes tiers sont à vous, documentés, avec les accès transmis.
• Il existe un chemin de support : comment un incident nous parvient, comment il est trié, et ce qui se passe ensuite.

Le lancement est le début de la partie utile. Les premières semaines après la mise en ligne produisent le seul retour qui compte — vrais appareils, vrais réseaux, vrais utilisateurs — et le plan laisse de la place pour en tenir compte.