Dans une analyse de 2025 portant sur plus de 100 grands modèles de langage, Veracode a constaté que Près de la moitié (45 %) du code généré par l'IA est à l'origine de problèmes de sécurité et de vulnérabilités connus. De nouveaux risques s'introduisent dans vos systèmes opérationnels plus rapidement que les humains ne peuvent les gérer ou les examiner. Parallèlement, Des études suggèrent que La relecture humaine n'est pas très efficace, surtout au-delà de 400 lignes de code. .

Mais le code généré par l'IA n'est pas fondamentalement mauvais. Il ne fonctionne simplement pas toujours sur l'ensemble du système.

Dans les environnements de microservices et cloud-native, aucun ingénieur (ou agent de développement) ne maîtrise l'état complet du système. L'agent d'un ingénieur peut générer du code fonctionnant parfaitement en développement, mais provoquant une panne d'un système en aval en production, même sans la moindre erreur de syntaxe.

La plupart des équipes tentent de résoudre ce problème par une relecture humaine manuelle, ce qui a transformé la revue de code en un nouveau goulot d'étranglement. Plutôt que de ralentir, les équipes tombent souvent dans ce qui suit : L'équipe des directeurs techniques de Google parle de « lassitude face à l'approbation » — un flux continu de micro-approbations qui engendre une lassitude de bas niveau, où les développeurs commencent à valider le code de manière réflexe.

Mais des études récentes ont montré que l'examen traditionnel du code d'IA pourrait ne pas être aussi efficace que prévu, car la capacité d'un ingénieur humain à détecter les erreurs est généralement limitée. chute après environ 400 lignes de code .

Les gains d'efficacité apportés par le code généré par l'IA sont trop précieux pour être sacrifiés au détriment de la production. Cependant, ce code est trop risqué pour être intégré au système sans une forme de vérification préalable. Comment les équipes peuvent-elles alors vérifier efficacement le code sans limiter la vitesse de leurs agents de développement ?

Les équipes les plus performantes atténuent les risques en intégrant le contexte opérationnel à leurs agents d'IA. Ainsi, ces derniers tirent des enseignements des incidents et transmettent les signaux de risque en amont, dans l'environnement de développement. Au lieu de détecter les risques après le déploiement, les développeurs peuvent identifier les problèmes avant qu'ils n'impactent la production et n'entraînent des coûts.

Voici comment ça fonctionne :

Décaler vers la gauche est la seule façon de résoudre le goulot d'étranglement du code de l'IA

Ce qui fait des ingénieurs de bons relecteurs, ce n'est pas tant leur capacité à repérer les erreurs, mais leur mémoire opérationnelle. Ils connaissent l'historique non écrit des incidents passés, les cas limites critiques et les particularités architecturales qui n'ont jamais été documentées.

Le problème, c'est que la mémoire humaine a ses limites. Personne ne peut vérifier systématiquement chaque demande de modification (PR) avec l'historique opérationnel complet d'un vaste réseau d'entreprise. Mais grâce à la technologie « shift-left », les équipes d'ingénierie bénéficient d'une visibilité inédite.

Déplacement vers la gauche cela signifie déplacer les contrôles de validation critiques plus tôt dans le cycle de vie du développement logiciel afin de détecter les problèmes alors que Le code est créé en cours de création (et non après son déploiement).

Détecter les problèmes au niveau du poste de travail avant même l'ouverture d'une demande de fusion permet d'éviter que du code défectueux ne se retrouve dans la file d'attente de révision et épargne aux réviseurs humains le travail de détective sur du code qui n'était jamais prêt à être déployé.

Les équipes d'ingénierie adoptent déjà plusieurs approches de conception qui ne nécessitent pas d'examen manuel approfondi :

• Linters et outils d'analyse statique comme ESLint ou SonarQube qui détectent les problèmes de formatage et autres erreurs évidentes.
• Tests de sécurité statiques des applications et analyseurs de dépendances comme Snyk ou Dependabot qui signalent les secrets codés en dur et les CVE connues dans les bibliothèques open-source.
• Tests unitaires et d'intégration locaux vérifier que les fonctions isolées se comportent comme prévu.

Les outils traditionnels de vérification à gauche peuvent contrôler la syntaxe et la sécurité du code, mais ils sont incapables de prédire s'il provoquera une défaillance en cascade de la base de données en situation réelle. Ces outils statiques n'ont aucune connaissance des dépendances du système en production ni des schémas de défaillance historiques ; cela requiert l'expertise et les connaissances opérationnelles des ingénieurs expérimentés.

À l'ère de l'IA, le passage à une approche plus gauche signifie intégrer la mémoire opérationnelle humaine au processus de codage lui-même.

Comment décaler vers la gauche : contextualiser le poste de travail

Pour réussir un passage à la phase de transition vers la gauche, les équipes doivent d'abord saisir automatiquement le contexte opérationnel afin de créer un système doté d'une capacité de rappel plus complète que celle de n'importe quel individu.

Les organisations doivent également rendre le contexte accessible aux développeurs dans leur environnement de travail habituel. Si la vérification des risques opérationnels nécessite l'ouverture d'un tableau de bord distinct ou la connexion à un autre outil, les développeurs ne le feront pas. L'information doit être directement intégrée au terminal ou à l'IDE.

PagerDuty redéfinit le concept de « shift left ». En connectant directement toutes vos données d'incidents passés à l'environnement de développement, PagerDuty fait évoluer les stratégies de « shift left » au-delà de l'analyse statique du code en trois étapes :

• Capture automatique des données d'incident. PagerDuty collecte en continu les données de télémétrie, l'historique de résolution, les fils de discussion et les analyses post-incident au fur et à mesure que les incidents se produisent.

• Constituer une mémoire opérationnelle structurée. L'agent SRE de PagerDuty capture les données brutes des incidents et les transforme en signaux de risque contextuels liés à des services et des fichiers spécifiques.

• Risque de surface au poste de travail. Les équipes peuvent intégrer ces signaux dans les outils de développement natifs, signalant les risques opérationnels et fournissant un score de risque avant même que le code n'atteigne la production.

Exemples modernes de dérive à gauche avec l'IA

Voici quelques exemples d'organisations qui mettent cette idée en pratique :

Intuit évalue les risques avant l'expédition

Lors d'une session à San Francisco de notre récent événement PagerDuty on Tour, Intuit L'entreprise a expliqué comment ses ingénieurs détectent les risques avant le déploiement. Lorsqu'un développeur écrit du code, un agent d'IA vérifie la modification par rapport aux services concernés, évalue l'étendue de son impact et le nombre de systèmes qui en dépendent. Il en résulte un score de risque indiquant au développeur le niveau de sécurité du nouveau code avant son déploiement.

PagerDuty se décale vers la gauche avec Claude Code et GitHub

Lors d'une session PagerDuty on Tour à Londres, PagerDuty a montré comment son nouveau Module d'extension Claude Code Ce système détecte les risques directement dans le terminal. Il repère le service sur lequel travaille le développeur, puis effectue une vérification rapide en se basant sur l'historique des incidents des 90 derniers jours et les analyses post-incident. En deux minutes environ, il signale les schémas à risque, comme l'absence de logique de nouvelle tentative ou un code similaire à un incident passé, et attribue un score de risque en indiquant les actions à entreprendre.

Pour les équipes utilisant GitHub, Agent personnalisé de réponse aux incidents de PagerDuty Cela permet d'intégrer le même contexte à la demande de fusion. Un développeur peut ainsi demander directement dans les commentaires si une modification est sans risque pour le déploiement. L'agent vérifie l'état des dépendances en temps réel et signale les problèmes non résolus des revues précédentes, ce qui permet à l'équipe de recevoir une confirmation claire de sécurité avant la fusion.

Expédiez plus rapidement. Réduisez les pannes. Passez à la vitesse supérieure avec PagerDuty.

Le codage par IA offre un gain de temps, mais la rapidité sans sécurité ne fait que déplacer le travail en aval. Pour protéger la production, les équipes ont besoin d'un moyen de repérer les erreurs de logique générées par l'IA bien avant qu'elles n'atteignent une requête de fusion.

PagerDuty , intégré à votre système de résolution d'incidents existant, détient les données opérationnelles précises nécessaires à leur prévention. En comparant le code non validé aux schémas d'incidents passés et à la topologie du système en production, PagerDuty détecte les modes de défaillance connus avant même qu'ils ne soient pleinement opérationnels.

En consacrant moins de temps à la résolution d'incidents, vos ingénieurs peuvent récupérer leur temps. Moins d'alertes et d'incidents signifient plus de temps pour les tâches à forte valeur ajoutée liées à l'architecture et à la capacité, qui font progresser votre produit.

Prêt à éliminer le goulot d'étranglement des révisions par IA ? Planifiez une démonstration de PagerDuty dès aujourd'hui pour observer le contexte opérationnel en action.