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.

Les connecteurs GitHub, GitLab, Azure DevOps, Bitbucket, Slack, Discord, Microsoft Teams, Jira, Linear et Google Meet sont inclus à partir du plan Team. Power BI, l'API REST et le connecteur MCP relèvent du plan Portefeuille.

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 de piloter ses connecteurs : chaque membre est évalué sur son propre plan. Ce que les connecteurs Git rattachent aux fiches reste, lui, visible de tous les membres du projet.

Membre du projetCe qu'il peut faire
Plan Team ou supérieur Voir les liens Git sur les fiches, déclencher une synchronisation Jira, analyser une réunion Meet. La configuration reste réservée aux owners du projet.
Plan Starter Voit le bloc Développement des fiches et les pastilles de commits et de pull requests, en lecture seule. Ne peut ni configurer un connecteur, ni déclencher une synchronisation, ni analyser une réunion : même si le projet en a d'actifs.

Le travail de ce membre alimente aussi les connecteurs : ses commits sont rattachés aux tickets, ses modifications partent dans Jira, ses actions déclenchent les notifications. Les liens Git sont une lecture, ouverte à toute l'équipe comme les risques ou la RACI : seul le pilotage des connecteurs dépend de l'abonnement.

ConnecteurDirectionUsage principal
GitHub GitHub → Manifst Lier commits & PRs aux tickets, fermeture automatique sur merge
GitLab GitLab → Manifst Lier commits & merge requests aux tickets, fermeture automatique sur merge
Azure DevOps Azure DevOps → Manifst Lier commits & pull requests aux tickets, fermeture automatique sur merge
Bitbucket Bitbucket → Manifst Lier commits & pull requests aux tickets, fermeture automatique sur merge
Slack Manifst → Slack Notifications temps-réel sur les changements de statut, sprints, commentaires
Discord Manifst → Discord Notifications embed dans un canal Discord via Incoming Webhook
Microsoft Teams Manifst → Teams Notifications sous forme de cartes dans un canal Teams via un webhook Workflows
Power BI / API REST Manifst → Power BI Piloter et consolider vos données (EVM, coûts, backlog, roadmap) dans un rapport BI via l'API v1
Assistants IA (MCP) Manifst ↔ Claude, ChatGPT, Le Chat Consulter et mettre à jour vos projets en langage naturel depuis votre assistant IA

GitHub

Liez automatiquement commits et pull requests à vos tickets via des références dans les messages.

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.

Syntaxe
#<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 :

PréfixeCible
#US-42, #BG-7, …Un ticket, selon les abréviations définies dans Paramètres → Types de tickets
#EP-12Un Epic
#SE-3Un Super Epic
Le préfixe doit correspondre au type réel de l'élément : #US-42 ne rattache rien si l'élément 42 est un bug affiché BG-42. Les références non résolues sont visibles dans le journal des livraisons, elles ne sont pas rattachées au hasard.
Exemples
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.

Champ enregistréSource
SHA du commitcommit.id
Messagecommit.message (500 car. max)
URLcommit.url
Auteurcommit.author.name
Brancheref
Un push ne change pas le statut du ticket. Il crée uniquement un lien, visible dans le bloc Développement de la fiche. Pour changer le statut automatiquement, utilisez une Pull Request avec l'auto-close activé.

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.

Exemple de description de PR
## 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 :

Action GitHubStatut Manifst
opened, reopened, synchronize, editedopen (ou draft si la PR est en brouillon)
converted_to_draftdraft
ready_for_reviewopen
closed (non mergée)closed
closed (mergée)merged
Le texte courant de la PR fait autorité : retirer #US-42 de la description retire le lien correspondant. Un lien ayant déjà déclenché une fermeture automatique est conservé, pour ne pas effacer la trace de ce qui a changé le statut.

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.
Si un ticket a déjà le statut cible, aucune modification n'est effectuée. La colonne de destination doit appartenir au même projet.
L'auto-close ne concerne que les tickets. Un Epic ou un Super Epic référencé par #EP- ou #SE- est bien rattaché à la PR, mais son statut n'est jamais modifié : ces deux niveaux ne sont pas pilotés par les colonnes du Kanban.

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

