Un téléphone, une salle d’entraînement, quelques secondes entre deux séries. Cette situation tient lieu de cahier des charges à TRAME, et elle a défait plusieurs choses que nous avions construites. TRAME est un projet interne d’OSOM Labs : une application d’entraînement conçue sur mesure pour une seule personne, en usage réel depuis l’été 2026. Elle n’est pas publique, elle ne se télécharge pas, et ce récit ne donne aucun conseil d’entraînement. Le fitness est ici le terrain de l’exemple. La question posée est celle d’une direction de PME devant un projet d’application métier sur mesure : comment en décider le contenu, et à quel moment y renoncer. Ce qui suit vient de notre journal de décisions et de mesures relevées dans la base de l’application, erreurs comprises.
Une phrase qui tranche les désaccords
Le dossier de TRAME s’ouvre sur l’usage : en salle, sur téléphone, entre deux séries, « c’est la contrainte qui prime sur tout le reste ». Cette phrase se traduit en règles qu’on peut vérifier.
Les cibles tactiles font au moins 48 px. Chaque écran a un seul bouton principal. La séance n’ouvre qu’un seul mouvement à la fois. Toute information lue en séance fait au moins 13 px, et un test échoue si un composant descend en dessous.
Le même dossier dit ce qui n’entre pas. Une seule personne se sert de l’application : ni rôles, ni invitations, ni partage, ni abonnement. Toute fonction qui suppose un deuxième utilisateur reste hors périmètre.
Dans une organisation, la phrase sera autre : un technicien sur un toit, avec des gants ; une réceptionniste, avec quelqu’un en face d’elle. Si l’équipe n’arrive pas à l’écrire, le projet n’a pas encore de sujet.
Observer, puis retirer du chemin
Sur les premières séances mesurées, les séries d’un même mouvement étaient saisies d’un coup, en rafale de 3 à 15 secondes, une fois le mouvement terminé. L’unité de l’application est donc le passage : un mouvement fait en entier, toutes ses séries. Le mouvement ouvert arrive déjà rempli, et « Fait · 3 × 10 · 20 kg » écrit les trois séries d’un tap. Le détail série par série et la note restent facultatifs et n’allongent pas le chemin. Il n’y a pas de minuteur de repos : avec une saisie en rafale, il n’aurait pas de sens.
Le retrait le plus instructif concerne la note d’effort. Jusqu’au 26 août, quatre pastilles étaient proposées à chaque série : 0 saisie sur 38 séries. Une question plus simple les a remplacées, Facile, Juste ou Dur, posée sur le passage entier. Le 1er octobre, elle était renseignée sur 20 % des séries. Du 14 au 26 octobre, sur aucune série, en cinq séances. Pour la personne qui s’en sert, la question n’était pas intuitive.
Le 26 octobre, la question a quitté l’écran. À sa place, « La prochaine fois ? » demande en fin de passage ce que l’on veut viser ensuite : plus léger, pareil, une répétition de plus, plus lourd. L’ancienne question regardait en arrière. La nouvelle regarde devant, et sa réponse sert dès le passage suivant.
Dans une application métier, un champ que personne ne remplit est une mesure comme une autre. Il coûte trop cher au moment où on le demande, ou sa réponse ne sert à rien. La base le montre, à condition d’aller la relire.
Proposer, et laisser décider
Le calcul le plus lourd de conséquences, dans TRAME, porte sur la charge suivante. La règle s’appelle la double progression : les répétitions d’abord, et un palier de charge seulement quand quatre conditions sont réunies. Le dernier passage était complet. Sa série la plus faible a atteint le haut de la prescription, car une bonne première série ne prouve rien si les suivantes décrochent. L’effort, quand il a été noté, est resté sous un plafond. Et le palier de l’appareil est connu. Ne pas noter l’effort ne bloque rien, sans quoi l’application punirait une saisie absente.
Même réunies, ces conditions produisent une proposition, jamais un changement. La charge proposée n’entre dans la saisie que si la personne touche un bouton. L’historique connaît le passage précédent, et il ne sait rien de la forme du jour. La personne en salle, si.
Une exception est consignée. L’objectif fixé avec « La prochaine fois ? » préremplit bien la saisie du passage suivant, sur le même appareil. La règle protège d’une décision de l’application ; cet objectif est une décision de la personne, prise un passage plus tôt. Le conseil automatique, lui, ne remplit toujours rien.
Le programme suit la même logique. Il vient de l’extérieur : l’application le transcrit et ne le réécrit pas. Une fourchette de répétitions plus conforme aux habitudes de l’application a été écartée, parce qu’elle aurait affiché autre chose que la prescription. Quand il a fallu rapprocher les appareils du programme de ceux de la salle, trois cas douteux ont été tranchés un par un plutôt que devinés sur la ressemblance : deux étaient les mêmes, le troisième non.
TRAME ne contient aucune fonction d’intelligence artificielle. Ses propositions sortent de règles écrites, que l’on peut relire et tester. La démonstration de notre page Labs en montre deux sur des données fictives.
Pour tout automatisme d’une application métier, trois questions valent d’être posées : qui décide, qui peut corriger, et que voit-on quand le calcul ne sait pas ?
Quand l’application ne sait pas, elle le dit
Cinq appareils ajoutés en septembre portaient un palier de 2,5 kg posé par défaut, que personne n’avait relevé sur la machine. L’application pouvait donc proposer un cran inexistant. Ces valeurs ont été retirées. Un palier inconnu ne produit plus aucune hausse chiffrée, tant qu’il n’a pas été relevé en salle.
La durée des séances a connu le même sort. Des séries saisies après coup, toutes à la même heure, affichaient « 0 min », et une autre séance « 3 h 48 ». Le bilan écrit maintenant « Durée inconnue · séries saisies après coup », ou « à vérifier » au-delà de 2 h 30. « 0 min » affirmait une mesure qui n’avait pas eu lieu. C’est la discipline que nous décrivons dans le récit de l’algorithme honnête.
Certains chiffres trompent par leur sens. Sur les machines assistées, le nombre affiché est un contrepoids : progresser, c’est le faire baisser. Sans cette information posée sur l’appareil, la règle aurait proposé de l’augmenter. Chaque métier a ce genre de cas, et ils se trouvent sur le terrain.
Les corrections qui ont compté sont venues de la salle
Le 1er octobre, un audit de l’application a relu l’usage réel. Depuis la refonte visuelle du 24 septembre, aucune séance n’avait été enregistrée en direct en salle. Deux séances avaient été ouvertes puis effacées sans série, et les séries saisies après coup. Les notes et les repères d’appareil, construits autour de la séance, étaient à zéro.
La cause, donnée par la personne qui s’en sert : l’application proposait la mauvaise séance. Une séance du vendredi n’avait pas été faite. Le lundi, l’accueil continuait de la proposer, et son seul bouton ne démarrait qu’elle. La séance du lundi a eu lieu sans pouvoir être enregistrée sur le moment. Notre logique retenait le nombre de séances faites, jamais lesquelles. Depuis le 29 septembre, la séance proposée est celle qui suit la dernière séance close, avec « Faire une autre séance » juste en dessous. Un bouton « Passer » a été écarté : il aurait créé une séance fantôme que l’historique et le calendrier auraient dû apprendre à ignorer.
Le 30 septembre, le bouton de démarrage a mis environ 5 secondes à afficher la séance. La mesure a montré que les pages tournaient à Washington, alors que la base est à Zurich. La base répondait en 4 ms, le trajet portait la réponse à 292 ms (médianes sur 131 requêtes), et une page en enchaînait 6 à 9. Le calcul des pages est passé à Francfort et les lectures ont été regroupées. Le gain de ce déplacement reste une déduction : nous n’avons pas de mesure comparable faite après coup.
Ces deux constats ont changé l’ordre du travail. La suite prévue était visuelle. Elle est passée après la fiabilité de la séance : garder la saisie lors d’une coupure, montrer l’attente, une seule séance ouverte à la fois, plus d’effacement d’un seul tap. Trois fonctions déjà décidées ont été conditionnées à deux semaines de séances saisies en direct. Notre journal le dit ainsi : « L’habillage peut attendre une semaine ; une séance perdue, non. » Depuis, les séances se saisissent de nouveau en salle.
D’autres défauts ne se voyaient que sur place. Jusqu’au 26 août, l’en-tête se peignait sous l’horloge du téléphone et le bouton « Terminer » se trouvait dans la bande où iOS intercepte les touchers. Sur un ordinateur de développement, rien de cela n’apparaît. Une séance du 24 août est restée ouverte, avec ses 19 séries : le geste de clôture ressemblait alors trait pour trait à un lien voisin. Il a été déplacé, et il se fait maintenant en deux temps.
Ce que nous vérifions, et ce qui échappe aux tests
Au 3 novembre 2026, la suite compte 286 tests automatisés, et les 286 passent. Ils portent d’abord sur les règles qui produisent un chiffre : la montée de charge, la charge inversée, l’objectif de la prochaine fois, la durée d’une séance, la date d’un jour en heure suisse. Personne ne recalcule ces chiffres en salle : s’ils sont faux, ils seront crus. D’autres tests rejouent des migrations de la base dans une base d’essai, ou contrôlent l’interface, comme les contrastes et les tailles de texte.
Les coupures de réseau ont été essayées à la main, le 1er octobre : réseau coupé pendant « Fait », la saisie reste à l’écran et « Réessayer » enregistre le passage une seule fois. Le message dit « pas confirmé » et n’affirme jamais l’échec, car une réponse perdue peut suivre une écriture réussie. Un « Fait » qui avancerait avant la réponse du serveur a été écarté dans le même esprit : sans file locale, la coche pourrait mentir.
Les écrans et les échanges avec le serveur n’ont, pour l’essentiel, pas de tests automatisés, et c’est un choix : il faudrait une base de données ou trois dépendances de plus. Une suite au vert dit donc peu de chose de ce que voit la personne en salle.
Les limites que nous assumons
L’application ne fonctionne pas hors ligne. C’était pourtant l’une de nos quatre contraintes de conception, parce que beaucoup de salles captent mal au sous-sol. Rien ne s’enregistre sans réseau, et une application fermée perd sa saisie en cours. Travailler hors ligne demanderait une file locale et une synchronisation, soit une autre architecture. Nous l’avons exclu le 1er octobre et gardé le filet décrit plus haut. La contrainte reste écrite, avec la mention « non tenue ».
TRAME est une application web installable sur l’écran d’accueil du téléphone. Pour un projet de développement d’application mobile, cette forme a ses contreparties : l’application peut garder une ancienne version en mémoire après une mise à jour, et le calendrier natif de l’iPhone lui reste inaccessible.
Le développement d’une application web sur mesure en Suisse pose aussi la question du lieu. La base de TRAME est à Zurich. Ses pages se calculent à Francfort, son hébergeur n’ayant pas de région en Suisse.
Tout repose enfin sur une seule personne. Droits d’accès, rôles, reprise de données, formation d’une équipe, connexion à un outil existant : TRAME ne prouve rien sur ces sujets, que la plupart des applications métier rencontrent. Nos mesures décrivent un seul usage. Elles orientent nos décisions et n’établissent aucune généralité. Nous n’appliquons pas non plus notre règle partout : la note libre, sans aucune saisie du 1er septembre au 26 octobre, est toujours là.
La méthode, transposée à un métier
Avant de chercher un développeur d’application, en Suisse ou ailleurs, voici ce que nous ferions, dans cet ordre.
Quand le sur-mesure n’est pas la bonne réponse
Ce qui suit est notre avis, tiré de ce projet, et non une statistique.
Un logiciel du marché fait déjà le travail. Notre exemple le montre : des applications d’entraînement existent. TRAME tient à une préférence pour sa mécanique de saisie et à son statut de projet interne. Une PME n’a pas à raisonner ainsi. Si un logiciel existant couvre le geste, moyennant quelques détours, nous commencerions par le garder.
Personne n’a accès au terrain. Sans observation, on programme une hypothèse. Tout ce récit repose sur des séances réelles et sur une base qu’on peut relire.
La tâche est rare, ou pas encore stable. Si l’équipe ne sait pas encore comment elle veut travailler, un tableur ou un outil existant donnera d’abord la réponse, avec moins d’engagement.
Personne ne suivra l’application après sa mise en service. TRAME a changé de programme le 17 septembre, déplacé son calcul le 1er octobre et perdu sa question d’effort le 26 octobre. Ces changements sont venus du terrain, de mesures ou de retours que quelqu’un a lus. Une application livrée puis laissée seule n’en fera aucun.
Le sur-mesure se défend quand une contrainte d’usage forte et précise n’est respectée par aucun outil existant, quand on peut aller voir, et quand quelqu’un relira ce qui se passe après la mise en service. Pour un logiciel sur mesure en entreprise, notre offre d’applications métier sur mesure décrit notre façon d’avancer. Le premier échange part de la tâche à simplifier, des personnes concernées et des outils déjà utilisés.
Cadre de lecture
Ce récit décrit un projet interne d’OSOM Labs, conçu pour une seule personne. L’application n’est pas publique. Les règles citées décrivent son fonctionnement : elles ne constituent ni un conseil d’entraînement, ni un conseil de santé. Les mesures portent sur un seul usage et ne se généralisent pas.
Ce qu'il faut retenir
Une application métier part d’une situation d’usage écrite en une phrase. Pour TRAME : en salle, sur téléphone, entre deux séries.
Une note d’effort proposée à chaque série a recueilli 0 saisie sur 38 séries. Sa dernière version a quitté l’écran le 26 octobre 2026.
Un palier de charge est proposé, jamais appliqué d’office. La saisie reprend le dernier passage, ou l’objectif que la personne s’est fixé elle-même.
Une valeur inconnue reste inconnue : aucune hausse chiffrée sans palier relevé, « Durée inconnue » plutôt que « 0 min ».
286 tests vérifient l’application au 3 novembre 2026. Les écrans, pour l’essentiel, n’en font pas partie, et elle ne fonctionne pas hors ligne.
Le sur-mesure se défend mal quand un logiciel existant fait le travail, quand personne ne peut observer l’usage, ou quand personne ne suivra l’application après sa mise en service.