Connecteurs Manifst

Reliez Manifst à vos outils de développement pour synchroniser automatiquement vos tickets avec votre activité Git et recevoir des notifications dans Slack.

Vue d'ensemble

Les connecteurs sont configurés par projet depuis Paramètres → Intégrations. Seuls les owners du projet peuvent créer ou modifier des connecteurs.

Qui a accès

Un abonnement ouvre des capacités au compte, jamais au projet. Être invité sur le projet d'un abonné payant n'ouvre donc aucun droit sur ses connecteurs : chaque membre est évalué sur son propre plan.

En revanche, le travail de ce membre continue d'alimenter les connecteurs : ses commits sont rattachés aux tickets, ses modifications partent dans Jira, ses actions déclenchent les notifications. Le titulaire de l'abonnement a payé pour une vue complète de la livraison de son projet : la contribution d'un coéquipier n'en est pas retirée, elle lui reste simplement invisible.

GitHub

Configuration

1. Dans Manifst, ouvrez Paramètres → Intégrations → GitHub → Configurer.
2. Copiez la clé secrète affichée (visible une seule fois).
3. Dans GitHub, ouvrez votre dépôt → Settings → Webhooks → Add webhook.
4. Payload URL : l'URL affichée dans Manifst après enregistrement
5. Content type : application/json obligatoire
6. Secret : la clé secrète copiée à l'étape 2
7. Events : Pushes + Pull requests
8. Cliquez Add webhook. GitHub envoie un événement ping : Manifst répond {"ok":true}.
9. Content type : application/json

Push : Lier un commit à une ticket

Incluez une référence #<PRÉFIXE>-<id> dans le message de commit pour lier automatiquement le commit à l'élément correspondant.

#<PRÉFIXE>-<id numérique>

Le préfixe est celui affiché devant l'élément dans Manifst. Tous les types de tickets du projet sont reconnus : pas seulement US : ainsi que les deux niveaux de la roadmap :

git commit -m "fix: correction du formulaire de connexion #US-42"

git commit -m "feat: ajout pagination #US-17 #US-18"

git commit -m "fix: crash au démarrage #BG-7"

Plusieurs références dans le même commit sont supportées.

Nom de branche

Le nom de la branche est également analysé, sans croisillon : nul besoin de discipline sur les messages de commit si la convention de nommage porte déjà la référence.

git checkout -b feature/US-42-formulaire-connexion
git checkout -b hotfix/BG-7

La branche apparaît alors dans le bloc Développement de la fiche, aux côtés des commits et des pull requests.

Pull Requests

Mentionnez un ou plusieurs éléments dans le titre ou la description de la PR, avec la même syntaxe que pour les commits. La branche source de la PR est analysée en plus : une PR issue de feature/US-42-… est rattachée même sans mention explicite.

Les verbes de fermeture de GitHub (fix, fixes, close, closes, resolve, resolves…) placés devant une référence sont reconnus et enregistrés comme intention de fermeture.

## Changements
Implémentation du formulaire de profil utilisateur.

Closes #US-15 #US-23

Le statut du lien dans Manifst est mis à jour à chaque changement d'état de la PR :

Auto-close des stories sur merge

Quand une PR est mergée, Manifst peut automatiquement déplacer les tickets liées vers une colonne "Done".

Pour activer cette fonctionnalité :

1. Dans Paramètres → Intégrations → GitHub, activez Fermer automatiquement les stories à la merge.
2. Sélectionnez la colonne de destination dans la liste déroulante (colonnes de type "done" de votre Kanban).
3. Enregistrez. Toute PR mergée référençant un ticket déplacera les tickets concernés, quel que soit leur préfixe.

Une seule fois, au moment du merge

La fermeture se déclenche sur l'événement qui acte le merge, pas sur l'état « mergée ». Concrètement, si vous rouvrez un ticket à la main après coup, corriger ensuite le titre ou la description de la PR ne le refermera pas. Une décision humaine n'est jamais écrasée par une modification de texte sur GitHub.

Un ticket fermé automatiquement porte la mention « fermé automatiquement » sous le lien correspondant, dans le bloc Développement de sa fiche.

GitLab

Configuration

