Réponse courte. Une application hors ligne n'est pas une application qui « garde une copie au cas où » ; c'est une application dont l'écran ne lit que la base du téléphone, dont chaque écriture entre dans une file persistante avec une clé d'idempotence, dont la synchronisation est un travail de fond qui vide la file dans l'ordre quand le réseau revient, et dont le serveur reconnaît une clé déjà vue et renvoie la même réponse au lieu de créer un doublon. Les conflits se règlent par des règles écrites par champ avant le code, et chaque saisie porte un statut visible. Deux semaines d'inventaire, dix semaines de construction, une recette en mode avion, un pilote sur une tournée.
Ce guide s'adresse au distributeur dont les prévendeurs passent la journée dans des marchés couverts, au livreur qui signe dans un sous-sol, à l'agence qui fait des états des lieux dans des caves, à la chaîne de boutiques dont la caisse ne peut pas s'arrêter, et au fondateur installé en France qui a lu « mode hors ligne » dans trois devis sans qu'aucun ne dise ce que cela veut dire. Il ne choisit pas de framework ; il décrit ce qui doit exister pour que la phrase « ça marche sans réseau » soit vraie, et comment on le vérifie.
Ce que les chiffres disent
Le réseau algérien est partout et nulle part. Selon les chiffres de l'ARPCE repris par la presse, 48,7 millions des 54,87 millions d'abonnements mobiles étaient en 4G fin juin 2025, soit 88,8 %, et 51,63 millions d'abonnements 4G et 5G étaient comptés au deuxième trimestre 2026 ; l'UIT estime la couverture 3G et 4G de la population à 99,1 % en 2025, une estimation internationale, pas un relevé du régulateur. Mais les obligations de couverture sont exprimées en population, pas en superficie, et des sources secondaires décrivent des réseaux concentrés sur le couloir du nord ; Algérie Télécom annonçait en février 2026 un plan de 345 nouvelles stations 4G dans 44 wilayas, et la presse de septembre 2026 évoque l'extension des services à 3 000 localités peu denses. Un téléphone couvert à 99 % de la population l'est à zéro dans un marché couvert, un sous-sol, une cave, une chambre froide ou un village entre deux collines, et c'est là que travaillent les gens qui saisissent.
Le réseau s'arrête aussi sur décision. Pendant le baccalauréat, l'Algérie a coupé ou fortement perturbé l'internet fixe et mobile chaque mois de juin de 2018 à 2023 : l'AFP décrivait en 2018 des coupures complètes par créneaux d'une heure, Algérie Télécom parlait en 2021 d'une « restriction » des réseaux de partage pendant la première moitié de chaque épreuve, et TSA notait en 2023 un internet fortement perturbé dès le premier jour. Le bac 2026, qui a débuté le 7 juin, a été le premier sans coupure générale selon TSA et Algérie-Eco. Que les coupures reviennent ou non, une application de terrain construite pour l'Algérie a été conçue pour des journées où le réseau n'est pas une donnée.
Le sujet est écrit depuis longtemps par ceux qui construisent à grande échelle. Le guide d'architecture d'Android définit l'application hors ligne comme celle qui « peut exécuter tout ou une partie critique de ses fonctions sans accès à internet », pose que la source de données locale est la source de vérité canonique dont l'écran doit lire exclusivement, distingue trois stratégies d'écriture, en ligne seulement, en file, différée, et nomme la règle de conflit la plus courante, « la dernière écriture gagne », avec des tâches de fond qui attendent le réseau et réessaient à intervalle croissant. Stripe, de son côté, documente les clés d'idempotence : une clé générée par le client, un identifiant aléatoire suffisamment long, conservée au moins vingt-quatre heures, qui fait qu'une requête rejouée renvoie la réponse enregistrée au lieu de créer un second objet. Ces deux textes disent, à eux seuls, l'essentiel de ce guide ; le reste est l'Algérie et le métier.
La vie d'une saisie hors ligne, en six moments
L'architecture ne se décrit pas par ses composants mais par ce qui arrive à une commande prise à 9 h dans un marché couvert, jusqu'à ce que le dépôt la voie.
L'écriture locale est immédiate : la commande est enregistrée dans la base du téléphone avec un identifiant créé sur place, un identifiant aléatoire long, pas un numéro que seul le serveur peut donner ; l'heure du téléphone et une version. L'écran la montre aussitôt, parce qu'il lit la base locale et rien d'autre. La file d'attente reçoit l'opération, pas seulement la donnée : « créer la commande X », avec sa clé d'idempotence, son horodatage, son nombre d'essais, son statut. La file survit à la fermeture de l'application et au redémarrage du téléphone. Le réseau revient, parfois pour trente secondes dans un ascenseur : une tâche de fond vide la file dans l'ordre d'écriture, une opération à la fois ; en cas d'échec, elle réessaie après une seconde, puis deux, puis quatre, jamais en boucle serrée, parce qu'une boucle serrée vide la batterie et noie le serveur quand mille téléphones retrouvent le réseau à la même minute.
Le serveur reçoit et fait trois choses dans cet ordre : il regarde la clé d'idempotence, et s'il l'a déjà vue, il renvoie la réponse qu'il avait donnée, sans rien refaire ; sinon il vérifie la version de l'enregistrement, et s'il y a conflit, il applique la règle écrite pour ce champ ; puis il applique l'opération et répond. C'est ce moment qui distingue une application hors ligne d'une application qui réessaie. La réconciliation suit : la réponse du serveur contient l'état vrai, le prix validé, le numéro de commande définitif, la ligne refusée ; la base locale se met à jour, et l'écran suit sans que le prévendeur n'appuie sur rien. La preuve est ce que l'utilisateur exige et que les projets oublient : chaque saisie porte un statut, en attente, envoyée, confirmée, rejetée avec sa raison ; le prévendeur sait, à 16 h, ce qui est parti et ce qui ne l'est pas, et il n'appelle pas le dépôt pour le demander. C'est la même preuve que le guide sur la prévente demande pour la visite horodatée.
L'architecture hors ligne, en cinq couches
Derrière les six moments, cinq couches, et la première est une décision, pas une bibliothèque.
La base locale est la seule chose que l'écran lit : catalogue, clients, tarifs, commandes du jour, photos en attente. Elle est synchronisée en lecture par deltas, c'est-à-dire que le téléphone demande au serveur « ce qui a changé depuis ma dernière synchronisation » plutôt que tout le catalogue, ce qui compte sur un forfait et un réseau lents. Une application qui lit le réseau d'abord et « tombe sur le cache » si ça échoue n'est pas hors ligne : elle affiche une roue qui tourne pendant vingt secondes avant de décider qu'elle n'a pas de réseau, vingt fois par jour. La file d'attente est persistante, ordonnée et visible : une table de la base locale, pas une liste en mémoire ; chaque ligne porte la clé, l'horodatage, le nombre d'essais et le statut, et l'écran de l'application peut la montrer. La synchronisation est une tâche de fond, que le système d'exploitation lance quand le réseau revient et que la batterie le permet ; sur Android, c'est le rôle des tâches persistantes que Google documente, avec des réessais à intervalle croissant.
L'API idempotente est la couche côté serveur, et elle est souvent celle qui manque quand un prestataire promet le hors ligne : chaque écriture accepte une clé, le serveur garde la clé et la réponse pendant au moins vingt-quatre heures, et renvoie la même réponse si la clé revient ; chaque enregistrement porte une version, et chaque champ a une règle de conflit écrite avant le code. La supervision vient en dernier et change la vie du chef des ventes : la liste des téléphones dont la file contient des opérations de plus de deux heures, l'âge des données par appareil, les rejets par règle. Un téléphone bloqué depuis le matin est un appel à passer avant 11 h, pas une statistique du soir. Ces couches se construisent sur une API unique, celle décrite dans le guide sur la PWA et le natif : la face native du terrain porte la base locale et la file ; la face web des clients en porte une version plus légère.
«Une application qui lit le réseau et garde une copie au cas où n'est pas hors ligne ; elle est en ligne avec un cache.»
Un exemple chiffré
Un exemple sur des hypothèses de volume, et des exigences qui n'en sont pas : un distributeur, douze prévendeurs, une journée de tournée.
Huit heures n'est pas une hypothèse mais une exigence à écrire dans le cahier des charges : de 8 h à 16 h, le prévendeur doit lire le catalogue, les prix de ce client, son historique et son encours, et saisir des commandes et des relevés de rayon avec photos, sans que l'application ne demande une seule fois le réseau. Si le cahier des charges dit « mode hors ligne » sans dire huit heures et sans dire quoi, trois prestataires liront trois choses. 350 commandes sur douze téléphones dans la journée est notre hypothèse de volume ; ce qui n'en est pas une, c'est le résultat attendu : zéro commande perdue et zéro doublon à l'arrivée au dépôt, parce que chaque commande est écrite localement avant tout et porte une clé que le serveur reconnaît. Sans clé, une journée de réseau instable produit des doublons, et chaque doublon est un camion qui livre deux fois ou un détaillant qui refuse.
Deux minutes entre le retour du réseau et la commande visible au dépôt est notre hypothèse pour une file de trente opérations vidée dans l'ordre contre un serveur qui répond en moins d'une seconde ; elle devient dix minutes si la file contient des photos lourdes non compressées, ce qui se règle en compressant sur le téléphone et en envoyant les photos après les commandes. Une règle par champ est l'exigence qui coûte le moins et évite le plus : le serveur fait foi pour le prix, le téléphone fait foi pour la quantité saisie, le plus récent fait foi pour la note libre, la suppression côté serveur gagne. Les hypothèses à vérifier chez vous : combien d'heures sans réseau vos équipes passent réellement, combien d'écritures par jour et par appareil, et quelle taille font les photos ; une semaine de journal sur deux téléphones répond aux trois.
Six conflits qui arrivent, et la règle qu'on écrit avant le code
Les conflits ne sont pas des cas rares ; ils arrivent la première semaine, et le seul moyen de les rendre inoffensifs est d'avoir écrit la règle avant.
Deux prévendeurs qui modifient le même client hors ligne, l'un le téléphone, l'autre l'adresse : la règle naïve, « la dernière écriture gagne » sur tout l'enregistrement, efface la modification de l'un ; la règle utile fusionne par champ, chaque champ gardant sa modification la plus récente. La même commande envoyée deux fois est le conflit le plus fréquent et le plus coûteux : le réseau coupe après que le serveur a reçu la commande mais avant que le téléphone ait reçu la réponse ; le téléphone réessaie ; sans clé d'idempotence, le dépôt prépare deux fois. Le prix qui a changé pendant la journée se règle en décidant qui fait foi : le serveur, avec un seuil d'écart sous lequel la commande passe au prix saisi, au-dessus duquel elle part en validation chez le chef des ventes.
Le stock devenu insuffisant parce que trois prévendeurs ont vendu le même dernier carton ne se règle pas sur le téléphone, qui ne peut pas connaître le stock en temps réel hors ligne : la commande est acceptée avec une ligne « à confirmer », le dépôt propose la substitution, le détaillant est prévenu, et c'est le mécanisme que décrit le guide sur le portail de commande B2B. Un élément supprimé côté serveur et modifié en local : la suppression gagne, et la ligne passe en « rejetée, produit retiré » avec sa raison, visible du prévendeur, plutôt que de disparaître. L'horloge du téléphone fausse est plus fréquente qu'on ne croit : le serveur horodate à la réception et garde l'heure du téléphone comme information ; l'ordre des opérations vient de la file, jamais de l'horloge. Un septième conflit n'est pas dans le tableau parce qu'il est humain : un prévendeur qui corrige une commande rejetée en la ressaisissant au lieu de la modifier ; le statut « rejetée » avec un bouton « corriger » qui réutilise la clé évite le doublon.
«Ce qui rend un conflit inoffensif n'est pas une bibliothèque, c'est une règle écrite avant le code.»
Six produits : ce qui doit marcher sans réseau, ce qui l'attend
Tout ne doit pas marcher hors ligne, et la liste de ce qui doit l'être est la première chose à écrire.
Le prévendeur a besoin de tout lire et de saisir commandes et relevés ; il n'a pas besoin de la confirmation du dépôt ni du stock réel, qui attendent le réseau avec un statut clair. Le livreur a besoin de sa tournée, du bon, de la signature, de la photo et de l'encaissement avec reçu imprimé ou affiché ; le reçu SMS au client et la mise à jour de l'encours attendent, comme le décrit le guide sur la chaîne du froid et la preuve de livraison. L'état des lieux se fait dans une cave ou sur un toit : la grille complète, les photos horodatées et la signature doivent marcher sans rien, et le rapport part ensuite, comme dans le guide sur l'appartement géré depuis la France. La caisse ne peut pas s'arrêter : vente, ticket, remise, clôture et impression marchent toute la journée sans réseau, et le paiement par carte en ligne, le rapprochement et le tableau de la chaîne attendent, comme le décrit le guide sur la caisse et le paiement par QR.
Le portail ou l'application du client a besoin de moins : lire le catalogue, le panier et les dernières commandes, et saisir une commande qui part en file ; les prix du jour, la confirmation et le paiement attendent le réseau, et c'est acceptable parce que le client n'est pas dans une cave huit heures par jour. Le tableau de bord du gérant est le seul écran qui n'a pas à marcher hors ligne : il montre le dernier état connu avec son heure, sans permettre d'agir, parce que sa vérité est sur le serveur. C'est aussi l'écran que tout le monde demande en premier, et c'est pourquoi il faut l'écrire explicitement dans la colonne de droite : un gérant qui prend une décision sur un tableau de bord « hors ligne » décide sur des chiffres d'hier.
Vu ailleurs : ce que Google et Stripe ont écrit, et ce qui se transpose
Le guide d'architecture d'Android dit trois choses que tout cahier des charges algérien peut recopier. D'abord, que la source de données locale est la source de vérité canonique et que les couches hautes de l'application ne lisent qu'elle, ce qui garantit la cohérence entre les états de connexion. Ensuite, que les écritures relèvent de trois stratégies, en ligne seulement pour ce qui doit se faire en temps réel comme un virement, en file pour ce qui peut attendre sans que l'utilisateur soit prévenu comme des statistiques, différées pour ce qui est critique et doit exister localement d'abord comme une commande ; et que la troisième exige des règles de conflit. Enfin, que la synchronisation est un travail persistant, confié au système, avec des réessais à intervalle croissant et des contraintes comme « réseau connecté ». Ces trois choses se transposent telles quelles, et un prestataire qui ne les connaît pas ne construira pas une application hors ligne.
Stripe documente l'autre moitié, côté serveur : une requête idempotente porte une clé générée par le client, un identifiant aléatoire avec assez d'entropie pour éviter les collisions, jusqu'à 255 caractères ; le serveur enregistre le code et le corps de la première réponse, les renvoie si la clé revient, et peut supprimer les clés après au moins vingt-quatre heures. Ce qui se transpose : la clé par écriture, la réponse rejouée, la durée de conservation. Ce qui ne se transpose pas : l'échelle. Une API de distributeur algérien reçoit quelques milliers d'écritures par jour, pas des millions ; elle peut garder ses clés un mois et journaliser chaque conflit, ce que Stripe ne peut pas se permettre, et c'est un avantage : chaque rejet est lisible par le chef des ventes le soir même.
La recette en mode avion
Une application hors ligne se vérifie en coupant le réseau, et la recette qui ne le fait pas n'a rien vérifié. Les scénarios tiennent sur une page et se jouent sur deux téléphones réels, pas sur un émulateur : saisir dix commandes en mode avion, fermer l'application, redémarrer le téléphone, rallumer le réseau et compter au dépôt ; couper le réseau pendant l'envoi d'une commande, exactement entre la requête et la réponse, et vérifier qu'il n'y a qu'une commande ; modifier le même client sur deux appareils hors ligne et vérifier la fusion par champ ; régler l'horloge d'un téléphone sur l'an dernier ; vider la batterie à 30 % de la file ; charger 2 000 lignes de catalogue et 300 photos et mesurer le temps d'ouverture et de synchronisation sur le téléphone le plus ancien de l'équipe, celui en Android 11 ou 12 que le guide sur la PWA et le natif rappelle être quatre téléphones sur dix.
Chaque scénario a un résultat attendu écrit, et ces résultats sont les critères d'acceptation du cahier des charges, comme le recommande le guide sur le cahier des charges : « dix commandes saisies en mode avion sont au dépôt dans les deux minutes qui suivent le retour du réseau, sans doublon » se vérifie ; « mode hors ligne robuste » ne se vérifie pas. La recette en mode avion est un jalon à part entière, entre la construction et le pilote, et elle dure deux semaines parce qu'elle trouve toujours quelque chose.
Le calendrier 2027
Le calendrier est celui d'une construction en vingt-quatre semaines, dont les deux premières ne produisent pas de code et décident de tout.
Les semaines 0 à 2 font l'inventaire avec le métier : chaque écriture possible dans l'application, sa clé, sa règle de conflit, son statut visible, et la liste de ce qui doit marcher sans réseau pendant combien d'heures. Les semaines 2 à 6 branchent l'écran sur la base locale et construisent la synchronisation de lecture par deltas ; à la fin, l'application lit tout sans réseau. Les semaines 6 à 10 construisent la file, l'API idempotente, les versions et les règles codées, avec les statuts visibles ; c'est le cœur du projet. Les semaines 10 à 12 sont la recette en mode avion. Les semaines 12 à 16 sont le pilote sur une tournée réelle, douze téléphones, avec les files et les rejets observés chaque soir par le chef des ventes et le prestataire ensemble. Les semaines 16 à 20 ajoutent la supervision et étendent à toutes les équipes ; les semaines 20 à 24 font le bilan : pertes, doublons, conflits par règle, et ce qui, finalement, peut rester en ligne seulement. Ce que coûte ensuite une année d'une telle application est détaillé dans le guide sur la vie d'une application ; les délais par type de projet dans le guide sur les délais réels.
Ce qui fait échouer le hors ligne
Les applications « hors ligne » que nous voyons échouer échouent presque toujours pour l'une de ces raisons.
- Lire le réseau d'abord. La roue tourne vingt secondes avant de tomber sur le cache ; l'utilisateur reprend le carnet le troisième jour.
- Une file en mémoire. L'application est fermée par le système ou le téléphone redémarre ; la journée est perdue.
- Pas de clé d'idempotence. Le premier jour de réseau instable produit des doublons, et le dépôt ne fait plus confiance à aucune commande.
- Un identifiant donné par le serveur. La commande ne peut pas exister avant le réseau ; tout le reste est faux.
- « La dernière écriture gagne » sur tout l'enregistrement. L'adresse corrigée par l'un efface le téléphone corrigé par l'autre, sans que personne ne le sache.
- Aucun statut visible. Le prévendeur appelle le dépôt pour savoir ce qui est parti ; le dépôt appelle le prestataire.
- Une recette sans mode avion. Tout marche au bureau avec le Wi-Fi ; rien ne marche au marché couvert, et on l'apprend le jour du pilote.
Questions fréquentes
Les questions que nous recevons de distributeurs, de chaînes de boutiques, d'agences et de fondateurs installés en France.
- Le hors ligne, est-ce une option qu'on ajoute à la fin ?
- Non. Une application dont l'écran lit le réseau ne devient pas hors ligne en ajoutant un cache ; il faut que l'écran lise la base locale, que les écritures passent par une file et que le serveur accepte des clés d'idempotence. Ces trois choses se décident avant la première ligne de code, et c'est pour cela qu'elles sont dans le cahier des charges, avec le nombre d'heures et la liste des écrans.
- Combien d'heures sans réseau faut-il prévoir ?
- Celles que vos équipes passent réellement sans réseau, mesurées une semaine sur deux téléphones avant d'écrire le cahier des charges. Pour une tournée de prévente ou de livraison, huit heures est la règle ; pour une caisse, la journée entière ; pour un client qui commande depuis chez lui, quelques minutes suffisent.
- Que se passe-t-il si deux personnes modifient la même chose ?
- Ce que dit la règle écrite pour ce champ : le serveur fait foi pour le prix, le téléphone pour la quantité saisie, le plus récent pour la note, la suppression côté serveur gagne, les champs d'un même client fusionnent un par un. Quand la règle tranche contre l'utilisateur, il le voit dans le statut, avec la raison.
- Et les photos ?
- Elles sont compressées sur le téléphone, mises en file après les commandes, envoyées quand le réseau est bon et de préférence en Wi-Fi, et liées à leur commande ou à leur état des lieux par l'identifiant créé sur place. Un état des lieux de quarante photos part en quelques minutes sur un bon réseau et en une heure sur un mauvais ; l'utilisateur n'a pas à attendre.
- Une application web installable peut-elle être hors ligne ?
- Pour la lecture et pour une file de commandes légères, oui, sur Android et sur iPhone une fois ajoutée à l'écran d'accueil. Pour huit heures de terrain avec photos, scan et impression, non : c'est le travail de la face native, et le guide sur la PWA et le natif explique où passe la limite.
- Comment vérifier que le prestataire sait faire ?
- Demandez-lui, par écrit, les six scénarios de la recette en mode avion et le résultat attendu de chacun, et demandez à voir la table de la file d'attente et le traitement de la clé d'idempotence côté serveur dans une démonstration. Un prestataire qui a déjà construit du hors ligne a ces réponses en dix minutes.