Réponse courte. Vous ne contrôlez ni quand un client met à jour, ni s'il le fait ; vous contrôlez ce que l'application fait au démarrage et ce que l'API répond. Donc : chaque appel porte la version de l'application, l'API ajoute des champs et n'en retire jamais sans date, les anciennes routes sont maintenues jusqu'à une date écrite, et c'est le serveur qui décide qui voit un bandeau souple et qui voit un écran de mise à jour requise. La nouvelle version part sur les deux stores par déploiement progressif, 5 % puis 20 % puis 100 % sur Android, sept jours par phases sur iOS, avec un seuil de plantage écrit avant et un arrêt si on le franchit. Les textes, écrans et promotions passent par des drapeaux et par l'API, pas par une soumission. Un correctif critique part en un jour, par le même chemin. La version minimale n'est relevée qu'après 90 % d'adoption, jamais le jour de la sortie.
Ce guide s'adresse au gérant dont l'application est installée chez des centaines de clients ou de livreurs, au fondateur installé en France qui ne peut pas tester sur les téléphones de ses utilisateurs en Algérie, et au responsable qui doit comparer deux devis de maintenance. Il ne redit pas ce que coûte une application chaque année, décrit dans le guide sur la vie d'une application, ni comment on livre une plateforme web sans la casser, décrit dans le guide sur la livraison ; il décrit ce qui se construit pour qu'une mise à jour mobile soit un événement sans risque, et il prolonge notre page sur les applications mobiles.
Ce que les stores disent
La validation est plus rapide que ce qu'on croit, et moins que ce qu'il faudrait pour un correctif. Apple écrit que l'App Review traite « au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures », et qu'une revue accélérée peut être demandée « pour corriger un bogue critique », avec les étapes de reproduction. Ce que cela impose : un correctif critique iOS est une affaire d'un à deux jours même avec la demande accélérée, et c'est pour cela que l'application doit pouvoir continuer à marcher pendant ce temps, avec la fonction en cause désactivée par un drapeau servi par l'API.
Le déploiement progressif existe sur les deux stores, mais pas de la même façon. Sur l'App Store, la diffusion par phases « libère la mise à jour progressivement sur 7 jours », 1 %, 2 %, 5 %, 10 %, 20 %, 50 % puis 100 % des utilisateurs en mise à jour automatique, peut être mise en pause « jusqu'à 30 jours », et n'empêche personne de télécharger la version à la main. Sur Google Play, le déploiement par étapes est piloté à la main : vous choisissez le pourcentage, vous le relevez, et vous pouvez « arrêter un déploiement par étapes » si vous trouvez un problème, auquel cas « aucun utilisateur supplémentaire ne recevra » la version, ceux qui l'ont déjà la gardant. Ce que cela impose : sur iOS on surveille et on met en pause ; sur Android on décide chaque palier, et le palier suivant n'est franchi que lorsque le taux de plantage du jour est sous le seuil.
Le store peut proposer la mise à jour dans l'application elle-même. Les mises à jour dans l'application de Google Play, prises en charge « sur les appareils exécutant Android 5.0 ou plus », offrent deux parcours : le parcours « flexible », téléchargement en arrière-plan pendant que l'utilisateur continue, et le parcours « immédiat », un écran plein qui « exige de l'utilisateur qu'il mette à jour et redémarre l'application pour continuer ». Apple n'a pas d'équivalent : sur iOS, l'écran de mise à jour requise est le vôtre, et il renvoie vers l'App Store. Enfin, chaque année, Google Play relève l'API cible exigée pour les mises à jour, Android 16 au 31 août 2026 selon la page d'aide, et une application en retard « cesse d'être disponible pour les nouveaux utilisateurs » dont le téléphone est plus récent que sa cible, les utilisateurs existants la gardant. Ce que nous n'avons pas trouvé : une répartition publique des versions Android en Algérie ; ce que nous voyons sur nos projets, c'est encore des téléphones de 2019, et nous le disons comme une observation.
Une mise à jour mobile, en cinq couches
Avant le jour par jour, les cinq couches, et celle qui rend les quatre autres possibles.
Le téléphone du client : l'application installée, sa version, sa base locale, le système, parfois un Android de 2019 ; vous ne décidez ni quand il met à jour, ni s'il le fait. Les stores : la validation, le déploiement progressif ou par phases, l'arrêt ou la pause, la mise à jour dans l'application, et les exigences annuelles de version cible. Votre API : la version de l'application lue à chaque appel, la version minimale acceptée, les champs ajoutés jamais retirés, les anciennes routes maintenues jusqu'à une date ; c'est la couche qui doit parler à toutes les versions installées en même temps, et c'est elle qui décide qui doit mettre à jour.
L'observabilité : plantages pour mille sessions par version, adoption par jour, erreurs d'API par version, appareils et systèmes réellement présents ; le seuil est écrit avant le déploiement, et le chiffre est lu chaque matin pendant dix jours, sur un écran bâti comme le tableau de bord du gérant. Le processus : gel du code, tests sur appareils anciens, train de versions à dates fixes, notes de version, correctif en un jour, drapeaux de fonctionnalité. Une application dont l'API casse les anciennes versions n'a pas le choix : elle doit tout mettre à jour d'un coup, et c'est précisément ce qu'on ne peut pas faire sur des téléphones qu'on ne contrôle pas ; tout le reste découle de cette phrase.
«Une application dont l'API casse les anciennes versions doit tout mettre à jour d'un coup, et c'est précisément ce qu'on ne peut pas faire sur des téléphones qu'on ne contrôle pas.»
Une mise à jour, jour par jour, sur les deux stores
Une version se comprend sur dix jours, deux pistes, et un arrêt.
Jour 0 : tests internes sur Android via la piste interne, soumission sur iOS. Jour 1 : 5 % des clients Android reçoivent la version ; iOS est validée. Jour 2 : 5 % maintenus, le taux de plantage est à 0,5 pour mille sessions, sous le seuil de 1,0 ; iOS commence sa phase à 1 %. Jour 3 : passage à 20 % sur Android, et le chiffre du matin dit 2,1 : un plantage au paiement sur certains Android anciens, que les 5 % n'avaient pas montré parce qu'ils ne comptaient pas assez de ces téléphones. Le déploiement est arrêté ; personne au-delà de 20 % ne recevra cette version. Jour 4 : correctif 2.4.1, testé sur un Android 8, soumis ; la fonction de paiement en cause était déjà désactivée par drapeau la veille au soir, sans soumission, pour les 20 % touchés.
Jour 5 : la 2.4.1 part à 20 %, le taux retombe à 0,3. Jour 6 : 50 %. Jour 7 : 100 % sur Android ; iOS en est à 50 % de sa courbe et finit le jour 8. Pendant ces dix jours, l'API a servi la 2.3 et la 2.4 en même temps : personne n'a été bloqué, et les 71 % de clients encore en 2.3 ont continué à commander. Les chiffres de plantage de ce récit sont un exemple construit ; ce qui ne l'est pas, c'est l'ordre des décisions, et le fait que l'arrêt a été décidé par un chiffre lu le matin, pas par un client au téléphone.
Six types de changement, et le chemin que chacun emprunte
Tout ne passe pas par les stores, et la plupart des changements ne devraient pas.
Un texte, une couleur, un écran : drapeau de fonctionnalité ou contenu servi par l'API ; actif le jour même, pour toutes les versions. Un nouveau champ : ajouté à la réponse, jamais obligatoire ; l'ancienne version l'ignore sans erreur, la nouvelle le lit ; c'est le changement le plus fréquent et il ne coûte rien quand la règle est tenue. Un correctif critique : version corrective le jour même, revue accélérée demandée avec les étapes de reproduction, mise à jour immédiate proposée dans l'application sur Android, écran de mise à jour sur iOS une fois la version visible.
La base locale change : migration versionnée exécutée au démarrage, testée sur une base pleine et sur un appareil ancien, jamais de suppression de colonne dans la même version ; c'est la partie fragile d'une application qui travaille hors ligne, décrite dans le guide sur la synchronisation. Un écran disparaît : drapeau éteint d'abord pour tous, code retiré deux versions plus tard. L'API change de forme : nouvelle route v2, v1 maintenue jusqu'à une date écrite, version minimale relevée après 90 % d'adoption. Quatre des six changements ne passent pas par les stores, ou pas tout de suite ; le réflexe « on sort une version » est réservé à ce qui change vraiment le code installé.
Une seule API, trois versions installées au même moment
La compatibilité ne se décide pas dans l'application mais dans l'API, et elle se voit sur trois téléphones.
Chaque appel porte la version de l'application dans un en-tête, et le serveur répond différemment à chacune. La 2.2, sur un Android de 2019 jamais mis à jour, est sous la version minimale : elle reçoit une réponse qui dit « version trop ancienne », et l'application affiche l'écran de mise à jour requise, avec le lien vers le store et, sur Android, la mise à jour immédiate dans l'application. La 2.3, la version courante chez 71 % des clients, reçoit ses données et un bandeau souple ; le champ ajouté par la 2.4 est présent dans la réponse et elle l'ignore sans erreur. La 2.4 lit les nouveaux champs sur la route v2.
Trois règles tiennent ce dessin. On ajoute des champs, on n'en retire jamais sans date : tant qu'une version servie lit un champ, il reste. Les anciennes routes sont maintenues jusqu'à une date écrite dans le contrat, pas « quand tout le monde aura migré ». La version minimale est relevée par le serveur, après 90 % d'adoption et un taux de plantage stable, jamais le jour de la sortie, et jamais vers une version qui n'est pas encore visible dans les deux stores. Les parts du dessin sont un exemple ; le journal des appels par version, lu chaque semaine, donne les vraies, et c'est lui qui dit quand relever la version minimale.
«On ajoute des champs, on n'en retire jamais sans date ; et c'est le serveur qui décide qui doit mettre à jour.»
Six pannes de mise à jour, et ce que l'architecture fait
Six pannes que nous voyons sur les applications que nous reprenons, et la parade de chacune.
L'application refuse de démarrer sur les téléphones de 2019 : la version minimale du système se décide sur les appareils réellement présents dans le journal, pas sur les statistiques mondiales, et l'ancienne application continue d'être servie. Un champ retiré de l'API fait planter toutes les anciennes versions le même matin : tests de contrat joués contre les trois dernières versions avant chaque mise en production. La migration locale corrompt la base et les commandes hors ligne de la semaine disparaissent : migration testée sur une base pleine, sauvegarde locale avant migration, 5 % d'abord.
Mise à jour forcée vers une version absente : le serveur exige la 2.4 encore en validation, tout le monde est bloqué ; la version minimale n'est relevée qu'une fois la version visible dans les deux stores et adoptée. Le correctif aggrave : sorti sans test à 100 % ; même chemin que toute version. Personne ne regarde : le taux double et on l'apprend par un client ; tableau par version lu chaque matin, alerte au-dessus du seuil. Toutes ces pannes se voient à 5 % avant de se voir à 100 %, et c'est la seule raison du déploiement progressif ; une application reprise d'un prestataire disparu, comme dans le guide dédié, commence par ce tableau.
Vu ailleurs : les documentations des stores, et ce qui se transpose
Trois sources disent l'essentiel. Apple documente la diffusion par phases sur sept jours, la pause jusqu'à trente jours, les délais de revue et la revue accélérée pour un bogue critique ; ce qui se transpose, c'est qu'un correctif iOS est une affaire d'un à deux jours, et que l'application doit tenir ce temps avec la fonction désactivée par drapeau. Google documente le déploiement par étapes piloté à la main, l'arrêt, et les mises à jour dans l'application, flexible ou immédiate ; ce qui se transpose, c'est que chaque palier Android est une décision prise sur le chiffre du matin, et que la mise à jour immédiate est l'outil de la version minimale. Google documente aussi la cible annuelle, Android 16 au 31 août 2026 ; ce qui se transpose, c'est une version de plus dans le train chaque été, planifiée en juin.
Ce que ces sources ne disent pas : quels téléphones ont vos clients, quel seuil de plantage vous acceptez, et combien de versions vous servez en même temps ; le journal des appels par version répond à la première question, le cahier des charges aux deux autres.
Les règles d'une mise à jour qu'on peut livrer sans trembler
Six règles, écrites avant la première version. Chaque appel porte la version de l'application. L'API ajoute et ne retire jamais sans date. Le serveur décide de la version minimale, après l'adoption, jamais le jour de la sortie. Déploiement progressif sur les deux stores avec un seuil de plantage écrit avant et un arrêt possible. Tests sur les appareils réellement présents, dont les anciens, et sur une base locale pleine. Les textes, écrans et promotions passent par des drapeaux, pas par une soumission.
Une septième règle porte sur le devis : « maintenance et mises à jour de l'application » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « version de l'application dans chaque appel ; règle d'ajout sans retrait et routes maintenues jusqu'à une date ; version minimale décidée côté serveur après adoption ; déploiement progressif avec seuil de plantage et arrêt ; mise à jour dans l'application sur Android et écran de mise à jour requise sur iOS ; drapeaux de fonctionnalité ; migrations locales versionnées testées sur base pleine ; tests de contrat contre les trois dernières versions ; tableau de plantages et d'adoption par version ; correctif en un jour par le même chemin ; version de cible Android chaque été », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « la publication sur les stores » a chiffré le jour 0 d'un processus de dix jours.
Six applications, et la mise à jour qui leur fait le plus peur
Six applications que nous maintenons souvent, et pour chacune la mise à jour qui demande le plus de soin.
- L'application des commerciaux terrain, décrite dans le guide dédié. La base locale pleine de commandes de la tournée ; la migration locale est testée sur un téléphone revenu de trois jours sans réseau.
- L'application des livreurs, décrite dans le guide dédié. Deux cents téléphones hétérogènes ; la version minimale du système se décide sur le journal, et la mise à jour immédiate se fait au dépôt, en wifi, pas en tournée.
- L'application de la salle de sport, décrite dans le guide dédié. Le contrôle d'accès doit marcher avec l'ancienne version le jour de la sortie ; le nouveau format de badge est ajouté, l'ancien reste servi.
- L'application de paiement, décrite dans le guide sur le paiement en ligne. Un correctif au paiement part en un jour, et la fonction est coupée par drapeau en attendant.
- L'application de l'agence Omra, décrite dans le guide dédié. Les pèlerins sont à l'étranger pendant la saison ; aucune mise à jour forcée pendant le voyage, drapeaux seulement.
- L'application pilotée depuis la France, décrite dans le guide dédié. Le fondateur ne voit pas les téléphones de ses clients ; le tableau par version est son seul œil, et il le lit chaque matin pendant dix jours.
Le calendrier 2027
Le calendrier est celui d'une version livrée en huit semaines, dont une seule de déploiement.
La semaine 0 à 1 gèle le code et écrit les notes de version, pour le client et pour les stores. La semaine 1 à 2 teste sur les appareils anciens, Android 8 et 10, un iPhone de six ans, un réseau lent, la migration locale sur une base pleine, et joue les tests de contrat contre les trois dernières versions. La semaine 2 à 3 soumet aux deux stores, avec la piste interne Google Play en parallèle. La semaine 3 à 4 est le déploiement progressif, 5 %, 20 %, 50 %, 100 % sur Android et les phases iOS, avec arrêt si le seuil est franchi.
Les semaines 3 à 5 surveillent, plantages et erreurs d'API par version chaque matin, et sortent un correctif en un jour si besoin, par le même chemin. Les semaines 6 à 8 relèvent la version minimale, après 90 % d'adoption et un taux stable ; les retardataires voient l'écran de mise à jour requise. Chaque version est démontrée au client avant soumission, comme le guide sur la livraison le décrit ; et chaque été, le 31 août, la cible Android exigée par Google Play est une version de plus dans le train, planifiée en juin. Le choix entre application native et application web installable, décrit dans le guide dédié, change ce calendrier : une application web installable n'a pas de jour 2 à 3.
Ce qui fait échouer une mise à jour mobile
Les applications que nous reprenons ont presque toujours échoué sur une mise à jour pour l'une de ces raisons.
- L'API qui ne connaît pas la version de l'application. Impossible de savoir qui plante, impossible de forcer qui que ce soit proprement.
- Un champ retiré « parce que plus personne ne s'en sert ». Les 6 % qui s'en servaient appellent le lendemain.
- 100 % d'un coup. Le plantage se voit chez tous les clients au lieu de 5 %.
- La version minimale relevée le jour de la sortie. La version n'est pas encore visible sur l'App Store ; tout le monde est bloqué.
- Les tests sur le téléphone du développeur. Un modèle récent, en wifi, à Alger ; les clients ont des Android de 2019, en 3G, à Sétif.
- La migration locale sans sauvegarde. Les commandes hors ligne de la semaine disparaissent et ne reviennent pas.
- Personne ne regarde le tableau. Le taux de plantage double, et on l'apprend par un client.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et de responsables informatiques.
- Pourquoi la moitié de mes clients ont-ils encore l’ancienne version ?
- Parce que la mise à jour dépend du téléphone : réglages de mise à jour automatique, wifi, espace libre, version du système. Sur iOS, la diffusion par phases ne touche que les utilisateurs en mise à jour automatique, 1 % le premier jour et 100 % le septième ; sur Android, c'est vous qui choisissez le pourcentage. Une application bien construite n'a pas besoin que tout le monde soit à jour : l'API sert plusieurs versions à la fois, et la version minimale n'est relevée qu'après l'adoption.
- Peut-on forcer la mise à jour ?
- Oui, mais par le serveur, pas par l'application : chaque appel porte la version, et au-dessous de la version minimale, l'API répond « version trop ancienne » et l'application affiche l'écran de mise à jour requise, avec sur Android la mise à jour immédiate dans l'application. On ne relève la version minimale qu'après 90 % d'adoption et un taux de plantage stable, et jamais vers une version qui n'est pas encore visible dans les deux stores.
- Combien de temps pour corriger un bogue critique ?
- Un jour pour la version corrective, puis la validation : Apple dit traiter au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48, et une revue accélérée peut être demandée pour un bogue critique. Pendant ce temps, la fonction en cause est désactivée par un drapeau servi par l'API, sans soumission, et l'application continue de marcher.
- Faut-il tout faire passer par les stores ?
- Non. Les textes, l'ordre des écrans, les promotions et les contenus passent par des drapeaux et par l'API, actifs le jour même pour toutes les versions. Un nouveau champ est ajouté à l'API sans soumission. Seul ce qui change vraiment le code installé, un écran nouveau, une base locale modifiée, un correctif de plantage, passe par une version.
- Comment tester sur des téléphones que je ne vois pas ?
- Le journal des appels par version et par appareil dit quels téléphones et quels systèmes sont réellement présents chez vos clients ; nous testons sur ces modèles-là, dont les anciens, et sur un réseau lent. Puis le déploiement progressif fait le reste : 5 % des clients sont le dernier test, et le seuil de plantage décide de la suite.
- Que se passe-t-il avec Google Play chaque année ?
- Chaque 31 août, Google Play relève la version Android cible exigée pour les mises à jour, Android 16 au 31 août 2026 selon sa page d'aide ; une application en retard cesse d'être proposée aux nouveaux utilisateurs dont le téléphone est plus récent que sa cible, les utilisateurs existants la gardant. C'est une version de plus dans le train, planifiée en juin, et un poste du contrat de maintenance.