Auto héberger le suivi sportif volontaire en PME

L'essentiel à retenir

Auto-héberger un suivi sportif pour une équipe peut sembler vertueux. Le sujet devient pourtant sensible dès que l'employeur entre dans la boucle. La bonne question n'est donc pas : openGym est-il un bon tracker ? C'est plutôt : une PME peut-elle mettre un tel service à disposition sans créer de pression, de surveillance ou d'usage RH ?

Selon son README, openGym est un tracker auto-hébergé pour les entraînements et le poids, utilisable comme PWA hors ligne avec synchronisation. Le projet annonce aussi une connexion par passkeys, plusieurs imports, un export JSON et un stockage local dans ./data. Cela donne à une petite entreprise davantage de maîtrise technique qu'un service centralisé classique. Cette maîtrise ne garantit toutefois ni la confiance ni le bon usage.

Pour une PME belge de 10 à 50 personnes, le projet n'a de sens que sous des conditions strictes : participation réellement volontaire, comptes personnels, absence d'accès patronal aux données, aucune conséquence professionnelle et sortie simple. openGym n'est pas un outil RH. Si l'entreprise veut mesurer, comparer ou suivre ses salariés, il faut l'écarter. Le pilote responsable commence par cette limite. Pas par Docker.

Le problème que ça résout

Le besoin peut être légitime : proposer un service sportif interne sans imposer une plateforme commerciale à toute l'équipe. Certains salariés suivent déjà leurs entraînements dans différentes applications. D'autres veulent simplement conserver un historique personnel, y compris lorsque la connexion disparaît. Une PME peut alors envisager de mettre une instance à disposition comme elle fournirait un autre service facultatif.

Selon le README du projet, openGym regroupe le suivi des entraînements et du poids dans une application auto-hébergée. Il peut importer des données issues de FitNotes, Strong et Hevy, ainsi que des données de poids provenant d'Apple Health. Il permet aussi un export JSON. Pour un utilisateur qui souhaite récupérer ou déplacer ses informations, ces fonctions répondent à un problème concret : éviter que l'historique reste enfermé dans un seul parcours applicatif.

Mais l'hébergement interne déplace la responsabilité. L'entreprise ne devient pas propriétaire des habitudes sportives parce qu'elle paie le serveur. Elle devient dépositaire d'un système qui peut contenir des données intimes sur les routines, les performances et le poids. Même sans tableau de bord RH, un administrateur technique pourrait être perçu comme capable d'observer. Cette perception suffit à abîmer le volontariat.

La décision doit donc séparer trois sujets souvent mélangés :

• le produit, qui sert à enregistrer une activité personnelle selon le README ;
• l'infrastructure, que la PME choisit d'exploiter ;
• la gouvernance, qui fixe qui peut accéder à quoi et pour quelle raison.

openGym peut répondre au premier sujet et fournir une base pour le deuxième. Il ne règle pas le troisième à la place de l'entreprise. Aucun fichier Docker Compose ne transforme une relation de travail en espace neutre.

La question lecteur est simple : faut-il auto-héberger ce service volontaire pour l'équipe ? La réponse est oui seulement si la PME accepte de renoncer explicitement à toute exploitation managériale. Si cette renonciation paraît excessive, le projet n'est déjà plus adapté.

Ce que c'est concrètement

D'après son README, openGym est un tracker sport et poids auto-hébergé. L'application est présentée comme une PWA capable de fonctionner hors ligne puis de synchroniser les données. Le projet propose un déploiement avec Docker Compose et stocke ses données dans ./data. Il existe également une démo accessible dans le navigateur pour examiner le produit avant un déploiement.

Le README mentionne la connexion par passkeys. Il décrit aussi les imports depuis FitNotes, Strong et Hevy, l'import du poids depuis Apple Health et l'export JSON. Pour un pilote interne, ces éléments permettent d'évaluer deux points sans promesse abstraite : la facilité d'arrivée pour les volontaires qui ont déjà un historique, puis leur capacité à repartir avec leurs données.

Le projet indique qu'il n'y a ni abonnement, ni publicité, ni télémétrie. Cette affirmation vient du README. Elle ne dispense pas l'entreprise de vérifier la version qu'elle déploie, ses dépendances, ses journaux techniques et sa propre configuration. Auto-héberger ne signifie pas automatiquement minimiser. Un reverse proxy trop bavard ou des sauvegardes accessibles à trop de personnes peuvent contredire l'intention initiale sans modifier une ligne du produit.

openGym prévoit aussi deux fonctions optionnelles qui demandent une décision séparée. Le README présente un coach IA désactivé par défaut, avec un fournisseur choisi par l'utilisateur et une approbation requise pour chaque changement. Il mentionne également un serveur MCP optionnel, local et en lecture seule. Dans une PME, « optionnel » doit vraiment vouloir dire absent du premier pilote. Chaque intégration supplémentaire agrandit le périmètre à comprendre, à documenter et à défendre.

Le code est publié sous licence AGPL-3.0 selon le dépôt. Le README précise que les médias d'exercices relèvent d'une licence distincte. Il faut donc distinguer le droit applicable au code de celui applicable aux contenus visuels. L'auto-hébergement donne du contrôle opérationnel, pas un droit général de réutilisation sur tout ce que contient le dépôt.

