Un agent de code connaît les fichiers du projet, mais pas toujours ce que le navigateur affiche réellement. Une feuille de style peut sembler correcte dans le dépôt et casser une mise en page ; une requête peut échouer uniquement dans Safari ; un composant peut être présent dans le DOM tout en restant inutilisable au clavier.
Avec Safari 27 bêta et Safari Technology Preview 247, WebKit propose un serveur Model Context Protocol (MCP) intégré à safaridriver. Un client compatible peut ainsi observer et manipuler une fenêtre Safari locale. La nouveauté ne transforme pas Safari en assistant généraliste : elle fournit des outils de développement au modèle choisi par l’utilisateur.
Sommaire
Ce que l’agent peut réellement voir
Le serveur expose des opérations ciblées : lister et changer d’onglet, ouvrir une URL, extraire le contenu de la page, interagir avec le DOM, consulter les messages de console et les requêtes réseau, exécuter du JavaScript, prendre une capture, modifier la taille de la fenêtre ou le média CSS émulé.
modifier le code
→ charger la page dans Safari
→ observer DOM, console, réseau et rendu
→ vérifier un comportement
→ corriger ou demander une validationLe gain potentiel vient moins de l’autonomie que de la qualité du retour. Le modèle peut confronter sa modification à un navigateur réel au lieu d’inférer le rendu à partir du code.
Trois usages particulièrement solides
- Compatibilité Safari : reproduire un défaut, lire les erreurs et vérifier la correction dans WebKit.
- Accessibilité : contrôler structure, libellés, attributs ARIA, contraste et parcours interactifs, puis compléter par un test humain.
- Performance : relier chronologie réseau, ressources et mesures de navigation à une modification précise.
Les scénarios doivent formuler un résultat observable : « le formulaire refuse une adresse invalide et annonce l’erreur au lecteur d’écran » est plus vérifiable que « améliore le formulaire ».
Une configuration volontaire et locale
WebKit demande d’activer les fonctions de développement puis l’autorisation d’automatisation distante et d’agents externes. Pour Safari Technology Preview, un client lance le serveur avec "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp.
WebKit indique que le serveur fonctionne sur la machine et ne réalise pas lui-même d’appels réseau. Il n’accède pas aux informations personnelles de Safari telles que l’AutoFill ou l’activité de navigation. En revanche, le contenu capturé, les captures d’écran et les journaux sont transmis à l’agent connecté. Leur traitement dépend donc de ce client et de son fournisseur de modèle.
Le navigateur reste une frontière de sécurité
Une page est une entrée non fiable. Elle peut contenir du texte conçu pour détourner un agent, déclencher un téléchargement ou l’inciter à révéler des informations. L’accès à evaluate_javascript et aux interactions DOM augmente aussi l’impact d’une mauvaise décision.
- Utiliser une fenêtre dédiée au développement, sans session personnelle.
- Privilégier un environnement de test avec des données synthétiques.
- Limiter les secrets accessibles au processus de l’agent.
- Exiger une confirmation avant soumission, achat, publication ou modification distante.
- Conserver la trace des outils appelés et des fichiers modifiés.
- Relire les changements et exécuter la suite de tests hors du seul contexte de l’agent.
Le serveur MCP ne doit pas être exposé comme un service réseau public. Il s’agit d’un pont local vers une application dotée d’un contexte puissant.
Construire un test reproductible
Pour éviter une simple démonstration, le scénario précise l’URL de test, la taille de fenêtre, l’état initial, les actions autorisées et les assertions attendues. On conserve la capture, les erreurs console, les requêtes fautives et le diff de code comme artefacts. Un test déterministe rejoint ensuite la CI lorsque c’est possible.
Safari MCP devient alors un instrument de diagnostic et d’exploration, tandis que WebDriver et les tests automatisés restent la base reproductible de la non-régression.
Une boucle de revue qui reste humaine
Le bon usage n’est pas de demander à l’agent de « tester le site », mais de lui confier un écart précis et un périmètre fermé. Par exemple : reproduire un défaut sur une largeur donnée, relever les erreurs de console, proposer un correctif, puis vérifier les trois assertions qui comptent. Le développeur conserve la décision : il relit le diff, confirme le comportement dans le navigateur et décide si le cas devient un test durable.
- Entrée : URL, état de session et jeu de données explicitement autorisés.
- Observation : capture, console, réseau ou arbre d’accessibilité associé au constat.
- Sortie : correction limitée, assertions vérifiables et retour arrière simple.
Un retour d’expérience, pas un pilote automatique
Donner au modèle accès au rendu réel est une évolution importante pour le développement web assisté. La valeur vient d’une boucle plus courte entre hypothèse et observation. La sûreté, elle, repose toujours sur l’isolation de la session, le choix du client, la maîtrise des données transmises et la validation des effets.
