Discussion :

[Stéphane le calme]

Hooks, règles d’équipe, sandbox : avec la version 1.7, Cursor donne davantage de contrôle aux développeurs sur les actions de l'IA
qui peut désormais contrôler le navigateur

Cursor continue d’avancer dans sa vision d’un environnement de développement centré sur l’agent. Avec la version 1.7, l’éditeur franchit un cap en donnant aux développeurs non seulement plus de fluidité dans leur travail quotidien, mais aussi davantage de contrôle et de gouvernance sur les actions de l’IA. L’objectif est clair : réduire les interruptions, renforcer la sécurité et introduire une véritable programmabilité de l’agent.

L’une des évolutions majeures réside dans la possibilité pour l’agent d’interagir avec le navigateur. Désormais, il peut analyser une interface, prendre des captures d’écran ou aider à diagnostiquer des problèmes côté client. Cette intégration rapproche encore davantage le travail du développeur front-end et back-end. Autre avancée notable : l’autocomplétion de prompts. Le système propose en temps réel des compléments pertinents lors de la rédaction d’une instruction, ce qui rend la formulation plus rapide et plus fluide. Le développeur se concentre sur l’essentiel sans se perdre dans des détails répétitifs.

L'agent peut contrôler un navigateur Web pour tester des applications, vérifier l'accessibilité, convertir des conceptions en code, etc. Grâce à un accès complet aux journaux de la console et au trafic réseau, Agent peut déboguer les problèmes et automatiser des workflows de test complets.

L'automatisation du navigateur n'est actuellement pas disponible pour les clients professionnels. Cette fonctionnalité est disponible pour les utilisateurs individuels et les équipes.

Intégration native

Agent affiche les actions du navigateur telles que les captures d'écran et les actions dans le chat, ainsi que la fenêtre du navigateur elle-même, soit dans une fenêtre séparée, soit dans un volet intégré.

Nous avons optimisé les outils du navigateur pour les rendre plus efficaces et réduire l'utilisation des jetons, ainsi que :

• Gestion efficace des journaux : les journaux du navigateur sont écrits dans des fichiers que Agent peut rechercher et lire de manière sélective. Au lieu de résumer les sorties détaillées après chaque action, l'agent ne lit que les lignes pertinentes dont il a besoin. Cela permet de conserver le contexte complet tout en minimisant l'utilisation des jetons.
• Retour visuel avec des images : les captures d'écran sont intégrées directement à l'outil de lecture de fichiers, de sorte que l'agent voit réellement l'état du navigateur sous forme d'images plutôt que de se fier à des descriptions textuelles. Cela permet de mieux comprendre les dispositions visuelles et les éléments de l'interface utilisateur.
• Invites intelligentes : l'agent reçoit des informations supplémentaires sur les journaux du navigateur, notamment le nombre total de lignes et des extraits d'aperçu, ce qui l'aide à prendre des décisions éclairées sur les éléments à inspecter.
• Reconnaissance des serveurs de développement : l'agent est invité à détecter les serveurs de développement en cours d'exécution et à utiliser les ports appropriés au lieu de démarrer des serveurs en double ou de deviner les numéros de port.

Les hooks : la vraie révolution de cette version

La grande nouveauté reste l’introduction des hooks, encore en phase bêta. Ils permettent d’intercepter et de personnaliser le comportement de l’agent à différents moments de son exécution. Concrètement, il devient possible de bloquer certaines commandes, de masquer des secrets, de déclencher un outil interne après une modification de fichier ou encore de consigner les actions de l’agent pour audit.

Cela marque un changement profond : l’agent n’est plus une boîte noire, il devient programmable et extensible. Les entreprises peuvent ainsi intégrer leurs propres règles de sécurité, automatiser des tests ou enrichir leurs pipelines CI/CD en fonction des besoins.

Hooks (bêta)

