Curseur pour l'AIOps : où les agents de codage IA contribuent à la réponse aux incidents (et où ils ne le font pas)

L'AIOps a connu quelques changements d'identité ces dernières années. Les tableaux de bord et les alertes de seuil sont venus en premier. Ensuite, la détection des anomalies pilotée par machine learning a eu son heure de gloire. Aujourd'hui, quelque chose de différent se produit : les ingénieurs intègrent des agents de codage IA tels que Cursor à leurs flux de travail de réponse aux incidents. Parfois, cela fonctionne. La plupart du temps, ce n'est pas le cas.

Nous comprenons pourquoi il y a confusion. L'infrastructure, c'est du code. Les incidents nécessitent généralement des correctifs au niveau du code. Avec sa compréhension de l'ensemble de la base de code et son édition agentique, Cursor semble avoir sa place dans la boîte à outils d'un SRE.

Sauf que Cursor est un agent de codage. Ce n'est pas un système AIOps. Il ne surveillera pas votre infra. Les alertes ne seront pas corrélées. N'a aucune idée que votre cluster Kubernetes est en train de fondre à moins que quelqu'un ne le lui indique explicitement.

Ce qui suit est une analyse honnête des domaines dans lesquels Cursor apporte une réelle valeur ajoutée à AIOps et des domaines dans lesquels il échoue. Si vous êtes un SRE, un ingénieur DevOps ou un responsable de plateforme qui essaie de comprendre ce qui fonctionne réellement, c'est pour vous.

Qu'est-ce que l'AIOps ?

L'AIOps (intelligence artificielle pour les opérations informatiques) existe depuis que Gartner a inventé le terme en 2017. Supprimez le marketing et tout se résume à appliquer le ML, le NLP et l'analyse des données au chaos des opérations informatiques.

Les plateformes AIOps ingèrent des journaux, des métriques et des événements, puis utilisent ces données de quatre manières :

• Détection: La détection des anomalies basée sur le ML détecte les dégradations avant qu'elles ne deviennent des boules de neige. Apprend à quoi ressemble la « normale » dans votre environnement et signale les écarts de manière dynamique
• Corrélation: regroupe des centaines d'alertes connexes en un seul incident via des moteurs de corrélation d'événements. BigPanda réduirait le bruit de plus de 95 % dans les grandes entreprises
• Automatisation: déclenche des flux de travail de remédiation prédéfinis. Redémarrez les pods, augmentez les ressources, redirigez le trafic. PagerDuty, Datadog, ServiceNow ITOM proposent tous une version de ce logiciel
• Prédiction: analyse la télémétrie historique pour prévoir les pénuries de capacité ou évaluer le risque de déploiement avant que les modifications n'affectent la production

Le marché le confirme. L'AIOps a atteint 2,23 milliards de dollars en 2025, par Fortune Business Insights, avec une projection de 11,8 milliards de dollars pour 2034. Gartner s'attend à ce que 60 % des grandes entreprises considèrent l'AIOps comme une pratique standard d'ici 2026.

Le principal point à retenir : l'AIOps concerne l'intelligence au niveau du système. « Que se passe-t-il actuellement dans mon infrastructure ? » C'est la question à laquelle il répond.

Qu'est-ce que Cursor et pourquoi intervient-il dans les conversations AIOps ?

Cursor est un éditeur de code axé sur l'IA : AnySphere a créé VS Code et l'a reconstruit autour de l'IA comme base, et non d'un plugin. Depuis mars 2026, il prend en charge GPT-5.2, Claude Opus 4.6, Gemini 3 Pro et Grok Code, interchangeables par tâche. Principales caractéristiques :

• Mode agent — sélectionne les fichiers, exécute les commandes du terminal, itère jusqu'à ce que vous ayez terminé
• Compositeur — édition de plusieurs fichiers avec prise en compte complète de la base de code
• Agents d'arrière-plan — tâches parallèles via git worktrees ou des machines distantes
• Intégrations MCP — Datadog, PagerDuty, Slack, Linear via le Cursor Marketplace

Cursor a franchi 500 millions de dollars ARR en 2025 et aurait frôlé les 2 milliards de dollars au début de 2026. Plus de 90 % des développeurs de Salesforce l'utilisent.

Pourquoi les SRE s'en soucieraient ? Parce que l'infrastructure réside dans Git. Modules Terraform, manifestes Kubernetes, pipelines CI/CD : lorsque quelque chose tombe en panne à 3 heures du matin, la solution consiste presque toujours en un changement de code. Le curseur lit le code au niveau du projet, et pas seulement le fichier ouvert. Pour un ingénieur de garde qui connaît YAML à 3 heures du matin jusqu'aux genoux, ce contexte est important.

