Champ	Valeur
Phase	4 sur 5 — l'assistant connaît les gens, tient les promesses, et ne parle qu'à bon escient
Document parent	`ASSISTANT-V2.1.md` — en particulier §13.2 (personnes & engagements), §17 (voix & réunions), §9.6 (candidats connecteurs), §14.4 (budget d'interruption)
Version	1.0 — 9 octobre 2026
Auteur	Spark, pour Bruno
Statut	Prêt à implémenter
Tranches	#211 (personnes & engagements), #209 (voix, transcription & réunions), #201 (proactivité / insights, forme complète)
Effort estimé	9–13 jours
Prérequis	Phase 0 (entités #192, miroir `Personnes.md` en coquille #193), phase 1 (tâches #202, file d'approbations #203), phase 2 (consolidation #194, budget d'interruption, automatisations #208) ; phase 3 recommandée (l'agenda réel et les courriels candidats donnent leur pleine valeur à #211 et à la préparation de réunions) mais non bloquante : la phase fonctionne sur le vault seul, dégradée proprement
Dépendances	#211 ← #192, #202 ; #209 ← #205, #211 ; #201 ← #194, #199, #202, #211
Débloque	Phase 5 (les packs Communication, Maison & admin et Voyages consomment personnes, engagements et cycle de réunion)

Résultat visible à la fin de cette phase. L'assistant sait qui sont les gens : entités personnes peuplées, notes dédiées quand Bruno le veut, anniversaires, dernières interactions sourcées. Il tient les engagements dans les deux sens — ce que Bruno a promis et ce qu'on lui doit — détectés en conversation ou dans les courriels (en candidats validables, jamais en silence), suivis en revue, avec des relances rédigées en brouillon. La voix devient une entrée de premier rang : dictée, notes vocales transcrites et triées, et cycle de réunion complet (préparation avec historique des participants → compte rendu structuré → actions datées avec responsables). Enfin, la proactivité #201 arrive en forme complète : détecteurs branchés sur tâches, engagements, plans et habitudes, publiés dans Insights.md et consommés sous le budget d'interruption — utiles ou silencieux.

1. Objectif et principe directeur

Le principe : les gens ne sont pas des données à aspirer, ce sont des relations à servir. Chaque information sur une personne a une source que Bruno peut voir (il l'a dite, écrite, ou validée depuis un courriel candidat) ; rien n'est importé en masse, rien n'est inféré sur une personne à partir de signaux indirects, et les coordonnées restent sensitivity='private' — jamais transmises à un outil externe ou à un envoi sans que Bruno les ait lui-même fournies dans ce contexte.

Corollaires :

Un engagement n'existe que validé. Détecter n'est pas enregistrer : toute détection (chat, courriel, compte rendu) produit une carte ; la création silencieuse est structurellement impossible (le pipeline n'a pas de chemin d'écriture sans approval de type fait/triage).
La proactivité se juge à son taux d'acceptation. Un insight refusé ou ignoré de façon répétée doit faire taire son détecteur (seuil relevé, puis suspension proposée) — la métrique décide, pas l'entêtement du système.

2. Périmètre

2.1 Inclus

#211 : peuplement des entités personnes (miroir Personnes.md complet, notes dédiées optionnelles par personne), outils people.* ; table commitments (parent §13.2) et outils/API associés ; détection d'engagements en conversation (carte) et via les candidats connecteurs (§9.6 du parent — activation du réglage par connecteur, défaut off) ; suivi (revue du soir, échéance, relance rédigée en brouillon, clôture en un clic) ; anniversaires depuis les attributs des entités (recette de la phase 2 activée sur données réelles).
#209 : dictée dans les surfaces existantes ; enregistrement audio déposé (PWA, chat, pièce jointe) → transcription par le fournisseur choisi explicitement dans les Configurations (décision ouverte n° 3 du parent : défaut proposé = API du provider LLM déjà configuré ; aucun envoi audio par défaut sans ce choix) ; notes vocales comme items d'inbox kind='voice' (transcrites, résumées en une ligne, triées) ; cycle de réunion : note de préparation (participants = entités, historique sourcé, engagements ouverts avec eux, documents liés), capture optionnelle dans la note (dictée ou audio déposé), compte rendu structuré selon la procédure par défaut (résumé, décisions, actions) avec extraction des actions en tâches datées à responsables nommés dans le texte uniquement, décisions proposées à la mémoire en cartes, rappels de consentement à la capture.
#201 : détecteurs complets (projet sans prochaine action ; tâche reportée ≥ 3 fois ; engagement échu ; note « à faire » vieillissante > 21 j ; snooze ≥ 3 sur un rappel ; série d'habitude cassée ; inbox vieillissante) tournant en tâche planifiée légère et à la demande ; publication dans Insights.md (sections gérées, suppression = rejet du détecteur pour cet objet) ; suggestions injectées au compileur de contexte (bornées, sourcées) ; consommation stricte du budget d'interruption (phase 2) ; retour d'acceptation mesuré par détecteur avec auto-ajustement (§7.3).

2.2 Exclu (phases ultérieures / jamais)

Tout enrichissement externe de profils (réseaux sociaux, bases tierces) : hors périmètre durable, pas seulement ajourné — contraire au principe du §1.
L'import en masse d'un carnet d'adresses : un connecteur contacts en lecture pourra être un pack de la phase 5, avec validation personne par personne ; rien ici ne l'anticipe en base.
L'enregistrement automatique de réunions (bot qui rejoint les appels) : la capture est toujours déclenchée par Bruno dans la note.
Le diagnostic ou le conseil santé à partir d'habitudes ou de personnes : hors périmètre (rappelé dans les procédures des packs concernés).

3. État d'entrée

Élément	Usage en phase 4
Entités/relations + `Personnes.md` coquille (phase 0)	Le modèle est là ; la phase peuple, outille et met en usage
Consolidation (phase 2)	Émet déjà faits `open_loop` et candidats entités ; la phase branche la promotion en engagements et les cartes associées
Candidats connecteurs (mécanisme phases 2–3, défaut `off`)	Première source réelle : les engagements et rendez-vous lus dans les courriels choisis
Inbox et triage (phase 1)	Les notes vocales sont des items comme les autres ; les comptes rendus déposés se trient vers tâches/engagements
Agenda réel (phase 3, optionnel)	La préparation de réunion part des événements ; sans connecteur, elle part des notes de réunion du vault

4. Modèle de données

Table commitments du parent §13.2 (dans data/assistant.sqlite3) — reprise sans changement, avec la règle : source ∈ {chat, consolidation, connector, meeting, manual} et source_ref obligatoire sauf manual.

Attributs d'entité personne utilisés par la phase (dans attrs_json, schéma libre mais documenté) : anniversaire (MM-JJ ou AAAA-MM-JJ), role (texte libre de Bruno), canal_prefere (texte), derniere_interaction (calculé, jamais saisi par le modèle). Les coordonnées (courriel, téléphone) ne sont pas des attributs libres : champs dédiés contact_json chiffrés au repos quand le chiffrement #172 est actif, sensitivity='private' dans tous les cas, exclus des exports par défaut et du compileur de contexte sauf conversation concernant explicitement la personne.

Transcriptions : l'audio est un fichier temporaire de data/ supprimé après transcription réussie (sauf réglage explicite « conserver les audios ») ; la transcription vit dans la note ou l'item d'inbox, jamais dans une base séparée.

5. Tickets de travail

Convention : chaque ticket est indépendamment testable ; « Fichiers » donne les points d'ancrage d'après la V2.1 — à confirmer contre le code réel au démarrage du ticket.

Personnes & engagements — #211

P4-T01 — Personnes : miroir complet et notes dédiées. Fichiers : backend/memory/mirror.py (extension), backend/tools/people.py. Travail : Personnes.md peuplé (par personne : relations connues, anniversaire, dernières interactions sourcées avec dates, engagements ouverts la concernant) ; création optionnelle d'une note dédiée par personne (dossier configurable, créée uniquement sur demande explicite ou validation de carte) ; outils people_list (READ), people_get (READ — coordonnées masquées par défaut, révélées seulement en conversation la concernant), people_note_add (WRITE — ligne datée dans la note dédiée). Acceptation : aucune coordonnée n'apparaît dans Personnes.md (miroir = relations et contexte, pas carnet d'adresses) ; un test le vérifie sur fixture contenant des coordonnées.

P4-T02 — Engagements : store, outils, API. Fichiers : backend/tools/people.py (suite), backend/routers/commitments.py ou extension du routeur approvals/today. Travail : table commitments (§4) ; outils commitment_list (READ — ouverts, échus d'abord), commitment_create (WRITE via carte), commitment_close (WRITE — done|dropped, motif libre), commitment_followup (READ — état et dernière relance) ; section « Engagements » d'Aujourd'hui (échus en tête) et de la revue du soir ; clôture en un clic depuis la carte, Aujourd'hui ou la conversation. Acceptation : un engagement échu non clos apparaît à la revue du soir le jour J, puis en insight (#201) à J+2 s'il est toujours ouvert — pas avant, pas en notification dédiée (budget).

P4-T03 — Détection en conversation et en consolidation. Travail : en conversation, les formulations d'engagement (« je vais envoyer X à Marie vendredi », « Karim doit me rendre Y ») produisent une carte de création pré-remplie (direction, personne résolue ou proposée, échéance uniquement si énoncée) ; en consolidation, les faits open_loop validés sont proposés en promotion vers commitments (une carte, pas une conversion automatique) ; résolution de personne ambiguë = carte de choix (règle de la phase 0). Acceptation : sur un corpus de 20 formulations de test, aucune création sans carte et aucune échéance inventée ; une promotion refusée ne se représente pas au run suivant (mémoire de rejet).

P4-T04 — Candidats connecteurs et relances. Travail : activation du réglage memoire: candidats par connecteur (défaut off, UI Sources connectées) : les engagements détectés dans les collections synchronisées choisies deviennent des candidats pending sourcés (lien vers l'objet) dans la file unifiée ; relance : à l'échéance + délai configurable, proposition de brouillon de relance (prompt de l'annexe B.3 du parent) via gmail.create_draft/outlook.create_draft quand le connecteur existe, sinon texte proposé dans la carte ; l'envoi suit le régime de la phase 3 (§11.4 du parent), sans exception. Acceptation : avec le réglage off, zéro candidat produit (test) ; avec on, un courriel fixture « je vous enverrai le devis jeudi » produit exactement un candidat sourcé ; la relance n'est jamais envoyée par la tranche.

Voix & réunions — #209

P4-T05 — Transcription : fournisseur et surfaces. Fichiers : backend/tools/voice.py (ou module backend/voice/), Configurations. Travail : réglage du fournisseur de transcription (choix explicite obligatoire avant le premier envoi audio ; choix proposés : API du provider LLM configuré disposant d'une offre voix, sinon aucun — pas de moteur ajouté au conteneur, P1) ; dictée navigateur branchée sur le champ de capture, le panneau et l'éditeur ; enregistrement et dépôt d'audio (PWA, chat, pièce jointe) → file de transcription (run visible) → texte ; suppression de l'audio après succès sauf réglage contraire ; durées et tailles plafonnées et affichées. Acceptation : sans fournisseur choisi, l'UI explique et ne transmet rien ; une transcription est un run journalisé avec son coût ; l'audio d'un test est absent de data/ après traitement (réglage par défaut).

P4-T06 — Notes vocales vers l'Inbox. Travail : un audio déposé devient un item kind='voice' : transcription, résumé en une ligne (cheap model), puis triage ordinaire de la phase 1 (les dates relatives se résolvent à l'horodatage de l'enregistrement) ; la carte de triage montre la transcription complète repliable, jamais le seul résumé. Acceptation : « rappelle-moi demain d'appeler le dentiste » en note vocale produit une proposition de tâche à la bonne date ; une note vocale ambiguë reste un item texte, pas une action devinée.

P4-T07 — Préparation de réunion. Fichiers : skill /reunion-prep, outil de préparation (agrégateur READ). Travail : à partir d'un événement (phase 3) ou d'une note de réunion : participants résolus en entités, historique (notes liées, derniers comptes rendus avec eux), engagements ouverts les concernant (T02), documents rassemblés (liens), points probables uniquement sourcés (ordres du jour passés, tâches ouvertes du projet) ; sortie = note de préparation dans le vault, générée en run, relue par Bruno avant la réunion. Acceptation : la préparation d'une réunion fixture ne contient aucune affirmation sans source ; un participant inconnu est signalé comme tel, pas « enrichi ».

P4-T08 — Compte rendu et extraction d'actions. Travail : transcription (dictée en direct dans la note, ou audio déposé) → compte rendu structuré selon la procédure par défaut (modifiable, mémoire procédurale phase 0) : résumé, décisions, actions ; extraction selon le prompt de l'annexe B.2 du parent : responsable = personne nommée dans le texte, échéance = énoncée, le reste part en a_clarifier ; propositions en file unifiée : tâches (créées dans la note projet ou la note de réunion), décisions → faits mémoire pending, suivis → brouillons ; écran de capture avec rappel de consentement, et aucune capture ne peut être déclenchée par une automatisation (politique). Acceptation : le scénario G4-bis (transcription fixture avec 3 actions dont 1 sans date et 1 sans responsable) produit 3 propositions exactes : 1 tâche datée complète, 1 sans échéance, 1 en a_clarifier — aucune invention.

Proactivité complète — #201

P4-T09 — Détecteurs. Fichiers : backend/automations/detectors.py (nouveau), tâche planifiée légère. Travail : les sept détecteurs du §2.1, déterministes sur les index (tâches, engagements, inbox, habitudes, notes) — seul le détecteur « note à faire vieillissante » utilise un balayage de contenu borné ; chaque détection produit un objet insight {détecteur, objet, preuve, proposition d'action} ; exécution nocturne (avec la consolidation, sans coût LLM sauf rédaction optionnelle) et à la demande (/insights). Acceptation : chaque détecteur a une fixture positive et une négative ; aucun détecteur n'émet deux fois pour le même objet et le même état (dédup par empreinte objet+état).

P4-T10 — Publication et consommation des insights. Travail : Insights.md en sections gérées (suppression d'un item = rejet pour cet objet, alimentant le compteur du détecteur) ; injection bornée au compileur de contexte (≤ 3, sourcés, seulement s'ils concernent le sujet de la conversation) ; actions proposées en un clic (créer la prochaine action du projet, clore ou relancer l'engagement, découper la tâche reportée) — toujours des cartes/runs ordinaires ; consommation du budget d'interruption : les insights ne notifient jamais directement, ils attendent le briefing ou Aujourd'hui (sévérité info par construction). Acceptation : une semaine de fixture produit des insights consultables sans produire une seule notification push d'insight.

P4-T11 — Boucle d'acceptation des détecteurs. Travail : compteurs par détecteur (émis, acceptés, rejetés, ignorés 3 fois) au centre de contrôle ; règles d'auto-ajustement : taux d'acceptation < 20 % sur 20 émissions → seuil du détecteur relevé automatiquement (journalisé) ; < 10 % ensuite → proposition de suspension en carte (jamais de suspension silencieuse) ; réactivation manuelle toujours possible. Acceptation : un détecteur fixture bruyant voit son seuil relevé après 20 émissions majoritairement rejetées, et l'événement est visible au centre de contrôle.

Finitions

P4-T12 — i18n, docs, guides, vie privée. Travail : clés FR/EN (personnes, engagements, réunions, insights) ; fiches docs/features/ pour #211, #209, #201 ; guide « Personnes, engagements et réunions » incluant la page des réglages de confidentialité (candidats connecteurs, fournisseur de transcription, conservation des audios) ; extension de l'export/effacement (parent §15.4) aux engagements et aux attributs personnes. Acceptation : l'effacement du domaine « personnes » supprime entités concernées, engagements et miroirs associés, avec trace d'audit ; DoD du §12 pour le reste.

6. API livrée par la phase

Route	Rôle	Ticket
`GET /api/people` · `GET /api/people/{id}`	Personnes (coordonnées masquées par défaut)	P4-T01
`GET/POST /api/commitments` · `POST /api/commitments/{id}/close`	Engagements et clôture	P4-T02
`POST /api/voice/transcribe`	Transcription d'un audio déposé (run)	P4-T05
`POST /api/meetings/prepare` · `POST /api/meetings/minutes`	Préparation et compte rendu	P4-T07/T08
`GET /api/insights` · `POST /api/insights/{id}/act	dismiss`	Insights et leurs actions

Outils @tool correspondants : people.*, commitment.* (parent §9.7/§13.2), exposés au MCP comme les autres — avec la règle que people_get via MCP ne renvoie jamais les coordonnées (masquage renforcé hors conversation directe).

7. Comportements détaillés

7.1 Sans la phase 3, la phase vit quand même

Pas de courriel candidat (la détection reste conversation + consolidation), préparation de réunion depuis les notes du vault, anniversaires et engagements pleinement fonctionnels. L'UI signale les capacités absentes comme des réglages à activer, pas comme des erreurs.

7.2 Un engagement, deux directions, un seul objet

je_dois et on_me_doit partagent le même cycle de vie ; la revue du soir présente les deux listes séparément (ce que je dois faire demain / ce que j'attends), et une relance n'existe que pour on_me_doit — pour je_dois, l'action proposée est une tâche.

7.3 La proactivité a un éditeur : Bruno

Le taux d'acceptation par détecteur est la métrique directrice de la phase (suivie par #212) : elle est affichée, et les ajustements automatiques de seuil sont des événements journalisés et réversibles. Un détecteur suspendu peut être réactivé ; un détecteur supprimé d'Insights.md objet par objet apprend ce qui ne sert pas.

8. Tests et golden tasks

Unitaires : détection d'engagements (corpus de formulations, aucune date inventée), masquage des coordonnées (miroir, export, MCP), dédup des insights, auto-ajustement des seuils.
Intégration : courriel candidat → engagement → échéance → brouillon de relance ; note vocale → tâche ; réunion complète prép → CR → tâches.
Golden tasks de la phase : G12 — « engagement pris par courriel (réglage candidats activé) suivi jusqu'au brouillon de relance, jamais envoyé seul » ; G13 — « compte rendu : 3 actions extraites sans invention (cf. P4-T08) » ; G14 — « une semaine d'insights : zéro notification d'insight, taux d'acceptation mesuré ». (Suite de G1–G11.)

9. Critères d'acceptation de la phase

Un engagement créé en conversation ou validé depuis un courriel est suivi jusqu'à sa clôture ou sa relance rédigée — sans création silencieuse à aucun maillon.
Aucune coordonnée de personne ne fuit : ni miroir, ni export par défaut, ni MCP, ni outil externe (tests dédiés verts).
Une note vocale et un compte rendu produisent des tâches exactes (responsables et dates uniquement quand ils sont énoncés).
Les insights sont utiles ou se taisent : publication sans notification directe, compteurs d'acceptation actifs, auto-ajustement prouvé sur fixture.
La phase fonctionne, dégradée mais complète, sans aucun connecteur.

10. Risques spécifiques et vigilance

Risque	Vigilance
Sentiment de surveillance des tiers (réunions, courriels)	Consentement affiché à la capture, candidats toujours validés, aucune donnée tierce conservée hors du fait validé ; les personnes peuvent être « gelées » (entité exclue de toute détection) par un réglage par personne
Détection d'engagements trop zélée (faux positifs en chaîne)	Cartes regroupées, mémoire de rejet par formulation, métrique d'acceptation du détecteur d'engagements suivie comme les autres
Coût de transcription sur de longues réunions	Plafonds de durée affichés avant traitement, coût journalisé par run, fournisseur choisi et révocable
Insights « bienveillants » mais inutiles qui érodent la confiance	La boucle d'acceptation (P4-T11) est un critère de phase, pas une amélioration future

11. Ordre d'exécution

P4-T01 → T02 → T03 → T04        (#211)
P4-T05 → T06 ; T07 → T08        (#209 — T07 peut démarrer après T01/T02)
P4-T09 → T10 → T11              (#201 — après T02 pour le détecteur d'engagements)
P4-T12                          (clôture)

12. Définition de « terminé »

DoD du document de phase 0 §12, inchangée, plus : les golden tasks G12–G14 vertes en CI ; les tests de non-fuite des coordonnées (§9, critère 2) font partie de la suite permanente, pas d'un audit ponctuel.

22 KiB Raw Blame History Unescape Escape

Assistant V2.1 ObsiGate — Phase 4 : Les gens (personnes & engagements, voix & réunions, proactivité complète)