Accueil / Blog / Argent

Partager une addition quand un plat n'a pas été partagé

29 août 2026 · 10 min de lecture · Dimesum Engineering

Diviser un dîner de 525 € à parts égales fait payer à une personne 70 € pour un plat qu'elle n'a jamais touché, et la solution tient en une dépense avec deux règles.

Divisez un dîner de 525 € à parts égales et une personne paie 70 € de trop. Deux des trois convives ont mangé le plateau de fruits de mer à 200 € et le troisième non, pourtant un partage égal facture 175 € à chacun. Dimesum traite cette addition comme une seule dépense : égalité au sommet, la ligne de 200 € étant portée uniquement par les deux qui l'ont commandée.

Les additions presque égales avec une seule ligne non partagée sont la demande la plus courante faite à une application de partage, et le premier modèle de données de Dimesum ne savait pas l'exprimer. La conception antérieure faisait de ITEMIZED un type de partage, mutuellement exclusif avec EQUAL, PERCENT et SHARES. Une vraie addition de restaurant est les deux à la fois.

Le détail est une précision sur la dépense, pas un autre type de partage

Une dépense détaillée dans Dimesum est une dépense ordinaire qui porte simplement ses lignes. La dépense garde tout ce que les dépenses ont déjà : un total, des participants, un type de partage, un ou plusieurs payeurs. Elle y ajoute les articles, les lignes de l'addition, et les ajustements, soit la taxe, le pourboire, les frais et les remises inscrits en dessous.

Deux niveaux décident ensuite chaque centime. Le type de partage de la dépense divise toute ligne où personne n'est nommé. Une ligne avec des affectataires est portée exactement par ces personnes, et par personne d'autre.

Un dîner de 525 € où la personne qui a le moins mangé paie 105 €

Asha, Bhavna et Chetan dînent, partage égal au sommet. Les plats partagés reviennent à 300 €. Un plat de fruits de mer revient à 200 €, et seuls Asha et Bhavna en ont mangé. Le service est de 5 %, et Chetan a payé la totalité des 525 €.

Chetan a payé 525 € et doit 105 €, il lui revient donc 420 € : 210 € d'Asha et 210 € de Bhavna. Qui a payé est indépendant de qui doit. Le fait que le payeur soit la personne qui a à peine mangé ne change aucune des parts, et c'est pourquoi Dimesum garde les payeurs au niveau de la dépense et les affectataires au niveau de la ligne.

La taxe suit ce que vous avez mangé, pas votre nombre

La part de Chetan sur les 25 € de service est de 5 €, pas de 8,33 €. Chaque ajustement se répartit au prorata du sous-total d'articles de chacun, donc la répartition 200:200:100 de la nourriture décide aussi celle du service. Répartir par tête ferait discrètement payer à Chetan une taxe sur un plat auquel il n'a jamais touché.

Une personne qui n'a rien commandé ne paie donc aucune taxe et ne reçoit aucune remise. Les poids sont les sous-totaux avant ajustement plutôt que le total courant, ce qui empêche aussi l'arrondi de chaque ajustement de se répercuter dans les poids du suivant.

Les ajustements s'appliquent dans l'ordre, donc une remise déplace la base de TVA

Une addition indiquant « 1 000 €, moins 10 %, plus 5 % de TVA » facture la TVA sur 900 €, et la ligne de TVA est de 45 €. Inversez les deux et la TVA est facturée sur 1 000 €, soit 50 €. Les ajustements forment une liste ordonnée, et un pourcentage s'applique au total courant à sa propre position. Les deux ordres sont de vraies additions, donc la liste est ordonnée plutôt qu'un ensemble.

Trois validations se dressent entre une faute de frappe et l'arithmétique. Un pool indique soit un montant fixe, soit un taux en points de base, jamais les deux, car stocker les deux revient à stocker un nombre et sa propre dérivation. Un montant négatif est refusé, avec une erreur désignant DISCOUNT comme la manière d'écrire une réduction. Un taux supérieur à 100 000 points de base est également refusé, un plafond fixé bien au-dessus des 10 000 points de base qui valent 100 %, car cent pour cent de remise est une vraie remise.

Le total vient des lignes, et un total saisi n'est qu'une somme de contrôle

Un total détaillé est dérivé : la somme des articles plus la somme des ajustements. Les lignes disent déjà ce que coûte l'addition, donc un total indiqué séparément serait une seconde source de vérité pouvant contredire la première. Celui qui saisit mal une addition corrige une ligne, là où se trouve réellement l'erreur, et le total suit. Corriger une addition déjà enregistrée passe par une modification qui reformule son partage, de sorte que la correction arrive comme une nouvelle version plutôt que comme un écrasement.

Un client peut tout de même envoyer amount_minor, et Dimesum le traite alors comme une somme de contrôle plutôt que comme la réponse. Un accord signifie que le client a lu la même addition. Un désaccord arrête la dépense avant qu'aucun argent ne bouge.

Une version antérieure ajoutait automatiquement une ligne « Autre » pour tout ce qu'un total indiqué n'expliquait pas, et retirait la ligne quand l'écart se refermait. Cette ligne fonctionnait, et elle a disparu. Dériver le total a dissous le problème que la ligne « Autre » servait à gérer, un problème qui ne surgissait que parce que le total était indiqué deux fois.

Pourquoi EXACT et les articles sont refusés ensemble

EXACT nomme le montant final de chaque membre. Les articles dérivent le montant de chaque membre. Les deux à la fois sont surdéterminés : soit ils concordent, auquel cas l'un est redondant, soit ils divergent, auquel cas la dépense a deux réponses et aucune règle ne dit laquelle l'emporte. Dimesum refuse la combinaison dès l'entrée plutôt que de la trancher avec une règle de priorité que personne ne retiendrait.

EQUAL, PERCENT et SHARES se combinent tous avec les articles, car chacun est une règle pour diviser un coût partagé plutôt qu'un ensemble de montants finaux.

Là où une remise perdait autrefois un centime

Chaque répartition utilise la méthode du plus fort reste, et chacune conserve exactement son propre total. Les égalités dans cette méthode allaient autrefois au plus petit identifiant de membre, ce qui remettait au membre le plus ancien du groupe le centime supplémentaire sur chaque dépense partagée à parts égales ; l'égalité pivote désormais sur un hachage de l'identifiant de la dépense. Les lignes partagées sont regroupées et divisées une seule fois plutôt que ligne par ligne, de sorte que le centime en trop ne retombe pas sur le même membre pour chaque ligne de l'addition.

Notre fonction apportion avait ici un vrai défaut. La division entière de Go tronque vers zéro, donc un total négatif était arrondi du mauvais côté et le reliquat n'était jamais distribué : −10,00 € répartis sur des poids de 100, 200 et 300 revenaient à −9,99 €. Un centime disparu aurait fait échouer une addition remisée pourtant correcte à sa propre vérification de somme, et l'on aurait dit à l'utilisateur que son calcul était faux. Les totaux négatifs sont désormais répartis par magnitude puis leur signe négatif est rétabli.