55 lines
5.6 KiB
Markdown
55 lines
5.6 KiB
Markdown
---
|
|
title: 'Comprendre TrainUs'
|
|
description: "Le pourquoi derrière les choix de l'application : local-first, JSON vs base de données, minuteries."
|
|
weight: 4
|
|
date: 2026-06-14
|
|
---
|
|
|
|
## Pourquoi une application locale ?
|
|
|
|
Beaucoup d'applications de fitness fonctionnent avec un compte et un serveur central : c'est pratique pour synchroniser vos appareils, mais cela veut aussi dire qu'une société tierce héberge vos données, et que l'application devient inutilisable sans connexion — ou si le service ferme un jour.
|
|
|
|
TrainUs fait le choix inverse : tout tourne dans votre navigateur, vos données sont stockées localement, et rien n'est jamais envoyé à un serveur. Ce choix a un coût — pas de synchronisation ni de sauvegarde automatiques entre appareils — mais ce coût est couvert par des solutions simples et manuelles : voir les [Guides pratiques]({{< relref "guides-pratiques.fr.md" >}}) pour la sauvegarde et la synchronisation.
|
|
|
|
## JSON ou base de données : que choisir ?
|
|
|
|
Deux façons d'exporter vos données, pour deux besoins différents :
|
|
|
|
| | Export JSON | Export base de données (SQLite) |
|
|
| ----------------- | ----------------------------------------------------------------- | ----------------------------------------------------- |
|
|
| Contenu | Un ou plusieurs types de données au choix (exercices, séances...) | Tout, sans exception |
|
|
| Usage typique | Partager une séance, sauvegarder un sous-ensemble | Sauvegarde complète, migration vers un autre appareil |
|
|
| À l'import | Fusion : conflits gérés un par un, suffixe si autre utilisateur | Remplacement total des données existantes |
|
|
| Format du fichier | Fichier texte, lisible, modifiable avec précaution | Fichier binaire, à ne jamais modifier à la main |
|
|
|
|
Concrètement : un fichier **JSON** est un simple fichier texte qui décrit vos exercices, combos, séances ou collections dans un format structuré et lisible. Un fichier **SQLite** (`.sqlite3` / `.db`) contient la base de données complète de l'application ; il peut être ouvert avec un outil spécialisé (DB Browser for SQLite, par exemple) mais ne doit jamais être édité à la main.
|
|
|
|
Il existe une troisième façon de faire sortir des données de l'application : l'export HTML de la page d'accueil (voir [Guides pratiques]({{< relref "guides-pratiques.fr.md" >}})). C'est aussi un export de données, même si le format est différent — sauf qu'il est à sens unique : un fichier HTML ne se réimporte pas dans TrainUs. Il n'est pas fait pour la sauvegarde mais pour la lecture par quelqu'un d'autre, typiquement un ami ou un coach.
|
|
|
|
## Ce qu'il se passe vraiment à l'import
|
|
|
|
Importer un fichier JSON ne supprime jamais vos données existantes par surprise :
|
|
|
|
- S'il vient de **vous** (même identifiant utilisateur) : TrainUs compare avec ce que vous avez déjà. Pour chaque élément déjà présent (même identifiant, ou même titre s'il s'agit d'un élément différent), vous choisissez de le remplacer ou de le garder, un par un ou en lot.
|
|
- S'il vient d'**un autre utilisateur** : tous les titres importés reçoivent un court suffixe que vous choisissez (« [JD] »), pour ne jamais se confondre avec vos propres données. Le suffixe est mémorisé et réutilisé si vous importez à nouveau depuis la même personne. Si le titre suffixé entre en conflit avec un élément déjà importé précédemment (typiquement une nouvelle version du même élément, réexportée par la même personne), vous choisissez de le remplacer ou de le garder, exactement comme pour vos propres données.
|
|
|
|
Dans tous les cas, un écran récapitulatif montre ce qui va changer avant que rien ne soit appliqué.
|
|
|
|
À l'inverse, **restaurer une base de données** (fichier `.sqlite3`) remplace tout, sans fusion possible — c'est voulu : ce mécanisme est pensé pour la sauvegarde et la restauration complètes, pas pour le partage sélectif.
|
|
|
|
## Comment fonctionnent les minuteries (EMOM / AMRAP / TABATA)
|
|
|
|
Les trois types de combo minuté suivent chacun leur propre logique :
|
|
|
|
- **EMOM** (_Every Minute On the Minute_) : un nouvel exercice démarre chaque minute. La durée que vous réglez est divisée par le nombre d'exercices du combo pour savoir combien de tours faire — chaque exercice occupe une tranche de 60 secondes.
|
|
- **AMRAP** (_As Many Rounds As Possible_) : un compte à rebours unique tourne pour toute la durée réglée ; vous enchaînez les exercices en boucle, en faisant autant de tours que possible.
|
|
- **TABATA** : alternance stricte de phases de travail et de repos, répétées un nombre de fois donné.
|
|
|
|
Dans les trois cas, deux sons différents vous guident sans avoir à regarder l'écran : un bip discret pour les repères intermédiaires, un BIP plus marqué pour les changements de phase ou la fin du temps. Pour le détail minute par minute, voir la section [Signaux sonores]({{< relref "user-guide.fr.md" >}}#signaux-sonores) de la Référence.
|
|
|
|
L'avancement entre exercices ou tours est automatique pour les trois types — vous n'avez rien à valider vous-même pendant que le chronomètre tourne.
|
|
|
|
## Et les statistiques ?
|
|
|
|
Pour être honnête, l'écran Statistiques est celui sur lequel l'auteur de l'application a le moins de retour d'expérience personnel — il ne s'en sert pas lui-même au quotidien. Les graphiques actuels (fréquence, volume, progression par exercice) sont un point de départ raisonnable, mais s'il vous manque quelque chose, c'est probablement vrai pour d'autres aussi : vos retours sont bienvenus.
|