Parcours de fondatrice
Ce que j’ai sous-estimé en construisant KAVYLO
Par Naomi Stiel · 25 septembre 2026
En construisant KAVYLO, j’ai appris que développer une application fitness va bien au-delà du code. Tests, localisation, structure du produit, retours utilisateurs et travail autour de chaque nouvelle fonction : voici ce que j’ai le plus sous-estimé.
Créer une application fitness va bien au-delà du code
Lorsque j’ai commencé à construire KAVYLO, je savais que développer une application fitness demanderait du temps.
Ce que j’ai sous-estimé, c’est la part de ce temps qui aurait finalement assez peu à voir avec le fait de programmer la fonction elle-même.
Une nouvelle fonctionnalité peut commencer par une idée relativement simple : ajouter des plans d’entraînement, améliorer le suivi des séances, développer l’espace Coach ou mieux relier plusieurs parties de l’application.
Mais entre cette idée et une fonction qui semble vraiment terminée, il y a énormément de travail.
Il faut penser à l’interface, aux données derrière la fonction, aux tests, aux cas particuliers, aux traductions, à la navigation, à l’accessibilité, aux exigences de l’App Store, au contenu du site et à tout ce qui doit continuer de fonctionner après la publication.
C’est probablement l’une des plus grandes leçons que j’ai apprises en construisant KAVYLO.
Chaque nouvelle fonction crée du travail autour d’elle
Il est facile d’imaginer une nouvelle fonctionnalité comme un écran ou une fonction isolée.
En pratique, presque chaque ajout touche plusieurs autres parties du produit.
Une nouvelle fonction liée à l’entraînement peut par exemple nécessiter :
- des modifications de navigation
- de nouvelles structures de données
- des réglages supplémentaires
- de nouveaux états vides ou d’erreur
- des tests dans différentes situations
- des mises à jour du site
- des traductions
- du contenu d’aide
- de nouvelles vues d’analyse ou de progression
- des adaptations dans d’autres fonctions connectées
La fonctionnalité visible ne représente souvent qu’une petite partie du travail total.
C’est devenu particulièrement évident lorsque KAVYLO a commencé à évoluer au-delà d’un simple tracker de workouts.
Entraînement, Nutrition, Recovery, Progression, Apple Health, Apple Watch, coaching, Community et d’autres domaines doivent fonctionner ensemble comme les parties d’un même produit.
Vous pouvez en découvrir davantage sur la structure globale sur la page des fonctionnalités KAVYLO.
Garder une application fitness claire en grandissant est difficile
Un autre point que j’ai sous-estimé est la difficulté d’ajouter davantage de fonctionnalités sans rendre l’application plus compliquée à utiliser.
Créer une nouvelle fonction est relativement simple.
Le plus difficile est souvent de décider où elle doit se trouver dans le produit.
À mesure que KAVYLO a grandi, l’architecture de l’information est devenue beaucoup plus importante.
Toutes les fonctions ne doivent pas avoir la même priorité visuelle.
Tout n’a pas besoin d’apparaître directement sur le premier écran.
Une application peut proposer beaucoup de fonctionnalités tout en restant simple, mais uniquement si sa structure reste compréhensible.
Je me pose donc de plus en plus souvent des questions comme :
- Que doit voir l’utilisateur en premier ?
- Quelles fonctions vont ensemble ?
- Qu’est-ce qui devrait se trouver dans un écran secondaire ?
- Quelle information est utile maintenant ?
- Quelle information peut attendre que l’utilisateur la recherche volontairement ?
J’ai appris que simplifier un produit ne signifie pas forcément supprimer des fonctionnalités.
Cela peut aussi vouloir dire montrer la bonne fonction au bon moment.
Les plans d’entraînement en sont un bon exemple
Les plans d’entraînement semblent au départ être une fonctionnalité assez clairement définie.
Mais dès que l’on veut vraiment les intégrer utilement dans une application fitness, ils commencent à se connecter à beaucoup d’autres domaines.
Il y a les plans eux-mêmes, les exercices, l’historique d’entraînement, les prochaines séances, les différents sports, la progression et la manière dont toutes ces informations doivent fonctionner ensemble.
C’est pourquoi je ne veux pas que KAVYLO traite un plan d’entraînement comme une simple liste isolée de workouts.
La planification doit être reliée aux séances réellement effectuées et au contexte fitness plus large qui les entoure.
Vous pouvez en savoir plus sur la page Plan d’entraînement avec KAVYLO.
Le travail invisible prend énormément de temps
Certaines des tâches qui prennent le plus de temps sont aussi celles que les utilisateurs ne remarqueront probablement jamais consciemment.
Un bouton doit réagir correctement.
Une page ne doit pas casser sur un petit écran.
Une traduction doit disposer de suffisamment d’espace.
Un état de chargement doit être compréhensible.
Un écran vide doit expliquer ce qui peut être fait ensuite.
L’utilisateur doit comprendre où il se trouve sans avoir à réfléchir à la navigation.
Aucune de ces choses ne paraît particulièrement spectaculaire lorsqu’on les regarde séparément.
Mais ensemble, elles déterminent si une application semble aboutie ou encore inachevée.
J’ai sous-estimé le temps que ce type de travail allait demander.
La localisation ne consiste pas seulement à traduire des textes
KAVYLO est désormais disponible dans plusieurs langues.
Au premier abord, la localisation peut sembler simple : traduire les textes et ajouter un sélecteur de langue.
En réalité, elle touche de nombreux aspects du produit.
Les textes n’ont pas tous la même longueur.
Les libellés de navigation changent.
Les pages SEO ont besoin de leurs propres titres, descriptions et URL.
Les articles de blog nécessitent leurs propres versions linguistiques.
Certains termes doivent être traduits, tandis que d’autres font volontairement partie du langage du produit.
Et chaque langue doit rester cohérente lorsque KAVYLO évolue.
Le travail ne s’arrête donc pas lorsque la première traduction est terminée.
Chaque future fonction doit également s’intégrer dans ce système.
Là encore, l’effort sur le long terme s’est révélé bien plus important que je ne l’avais imaginé au départ.
Publier une application ne signifie pas qu’elle est terminée
Avant de construire KAVYLO, il était facile d’imaginer la publication sur l’App Store comme une ligne d’arrivée.
Ce n’est pas le cas.
La publication marque plutôt le début d’un autre type de travail.
Les vrais utilisateurs utilisent l’application différemment de moi pendant le développement.
Ils remarquent des choses que je ne vois parfois plus parce que j’ai regardé le même écran des centaines de fois.
Une fonction qui me semble évidente peut ne pas l’être pour quelqu’un qui ouvre KAVYLO pour la première fois.
Ces retours sont importants parce qu’ils changent la manière dont je pense le produit.
L’objectif n’est pas de modifier immédiatement l’application à chaque commentaire individuel.
Il s’agit surtout de comprendre ce que le retour révèle sur l’expérience utilisateur sous-jacente.
Les retours utilisateurs ont changé ma manière de voir la complexité
L’une des leçons les plus importantes a été qu’un produit riche en fonctionnalités peut rapidement sembler surchargé.
KAVYLO réunit volontairement plusieurs domaines du fitness.
Je ne veux donc pas résoudre ce problème simplement en supprimant des fonctions utiles.
Je me concentre davantage sur la complexité visible.
La question n’est plus seulement :
« Que peut encore faire KAVYLO ? »
Mais aussi :
« Comment KAVYLO peut-il faire davantage sans demander davantage d’effort mental à l’utilisateur ? »
Cela influence les espaces Training, Today, Nutrition, Progress, Community et la manière dont les nouvelles fonctionnalités sont introduites.
Construire KAVYLO seule change ma manière de prioriser
Je développe KAVYLO de manière indépendante.
Cela me donne beaucoup de liberté, car je peux prendre rapidement des décisions produit et garder une vision claire de la direction que je veux donner à KAVYLO.
Mais cela signifie aussi que tous les domaines se disputent le même temps limité.
Développement, design, tests, contenu, traductions, support, site web, App Store et planification future doivent constamment être priorisés.
Toutes les bonnes idées ne peuvent pas être développées immédiatement.
Apprendre ce que je décide volontairement de ne pas construire tout de suite est devenu aussi important que choisir ce que je vais développer ensuite.
J’ai écrit davantage à ce sujet dans Comment je construis KAVYLO en parallèle d’un emploi à temps plein, de mes études et du quotidien.
Une fonction qui marche n’est pas forcément une fonction terminée
C’est probablement l’une des distinctions les plus importantes que j’ai apprises.
Une fonction peut fonctionner techniquement tout en n’étant pas encore vraiment terminée.
Le texte peut manquer de clarté.
La hiérarchie visuelle peut ne pas être correcte.
Un écran peut contenir trop d’informations.
Un état vide peut être confus.
Ou la fonction peut fonctionner parfaitement sur mon appareil et se comporter différemment dans une autre situation.
La première version fonctionnelle n’est donc souvent que le début.
C’est le travail de finition qui transforme une fonctionnalité en véritable expérience produit.
J’ai sous-estimé à quel point tout allait devenir connecté
Plus KAVYLO grandit, moins les fonctions existent réellement de manière isolée.
Training est lié à Progress.
Training est lié à Recovery.
Nutrition apporte du contexte supplémentaire.
Apple Health et Apple Watch fournissent des données.
Le coaching peut utiliser des informations provenant de plusieurs domaines.
Une modification dans une partie de l’application peut donc influencer la manière dont une autre partie devrait fonctionner.
C’est l’un des aspects que je trouve les plus intéressants dans le développement de KAVYLO.
Mais cette connexion crée aussi davantage de complexité en arrière-plan.
Le défi consiste à rendre cette complexité utile sans la faire peser sur l’utilisateur.
Ce que je ferais différemment aujourd’hui
Si je recommençais aujourd’hui avec ce que je sais maintenant, je penserais plus tôt en termes de systèmes.
Pas seulement aux fonctions individuelles, mais aux structures capables de supporter les futures évolutions.
Cela comprend :
- des composants réutilisables
- des structures de contenu évolutives
- la localisation dès le départ
- une architecture de l’information plus claire
- des outils d’administration réutilisables
- des modèles de données cohérents
- moins de solutions uniques créées pour un seul cas
Certaines de ces leçons changent déjà la manière dont je construis KAVYLO aujourd’hui.
Par exemple, certaines parties du site qui auraient autrefois nécessité une modification de code individuelle fonctionnent maintenant grâce à des systèmes réutilisables.
Cela me permet d’ajouter plus rapidement de nouveaux contenus et évite de résoudre le même problème technique encore et encore.
Ce que j’ai appris en construisant KAVYLO
Construire KAVYLO a profondément changé ma manière de voir le développement logiciel.
Le produit visible n’est que la surface.
Derrière chaque écran se trouvent de nombreuses petites décisions liées à la structure, à la clarté, à la fiabilité et à ce qui doit se passer ensuite.
J’ai encore une longue liste de choses que je souhaite améliorer ou construire.
Mais je réfléchis aujourd’hui beaucoup plus consciemment à la manière dont chaque nouvelle fonction devient une partie de KAVYLO.
L’objectif n’est pas de construire l’application fitness qui possède le plus de fonctionnalités.
L’objectif est de créer une application fitness dans laquelle entraînement, nutrition, Recovery, progression et données associées fonctionnent ensemble d’une manière réellement utile au quotidien.
Et cela s’est révélé bien plus complexe, mais aussi bien plus intéressant, que je ne l’avais imaginé au début.