Speak-Y Diffusion : alertes e-mail et webhook pour vos réunions

2026-10-09

L’onglet Diffusion d’un espace de travail d’équipe Speak-Y fait deux choses quand un enregistrement est partagé dans un canal : il envoie un e-mail aux adresses que vous avez indiquées, et il envoie une requête POST signée à l’URL de votre choix. Les deux portent le même petit jeu d’informations — qui a partagé, combien de temps dure l’enregistrement, quand, et de quel enregistrement il s’agit. Ni l’un ni l’autre ne porte le résumé ou la transcription.

Ce n’est pas une fonction manquante. Le contenu des canaux est chiffré de bout en bout : le serveur qui envoie l’e-mail et le webhook n’a jamais vu le texte. Ce guide montre comment configurer les deux, ce qui arrive exactement dans la boîte de réception et sur votre endpoint, comment vérifier l’en-tête X-Speaky-Signature, et quels canaux sont concernés. Tout ce qui suit a été vérifié dans l’app et sur le serveur le 9 octobre 2026.

À quoi sert l’onglet Diffusion ?

Il annonce les nouveaux enregistrements aux personnes et aux systèmes qui ne suivent pas le fil du canal. Un collègue partage une réunion dans un canal ; le serveur stocke l’enregistrement chiffré, puis prévient deux destinations, si elles sont configurées :

• Email delivery — jusqu’à 10 adresses reçoivent un court e-mail avec un bouton Ouvrir dans Speak-Y.
• Webhook — votre URL reçoit une requête POST en JSON, signée en HMAC SHA-256 dans l’en-tête X-Speaky-Signature.

Les réglages appartiennent à un espace de travail, pas à votre compte : chaque espace de travail a ses propres destinataires et son propre webhook. Seul le propriétaire de l’espace de travail ou un administrateur peut les modifier. Les membres voient l’onglet en lecture seule, avec la mention « Only an owner or admin can change integrations. » (seul un propriétaire ou un administrateur peut modifier les intégrations).

Comment le configurer ?

Il vous faut l’app macOS et le rôle de propriétaire ou d’administrateur dans l’espace de travail.

1. Ouvrez la page de l’espace de travail. Cliquez sur ⋯ à côté du nom de l’espace de travail dans la barre latérale et choisissez Edit workspace.
2. Allez dans l’onglet Diffusion. C’est le troisième onglet, après Overview et Members.
3. Lisez la carte Ce qui est envoyé. Elle liste les canaux de l’espace de travail : vous voyez le périmètre avant d’enregistrer quoi que ce soit.
4. Remplissez Webhook. Collez votre adresse dans Endpoint URL et saisissez un secret d’au moins 8 caractères dans Webhook secret (HMAC). Le bouton Save webhook reste inactif tant que le secret n’est pas assez long. Après l’enregistrement, l’état indique Saved, le titre reçoit un badge Configuré et le champ du secret est vidé : l’app n’affiche plus jamais le secret.
5. Remplissez Email delivery. Saisissez les adresses dans Recipients, séparées par des virgules, et appuyez sur Save email delivery.

Chaque bloc fonctionne sans l’autre. Pour modifier le webhook plus tard, saisissez de nouveau l’URL et un secret — le secret n’est pas prérempli, car le serveur ne le renvoie pas.

Qu’est-ce qui arrive exactement par e-mail ?

Un avis, pas un compte rendu. L’objet est « Nouvelle réunion dans Speak-Y » (ou « Nouvelle dictée dans Speak-Y » quand c’est une dictée qui a été partagée), et le corps comporte trois lignes et un bouton :

Sous le bouton, l’e-mail le dit sans détour : « Les enregistrements sont chiffrés de bout en bout : cette notification ne contient que des métadonnées. » Le nom du canal et celui de l’espace de travail ne figurent pas non plus dans l’e-mail — ils sont chiffrés eux aussi, le serveur ne les connaît donc pas.

Deux détails à connaître avant de promettre cet e-mail à l’équipe :

