Cayenne

Cayenne est le moteur de prévision de surf de Duckrew, spot par spot. Il est en bêta privée, sans utilisateur pour l’instant.

Dans 4 575 lignes d’avis publics sur les applications existantes, la frustration n°1 n’est pas la houle. C’est la note. « Comment 1 pied peut être bon ? »

Et le coût de l’erreur, dit par un utilisateur : « après avoir fait 3 heures de voiture, je vois le spot désert et des petites vaguelettes insurfables. »

On croit qu’un surfeur veut plus de données. Le corpus dit l’inverse : il veut une décision juste en deux secondes, et le droit de la vérifier. Le problème n’était pas de mieux prédire. Il était de mériter la confiance.

C’est le problème de toute interface où une machine propose et où un expert doit pouvoir contester. Ici, la contrainte était que je ne pouvais pas savoir si la prévision était juste. Il fallait donc concevoir le fait de ne pas savoir.

• 4 575 lignes d’avis publics : App Store, Google Play, Reddit, les avis d’un concurrent avec les réponses de son fondateur, des commentaires Instagram. Lecture intégrale en deux tranches, avec la même grille, chaque verbatim cité avec son numéro de ligne.
• En sortie : 20 thèmes comptés, 10 vérités, 4 personas, 10 jobs to be done, un arbre d’opportunités.

Les limites, écrites avant qu’on les demande. Ce sont les utilisateurs d’autres produits, pas les miens. Aucun entretien, aucune observation. Le corpus surreprésente les mécontents et les experts. Le premier terrain sera la bêta, et son protocole est écrit.

• Aucune mesure de terrain : la justesse du moteur n’est pas encore prouvée.
• Zéro utilisateur, zéro donnée d’usage : le produit est derrière un drapeau.
• Un système construit par des agents IA : le risque n’était pas d’écrire trop peu de code, c’était qu’il me raconte ce que je voulais entendre.

Trois mots, jamais un nombre : « Ça vaut le coup », « Ça se tente », « Reste au chaud ». Et dessous, le pourquoi, calculé, jamais rédigé.

L’incertitude comme matériau de design

La confiance ne se déclare pas, elle se conçoit.

La question du soir est désancrée

Pour vérifier un verdict, le produit demande le lendemain : « Hier à Lacanau, c’était comment ? ». Jamais « on avait dit ça se tente, c’était comment ? » : citer le verdict dans la question qui doit le vérifier tire les réponses vers ce qu’on a annoncé. La question porte sur la mer et pas sur la session, pour que les faux positifs restent mesurables, et le verdict ne se révèle qu’après la réponse.

Je n’ai pas écrit ce code à la main. J’ai conçu le produit et orchestré des agents pour le construire, avec Claude Code : 210 des 222 commits du moteur sont co-signés par l’agent, et ma formation à Epitech me sert à lire ce qu’il écrit, à le juger et à le refuser. Ce que j’ai apporté, ce sont les arbitrages : la langue, les refus, l’architecture de la décision, et les règles qui empêchent un système autonome de me raconter ce que je veux entendre.

• Un document de règles écrit avant la première ligne de code, avec ses interdits.
• Le critère de réussite écrit avant de regarder les données ; un résultat négatif se publie comme un positif.
• Une décision qui n’est pas écrite dans le dépôt n’a pas eu lieu.
• Si un document contredit le code, le code gagne.
• Aucun chiffre en documentation qui ne se vérifie dans le dépôt.
• Le jeu de test se regarde une fois par jalon : chaque regard de plus, c’est moi qui surapprends.

Le juge circulaire. Le 26 août, un audit établit que la chaîne qui transforme la mer du large en hauteur affichée porte un biais d’optimisme de +15,8 %, le même sur tous les spots. Aucun filet ne pouvait le voir : tous comparaient le moteur à une copie du moteur. Un étage de vérification qui se donnait raison, quel que soit le moteur.

Je n’ai pas corrigé l’erreur d’abord : j’ai corrigé le dispositif qui empêchait de la voir.

Ce qui n’est pas prouvé. Zéro utilisateur, zéro donnée d’usage, aucune mesure de justesse à ce jour. Le critère qui dira si le moteur marche est écrit et daté avant la première mesure.

[à écrire]