Vous pouvez désormais observer, contrôler et étendre la boucle Agent à l'aide de scripts personnalisés. Les hooks vous permettent de personnaliser et d'influencer le comportement de l'Agent lors de l'exécution.

Utilisez les hooks pour auditer l'utilisation de l'Agent, bloquer des commandes ou supprimer des secrets du contexte. Cette fonctionnalité est encore en version bêta et nous serions ravis de connaître votre avis.

Comprendre la logique des hooks

Les hooks fonctionnent comme des “points d’interception” dans le cycle de vie de l’agent. Chaque événement déclenche l’appel d’un processus externe qui reçoit des données JSON en entrée et renvoie une sortie structurée pour influer sur le comportement de l’agent.

Parmi les événements disponibles, on retrouve notamment :

• beforeShellExecution : s’exécute avant qu’une commande ne soit envoyée au shell.
• beforeReadFile : intercepte une tentative de lecture de fichier.
• afterFileEdit : se déclenche après la modification d’un fichier par l’agent.
• beforeMCPExecution : agit avant l’appel à une ressource via le Model Context Protocol.
• stop : hook final qui s’exécute quand l’agent termine une tâche.

Chaque hook est défini dans un fichier de configuration (par exemple cursor.hooks.json) et pointe vers un script ou une commande externe.

Nous pouvons imaginer plusieurs scénarios :

Exemple 1 : sécuriser les commandes shell

Imaginez que vous ne souhaitiez jamais que l’agent exécute un rm -rf en dehors d’un dossier de test. Vous pouvez intercepter toutes les commandes shell et appliquer un filtre :

Code json :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
{
  "hooks": {
    "beforeShellExecution": {
      "command": "node ./hooks/check-shell.js"
    }
  }
}

Puis, dans hooks/check-shell.js

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
const fs = require("fs");
 
let input = "";
process.stdin.on("data", chunk => (input += chunk));
process.stdin.on("end", () => {
  const data = JSON.parse(input);
  const cmd = data.command;
 
  if (cmd.includes("rm -rf") && !cmd.includes("/tmp/safe")) {
    process.stdout.write(JSON.stringify({ block: true, message: "Commande dangereuse bloquée." }));
  } else {
    process.stdout.write(JSON.stringify({ allow: true }));
  }
});

Résultat : toute commande potentiellement destructrice sera bloquée par défaut, sauf si elle cible un dossier explicitement autorisé.

Autres exemples

Il est possible de faire un audit automatique des modifications de fichiers. Un hook afterFileEdit peut servir à lancer un formateur ou consigner les changements dans un fichier de log. Il est question ici d’imposer automatiquement le style de code et de garder une trace de toutes les interventions de l’agent.

Vous pouvez également masquer les secrets avant lecture. Un hook beforeReadFile peut intercepter la lecture de fichiers sensibles et remplacer les secrets par des placeholders avant que l’agent ne les voie. Ainsi, l’agent garde le contexte des fichiers sans jamais avoir accès aux vraies clés API ou mots de passe.

Vous pouvez aussi passer aux scénarios avancés pour équipes :

• Conformité organisationnelle : interdire certains patterns de code ou de commandes via des hooks partagés dans un dépôt d’équipe.
• Automatisation de pipeline : déclencher un test ou une analyse statique après chaque modification générée par l’agent.
• Observabilité : créer un hook stop qui envoie des métriques (durée, fichiers modifiés, commandes exécutées) vers un système interne de monitoring.
• Personnalisation par projet : définir des hooks spécifiques selon le langage ou le type de service (exemple : lancer ESLint sur un projet JS mais Black sur un projet Python).

Des règles d’équipe et un contrôle accru

La version 1.7 introduit aussi un mécanisme de règles d’équipe. Les organisations peuvent désormais définir des politiques communes qui s’appliquent à tous les développeurs. Cela permet d’harmoniser l’utilisation de l’agent, d’éviter des écarts de pratiques et d’imposer un cadre cohérent, notamment pour les revues de code ou la gestion de bugs.

