Les agents IA en continu de Cursor sont là. Vos équipes sont-elles prêtes ?

La nouveauté

Cursor a livré jeudi une fonctionnalité appelée Automations. En résumé : plutôt qu'un développeur sollicite un agent IA à chaque besoin, Automations vous permet de définir des déclencheurs — un nouveau commit, un message Slack, une alerte PagerDuty, une minuterie — qui lancent des agents de façon autonome. Les agents s'exécutent, accomplissent leur travail, et n'impliquent un humain que lorsqu'ils rencontrent quelque chose qui nécessite un jugement.

Le responsable engineering de Cursor, Jonas Nelle, l'a formulé clairement : les ingénieurs « ne sont pas toujours à l'initiative. Ils sont appelés aux bons moments dans cette chaîne de traitement. » L'entreprise indique qu'elle fait déjà tourner des centaines de ces automations par heure sur sa propre base de code, en gérant aussi bien la détection de bugs que la réponse aux incidents ou les résumés hebdomadaires de changelog publiés sur Slack.

Les chiffres sont difficiles à ignorer. Bloomberg a rapporté cette semaine que le chiffre d'affaires annualisé de Cursor a dépassé 2 milliards de dollars, doublant en à peine trois mois. L'entreprise détient environ 25 % de parts de marché parmi les abonnés aux outils d'IA générative.

Pourquoi c'est plus important que ça n'y paraît

En surface, cela ressemble à une amélioration du workflow. Définir un déclencheur, laisser un agent s'en charger. Pratique. Mais en prenant du recul, ce que Cursor fait réellement, c'est transformer l'assistant IA de codage en infrastructure. Pas un outil qu'on ouvre et qu'on utilise. Un système qui tourne en permanence.

C'est un changement significatif. On est passé de « l'autocomplétion dans votre éditeur » à « des processus en arrière-plan qui commitent du code, reviewent des PRs, scannent les failles de sécurité et répondent aux incidents de production pendant que vous dormez. » En à peu près deux ans.

Je reviens sans cesse sur le problème d'attention. Un développeur qui gère des dizaines d'agents simultanément ne relit rien vraiment attentivement. Il approuve en masse. Automations tente de résoudre ça en étant sélectif sur les moments où il sollicite une intervention humaine. C'est un bon instinct de conception — mais cela signifie aussi que la qualité du jugement de l'automation devient critique. Si l'agent décide que quelque chose ne nécessite pas de revue humaine, et qu'il se trompe, personne ne le détecte.

Ce qu'on observe en pratique

À travers notre travail de développement web et API, nous avons suivi l'évolution des conversations autour des outils IA au cours de l'année passée. Au début, les clients voulaient savoir si l'IA pouvait accélérer le développement de fonctionnalités. Maintenant, les questions ont changé : comment gouverner ce que font les agents IA sur nos dépôts ? Qui est responsable quand une PR automatisée introduit une régression ? Comment auditez-vous ça ?

Ce ne sont pas des questions hypothétiques. Dans notre travail avec des clients enterprise, notamment ceux soumis aux exigences de conformité suisses, « c'est un agent IA qui l'a fait » n'est pas une réponse acceptable quand quelque chose tourne mal. Il faut de la traçabilité. Il faut savoir quel agent a tourné, ce qu'il a modifié, pourquoi, et qui l'a approuvé.

Le framework Automations de Cursor semble comprendre ça, au moins en partie. L'intégration PagerDuty, par exemple, interroge les logs via des connexions MCP et assemble une chronologie avant de proposer un correctif. C'est une forme de piste d'audit. Mais « une forme de » ne suffit pas dans les environnements régulés.

L'angle sécurité dont personne ne parle

Voici ce qui m'inquiète vraiment. Dans nos missions de tests d'intrusion avec des studios de jeux vidéo et des plateformes enterprise, l'un des vecteurs d'attaque les plus fréquents que nous trouvons, ce sont les processus automatisés avec des permissions excessives. Des pipelines CI/CD capables de déployer en production. Des comptes de service avec des droits admin que personne n'a revus depuis deux ans.

