La promesse de l’IA “qui programme pour vous” s’est heurtée à une réalité tenace : 45 % des développeurs affirment que déboguer le code généré par l’IA leur prend plus de temps que de l’écrire eux-mêmes, selon la Stack Overflow Developer Survey 2025. Entre le va-et-vient des onglets, outils déconnectés et tickets qui n’aboutissent jamais en production, les équipes de développement passent encore des heures à changer de contexte, à faire du troubleshooting manuel et à appliquer des remèdes à moitié efficaces.
Dans ce contexte, New Relic — la société d’Observabilité Intelligente — a annoncé trois nouvelles intégrations avec GitHub dont l’objectif est de déployer une observabilité intelligente là où le développeur travaille déjà : le repository et le pipeline. La pièce maîtresse : une intégration IA qui correlate les vulnérabilités entre GitHub et New Relic, génère le plan de remédiation et automatise la correction avec GitHub Copilot, en intégrant un contexte d’runtime pour hiérarchiser ce qui est réellement exposé en production.
Ce package comprend également un assistant d’instrumentation qui détecte et rectifie l’absence d’observabilité au moment du déploiement (en utilisant Copilot pour ajouter la couverture directement dans les pull requests), ainsi qu’une intégration entre Service Architecture Intelligence et GitHub pour importer des métadonnées (versions, ownership, etc.) et accélérer l’adoption des bonnes pratiques. Le message est clair : moins d’outils, moins de tâches répétitives et plus d’automatisation pour les plus de 20 millions d’utilisateurs de GitHub Copilot.
Une sécurité “qui comprend” le contexte : du signal à la correction sans changer de fenêtre
Dans trop d’organisations, la sécurité des applications est un labyrinthe : données dispersées dans des silos, montagnes de tickets concernant du code qui ne s’exécute même pas et un tourbillon d’onglets qui décourage toute tentative de correction. L’intégration IA de New Relic Security RX cherche à trancher dans le vif :
- Corrélation automatique des vulnérabilités entre GitHub et New Relic, enrichie avec du contexte d’exécution (runtime et build time).
- Évaluation du risque réel : différencier l’exposition en production du bruit dans les dépôts, pour prioriser ce qui compte.
- Plan de remédiation généré en contexte : création d’un Issue GitHub avec impact, étapes de test, critères d’acceptation.
- Clôture du cercle avec Copilot : GitHub Copilot produit un pull request avec changements proposés, commentaires et toute la traçabilité nécessaire pour une résolution rapide et auditable.
L’objectif n’est pas uniquement de déployer un correctif, mais de appliquer le bon patch là où la vulnérabilité a été démontrée, avec la moindre friction pour l’équipe.
Zéro “angle mort” lors du déploiement : l’instrumentation intégrée dans le pull request
Un autre cas classique : on déploie une nouvelle fonctionnalité en production et, quand quelque chose ne fonctionne pas, il n’y a pas assez de métriques ni de traces. La nouvelle intégration de l’assistant d’instrumentation fait de GitHub Copilot un constructeur plus complet :
- Détecte l’absence d’instrumentation lors du déploiement.
- Fait appel à Copilot pour ajouter la couverture d’observabilité dans le PR concernant la nouvelle fonctionnalité.
- Ne se limite pas à produire “un bout de logique” fonctionnel : il fournit un service instrumenté de bout en bout.
Selon New Relic, Copilot ne se contente pas d’écrire le backend ; il instrumente tout le stack en ajoutant :
- APM (traces, métriques, erreurs)
- Attributs personnalisés pour la logique métier
- Une Action GitHub de Change Tracking avec New Relic
- L’agent Browser pour la visibilité du front-end
Le résultat : le même PR qui déploie la nouvelle fonctionnalité apporte aussi la visibilité nécessaire pour contrôler son comportement en production dès le départ. Fini de découvrir a posteriori qu’il manquait de visibilité.
Moins de configuration, plus de vitesse : métadonnées GitHub dans Service Architecture Intelligence
La productivité ne dépend pas uniquement du code. Sans données riches sur les déploiements, la propriété et la topologie des services, il faut plus de temps pour savoir qui contrôle quoi, où se trouve le owner ou encore ce qui impacte quoi. Grâce à l’intégration entre New Relic Service Architecture Intelligence et GitHub, les équipes peuvent importer directement ces métadonnées dans New Relic et automatiser une partie de la configuration.
Cela accélère :
- L’attribution de responsabilités (pour éviter le “ping-pong” sur Slack).
- La mise en œuvre de bonnes pratiques (conventions de tags, gestion des services, runbooks).
- L’onboarding de nouvelles personnes (avec un contexte vivant, sans se limiter à des wikis obsolètes).
Quel impact au quotidien pour le développeur ?
- Moins de changement de contexte : des insights sur la sécurité, l’observabilité et l’architecture dans GitHub, où le travail a déjà lieu.
- Moins de tâches répétitives : corrélations, plans de remédiation, ouverture d’issues et de PRs automatisés avec contexte d’exécution.
- Moins de dette d’instrumentation : la couverture est détectée et corrigée dans le même PR, et non après un incident.
- Plus de concentration sur le problème : avec données et contexte sous la main, la résolution redevient de l’ingénierie.
Pour les organisations souffrant de outilsprawl (trop d’outils et d’onglets), la valeur ajoutée est évidente : consolidation sur une plateforme unifiée d’Observabilité Intelligente qui collecte la télémétrie, apporte du contexte et déclenche des actions.
Et la sécurité ? Corriger “ce qu’il faut” sans paralyser l’équipe
L’approche de Security RX adresse deux douleurs très courantes :
- Fausse urgence : listes interminables de vulnérabilités dans du code inerte. L’intégration utilise le contexte d’exécution pour distinguer l’exposition réelle du bruit.
- Paralysie par la complexité : trop d’étapes, trop d’outils. Ici, le plan de remédiation est automatiquement créé sous forme d’Issue GitHub avec impact, tests et critères d’acceptation ; Copilot prépare le PR avec commentaires et références.
L’équipe peut ainsi consacrer moins de temps à faire du triage et à chercher du contexte, pour se concentrer sur la résolution des risques réels en production.
Copilot, en “constructeur de solutions”, et pas seulement générateur de snippets
Les annonces reflètent une évolution naturelle du rôle de GitHub Copilot : de générateur de code à constructeur de solutions intégrant observabilité et sûreté dès la conception. Au lieu de se limiter à produire un fragment “qui compile”, l’assistant propose un service complet :
- Doté d’télémétrie prête à l’emploi
- Avec des changements tracés en déploiement
- Assurant une traçabilité pour les audits et post-mortems
- Plus, un plan de remédiation quand une vulnérabilité réelle apparaît
Pour les organisations cherchant à réduire le downtime et à accélérer les releases tout en limitant le risque, cette convergence code-observabilité-sécurité est la voie évidente.
Moins d’outils, moins de coûts cachés
La “taxe de toil” du développement moderne ne réside pas uniquement dans le temps. Chaque outil supplémentaire entraîne :
- Des coûts directs accrus (licences)
- Plus de friction (apprentissage, permissions, gouvernance)
- Plus d’ops (intégrations brisées, transferts)
- Plus d’erreurs humaines
Une plateforme unifiée d’Observabilité Intelligente — qui correlate vulnérabilités, amène la visibilité au PR et mappe architecture et propriété — réduit cette charge. Les nouvelles intégrations de New Relic + GitHub visent justement cette direction : automatisation là où ça fait mal, contexte là où travaille l’équipe.
Disponibilité et contexte
New Relic présentera ces capacités lors de GitHub Universe 2025 (stand #403 à San Francisco) accompagné d’un blog technique détaillé. Comme pour toute feuille de route, la société rappelle que l’annonce inclut des déclarations prospectives et que les fonctionnalités et calendriers peuvent évoluer.
Bonnes pratiques pour en profiter dès le jour un
- Activer Security RX avec Copilot sur une application pilote et mesurer le MTTR (temps de résolution) avant/après.
- Intégrer l’instrumentation assistant dans votre modèle de PR : chaque PR concernant du code doit apporter de l’observabilité.
- Importer des métadonnées GitHub dans Service Architecture Intelligence pour normaliser ownership et cycles de déploiement.
- Définir des politiques : quelles vulnérabilités sont corrigées automatiquement (avec quels tests), lesquelles nécessitent une revue, comment valider les PR générés par Copilot.
- Fermer la boucle : utiliser Change Tracking lors des déploiements pour corréliser versions, métriques et erreurs. La visibilité reste le meilleur rempart contre le “ça fonctionne en staging”.
Résumé
- Intégration IA + Security RX : corrélation des vulnérabilités entre GitHub et New Relic avec contexte d’runtime, création d’issues et génération de PRs avec Copilot.
- Assistant d’instrumentation : détection et résolution de l’absence d’instrumentation lors du déploiement ; ajout de APM, attributs personnalisés, Change Tracking et agent Browser dans le PR.
- Architecture et ownership : Service Architecture Intelligence + GitHub pour importer des métadonnées et automatiser la configuration.
- Objectif : moins de tool sprawl, moins de toil, moins d’downtime ; plus d’automatisation, plus de contexte, plus de developer velocity dans le même workflow.
Foire aux questions
Comment New Relic décide-t-elle de remédier automatiquement à des vulnérabilités avec Copilot ?
L’intégration de Security RX corrèle les découvertes de GitHub et New Relic avec contexte d’exécution pour prioriser ce qui est exposé en production. Ensuite, elle crée un Issue avec impact, tests et critères, puis propose un PR avec Copilot. Chaque équipe contrôle quels vulnérabilités sont corrigées automatiquement et lesquelles nécessitent une revue.
En quoi consiste l’assistant d’instrumentation dans le PR et que rajoute-t-il précisément ?
Lorsqu’il détecte des points aveugles d’observabilité, il fait appel à GitHub Copilot pour instrumenter toute la stack dans le PR : APM pour le backend, attributs métier, une Action GitHub pour le Change Tracking avec New Relic, et l’agent Browser pour la visibilité du front-end.
Que permet l’intégration de Service Architecture Intelligence avec GitHub pour la gouvernance des services ?
Elle permet d’importer directement des métadonnées (déploiements, propriété, relations) dans New Relic, ce qui accélère l’assignation des responsables, facilite l’adoption des bonnes pratiques et simplifie l’onboarding. Avec Change Tracking, il devient plus simple de lier les releases aux métriques et erreurs.
Comment cela s’intègre-t-il dans la stratégie de réduction du tool sprawl et de la surcharge pour le développeur ?
En intégrant une observabilité intelligente dans GitHub, en automatisant le triage et la remédiation, et en assurant une couverture instrumentale complète dès le PR, on diminue les changements de contexte, on évite les tâches répétitives et on concentre les efforts sur la livraison de valeur. Moins d’onglets, plus de flot fluide.
Source : newrelic
Le « durcisseur » d’Ubuntu qui gagne des adeptes : comment fonctionne le script de Konstruktoïd pour sécuriser les systèmes systemd de haut en bas