Comment utiliser Briefboard avec Claude Code (MCP)

Briefboard embarque un serveur MCP : Claude Code peut lire et écrire votre projet directement — sans copier-coller de tâches dans un prompt. L'agent travaille depuis les mêmes milestones, specs et tâches que votre équipe.

Ce guide couvre l'installation, puis déroule une session réelle complète : l'agent tire sa prochaine tâche, lit la spec qui la gouverne, implémente et rend compte — pendant que votre board reste juste sans que personne n'y touche.

Ce que MCP vous apporte

MCP (le Model Context Protocol) est un standard qui permet aux outils IA de dialoguer avec des systèmes externes. Briefboard expose ses données projet via un serveur MCP, donc un agent connecté peut :

Tirer la prochaine tâche prioritaire qui lui est assignée.
Lire le brief complet et l'historique de discussion d'une tâche.
Récupérer le milestone et ses specs.
Mettre à jour le statut des tâches et poster des commentaires de progression.

La différence avec le contexte collé à la main, ce n'est pas le confort — c'est la fraîcheur. Un brief collé est périmé dès qu'un collègue repriorise. Un agent en MCP interroge le board au moment où il commence à travailler.

Connecter Claude Code

Une seule commande :

claude mcp add --transport http briefboard https://app.briefboard.io/mcp/briefboard

Le serveur est un endpoint HTTP streamable protégé par OAuth avec enregistrement dynamique du client : un écran d'autorisation s'ouvre dans votre navigateur, vous approuvez, et la connexion est enregistrée. Aucune clé API à créer, aucun token à faire tourner.

Vous utilisez Cursor ou OpenAI Codex ? Le guide de connexion MCP donne la configuration équivalente pour chaque client.

En développement local, connectez-vous en http:// plutôt qu'en https:// — certains clients MCP utilisent le magasin de certificats de Node et rejetteront un certificat auto-signé.

Une vraie session, du début à la fin

Voici à quoi ressemble concrètement une session de travail sur un projet — appelons-le Atlas — où un milestone est en cours et des tâches sont assignées à l'agent.

1. L'agent demande du travail

Vous ouvrez Claude Code et tapez une ligne :

> Récupère ma prochaine tâche Briefboard et implémente-la.

L'agent appelle get-next-task et reçoit la tâche la plus prioritaire qui lui est assignée — pas une supposition : le même ordre que celui que votre équipe voit sur le board :

● briefboard - get-next-task
  ⎿ BB-T204 — Add retry logic to webhook delivery
    Milestone : MA-M1 « Public launch » (at risk)
    Priorité : haute · Statut : todo

2. Il tire le brief complet

Un titre de tâche ne suffit pas pour implémenter. L'agent appelle get-task-prompt, qui renvoie un prompt d'implémentation pré-rempli avec tout ce que le board sait : description de la tâche — checklist des résultats attendus comprise —, objectif du milestone, et les specs liées à ce milestone.

● briefboard - get-task-prompt
  ⎿ ## Task: Add retry logic to webhook delivery
    Failed webhook deliveries are currently dropped. Add exponential
    backoff with a maximum of 5 attempts.

    - [ ] Failed deliveries retry with exponential backoff
    - [ ] Delivery gives up after 5 attempts and marks the webhook failed
    - [ ] Each attempt is logged with its attempt number

    ## Linked spec: webhook-delivery-contract (v3)
    Retries MUST reuse the original event payload. The receiving
    endpoint sees an `X-Attempt` header…

Ce dernier bloc, c'est ce que les workflows copier-coller perdent toujours : la spec. Dans Briefboard, les specs sont des documents versionnés liés aux milestones — un contrat d'API, un modèle de données, des règles d'acceptation. L'agent ne travaille pas depuis son souvenir de votre architecture ; il travaille depuis le document sur lequel votre équipe s'est accordée. S'il lui en faut plus, get-milestone-specs et get-spec sont à un appel de distance.

3. Il travaille — et prend la tâche

Avant d'écrire du code, l'agent passe la tâche en cours pour que le board reflète la réalité :

● briefboard - update-task-status (BB-T204, in_progress)
  ⎿ Task BB-T204 is now in progress

Quiconque regarde le board Atlas à cet instant — y compris vos collègues non techniques — voit BB-T204 avancer, sans standup. Puis l'agent fait ce que Claude Code sait faire : lire le code, écrire la logique de retry, lancer les tests.

4. Il rend compte là où l'équipe lit

Le travail terminé, l'agent ne résume pas dans le vide d'un terminal. Il poste sur le canal technique de la tâche :

● briefboard - add-task-comment (BB-T204, channel: technical)
  ⎿ Implemented exponential backoff (base 2s, max 5 attempts) in
    WebhookDeliveryJob. Added X-Attempt header per spec v3. 14 new
    tests, all green. Files: app/Jobs/WebhookDeliveryJob.php,
    tests/Feature/WebhookRetryTest.php

…et passe la tâche en done :

● briefboard - update-task-status (BB-T204, done)
  ⎿ Task BB-T204 is now done

Contribution humaine totale sur toute la boucle : une phrase. Mises à jour du board faites à la main : zéro.

Pourquoi ça survit à plusieurs sessions

Le superpouvoir discret de cette configuration : l'état vit sur le board, pas dans la conversation. Fermez Claude Code, rouvrez-le demain, demandez la prochaine tâche — l'agent reprend exactement là où en est le projet, parce que le projet est la source de vérité. Même chose pour faire tourner plusieurs agents, ou un agent et un humain, sur le même milestone : ils se coordonnent par l'assignation et le statut des tâches, comme des coéquipiers — pas via un document de prompt partagé que quelqu'un a oublié de mettre à jour.

C'est aussi pour ça que la boucle fonctionne à toute échelle. Dev solo, un projet, l'agent fait le gros de l'implémentation ? Le board est votre mémoire entre les sessions. Équipe de huit avec deux agents dans la boucle ? Même board, mêmes règles — les agents respectent les mêmes rôles, permissions et limites de plan que n'importe quel membre.

Si quelque chose ne marche pas

Trois points couvrent l'essentiel des frictions d'installation :

L'écran d'autorisation ne s'ouvre jamais. Vérifiez que vous vous connectez à l'endpoint exact https://app.briefboard.io/mcp/briefboard avec --transport http — le serveur streame en HTTP ; une configuration stdio ne se connectera pas.
L'agent ne voit aucune tâche. get-next-task renvoie les tâches assignées au membre connecté. Si la file est vide, assignez une tâche à l'agent sur le board — ou demandez-lui d'appeler list-tasks et d'en prendre une.
Un appel d'outil est refusé. Les outils respectent les mêmes permissions et quotas que l'application web. Un agent membre d'un projet ne peut pas toucher aux autres, et les limites du plan Free s'appliquent aussi aux agents. C'est voulu : vos rôles définissent le périmètre.

Gardez l'humain dans la boucle

L'agent peut déplacer des tâches et laisser des commentaires, mais les décisions importantes — quoi construire, quand c'est vraiment terminé, quand merger — restent chez vous. Rien dans la boucle ci-dessus ne merge du code ni ne clôt un milestone ; elle garde l'image partagée honnête pendant que l'agent abat le travail.

C'est toute l'idée du développement piloté par IA sur Briefboard : donner à l'agent du vrai contexte, le laisser travailler, et garder les humains concentrés sur les résultats. Pour la liste complète des outils — planification, specs, triage — direction le guide des outils MCP.