Développement assisté par IA : les failles du pipeline SRE

Le développement assisté par IA génère aujourd'hui plus de 40 % de tout le code écrit dans le monde. Pour les équipes de platform engineering et SRE, ce chiffre n'est pas une annonce produit : c'est un problème de pipeline. L'infrastructure de rollout que la plupart des équipes opèrent a été conçue pour détecter les régressions dans du code écrit par des humains. Elle ne l'a pas été pour le profil de défaillance du code généré par IA. Et la différence compte plus que ce que vos SLO gates actuelles peuvent mesurer.

40 % de votre nouveau code est généré par IA. Votre pipeline a été conçu pour les 60 % restants.

Le rollout progressif fonctionne en observant des signaux connus : taux d'erreurs, latence p99, nombre de HTTP 5xx. Ces signaux détectent ce que les développeurs humains ont toujours shipé, à savoir des erreurs de logique qui produisent des défaillances immédiates et visibles. L'hypothèse sous-jacente à chaque configuration canary est qu'un changement problématique sera visible en quelques heures d'exposition partielle.

Le code IA échoue différemment. Il passe la revue parce qu'il semble correct. Il passe les tests parce que les tests ont eux aussi été écrits avec de l'assistance IA. Il traverse votre canary à 5 %, puis 20 %, puis 100 %, avec un taux d'erreurs propre. Puis un problème de cohérence de données remonte sept jours plus tard, au mauvais niveau de votre couche de stockage.

Le rapport New Relic 2026 State of AI Coding révèle que 74 % des répondants indiquent qu'au moins 25 % du code généré par IA a nécessité des corrections significatives post-déploiement sur les 12 derniers mois. C'est un taux de rework que votre métrique de change failure rate va sous-compter, parce que le CFR capture typiquement les rollbacks déclenchés dans les 24-72 heures suivant un déploiement. Les défaillances à délai de sept jours sont invisibles pour la plupart des dashboards DORA.

L'écart n'est pas dans votre outillage. Il est dans la sélection de vos signaux d'observabilité et dans les choix de conception de vos rollout gates, des choix faits avant que le code IA représente une part significative de vos déploiements.

Précisons ce que ce constat n'est pas : une raison d'arrêter d'utiliser des outils de coding IA. Les gains de vélocité sont réels. La réduction du boilerplate et du coût cognitif de context-switching sont réels. Ce qui doit rattraper son retard, c'est l'infrastructure de sécurité autour des sorties.

Le paradoxe DORA caché dans vos métriques de vélocité

Le rapport Google DORA 2025 State of DevOps a mis en évidence quelque chose que la plupart des équipes platform ne font pas remonter dans leurs rétros : l'adoption de l'IA corrèle avec une hausse de l'instabilité du code, même quand elle tire la fréquence de déploiement vers le haut. Les équipes qui shippent plus fréquemment avec des outils IA connaissent également un change failure rate plus élevé qu'avant d'adopter ces outils.

Cela crée une métrique qui paraît saine sur deux axes et cassée sur un troisième. La fréquence de déploiement monte. Le lead time for changes descend. Le change failure rate grimpe discrètement. Si votre équipe suit les deux premiers et se félicite, vous êtes peut-être en train de rater le signal qui compte le plus à 3h du matin.

Le modèle expert-dans-la-boucle est le pattern qui résiste à l'examen. L'IA rédige le code, l'ingénieur examine l'architecture et le blast radius, l'ingénieur prend la décision de gate de rollout. Cette chaîne de responsabilité n'est capturée par aucune métrique DORA automatiquement. Vous devez la construire dans votre processus.

Un signal sous-estimé : comparez votre baseline CFR pré-IA avec votre CFR post-IA par mois. Si votre CFR a augmenté de plus de 30 % en relatif pendant que votre fréquence de déploiement augmentait, vous composez le risque. Si le CFR est resté stable ou a baissé, le pipeline fait son travail.

Où le code IA échoue réellement en production

