Article d’archive. Texte préparé le 1 novembre 2026, mis en ligne le 7 novembre 2026.
Une coupure peut faire disparaître la confirmation alors que le serveur a déjà enregistré la commande. Un identifiant conservé sur le téléphone et une règle de déduplication côté serveur rendent cette reprise vérifiable.
Ce problème vient d’une ambiguïté : le téléphone ignore si la première demande a été exécutée. Répéter l’envoi peut être nécessaire, mais la reprise doit préserver l’identité de l’opération. Voici une proposition d’architecture pour une application Android de prise de commande, avec un contrat d’API fictif et des tests reproductibles.
Une base documentaire actuelle, sans promesse de nouveauté
Le guide officiel Android sur les applications offline-first, mis à jour le 14 octobre 2026, décrit l’articulation entre données locales, accès réseau et synchronisation. La documentation des travaux uniques de WorkManager explique comment limiter les tâches concurrentes portant le même nom.
La version stable WorkManager 2.12.0 date du 23 septembre 2026 et relève le minSdk à l’API 24. Une application visant des téléphones plus anciens doit donc vérifier sa stratégie de dépendances. Ces références récentes ne changent pas un point essentiel : organiser les reprises Android ne suffit pas à empêcher un doublon métier sur le serveur.
Séparer le panier, l’opération et la confirmation
Le panier peut rester modifiable tant qu’il n’a pas été envoyé. Au moment de l’envoi, créez une opération durable contenant un identifiant unique, les lignes et la version du catalogue utilisée. Enregistrez cet ensemble localement avant la tentative réseau. Cet enregistrement doit survivre à une fermeture de l’application.
Une fois cette opération mise en attente, ses reprises utilisent le même identifiant et le même contenu. Si le client veut réellement modifier la commande, traitez cette intention séparément : nouvelle opération ou procédure explicite de modification. Réutiliser silencieusement un identifiant pour un autre panier rendrait le diagnostic impossible.
L’interface peut afficher quatre états distincts : enregistré sur le téléphone, en attente d’envoi, confirmation reçue, intervention nécessaire. Une erreur réseau laisse l’opération en attente de résolution. Elle ne doit pas être traduite automatiquement par « commande inexistante », ni déclencher la création d’une nouvelle identité.
Définir un contrat de déduplication côté serveur
La RFC 9110, section 9.2.2, publiée en juin 2022, définit l’idempotence et encadre la répétition des requêtes. Une création par POST n’est pas rendue idempotente par le seul choix du protocole HTTP. Le comportement de reprise doit être prévu dans le service concerné. Le contrat ci-dessous est une proposition applicative, pas une API native d’uniCenta.
{
"operation_id": "demo-commande-001",
"catalogue_version": "demo-v1",
"lignes": [
{
"produit_id": "P-01",
"quantite": 2
}
]
}Pour un endpoint fictif de création de commande, le serveur commence par authentifier le terminal et contrôler ses droits. Il recherche ensuite l’identifiant d’opération dans le périmètre de l’établissement concerné. À la première demande valide, il crée la commande et conserve une correspondance durable entre cet identifiant, le contenu normalisé et le résultat.
La création métier et l’enregistrement de cette correspondance doivent être atomiques, ou intégrés dans une orchestration durable qui assure la même protection. Une contrainte d’unicité en base et un traitement explicite des demandes simultanées sont nécessaires : un simple « rechercher puis insérer » sans protection concurrente laisse une course possible.
À la reprise, un contenu identique doit retrouver la commande déjà créée. Un même identifiant associé à un contenu différent doit produire un conflit explicite. Le serveur valide aussi les produits, quantités et conditions tarifaires applicables ; il ne doit pas accepter un montant arbitraire envoyé par le téléphone comme preuve du prix autorisé.
Conserver la reprise sans promettre l’instantanéité
Une file persistante permet de savoir quelles opérations restent à confirmer. WorkManager peut participer à sa reprise, avec une tâche unique et des contraintes adaptées. Toutefois, le nom unique de la tâche Android ne remplace pas l’unicité de l’opération sur le serveur : une même demande peut être rejouée après une réponse perdue.
Pour une prise de commande en salle, une tentative peut partir pendant que l’application est visible, puis une reprise persistante prendre le relais selon les conditions du système. L’utilisateur doit voir l’état réel de la demande. Un indicateur de connectivité ne prouve ni que le serveur local est joignable ni qu’une opération a été acceptée.
Tester la panne au bon endroit
Sur un environnement de démonstration, envoyez l’opération « demo-commande-001 ». Faites enregistrer la commande, puis simulez une perte de réponse avant son arrivée au téléphone, par exemple au moyen d’un mécanisme de test côté service. Relancez ensuite exactement la même demande : le résultat attendu est une seule commande et le même identifiant métier retourné.
Complétez avec trois essais. Envoyez deux demandes identiques en parallèle ; changez la quantité tout en conservant le même identifiant ; fermez puis relancez l’application avant la confirmation. Les résultats attendus sont respectivement une seule création, un conflit détectable et la reprise de l’opération conservée localement. Il s’agit d’un plan de tests proposé, pas de résultats mesurés sur un logiciel existant.
Définissez aussi la durée de conservation de la correspondance serveur. Si elle expire alors qu’un téléphone peut encore rejouer une ancienne demande, la protection peut disparaître. Prévoir une procédure de rapprochement pour les opérations anciennes ou ambiguës vaut mieux que relancer aveuglément leur création.
Ne pas confondre commande, paiement et impression
La confirmation d’une commande ne garantit pas son impression physique ou son encaissement. Une imprimante peut recevoir un travail puis perdre sa confirmation ; un prestataire de paiement possède également son propre contrat de reprise. Chaque effet doit disposer d’un suivi adapté, sans présenter une transaction de base de données comme une garantie universelle d’exécution unique.
Pour une intégration à un POS existant, placez cette logique dans un service métier contrôlé et vérifiez les règles de la version effectivement déployée. Un accès MySQL direct depuis le téléphone ne fournit pas ce contrat. L’objectif est que l’utilisateur puisse distinguer une commande confirmée d’une opération encore incertaine, et que chaque reprise ait une identité vérifiable.
Références
Android Developers — Build an offline-first app, mise à jour du 14 octobre 2026 ; Managing work, consulté le 1er novembre 2026 ; WorkManager 2.12.0, version du 23 septembre 2026 ; IETF — RFC 9110, juin 2022, référence de fond. Le scénario et le contrat JSON sont fictifs ; aucune compatibilité avec une version particulière d’uniCenta n’est affirmée.
Dans les archives Geekkech. Développer une caisse utile : le terrain avant les fonctionnalités.
Le fonctionnement en images
