Réponse courte. Une application livrée coûte chaque année quatre choses : les comptes stores (99 dollars par an chez Apple, 25 dollars une fois chez Google), le serveur et le domaine (de quelques milliers à quelques dizaines de milliers de dinars par mois selon l'hébergeur), les services consommés (SMS de connexion, notifications, cartes, paiement) et, surtout, des jours d'ingénieur pour suivre Android en juin, iOS en septembre, les exigences des stores à dates fixes, les bibliothèques et les correctifs que l'usage révèle. Les trois premiers postes se lisent sur des factures ; le quatrième décide du budget. L'ordre de grandeur que nous donnons depuis 2026, quinze à vingt-cinq pour cent du coût de construction par an, reste valable ; ce guide montre d'où il vient.
Il s'adresse au fondateur, en Algérie ou en France, qui vient de faire livrer une application, à l'entreprise dont l'application a été construite par un prestataire qui ne répond plus, et à celui qui compare des contrats de maintenance. Il ne traite pas du prix de construction, que nous détaillons dans connaître le prix total d'une application avant de commencer, ni de la reprise d'un projet bloqué, décrite dans mon application est bloquée chez un développeur disparu. Il traite de l'année qui suit la mise en ligne.
Ce qui change chaque année, avec les dates
Les deux stores imposent des exigences à dates fixes, et elles reviennent tous les ans. Côté Google, la page de règles de Google Play indique que les nouvelles applications et les mises à jour doivent cibler Android 16 (API 36) au plus tard le 31 août 2026, et que les applications existantes doivent cibler au moins Android 15 (API 35) à la même date ; une application qui ne cible pas une version récente dans les deux ans de la dernière version majeure d'Android cesse d'être visible pour les nouveaux utilisateurs sur les appareils récents, et une mise à jour qui ne respecte pas la cible est bloquée. La date se répète d'une année sur l'autre avec une version de plus. Côté Apple, la page des exigences à venir indique que depuis le 28 avril 2026, toute application envoyée sur App Store Connect doit être compilée avec Xcode 26 et le SDK d'iOS 26 ; l'année précédente, l'exigence équivalente (Xcode 16, SDK iOS 18) datait du 24 avril 2025. Là aussi, la fenêtre revient chaque printemps.
Les systèmes eux-mêmes changent à rythme fixe : Android 17 est sorti en version stable mi-juin 2026 sur les Pixel, après Android 16 le 10 juin 2025 ; iOS 26 est sorti le 15 septembre 2025 et son successeur suivra en septembre 2027 si le rythme se maintient. Chaque version apporte des changements de permissions, de notifications, de caméra ou de stockage qui cassent des applications non testées. Pour une application Flutter, le calendrier officiel prévoit quatre versions stables par an (3.41 en février, 3.44 en mai, 3.47 en août, 3.50 en novembre 2026), et les bibliothèques de paiement, de cartes ou de notifications suivent leur propre rythme.
En Algérie, la priorité est claire : selon StatCounter, Android représente environ 88 à 89 % des mobiles au milieu de 2026, iOS environ 11 %. L'échéance du 31 août chez Google est donc celle qui touche presque tous vos utilisateurs ; celle d'Apple touche les clients les plus équipés, souvent ceux qui paient. Les frais de compte sont connus : 99 dollars par an pour l'Apple Developer Program, 25 dollars une fois pour Google Play, et, pour un compte Google personnel créé après le 13 novembre 2023, un test fermé avec au moins douze testeurs pendant quatorze jours avant la publication. Ces montants se paient par carte internationale ; depuis l'Algérie, c'est souvent la pièce la plus compliquée du budget, et une raison de plus pour que les comptes soient au nom de l'entreprise et non du développeur.
L'année 1 en six moments
Une application ne vieillit pas de façon continue. Elle vieillit par à-coups, à six moments que l'on peut mettre dans un calendrier.
La première semaine se passe sur les comptes et les fiches : les captures, la description en arabe et en français, la première note et les premiers avis, qui pèsent longtemps. Le premier mois apporte les retours que les tests n'avaient pas vus, parce que les téléphones des utilisateurs ne sont pas ceux du développeur : une surcouche Android particulière, un écran étroit, une version ancienne. Le troisième mois, les bibliothèques ont bougé : paiement, cartes, notifications, et la mise à jour d'une seule entraîne souvent les autres.
Juin et septembre sont les mois des nouveaux systèmes, Android puis iOS, avec leurs permissions et leurs comportements changés. Le 31 août est la date de Google : une mise à jour qui ne cible pas la version exigée est refusée. Le douzième mois apporte les renouvellements, Apple, domaine, certificats, et le bilan qui décide des évolutions de l'année suivante. Les moments 04, 05 et 06 reviennent chaque année ; ils sont la raison pour laquelle une application a besoin d'un calendrier et pas seulement d'un numéro à appeler.
Les cinq postes
Le budget d'une année se décompose en cinq postes. Les quatre premiers se lisent sur des factures ; le cinquième se chiffre en jours.
Les comptes et les stores sont le poste le plus petit et le plus visible. Le serveur et le socle comprennent la machine, le domaine, les certificats, les sauvegardes et la supervision ; un guide comparatif d'août 2026 relève des offres publiques d'hébergeurs algériens allant d'environ 1 900 dinars par mois pour un petit serveur virtuel à plusieurs dizaines de milliers de dinars pour une machine sérieuse, hors taxes et hors sauvegardes selon les cas ; un serveur européen se paie en euros par carte internationale. L'emplacement des données se décide avec la loi 18-07 en tête. Les services consommés sont facturés à l'usage : chaque code de connexion par SMS, chaque notification, chaque appel à une API de cartes, chaque transaction par la plateforme de paiement agréée.
Le code est le poste qui pèse. Il faut suivre deux systèmes, un framework et des bibliothèques qui changent, tester sur les bêtas avant les sorties, publier les montées de version avant les dates des stores, et corriger ce que l'usage révèle. Le produit, enfin, regroupe les évolutions que les utilisateurs demandent une fois qu'ils utilisent l'application ; ce poste se budgète à part, parce qu'il dépend du succès, mais il ne doit pas consommer les jours réservés au code, sinon les dates sont manquées. Nous détaillons les durées de ces travaux dans combien de temps pour développer une application ou une plateforme.
«Les factures des stores et du serveur se lisent ; les jours d'ingénieur se décident. C'est eux qui font le budget.»
Un exemple chiffré
Un exemple sur des hypothèses, à refaire avec vos chiffres : une application pour une PME, cinq mille utilisateurs actifs, Android et iOS, un serveur, des codes de connexion par SMS.
Les stores : 99 dollars pour Apple, soit environ 13 000 dinars au cours officiel d'avril 2026 (132,12 dinars pour un dollar selon la Banque d'Algérie, rapporté par ObservAlgérie) ; le compte Google est déjà payé. Le serveur et le domaine : entre 5 000 et 15 000 dinars par mois selon l'hébergeur et la taille, soit 60 000 à 180 000 dinars sur l'année, sauvegardes comprises si vous les exigez. Les SMS : nous n'avons trouvé aucun tarif public en dinars pour les SMS professionnels en Algérie ; sur une hypothèse de 3 dinars par message et de quatre codes par utilisateur et par an, cela fait environ 60 000 dinars, à vérifier avec l'agrégateur ou l'opérateur.
Les jours d'ingénieur : deux cycles de systèmes à cinq jours chacun (tests sur les bêtas, permissions, publication), cinq jours pour les exigences des stores et les montées de version, dix jours de dépendances et de correctifs répartis sur l'année : environ vingt-cinq jours. C'est ce chiffre, multiplié par le taux journalier de votre prestataire, qui fait le budget ; les factures du dessus pèsent moins qu'un mois de ce poste. Si votre application a coûté X à construire, vingt-cinq jours représentent en général entre quinze et vingt-cinq pour cent de X, ce qui rejoint l'ordre de grandeur donné dans le prix d'une application mobile en Algérie. Une application sans paiement ni SMS, interne à l'entreprise, tombe en dessous ; une application qui encaisse, avec des pics le week-end, monte au-dessus.
Six pannes silencieuses
Aucune de ces pannes ne prévient. Deux ont une date fixe ; quatre arrivent quand personne ne regarde.
La mise à jour refusée par Play est la plus fréquente : la cible Android n'a pas été montée avant le 31 août, et la mise à jour de septembre, celle qui corrige justement un plantage, est bloquée jusqu'à ce que le code soit adapté. L'envoi refusé par Apple arrive au printemps, quand un projet compilé avec un Xcode de l'année précédente n'est plus accepté. Le domaine ou le certificat expiré produit le message le plus trompeur, « l'application ne marche plus », alors que le serveur tourne ; le renouvellement automatique et une alerte trente jours avant suffisent.
Le crédit SMS épuisé coupe les connexions et les inscriptions d'un coup, souvent un soir de fin de mois ; un seuil d'alerte et un second fournisseur règlent le problème. La dépendance avec une faille ne se voit pas tant que personne ne l'exploite ; une revue des bibliothèques à chaque cycle, avec mise à jour testée, est la seule parade. La nouvelle permission de l'OS, caméra, localisation, notifications, casse une fonction pour les utilisateurs qui ont mis leur téléphone à jour, et seulement eux, ce qui rend la panne difficile à reproduire si l'on n'a pas testé sur les bêtas.
«Une application ne vieillit pas lentement : elle vieillit le 31 août, et fin avril.»
Depuis la France : faire vivre une application qu'on ne voit pas
Le fondateur de la diaspora a un avantage et un risque. L'avantage : la carte internationale qui paie Apple, le serveur européen et les API est entre ses mains. Le risque : il ne voit ni les plantages, ni les avis, ni le crédit SMS, et il l'apprend par un cousin ou par un client.
La réponse tient en trois pièces. Les comptes à votre nom dès la première semaine : Apple, Google, domaine, serveur, SMS, paiement, avec le prestataire en accès délégué et non en propriétaire. Un tableau de bord qui montre les plantages par version, les installations, les avis, le solde SMS et l'état du serveur, consulté en cinq minutes par semaine depuis Paris ou Lyon. Un rapport mensuel écrit, une page, qui dit ce qui a été publié, ce qui a été corrigé, ce qui arrive aux dates des stores. C'est la même logique que nous décrivons pour gérer son commerce en Algérie depuis la France : voir à distance ce qui se passe, et décider sur des chiffres plutôt que sur des appels.
Qui s'en occupe
Six façons de faire vivre une application, de ne rien faire à la reprise d'un projet abandonné.
Ne rien faire ne coûte rien la première année ; la deuxième, une mise à jour est refusée, puis l'application devient invisible pour les nouveaux utilisateurs sur les téléphones récents, exactement ce que la règle de Google prévoit. Le développeur interne est réactif et connaît le code, mais il est seul à savoir ; quand il part, le calendrier part avec lui. Le freelance à l'appel corrige ce qu'on lui signale ; personne ne regarde les dates ni les dépendances. Le contrat d'heures avec une agence donne un budget connu, mais les heures partent dans les urgences et les mises à jour planifiées sont repoussées.
Le contrat avec supervision et calendrier est celui que nous conseillons pour toute application qui encaisse ou qui sert des clients : les dates sont tenues, les pannes vues avant les utilisateurs, et le coût est fixe, y compris les mois calmes. La reprise d'une application abandonnée commence par un audit écrit et la récupération des comptes ; parfois le code se met à jour et la maintenance reprend, parfois il faut réécrire, ce que nous détaillons dans reprendre un projet bloqué. Dans tous les cas, ce qui distingue un contrat sérieux est simple : il contient un calendrier avec les dates de Google et d'Apple, une supervision, et un rapport mensuel.
Le calendrier 2027
Deux mises à jour planifiées par an, en juillet et en octobre, couvrent presque tout ; les correctifs se glissent entre les deux.
Janvier et février : le bilan et les dépendances, et surtout le budget écrit de l'année, avec les jours réservés au code. Avril : la fenêtre Apple, si l'exigence revient fin avril comme en 2025 et en 2026, avec Xcode et le SDK de l'année. Juin : le nouvel Android, tests sur la bêta puis sur la version stable, permissions et notifications. Juillet : la mise à jour qui monte la cible Android avant le 31 août, c'est la date la plus importante de l'année pour une application algérienne.
Septembre : le nouvel iOS, tests et correctifs. Octobre : la seconde mise à jour planifiée, qui porte aussi les évolutions demandées. Novembre et décembre : les renouvellements, Apple, domaine, certificats, et la préparation de l'année suivante. Ce calendrier se construit en novembre, avant la mise en ligne, comme nous le recommandons dans créer une application mobile en 2027 : le budget de maintenance se décide avec le budget de construction, dans le même document.
Ce qui fait échouer ce type de contrat
- Les comptes au nom du développeur. Apple, Google, domaine, serveur, SMS : au nom de l'entreprise dès la première semaine, sinon chaque renouvellement dépend de quelqu'un d'autre.
- Un contrat sans dates. « Réactivité sous 24 heures » ne dit rien du 31 août ; un contrat sérieux contient les fenêtres de Google et d'Apple.
- Les heures mangées par les urgences. Si les jours réservés au code servent aux évolutions, les montées de version sont manquées.
- Pas de tests sur les bêtas. Découvrir un nouvel Android le jour de sa sortie, c'est le découvrir en même temps que les utilisateurs.
- Un seul fournisseur de SMS, sans seuil. Le crédit tombe à zéro un vendredi soir, et plus personne ne se connecte.
- Le code non versionné, ou versionné chez le prestataire. Le dépôt est à vous, avec l'historique ; c'est ce qui rend une reprise possible.
- Aucun tableau de bord. Sans plantages par version et sans solde SMS visibles, la panne est signalée par les clients.
Questions fréquentes
- Combien coûte la maintenance d'une application mobile par an en Algérie ?
- Les factures fixes sont petites : 99 dollars par an pour Apple, le serveur de quelques milliers à quelques dizaines de milliers de dinars par mois, les SMS et les API à l'usage. Le poste qui décide est le code : environ vingt-cinq jours d'ingénieur par an pour une application courante avec paiement et SMS, à multiplier par le taux journalier de votre prestataire. En général, cela représente quinze à vingt-cinq pour cent du coût de construction.
- Que se passe-t-il si je ne mets jamais à jour mon application ?
- Selon la règle de Google Play, une mise à jour qui ne cible pas la version Android exigée est refusée, et une application qui ne cible pas une version récente dans les deux ans de la dernière version majeure cesse d'être visible pour les nouveaux utilisateurs sur les appareils récents. Chez Apple, une application envoyée avec un SDK trop ancien est refusée depuis la fenêtre de fin avril. Les utilisateurs existants gardent l'application, mais elle finit par casser sur les nouveaux téléphones.
- Quelles sont les dates à retenir en 2027 ?
- Fin avril pour l'exigence de SDK d'Apple, si elle revient comme en 2025 et en 2026 ; juin pour le nouvel Android ; le 31 août pour la cible Android imposée par Google Play ; septembre pour le nouvel iOS. Google et Apple peuvent déplacer ces dates ; le contrat doit prévoir une marge.
- Faut-il héberger en Algérie ou en Europe ?
- Les deux se font. Les hébergeurs algériens publient des offres de serveurs virtuels à partir d'environ 1 900 dinars par mois, payables en dinars ; un serveur européen se paie en euros par carte internationale. La décision se prend avec la loi 18-07 sur les données personnelles et avec le lieu où se trouvent vos utilisateurs.
- Je suis en France, comment suivre une application utilisée en Algérie ?
- Les comptes à votre nom, un tableau de bord des plantages, installations, avis et solde SMS, et un rapport mensuel écrit du prestataire. Vous voyez l'état de l'application en cinq minutes par semaine, sans dépendre d'un appel.
- Mon prestataire ne répond plus, l'application est en ligne, que faire ?
- Récupérer d'abord les comptes, Apple, Google, domaine, serveur, SMS, puis faire auditer le code et les dépendances. Si le code se met à jour, la maintenance reprend avec un calendrier ; sinon il faut réécrire en reprenant les données et les utilisateurs. Nous décrivons la démarche dans le guide sur la reprise d'un projet bloqué.