ActualitéIA

Serveurs MCP et DevOps : connecter un assistant aux outils sans lui ouvrir toute la production

Suivre Sefior sur Google

Un assistant capable de consulter un dépôt ou les journaux d’un service peut faciliter une enquête DevOps. Lui permettre de modifier une infrastructure change la nature du risque. Avant d’ajouter un serveur MCP, la question utile n’est donc pas seulement « que peut faire l’IA ? », mais quelles actions lui seront réellement permises et avec quels droits ?

MCP relie des composants, il ne remplace pas les permissions

La documentation officielle MCP décrit une architecture avec une application hôte, un client et un serveur. Le serveur expose notamment des outils, des ressources ou des prompts. Le client découvre les outils disponibles et les appelle avec des arguments structurés. Le serveur ne reçoit donc pas nécessairement une demande en langage naturel qu’il interpréterait lui-même.

Le protocole organise les échanges ; la connexion à Git, à une plateforme cloud ou à un outil interne dépend du serveur choisi. La présence d’un outil dans la liste ne démontre pas qu’il est adapté à votre environnement. Un assistant qui lit une page convertie par Markdown for Agents ne reçoit pas, pour cette raison, une autorisation d’agir sur les services décrits. Lisez son périmètre, vérifiez son origine et identifiez le compte utilisé pour exécuter ses actions.

Commencez par la lecture seule.

Pour un pilote, choisissez une tâche étroite : consulter l’état d’un déploiement de test, par exemple. Notez les données nécessaires, les résultats attendus et ce qui doit rester inaccessible. Cette délimitation donne un critère de réussite plus clair qu’une démonstration où l’assistant dispose d’un compte administrateur.

Cas d’usage proposéAccès initialContrôle avant extension
Lire un dépôtDépôt de test et lecture seuleVérifier les fichiers transmis et les exclusions.
Examiner des journauxJeu de données expurgéContrôler l’absence de secrets et de données personnelles.
Préparer une modificationProposition sans applicationRelecture humaine du changement exact.
Déclencher un déploiementPréproduction séparéeAutorisation, journal d’action et procédure de retour.

Un serveur local ne suffit pas à assurer la confidentialité

Il faut examiner le trajet complet : application hôte, modèle, serveur MCP, services appelés et stockage des journaux. Installer le serveur sur une machine interne ne dit rien, à lui seul, sur la destination des informations intégrées dans le contexte du modèle. Établissez un inventaire des flux avant d’utiliser des données de production.

Le guide de sécurité MCP traite notamment des permissions excessives, de l’exécution de serveurs locaux et de la validation des jetons. Il recommande des accès restreints et décrit les risques d’exfiltration ou de perte de données. Les résultats d’un outil doivent rester des données à examiner, pas des instructions qui autorisent une nouvelle action.

Dans notre scénario de pilote, prévoyez deux vérifications : une consultation autorisée doit réussir, et une action hors périmètre doit être refusée. Testez aussi une demande ambiguë, un service indisponible et un résultat contenant une instruction suspecte. Vous évaluez ainsi les limites, pas seulement le chemin idéal.

Avant d’étendre l’accès, désignez qui peut révoquer le compte, où les actions sont journalisées et comment revenir sur une modification. Une proposition Terraform n’est pas un déploiement : l’application du changement doit conserver les contrôles habituels de votre équipe. Si l’intégration ne permet pas de décrire ces étapes clairement, limitez-la à l’assistance en lecture.

Une fiche de validation à remplir avant l’ouverture des accès

Pour rendre le pilote vérifiable, rédigez une fiche comportant le nom du service, le compte utilisé, les opérations permises, le responsable et le moyen de révocation. Ajoutez trois exemples : une requête autorisée, une demande hors périmètre et une erreur de service. Pour chaque essai, conservez le résultat réellement observé. Une démonstration où tout réussit ne montre pas que les limites fonctionnent.

Si l’agent prépare un changement, demandez le diff exact et le test qui permettra de constater son effet. Pour une commande de déploiement, identifiez aussi l’environnement ciblé avant l’exécution. Ces contrôles restent nécessaires lorsque l’on poursuit la tâche depuis un téléphone avec Claude Code Remote Control : changer d’écran de pilotage ne réduit pas les droits du compte connecté.

Romain Delcourt

Je suis Romain Delcourt, rédacteur tech passionné par le numérique et l’intelligence artificielle. J’écris pour décoder les tendances, les outils et les changements qui façonnent nos usages au quotidien.

Voir tous les articles

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *