Introduction
Le pipeline CI/CD s'est considérablement automatisé ces dernières années, mais il conservait un angle mort persistant : ce qui se passe entre la validation d'une pull request et la confirmation que tout va bien en production. Cursor vient de publier deux fonctionnalités pour combler exactement ce vide, disponibles depuis le 23 septembre 2026 pour les plans Teams et Enterprise.
Rollouts : surveiller chaque changement du merge à la production
La première fonctionnalité, Rollouts, attache un moniteur automatique à chaque pull request dès son ouverture. Le bot analyse le diff, identifie les systèmes affectés et génère un plan de surveillance qu'il publie en commentaire avant le déploiement. Une fois le changement déployé, Rollouts suit son comportement en temps réel via les logs, métriques et traces remontés par les outils de télémétrie connectés — Datadog en premier lieu.
Le verdict rendu par environnement est explicite : verified healthy, regression detected ou inconclusive. Si une régression est identifiée, le bot notifie les auteurs du changement et peut déclencher automatiquement l'ouverture d'une PR de revert. L'intégration couvre GitHub et les principaux systèmes de déploiement continu, avec le support des feature flags annoncé comme prochaine étape.
Cette approche tranche avec les pratiques habituelles où la détection d'une régression dépend soit d'une alerte de monitoring déjà configurée, soit d'un utilisateur qui remonte un incident. Rollouts introduit une vérification systématique et contextuelle, liée à chaque changement individuel plutôt qu'à l'état global du système.
Security Review : la revue de sécurité à chaque PR
La seconde fonctionnalité s'attaque à un autre angle mort : la sécurité du code avant qu'il n'atteigne la production. Security Review analyse chaque pull request dans le contexte complet du codebase et produit un rapport concentré en un seul commentaire.
Les vulnérabilités ciblées couvrent un spectre large : injections SQL, de commandes et de templates, contournements d'authentification et d'autorisation, exposition de secrets ou de credentials, SSRF, redirections non validées, désérialisation non sécurisée et failles dans les dépendances. Pour chaque finding, le bot indique le niveau de sévérité, retrace le chemin d'attaque depuis le point d'entrée utilisateur jusqu'à la surface vulnérable, et propose un correctif. Les équipes peuvent par ailleurs configurer des règles personnalisées pour adapter l'analyse à leur contexte métier ou à leurs standards internes.
Le bot opère en 3,8 minutes en moyenne — une performance en amélioration de 21 % par rapport aux versions précédentes, ce qui le rend compatible avec des cadences de déploiement rapides sans créer de goulot d'étranglement.
L'enjeu derrière les fonctionnalités
Ce qui rend ces deux outils intéressants, ce n'est pas leur existence en tant que telle — la détection de régressions et la revue de sécurité existent depuis longtemps dans les pipelines DevOps bien outillés. C'est leur positionnement comme étape automatique et systématique, intégrée nativement au flux PR plutôt que gérée par des scripts d'infrastructure ou des processus manuels.
Pour les équipes de taille moyenne, souvent sans spécialiste sécurité dédié ni équipe SRE structurée, le bénéfice est double : réduire la dépendance aux configurations de monitoring ad hoc, et instaurer une première ligne de défense sécurité sans allonger le cycle de revue humaine. Les crédits d'utilisation offerts les dix premiers jours permettent de tester le dispositif sur des changements réels avant toute décision d'activation durable.
La tendance de fond est claire : le déploiement continu mûrit vers une logique de vérification continue, où chaque changement porte avec lui son propre plan d'observation et son propre audit de sécurité — sans intervention manuelle supplémentaire.