Les prompts deviennent par ailleurs partageables grâce à des liens directs. Cette fonctionnalité simplifie la diffusion de workflows ou de modèles de requêtes au sein d’une équipe, et réduit les efforts liés à la documentation interne.

Sécurité et multimodalité renforcées

La gestion des terminaux gagne en sécurité grâce à une exécution en sandbox. Les commandes suspectes peuvent être isolées et relancées uniquement si l’utilisateur l’autorise explicitement. Cela limite le risque de manipulations non désirées.

L’agent peut désormais exploiter directement des images présentes dans le projet. Qu’il s’agisse de diagrammes ou de schémas techniques, ces visuels deviennent partie intégrante du contexte de travail et peuvent être utilisés pour orienter la génération ou la refactorisation de code.

Une expérience de “vibe coding” plus fluide

Cursor 1.7 ne se limite pas aux grandes nouveautés : l’éditeur a aussi corrigé de nombreuses frictions qui interrompaient le flux de travail. Le suivi des agents se fait maintenant depuis une barre de menu discrète, ce qui évite de basculer constamment entre fenêtres. Le contexte du chat est mieux géré, notamment lors du partage de code ou de sorties de terminal. L’expérience globale devient plus fluide et moins intrusive.

Une avancée prometteuse mais à manier avec prudence

Si cette version ouvre des perspectives considérables, elle s’accompagne aussi de nouveaux défis. Les hooks, bien que puissants, ajoutent de la complexité et nécessitent une maintenance continue. Leur documentation reste incomplète et leur stabilité doit encore être éprouvée. Les organisations devront donc adopter une approche progressive : commencer par les fonctionnalités simples et sécurisées, puis expérimenter avec des hooks ciblés avant de généraliser leur usage.

Vers un futur où l’agent est programmable et gouverné

Cursor 1.7 marque le début d’une nouvelle phase : celle où l’agent n’est plus seulement un assistant réactif mais une véritable plateforme programmable. Les développeurs individuels y trouveront une expérience plus fluide et plus naturelle, tandis que les équipes pourront imposer des règles de sécurité et de conformité adaptées à leurs besoins. Cette évolution prépare un futur où le développement logiciel sera de plus en plus hybride : un dialogue permanent entre humains et agents, dans un cadre maîtrisé et extensible.

Cursor 1.7 ouvre une nouvelle ère du développement assisté par IA : l’agent devient programmable et gouverné. Les hooks transforment l’outil en plateforme, où chaque équipe peut imposer ses règles, automatiser ses workflows et renforcer sa sécurité. Pour un développeur expérimenté, cela signifie plus de pouvoir, mais aussi plus de responsabilité : il ne s’agit plus seulement de “laisser l’agent coder”, mais de concevoir un véritable écosystème où l’IA travaille dans un cadre défini par l’humain.

Source : Cursor

Et vous ?

Les hooks vont-ils vraiment démocratiser la programmabilité des agents ou créer une nouvelle dette technique difficile à maintenir ?

Jusqu’où peut-on confier à un agent le contrôle du navigateur et du terminal sans risquer des dérives de sécurité ? Les règles d’équipe suffisent-elles pour garantir la conformité dans des environnements sensibles (finance, santé, défense) ?

Le partage de prompts via des liens va-t-il professionnaliser l’onboarding des développeurs ou encourager des usages trop standardisés ?

Les agents doivent-ils rester des assistants passifs ou devenir des plateformes extensibles à part entière ? Cursor 1.7 annonce-t-il un futur où les EDI seront remplacés par des environnements “agent-first” ?

Comment comparer l’approche de Cursor à celle d’éditeurs concurrents (Copilot Workspace, Claude Code, Gemini Code Assist) ?

La sécurité apportée par les terminaux sandboxés est-elle suffisante pour convaincre les grandes entreprises encore frileuses vis-à-vis des agents IA ?