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.
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.
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 |
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 |
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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.