• La ligne de description dans l’app est en avance sur la réalité. Le bloc a pour sous-titre « Email a summary or the full transcript when a meeting ends. » (envoyer par e-mail un résumé ou la transcription complète à la fin d’une réunion). La partie exacte, c’est la note sous le champ des destinataires : « le résumé ne contient que des métadonnées » — ce « résumé » désigne la notification elle-même. Il n’existe aucun réglage pour choisir entre un résumé et une transcription complète.
• Les destinataires n’ont pas besoin de compte Speak-Y pour recevoir l’e-mail, mais le bouton ne sert qu’aux membres du canal. Les destinataires qui ont un compte reçoivent l’e-mail dans la langue de leur interface.

Qu’envoie le webhook ?

Une requête POST par nouvel enregistrement, avec Content-Type: application/json, l’en-tête X-Speaky-Event: team_record.created et ce corps :

{
  "event": "team_record.created",
  "workspace_id": "5b0e7c1e-2f4d-4a57-9d0a-6f1b2c3d4e5f",
  "channel_id": "c1a2b3c4-d5e6-47f8-9a0b-1c2d3e4f5a6b",
  "record_id": "8F2C1D7A-3B4E-4C5D-9E6F-0A1B2C3D4E5F",
  "created_by": "0d9c8b7a-6e5f-4d3c-2b1a-0f9e8d7c6b5a",
  "meta": { "duration_s": 2520, "kind": "meeting" },
  "server_created_at": "2026-10-09T14:05:12+00:00",
  "protocol_version": 2,
  "sent_at": "2026-10-09T14:05:12.480113+00:00"
}

meta.kind vaut meeting ou dictation, et meta.duration_s est la durée en secondes. Tout le reste est un identifiant ou un horodatage. Il n’y a ni titre, ni liste d’intervenants, ni résumé, ni nom de canal : votre endpoint apprend que quelque chose s’est produit et où, pas ce qui a été dit.

Cela suffit pour les usages courants — une ligne dans la messagerie de l’équipe, une ligne dans un outil de suivi, un compteur de réunions par canal. Tenez votre propre table de correspondance entre channel_id et un nom lisible. Notez que le webhook entrant d’une messagerie ne peut pas recevoir cette requête telle quelle : les webhooks entrants de Slack, par exemple, attendent un corps JSON avec un champ text, il vous faut donc un petit relais qui vérifie la signature et reformate le message.

Comment vérifier la signature ?

L’en-tête X-Speaky-Signature a la forme sha256=<hex>. La valeur est le HMAC SHA-256 du corps brut de la requête, avec pour clé le secret que vous avez saisi dans l’onglet Diffusion. Un récepteur en Python :

import hashlib
import hmac

def is_from_speaky(secret: str, raw_body: bytes, header: str) -> bool:
    digest = hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(f"sha256={digest}", header)

Signez les octets exactement tels qu’ils sont arrivés. Si votre framework analyse le JSON et que vous le sérialisez de nouveau, l’ordre des clés et les espaces changent, et la signature ne correspondra plus.

Quelques propriétés de l’émetteur déterminent la façon d’écrire le récepteur :

• Une seule tentative. Un envoi qui échoue ou qui expire n’est pas retenté. Le délai d’expiration est de 10 secondes : accusez donc réception de la requête d’abord, et faites le travail lent ensuite. Traitez le webhook comme un signal, pas comme une file d’attente : n’y adossez ni facturation ni piste d’audit.
• Pas de protection contre le rejeu dans la signature. La signature ne couvre que le corps. Servez-vous de record_id pour ignorer une requête déjà traitée, et de sent_at pour écarter celles qui sont périmées.
• Le renouvellement du secret vous appartient. Enregistrez de nouveau le webhook avec un nouveau secret et mettez à jour le récepteur.

Quels canaux sont concernés ?

Tout l’espace de travail, à une exception près. La carte de périmètre indique « Chaque nouvel enregistrement dans n'importe quel canal de cet espace déclenche un envoi », et il n’y a pas de filtre par canal. Dans un espace de travail où les canaux clients sont actifs, le point hebdo ne sera pas la seule chose annoncée.

L’exception, ce sont les canaux privés : un enregistrement partagé dans un canal privé n’est annoncé nulle part — ni e-mail, ni webhook. La carte liste les canaux que vous pouvez voir, y compris les canaux privés, marqués d’un cadenas, mais le serveur les ignore. La raison : la diffusion est configurée par un propriétaire ou un administrateur qui n’est pas forcément membre de ce canal privé ; même le fait que quelque chose y a été enregistré ne lui est pas destiné. La répartition des canaux entre publics et privés est expliquée dans qui voit quoi dans les canaux d’équipe.