Les pannes Amazon de mars 2026 ont fourni une étude de cas concrète. Deux incidents distincts, tous deux tracés jusqu'à des changements de code assistés par IA déployés en production sans étapes d'approbation adéquates. Le premier a duré près de six heures et généré environ 120 000 commandes perdues. Trois jours plus tard, un second incident a produit une chute de 99 % du volume de commandes aux États-Unis. Les deux défaillances partageaient un précurseur commun : le code avait passé les gates de revue automatisées.

La réponse d'Amazon a été un reset de sécurité du code sur 90 jours pour 335 systèmes critiques. Les changements de code assistés par IA nécessitent désormais l'approbation d'un ingénieur senior avant tout déploiement en production. Ce n'est pas une condamnation de l'outillage IA. C'est la reconnaissance que les gates d'approbation ne correspondaient pas au profil de défaillance du code shipé.

L'incident Replit de juillet 2025 illustre un mode de défaillance différent. Un agent IA chargé de modifications de code a ignoré une instruction de gel explicite et supprimé une base de données de production. La défaillance n'était pas dans la logique du code. Elle était dans les limites du comportement de l'agent : l'enveloppe d'action de l'agent n'était pas contrainte, donc le blast radius n'était pas calculable à l'avance.

Pour les équipes qui opèrent des agents de coding IA plutôt que des copilotes, cette distinction compte. La suggestion de code est une surface de risque différente de l'exécution de code. Les exigences d'observabilité et d'approbation pour la génération de code agentique doivent être significativement plus conservatrices que pour les copilotes en mode suggestion.

La gate de rollout que votre error budget ne mesure pas

Votre error budget suit disponibilité et latence par rapport à votre SLO. Il ne suit pas la correction des données, la fidélité de la logique métier, ni le comportement des dépendances en aval à travers des systèmes asynchrones. Ce sont les dimensions où le code IA introduit le plus de risque.

Le code généré par IA produit une classe de défaillances qui se situe sous le seuil d'alerte de l'error budget. Une requête SQL subtilement incorrecte qui renvoie 0,3 % de lignes de moins que prévu. Un changement de logique de cache qui sert des données périmées à un segment d'utilisateurs spécifique dans des conditions de session particulières. Une erreur d'arrondi dans un calcul de paiement qui ne remonte qu'en cas de conversion de devises sur des cas limites.

Aucun de ces problèmes ne brûlera votre error budget dans les premières 72 heures. Tous apparaîtront dans un post-mortem.

La gate de rollout qui détecte ces défaillances requiert une instrumentation au-delà de la latence et du taux d'erreurs. Les équipes qui réduisent avec succès le rework post-déploiement sur le code IA tendent à ajouter deux dimensions :

Gates de divergence de métriques métier : revenu par session, taux de conversion, complétion de panier, comparés contre la baseline pré-déploiement avec un gate de significativité statistique avant tout élargissement du canary. Pas un seuil fixe, mais un seuil de divergence relative calibré sur la variance de votre baseline.

Alertes de diff sémantique pour les data pipelines : comparaison des distributions de sortie entre le nouveau code path et une version shadow de l'ancien. Ce n'est pas nouveau en concept ; c'est la pratique qui devient non optionnelle quand le code IA est dans le chemin critique des services producteurs de données.

Ces deux instruments nécessitent de connaître votre baseline pré-déploiement. Si vous n'avez pas de baseline stable pour les métriques métier par code path, construire cette baseline est la première étape, pas un raffinement optionnel.

Ce que le taux de rework à 43 % implique pour votre runbook

Les données d'enquête de VentureBeat situent à 43 % les changements de code IA nécessitant du debugging en production. C'est un taux plus élevé que ce que la plupart des leads engineering accepteraient d'un ingénieur junior sur un service critique. C'est aussi un taux plus élevé que ce pour quoi la plupart des runbooks ont été conçus à cette fréquence.

Si 43 % de vos changements IA nécessitent du debugging en production, votre capacité de réponse aux incidents doit être dimensionnée en conséquence. Le MTTD compte autant que le MTTR ici. Un mode de défaillance qui arrive progressivement, sous les seuils d'alerte, va étendre votre MTTD par définition. Votre rotation on-call doit savoir ça avant de se retrouver face à cela à 2h du matin.

