enregistrement-vers-obsidian

Que fait enregistrement-vers-obsidian ?

Transformez une réunion ou un cours en une partie autonome et entièrement liée d'un coffre Obsidian. Les deux modes partagent le pipeline, les conventions et l'étape de vérification ; ils diffèrent par ce qu'ils extraient et par la structure des notes.

	Mode réunion	Mode cours
Objectif	se souvenir de ce qui a été décidé et qui fait quoi d'ici quand	réapprendre les idées rapidement à tout moment
Hub	un hub de réunion par session + un MOC de série avec une entrée par réunion	un MOC par cours
Notes principales	fiches de décision de type ADR ; notes thématiques pour les connaissances durables	notes d'ancrage (denses) + notes atomiques (une idée chacune)
Traçabilité	horodatages du transcript [00:12:34] sur les décisions et les actions	liens PDF++ vers les slides [[deck.pdf#page=5]] ; horodatages pour le contenu uniquement oral
Référence	references/meeting-mode.md	references/lecture-mode.md

<skill> ci-dessous désigne le dossier dans lequel se trouve ce fichier.

1. Pipeline

materials ──► 1 setup ──► 2 transcribe ──► 3 pick mode ──► 4 note-writer ──► 5 verify ──► 6 report
             config,      scripts/          meeting or      writes notes     check_vault
             python       transcribe.py     lecture          (one subagent)   scan_secrets

1.1 Configuration

Notez d'abord l'heure de début : exécutez date +%s et conservez le nombre ; la vérification ne contrôle que les notes écrites après.

Lisez <skill>/config.toml. Il définit le backend/modèle/langue de transcription, la diarisation, notes.output_language, notes.default_mode et les noms des dossiers du coffre (notes_dir, moc_dir, meetings_dir, sources_dir ; les valeurs par défaut sont utilisées ci-dessous). L'interpréteur pour les scripts est runtime.python ; s'il est vide, utilisez ~/.local/share/recording-to-obsidian/venv/bin/python. Appelez-le $PY — c'est une notation : dans les commandes, écrivez les chemins littéraux complets de l'interpréteur et des scripts, une commande par appel, sans variables shell ni chaînes cd … && (les règles d'autorisation de l'agent correspondent à la commande littérale, et les variables la rendent invérifiable). S'il n'existe pas, dites à l'utilisateur d'exécuter install.sh (README) — n'installez pas pip dans les environnements Python de l'utilisateur.

Établissez les faits avant toute chose (ne demandez que ce que vous ne pouvez pas déduire) :

• coffre — le chemin de l'utilisateur, sinon le répertoire de travail actuel s'il contient .obsidian/ ou si l'utilisateur a dit « ce coffre » ; écrivez uniquement à l'intérieur ;
• materials — chemins absolus de chaque fichier ; classez chaque fichier par extension : audio/vidéo, sous-titres (.srt/.vtt), slides (.pdf/.pptx), notebooks/code, images/photos, documents ;
• titre, série/cours, date — de l'utilisateur, des noms de fichiers ou des matériaux ; n'inventez jamais une date ou une liste de participants (écrivez TBD et précisez-le) ;
• langue de sortie — notes.output_language sauf si l'utilisateur en a demandé une.

1.2 Transcription

Pour chaque enregistrement sans fichier de sous-titres correspondant (même racine), exécutez :

$PY <skill>/scripts/transcribe.py <enregistrement> -o <scratch>/transcripts

• <scratch> est un dossier temporaire en dehors du coffre (par exemple $TMPDIR/recording-to-obsidian-<date>-<slug>), utilisé pour tous les fichiers intermédiaires.
• Options si nécessaire : --model small (plus rapide, moins précis), --language en (ignorer la détection), --diarize (étiquettes de locuteurs ; nécessite install.sh --diarize et un jeton Hugging Face dans la variable d'environnement nommée par diarize.hf_token_env). La première exécution télécharge le modèle, ce qui peut prendre quelques minutes ; il imprime la progression sur stderr — laissez-le terminer.
• Il écrit <stem>.srt et <stem>.txt (une ligne [HH:MM:SS] Locuteur N: texte par segment) et imprime une ligne de résumé JSON (langue, modèle, durée, locuteurs, statistiques de nettoyage, chemins des fichiers). Conservez ce résumé : la langue, le modèle et la diarisation vont dans la section Source des notes.
• Les sous-titres existants provenant de n'importe quel outil peuvent être normalisés de la même manière : $PY <skill>/scripts/transcribe.py talk.vtt -o <scratch>/transcripts (aucun modèle impliqué ; les boucles de répétition sont pliées et un fichier .txt avec horodatages est écrit).
• Les enregistrements longs conviennent : le script gère des heures d'audio ; ne divisez pas le fichier.

Si la transcription échoue, signalez la ligne d'erreur ; $PY <skill>/scripts/transcribe.py --check montre ce qui manque.

1.3 Choix du mode

Un mode explicite de l'utilisateur (ou notes.default_mode différent de auto) l'emporte. Sinon :

1. Slides, notebooks, code de laboratoire ou documents parmi les matériaux → cours.
2. Sinon, lisez les ~5 premières minutes du transcript et parcourez le reste :

Signaux de réunion	Signaux de cours
plusieurs locuteurs avec un temps de parole comparable	un locuteur dominant qui explique
ordre du jour, mises à jour de statut, « où en sommes-nous sur… »	« aujourd'hui nous allons couvrir… », « la semaine dernière nous avons vu… »
propositions, compromis argumentés, « allons-y avec… », « d'accord »	définitions, dérivations, exemples travaillés, exercices
propriétaires et dates : « peux-tu t'en occuper d'ici vendredi ? »	questions du public posées pour comprendre, pas pour décider
projets, clients, délais, risques	numérotation des cours / conférences, lectures, devoirs

3. Les cas mixtes sont tranchés par l'objectif : les revues de conception, la planification, les rétrospectives, les débriefings et les 1:1 sont des réunions ; les talks techniques enregistrés, les formations, les séminaires et les tutoriels sont des cours, même avec un peu de discussion.

Enregistrez le choix et les deux ou trois signaux qui l'ont motivé (ils vont dans le rapport). S'il s'agit d'une vraie hésitation et que vous pouvez demander, demandez ; sinon choisissez et dites pourquoi.

1.4 Modèle d'exécution : orchestrateur + un rédacteur de notes

Lire un transcript entier, un deck page par page et des notebooks, puis écrire des dizaines de fichiers remplit rapidement la fenêtre de contexte, donc divisez les rôles :

• Orchestrateur — la session qui a reçu la demande. Il fait 1.1–1.3 (la sortie de la transcription reste sur le disque ; il lit juste assez du transcript pour choisir le mode), confie l'écriture à un sous-agent rédacteur de notes, puis exécute la vérification en 1.5 et fait le rapport.
• Rédacteur de notes — un sous-agent qui fait tout le travail d'écriture pour le mode choisi dans son propre contexte : lire chaque matériau, planifier, écrire, s'auto-vérifier. Une réunion ou un cours tient confortablement dans un contexte ; ne divisez pas les pages ou les morceaux de transcript entre agents (cela perd les références croisées et duplique les notes).

Faites le travail vous-même au lieu de déléguer lorsqu'aucun outil de sous-agent n'est disponible, lorsqu'un sous-agent ne pourrait pas faire ce que le travail nécessite (voir des images, exécuter des scripts, écrire des fichiers). En mode réunion, vous pouvez également écrire directement lorsque la réunion est assez courte pour que le briefing soit aussi long que le travail (un enregistrement de moins de ~15 minutes sans slides ni documents). Le mode cours utilise toujours le rédacteur de notes sauf si un sous-agent n'est pas disponible ou ne peut pas faire le travail : un deck doit être lu page par page, et cela appartient au contexte du rédacteur, pas au vôtre. Dites lequel vous avez choisi dans le rapport. La vérification (1.5) n'est jamais ignorée. Pour plusieurs sessions, utilisez un rédacteur de notes par session, séquentiellement lorsqu'elles ajoutent au même MOC.

Briefing pour le rédacteur de notes — il commence sans contexte, donnez-lui donc tout :

• le chemin absolu de cette compétence ; le mode ; les fichiers à suivre : references/meeting-mode.md ou references/lecture-mode.md, plus references/note-templates.md, references/transcript-processing.md, references/mermaid-style.md ;
• le chemin du coffre, le dossier temporaire, $PY, la langue de sortie, le titre/série/date (ou « dériver »), les noms de dossiers de la configuration ;
• les chemins absolus de chaque matériau et des fichiers de transcript, avec le résumé de transcription (langue, modèle, locuteurs) ;
• le MOC de série/cours existant et le hub/MOC de la session précédente, le cas échéant ; tout ce que l'utilisateur a demandé spécifiquement ;
• règles : écrire uniquement à l'intérieur du coffre ; ne jamais modifier les notes préexistantes sauf les ajouts documentés ; pas de secrets ;
• ce qu'il doit retourner : le bloc de rapport de la Section 3 plus tout ce qu'il n'a pas pu résoudre.

1.5 Vérification (orchestrateur)

Lorsque le rédacteur de notes revient, vérifiez son travail indépendamment plutôt que de vous fier à son résumé :

$PY <skill>/scripts/check_vault.py <coffre> --since <secondes epoch au début de la tâche>
$PY <skill>/scripts/scan_secrets.py <coffre>/sources

check_vault.py doit se terminer par issues: 0 ; corrigez aussi les avertissements sauf s'il y a une raison de ne pas le faire (dites laquelle). Il résout les liens comme le fait Obsidian (nom de fichier ou chemin partiel, insensible à la casse, ignorant #heading/|alias, sautant les blocs de code), donc un lien cassé qu'il signale est cassé dans Obsidian. Il vérifie : les [[liens]]/embeds/liens markdown cassés, les liens PDF++ sans .pdf, le frontmatter (title, type, date_created), la couverture du hub (chaque nouvelle note est liée depuis un MOC ou un hub de réunion ; chaque hub de réunion depuis un MOC), les secrets ; des avertissements pour les notes sans connexions, les Mermaid sans style et les liens ambigus.

Ensuite, vérifiez ce que les scripts ne peuvent pas :

• aucune note préexistante modifiée sauf les ajouts documentés (entrée du MOC de série, statut de décision remplacée, lien « suivant » du MOC de cours précédent) ;
• mode réunion : chaque décision a une fiche ou est explicitement mineure ; chaque action a un propriétaire (ou TBD), une date d'échéance (ou TBD) et un horodatage ;
• mode cours : le MOC liste chaque nouvelle note exactement une fois ; la granularité et les cibles d'ancrage de l'auto-vérification du cours sont satisfaites.

Corrigez les petits problèmes directement ; renvoyez les plus gros au rédacteur de notes avec la liste exacte. Réexécutez check_vault.py jusqu'à ce qu'il signale 0 problèmes. Supprimez le dossier temporaire (il contient le wav et les images de pages) sauf si l'utilisateur le souhaite.

2. Conventions partagées

Structure du coffre — les notes sont plates ; la navigation vient des MOC et des hubs, pas des dossiers.

coffre/
├── notes/                         # notes atomiques, d'ancrage, de décision et thématiques (plates)
├── reunions/<série>/              # hubs de réunion : "YYYY-MM-DD <titre>.md"
├── moc/<série ou cours>/        # MOC de série (réunions) / un MOC par cours
└── sources/<série ou cours>/<YYYY-MM-DD ou Cours_NN>/
    ├── <préfixe>_transcription.srt / .txt
    ├── <préfixe>.pdf               # slides, pour les liens PDF++
    ├── images_slides/  photos_tableau_blanc/  notebooks/
    └── slides_structurees.json     # enregistrement de lecture optionnel par page

Donnez à chaque fichier copié dans sources/ un préfixe de série/cours + session (Atlas_2026-11-12_transcription.srt, Optique101_L03.pdf, Optique101_L03_p08.jpg) : Obsidian résout les liens par nom de fichier, donc deux sessions qui contiennent toutes deux transcription.srt ou page-08.jpg se croiseraient. Les noms de dossiers utilisent le nom de la série/cours avec les espaces remplacés par -.

Noms de fichiers — le titre lisible par un humain, sans identifiants (les hubs de réunion sont l'exception : ils commencent par la date pour être triés). Évitez / \ : * ? " < > | # ^ [ ] ; écrivez — au lieu de :. Les titres sont suffisamment spécifiques pour être autonomes : Les limites de débit utilisent un seau à jetons par clé API.md, pas Limitation de débit.md.

Frontmatter — chaque note commence par un frontmatter YAML avec au moins title, type et date_created. type est moc, reunion, decision ou theme (mode réunion) et moc, ancrage ou atomique (mode cours). Les champs spécifiques au mode sont dans references/note-templates.md. Les tags sont en anglais kebab-case minuscules : un tag de série/cours, 2 à 4 tags de sujet, un tag de type ; réutilisez les tags déjà présents dans le coffre avant d'en inventer de nouveaux.

Langue — output_language = "auto" signifie : écrivez dans la langue des matériaux (la langue détectée du transcript, ou celle des slides). Lorsque la langue de sortie diffère de la langue des matériaux, gardez les termes techniques dans la langue originale et glosez chacun à la première occurrence — notes en chinois d'une réunion en anglais : commutateur de fonctionnalité (feature flag) ; notes en anglais d'un cours en allemand : error propagation (Fehlerfortpflanzung) — puis utilisez la forme qui se lit naturellement. Le code, les commandes, les chemins, les noms de produits et d'outils ne sont jamais traduits. Les titres suivent la langue de sortie.

Liens — chaque [[wikilink]] doit résoudre en une note ou un fichier du coffre. Liez à une note existante au lieu d'écrire un doublon. Utilisez un chemin ([[sources/Atlas/2026-11-12/Atlas_2026-11-12_transcription.srt|transcription]]) lorsqu'un nom nu pourrait être ambigu. Les liens PDF++ conservent toujours .pdf : [[Optique101_L03.pdf#page=5|Slide p.5 "Loi de Snell"]].

Horodatages — citez le [HH:MM:SS] du transcript pour chaque décision, action et affirmation qui ne provient que du discours. Ils sont la piste d'audit vers l'enregistrement.

Secrets — n'écrivez jamais d'identifiants dans le coffre. Avant de copier des notebooks ou du code dans sources/, exécutez $PY <skill>/scripts/scan_secrets.py --redact <copie> sur la copie (les valeurs deviennent <REDACTED>, les noms de variables restent). Les mots de passe prononcés, les numéros de carte ou les données personnelles sensibles lors d'une réunion ne sont pas non plus consignés — écrivez « les identifiants ont été partagés verbalement (non enregistrés ici) ».

Visuels — lisez references/mermaid-style.md avant d'écrire un diagramme Mermaid : il contient la palette et les règles qui garantissent le rendu des diagrammes. Une syntaxe invalide est pire que pas de diagramme.

Sorties du mode

• Réunion → references/meeting-mode.md : 1 hub, 1 fiche de décision par décision significative, 0–N notes thématiques pour les connaissances à conserver, une entrée ajoutée au MOC de série (créé à la première utilisation), transcript copié dans sources/.
• Cours → references/lecture-mode.md : 1 MOC, 8–15 notes d'ancrage pour un deck normal de 30+ pages, en moyenne au moins une note atomique par slide de contenu, slides/notebooks/transcript copiés dans sources/.

3. Rapport

Mode réunion :

Réunion 2026-11-12 — <titre>  (série: <série>)   mode: réunion (signaux: …)
  Transcription : 00:41:07, mlx:whisper-large-v3-turbo, 3 locuteurs, en → notes en
  Hub : reunions/<série>/2026-11-12 <titre>.md
  Décisions : 3 (fiches : 3)   Actions : 7 (propriétaire TBD : 1, échéance TBD : 2)
  Notes thématiques : 2   Questions ouvertes : 2   Risques : 1
  MOC de série : moc/<série>/MOC — <série>.md (entrée ajoutée)
  check_vault : issues 0, avertissements 0
  Non résolus : <locuteurs non appariés aux noms, passages peu clairs, …>

Mode cours :

Cours NN — <sujet>   mode: cours (signaux: …)
  Slides : 45 pages (contenu 37)    Points de connaissance : 68
  Notes : 56 atomiques + 12 d'ancrage     archétypes : concept=34, pratique-demo=6, …
  Notes par slide de contenu : 1.5     Ancrages avec ≥2 éléments riches : 12/12
  Mermaid : 14 (types : séquence, mindmap, diagramme de flux, …)
  check_vault : issues 0, avertissements 1 (avertissement : « Rate limiting » -> lien ambigu vers `notes/Limites de débit seau à jetons.md` corrigé)
  Non résolus : les diapositives 31–33 nécessitent le PDF du manuel (l'utilisateur l'a, pas nous)