Cependant, utile n'est pas la même chose que suffisant.

L'utilité du curseur dans les flux de travail AIOps

Le curseur ne remplacera pas les outils AIOps. Ce qu'il fait bien, c'est de combler des lacunes spécifiques dans le flux de travail de réponse aux incidents que les plateformes AIOps ne touchent pas. Cinq cas d'utilisation se démarquent :

Débogage plus rapide des problèmes de production

Collez les journaux d'erreurs dans l'agent. Le curseur lit la trace de la pile, trouve les fichiers pertinents dans la base de code et réduit la cause première avec le contexte complet du projet. Avec le Extension du curseur Datadog connecté via MCP, il extrait des journaux, des métriques et des traces directement depuis l'IDE. Aucun navigateur n'est nécessaire. Le temps entre « Je vois une alerte » et « Je comprends le chemin du code » passe de quelques minutes à quelques secondes.

Rédaction et mise à jour de Runbooks

Chaque équipe possède des runbooks. Presque toutes les équipes sont dépassées. Cursor rédige des runbooks en fonction de l'apparence actuelle de la base de code : chemins de fichiers réels, valeurs de configuration réelles, commandes réelles. Mieux encore, il met à jour les runbooks existants en signalant les références périmées et les commandes obsolètes. Cela nécessite encore un examen humain, mais la charge de maintenance diminue considérablement.

Génération de correctifs et de scripts de restauration

Dites à l'agent ce qui ne va pas, dirigez-le vers les fichiers de déploiement et vous obtiendrez des scripts de restauration, des correctifs de configuration et du code de correctif. Le Module PagerDuty MCP permet aux ingénieurs d'extraire le contexte de l'incident et les horaires d'astreinte directement dans l'éditeur. Un schéma courant : l'ingénieur détecte un mauvais déploiement, passe à Cursor, rédige un brouillon de PR d'annulation en quelques minutes.

Débogage de l'infrastructure en tant que code

Le curseur trace les définitions de ressources Terraform via des références de modules, des fichiers variables et des configurations de fournisseurs. Il détecte les erreurs d'indentation YAML, les étiquettes manquantes et les limites de ressources mal configurées que les linters au niveau des fichiers ne respectent pas. L'intégration MCP de StackGen intègre la génération d'IaC et les flux de travail de correction SRE dans l'éditeur, en s'appuyant sur les normes d'infrastructure actuelles de l'équipe.

Automatiser les tâches opérationnelles répétitives

« Écrivez un script Bash pour alterner les secrets entre le développement, la mise en scène et la production. » Fait dès la première tentative. « chaîne de commande kubectl pour boucler, vider et déconnecter un nœud en toute sécurité. » La bonne séquence, les bons drapeaux. Petites victoires individuelles ; heures récupérées chaque semaine.

Là où Cursor échoue dans l'AIOps

Les limites sont réelles. En un coup d'œil :

• Aucun contexte système en temps réel, il ne sait que ce que vous lui donnez
• Aucune corrélation d'alerte : fonctionne au niveau du code, pas au niveau du signal
• Aucune observabilité : impossible de suivre la latence, les taux d'erreur ou les modèles de trafic au fil du temps
• Pas de suivi des incidents : pas de concept de propriété, d'escalade, de SLA ou de post-mortem
• Pas de piste d'audit, pas de journal indiquant ce que l'IA a changé ni pourquoi

Le curseur vous aide à résoudre les problèmes. Il ne vous dira pas quel est le problème.

L'écart entre l'intelligence au niveau du code et l'intelligence au niveau du système

L'AIOps vous indique ce qui s'est passé. Le curseur vous indique comment y remédier. Des emplois complètement différents.

La pièce manquante ? Le lien entre la détection et la résolution. MCP y remédie : les serveurs MCP de Datadog et PagerDuty permettent à Cursor d'interroger les données de télémétrie et d'incident. Mais la plupart des intégrations sont encore en version préliminaire. La traversée des données est dirigée par l'ingénieur et n'est pas autonome. Des garanties de sécurité pour les changements d'infrastructure générés par l'IA en production ? Inexistant.

Difficultés liées à l'utilisation de Cursor pour l'AIOps à grande échelle

Quatre problèmes apparaissent lorsque vous ne vous contentez pas d'un seul ingénieur qui fait des expériences :

