# Flux de travail d'intégration (/fr/docs/verdent-for-vscode/advanced-features/integrations)
> Modèles pratiques pour intégrer Verdent avec des outils et services externes
### Ce que vous allez apprendre [#ce-que-vous-allez-apprendre]
Des flux de travail d'intégration pratiques combinant des sous-agents personnalisés, des règles et des serveurs MCP pour des scénarios de développement réels.
***
## Méthodes d'intégration [#méthodes-dintégration]
| Méthode | Idéal pour | Configuration |
| ----------------------------- | -------------------------------------- | ------------------------------ |
| **Sous-agents personnalisés** | Tâches spécialisées assistées par IA | `~/.verdent/subagents/*.md` |
| **Règles (AGENTS.md)** | Standards et comportement d'équipe | Racine du projet `AGENTS.md` |
| **Serveurs MCP** | Outils externes conformes au protocole | `.mcp.json` (racine du projet) |
**Philosophie :** Combinez ces méthodes pour créer des flux de travail complets adaptés à vos besoins.
***
## Modèles d'intégration courants [#modèles-dintégration-courants]
### Flux de travail de développement de base de données [#flux-de-travail-de-développement-de-base-de-données]
**Pile technique :** Sous-agent réviseur de migrations + standards AGENTS.md + serveur MCP PostgreSQL
**Sous-agent :**
```markdown
---
name: migration-reviewer
description: Reviews database migrations for safety
---
Checks: Destructive operations, reversibility, indexing, blocking operations
```
**AGENTS.md :**
```markdown
## Database Standards
- All migrations reviewed by @migration-reviewer
- Test on staging before production
- Include rollback procedures
```
**MCP :** Serveur PostgreSQL pour l'exécution de requêtes, l'inspection de schémas, la validation des migrations
**Flux de travail :** Écrire la migration → @migration-reviewer valide → MCP teste en environnement de préproduction → documentation de la PR
***
### Développement API sécurisé [#développement-api-sécurisé]
**Pile technique :** Auditeur de sécurité + règles AGENTS.md + outil de test API personnalisé
**Composants :**
* **Sous-agent :** `@api-security-auditor` - Validation des entrées, injection SQL, authentification, limitation de débit
* **Règles :** Tous les points de terminaison exigent une revue de sécurité, limitation de débit sur les APIs publics
* **Outils externes :** Tests automatisés des points de terminaison et analyses de sécurité via une intégration personnalisée
**Résultat :** Revue de sécurité automatique avant l'approbation de la PR.
Les outils de test API et d'analyse de sécurité peuvent être intégrés via des implémentations de serveur MCP personnalisées ou d'autres méthodes d'intégration selon votre outillage.
***
### Accessibilité front-end [#accessibilité-front-end]
**Pile technique :** Auditeur d'accessibilité + règles WCAG + intégration Lighthouse
**Flux de travail :**
```
Create component → @a11y-auditor reviews → Lighthouse tests accessibility → Rules enforce >90 score
```
Lighthouse et d'autres outils d'accessibilité peuvent être intégrés via des serveurs MCP personnalisés ou une intégration dans le pipeline CI/CD selon votre flux de travail.
***
## Exemples de configuration MCP [#exemples-de-configuration-mcp]
### Comprendre MCP [#comprendre-mcp]
**Le Model Context Protocol (MCP)** est un protocole ouvert qui standardise la façon dont les applications fournissent du contexte aux LLMs. Les serveurs MCP sont des exécutables qui implémentent ce protocole. Ce ne sont pas des connexions à des bases de données ni des points de terminaison API, mais des programmes qui s'exécutent et communiquent via JSON-RPC 2.0.
**Concepts clés :**
* **Serveurs MCP** : Exécutables (paquets Node.js, scripts Python, etc.) qui implémentent le protocole MCP
* **Configuration** : Indique à Verdent comment démarrer le serveur (`command` + `args`)
* **Communication** : Les serveurs gèrent leur propre logique métier (requêtes, appels API, etc.)
### Configuration de base [#configuration-de-base]
**Emplacement :** `.mcp.json` à la racine du projet
```json PostgreSQL Server
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/myapp_dev"
]
}
}
}
```
```json GitHub Server
{
"mcpServers": {
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
```
```json Multiple Servers
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/myapp_dev"
]
},
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
```
**Explication :**
* `mcpServers` - Clé de premier niveau requise pour la configuration MCP
* `command` - Exécutable à lancer (généralement `npx` pour les paquets Node.js)
* `args` - Arguments passés à la commande (nom du paquet, chaînes de connexion, etc.)
* `env` - Variables d'environnement pour l'authentification/la configuration
### Multi-environnement [#multi-environnement]
```json
{
"mcpServers": {
"postgres-dev": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"${DEV_DATABASE_URL}"
]
},
"postgres-staging": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"${STAGING_DATABASE_URL}"
]
},
"postgres-prod": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"${PROD_DATABASE_URL}"
]
}
}
}
```
**Bonne pratique :** Utilisez des variables d'environnement pour les chaînes de connexion afin de sécuriser les identifiants. Les serveurs MCP gèrent le comportement en lecture seule en interne selon leur implémentation. Consultez la documentation spécifique de chaque serveur pour les options de contrôle d'accès.
**En savoir plus sur MCP :**
* [Spécification du Model Context Protocol](https://modelcontextprotocol.io/specification)
* [Registre de serveurs MCP](https://mcp.so/servers) - Parcourez les serveurs MCP disponibles
* [Serveurs MCP officiels](https://github.com/modelcontextprotocol) - PostgreSQL, GitHub, système de fichiers, et plus encore
***
## Intégration à l'espace de travail [#intégration-à-lespace-de-travail]
### Configuration spécifique au projet [#configuration-spécifique-au-projet]
**Configuration :**
1. Stockez à la racine du projet : `.mcp.json`
2. Validez dans le contrôle de version pour le partage en équipe
3. Les membres de l'équipe utilisent automatiquement les serveurs MCP du projet
**Exemple de microservices :**
```json
{
"mcpServers": {
"users-db": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/users"
]
},
"orders-db": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5433/orders"
]
}
}
}
```
Pour des services supplémentaires comme Kafka, vous aurez besoin d'une implémentation de serveur MCP compatible. Le registre officiel de serveurs MCP sur [mcp.so/servers](https://mcp.so/servers) recense les serveurs communautaires disponibles.
***
## Collaboration en équipe [#collaboration-en-équipe]
### Standards AGENTS.md partagés [#standards-agentsmd-partagés]
Validez dans le contrôle de version pour assurer la cohérence à l'échelle de l'équipe :
```markdown
# AGENTS.md
## Code Review Process
- Run @code-reviewer before PR
- Address all security warnings
- Minimum 80% test coverage
## Integration Requirements
- @migration-reviewer for database changes
- @api-security-auditor for new endpoints
- @a11y-auditor for UI components
## MCP Servers
- Use postgres-staging MCP server for queries
- Never use postgres-prod MCP server for exploratory queries
```
**Avantages :** Comportement cohérent, standards appliqués, contrôles qualité automatiques.
***
## Coordination multi-agents [#coordination-multi-agents]
### Flux de travail pour une fonctionnalité complexe [#flux-de-travail-pour-une-fonctionnalité-complexe]
**Exemple :** Nouveau point de terminaison de paiement
```
1. Developer request → 2. Main agent generates code →
3. @api-security-auditor reviews security →
4. @migration-reviewer validates schema →
5. MCP tests on staging →
6. Main agent generates tests and PR
```
**Résultat :** Point de terminaison entièrement revu avec les bonnes pratiques de sécurité et de base de données appliquées.
***
## Bonnes pratiques d'intégration [#bonnes-pratiques-dintégration]
### Adoption progressive [#adoption-progressive]
**Phase 1 :** Règles de base
```markdown
## Code Standards
- Use TypeScript strict mode
- Run tests before commit
```
**Phase 2 :** Ajouter un sous-agent spécialisé
```markdown
## Code Review
- Run @security-reviewer before PR
```
**Phase 3 :** Intégrer MCP
```markdown
## Database Access
- Use MCP postgres-staging for queries
```
### Combinaisons stratégiques [#combinaisons-stratégiques]
| Combinaison | Objectif | Exemple |
| -------------------- | ----------------------------------------------------------- | -------------------------------------------------------------- |
| Règles + sous-agents | Les règles définissent *quand*, les sous-agents *analysent* | AGENTS.md : « Réviser avec @security-reviewer » |
| Règles + MCP | Les règles précisent *quels* serveurs, MCP *y accède* | AGENTS.md : « Utiliser uniquement db-staging » |
| Sous-agents + MCP | Le sous-agent utilise MCP pour des *données externes* | L'auditeur de sécurité interroge les points de terminaison API |
### Bonnes pratiques de documentation d'équipe [#bonnes-pratiques-de-documentation-déquipe]
Lorsque vous documentez les intégrations pour votre équipe, incluez :
* **Sous-agents personnalisés** : listez le nom, l'objectif et le moment d'invocation de chaque sous-agent
* **Règles AGENTS.md** : documentez les règles avec une justification expliquant le « pourquoi » de chaque standard
* **Serveurs MCP** : décrivez l'objectif, le niveau d'accès (lecture seule/écriture) et le moment d'utilisation de chaque serveur
* **Flux de travail d'intégration** : fournissez des exemples de flux de travail montrant comment les composants fonctionnent ensemble
* **Dépannage** : documentez les problèmes courants propres à votre configuration et leurs solutions
Validez la documentation d'intégration avec vos fichiers `.mcp.json` et `AGENTS.md` afin que les nouveaux membres de l'équipe puissent rapidement comprendre votre configuration.
***
## Dépannage [#dépannage]
**Problème :** Le sous-agent ne s'invoque pas comme prévu
**Vérifiez :**
**Emplacement** : le fichier existe à `~/.verdent/subagents/[name].md`
**En-tête YAML** : syntaxe valide avec les champs requis `name` et `description`
**Politique d'invocation** : correspond à l'usage (le mode strict exige une mention @ explicite)
**Description** : la `description` de l'agent décrit précisément quand le sous-agent doit être utilisé
**Redémarrage** : essayez de redémarrer Verdent pour recharger les définitions des sous-agents
***
**Causes courantes :**
* Faute de frappe dans le nom du fichier du sous-agent ou dans la mention @
* Syntaxe YAML invalide dans l'en-tête
* La `description` du sous-agent ne correspond pas au contexte de la tâche
**Problème :** Les règles AGENTS.md ne sont pas appliquées
**Vérifiez :**
**Emplacement** : le fichier se trouve à la racine du projet
**Syntaxe** : Markdown valide sans erreur d'analyse
**Style des directives** : utilisez des commandes précises (« Toujours utiliser... » plutôt que « Essayer de... »)
**Session** : démarrez une nouvelle conversation pour tester l'application des nouvelles règles
**Conflits** : vérifiez si les règles utilisateur écrasent involontairement les règles du projet
***
**Causes courantes :**
* AGENTS.md dans le mauvais répertoire (doit être à la racine du projet)
* Instructions vagues que l'IA interprète différemment
* Règles appliquées mais résultats non conformes aux attentes (affinez la formulation)
**Problème :** Le serveur MCP échoue au démarrage ou à la connexion
**Vérifiez :**
**Syntaxe** : `.mcp.json` contient du JSON valide (utilisez `jq` pour valider)
**Structure** : la clé requise `mcpServers` est présente au premier niveau
**Configuration du serveur** : chaque serveur a `command` et `args` correctement spécifiés
**Paquet** : le paquet du serveur MCP est accessible (`npx` télécharge les paquets automatiquement ; l'indicateur `-y` contourne l'invite de confirmation)
**Environnement** : les variables de l'objet `env` sont correctement définies dans votre shell
**Autorisations** : l'exécutable du serveur possède les autorisations d'exécution appropriées
***
**Causes courantes :**
* Faute de frappe dans le JSON (virgule manquante, crochet non fermé)
* Nom de paquet erroné dans le tableau args
* Variables d'environnement manquantes ou incorrectes
* Réseau/pare-feu bloquant l'installation du paquet via npx
***
**Étapes de débogage :**
1. Valider le JSON : `cat .mcp.json | jq .`
2. Tester la commande manuellement : `npx -y @modelcontextprotocol/server-postgres "postgresql://..."`
3. Vérifier l'environnement : `echo $GITHUB_TOKEN`
4. Consulter les journaux Verdent pour des messages d'erreur précis
***
## Voir aussi [#voir-aussi]
Vue d'ensemble complète des méthodes d'extension
Détails du Model Context Protocol