Aller au contenu
beeraw
// développement sur-mesure · 2026

Croche

Un éditeur de partitions pour une enfant qui sait lire la musique et veut écrire la sienne. Sur iPad, au doigt, sans adresse e-mail ni mot de passe.

Le point de départ

Une enfant qui apprend le solfège arrive vite à un moment frustrant : elle sait lire une partition simple, elle a des idées, et elle n'a aucun moyen de les écrire autrement qu'au crayon sur une feuille qui finira pliée au fond d'un cartable.

Les éditeurs de partition professionnels existent, et ils sont hors de portée. Non pas parce qu'ils sont difficiles — parce qu'ils ne sont pas faits pour elle. Ils demandent un compte, une souris, un vocabulaire de métier, et ils ouvrent sur une page vide entourée de cent boutons. Le premier geste attendu d'un enfant est d'y renoncer.

Le besoin réel était étroit et clair : écrire, entendre, et surtout ne pas perdre.

Ce qui a été construit

Une application web installable sur l'écran d'accueil de l'iPad, en plein écran, indiscernable d'une application native pour qui l'utilise.

  • Une portée complète — clés de sol et de fa, accolade, barres alignées.
  • Les notes se posent au clavier de piano virtuel, ou en tapant directement sur la portée.
  • Lecture audio des deux portées, avec un curseur qui suit la musique.
  • Enregistrement automatique, avec historique des révisions.
  • Impression propre, pour que le morceau devienne une vraie partition sur papier.

Et deux écrans pour entrer : sa vignette, son code à quatre chiffres. Pas d'adresse e-mail, pas de mot de passe à retenir.

Le déroulé

Le sujet ressemble à un problème d'interface. C'est d'abord un problème de contraintes : chacune des décisions ci-dessous découle de la même question — « est-ce qu'une enfant de dix ans y arrive seule, sur un iPad, sans qu'on soit derrière elle ? »

Supprimer le compte utilisateur

Le premier obstacle d'une application pour enfant n'est pas la fonctionnalité, c'est l'inscription. Une adresse e-mail, une confirmation, un mot de passe qui doit contenir un caractère spécial : le parent est convoqué avant que l'enfant ait joué une note.

J'ai retiré tout cela. Deux écrans : une grille de vignettes — une par enfant, avec une icône et un prénom — puis un pavé numérique à quatre chiffres. Quatre points se remplissent, on est entré.

Le compromis de sécurité est assumé et il est proportionné à ce qu'il protège : des partitions d'enfant sur un iPad familial. Un code à quatre chiffres ne tiendrait pas une seconde devant un dossier médical ; il est exactement ce qu'il faut ici, et un mot de passe fort aurait garanti une seule chose — que l'application ne serve jamais.

Dessiner la portée en SVG plutôt qu'en canvas

Une partition est un objet vectoriel, avec des éléments qu'on veut pouvoir désigner, sélectionner et styler individuellement. Un canvas aurait été plus rapide à mettre en mouvement, mais chaque note y devient un tas de pixels : plus de sélection au doigt sans recalculer les zones à la main, plus de mise en surbrillance sans tout redessiner, et rien d'exploitable à l'impression.

En SVG, une note est un nœud du document. Elle se cible au CSS, elle reçoit un événement tactile, et l'impression sort nette à n'importe quelle taille — ce qui était l'exigence de départ : que le morceau puisse devenir une vraie partition sur papier.

Écrire pour des doigts, pas pour un curseur

Un clavier de piano à l'écran ne se conçoit pas comme un clavier de piano. Les touches doivent être assez larges pour deux mains d'enfant, ce qui interdit d'afficher toutes les octaves à la fois. Le clavier glisse donc latéralement pour atteindre les octaves voisines, plutôt que de se rétrécir pour tout montrer.

Même logique pour la portée active : plutôt qu'un indicateur discret, une bande colorée marque celle sur laquelle on écrit. Sur un écran tenu à bout de bras, un liseré de deux pixels n'existe pas.

Rendre la visite guidée obligatoire, puis rejouable

La visite guidée démarre d'elle-même à la première ouverture de chaque écran — six étapes sur la bibliothèque, seize dans l'éditeur — et le bouton d'aide la rejoue ensuite autant de fois qu'on veut.

Pour une enfant seule devant l'application, la visite est la documentation : il n'y aura pas de deuxième source. La rendre rejouable était l'autre moitié de la décision — un enfant qui revient après trois semaines a tout oublié, et n'osera pas demander.

Rendre l'attente impossible à manquer

Le dernier commit du projet à ce jour porte sur le retour visuel du chargement. Ce n'est pas un détail cosmétique : sur un iPad, une action qui met une seconde à répondre sans rien afficher est interprétée comme un échec, et l'enfant appuie de nouveau. Deux appuis, deux morceaux créés, de la confusion.

Le signal a donc été rendu franc plutôt que discret. La retenue graphique est une qualité quand l'utilisateur sait ce qu'il attend ; elle devient un défaut quand il ne le sait pas.

Ce que ça a changé

L'application est en ligne et utilisée. Le critère de réussite n'était pas le nombre de fonctionnalités mais l'autonomie : entrer, écrire, entendre et retrouver son morceau sans aide d'adulte. Il est tenu.

Ce que ce projet m'a appris et que j'emporte ailleurs : contraindre l'utilisateur cible aussi étroitement — une enfant, un iPad, un usage — est un accélérateur. La moitié des décisions d'interface se tranchent toutes seules quand on refuse de servir tout le monde.

Ce que je surveille : l'historique des révisions est aujourd'hui sans limite. Il faudra un jour décider ce qu'on jette, et cette décision-là est plus délicate qu'elle n'en a l'air quand l'utilisateur est un enfant attaché à ses brouillons.

Le prochain, c'est peut-être le vôtre

Dites-moi ce que vous voulez construire. Vous écrivez au développeur, pas à un formulaire anonyme.

Démarrer la conversation