Il y a un moment, dans un projet personnel, où il faut arrêter d'ajouter des fonctionnalités et se demander : est-ce que ça marche, vraiment, entre les mains d'un humain ? Pour Rainbow Journey — mon projet de piano qui transforme l'improvisation en paysage lumineux réactif — ce moment a eu lieu le 12 septembre, devant mon vrai piano numérique, en jouant pendant qu'un agent IA prenait des notes à côté de moi.
Cet article raconte où en est le projet, ce que cette session a révélé, et surtout pourquoi le plan de travail qui en découle est ordonné comme il l'est. Parce qu'il y a une vraie méthode derrière : qu'est-ce qui doit rester entre les mains d'un humain, et qu'est-ce qu'on peut confier à une IA sans risque ?
D'abord, où on en est
Rainbow Journey est né d'une expérience simple à raconter et difficile à construire : quand on joue au piano, chaque note est une couleur, chaque intervalle est une direction dans une vallée 3D, et le monde réagit à ce qu'on joue — doucement si on joue doucement, tendu si la musique se tend. Derrière cette poésie, il y a du concret : 66 tests automatisés qui passent, une architecture TypeScript nette (contenu, modèle, moteur, rendu, interface — chaque couche a sa frontière), et un éditeur de réglages en jeu.
En une journée de développement assisté par IA, deux prototypes sont nés : Rainbow Journey (React/Three.js) et Chromatic River (JavaScript vanilla). Un rapport comparatif a tranché : Rainbow Journey est le meilleur socle technique, Chromatic River a les meilleures idées. Un plan de fusion des deux est écrit. Mais avant de fusionner quoi que ce soit, une question plus urgente : est-ce que jouer dessus fait du bien ?
La session qui a tout changé : jouer avec un agent dans la boucle
Voici le protocole, parce qu'il vaut la peine d'être expliqué. Plutôt que de lister des bugs depuis mon bureau, j'ai branché mon piano (un Roland FP-1), lancé le jeu, et suivi un quiz de jeu avec l'agent : jouer des notes staccato, des traits lents, doux puis fort, des accords, des intervalles larges. L'agent observait, notait, et on validait chaque étape ensemble.
Les résultats, en langage clair :
- Ça marche. Le MIDI est capté en direct, le mode démo fonctionne, la détection d'accords est stable, les suggestions musicales s'affichent correctement.
- Mais trois frictions sont apparues, toutes banales et toutes réelles : le piano sélectionné n'est pas retenu d'une session à l'autre (il faut le re-sélectionner à chaque visite), la sensibilité de la vélocité (la force avec laquelle on frappe) ne se ressent pas assez visuellement, et il manque un bouton "tout remettre à zéro" rassurant quand le monde visuel part dans tous les sens.
La leçon pédagogique est importante : aucun de ces trois problèmes n'aurait été trouvé par les tests automatisés. Ils sont apparus en jouant. Un test unitaire vérifie que le code fait ce que le code dit ; une session de jeu vérifie que l'expérience fait ce que l'humain espère. Ce sont deux métiers différents.
Le plan, et pourquoi il est dans cet ordre
Le plan complet tient sur une page. Voici son essence, vulgarisée — et à chaque fois, la raison du choix.
1. Finir le quiz de jeu (c'est le travail urgent, et il est à moi)
Il reste six étapes : intervalles jusqu'à deux octaves, extrêmes du clavier (du La grave au Do aigu), pédale de sustain, latence ressentie, enregistrement/relecture, accessibilité clavier. Pourquoi d'abord ? Parce que tout le reste — les nouvelles fonctionnalités, la fusion des deux prototypes, les optimisations — dépend de la réponse à une question que seule une session de jeu peut poser : est-ce que le fondation tient ? Construire une tour sur un quiz à moitié rempli, c'est décorer une pièce dont on n'a pas vérifié la charpente.
2. Trancher deux décisions en cinq minutes (elles débloquent tout le reste)
Deux questions restent ouvertes : le périmètre exact du "remise à zéro" (un gros bouton unique ou plusieurs resets ciblés ?) et l'ordre des prochains chantiers (hologramme de rivière future, couleurs émotionnelles, scores de style). Pourquoi c'est à moi ? Parce qu'un agent peut implémenter n'importe laquelle des options, mais il ne peut pas choisir pour moi ce que je veux ressentir en jouant. Une décision de produit non prise, c'est un agent qui part dans le mauvais sens avec le sourire.
3. Calibrer au feeling ce qui ne se calibre pas seul
Deux réglages visuels — l'épaisseur des traînées de lumière selon la force du jeu, et le "bloom" néon de l'eau — sont volontairement laissés partiels. Pourquoi ? Parce que "c'est joli" n'est pas une spécification. Ces réglages se ferment devant l'écran, en jouant fort puis doux, jusqu'à ce que l'œil dise oui. Aucune IA ne peut faire ce geste à ma place.
4. Déléguer ce qui est spécifié, garder ce qui demande du jugement
Et c'est là que le plan devient intéressant méthodologiquement. Il y a six chantiers prêts à être confiés à des agents :
- La persistance du choix de piano — le périmètre est fermé, les cas particuliers sont listés (rafraîchir, débrancher/rebrancher, plusieurs ports). C'est du travail de plomberie avec des tests possibles.
- La courbe de vélocité — paramétrable de façon isolée ; moi, je ne fais que valider le ressenti final.
- Un mode DEBUG collaboratif — l'architecture est déjà tranchée (un flux d'événements local que l'agent peut lire pendant que je joue). C'est de l'implémentation, pas de la conception.
- La relecture des tests automatisés — mécanique pure, verdict vert ou rouge.
- Les réglages mobiles des panneaux flottants — suit exactement le même patron que ce qui vient d'être fait sur desktop.
- La mesure de performance — les outils existent, il faut juste une baseline chiffrée.
Le critère de délégation, et c'est le cœur de l'article : on délègue ce qui a une spécification écrite, un périmètre fermé et des critères de succès vérifiables. On garde ce qui demande une oreille, un œil, ou une préférence. Le reste — les grandes visions comme l'hologramme de rivière future ou la fusion des deux prototypes — attend sagement que le quiz soit fini.
Ce que ce plan m'apprend sur le travail avec les IA
Écrire ce plan m'a pris moins de temps que de le justifier, et c'est voulu. Un plan de travail dans un projet assisté par IA, ce n'est pas une liste de tâches : c'est une frontière de responsabilité. D'un côté, ce que seul un humain peut faire — jouer, ressentir, décider ce qui vaut la peine d'exister. De l'autre, ce qu'un agent fait mieux que moi — exécuter une spécification sans se lasser, tester sans s'ennuyer, mesurer sans approximer.
La tentation, quand on est entouré d'agents rapides, c'est de tout déléguer et de tout construire en parallèle. Le plan dit l'inverse : ralentir, jouer, trancher, puis seulement accélérer. Les 66 tests automatisés rassurent sur la solidité ; la session de piano rassure sur l'expérience. Il faut les deux — mais dans cet ordre.
Prochaine étape, concrètement : une session piano pour finir le quiz, et pendant ce temps, un agent s'occupe de la persistance du choix de piano. Le piano parle, l'IA écrit, et le plan dit qui fait quoi.
Le plan complet, les détails techniques et l'état des tests sont versionnés dans le dépôt du projet. Rainbow Journey est en développement actif — retours de joueurs bienvenus.