Les agents de codage en continu relèvent de la même catégorie de risque, avec davantage d'autonomie. Un agent capable de lire votre base de code, d'interroger vos logs de production via Datadog, d'ouvrir des PRs et de déclencher des déploiements représente une cible extrêmement attractive. Si un attaquant compromet le mécanisme de déclenchement — disons, un message Slack forgé — il obtient potentiellement un accès au niveau de l'agent sur l'intégralité de votre workflow de développement.

Automations de Cursor se déclenche actuellement depuis des messages Slack, des changements de code et des alertes PagerDuty. Chacun de ces éléments est une surface d'attaque. Quand nous configurons des outils comme Cloudflare ou Akamai pour la protection DDoS, nous cartographions toujours la chaîne complète des systèmes automatisés pouvant modifier l'état de la production. Les agents IA de codage appartiennent désormais à cette carte.

Ce que vous devriez faire maintenant

Si votre équipe utilise ou évalue des outils IA de codage avec des fonctionnalités d'automation, voici des actions concrètes à traiter cette semaine :

1. Inventoriez les permissions de vos agents. Que peut lire, écrire et exécuter chaque agent ? Traitez cela comme vous traiteriez un audit de comptes de service. Si un agent peut ouvrir des PRs et interroger des logs de production, il nécessite le même niveau de rigueur sécurité que n'importe quel outil de déploiement automatisé.

2. Définissez votre politique d'intervention humaine avant d'en avoir besoin. Ne laissez pas l'outil décider de ce qui mérite l'attention d'un humain. Votre équipe doit définir ce seuil en fonction du risque : tout ce qui touche à l'authentification, aux paiements, à la configuration d'infrastructure ou aux données utilisateurs fait l'objet d'une revue humaine. Point final.

3. Journalisez tout. Si vous faites tourner des agents qui effectuent des modifications de manière autonome, vous avez besoin de logs immuables de ce qui a été déclenché, de ce qui a été modifié et de ce qui a été approuvé (et par qui). Dans notre travail de création d'applications cloud-native pour des clients enterprise, nous câblons ça dans le pipeline CI/CD dès le premier jour. Le faire après coup, et vous passerez à côté de lacunes.

4. Traitez les intégrations d'agents comme faisant partie de votre modèle de menace. Si vous faites un quelconque audit de sécurité ou un test d'intrusion, incluez vos configurations d'agents IA. Dans nos projets iOS et Android natifs, nous avons vu des équipes verrouiller la sécurité de leur application mobile tout en laissant leur chaîne d'outils de développement grande ouverte. Le même principe s'applique ici.

La vue d'ensemble

L'espace du codage agentique évolue rapidement. Les deux principaux laboratoires d'IA ont tous deux livré des fonctionnalités concurrentes le mois dernier, et la direction est claire : les outils de codage veulent être toujours actifs, autonomes et profondément intégrés à votre stack.

C'est probablement là que les choses se dirigent. Je ne suggère pas aux équipes d'éviter ces outils. Nous utilisons nous-mêmes le développement assisté par IA, et les gains de productivité sur le code répétitif, l'échafaudage de tests et les refactorisations de routine sont réels.

Mais il y a une différence entre utiliser des outils IA et laisser des outils IA gérer votre processus de développement sans supervision. La frontière entre les deux vient de devenir plus floue. Les équipes qui traitent leurs agents IA avec la même rigueur qu'elles appliquent à n'importe quel autre système automatisé ayant accès à la production s'en sortiront bien. Celles qui ne le font pas comprendront pourquoi à leurs dépens.

Nous avons déjà vu ce schéma. Quand les pipelines CI/CD se sont généralisés, les équipes qui les ont traités comme une infrastructure critique dès le premier jour ont évité les failles de sécurité qui ont touché tout le monde quelques années plus tard. Les agents IA de codage se trouvent exactement à ce même point d'inflexion en ce moment.

Si déterminer comment gouverner les outils IA au sein de votre équipe de développement est votre problème du moment, parlons-en.