1. Dans Manifst, ouvrez Paramètres → Intégrations → GitLab → Configurer.
2. Copiez le jeton affiché (visible une seule fois).
3. Dans GitLab, ouvrez votre projet → Settings → Webhooks → Add new webhook.
4. URL : celle affichée dans Manifst après enregistrement.
5. Secret token : le jeton copié à l'étape 2.
6. Trigger : Push events + Merge request events.
7. Laissez Enable SSL verification coché, puis Add webhook.

Références

La syntaxe est identique à GitHub : #<PRÉFIXE>-<id> dans un message de commit, le nom de la branche analysé sans croisillon, et les verbes de fermeture reconnus. Reportez-vous à la section GitHub pour le détail : le moteur d'analyse est le même code.

Dépôts privés et instances auto-hébergées

Le connecteur est entrant : c'est GitLab qui appelle Manifst. Un dépôt privé fonctionne donc exactement comme un dépôt public : aucun jeton d'accès au dépôt n'est nécessaire, Manifst ne lit jamais votre code.

Une instance auto-hébergée fonctionne également, à une condition : qu'elle puisse joindre l'URL publique de Manifst. Une instance derrière un pare-feu d'entreprise peut émettre vers l'extérieur même si l'inverse est impossible : c'est le sens de circulation qui compte.

Seule nuance sur les liens : ceux enregistrés pointent vers votre dépôt. Sur un dépôt privé, un membre Manifst sans accès GitLab tombera sur une page de connexion. C'est le comportement attendu : les permissions du dépôt appartiennent à GitLab.

Azure DevOps

Mêmes rattachements que GitHub et GitLab, appliqués aux Service Hooks d'Azure Repos. Le moteur d'analyse est le même code : la syntaxe des références ne change pas d'une plateforme à l'autre.

Configuration

Azure DevOps ne pose pas un webhook couvrant plusieurs événements : il crée une souscription par événement. Il faut donc répéter l'opération, vers la même URL, pour chaque type d'événement à suivre.

1. Dans Manifst, ouvrez Paramètres → Intégrations → Connecteur Git → Configurer, choisissez Azure DevOps, renseignez l'URL du dépôt et enregistrez.
2. Copiez le jeton et l'URL du webhook affichés (le jeton n'est visible qu'une fois).
3. Dans Azure DevOps, ouvrez Project settings → Service hooks, puis Create subscription.
4. Service : Web Hooks. Trigger : Code pushed.
5. Sur l'écran Action : collez l'URL Manifst dans URL, et dans HTTP headers saisissez la ligne :
   X-Manifst-Token: <votre jeton>
6. Laissez Resource details to send sur All.
7. Test, puis Finish.
8. Répétez les étapes 3 à 7 pour Pull request created, Pull request updated et Pull request merge attempted.

Références

La syntaxe est identique à GitHub : #<PRÉFIXE>-<id> dans un message de commit ou dans la description d'une pull request, le nom de la branche analysé sans croisillon, et les verbes de fermeture reconnus. Reportez-vous à la section GitHub pour le détail.

Dépôts privés et Azure DevOps Server

Le connecteur est entrant : c'est Azure qui appelle Manifst. Un dépôt privé fonctionne donc exactement comme un dépôt public : aucun jeton d'accès au dépôt n'est nécessaire, Manifst ne lit jamais votre code.

Une instance Azure DevOps Server (auto-hébergée) fonctionne également, à condition qu'elle puisse joindre l'URL publique de Manifst. C'est le sens de circulation qui compte : une instance derrière un pare-feu d'entreprise peut émettre vers l'extérieur même si l'inverse est impossible.

Bitbucket

Configuration

1. Dans Manifst, ouvrez Paramètres → Intégrations → Connecteur Git → Configurer, choisissez Bitbucket, renseignez l'URL du dépôt et enregistrez.
2. Copiez le secret et l'URL du webhook affichés (le secret n'est visible qu'une fois).
3. Dans Bitbucket, ouvrez votre dépôt → Repository settings → Webhooks → Add webhook.
4. Title : « Manifst ». URL : collez l'URL Manifst.
5. Secret : collez le secret Manifst. Ce champ est facultatif chez Bitbucket, mais obligatoire pour Manifst : voir l'avertissement ci-dessous.
6. Triggers : cochez Repository → Push, puis, sous Pull request, les cases Created, Updated, Merged et Declined.
7. Laissez Status sur Active, puis Save.

Références

La syntaxe est identique à GitHub : #<PRÉFIXE>-<id> dans un message de commit ou dans la description d'une pull request, le nom de la branche analysé sans croisillon, et les verbes de fermeture reconnus. Reportez-vous à la section GitHub pour le détail.

