Splync v1.5 — Ratios de Répartition Personnalisables par Projet et Catégorie

Le 16 septembre 2025, Splync v1.5 a été lancé — seulement quatre jours après que notre mariage international a finalement été accepté par la ville. Jusqu'à cette mise à jour, Splync ne pouvait pas du tout personnaliser les ratios de répartition ; chaque dépense était divisée équitablement par défaut. Avec v1.5, les utilisateurs peuvent désormais définir des ratios personnalisés à la fois par projet et par catégorie. Ce changement permet aux couples et amis de partager leurs coûts de manière à mieux refléter leur vie réelle, et non simplement un simple 50:50. Vous pouvez commencer un nouveau projet comptable avec une répartition de 60:40 pour les dépenses quotidiennes à partir d'octobre, tout en gardant le loyer de votre appartement à un 50:50 équitable si cela vous convient. Et si les courses semblent plus équilibrées à 70:30 tandis que les charges semblent mieux à 62:38, vous pouvez désormais attribuer ces ratios séparément — catégorie par catégorie — au sein d'un même projet.

Le changement le plus visible dans la v1.5 est la nouvelle section Membres & Parts par Défaut, où vous pouvez ajouter des membres au projet et attribuer à chacun une part par défaut. Si un projet a deux membres, le ratio pourrait être de 50:50, 40:60, ou ce qui vous semble juste. Avec trois membres, il pourrait être de 33.33:33.33:33.34, 50:25:25, ou toute autre combinaison que vous préférez. Cela devient le partage par défaut du projet. En dessous, vous pouvez faire défiler pour ajuster la part de chaque catégorie si vous voulez qu'elle diffère du défaut du projet. Lorsque vous attribuez un ratio personnalisé à une catégorie, sa marque bleue devient orange — un petit indice visuel que la catégorie utilise sa propre règle plutôt que celle du projet. Bien que ce changement ajoute beaucoup plus de flexibilité aux paramètres de projet, il rend également la vue créer/modifier un projet un peu plus complexe. Pour aider, j'ai ajouté des boutons d'information à chaque section afin que vous puissiez les toucher pour voir de petites aides Q&R.

La mise en œuvre de ce changement a été plus complexe que prévu. Splync avait toujours supposé un monde propre à 50:50 — un seul chiffre, appliqué partout, et le calcul était fait. Une fois que j'ai décidé de prendre en charge les ratios personnalisés, toute la structure interne devait être repensée. Un projet ne pouvait plus se reposer sur un seul pourcentage partagé. Chaque catégorie avait besoin de son propre ratio, et chaque dépense devait faire référence à la fois au défaut du projet et à l'exception de la catégorie. Pour que cela fonctionne, j'ai réécrit la logique de calcul depuis la base. Chaque dépense comporte désormais un petit arbre de décision : "Cette catégorie a-t-elle son propre ratio ? Si oui, utilisez-le. Sinon, revenez au ratio du projet." Cela semble simple à expliquer, mais maintenir la cohérence du modèle de données à travers l'application — vues iOS, backend FastAPI, et schémas MariaDB — a nécessité plus de réglages minutieux que prévu.

Toute mise à jour touchant le côté serveur doit être traitée avec une extrême prudence. Si vous modifiez accidentellement le code serveur existant, les utilisateurs encore sur v1.4 rencontreront immédiatement des bugs ou des erreurs système. Par exemple, le programme serveur pour v1.5 s'attend à ce que les paramètres du projet incluent des données de ratio, mais l'application v1.4 envoie des paramètres de projet sans aucun ratio. Dès que ces deux versions essayent de communiquer, la requête échoue — simplement parce qu'elles parlent des "langages" légèrement différents. Les développeurs peuvent bien sûr apporter des modifications en toute sécurité dans un environnement de test. La partie délicate commence après avoir soumis une nouvelle version pour l'examen d'Apple, alors que les utilisateurs existants sont toujours sur v1.4. Pendant toute la période de soumission à la sortie, le serveur doit prendre en charge les deux versions en même temps pour que les examinateurs d'Apple puissent tester v1.5 et que les utilisateurs existants puissent continuer à utiliser v1.4 sans interruption.

Dans le développement d'applications, un "point d'accès" est simplement l'endroit où l'application envoie ses requêtes sur le serveur — un peu comme un guichet spécifique à la mairie. Un guichet s'occupe des enregistrements de mariage, un autre des dossiers des résidents, et un autre des passeports. Les applications fonctionnent de la même manière : chaque point d'accès est une fenêtre dédiée où le serveur accepte un type spécifique de requête comme la connexion, la création de projet, l'édition de dépense, la demande d'ami, etc. Lorsque Splync v1.4 envoie une requête, elle va à la "vieille" fenêtre qui comprend l'ancien format. Splync v1.5 envoie sa requête à une "nouvelle" fenêtre qui comprend les données de ratio. Si le serveur fermait la vieille fenêtre trop tôt, les utilisateurs de v1.4 n'auraient nulle part où "soumettre" leurs données. C'est pourquoi, lors d'une mise à jour, le serveur doit garder les deux fenêtres ouvertes — les deux points d'accès — jusqu'à ce que chaque utilisateur soit passé à la nouvelle version en toute sécurité. Pour être honnête, gérer ces deux fenêtres en même temps, c'était comme penser dans une dimension supplémentaire.

Splync v1.5 peut personnaliser les répartitions par projet et par catégorie, mais pas encore par dépense. Pour prendre en charge les ratios par dépense, nous avons besoin d'une autre couche structurelle — essentiellement une réécriture plus profonde de la façon dont chaque dépense stocke et calcule ses parts. Nous devons également faire attention à ne pas compliquer soudainement l'interface de l'application juste pour ajouter plus de puissance. C'est une mise à niveau plus importante qu'il n'y paraît. Donnez-nous encore un peu de temps pour y parvenir. C'est sur notre horizon — et nous y arriverons. En attendant, explorons comment les nouveaux ratios par projet et par catégorie rendent déjà les dépenses partagées beaucoup plus flexibles.