• Risques de sécurité — Le mode agent lit/écrit des fichiers susceptibles de contenir des secrets et des configurations IAM. Les LLM produisent un code plausible, pas nécessairement un code sûr
• Corrections hallucinées — Les suggestions semblent correctes (bonne syntaxe, chemins de fichiers réels), mais la logique est erronée. Un mauvais changement d'infrastructure n'échoue pas à un test, il passe en production
• Aucune validation — Le curseur écrit le code et le transmet. Je n'exécuterai pas de plan Terraform, je n'irai pas à l'encontre des politiques de l'OPA. La validation incombe entièrement à l'ingénieur, sous pression, à 3 heures du matin
• Aucune collaboration — Outil solo. Aucun état partagé entre les membres de l'équipe lors de la réponse à un incident

Meilleures pratiques pour l'utilisation du curseur dans les flux de travail AIOps

Six garde-corps qui comptent :

• Validez tout. plan terraform, kubectl diff, linter, politiques OPA. Traitez chaque sortie du curseur comme non fiable jusqu'à preuve du contraire
• Parcours par étapes. À chaque fois. Ne transmettez jamais les correctifs générés par l'IA directement à la production. Laissez CI/CD comprendre ce que le LLM a oublié
• Définissez les autorisations de manière stricte. Les jetons MCP doivent être en lecture seule. L'agent lit les journaux et les incidents, il n'y écrit pas
• Placez le curseur au-dessus de l'AIOps, ne le remplacez pas. Une alerte se déclenche dans Datadog → PagerDuty pages engineer → engineer opens Cursor → Cursor interroge la télémétrie via MCP → Engineer reviews and ships. Supprimez la couche AIOps et vous débuguez à l'aveugle
• Une approbation humaine pour chaque changement de production. Les agents d'arrière-plan sont parfaits pour les développeurs. C'est terrible pour le prod. L'automatisation réduit le labeur, pas la supervision
• Enregistrez les modifications assistées par l'IA dans la chronologie de vos incidents. Le curseur ne le fera pas. Développez l'habitude. Enregistrez ce que l'IA a généré par rapport à ce que vous avez écrit manuellement

Comment l'AIOps moderne évolue grâce à l'IA

L'écart entre la détection et la résolution ne restera pas aussi important. Quatre tendances à surveiller :

• La réponse aux incidents assistée par l'IA est en train de devenir une véritable catégorie de produits. L'agent AI SRE d'incident.io enquête de manière autonome sur les incidents. L'agent SRE de PagerDuty met en évidence les causes profondes et génère des playbooks à partir des résolutions historiques. Ces outils étudient, pas seulement filtrent
• La remédiation basée sur des agents est en train de quitter le stade du prototype. AWS DevOps Agent et Microsoft Azure SRE Agent mettent tous deux l'accent sur l'investigation et la recommandation, en évitant délibérément toute action autonome en phase de production
• Le MCP est en train de devenir le tissu conjonctif. Datadog, PagerDuty, Grafana et Prometheus disposent tous de serveurs MCP. La place de marché de Cursor répertorie les intégrations pour la plupart des principales plateformes d'observabilité. La connectivité est la condition préalable à tout le reste
• Les outils de développement et d'exploitation fusionnent. Les partenariats de mars 2026 de PagerDuty avec Cursor, Anthropic et LangChain indiquent la direction que prend l'industrie

Passerelle IA de TrueFoundry fournit la couche d'observabilité, de gouvernance et de routage dont les déploiements LLM de production ont besoin. À mesure que les agents d'IA jouent un rôle de plus en plus important dans les flux de travail opérationnels, cette couche de passerelle devient fondamentale : limites de taux, suivi des coûts des jetons, solutions de rechange pour les modèles, pistes d'audit pour chaque action pilotée par l'IA.

Conclusion

Le curseur accélère ce que font déjà les SRE : tracer le code, écrire des annulations, actualiser les runbooks, travailler dur. Il fait partie de la boîte à outils.

Ce qu'il ne peut pas faire : détecter les anomalies, corréler les alertes, surveiller votre infra, gérer le cycle de vie des incidents. Utilisez-le comme couche d'exécution : l'outil que vous récupérez une fois que l'AIOps vous indique ce qui ne fonctionne pas. Associez-le à Datadog, PagerDuty et MCP. Gardez toujours un humain entre le correctif généré par l'IA et la production.

Utilise les deux. N'échangez pas l'un contre l'autre.

FAQs

1. Le curseur peut-il remplacer des outils tels que Datadog ou PagerDuty, qui sont des outils AIOps ?

La réponse est un « non » définitif, car ils résolvent différents problèmes. Datadog, PagerDuty ou d'autres outils AIOps sont principalement utilisés pour identifier les problèmes en temps réel, tandis que Cursor, en tant qu'agent de codage basé sur l'IA, s'exécute dans la base de code. Il aide les développeurs à déboguer, à comprendre et même à générer du code pour résoudre un problème une fois identifié. En d'autres termes, Datadog vous indique ce qui est cassé et où, tandis que Cursor vous indique comment résoudre le problème.

