Safari MCP Server : WebKit branche Safari sur vos agents IA de code

Le 1er juillet 2026, WebKit a publié Safari Technology Preview 247. Une ligne du changelog va retenir l'attention de tous les développeurs qui travaillent déjà avec un agent IA au quotidien : l'arrivée du Safari MCP server, un serveur Model Context Protocol officiel qui connecte Safari à votre agent, que ce soit Claude Code, Codex, ou tout autre client compatible MCP.

Concrètement, votre agent peut désormais ouvrir une vraie fenêtre Safari, regarder ce qui s'affiche, lire la console, inspecter le réseau, et corriger le code en connaissance de cause. Fini le cycle « je décris le bug, je colle une capture d'écran, je croise les doigts ». On regarde ce que le serveur expose, comment l'installer, et ce que ça change face à l'équivalent côté Chrome.

Le MCP et Safari Technology Preview, en deux mots

Le Model Context Protocol (MCP) est un protocole ouvert qui permet à un agent IA de piloter des outils externes de façon standardisée : un serveur MCP expose une liste de fonctions, l'agent les appelle selon ce dont il a besoin. C'est déjà le mécanisme derrière la plupart des intégrations GitHub, base de données ou système de fichiers des agents de code actuels.

Safari Technology Preview, de son côté, est la version expérimentale de Safari sur laquelle Apple fait atterrir en premier les futures fonctionnalités WebKit, avant leur passage en version stable. C'est là, en version 247, que le Safari MCP server fait ses débuts.

Ce que le serveur expose concrètement à votre agent

WebKit publie la liste complète des outils disponibles : il y en a dix-sept, qu'on peut regrouper en trois familles.

• Navigation et gestion d'onglets : create_tab, close_tab, list_tabs, switch_tab, navigate_to_url, wait_for_navigation, page_info.
• Inspection de la page : get_page_content, evaluate_javascript, page_interactions (clic, saisie, défilement, survol, appui clavier), screenshot, set_viewport_size, set_emulated_media.
• Réseau, console et dialogues : list_network_requests, get_network_request, browser_console_messages, browser_dialogs.

Avec ces dix-sept outils, un agent peut reproduire quasiment tout ce qu'un développeur fait à la main dans l'inspecteur : ouvrir la page, cliquer sur un bouton, lire l'erreur en console, vérifier le code retour d'un appel API, comparer le rendu à différentes tailles d'écran ou en émulation d'impression.

Installer le serveur sur votre poste

Trois étapes avant de brancher quoi que ce soit :

1. Installer Safari Technology Preview.
2. Dans Safari, ouvrir Réglages, Avancé, puis activer « Afficher les fonctions pour développeurs web ».
3. Toujours dans Réglages, section Développeur, activer « Enable remote automation and external agents ».

Avec Claude Code, une seule commande suffit :

claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

Avec Codex, la commande suit la même logique :

codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

Pour tout autre client compatible MCP, il suffit d'ajouter l'entrée suivante dans votre mcp.json ou config.json :

"safari-mcp-stp": {
  "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",
  "args": ["--mcp"]
}

Le nom safari-mcp-stp n'a rien d'obligatoire, vous pouvez l'appeler simplement safari. Une fois branché, inutile de rédiger un prompt détaillé : une demande simple comme « trouve les bugs de mon site dans Safari » ou « vérifie l'accessibilité de mon site dans Safari » suffit à le déclencher.

Les cas d'usage qui font gagner du temps

WebKit met en avant cinq usages concrets, et ils couvrent l'essentiel du travail front-end quotidien :

• Développement en Safari : votre agent voit directement comment le code rend, sans que vous ayez à décrire l'écran.
• Compatibilité : il inspecte les styles calculés, la mise en page, et compare au comportement attendu, sans changer de fenêtre.
• Performance : il exécute du JavaScript sur la page pour extraire des métriques de navigation et de temps de chargement des ressources, et repère ce qui ralentit le site.
• Accessibilité : il repère les libellés manquants, les attributs ARIA mal posés, les problèmes de contraste.
• Vérification d'état : il contrôle l'état d'un formulaire, interroge un élément via un sélecteur, confirme le déroulé d'un tunnel de commande.

Le scénario type ressemble à ceci : vous signalez un bug remonté sur Safari, l'agent ouvre la page concernée, lit la console et le réseau, identifie deux bugs distincts, propose de les corriger. Vous validez, il enchaîne. Tout ça sans quitter votre terminal.

Autre point à noter : WebKit précise que le serveur tourne entièrement en local, qu'il ne fait aucun appel réseau de son côté, et qu'il n'a pas accès à vos données personnelles dans Safari (remplissage automatique, historique de navigation). Ce que le serveur capture (contenu de page, captures d'écran, journaux de console) part directement vers l'agent que vous utilisez, pas vers Apple. Ce qui en est fait ensuite dépend de l'agent et du modèle choisis, donc de la même vigilance que pour tout outil auquel vous donnez accès à votre navigateur.

Face au Chrome DevTools MCP : deux approches complémentaires

Google propose depuis quelque temps son propre serveur MCP pour piloter Chrome via DevTools. La logique est proche (donner à un agent l'accès à un vrai moteur de rendu plutôt qu'à une simulation), mais les deux serveurs ne couvrent pas le même terrain. Chrome tourne sur Blink, Safari sur WebKit : deux moteurs, des comportements CSS et JavaScript parfois différents, donc deux sources d'information distinctes pour un agent chargé de valider un rendu.

Pour une équipe qui teste presque exclusivement sur Chrome, ce qui reste courant sur les projets français, le Safari MCP server n'est pas un concurrent à choisir à la place de l'autre. C'est le chaînon qui manquait pour couvrir automatiquement le rendu WebKit, sans installer une suite de tests cross-browser payante ni ouvrir manuellement un simulateur.

Notre lecture chez CZSyn

Sur nos projets clients, la compatibilité Safari reste un point de friction classique : beaucoup de PME développent et testent sur Chrome, et découvrent les problèmes WebKit une fois le site en ligne, via un retour client agacé. Un outil qui permet à l'agent de vérifier lui-même le rendu Safari avant la mise en production, sans effort supplémentaire côté développeur, comble un vrai manque dans le workflow, pas un gadget de plus.

On retient surtout la promesse de bouclage rapide : signaler un bug en une phrase, laisser l'agent creuser dans le vrai navigateur, valider la correction, sans ouvrir soi-même l'inspecteur. C'est exactement le genre de gain de temps qui compte pour une petite équipe qui n'a pas de temps à consacrer aux tests manuels multi-navigateurs.

Un bémol tout de même : le serveur est pour l'instant réservé à Safari Technology Preview, pas encore à la version stable, et suppose un poste macOS. Pour les équipes qui développent ailleurs, la vérification Safari devra encore passer par d'autres moyens en attendant que l'outil descende dans Safari grand public. En attendant, brancher ce serveur en complément d'un équivalent Chrome DevTools MCP donne à un agent une vision des deux moteurs de rendu majeurs du marché, probablement la meilleure configuration possible aujourd'hui pour du débogage front-end assisté par IA.

Sources primaires

• WebKit Blog, « Introducing the Safari MCP server for web developers », 1er juillet 2026.
• Apple Developer, page officielle de Safari Technology Preview.
• Model Context Protocol, documentation officielle du protocole.