Enfin, le positionnement doit rester net. openGym n'est pas un logiciel de coaching collectif, une plateforme de défis entre collègues, un outil de gestion de salle ou un système de reporting RH. Son intérêt, dans ce scénario, tient justement à son caractère personnel. Le transformer en instrument de classement détruirait la condition qui rend son usage défendable.

Comment s'en servir

Un pilote responsable ne commence pas par inviter toute l'entreprise. Il réduit d'abord le périmètre, écrit les limites et teste la sortie. L'objectif n'est pas de prouver que l'outil fonctionne. La démo navigateur et le dépôt servent déjà à examiner le produit. L'objectif est de vérifier que l'organisation sait le proposer sans se l'approprier.

Étape 1 : écrire le contrat de non-usage

Avant toute installation, rédigez une règle courte et compréhensible. La participation est facultative. Les données ne servent ni à l'évaluation, ni au recrutement, ni à l'absentéisme, ni aux avantages, ni aux promotions. Aucun manager ne reçoit de vue individuelle ou agrégée. Refuser, arrêter ou ne rien enregistrer ne produit aucune conséquence.

Cette règle doit nommer les personnes qui administrent le service et les cas précis où elles peuvent intervenir. Une formule vague sur la « confidentialité » ne suffit pas. Il faut définir les accès, les motifs, la traçabilité interne et la procédure en cas d'incident. Si l'entreprise ne peut pas expliquer cela en langage courant, elle n'est pas prête à héberger.

Étape 2 : évaluer le produit avant les données réelles

Utilisez d'abord la démo navigateur mentionnée par le projet. Examinez les parcours utiles : création d'un accès, saisie d'un entraînement, usage hors ligne, synchronisation, import et export. Vérifiez ce que voit un utilisateur et ce qu'un administrateur peut techniquement atteindre dans l'environnement prévu.

Le README constitue le point de départ, pas la recette de gouvernance de votre PME. Les fonctions annoncées doivent être confrontées à la version réellement envisagée. Le bon test n'est pas seulement « peut-on importer ? ». Il faut aussi demander : peut-on quitter le service proprement, récupérer ses données et demander leur suppression sans négociation avec son employeur ?

Étape 3 : déployer le périmètre minimal

Selon le README, openGym peut être déployé avec Docker Compose et utilise ./data pour le stockage. Pour le pilote, restez au plus près de ce périmètre. N'activez pas le coach IA. N'activez pas le serveur MCP. N'ajoutez pas de connecteur analytique. N'envoyez pas les journaux vers un système consulté par les managers.

Le principe est simple : chaque composant doit avoir une raison liée au service rendu aux volontaires. « Cela pourrait être utile plus tard » n'est pas une raison. C'est une dette de confiance ajoutée avant même le premier usage.

Étape 4 : recruter des volontaires sans pression

L'invitation ne doit pas venir sous la forme d'un objectif d'équipe. Évitez les taux de participation, les défis obligatoires et les relances nominatives. Présentez le service, ses limites et sa procédure de sortie. Puis laissez les personnes choisir.

Dans une entreprise de 10 à 50 personnes, l'informel peut rendre la pression plus forte, pas plus faible. Une remarque enthousiaste du dirigeant peut être entendue comme une attente. Le volontariat se juge donc aux mécanismes : pas de liste publique des inscrits, pas de comparaison, pas de récompense liée aux données et pas de justification demandée aux non-participants.

Étape 5 : tester la réversibilité

Le README annonce un export JSON. Faites-en un critère du pilote. Un volontaire doit pouvoir récupérer ses données dans un format exploitable sans dépendre d'une faveur administrative. Testez aussi la restauration des sauvegardes, la suppression d'un compte et la fin complète du service.

La réversibilité concerne également l'entreprise. Qui reprend l'instance si l'administrateur quitte la PME ? Que se passe-t-il si le projet n'est plus maintenu comme vous l'espérez ? Comment avertir les utilisateurs avant une migration ou un arrêt ? Un outil interne acceptable doit pouvoir s'éteindre proprement.

Étape 6 : décider avec une grille go ou no-go

Le go exige que toutes les réponses suivantes soient positives : le volontariat est crédible, l'accès administratif est limité, les données sont exportables, la suppression est organisée, les fonctions optionnelles restent désactivées et aucun usage RH n'est prévu. Ajoutez une personne capable d'assumer la maintenance et une procédure d'incident compréhensible.

Le no-go s'impose dès qu'une condition centrale manque. Si la direction souhaite connaître la participation, comparer les habitudes, identifier les personnes « engagées » ou produire un indicateur collectif, arrêtez le projet. Si personne ne peut maintenir l'instance ou expliquer les sauvegardes, arrêtez aussi. Renoncer à un déploiement mal gouverné n'est pas un échec technique. C'est une décision correcte.

Ce que ça coûte vraiment

Le README indique l'absence d'abonnement, de publicité et de télémétrie. Cela ne rend pas le service gratuit pour l'entreprise. Le prix d'un logiciel auto-hébergé ne se résume jamais à sa facture de licence.

