---
title: "Recherches et audits : ce que nous avons vraiment vérifié"
subtitle: "Le récit complet des tests, des essais en direct, des bugs trouvés à l'usage et de la frontière assumée entre ce qui est prouvé et ce qui est encore une intention — sur les deux projets"
date: 2026-09-12
time: "22:51"
author: VFG
publishedBy: idea
status: pub
tags: ["rainbowjourney", "chromaticriver", "audit", "tests", "methodologie", "devblog"]
---

![Recherches et audits : ce que nous avons vraiment vérifié](../images/covers/2026-09-12-recherches-et-audits-ce-qui-a-ete-verifie.png)


Un devblog qui ne raconte que les réussites finit toujours par mentir un peu. Ce billet fait l'inverse : il raconte comment Rainbow Journey et Chromatic River ont été vérifiés, ce qui a été trouvé cassé en cours de route, ce qui a été corrigé, et — point le plus important — ce qui reste aujourd'hui non vérifié malgré tous les tests passés au vert.

C'est un billet long, volontairement. Il rassemble deux méthodologies d'audit très différentes, appliquées à deux projets qui partagent la même ambition mais pas la même façon de la construire.

## Deux philosophies de vérification

Rainbow Journey est un code unique, qui évolue par vagues successives sur une seule base. Chromatic River est né d'un tout autre procédé : un contrat d'interface figé (`CONTRATS.md`), puis des paquets de travail à fichiers strictement exclusifs, confiés à des agents lancés en parallèle sans jamais lire le travail des autres, avant une relecture croisée finale.

Ces deux méthodes appellent deux formes d'audit :

- Pour Rainbow Journey, l'audit est **continu** : suite de tests automatisés, revalidée à chaque lot, complétée par des sessions de jeu en direct qui remontent des frictions que les tests ne peuvent pas voir.
- Pour Chromatic River, l'audit est **structurel d'abord** : chaque paquet livré est relu contre le contrat qui l'a défini, avant même d'être exécuté — puis vérifié à l'exécution dans un navigateur, note par note, geste par geste.

## Rainbow Journey : ce que l'automatisation a attrapé

Le lot d'optimisation et de robustesse (« Lot 1 ») a été vérifié par une suite complète : tests unitaires et d'intégration, scénarios de bout en bout dans un vrai navigateur Chromium, vérification stricte des types, analyse statique, build de production, et audit de sécurité des dépendances. Au moment de la clôture de ce lot, l'ensemble était vert : aucune erreur de type, aucun avertissement de lint, aucune vulnérabilité signalée.

Deux incidents ont pourtant été trouvés *pendant* cette vérification, pas avant :

| Incident constaté | Cause | Correction |
| --- | --- | --- |
| Un scénario de rejouabilité échouait par intermittence | Un composant fermait la connexion à la base de données locale partagée, invalidant les sauvegardes suivantes | Suppression de cette fermeture prématurée, la connexion reste un singleton actif |
| Des bascules rapides de réglages dans l'interface semblaient en retard | Les notifications à l'interface étaient groupées une fois par image, ce qui convient au flux MIDI mais pas à un clic direct | Un chemin de notification immédiate a été ajouté pour les actions directes de l'utilisateur |

Ces deux bugs partagent un point commun : ils n'apparaissent que sous un usage réel et répété, pas dans un test qui exécute une seule action isolée. C'est une des leçons méthodologiques du projet — une suite verte ne dit pas qu'un système résiste à l'usage, seulement qu'il résiste aux scénarios qu'on a pensé à écrire.

## Le piège du rendu logiciel

Un autre épisode mérite d'être raconté en détail parce qu'il aurait pu conduire à une conclusion complètement fausse. Lors de premiers essais automatisés, la scène 3D tournait autour de trois images par seconde — un chiffre catastrophique qui aurait pu faire croire que le monde 3D était bien trop lourd pour tourner correctement.

En creusant, la cause n'était pas la scène : c'était l'environnement de test, un navigateur exécuté en rendu logiciel (sans accélération graphique), très différent de ce qu'un vrai utilisateur voit dans Chrome ou Edge avec sa carte graphique activée. Une fois le test relancé avec un navigateur complet et l'accélération D3D11 sous Windows, la même scène tournait normalement. La leçon générale, consignée depuis dans la mémoire du projet : ne jamais déclarer une scène trop lourde à partir d'un chemin d'exécution que l'utilisateur final n'empruntera jamais.

## L'essai en direct : ce que les tests automatisés ne peuvent pas voir

Après la clôture du Lot 1, une session collaborative a branché le vrai piano — un Bird DP1 de 88 touches — et suivi un protocole écrit à l'avance, en quatorze étapes numérotées : connexion MIDI, persistance du port choisi, cartographie de tous les mécanismes de remise à zéro existants, notes et vélocité, accords, intervalles jusqu'à deux octaves, extrêmes du clavier, pédale et Panic, latence ressentie, enregistrement et relecture, accessibilité.

Ce protocole a produit des résultats qu'aucune suite automatisée n'aurait pu remonter, précisément parce qu'ils dépendent d'un ressenti humain et d'un vrai geste musical :