Dépôts privés

Le connecteur est entrant : c'est Bitbucket qui appelle Manifst. Un dépôt privé fonctionne donc exactement comme un dépôt public : aucun jeton d'accès au dépôt n'est nécessaire, Manifst ne lit jamais votre code.

Seule nuance sur les liens : ceux enregistrés pointent vers votre dépôt. Sur un dépôt privé, un membre Manifst sans accès Bitbucket tombera sur une page de connexion. C'est le comportement attendu : les permissions du dépôt appartiennent à Bitbucket.

Jira

Synchronisez automatiquement votre backlog Jira Cloud avec Manifst (Tickets, Epics, Super Epics et Story Points).

Configuration

1. Dans Manifst, ouvrez Paramètres → Intégrations → Connecteur backlog → Configurer, puis choisissez Jira.
2. Connexion : renseignez l'URL de votre site Jira (ex. https://votre-site.atlassian.net), votre email Atlassian et votre API token, puis cliquez Tester.
3. Projet : indiquez la clé projet (ex. PROJ).
4. Correspondances : vérifiez les types Jira retenus pour les Epics et les Super Epics, et le champ Story Points.
5. Filtre : ajustez le JQL et la fréquence de synchro automatique.
6. Synchro : Manifst lit votre backlog, affiche ce qui va changer, et n'écrit qu'une fois que vous avez cliqué Sauvegarder dans Manifst.

Dépendances entre tickets

Manifst n'importe que les liens Jira de type Blocks (« bloque » / « est bloqué par ») : ce sont les seuls qui disent quel ticket passe en premier. Un lien Relates, Duplicate ou Cloners n'a pas de sens d'ordonnancement et est ignoré.

Azure Boards

Synchronisez un projet Azure Boards avec Manifst, dans les deux sens : work items, hiérarchie, itérations, commentaires, pièces jointes et dépendances.

Configuration

1. Dans Azure DevOps, créez un jeton d'accès personnel : User settings → Personal access tokens → New Token, avec la portée Work Items : Read, write & manage.
2. Dans Manifst, ouvrez Paramètres → Intégrations → Connecteur backlog → Configurer, puis choisissez Azure Boards.
3. Connexion : renseignez l'URL de votre organisation (https://dev.azure.com/mon-organisation) et le jeton, puis cliquez Tester.
4. Projet : choisissez le projet et l'équipe.
5. Correspondances : Manifst détecte le modèle de process (Agile, Scrum, CMMI ou Basic) et en déduit les quatre types de work items. Vous pouvez les forcer si votre process est personnalisé.
6. Filtre : ajustez la requête WIQL et la fréquence de synchro automatique.
7. Synchro : Manifst lit le backlog, affiche ce qui va changer, et n'écrit qu'une fois que vous avez cliqué Sauvegarder dans Manifst. La synchro automatique repasse ensuite toutes les 10 minutes par défaut.

Correspondances

Ces types sont modifiables dans les options avancées de la modale si votre process est personnalisé.

Limites

• Azure DevOps Services uniquement (le cloud). Azure DevOps Server auto-hébergé n'est pas pris en charge.
• Le process Basic n'a que trois niveaux (Epic → Issue → Task) : les Super Epics Manifst n'y sont pas remontés.
• La suppression d'un ticket Manifst envoie le work item à la corbeille d'Azure, jamais en destruction définitive : il reste récupérable côté Azure.
• La purge des éléments supprimés côté Azure n'a lieu que lors d'une synchro manuelle : la synchro automatique est incrémentale et ne voit pas ce qui a disparu.

Linear

Synchronisez une équipe Linear avec Manifst, dans les deux sens : Initiatives, Projects, Issues, sous-issues, Cycles, commentaires, labels/tags, estimations et dépendances.

Configuration

