Je construis une application d'enregistrement et de transcription de réunions exclusive à Mac appelée Kanary en utilisant une paire de Claude Code (Opus 4.8) / Codex (GPT-5.5). Certaines personnes pourraient avoir du mal à imaginer comment le « vibe coding » fonctionne réellement en développement.
Cette fois, je veux parler de la grandeur d'Opus, qui travaille spécifiquement en tant que designer et conseiller en spécifications de haut niveau.
Le défi cette fois-ci est le problème d'oublier d'arrêter l'enregistrement. C'est actuellement le problème le plus signalé par les utilisateurs.
Voici le dialogue : Moi > Claude > Codex > Claude.
Moi
Concernant l'arrêt des enregistrements : Comme Kanary n'affiche qu'un seul point rouge dans la barre de menu lorsque la fenêtre est fermée, et qu'il synthétise tout l'audio global du micro/haut-parleur sans être lié à une application spécifique, il est théoriquement impossible de détecter la fin d'une réunion. En conséquence, de nombreux utilisateurs se retrouvent avec des heures de silence enregistrées après une réunion. Je viens d'ajouter une fonctionnalité pour couper le début et la fin afin d'endiguer le problème, mais je pense que le véritable objectif est de faire prendre conscience à l'utilisateur que la réunion est terminée.
J'ai deux idées pour l'instant :
- Émettre une notification si le volume du micro/haut-parleur reste quasi silencieux pendant 5 minutes.
- Afficher un mini-lecteur au début de l'enregistrement pour éviter de le laisser tourner sans s'en rendre compte.
Les deux ont des avantages et des inconvénients. Qu'en pensez-vous ?
Claude
Pour aller droit au but, ces deux approches traitent différentes couches du problème, et celle qui touche le cœur (= les faire remarquer la fin) est l'approche de type 1. Cependant, les deux ont des faiblesses seules ; la solution gagnante réside dans la façon de les combiner. Détaillons cela.
D'abord, alignons-nous sur la définition du mode de défaillance
L'état « des heures d'enregistrement vide » se produit, par définition, parce que l'utilisateur n'est pas devant l'écran ou ne le regarde pas. C'est le cœur de l'axe d'évaluation.
- 2 (mini-lecteur) est une affordance visuelle → Il n'atteint que les personnes qui regardent l'écran. Il fonctionne pour les cas où quelqu'un est « à son bureau mais absorbé par un autre travail », mais il échoue théoriquement à atteindre le problème central : « a quitté le bureau / s'est éloigné du PC. » Il ne fonctionne pas dans la situation où il est le plus nécessaire.
- 1 (notification) atteint l'extérieur de l'écran → Elle va au Centre de notifications, à l'écran de verrouillage et (si mis en miroir) à l'iPhone. La compatibilité avec le mode de défaillance est nettement meilleure avec 1.
Donc, si nous visons le cœur, nous nous basons sur 1.
Faiblesses de chaque proposition
La faiblesse de 1 est les faux positifs. Le silence ≠ Fin de réunion. Le silence se produit normalement dans les réunions réelles (lecture de documents, réflexion, pauses, visionnage d'une vidéo silencieuse via le partage d'écran, etc.). Un seuil de 5 minutes est un compromis entre « court = ennuyeux / long = espace vide restant », ce qui devient facilement un enfer de réglage. Si des déclenchements faux se produisent quelques fois, la confiance dans la notification meurt, ce qui est le plus effrayant.
La faiblesse de 2 est l'habituation et les fuites de partage d'écran. Un affichage constant devient un fond d'écran en une semaine et disparaît de la cognition. De plus, étant donné la nature d'un outil de réunion, avoir un indicateur d'enregistrement qui apparaît sur un écran partagé est un accident en termes de fuite d'informations et d'esthétique.
La solution gagnante : Ne pas juger par le silence seul. « Silence ET Inactivité de l'utilisateur »
Le problème des faux positifs de 1 disparaît presque si vous ajoutez un autre signal.
- Le RMS audio est en dessous du seuil (micro + haut-parleur) PLUS
- Le temps d'inactivité HID (CGEventSourceSecondsSinceLastEventType / IOKit, aucune opération clavier/souris), et idéalement le sommeil de l'écran / le verrouillage de l'écran.
Prendre cette logique ET change le jugement de « silence » à « la réunion est terminée ET la personne est partie. » Cela ne déclenche presque jamais de faux positifs. Le silence pendant une réunion ne le déclenchera pas car l'utilisateur est à son bureau et utilise l'ordinateur, donc il n'est pas « inactif. »
Et si cette condition est remplie, le fait que nous puissions déclencher en toute sécurité un arrêt automatique est énorme :
- L'utilisateur opère (présent) → Ne pas arrêter automatiquement ni notifier quoi qu'il arrive. La personne regarde, et il y a le point rouge dans la barre de menu. Faites-lui confiance. (C'est là que le mini-lecteur de 2 fonctionne).
- Inactif mais audio présent → Possibilité d'un enregistrement à distance légitime comme un webinaire. Ne pas arrêter.
- Inactif ET silencieux → C'est le seul état confirmé de « réunion terminée + parti » → Notifier → Si aucune réponse, arrêt automatique.
Puisqu'ils ont quitté le bureau, le risque de manquer le reste de la réunion avec un arrêt automatique est structurellement nul. Puisque la fonction de coupe nettoie le silence de fin, le matériel au point d'arrêt est également propre. En créant une échelle de notification (une échappatoire pour le travail de longue durée) → arrêt automatique après M minutes (auto-guérison pour les utilisateurs partis), cela se corrige même si l'utilisateur ne remarque pas la notification.
Pourquoi nous devrions arrêter, pas seulement « les faire remarquer »
La raison de s'en tenir au cœur plutôt que de simplement couper est la vie privée. Capturer l'audio ambiant pendant des heures après une réunion est un accident impliquant l'enregistrement de conversations privées sans rapport avec la réunion. C'est pourquoi je pousse pour la direction active de l'arrêt en cas d'absence plutôt que simplement « les faire remarquer (passif). »
Résumé
- Axe principal = Version améliorée de 1 : Silence ET inactivité → Notification → Échelle d'arrêt automatique. Touche directement le mode de défaillance, écrase les faux positifs et protège la vie privée.
- 2 = Auxiliaire : Précieux comme affichage ambiant pour les utilisateurs à leur bureau, mais priorité moindre. S'il est inclus, le masquage/la réduction automatique pendant le partage d'écran est un must.
- Ajouter l'affichage du temps écoulé au point rouge de la barre de menu est peu coûteux mais augmente la conscience que « ça enregistre encore », donc ça vaut la peine de le faire immédiatement quelle que soit la direction choisie.
En contre-argument, on pourrait ne pas aimer l'arrêt automatique comme « coupant arbitrairement le matériel de l'utilisateur. » Dans ce cas, le compromis serait d'arrêter à la notification, rendant la notification fiable en éliminant les faux positifs avec la condition d'inactivité. Une fois que vous décidez d'aller jusqu'à l'arrêt automatique ou de vous arrêter à la notification, la politique de mise en œuvre est définie.
Codex
Je pense que l'avis de Claude est très solide. Surtout l'organisation selon laquelle « 1 et 2 sont des couches différentes » et la logique « Silence ET inactivité » est forte.
Voici comment je prioriserais :
- Notifier sur Silence ET Inactivité
- Micro et haut-parleur quasi silencieux
- Aucune opération clavier/souris
- Idéalement, prendre en compte le verrouillage de l'écran/le sommeil de l'affichage
- Après 5 minutes, une notification : « L'enregistrement continue. Arrêter ? »
- Arrêt automatique si aucune réponse pendant un certain temps après la notification
- Cela dépend de la philosophie du produit, mais je pense qu'il est acceptable de l'inclure.
- La raison est comme Claude l'a dit : ce n'est pas un problème de stockage, c'est un problème de vie privée.
- Cependant, initialement, il devrait pouvoir être activé/désactivé dans les paramètres, ou au moins « Recommandé ON. »
- Afficher le temps d'enregistrement sur le point rouge de la barre de menu
- Peu coûteux et efficace.
- Comme ● 1:24:03, pour qu'ils sachent « ça enregistre encore » même si la fenêtre est fermée.
- Cela vaut la peine d'être fait maintenant.
Quant au mini-lecteur, je le déprioriserais en tant que solution centrale. La raison est que le plus grand cas d'« oubli et de laisser tourner » est quand ils ne regardent pas l'écran ou ont quitté leur siège. Le mini-lecteur ne les atteint pas là. De plus, le risque qu'il apparaisse dans les partages d'écran est un peu gênant.
Ce n'est pas que le mini-lecteur soit inutile, mais il a un rôle différent. Il est efficace pour « rappeler naturellement pendant le travail que l'enregistrement est en cours. » Mais pour « arrêter l'accident d'enregistrer pendant des heures après une réunion », la notification/l'arrêt automatique touche plus directement la cible.
Ma spécification recommandée est celle-ci :
Si le micro/haut-parleur est quasi silencieux ET que l'inactivité de l'utilisateur continue pendant 5 minutes pendant l'enregistrement, notifier. Si aucune réponse pendant encore 5 minutes après la notification, arrêt automatique. Après l'arrêt, couper le silence de fin et sauvegarder.
Avec cette configuration, il est difficile de s'arrêter pendant le silence dans une réunion, et cela ne s'arrêtera pas pour les cas où l'audio est en cours de lecture, comme regarder un webinaire. De plus, il peut s'auto-guérir dans l'état le plus problématique : « loin du bureau et incapable de remarquer la notification. »
Une chose à noter : le seuil pour « quasi silencieux » varie considérablement selon l'environnement de l'utilisateur, donc des valeurs fixes pourraient être désordonnées. Il serait préférable d'apprendre le bruit ambiant après le début de l'enregistrement et de rechercher des états « semblables au silence » de manière relative. Cela peut être approximatif au début, mais cela déterminera la qualité de l'expérience à l'avenir.
En conclusion, je suis fortement d'accord avec la proposition de Claude. Cependant, j'aimerais aller un pas plus loin de « le cœur est de les faire remarquer » à arrêter réellement quand ils partent. Le sentiment de confiance que Kanary vous protégera automatiquement correspond mieux à ce problème.
Claude
D'accord. Je suis favorable à aller jusqu'à l'arrêt quand ils partent. Le format en échelle (Silence + Inactivité 5 min → Notification → Encore 5 min → Arrêt automatique → Coupe de fin) est solide. En plus de cela, j'ajouterai 4 points qui feront la différence dans la mise en œuvre.
1. Le sujet du seuil est comme Codex l'a dit, et cela détermine la qualité de l'expérience. Rendons la conception plus spécifique.
Des seuils dB fixes seront définitivement désordonnés en raison des différences environnementales, donc la bonne réponse est de regarder les valeurs relatives au sein de la session d'enregistrement. Apprendre de manière continue la « plage de volume actif (médiane) pendant la parole » dans les premières dizaines de secondes à minutes de l'enregistrement, et considérer le RMS actuel comme un état « semblable au silence » s'il chute significativement par rapport à cela. N'utiliser les valeurs absolues que comme une garde de limite inférieure supplémentaire.
Autre chose : il est efficace que le micro et le haut-parleur puissent être traités différemment. Pour le côté haut-parleur, au lieu de mesurer le RMS, vous pouvez obtenir « si une application émet actuellement du son » depuis l'OS (processus audio CoreAudio / tap), ce qui permet un jugement presque déterministe. RMS relatif uniquement pour le côté micro. Prendre le ET des deux étant silencieux. Puisque le haut-parleur devient un signal confirmé, les faux positifs sont encore réduits.
Une note : comme il y a des cas où les réunions commencent tranquillement (où la ligne de base « semblable au silence » apprise au début est en fait une conversation normale), gardez la ligne de base continue plutôt que fixe.
2. Ajouter deux garde-fous à l'arrêt automatique.
- Ne pas arrêter automatiquement pendant les N premières minutes (par exemple, 5-10 min) de l'enregistrement. Pour éviter de tuer le silence pendant la configuration ou l'état « démarrer l'enregistrement tôt et attendre. »
- Une échappatoire pour « Ne pas arrêter cette session / Ne plus demander. » Pour que les utilisateurs expérimentés dans des cas légitimes comme l'enregistrement ciblé solo de longue durée ou les conférences quasi silencieuses ne soient pas ennuyés à chaque fois. Une fois que « Garder » est pressé, désactivez-le pour cette session.
3. Être attentif à l'ordre de valeur pour ne pas mal allouer l'investissement. En réalité, l'arrêt automatique est le véritable atout pour les « utilisateurs absents », et la notification est principalement une courtoisie + une vérification de consentement pour les « personnes à leur bureau mais absorbées. » S'ils ont quitté le bureau, ils ne remarqueront pas la notification (les actions de notification sur l'écran de verrouillage sont également limitées), donc ne sur-ingénierisez pas l'UX de la notification. Réaliser que l'auto-guérison se produit du côté de l'arrêt automatique vous permet de garder la mise en œuvre initiale simple.
4. Construire une boucle de rétroaction pour le réglage des seuils dès le début. Le meilleur signal pour savoir si un arrêt automatique était un faux déclencheur est si l'utilisateur a manuellement repris l'enregistrement immédiatement (dans les X minutes) après l'arrêt. Enregistrer cela accumulera automatiquement des preuves de « trop d'arrêts », vous permettant de resserrer les seuils avec des données. C'est peu coûteux, donc ça vaut la peine de le mettre en place dès le début.
Je pousse pour ON par défaut (d'accord avec le « Recommandé ON » de Codex, ou plutôt, je pousse pour ON avec des seuils conservateurs). La raison est simple : les personnes qui sont brûlées par cet accident sont celles qui n'ouvrent pas l'écran des paramètres. Les paramètres ne sauvent que les personnes qui n'étaient pas dérangées pour commencer.
Le temps écoulé dans la barre de menu (● 1:24:03) n'a aucune dépendance et peut être fait immédiatement. Le mini-lecteur est reporté comme un auxiliaire avec un rôle différent + masquer pendant le partage d'écran.
Je pense que les spécifications sont déjà solides. La seule décision restante est « d'aller jusqu'à l'arrêt automatique dans la première version ou de voir comment ça se passe avec seulement des notifications pendant un cycle. » Si nous prenons le cadrage du problème de vie privée, je parierais sur une sortie avec l'arrêt automatique inclus dès le début.
N'est-ce pas ? N'est-ce pas incroyable ?
Il n'y a pas beaucoup de designers de produits capables de proposer instantanément des spécifications montrant une considération aussi méticuleuse. J'ai travaillé avec des personnes considérées comme des super designers dans la Silicon Valley, mais il est impossible pour un humain de fournir une réponse après avoir lu le code source à cette vitesse.
Les idées de Claude sont particulièrement profondes. Avec Opus 4.8, il a commencé à réfléchir à des parties très profondes de l'expérience utilisateur.
Cependant, même s'il peut penser aussi profondément et donner des instructions jusqu'au contenu spécifique du code, si vous le laissez toucher au code dans ce flux, c'est un total maladroit et il cassera définitivement quelque chose. C'est comme une personne brillante mais maladroite de ses mains. C'est pourquoi je fais toujours gérer le code par Codex. Et enfin, je fais réviser par Claude pour signaler le code redondant de Codex. (Mais c'est Codex qui le corrige aussi.)
Donc, je passe mes journées à développer entouré de ces deux surhumains.
J'espère que vous pouvez ressentir l'atmosphère de cette réunion de spécifications à travers la vie quotidienne du développement en juin 2026.