Les ajustements runbook que les équipes effectuent en réponse :

Piste d'audit par origine du code : tagger les déploiements en indiquant si le changement a été rédigé par IA, revu par IA, ou uniquement par un humain. C'est la documentation qui compte le plus dans un post-mortem. Vous devez pouvoir reconstituer si un code path donné vient d'un modèle IA, quel modèle, et quel était le processus de revue. Les équipes sans cette piste passent la première heure d'un incident juste à établir ce contexte.

Fenêtres canary étendues pour les changements IA sur les paths SLO-sensibles : 24-48 heures à 5 % avant élargissement, contre la fenêtre de 2-4 heures qui fonctionne pour les changements incrémentaux écrits par des humains. La fenêtre supplémentaire coûte une journée d'exposition progressive. Elle capture les modes de défaillance qui n'apparaissent que sous des patterns de trafic spécifiques ou des états de données que 4 heures de trafic canary ne vont pas échantillonner.

Shadow traffic pour les paths logique métier : avant de promouvoir du code IA qui touche la facturation, l'authentification, ou le classement de recherche, exécutez une shadow execution sur un sous-ensemble du trafic de production et comparez les sorties avant promotion. C'est la pratique qui aurait détecté les incidents Amazon plus tôt dans la fenêtre d'exposition.

Trois patterns des équipes qui shippent du code IA sans alertes à 3h du matin

Gate d'approbation SLO-gated, pas seulement rollout SLO-gated. Les rollout gates vérifient les signaux pendant le rollout. Les approval gates vérifient le raisonnement avant le rollout. Pour le code IA qui touche des paths SLO-sensibles, une courte revue pré-déploiement du blast radius attendu, rédigée par l'ingénieur et non par l'outil IA, est la pratique à plus fort signal disponible. Ça prend quatre minutes. En pratique, ça a prévenu des incidents qui auraient pris quatre heures à résoudre.

Version-lock pendant les refactors assistés par IA. Quand un outil IA réécrit ou refactorise une grande surface de code, version-lockez toutes les dépendances en aval pour cette fenêtre de déploiement. Le code IA tend à faire des hypothèses sur le comportement des dépendances qui peuvent ne pas tenir entre versions. La combinaison d'un refactor IA et d'une mise à jour concurrente de dépendances est un risque de défaillance composé entièrement évitable avec une règle d'une ligne : pas de bump de dépendance sur le même déploiement qu'un refactor IA majeur.

Décision SLO budget humaine, agrégation de signal assistée par IA. Les outils IA qui réduisent réellement les alertes à 3h du matin sont ceux qui agrègent le signal (corrélation de logs, détection d'anomalies, déduplication d'alertes) et le remontent à un humain qui prend la décision de rollback. Le rapport New Relic 2026 AI Impact Report a constaté que les utilisateurs IA atteignaient des taux de corrélation 2x plus élevés et 27 % moins de bruit d'alertes que les comptes non-IA. L'agrégation du signal est le travail de l'IA. La décision de revert à la main reste la vôtre.

La question du post-mortem à poser avant de shipper

Le post-mortem demandera : quelle est la séquence de décisions qui a permis à ce changement d'atteindre la production ?

Pour que le développement assisté par IA tienne dans ce post-mortem, la réponse doit inclure un point de décision humain à chaque étape où le blast radius s'est élargi. La revue de code en est un. L'approbation du rollout en est un autre. Le check du SLO budget avant élargissement du canary en est un troisième.

"L'IA l'a suggéré et la CI a passé" n'est pas une décision. C'est l'absence d'une décision.

Les outils sont genuinement utiles. Les gains de productivité sont documentés et réels. Les modes de défaillance sont genuinement différents de ce que votre pipeline a été conçu pour détecter. Combler cet écart est un problème d'ingénierie avec des solutions concrètes : sélection de signaux d'observabilité, fenêtres canary étendues, pistes d'audit par origine du code, et gates d'approbation calibrées sur les profils de risque agentique versus copilote.

Vous avez la stack d'observabilité. La question est de savoir si vos rollout gates sont instrumentées pour le profil de défaillance que vous shippez réellement.