- la sélection du port MIDI d'entrée n'était pas conservée d'une session à l'autre ;
- il n'existait aucun bouton de remise à zéro global — seulement des remises à zéro partielles (Panic pour les notes, un préréglage pour les réglages, un retour au direct uniquement en relecture) ;
- la sensibilité à la vélocité méritait d'être revue, alors que la détection des notes elles-mêmes était jugée « nickel » ;
- un mode de débogage collaboratif, permettant de suivre les événements en direct pendant une session de test avec un agent, restait à construire.

Ces quatre constats ont été tracés comme priorités explicites plutôt que corrigés dans l'urgence, avec un ordre de priorité proposé par l'utilisateur lui-même. C'est une différence importante avec un audit de code classique : ici, l'audit ne cherche pas seulement des bugs, il cherche des frictions d'usage, qui ne sont pas des erreurs de programme mais des manques de produit.

## Chromatic River : un audit qui commence avant le premier test

Le processus de vérification de Chromatic River commence plus tôt : par la relecture systématique de chaque paquet de travail contre le contrat qui l'a défini, avant même de lancer le navigateur. Les douze paquets des vagues A, B et C ont ainsi été confrontés un par un à leurs signatures figées — non pas pour vérifier qu'ils « marchent », mais qu'ils respectent exactement la forme convenue, condition nécessaire pour que des paquets développés en parallèle et sans communication s'assemblent sans friction.

Une fois cette relecture terminée, une vérification à l'exécution a suivi une liste de points de contrôle précis, jouée dans un vrai navigateur :

| Point vérifié | Résultat observé |
| --- | --- |
| Démarrage sans erreur | Application prête, aucune erreur en console |
| Octave Do4→Do5 et Do5→Do4 | Toujours étiquetée « Octave », jamais « Ancrage » (l'ancien bug de l'unisson) |
| Carte de transition | La note de départ s'affiche bien (« Do4 → Mi4 ») |
| Degrés en gamme courte | Pentatonique majeure : le Sol s'affiche bien comme une quinte, pas une quarte |
| Tonique sur touche noire | En Fa♯ majeur, la tonique est bien marquée malgré la touche noire |
| Fantômes | Quatre suggestions fortes sur quatorze candidats, glyphes lisibles |
| Mouvement du bateau | Environ 1,9 mètre par seconde simulée, sillage continu, rame animée |
| Qualité de réflexion | Trois résolutions différentes selon le réglage choisi |
| Statistiques | Classement des enchaînements en direct, correctement mis à jour |
| Taille de texte | Trois crans appliqués correctement au HUD |
| Menus | Neuf listes déroulantes fonctionnelles (tonique, gamme, émotions, qualité, entrées, sorties, canal, mode) |

Deux défauts ont été trouvés *pendant cet essai en direct*, pas avant :

- la carte de transition n'avait aucun fond et devenait illisible sur le ciel le plus clair du parcours — corrigée par un fond assorti à celui du panneau de statistiques ;
- la fontaine de particules projetait d'énormes nuages blancs qui masquaient le canal et effaçaient la couleur de la note elle-même, parce que le point d'émission projeté depuis la touche tombait à quelques mètres seulement de la caméra — corrigée en repoussant l'émission à une distance minimale, en plafonnant la taille des particules et en élargissant le fondu de proximité.

## Ce qui reste non vérifié — et pourquoi c'est important de le dire

Pour Chromatic River, trois points restent explicitement hors de portée de la vérification actuelle : le MIDI physique (le navigateur utilisé pour les tests automatisés refuse l'accès Web MIDI, seule une doublure logicielle a été testée avec 43 assertions), la comparaison réelle des images par seconde selon le niveau de qualité (la boucle de rendu était suspendue pendant la mesure, faussant le résultat), et le comportement du canal en boucle sans segment traversant (corrigé dans le code, jamais observé à l'écran).

Pour Rainbow Journey, la liste équivalente inclut : la latence réelle entre la touche et l'effet visuel avec le piano physique (jamais mesurée), le comportement sur des sessions longues de dix à trente minutes (aucun percentile CPU, GPU ou mémoire collecté), et la cible de 60 images par seconde en 1080p, qui reste un objectif, pas une garantie mesurée.

Cette liste n'est pas un aveu de faiblesse. C'est une discipline : dans les deux projets, la documentation distingue explicitement ce qui a été *prouvé* par un test reproductible, ce qui a été *observé* une fois en direct sans automatisation, et ce qui reste une *intention* documentée mais non construite. Un statut ou un handoff qui confond ces trois catégories finit toujours par surestimer ce qui existe réellement.

## La leçon commune aux deux audits

Qu'il s'agisse d'une suite de tests automatisés ou d'une relecture croisée contre un contrat, aucune des deux méthodes ne remplace l'autre. Les tests automatisés attrapent les régressions et les cas limites qu'on a pensé à écrire ; ils ne remplacent jamais un vrai piano branché, une vraie improvisation, un vrai regard porté sur l'écran pendant que les mains jouent. Inversement, un essai en direct ne peut pas, à lui seul, garantir qu'un changement futur ne cassera pas silencieusement ce qui marchait la veille.

Les deux projets ont donc choisi la même réponse à cette tension : garder les deux, les documenter séparément, et ne jamais laisser un statut vert masquer une case encore non cochée.