Webhooks : tout ce qui parle HTTP devient une note

Denis Povarov18 septembre 2026

Chaque espace de travail avait déjà trois portes d’entrée : l’appli, la CLI et un assistant IA via MCP. Les trois supposent qu’une personne ou un assistant écrit. Or beaucoup de choses qui méritent d’être gardées ne sont écrites ni par l’un ni par l’autre : un déploiement qui a échoué, un commentaire Figma, le versement de la semaine, un formulaire rempli par quelqu’un.

Notez v0.15.0 ajoute la quatrième : une URL de webhook. Tout ce qui sait envoyer une requête HTTP peut désormais déposer une note.

Des notes créées par un webhook dans la liste des notes de Notez, chacune marquée du badge de source WH

Une URL, une ligne de curl

Créez un webhook dans Paramètres → Intégrations → Webhooks, et Notez vous donne une URL. C’est toute la configuration :

curl -X POST "https://api.notez.dev/api/webhooks/notes/<your-token>" \
  -H "Content-Type: application/json" \
  -d '{"title": "Deploy failed on main", "content": "## Details\n- commit abc123", "tags": ["alerts"]}'

La note apparaît avec ses étiquettes, dans la note choisie comme destination, dans la colonne de tableau sélectionnée. Les étiquettes que vous n’avez encore jamais utilisées sont créées sur le moment.

La fenêtre Nouveau webhook avec le nom, le format des données, la note de destination, les étiquettes par défaut, la colonne du tableau et la vérification de signature

Les expéditeurs qui n’apprendront pas votre format

Un format JSON bien propre fonctionne quand vous contrôlez l’expéditeur. GitHub, Stripe et Sentry se moquent du format que vous aimeriez : ils envoient leurs propres données, et la seule chose que vous choisissez, c’est l’URL.

Un webhook a donc deux modes. Format Notez valide strictement, rejette les fautes de frappe et vous donne titre, contenu, étiquettes et pièces jointes. JSON quelconque prend tout ce qui arrive et l’enregistre dans un bloc de code mis en forme, avec pour titre le champ title des données s’il existe, sinon le nom du webhook. Rien n’est rejeté pour des champs inattendus, et c’est tout l’intérêt.

Les pièces jointes, y compris celles dont vous n’avez que le lien

Une requête peut transporter jusqu’à dix fichiers, de trois façons : en envoi de fichier, en base64 dans le JSON, ou sous forme de lien que Notez télécharge pour vous. La troisième est celle qui rend les outils d’automatisation utilisables : Zapier vous donne un lien vers un fichier, jamais les octets.

Télécharger tout ce vers quoi pointe une URL est aussi le moyen le plus rapide d’ouvrir une brèche dans sa propre infrastructure. Une URL de webhook est publique : sans protection, « télécharge ce lien » permettrait à n’importe qui de diriger mes serveurs vers des adresses internes et de lire ce qui répond. Chaque téléchargement résout d’abord l’adresse, refuse les plages privées, internes et de métadonnées cloud, revérifie après chaque redirection et ne se connecte qu’à l’adresse déjà vérifiée, si bien qu’une deuxième réponse DNS ne peut pas glisser une adresse interne après la vérification. Les fichiers trop lents, trop gros ou protégés par une connexion deviennent des liens dans la note au lieu de disparaître.

Les relances, et la note que vous ne vouliez pas en double

Les expéditeurs relancent quand une réponse tarde, et une relance qui crée une deuxième note est pire que pas de note du tout. Envoyez un en-tête Idempotency-Key, ou un externalId dans le corps, et une répétition dans les 24 heures renvoie la note qui existe déjà. L’identifiant de livraison de GitHub est repris automatiquement : ses relances ne créent pas de doublon, sans rien configurer.

Les signatures : facultatives, et c’est voulu

L’URL fait office d’identifiant, et les URL fuient : dans les journaux, les captures d’écran, les configurations partagées. Si l’expéditeur sait signer ses requêtes, Notez peut vérifier la signature et refuser tout le reste.

J’ai rendu cette vérification facultative, et cela mérite une explication. La vérification n’est pas un verrou entre mes mains : elle porte sur une chose que l’expéditeur doit faire. GitHub signe. Stripe signe. Zapier, Raccourcis et la plupart des scripts ne savent pas le faire. Exiger des signatures aurait transformé une fonctionnalité qui marche avec tout en une fonctionnalité qui marche avec trois services. L’URL reste donc la base, et la signature est une deuxième couche pour les expéditeurs qui la prennent en charge. La liste signale les webhooks non signés, pour que le compromis reste visible au lieu d’être oublié.

Deux webhooks dans un espace de travail Notez, l’un non signé avec un avertissement, l’autre avec le badge Signé

Un secret de signature est le rare identifiant que je dois pouvoir relire : vérifier une signature, c’est la recalculer, donc le secret est chiffré plutôt que haché. Cette distinction compte plus qu’il n’y paraît, et elle a changé autre chose dans cette version.

Au passage : les clés sont désormais hachées

Les URL de webhook sont stockées sous forme de hachage, parce que reconnaître un jeton n’exige jamais de le reproduire. Les clés MCP et CLI, conçues plus tôt, étaient stockées en clair, lisibles par quiconque pouvait lire la base de données.

Elles sont désormais hachées, elles aussi. Effet pratique : une clé MCP s’affiche une seule fois, au moment où vous la générez, puis l’écran n’en montre que les premiers caractères. Vous l’avez perdue ? Renouvelez-la. La CLI, elle, n’a jamais affiché sa clé.

Deux changements plus petits sont sortis du même travail. Chaque webhook crée des notes au nom de la personne qui l’a créé : retirer quelqu’un d’un espace de travail supprime donc désormais ses webhooks avec lui, et aucune URL ne survit à son propriétaire. Et le journal d’audit, qui enregistre les données de chaque modification, masque maintenant tout ce qui ressemble à un identifiant : il s’apprêtait à stocker des secrets de signature en clair, juste à côté de leurs copies chiffrées.

Quoi y brancher

GitHub — tickets, déploiements, workflows en échec, avec la vérification de signature activée.
Zapier ou Make — une étape à la fin de n’importe quelle automatisation, qui range le résultat là où vous le retrouverez.
Cron et CI — rapports de sauvegarde nocturnes, notes de version, un résumé qui dormirait sinon dans un journal que personne n’ouvre.
Votre propre appli — demandes de support, inscriptions, tout ce qui mérite d’être gardé à côté de vos notes.

Les notes venues d’un webhook portent un badge WH, pour que vos propres écrits ne se perdent jamais parmi elles.

Tous les détails, les limites et le pas-à-pas pour GitHub sont dans l’article d’aide sur les webhooks.