Pourquoi le contexte change tout
Un assistant IA sans contexte produit des réponses générales. Connecté à Jira, Figma, GitHub et à la documentation interne, il peut travailler sur le vrai matériau projet : tickets, maquettes, conventions, historique de décisions, code et PR.
Le contexte ne rend pas l'IA infaillible, mais il rend ses réponses vérifiables et beaucoup plus proches du travail réel.
C'est le rôle des Model Context Protocols (MCP) : exposer des sources et outils à un assistant IA de manière structurée, traçable et contrôlée.
Le MCP, sans jargon inutile
Un MCP permet à un LLM de se connecter à une source externe, par exemple Jira, Figma, GitHub ou une base documentaire, via des outils exposés par un serveur. L'objectif est d'éviter le copier-coller fragile et de donner au modèle un accès borné au contexte dont il a besoin.
Le point important n'est pas seulement la connexion. C'est le contrôle : droits, scopes, traces, limites et possibilité de couper un connecteur.
| Avant MCP | Avec MCP |
|---|---|
| Copier/coller manuel du ticket Jira | Le LLM lit le ticket en direct |
| Décrire la maquette à l'oral | Le LLM lit la frame Figma exposée |
| Recoller le diff GitHub à chaque review | Le LLM accède à la PR + à l'historique |
| Prompt long, fragile, partiel | Prompt court, requête riche |
:::
Ce que le contexte vivant change dans le delivery
Génération de specs contextualisées
L'assistant lit le ticket Jira, la maquette Figma et les conventions existantes, puis produit une spec qui :
- Utilise vos conventions de nommage
- Référence les patterns techniques déjà en place
- Détecte les impacts sur les autres modules
Code review qui connaît vos conventions internes
Une review IA connectée au contexte peut :
- Connaît vos ADR (Architecture Decision Records)
- Sait quels patterns sont préférés / interdits dans votre codebase
- Référence les PR similaires passées
Documentation qui se met à jour seule
À partir des PR mergées, l'assistant peut :
- Met à jour le changelog
- Met à jour la documentation utilisateur impactée
- Crée les release notes prêtes à publier
L'architecture qui tient quand les usages montent
Pour passer à l'échelle sereinement :
- un broker MCP central, pour éviter les connexions dispersées ;
- des connecteurs versionnés, pour savoir ce qui est en production ;
- une politique d'accès claire, alignée sur les droits humains ;
- un journal d'audit exploitable ;
- une capacité de retrait rapide si un connecteur pose problème.
Le bon connecteur MCP est celui que l'on peut auditer, limiter et désactiver sans casser le delivery.
| Composant | Rôle | Recommandation |
|---|---|---|
| Broker MCP | Point d'entrée unique | Self-hosted, derrière SSO interne |
| Connecteurs | 1 par source (Jira, GitHub...) | Versionnés en Git, déployés via CI |
| Auth | Délégation OAuth | Jamais de token partagé |
| Audit log | Traçabilité | Conservation ≥ 90 jours, alerte sur anomalie |
| Rate limiting | Protection des API tierces | Quota par utilisateur + global |
:::
Les garde-fous à poser avant d'ouvrir les connecteurs
Le MCP est puissant — donc dangereux s'il est mal cadré.
- Données sensibles : politique stricte (masquage, anonymisation, exclusion)
- Droits d'accès : alignés sur les droits Jira/GitHub des humains, pas plus larges
- Traçabilité : chaque appel MCP est journalisé
- Réversibilité : on doit pouvoir couper un connecteur sans casser le delivery
Huit semaines pour passer du prompt au contexte vivant
Un déploiement progressif peut ressembler à ceci :
- Semaine 1-2 : architecture MCP, choix des connecteurs prioritaires
- Semaine 3-4 : déploiement Jira + GitHub
- Semaine 5-6 : ajout Figma + Confluence
- Semaine 7-8 : industrialisation, monitoring, formation
Au bout de ce cycle, les équipes disposent d'un assistant qui travaille sur les bonnes sources, avec des droits et des traces lisibles.
Les questions qui reviennent avant d'ouvrir Jira, Figma et GitHub
MCP est-il un standard pérenne ?
Le protocole répond à un besoin durable : connecter les assistants à des outils et sources de manière standardisée. Comme tout standard jeune, il faut garder une architecture réversible.
Faut-il développer ses propres serveurs MCP ?
Pour Jira, GitHub, Figma ou Notion, des serveurs MCP officiels ou communautaires existent déjà. Pour vos systèmes internes, un développement spécifique reste souvent nécessaire, mais il est généralement léger.
Comment gérer les droits d'accès finement ?
La règle d'or est simple : le LLM hérite des droits de l'utilisateur, jamais de droits étendus. L'OAuth délégué est la voie standard, avec revue régulière des scopes accordés.
MCP remplace-t-il un RAG ?
Non. MCP donne accès à des données vivantes via API. Un RAG indexe et rend recherchable du contenu non structuré. Les deux sont complémentaires dans une stack mature.
Le signal qui montre si votre contexte manque déjà
Le Score VÉLOCIA mesure spécifiquement votre niveau d'intégration au contexte projet. C'est l'un des 11 piliers évalués, car un assistant non connecté reste vite limité aux tâches génériques.