Le premier coût est le temps technique : préparer l'hébergement, sécuriser l'accès, gérer les mises à jour, surveiller la disponibilité, sauvegarder ./data, tester les restaurations et traiter les incidents. Le deuxième est organisationnel : écrire les règles, répondre aux questions, gérer les départs et prouver que les données ne circulent pas vers le management. Le troisième est juridique et documentaire : vérifier le cadre applicable à l'entreprise, les responsabilités, la conservation et les droits des personnes.

Aucun montant universel ne serait honnête ici. Il dépend de l'infrastructure déjà disponible, du niveau de service promis, des compétences internes et du périmètre choisi. Une petite instance sobre, sans coach IA ni MCP, réduit la complexité. Elle ne supprime ni l'administration ni la responsabilité.

La licence AGPL-3.0 du code mérite aussi une lecture adaptée à l'usage prévu, tandis que les médias d'exercices ont, selon le README, une licence distincte. Si la PME modifie, redistribue ou expose le logiciel d'une manière qui soulève une question de conformité, elle doit vérifier ses obligations au lieu de supposer que « open source » signifie « sans condition ».

Le coût décisif reste pourtant celui de la confiance. Une fuite, un accès mal expliqué ou une demande managériale improvisée peut rendre le service inutilisable même si le serveur reste parfaitement disponible. La bonne économie consiste donc à réduire le périmètre dès le départ. Moins de fonctions. Moins d'accès. Moins d'ambiguïté.

Pour qui ce n'est pas

openGym n'est pas adapté à une entreprise qui cherche un outil RH. Le projet décrit un tracker personnel, pas un système conçu pour mesurer le bien-être, la productivité, l'engagement ou la santé des salariés. Si ces objectifs figurent dans le cahier des charges, il faut écarter cet outil plutôt que le détourner.

Ce n'est pas non plus une plateforme de coaching collectif. Le README présente un coach IA optionnel sous le contrôle de l'utilisateur, avec approbation de chaque changement. Cela ne crée pas un programme d'accompagnement d'équipe, un espace de supervision par un coach ou une méthode de prévention au travail.

Ce n'est pas une solution de gestion de salle. Le projet ne doit pas être présenté comme un système de réservation, de contrôle d'accès, de gestion d'abonnements ou de planification de cours. Lui attribuer ces fonctions reviendrait à inventer un produit différent.

Le no-go concerne aussi plusieurs profils d'entreprise :

• celles qui veulent consolider les données sportives dans un tableau de bord ;
• celles qui conditionnent un avantage à une activité mesurée ;
• celles qui ne peuvent pas séparer l'administration technique de la hiérarchie ;
• celles qui n'ont personne pour maintenir, sauvegarder et arrêter proprement le service ;
• celles qui souhaitent activer immédiatement des intégrations externes sans clarifier les flux.

Une PME peut mettre un outil à disposition. Elle ne peut pas appeler « volontaire » un dispositif dont elle attend des résultats individuels. Le seuil est là. Clair. Si l'entreprise veut suivre les salariés, openGym n'est pas le mauvais outil à adapter. C'est l'outil à ne pas déployer.

Source : https://github.com/DuarteSantos8/openGym

FAQ

openGym permet-il à une PME de suivre ses salariés ?

Ce ne devrait pas être l'objectif. Le projet est présenté comme un tracker personnel de sport et de poids. Dans le scénario décrit ici, l'entreprise doit renoncer à tout suivi individuel ou agrégé. Si elle veut observer, comparer ou évaluer les salariés, elle doit choisir de ne pas déployer openGym.

Le service peut-il rester réellement volontaire ?

Oui, à condition que le volontariat soit organisé et pas seulement déclaré. Il faut éviter les objectifs de participation, les relances nominatives, les classements et toute conséquence professionnelle. Les non-participants ne doivent pas avoir à expliquer leur choix.

Faut-il activer le coach IA pendant le pilote ?

Non. Le README indique que ce coach est optionnel et désactivé par défaut, avec un fournisseur choisi par l'utilisateur et une approbation de chaque changement. Un premier pilote gagne à conserver ce réglage par défaut afin de limiter les flux, les décisions techniques et les questions de gouvernance.

À quoi sert le serveur MCP mentionné par le projet ?

Le README décrit un serveur MCP optionnel, local et en lecture seule. Sa présence ne justifie pas son activation dans une PME. Tant qu'un besoin explicite, proportionné et compris par les utilisateurs n'existe pas, il vaut mieux le laisser désactivé.

Comment permettre à un salarié de quitter le service ?

Le projet annonce un export JSON. Le pilote doit vérifier ce parcours, puis définir la suppression du compte et des données associées. La sortie doit être simple, documentée et indépendante de la relation avec un manager.

Quel est le premier critère de décision ?

La gouvernance. Si l'entreprise ne peut pas garantir l'absence d'usage RH et limiter les accès administratifs, le projet doit s'arrêter avant l'installation. La technique peut servir une règle claire. Elle ne peut pas remplacer cette règle.

---

Publié le 20 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.