1. Dans Linear, ouvrez Settings → Account → API (ou Workspace → API) et créez une Clé API personnelle (Personal API Key).
2. Dans Manifst, ouvrez Paramètres → Intégrations → Connecteur backlog → Configurer, puis choisissez Linear.
3. Connexion : collez votre Clé API Linear et cliquez Tester. Manifst vérifie la clé et liste les équipes accessibles de votre organisation.
4. Équipe & Préfixe : sélectionnez l'Équipe Linear à synchroniser. Vous pouvez spécifier un préfixe pour les types de tickets (par défaut Type /, ex: les labels Type / Bug deviendront le type Bug dans Manifst).
5. Fréquence : ajustez l'intervalle de synchro automatique en arrière-plan (de 5 à 1440 minutes, 10 min par défaut).
6. Synchro : Manifst lit le backlog Linear, calcule et affiche le diff (créations, mises à jour), puis n'écrit les données dans Manifst que lorsque vous cliquez sur Sauvegarder dans Manifst.

Correspondances

Dépendances entre tickets

Linear gère plusieurs types de relations entre tickets (blocks, duplicate, related). Manifst filtre et synchronise exclusivement les relations de type blocks (« bloque » / « est bloqué par »), car ce sont les seules qui imposent un ordre d'exécution strict.

Limites & Bonnes pratiques

• Périmètre par Équipe (Team) : Un connecteur Linear donné est lié à une seule équipe au sein du workspace Linear. Pour synchroniser plusieurs équipes, activez le connecteur sur les projets Manifst correspondants.
• Adresses email identiques : L'assignation automatique des tickets et l'attribution des commentaires requièrent que les membres utilisent la même adresse email sur Linear et Manifst.
• Conversion Markdown ↔ HTML : Les descriptions et commentaires rédigés en HTML dans Manifst sont convertis en Markdown pour Linear, et vice-versa.

Slack

Configuration

1. Dans Slack, créez une Incoming Webhook sur api.slack.com/apps → votre app → Incoming Webhooks → Add New Webhook to Workspace. Sélectionnez le canal cible.
2. Copiez l'URL générée (format https://hooks.slack.com/services/T…/B…/…).
3. Dans Manifst, ouvrez Paramètres → Intégrations → Slack → Configurer.
4. Collez l'URL dans le champ Webhook URL.
5. Cochez les événements souhaités.
6. Cliquez Tester la connexion pour vérifier que le message arrive bien dans Slack, puis Enregistrer.

Événements disponibles

Format des messages

Les messages utilisent le format mrkdwn de Slack. Voici des exemples pour chaque événement :

🔄 *Statut modifié* : *Modifier le profil utilisateur*
Backlog → En cours

👤 *Story assignée* : *Ajouter la pagination*
Assignée à *Marie Dupont*

💬 *Nouveau commentaire* sur *Modifier le profil utilisateur*
Par *Jean Martin* : Le formulaire doit aussi gérer la photo de profil…

🚀 *Sprint démarré* : *Sprint 3 : Auth & Profil*

✅ *Sprint terminé* : *Sprint 3 : Auth & Profil*

Discord

Configuration

1. Dans Discord, ouvrez le canal cible → Paramètres du canal → Intégrations → Webhooks → Nouveau Webhook.
2. Donnez un nom au webhook (ex. Manifst), choisissez le canal, puis cliquez Copier l'URL du Webhook.
   L'URL a la forme https://discord.com/api/webhooks/<id>/<token>.
3. Dans Manifst, ouvrez Paramètres → Intégrations → Discord → Configurer.
4. Collez l'URL dans le champ Webhook URL.
5. Cochez les événements souhaités.
6. Cliquez Tester pour vérifier qu'un message de test arrive dans le canal, puis Enregistrer.

Événements disponibles

Les événements sont identiques à ceux du connecteur Slack : un même événement peut déclencher les deux connecteurs simultanément si les deux sont actifs.

Format des embeds

Les messages Discord utilisent des embeds avec une couleur latérale par type d'événement. Le texte supporte le Markdown Discord (**gras**, *italique*, `code`).

Exemple de payload envoyé à Discord :

{
  "embeds": [{
    "description": "🔄 **Story mise à jour** : **Modifier le profil utilisateur**\nStatut : `Backlog` → `En cours`",
    "color": 5793266
  }]
}

Google Meet

Transformez les enregistrements et transcripts de vos réunions Google Meet en Epics, User Stories et sous-tâches grâce à l'IA Manifst.

Configuration

1. Dans Manifst, ouvrez Paramètres → Intégrations → Google Meet → Connecter.
2. Autorisez Manifst à accéder à vos comptes-rendus et enregistrements de réunions Google Workspace via OAuth.
3. Une fois le compte relié, cliquez sur Réunions pour afficher les réunions disposant d'un transcript.
4. Sélectionnez la réunion souhaitée puis cliquez Générer le backlog : l'IA Manifst structure vos éléments.

