Étude de cas · UnlockLive IT (projet interne)

Connecter Claude à notre gestionnaire de tâches avec un serveur MCP distant (OAuth, Python, Django)

Comment nous avons créé un serveur MCP distant pour que chaque membre de notre équipe puisse interroger Claude sur les projets et les tâches, et les créer ou les mettre à jour, en son propre nom : connexion OAuth personnelle, scopes de lecture et d'écriture, 11 outils et un historique complet des modifications.

  • SecteurLogiciel / Outils internes
  • Année2026
  • PaysCanada
Connecting Claude to Our Task Manager with a Remote MCP Server (OAuth, Python, Django) hero screenshot

Résultats en un coup d'œil

  • 11outils MCP pour lire et modifier les tâches
  • 9,700+tâches réparties sur 165 projets, accessibles depuis Claude dès le lancement, dans le cadre des autorisations de chacun
  • 63tests automatisés couvrant le serveur MCP et le côté application
  • 0token utilisateur transmis au système interne

Le défi

Notre équipe gère des milliers de tâches réparties sur de nombreux projets clients dans notre propre gestionnaire de tâches. Les points quotidiens, les rapports hebdomadaires et la transformation de comptes rendus de réunion en tâches impliquaient beaucoup de copier-coller entre le gestionnaire de tâches et les conversations avec l'IA, et chaque copier-coller risquait d'introduire des erreurs ou de faire fuiter des données clients au mauvais endroit. Nous voulions que chacun puisse simplement demander à Claude « Qu'est-ce qui est en retard sur mes projets ? » ou « Transforme ces notes en tâches », l'IA travaillant dans le cadre des autorisations propres à chaque personne.

Notre solution

Nous avons créé un serveur MCP distant en Python et l'avons connecté à notre gestionnaire de tâches Django. Le gestionnaire de tâches fait office de serveur d'autorisation OAuth : chaque personne se connecte avec son compte existant et approuve l'accès ; le serveur MCP vérifie chaque token avant l'exécution d'un outil. Il ne transmet jamais le token de l'utilisateur à l'application : il appelle une API interne avec ses propres identifiants de service, au nom de la personne connectée, et l'application applique les autorisations de cette personne et enregistre chaque modification dans l'historique de la tâche.

  • 11 outils MCP : whoami, métadonnées de l'espace de travail, projets, membres de l'équipe, sprints, recherche, détails des tâches, résumés, activité, création, mise à jour et commentaire
  • Connexion OAuth personnelle : Claude agit en tant que personne connectée, jamais via un compte partagé
  • Scopes de lecture et d'écriture séparés ; les outils en lecture seule sont marqués comme tels
  • Création et mise à jour par lot (1 à 50 tâches par appel), avec un commentaire facultatif pour chaque modification
  • Chaque modification est enregistrée dans l'historique de la tâche, avec son auteur
  • Les tokens des utilisateurs ne sont jamais transmis à l'API interne
  • Fonctionne depuis Claude comme connecteur personnalisé et depuis Claude Code
  • Déploiement Docker derrière HTTPS avec un health check

Comment nous l'avons construit

  1. 01

    La conception des outils d'abord

    Nous avons listé les tâches que chacun effectue au quotidien (trouver des tâches, résumer un projet, voir ce qui a changé, créer et mettre à jour des tâches, commenter) et les avons transformées en 11 outils précis, avec des descriptions claires, des résultats compacts et des limites par lot.

  2. 02

    Connexion personnelle avec OAuth

    django-oauth-toolkit émet les tokens et répond aux requêtes d'introspection de token. Le serveur MCP publie des métadonnées de ressource protégée, si bien que Claude trouve seul la page de connexion lorsqu'une personne clique sur Connect.

  3. 03

    Scopes de lecture et d'écriture

    La lecture utilise un scope et la modification des données un autre : une personne peut donc se connecter avec un accès en lecture seule. Les outils d'écriture refusent de s'exécuter sans le scope d'écriture.

  4. 04

    Une API interne sécurisée

    Une API interne dédiée au serveur MCP applique les autorisations de la personne pour qui il agit, consigne chaque modification dans l'historique de la tâche et n'accepte que les appels provenant du serveur MCP lui-même.

  5. 05

    Des tests, puis la production

    Des tests automatisés couvrent le serveur MCP face à une fausse application, ainsi que l'OAuth, les autorisations et l'API côté application. Nous avons ensuite déployé le serveur dans Docker derrière HTTPS et l'avons testé de bout en bout avec un vrai token avant de l'ouvrir à l'équipe.

Stack technique

  • Model Context Protocol (MCP)
  • Python
  • MCP Python SDK
  • Django
  • django-oauth-toolkit
  • PostgreSQL
  • Docker
  • nginx
  • Claude
  • Claude Code
  • Développement de serveurs MCP
  • Développement d'agents IA
  • Python et FastAPI

Questions fréquentes

Claude peut-il modifier les données de notre système via MCP ?

Uniquement si vous l'autorisez. Dans notre configuration, la modification des tâches nécessite un scope d'écriture distinct, et chaque modification est effectuée au nom de la personne connectée et enregistrée dans l'historique.

Chaque personne a-t-elle besoin de son propre identifiant ?

Oui. Chaque personne se connecte avec son compte existant, de sorte que l'IA ne voit que ce que cette personne peut voir. Il n'y a pas de clé partagée.

Pouvez-vous faire la même chose pour notre CRM, notre ERP ou notre base de données ?

Oui. Le même modèle (connexion OAuth, outils limités par des scopes, API interne qui applique les autorisations, journalisation et tests) fonctionne pour les CRM, les ERP, les bases de données et d'autres systèmes internes.

Envie d'un résultat comme celui-ci ?

Parlez à l'équipe qui a construit Connecter Claude à notre gestionnaire de tâches avec un serveur MCP distant (OAuth, Python, Django). Nous définirons le périmètre de votre projet, vous remettrons une proposition à prix fixe et vous présenterons l'exemple le plus proche de notre portfolio.

Réserver un appel stratégique