Les enregistrements personnels restent en dehors de tout cela. Rien ne quitte votre bibliothèque tant que vous ne partagez pas vous-même un enregistrement dans un canal.

Pourquoi pas le résumé lui-même ?

Parce que le serveur devrait le lire. Dans Speak-Y, l’enregistrement est chiffré sur le Mac avec une clé de canal avant d’être envoyé, et les clés de canal n’existent que sur les appareils des membres — comment fonctionne le partage en équipe chiffré de bout en bout en détaille le mécanisme. Un serveur capable de mettre le résumé dans un e-mail serait un serveur capable de lire tous les canaux.

Les outils conçus dans l’autre sens envoient bel et bien du contenu, et c’est une raison légitime de les choisir quand un résumé dans la boîte de réception compte plus que le chiffrement de bout en bout. Vérifié le 9 octobre 2026 :

• Otter. Quand une réunion enregistrée est liée à un événement d’un calendrier synchronisé et que le partage automatique est activé, le propriétaire et les invités de l’événement reçoivent un e-mail Meeting Summary après la réunion.
• Fathom. Son webhook peut inclure le résumé, la transcription et les actions à suivre dans la charge utile ; c’est l’émetteur qui choisit.
• Fireflies. Ses webhooks suivent le même schéma que Speak-Y, prévenir puis aller chercher — l’événement meeting.transcribed porte un identifiant de réunion, signé en HMAC SHA-256 —, mais le contenu est ensuite récupéré via l’API de Fireflies, car le fournisseur le stocke sous forme lisible.

Si vous avez besoin d’une copie lisible hors de l’app, faites-la délibérément plutôt que par notification : des notes de réunion hebdomadaire que personne n’a à rédiger montre l’export vers Confluence ou Google Drive, et le serveur MCP de Speak-Y permet à un assistant IA sur le Mac d’un membre de lire les enregistrements que ce membre peut déjà ouvrir.

Les espaces de travail d’équipe sont disponibles dans l’app Speak-Y pour macOS : en créer un demande au minimum la formule Pro, et les collègues le rejoignent gratuitement avec n’importe quelle formule. La page Speak-Y Teams montre comment fonctionnent les canaux partagés.

FAQ

Speak-Y envoie-t-il le résumé ou la transcription par e-mail après une réunion ?

Non. La diffusion par e-mail envoie un avis indiquant qu’une nouvelle réunion a été partagée dans un canal : l’auteur, la durée, l’heure et un bouton Ouvrir dans Speak-Y. Les canaux sont chiffrés de bout en bout, le serveur n’a donc ni résumé ni transcription à mettre dans un e-mail. Le texte se lit dans l’app.

Qu’envoie le webhook de Speak-Y ?

Une requête POST en JSON avec l’événement team_record.created et uniquement des identifiants : workspace_id, channel_id, record_id, created_by, le type d’enregistrement et sa durée dans meta, et deux horodatages. Elle ne contient ni transcription, ni résumé, ni nom de canal ou d’espace de travail.

Comment vérifier l’en-tête X-Speaky-Signature ?

Calculez le HMAC SHA-256 du corps brut de la requête avec le secret de votre webhook, encodez-le en hexadécimal et préfixez-le par sha256=. Comparez le résultat à l’en-tête X-Speaky-Signature avec une comparaison en temps constant, et faites-le avant d’analyser le JSON.

Quels canaux déclenchent un envoi ?

Chaque nouvel enregistrement partagé dans n’importe quel canal public de l’espace de travail. Il n’y a pas de filtre par canal. Les canaux privés ne sont jamais annoncés, ni par e-mail ni par webhook, et les enregistrements personnels ne quittent jamais votre bibliothèque.

Qui peut configurer la diffusion par e-mail et le webhook ?

Le propriétaire de l’espace de travail ou un administrateur, dans l’onglet Diffusion de la page de l’espace de travail, dans l’app macOS. Les membres voient le même onglet en lecture seule.