MCP connecte les agents d'IA à des systèmes réels (code, journaux, bases de données), en remplaçant les scripts de test fragiles par une boucle intelligente : génération, exécution, diagnostic et correction automatique.
Format
Si vous avez déjà essayé de faire travailler un agent IA “sérieusement” sur votre QA (test logiciel), vous avez probablement connu ça : l’IA voit un test qui échoue… et commence à improviser. Elle “devine” le contexte, propose un correctif plausible, mais qui s'avère fragile. Et dès que vous changez un détail (un sélecteur, un flux, un environnement), c'est le drame : tout s’écroule.
C’est exactement là que MCP (Model Context Protocol) change la donne : en donnant enfin aux modèles un moyen standardisé d’accéder au contexte réel (code, logs, specs, outils, environnements), MCP transforme un LLM isolé en un agent intégré. Celui-ci est alors capable de raisonner à partir de ce que votre système sait déjà (au lieu de cliquer à l’aveugle). Décryptage.
Disclaimer : MCP reste un protocole jeune. Sa valeur est déjà très tangible, mais son écosystème, ses patterns d’implémentation “standard” et ses pratiques de gouvernance/sécurité continuent d’évoluer. Autrement dit : c’est une brique prometteuse, pas une baguette magique.
Le Model Context Protocol (MCP) est un protocole standardisé conçu pour relier une application d’IA (un “host”) à des systèmes externes (données et outils) via des serveurs MCP. Il a été introduit fin 2024 par Anthropic et publié comme un standard ouvert, avec l’ambition de réduire la fragmentation des intégrations entre modèles, agents, outils et systèmes d’entreprise.
En très simple : MCP définit une façon commune pour qu’un agent IA puisse “brancher” des capacités (lire un repo Git, interroger une base, appeler un outil interne, récupérer des logs, etc.) sans devoir réécrire une intégration sur-mesure à chaque fois.
Pourquoi un “nouveau protocole” ? Parce que jusque-là, chaque équipe faisait la même chose… mais différemment : un connecteur maison pour GitHub, un autre pour Jira, un autre pour la base, un autre pour les logs, etc. À l’échelle d’une organisation, ces intégrations deviennent vite coûteuses, difficiles à sécuriser et pénibles à maintenir.
Avant MCP, connecter un LLM à une base de données ou un outil interne demandait souvent du code spécifique : SDK propriétaires, wrappers ad hoc, pipelines d’authentification différents, conventions de payload inconsistantes, et parfois des “prompts outillés” difficiles à auditer.
Résultat : un enfer d’intégrations “N×M” (chaque modèle / chaque agent / chaque outil), souvent fragiles, rarement réutilisables.
MCP vient jouer le rôle de “prise universelle” : un cadre commun pour exposer des ressources et des actions à une application d’IA, avec une structure d’échange standard. En pratique, cela permet de construire des intégrations plus réutilisables et plus faciles à gouverner.
Anthropic présente d’ailleurs MCP comme un moyen de créer des connexions “secure, two-way” entre vos data sources et des outils IA.
Le Model Context Protocol repose sur une architecture Host / Client / Server (documentée officiellement) :
Sur le plan des flux, l’idée est simple : le Host orchestre une boucle “collecter du contexte → appeler un outil → vérifier → itérer”. Le serveur MCP expose ce que l’agent est autorisé à consulter (ressources) et ce qu’il est autorisé à faire (outils).
Voici une version visuelle du fonctionnement de MCP :
[ MCP Host : app IA ] | crée un ou plusieurs | [ MCP Client ] <—— session stateful ——> [ MCP Server : outil/donnée ] | JSON-RPC + échanges de contexte/outils
Détail important : la spec décrit MCP comme un protocole stateful orienté échanges de contexte, bâti sur JSON-RPC (donc assez simple à intégrer côté engineering).
Concrètement, un serveur MCP expose généralement 2 choses : (1) des “ressources” (ex. : fichiers, pages, extraits de logs, documentation) et (2) des “outils” (fonctions/actions invocables).
L’agent (Host) orchestre ensuite une séquence : récupérer du contexte → appeler un outil → vérifier le résultat → itérer.
Point important : plus l’agent a d’accès (outils + données), plus vous gagnez en autonomie… mais plus vous devez cadrer (permissions, audit, sandbox, latence, coût, déterminisme). MCP rend l’intégration plus propre ; il ne supprime pas les arbitrages d’architecture.
Le vrai basculement n’est pas “un nouveau plugin”. MCP change la nature de l’IA :
On passe d’une IA “en vitrine” à une IA au cœur de l’OS de votre engineering (au sens : branchée aux briques qui décrivent l’état réel du système).
Et c’est précisément pour ça que l’adoption intéresse autant : la valeur vient moins du modèle “tout seul” que de sa capacité à se connecter proprement à un écosystème d’outils (IDE, trackers, CI, observabilité, design systems, etc.).
La QA n’échoue presque jamais “juste” à cause d’un clic raté. Dans un pipeline moderne, un test end-to-end qui casse est souvent le symptôme de quelque chose d’autre :
Sans le Model Context Protocol, même si vous donnez un framework puissant à l’IA (Playwright, Selenium, Cypress), l’agent reste souvent myope : il observe l’UI, il voit un message d’erreur, mais il n’a pas accès à la cause racine.
C’est exactement ce que beaucoup d’équipes vivent avec l’automatisation “script-heavy” : dès que l’UI change, les scripts deviennent fragiles et la maintenance explose. Les outils open-source type Selenium/Playwright demandent du code rigoureux et peuvent devenir fragiles. De petits changements UI suffisent alors à casser les suites.
Prenons un cas ultra banal : vous testez l’inscription d’un utilisateur. Le test vérifie que l’écran affiche “Succès”. Sans contexte, un assistant IA peut juste dire : “le message n’apparaît pas”. Et ensuite… il tâtonne.
Avec l'écosystème MCP, un agent de test peut faire mieux :
Un MCP server sert à exposer des datasets structurés (résultats d’analyse statique, couverture, doc) pour que des agents puissent raisonner et agir avec le bon niveau de contexte. Le contexte n’est ainsi pas une cerise sur le gâteau. C’est le gâteau lui-même.
Mini-exemple “contrat API” : si le test casse lors de la création de compte, l’agent peut (via MCP) récupérer la spec OpenAPI/Swagger versionnée dans votre portail interne, constater qu’un champ requis a changé (ex. : phone → phoneNumber), et expliquer l’échec comme une divergence de contrat plutôt qu’un “bug UI”.
Ce qui est intéressant ici, ce n’est pas seulement d’avoir plus d’info : c’est de pouvoir enchaîner une vraie boucle d’investigation. Autrement dit : observer → collecter le contexte → tester une hypothèse → valider. MCP sert de rail standard pour brancher cette boucle sur vos systèmes.
Soyons clairs : Playwright et Cypress sont excellents. Ils ont rendu l’E2E (test de bout en bout) plus accessible, plus stable, plus rapide à industrialiser. Playwright, par exemple, met en avant ses mécanismes d’auto-wait et ses assertions “web-first” pour réduire la flakiness.
Le problème n’est pas leur puissance. Le problème, c’est leur modèle.
Un script Playwright interagit avec :
Si le DOM change, le test casse. Et surtout : le script ne “sait” pas pourquoi ça a changé. Il n’a pas accès à l’intention produit, au commit responsable, aux discussions Jira, aux specs mises à jour, ni aux logs.
Autre cas très réel : les feature flags. Le DOM ne “change” pas partout. Il change pour un segment, un environnement, un rollout. Sans contexte, vos tests ressemblent à des alarmes qui se déclenchent au hasard. Avec MCP, un agent peut lire l’état d’un flag (ou une config d’environnement) et adapter la stratégie de test à l’état réel de déploiement.
Avec MCP, votre agent a une posture différente :
Résultat : là où Playwright demande une intervention humaine pour mettre à jour un sélecteur, l’Agent MCP peut réduire une partie de la maintenance en s’appuyant sur le contexte pour s’adapter.
Nuance importante : “réduire” ne veut pas dire “supprimer”. Dans la pratique, vous gardez des zones où l’humain garde la main (stratégie de test, exigences, seuils d’acceptation, décisions produit). MCP aide surtout à automatiser la partie la plus coûteuse : diagnostiquer et corriger les ruptures triviales ou contextuelles.
Et côté architecture, ça se traduit souvent par un pattern simple : le framework (Playwright/Cypress) reste un moteur d’exécution, tandis que l’agent (piloté par contexte MCP) devient la couche de décision. Cette séparation “exécution vs raisonnement” est un design trade-off sain : vous limitez la surface d’actions, vous contrôlez mieux le risque.
On peut parler de Model Context Protocol en théorie pendant 3 heures. Mais la QA, c’est du concret. Alors voici 3 cas d’usage qui illustrent bien ce que MCP apporte quand on le branche à un pipeline qualité.
Scénario : un test UI échoue sur une PR.
Sans MCP :
Avec MCP :
C’est l’essence de l’agentic quality : faire plus que constater, expliquer.
Limite à connaître : plus vous voulez du diagnostic “automatique”, plus la qualité de l’observabilité devient critique (corrélation traces/logs, IDs de requêtes, conventions de logging). MCP vous connecte à la donnée ; il ne la rend pas magiquement exploitable si elle est incomplète ou incohérente.
La génération automatique de tests existe depuis un moment. Mais sans contexte, ça donne souvent des suites génériques, peu alignées avec la réalité produit.
Avec MCP, l’IA peut :
C’est un exemple de cas d’usage très concret : générer des tests à partir de parcours utilisateurs, exigences produit ou maquettes, puis organiser ces cas dans des ensembles.
Si vous avez déjà vécu une release où les tests “passent” mais ne testent plus rien d’utile… vous voyez tout de suite l’intérêt.
Design trade-off : cette génération “context-aware” améliore la pertinence, mais elle impose une gouvernance documentaire (source de vérité, versioning, droits d’accès). Sinon, l’agent risque de produire des tests parfaitement alignés… sur une spec obsolète.
Un agent QA sans accès infra reste dépendant des humains.
Avec MCP, l’agent peut piloter :
Ça devient très puissant quand vous voulez :
Et c’est exactement l’obsession DevOps : réduire le temps de feedback (avec notamment une intégration directe CI/CD et un support CLI / API).
Mini-exemple “data seeding / flakiness” : si un test flake parce que la base n’est pas dans le bon état, l’agent peut déclencher (via MCP) un seed contrôlé, relancer le test, puis archiver les artefacts. Vous évitez les “rerun until green” qui masquent les vrais problèmes.
Pré-requis : pour piloter l’infra via MCP sans créer un risque, il faut généralement un périmètre clair (sandbox/staging), des permissions minimales, et un audit des actions. Les patterns ‘least privilege’ et ‘deny by default’ deviennent non négociables.
Avec Thunders, vos assistants IA peuvent contribuer directement à l’ingénierie QA : rédiger, exécuter et analyser des tests automatiquement, tout en centralisant les résultats dans votre espace Thunders.
L’intérêt du MCP Thunders, dans ce contexte, est de permettre à l’agent de travailler avec du contexte (projets, exécutions, environnements, artefacts), ce qui réduit la maintenance et améliore la capacité d’auto-diagnostic.
Pour aller plus loin et découvrir comment configurer vos agents IA, consultez notre guide complet sur Thunders MCP.
Et si vous voulez voir le produit côté plateforme, voici la plateforme d'automatisation des tests IA.
Voici également l'angle “dev & CI/CD” en tant qu’alternative à Playwright.
À noter : le vrai “game changer” n’est pas juste la génération no-code. C’est la boucle complète : générer → exécuter → diagnostiquer → corriger/adapter → rejouer, avec des métriques qui remontent en continu. C’est là que l’approche agentique se différencie des automatisations classiques.
On a tendance à imaginer “un agent IA” comme un super-employé. Dans la réalité, les architectures qui tiennent la route ressemblent plus à… une équipe.
Avec MCP, on peut aller vers des agents spécialisés qui collaborent :
C’est d’ailleurs cohérent avec la façon dont le Model Context Protocol est conçu : un host peut connecter plusieurs serveurs via plusieurs clients, ce qui facilite une IA “branchée” sur de nombreuses sources/outils tout en gardant des frontières de sécurité.
On passe progressivement d’une QA “script-centric” (des suites figées qu’on répare) à une QA “context-centric” (des agents qui raisonnent sur l’état du système). Les tests deviennent moins des artefacts statiques, et plus des comportements vérifiables qui s’adaptent au contexte et à l’intention produit.
Là où beaucoup d’outils legacy restent enfermés dans une logique “scripts + rapports”, Thunders se positionne comme une plateforme pensée pour des workflows modernes : agents, personas, intégration DevOps, analytics, sécurité enterprise.
L’idée n’est pas de jeter Playwright à la poubelle. L’idée est d’arrêter de demander à votre pipeline qualité d’être intelligent… alors qu’il n’a pas le contexte pour l’être.
→ Vous voulez voir comment ça marche concrètement ? Réservez une démo.
Whether you're getting started or scaling advanced workflows, here are the answers to the most common questions we hear from QA, DevOps, and product teams.
No. The Model Context Protocol is not a testing framework. It is a connectivity and context layer. In practice, MCP can orchestrate existing tools or expose their capabilities through an MCP server. The protocol itself is not “Selenium 2.0.” In fact, some current experiments integrate a Playwright MCP server into agent-based architectures.
The promise of MCP is to enable secure and controlled connections between AI systems and data sources or tools. However, as with any system connecting agents to operational environments, you must take seriously:
MCP security guidelines define risks and best practices. On the Thunders MCP side, connections rely on OAuth, encrypted tokens, revocable access, and permissions limited to necessary actions.
GPTs and plugins have historically been proprietary mechanisms tied to a specific ecosystem. MCP, by contrast, is presented as an open standard with a public specification. Openness does not eliminate governance and security challenges, but it significantly reduces integration fragmentation.
If you are considering MCP in a QA pipeline, four concrete prerequisites condition success:
Without these foundations, the agent is either too restricted to be useful or too powerful to be safe.
