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
Pourquoi centraliser les connexions dans un broker MCP ?
Un point d'entrée commun évite les intégrations dispersées et facilite le versionnement, l'application des droits, la journalisation et le retrait d'un connecteur défaillant.
Quels critères rendent un connecteur MCP exploitable en production ?
Il doit pouvoir être versionné, audité, limité et désactivé sans casser le delivery. La connexion seule ne suffit pas si les scopes, les traces et la réversibilité ne sont pas maîtrisés.
Comment gérer les droits d'accès finement ?
Le connecteur doit rester aligné sur les droits Jira, GitHub ou Figma de l'utilisateur. L'authentification déléguée, l'absence de token partagé et la journalisation de chaque appel empêchent l'assistant d'obtenir un accès plus large que l'humain.
Dans quel ordre connecter Jira, GitHub, Figma et la documentation ?
Le plan proposé commence par Jira et GitHub, qui relient tickets, code et PR, puis ajoute Figma et la documentation. Cet ordre permet de valider les droits et les traces sur un périmètre borné avant d'élargir le contexte.
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.