2. Comment les agents de codage basés sur l'IA sont-ils utilisés pour répondre aux incidents ?

Les agents de codage IA, dont Cursor, sont de plus en plus utilisés pendant les phases de triage et de résolution d'un incident. Les développeurs saisissent les journaux, les traces de pile ou les messages d'erreur pertinents, qui sont ensuite utilisés par les agents de codage IA pour scanner l'intégralité de la base de code afin d'identifier la cause la plus probable de l'incident. En outre, les agents de codage IA sont utilisés pour générer des scripts visant à annuler le code, à générer des correctifs, à mettre à jour ou à créer des runbooks en fonction du code actuel, à suggérer des correctifs à l'infrastructure ou même à automatiser des commandes.

3. Quelle est la différence entre les outils AIOps et les agents de codage IA ?

La différence entre les outils AIOps et les agents de codage IA réside dans l'intelligence qu'ils fournissent. Les outils AIOps, dont Datadog, PagerDuty, etc., analysent les données de télémétrie pour identifier les anomalies, corréler les alertes et prévoir les défaillances d'un système distribué. D'autre part, les agents de codage IA, dont Cursor, fonctionnent au sein de la base de code pour aider les développeurs à comprendre la logique, les dépendances et la configuration de l'application pour générer du code.

En d'autres termes, les outils AIOps fournissent des informations pour identifier les problèmes, tandis que les agents de codage IA fournissent des informations pour résoudre les problèmes. L'AIOps répond à la question « Que se passe-t-il en production ? » Les agents d'IA répondent à la question « Quels changements devons-nous apporter pour y remédier ? » Nous avons besoin des deux pour obtenir une réponse complète à la question « Que s'est-il passé ? » qui fait partie d'un cycle complet de réponse aux incidents.

4. Est-il sûr d'utiliser des correctifs générés par l'IA dans les systèmes de production ?

L'utilisation de correctifs générés par l'IA dans les systèmes de production n'est pas sûre si des contrôles minutieux ne sont pas mis en place. Il existe un risque que du code « correct » mais logiquement erroné ou dangereux soit généré par l'IA. Dans les domaines liés aux infrastructures tels que Terraform ou Kubernetes, de petits changements peuvent avoir un rayon d'impact important. Certaines bonnes pratiques pour atténuer ce risque consistent à s'assurer que la validation est effectuée, à échelonner les modifications, à demander à une personne d'examiner les modifications, à disposer de journaux d'audit des modifications apportées par l'IA, etc. Il est préférable de traiter l'IA comme un copilote, et non comme un opérateur solo dans un système de production.

5. Comment le MCP (Model Context Protocol) intégre-t-il les agents AIOps et AI ?

Le MCP est un protocole qui permet de faire le pont entre les systèmes et les outils, en particulier entre les outils AIOps et les outils de codage IA tels que Cursor. Il permet à l'IA d'interroger directement des systèmes externes tels que Datadog, PagerDuty ou Slack pour obtenir un contexte pertinent tel que des journaux, des incidents, des alertes, etc. Cela réduit le besoin de changer manuellement d'outil, de copier-coller des données, ce qui est un problème courant dans le développement logiciel aujourd'hui. Cela permet à l'IA de travailler directement avec le contexte du système de production, ce qui constitue un avantage considérable, mais dans un environnement de développement. Cependant, la plupart des intégrations actuelles sont pilotées par des ingénieurs, en lecture seule, ce qui signifie que l'IA n'agit pas sur les systèmes, mais utilise plutôt les données qu'elle peut obtenir pour aider à résoudre les problèmes.

6. Quels sont les principaux risques liés à l'utilisation de l'IA dans les flux de travail DevOps ou AIOps ?

Les risques sont nombreux, mais les plus importants sont liés à une dépendance excessive à la technologie dans un environnement à enjeux élevés, tels que des solutions hallucinées, un code qui semble parfait mais qui résout le mauvais problème, etc. Manque de connaissance du système : les systèmes d'IA n'ont pas une compréhension intrinsèque de l'état actuel d'un système en temps réel, à moins qu'ils ne soient mis à leur disposition.

Risques de sécurité : l'accès aux configurations, aux secrets ou aux politiques IAM peut être mal géré

Absence d'auditabilité intrinsèque : de nombreux outils n'ont pas la capacité de suivre les modifications apportées par l'IA et les raisons qui les sous-tendent

Automatisation excessive : l'absence de validation ou de révision humaine peut entraîner des problèmes dans les systèmes de production

Pour y remédier, les équipes ont besoin de barrières, d'observabilité et de couches de gouvernance autour de l'utilisation de l'IA, plutôt que de simples modèles.