Power BI / API REST

Ce connecteur ne se configure pas dans Manifst : il s'agit de la consommation de l'API v1 depuis Power BI. La liste complète des endpoints est dans la Documentation API.

Clé & prérequis

• Un compte au plan Portefeuille (l'API REST y est incluse).
• Une clé API générée depuis Paramètres → Clés API, avec au minimum les scopes finance:read (indicateurs EVM & portefeuille) et roadmap:read (dépendances & jalons). Ajoutez tickets:read, time:read, team:read selon les données à remonter.
• L'URL de base de l'API : https://manifst.net/api/v1

Avant Power BI, validez la clé avec un simple appel (PowerShell) : si vous recevez du JSON {"data":[…]}, tout est prêt :

curl.exe -H "Authorization: Bearer mfst_live_VOTRE_CLE" https://manifst.net/api/v1/projects

Connexion depuis Power BI Desktop

L'API s'authentifie via un en-tête Authorization: Bearer. Le plus robuste est de le déclarer dans une requête M avec Web.Contents (compatible rafraîchissement planifié). Ouvrez Accueil → Transformer les données → Nouvelle source → Requête vide → Éditeur avancé et collez :

let
    BaseUrl = "https://manifst.net/api/v1",
    ApiKey  = "mfst_live_VOTRE_CLE",
    Source  = Json.Document(
        Web.Contents(BaseUrl, [
            RelativePath = "finance",
            Query   = [ project = "UUID_DU_PROJET" ],
            Headers = [ Authorization = "Bearer " & ApiKey ]
        ])
    )
in
    Source[data]

À l'invite d'authentification de Power BI, choisissez Anonyme : les identifiants sont déjà transmis via l'en-tête. L'UUID du projet se récupère via l'endpoint /projects.

Consolidation portefeuille (multi-projets)

L'endpoint /portfolio/finance agrège l'EVM de tous les projets accessibles à la clé en une seule requête : idéal pour une vue programme. Il renvoie un bloc totals consolidé et le détail par projet.

let
    BaseUrl = "https://manifst.net/api/v1",
    ApiKey  = "mfst_live_VOTRE_CLE",
    Source  = Json.Document(
        Web.Contents(BaseUrl, [
            RelativePath = "portfolio/finance",
            Headers = [ Authorization = "Bearer " & ApiKey ]
        ])
    ),
    Projets = Table.FromRecords(Source[data][projects])
in
    Projets

Le bloc consolidé se lit via Source[data][totals] (Σ BAC, CPI/SPI portefeuille, VAC…). Pour cibler une équipe précise, ajoutez Query = [ projects = "uuid1,uuid2" ].

Rafraîchissement incrémental & pagination

Les listes volumineuses /tickets et /time-entries acceptent une pagination et un filtre de fraîcheur, à passer dans Query :

            RelativePath = "tickets",
            Query = [ project = "UUID_DU_PROJET", updated_since = "2026-07-01", per_page = "500", page = "1" ],
            Headers = [ Authorization = "Bearer " & ApiKey ]

let
    BaseUrl = "https://manifst.net/api/v1",
    ApiKey  = "mfst_live_VOTRE_CLE",
    ParPage = 500,
    Page = (n as number) as record =>
        Json.Document(
            Web.Contents(BaseUrl, [
                RelativePath = "tickets",
                Query = [
                    project  = "UUID_DU_PROJET",
                    page     = Text.From(n),
                    per_page = Text.From(ParPage)
                ],
                Headers = [ Authorization = "Bearer " & ApiKey ]
            ])
        ),
    Pages = List.Generate(
        () => [ n = 1, r = Page(1) ],
        each List.Count([r][data]) > 0,
        each [ n = [n] + 1, r = Page([n] + 1) ],
        each [r][data]
    ),
    Tickets = Table.FromRecords(List.Combine(Pages)),
    // tags est une liste d'enregistrements : à développer ou à retirer
    Propre  = Table.RemoveColumns(Tickets, {"tags"}, MissingField.Ignore)
in
    Propre

Modèle de données

Chaque ticket porte les UUID de son projet, de son épic et de son sprint. Ce sont eux qui servent de clés étrangères dans le modèle :

Pensez aussi à typer les horodatages : ils arrivent en UTC au format YYYY-MM-DD HH:MM:SS et Power BI les traite comme du texte tant que vous ne les avez pas convertis via Table.TransformColumnTypes.

Dépannage

Sécurité

GitHub : Vérification HMAC

Chaque requête GitHub est vérifiée via une signature HMAC-SHA256 dans le header X-Hub-Signature-256. Toute requête avec une signature invalide est rejetée avec HTTP 401. Ne partagez jamais votre clé secrète.

Slack : Protection SSRF

Seules les URLs https://hooks.slack.com/services/… sont autorisées comme webhook Slack. Les URLs pointant vers des IP privées, localhost ou d'autres domaines sont systématiquement rejetées.

Discord : Protection SSRF

Seules les URLs https://discord.com/api/webhooks/<id>/<token> sont autorisées. Le token ne doit contenir que des caractères [A-Za-z0-9_-]. Toute autre URL est rejetée avec HTTP 422.

Rate limiting

Le bouton Tester (Slack et Discord) est limité à 5 appels par minute par utilisateur et par projet pour éviter les abus.

Circuit breaker Slack & Discord

En cas d'échecs répétés (5 livraisons consécutives en erreur), le connecteur est automatiquement désactivé pour éviter les erreurs silencieuses. Vous pouvez le réactiver depuis les paramètres une fois le webhook corrigé.

FAQ

Le webhook GitHub retourne ignored: invalid_json

Le Content type du webhook GitHub doit être application/json. Vérifiez ce réglage dans GitHub → Settings → Webhooks → votre webhook → Edit.

Le webhook retourne ignored: integration_not_configured

L'intégration GitHub n'est pas encore créée pour ce projet, ou elle a été supprimée. Configurez-la depuis Paramètres → Intégrations.

Les commits sont liés (refs_linked: 1) mais le statut ne change pas

Un push ne change jamais le statut : il crée seulement un lien informatif. Pour qu'une story se ferme automatiquement, utilisez une Pull Request mergée avec l'auto-close activé et une colonne de destination configurée.

Je ne reçois pas les notifications Slack

• Vérifiez que l'événement correspondant est coché dans la configuration du connecteur.
• Utilisez Tester la connexion pour valider que l'URL webhook est toujours active.
• Vérifiez que le connecteur n'a pas été désactivé par le circuit breaker (voir section Sécurité).
• Assurez-vous que l'app Slack est toujours installée dans votre workspace.

Puis-je connecter plusieurs dépôts GitHub ?

Non, un seul connecteur GitHub par projet est supporté. Pour multi-dépôts, configurez plusieurs webhooks GitHub pointant vers la même URL Manifst.

Un coéquipier ne voit pas le bloc « Développement »

Les connecteurs sont inclus à partir du plan Team, et la capacité s'évalue sur son abonnement, pas sur celui du propriétaire du projet ni sur le projet lui-même. Un membre au plan Starter ne voit donc ni le bloc, ni les pastilles de commits, même sur un projet dont le connecteur fonctionne. Ses propres commits, eux, restent bien rattachés et visibles des membres qui y ont droit.

La clé secrète GitHub n'est plus visible

Pour des raisons de sécurité, la clé secrète n'est affichée qu'une seule fois à la création. Si vous l'avez perdue, cliquez Régénérer le secret dans la configuration GitHub : cela invalide l'ancienne clé et en génère une nouvelle à copier dans GitHub.

Je ne reçois pas les notifications Discord

• Vérifiez que l'événement correspondant est coché dans la configuration du connecteur.
• Utilisez Tester pour vérifier que le webhook est toujours actif (Discord peut supprimer un webhook si le canal est supprimé ou si l'intégration est révoquée manuellement).
• Vérifiez que le connecteur n'a pas été désactivé par le circuit breaker (voir section Sécurité).
• Assurez-vous que le bot dispose bien des permissions d'écriture dans le canal cible.

Slack et Discord peuvent-ils être actifs en même temps ?

Oui. Les deux connecteurs sont indépendants. Si les deux sont configurés avec le même événement coché, Manifst envoie la notification aux deux simultanément.

Le token Discord dans l'URL est-il visible par les membres non-owner ?

Non. Pour les membres qui ne sont pas owners du projet, l'URL webhook Discord est masquée côté API : seuls les 4 premiers caractères du token sont visibles. Seul l'owner du projet voit l'URL complète.