Mêmes rattachements que GitHub, appliqués aux merge requests. Les deux connecteurs peuvent coexister sur un même projet.

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.
L'authentification GitLab est plus faible que celle de GitHub, et cela tient à GitLab, pas à Manifst. GitHub signe le corps de chaque livraison (HMAC-SHA256), ce qui prouve à la fois la détention du secret et l'intégrité du contenu. GitLab se contente de renvoyer le jeton en clair dans un en-tête. Conséquences : le contenu reçu n'est pas vérifiable, et le jeton est rejouable s'il est intercepté. L'URL du webhook doit donc être en HTTPS : en HTTP, le jeton circule en clair à chaque push.

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.

GitHubGitLab
Pull requestMerge request : numérotée !42 dans l'interface
Événement pull_requestMerge request events
En-tête X-Hub-Signature-256En-tête X-Gitlab-Token
Content type: application/json à choisirToujours JSON, rien à régler
Manifst retient le numéro visible de la merge request (iid, celui de l'URL et du !42), pas son identifiant interne à l'instance. Les liens pointent donc bien sur la MR que vous voyez.

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

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.
« Resource details to send » doit rester sur « All ». Réglé sur Minimal ou None, Azure n'envoie plus ni commits, ni titre, ni branche : il n'y a alors plus rien à analyser, et aucun lien ne peut être créé. Le journal des livraisons signale ce cas par le motif resource_too_thin : c'est un problème de réglage, pas de syntaxe de référence.
L'authentification est de même force que celle de GitLab, pas que celle de GitHub, et cela tient à Azure DevOps. GitHub signe le corps de chaque livraison (HMAC-SHA256), ce qui prouve à la fois la détention du secret et l'intégrité du contenu. Azure DevOps ne signe rien : il se contente de transmettre les en-têtes que vous lui avez indiqués. Conséquences : le contenu reçu n'est pas vérifiable, et le jeton est rejouable s'il est intercepté. L'URL du webhook doit donc être en HTTPS : Azure l'exige d'ailleurs dès qu'une authentification est en jeu.

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.

GitHubAzure DevOps
Un webhook, plusieurs événementsUne souscription par événement
En-tête X-Hub-Signature-256 (signature)En-tête libre X-Manifst-Token (jeton partagé)
Événement pull_requestPull request created / updated / merge attempted
Pull request notée #42Pull request notée !42
L'événement s'appelle « Pull request merge attempted », et le mot compte : Azure l'émet aussi quand la fusion échoue, sur conflit par exemple. Manifst ne considère la pull request comme fusionnée : et ne déclenche donc la fermeture automatique : que si Azure annonce en plus un état completed et une fusion succeeded. Une pull request en conflit ne ferme aucun ticket.

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.

Azure DevOps refuse de cibler localhost et les plages d'adresses réservées. Un environnement de développement n'est donc pas atteignable directement : il faut exposer Manifst derrière un tunnel HTTPS public pour éprouver le connecteur hors production.

Bitbucket

Mêmes rattachements que les trois autres plateformes, appliqués aux Webhooks de Bitbucket Cloud. Le moteur d'analyse est le même code : la syntaxe des références ne change pas d'une plateforme à l'autre.

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.
Le champ « Secret » n'est pas optionnel côté Manifst. Bitbucket accepte de créer un webhook sans secret : il n'envoie alors aucune signature, et Manifst refuse la livraison (HTTP 401). C'est délibéré : sans signature, n'importe qui connaissant l'URL pourrait fabriquer de faux liens de commit sur vos tickets. Un webhook qui ne remonte rien du tout, avec des 401 dans l'onglet View requests de Bitbucket, c'est presque toujours ce champ resté vide.
L'authentification est de même force que celle de GitHub, contrairement à GitLab et Azure DevOps. Bitbucket signe le corps de chaque livraison en HMAC-SHA256 et transmet le résultat dans l'en-tête X-Hub-Signature : la détention du secret et l'intégrité du contenu sont donc prouvées. Le secret n'est jamais rejouable seul.

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.

GitHubBitbucket
En-tête X-Hub-Signature-256En-tête X-Hub-Signature (même HMAC-SHA256)
Événement pull_requestpullrequest:created / updated / fulfilled / rejected
Fusionnée = mergedFusionnée = fulfilled, refusée = rejected
Une branche par livraisonPlusieurs branches possibles dans une seule livraison
Un git push --all arrive chez Bitbucket sous la forme d'un seul événement décrivant plusieurs branches. Manifst les analyse toutes : les tickets cités sur chacune sont rattachés en une fois. Les tags sont en revanche ignorés (motif tag_only au journal) : un tag n'est pas une branche de travail.
Bitbucket tronque les commits des gros pushes. Au-delà d'un certain volume, la charge utile ne contient qu'un extrait des commits et Bitbucket lève un drapeau truncated, que le journal des livraisons reprend. Un commit qui n'a pas été transmis ne peut pas être rattaché : ce n'est ni une erreur de syntaxe, ni un défaut de Manifst. Poussez plus souvent, ou citez la référence sur la pull request, qui n'est jamais tronquée.

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.

Bitbucket refuse de cibler localhost et les plages d'adresses réservées. Un environnement de développement n'est donc pas atteignable directement : il faut exposer Manifst derrière un tunnel HTTPS public pour éprouver le connecteur hors production.

Jira

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.
Passer à l'étape suivante enregistre le connecteur, mais n'écrit rien dans votre backlog. Les deux gestes sont distincts : la configuration est sauvegardée dès l'étape 5, le contenu ne l'est qu'à l'étape 6.

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é.

La reconnaissance se fait sur le nom du type de lien. Sur une instance Jira dont les types ont été créés dans une autre langue (« Bloque », « Blockiert »…), les dépendances ne remontent pas. L'étape Synchro nomme les types de liens réellement rencontrés : c'est là qu'on le voit.

Azure Boards

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.

Un seul outil de backlog par projet. Jira et Azure Boards écrivent tous deux le parent, l'état et le sprint des mêmes tickets. Les brancher ensemble ne synchroniserait pas deux fois : ils s'écraseraient l'un l'autre à chaque passage. Manifst refuse donc le second : débranchez le premier si vous changez d'outil.

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.
Passer à l'étape suivante enregistre le connecteur, mais n'écrit rien dans votre backlog. Les deux gestes sont distincts : la configuration est sauvegardée dès l'étape 5, le contenu ne l'est qu'à l'étape 6. La lecture reste valable 30 minutes ; passé ce délai, relancez-la.
Équipe et itérations. Les itérations remontent par équipe. Une itération définie au niveau du projet mais non rattachée à l'équipe choisie n'apparaîtra pas dans vos sprints : c'est la première cause de « mes sprints ne remontent pas ». Laissez le champ Équipe vide pour utiliser l'équipe par défaut du projet.

Correspondances

ManifstAzure Boards (Agile)Azure Boards (Scrum)
Super EpicEpicEpic
EpicFeatureFeature
TicketUser StoryProduct Backlog Item
Sous-tâcheTaskTask
SprintItération (System.IterationPath)
Story pointsMicrosoft.VSTS.Scheduling.StoryPointsMicrosoft.VSTS.Scheduling.Effort
StatutCatégorie d'état (Proposed / InProgress / Resolved / Completed)
PrioritéMicrosoft.VSTS.Common.Priority (1 à 4)
DépendanceRelation Predecessor / Successor

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

Limites

Linear

Linear

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

Un seul outil de backlog par projet. Jira, Azure Boards et Linear écrivent tous le parent, l'état et le sprint des mêmes tickets. Les brancher ensemble créerait des conflits d'écritures concurrentes. Manifst refuse donc d'activer un second connecteur de backlog sur le même projet : débranchez le premier si vous changez d'outil.

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.
Enregistrement et première écriture. Passer l'étape de configuration enregistre le connecteur dans votre projet, mais n'importe aucun élément dans Manifst tant que l'étape 6 n'est pas validée. Une fois activée, la synchronisation automatique repasse régulièrement en incrémental.
Synchronisation temps réel vers Linear. Dès que le connecteur est actif, toute modification effectuée dans Manifst (création ou mise à jour de Ticket, Sous-tâche, Epic, Super Epic, Sprint, Commentaire ou Dépendance) est immédiatement propagée vers Linear via son API GraphQL.

Correspondances

Concept ManifstObjet / Champ LinearDétails & Rapprochement
Super EpicInitiativeTitre, description (Markdown), statut, dates de début et cible.
EpicProjectRattaché à l'Initiative (Super Epic) parente et à l'équipe sélectionnée.
TicketIssueTitre, description (Markdown), priorités, points d'effort et statut.
Type de ticketLabel Type / ...Déduit des labels ayant le préfixe configuré (ex. Type / Feature → Feature).
Sous-tâcheSub-issueEnfant d'une Issue Linear, synchronisée avec état (À faire / En cours / Terminé).
SprintCycleDates de début/fin, nom du cycle, description et état (Actif / Passé / Futur).
Story pointsEstimateValeur numérique estimée sur l'Issue Linear.
PrioritéPriorityUrgent (1) ↔ Critique, High (2) ↔ Haute, Normal (3) ↔ Normale, Low (4) ↔ Faible.
StatutState CategoryTriage/Backlog/Unstarted → À faire, Started → En cours, Completed/Canceled → Terminé.
Membre assignéAssigneeRapprochement automatique basé sur l'adresse email de l'utilisateur.
CommentairesCommentsSynchro bidirectionnelle des commentaires textuels rattachés aux tickets.
ÉtiquettesLabelsCréation et rattachage automatique des tags Manifst correspondants.
DépendancesRelations (blocks)Les liens d'ordonnancement Linear sont synchronisés avec le graphe de dépendances Manifst.

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.

Lorsqu'un ticket local B est marqué comme dépendant d'un ticket A dans Manifst, le connecteur crée une relation GraphQL de type blocks où A bloque B dans Linear. Réciproquement, toute relation blocks créée dans Linear est immédiatement reflétée sur le diagramme et les fiches Manifst.

Limites & Bonnes pratiques

Slack

Recevez des notifications dans un canal Slack à chaque événement important de votre projet.

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.
Seules les URLs https://hooks.slack.com/services/… sont acceptées. Toute autre URL est rejetée pour des raisons de sécurité.

Événements disponibles

story_status_changed
Déclenché quand le statut d'une ticket change. Le message indique l'ancien statut, le nouveau statut et le titre de le ticket.
story_assigned
Déclenché quand une ticket est assignée à un membre de l'équipe (ou réassignée). N'est pas déclenché si l'assigné ne change pas.
new_comment
Déclenché à chaque nouveau commentaire sur une ticket. Le message inclut un aperçu du commentaire (120 caractères max, HTML strippé).
sprint_started
Déclenché quand un sprint passe de En planification à Actif.
sprint_ended
Déclenché quand un sprint est marqué comme Terminé.
pr_merged
Déclenché quand une pull request GitHub référençant un ou plusieurs éléments est mergée. Le message indique la branche cible, l'auteur du merge et les éléments liés. Nécessite le connecteur GitHub sur le même projet.

Format des messages

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

story_status_changed
🔄 *Statut modifié* : *Modifier le profil utilisateur*
Backlog → En cours
story_assigned
👤 *Story assignée* : *Ajouter la pagination*
Assignée à *Marie Dupont*
new_comment
💬 *Nouveau commentaire* sur *Modifier le profil utilisateur*
Par *Jean Martin* : Le formulaire doit aussi gérer la photo de profil…
sprint_started
🚀 *Sprint démarré* : *Sprint 3 : Auth & Profil*
sprint_ended
✅ *Sprint terminé* : *Sprint 3 : Auth & Profil*

Discord

Recevez des notifications embed dans un canal Discord à chaque événement important de votre projet.

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.
Seules les URLs https://discord.com/api/webhooks/… sont acceptées. Toute autre URL est rejetée pour des raisons de sécurité (anti-SSRF).

É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.

story_status_changed
Déclenché quand le statut d'une ticket change. L'embed indique l'ancien et le nouveau statut ainsi que le titre de le ticket.
story_assigned
Déclenché quand une ticket est assignée ou réassignée à un autre membre. N'est pas déclenché si l'assigné ne change pas.
new_comment
Déclenché à chaque nouveau commentaire sur une ticket. L'embed inclut un aperçu du commentaire (120 caractères max, HTML strippé).
sprint_started
Déclenché quand un sprint passe de En planification à Actif.
sprint_ended
Déclenché quand un sprint est marqué comme Terminé.
pr_merged
Déclenché quand une pull request GitHub référençant un ou plusieurs éléments est mergée. Le message indique la branche cible, l'auteur du merge et les éléments liés. Nécessite le connecteur GitHub sur le même projet.

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`).

ÉvénementCouleur
sprint_started#57F287 : Vert
sprint_ended#FEE75C : Jaune
new_comment#EB459E : Rose
story_status_changed, story_assigned#5865F2 : Blurple
pr_merged#8B5CF6 : Violet

Exemple de payload envoyé à Discord :

POST https://discord.com/api/webhooks/<id>/<token>
{
  "embeds": [{
    "description": "🔄 **Story mise à jour** : **Modifier le profil utilisateur**\nStatut : `Backlog` → `En cours`",
    "color": 5793266
  }]
}
Discord répond HTTP 204 No Content en cas de succès (contrairement à Slack qui répond 200 ok). Le connecteur Manifst détecte tout code différent de 204 comme un échec.

Microsoft Teams

Recevez une carte dans un canal Microsoft Teams à chaque événement important de votre projet.

Configuration

  1. Dans Teams, ouvrez l'application Workflows (ou, sur le canal cible : … → Workflows).
  2. Choisissez le modèle « Envoyer des alertes webhook à un canal » (Post to a channel when a webhook request is received), puis sélectionnez l'équipe et le canal.
  3. Si le déclencheur demande qui peut l'appeler, choisissez N'importe qui : c'est la signature contenue dans l'URL qui sert de secret.
  4. Copiez l'URL générée. Elle a l'une de ces deux formes :
    https://prod-NN.<région>.logic.azure.com:443/workflows/…/triggers/manual/paths/invoke?…&sig=…
    https://<environnement>.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/…/triggers/manual/paths/invoke?…
  5. Dans Manifst, ouvrez Paramètres → Intégrations → Microsoft Teams → Configurer et collez l'URL.
  6. Cochez les événements souhaités et la langue des messages.
  7. Cliquez Tester, vérifiez que la carte arrive dans le canal, puis Enregistrer.
Les anciens connecteurs Office 365 (« Incoming Webhook », URL *.webhook.office.com) ont été retirés de Teams par Microsoft en mai 2026 et ne livrent plus rien. Manifst les refuse : seul un webhook Workflows est accepté.
Teams répond HTTP 202 Accepted : le message est mis en file, pas encore affiché. Un test vert prouve que l'URL est valide ; si la carte n'apparaît pas, ouvrez l'historique d'exécution du flux dans Workflows. Un flux appartient à la personne qui l'a créé : s'il est supprimé ou si son compte est désactivé, recréez-le et collez la nouvelle URL.

Événements disponibles

Les événements sont identiques à ceux des connecteurs Slack et Discord : story_status_changed, story_assigned, new_comment, mention, sprint_started, sprint_ended, poker_started, standup_closed (daily clôturé) et pr_merged. Un même événement part vers toutes les messageries actives qui y sont abonnées.

Format des cartes

Chaque notification est une Adaptive Card : un titre en gras, le sujet (lien vers Manifst) puis les détails alignés en deux colonnes libellé / valeur. Les messages apparaissent au nom de la personne qui a créé le flux, suivi de « via Workflows ».

Exemple de payload envoyé à Teams :

POST https://prod-NN.<région>.logic.azure.com/workflows/…/triggers/manual/paths/invoke?…
{
  "type": "message",
  "attachments": [{
    "contentType": "application/vnd.microsoft.card.adaptive",
    "content": {
      "type": "AdaptiveCard",
      "version": "1.4",
      "body": [
        { "type": "TextBlock", "weight": "Bolder", "size": "Medium", "wrap": true, "text": "🔄 Statut modifié" },
        { "type": "TextBlock", "wrap": true, "text": "[Modifier le profil utilisateur](https://…)" },
        { "type": "FactSet", "facts": [ { "title": "Statut", "value": "Backlog → En cours" } ] }
      ],
      "msteams": { "width": "Full" }
    }
  }]
}

Google Meet

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 Récupérer le transcript : Launchpad s'ouvre avec le transcript, et l'IA Manifst en tire le backlog.

Assistants IA (MCP) : Claude, ChatGPT, Le Chat

Le serveur MCP de Manifst branche votre assistant IA sur vos projets. Demandez-lui où en est le sprint, quels tickets sont bloqués ou de rédiger une user story : il interroge Manifst et agit avec vos droits.

Le connecteur passe par l'API v1 : appartenance aux projets, permissions de rôle et règles de transition s'appliquent comme dans l'application. Il ne consomme aucun crédit IA, car c'est votre assistant qui fait le travail. Chaque modification apparaît dans l'historique du ticket avec la mention MCP.

Prérequis

Connexion

  1. Dans Manifst, ouvrez Paramètres → Accès → Assistants IA (MCP) et copiez l'URL du serveur. Choisissez votre assistant pour afficher ses étapes.
  2. Dans l'assistant, ajoutez un connecteur personnalisé et collez l'URL : Claude (Paramètres → Connecteurs), ChatGPT (mode développeur, Paramètres → Applications), Le Chat (Connecteurs → connecteur MCP personnalisé), Grok (Connecteurs → Custom).
  3. Autorisez l'accès sur l'écran Manifst qui s'ouvre. Aucune clé à copier : la connexion passe par OAuth.
  4. Les assistants connectés sont listés dans la même carte, avec leur dernière utilisation. Déconnecter coupe l'accès immédiatement.
Gemini CLI se branche avec une clé API plutôt que par OAuth : la commande à lancer est fournie dans la même carte. Dans un espace ChatGPT Business ou Enterprise, ou Grok Business, un administrateur doit d'abord autoriser le connecteur.

Ce que l'assistant peut faire

OutilRôle
list_projectsProjets auxquels vous avez accès
get_project_overviewStatuts, types de tickets, membres, sprints et volume par statut
list_ticketsTickets filtrés par statut, assigné, sprint, type, priorité ou texte
get_ticketDétail : description, critères d'acceptation, sous-tâches, liens (bloqué par, bloque, duplique, lié à), commentaires
list_epics · list_sprintsEpics et Super Epics, sprints avec objectif et dates
get_roadmapJalons et dépendances finish-to-start
get_financeValeur acquise : BAC, PV, EV, AC, CPI, SPI, EAC, si votre rôle voit la finance
get_portfolio_financeValeur acquise consolidée sur tous vos projets ou un programme, avec une ligne par projet
list_time_entriesTemps saisi, filtré par ticket, personne ou période, avec les totaux par personne et par ticket
create_ticket · update_ticketCréer (dans le projet que vous avez désigné : l’assistant vous le demande s’il hésite) et modifier un ticket, en Markdown, selon les règles de transition
create_epic · update_epicCréer (dans le projet que vous avez désigné) et modifier un epic
create_super_epic · update_super_epicCréer (dans le projet que vous avez désigné) et modifier un Super Epic, qui regroupe des epics
create_backlogCréer tout un backlog en un seul appel, en tout-ou-rien : Super Epic, epics, tickets et critères d’acceptation, ou des tickets ajoutés à des epics existants. Un appel rejoué ne crée pas de doublon
create_sprint · update_sprintCréer un sprint (dans le projet que vous avez désigné), modifier son objectif et ses dates
start_sprint · close_sprintDémarrer un sprint (un seul actif à la fois) et clôturer le sprint actif : les tickets non terminés passent au sprint suivant ou retournent au backlog, comme dans l’application
create_subtask · update_subtaskAjouter, renommer ou faire avancer une sous-tâche
add_commentCommenter un ticket et mentionner des membres
link_ticketsLier deux tickets : bloqué par, bloque, duplique, lié à. Une boucle de blocage est refusée
log_timeSaisir du temps, qui alimente le coût réel du projet

Sécurité et données

Power BI / API REST

Connectez Power BI Desktop (ou tout outil BI) à l'API REST v1 pour construire vos propres rapports et consolider plusieurs équipes-projets : valeur acquise (EVM), coûts, backlog, roadmap.

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

La clé est affichée une seule fois à la création et équivaut à un accès en lecture à vos données. Ne la partagez pas et ne l'exposez jamais côté client.

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 :

Les exemples écrivent la clé en dur pour rester lisibles. En pratique, créez un paramètre ApiKey (Accueil → Gérer les paramètres) et remplacez ApiKey = "mfst_live_…" par ce paramètre : une seule valeur à changer, et vous pourrez la redéfinir dans le service Power BI sans rouvrir le fichier.
Indicateurs EVM d'un projet
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.

Déclarez toujours l'en-tête via Web.Contents(BaseUrl, [RelativePath=…, Headers=…]) plutôt que dans l'assistant graphique : c'est la forme qui évite l'erreur « source de données dynamique » au rafraîchissement planifié.

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.

Table « un projet par ligne »
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" ].

La consolidation EVM ne porte que sur les projets dont le BAC est déclaré (Finance → onglet Budget). Les coûts de tous les projets restent visibles via les champs ac_all et engaged_all.

Rafraîchissement incrémental & pagination

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

ParamètreRôle
updated_sinceNe renvoie que les éléments modifiés depuis cette date (YYYY-MM-DD) : base d'un refresh incrémental.
page / per_pagePagination (défaut 100, max 500 par page). Le bloc meta.total donne le total réel.
            RelativePath = "tickets",
            Query = [ project = "UUID_DU_PROJET", updated_since = "2026-07-01", per_page = "500", page = "1" ],
            Headers = [ Authorization = "Bearer " & ApiKey ]
Demander page = "1" ne ramène que la première page. Au-delà de per_page tickets, le reste est absent du rapport sans le moindre message d'erreur : comparez toujours le nombre de lignes chargées à meta.total. Soit vous omettez page et per_page (l'API renvoie alors tout le projet d'un coup, ce qui suffit largement en dessous de quelques milliers de tickets), soit vous bouclez comme ci-dessous.
Toutes les pages : la boucle s'arrête sur la première page vide
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
Quotas API : 1 000 requêtes/heure et 10 000/mois par clé. Chaque réponse renvoie les en-têtes X-RateLimit-Remaining-*. Un rafraîchissement complet coûte une requête par table et par projet : pour douze projets (tickets, sprints, épics, finance, plus la liste des projets et le roll-up), comptez une cinquantaine d'appels, soit de l'ordre de six rafraîchissements complets par jour. Si c'est trop juste, rafraîchissez souvent /portfolio/finance : un seul appel : et gardez le détail ticket par ticket sur un rythme plus lent.

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 :

TableCléRelation
Projets (/projects)uuid1 : ∗ Tickets[project_uuid]
Épics (/epics)uuid1 : ∗ Tickets[epic_uuid]
Sprints (/sprints)uuid1 : ∗ Tickets[sprint_uuid]
Finance (/finance)project_uuid1 : 1 Projets[uuid]
Les colonnes project_id, epic_id et sprint_id sont des identifiants internes, conservés pour compatibilité. Ne les prenez pas comme clés : /projects et /sprints n'exposent pas d'id, les relations ne se refermeraient sur rien.

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

SymptômeCause & solution
401 MISSING_API_KEYL'en-tête Authorization n'est pas transmis. Utilisez la forme Web.Contents(BaseUrl, [Headers=…]) et non l'assistant graphique.
401 INVALID_API_KEYClé erronée, révoquée ou expirée. Régénérez-en une dans Paramètres → Clés API.
403 INSUFFICIENT_SCOPELa clé n'a pas le scope requis (finance:read, roadmap:read…). Recréez-la avec les bons scopes.
403 PLAN_REQUIREDL'API REST est incluse à partir du plan Portefeuille : le compte propriétaire de la clé n'y est pas.
403 EXTERNAL_ACCESS_DENIEDLe propriétaire du projet n'a pas ouvert l'accès par assistant IA ou API à votre rôle. Il peut le faire dans Paramètres → Accès → Assistants IA et API.
429 RATE_LIMIT_EXCEEDEDQuota horaire/mensuel dépassé. Attendez la valeur du header Retry-After ou réduisez la fréquence.
La connexion marche en Desktop mais pas au refresh planifiéEn-tête déclaré via l'assistant (source dynamique). Repassez à la requête M ci-dessus avec RelativePath + Headers.

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.

Si votre clé secrète est compromise, régénérez-la immédiatement depuis Paramètres → Intégrations → GitHub → Régénérer le secret, puis mettez à jour la valeur dans GitHub.

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.

Microsoft Teams : Protection SSRF

Seuls les déclencheurs HTTP Workflows hébergés par Microsoft sont autorisés : hôte prod-NN.<région>.logic.azure.com ou <env>.environment.api.powerplatform.com, en HTTPS sur le port 443, avec un chemin se terminant par /triggers/manual/paths/invoke. Toute autre URL est rejetée avec HTTP 422. Pour les membres non-owners, la signature sig de l'URL est masquée.

Rate limiting

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

Circuit breaker Slack, Discord & Teams

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

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.

Le bloc « Développement » n'apparaît pas sur une fiche

Le bloc s'affiche dès que le projet a un connecteur Git actif, ou que la fiche porte déjà des liens. Sans l'un ni l'autre, il est masqué pour ne pas encombrer les projets qui n'utilisent pas Git. Le plan du membre n'y change rien : un membre au plan Starter voit le bloc et les pastilles de commits comme les autres, il ne peut simplement pas configurer le connecteur.

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

Slack, Discord et Teams 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.

Je ne reçois pas les notifications Teams

Mon ancienne URL webhook.office.com est refusée

Microsoft a retiré les connecteurs Office 365 de Teams en mai 2026 : ces URL ne délivrent plus aucun message. Recréez la notification avec l'application Workflows (voir Configuration).