AI-translated from English; not yet reviewed by a fluent editor.

# L’écriture de code par l’IA fait de la livraison fiable le prochain défi d’ingénierie

> Lorsque l’IA augmente la production de code, les responsables d’ingénierie doivent savoir où les modifications attendent, combien coûte leur validation et si les logiciels livrés se comportent comme prévu.

By BIG CHANGE Editorial

Published: 2026-09-22T05:31:05.772Z
Updated: 2026-09-22T05:31:05.772Z
Canonical: https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery

![A large stack of blank work cards waits on a conveyor before a magnifying-glass inspection station, with a smaller stack in the output tray.](https://bigchange.ai/api/media/file/validation-queue-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. More proposed changes can put pressure on validation. Conceptual illustration of a queue and inspection stage; stack sizes are not measurements, and passing checks does not guarantee dependable delivery.

Un agent de codage par l’IA peut terminer une modification alors que les vérifications portant sur la précédente sont toujours en cours. Pour un responsable d’ingénierie, cela crée une distinction délicate : l’équipe a produit davantage de code, mais le client n’a encore rien reçu.

Linear fournit un exemple utile. Dans un compte rendu d’ingénierie du 21 septembre, Mufeez Amjad indique que les suites de tests ont presque quadruplé depuis le début de 2026, tandis que l’attente de l’intégration continue pour les demandes de fusion est passée de plus de six minutes à un peu plus de cinq. Le temps d’exécution des runners par test a approximativement diminué de moitié. Il s’agit de progrès distincts ; ce dernier chiffre ne signifie pas que la facture totale d’intégration continue a diminué de moitié. Linear attribue à l’assistance du développement par agents la pression croissante exercée sur la validation, mais son compte rendu n’est pas une expérience contrôlée démontrant l’effet de productivité de l’IA. [Compte rendu d’ingénierie de Linear](https://linear.app/now/ci-bottleneck-reworked).

L’intégration continue, ou CI, exécute des vérifications automatisées sur les modifications logicielles proposées. Elle se situe entre une modification plausible et celle qu’une équipe est prête à accepter. Lorsque le codage par l’IA augmente le nombre de modifications proposées, la capacité de vérification devient un enjeu commercial : quelle quantité de travail utile l’organisation peut-elle absorber en toute sécurité ?

À notre avis, les responsables devraient rendre visibles ensemble trois résultats : le délai avant d’obtenir des commentaires fiables, le volume total de calcul et la fiabilité des modifications publiées. Une réponse plus rapide n’est utile que si l’équipe comprend ce qu’elle permet d’établir.

## Une attente plus courte peut nécessiter davantage de travail

Imaginons une suite de tests qui représente douze minutes de travail sur une machine. La répartir uniformément entre quatre machines pourrait ramener ce temps à trois minutes. Cet exemple hypothétique suppose un équilibrage parfait et fait abstraction de tout le reste. Les machines effectuent toujours douze minutes de travail au total.

Ajoutons maintenant une minute de préparation à chaque machine. La version à quatre machines prend quatre minutes et consomme seize minutes de runner. La version à une machine prend treize minutes et en consomme treize. Le temps d’attente diminue fortement tandis que la consommation totale des machines augmente. Les frais réels dépendent aussi du type de runner, des tarifs et des règles de facturation.

Cette distinction compte lorsqu’un tableau de bord célèbre une barre verte plus courte. En achetant de la capacité parallèle, un responsable paie pour obtenir plus tôt des retours, éventuellement à un coût supplémentaire. Ce compromis peut être excellent s’il supprime une véritable contrainte. Il est plus difficile à justifier lorsque la modification terminée attend ensuite des heures qu’un réviseur soit disponible.

L’unité d’analyse devrait dépasser une seule exécution d’intégration continue. Une modification qui entraîne des révisions répétées, des relances et un deuxième cycle de révision peut exiger bien plus de travail que ne le laisse penser sa meilleure durée d’exécution. Comptez les tentatives nécessaires à l’acceptation d’une modification, y compris celles qui sont abandonnées. Sinon, un processus apparemment efficace peut masquer un développement coûteux.

Toute minute d’attente ne correspond pas non plus à un coût de main-d’œuvre équivalent. Un développeur qui entreprend une autre tâche utile pendant l’exécution des vérifications n’a pas nécessairement perdu tout cet intervalle. Les interruptions répétées et la reprise de travaux inachevés peuvent tout de même nuire à l’équipe. Pour mesurer ces effets, il faut observer son fonctionnement réel au lieu de multiplier les minutes écoulées par les salaires.

## Les études montrent un tableau contrasté

L’analyse de DORA de mars 2026 rapporte deux ensembles de données distincts. Ses recherches de 2025 associaient une adoption plus importante de l’IA à la fois à une plus grande capacité de livraison logicielle et à une plus grande instabilité. Séparément, des chercheurs ont analysé 1 110 réponses libres d’ingénieurs de Google recueillies au troisième trimestre 2025. Les ingénieurs ont décrit une aide à la rédaction et à d’autres tâches, ainsi que des vérifications supplémentaires. Cette étude qualitative interne ne concerne pas la population à l’origine de l’association générale de DORA, et ni l’une ni l’autre n’établit que l’IA a causé les problèmes de livraison d’une équipe particulière. [Analyse et méthodologie de DORA](https://dora.dev/insights/balancing-ai-tensions/).

Il existe aussi des preuves expérimentales plus solides, mais de portée plus restreinte. En juillet 2025, METR a mené une étude randomisée portant sur 246 tâches réparties entre 16 développeurs expérimentés de logiciels libres travaillant dans des dépôts qu’ils connaissaient bien. Avec les outils d’IA du début de 2025, la réalisation des tâches a pris 19 % plus de temps. Les participants pensaient néanmoins que l’IA les avait aidés à travailler plus vite. Ce résultat porte sur ces développeurs, ces tâches et ces outils ; il ne peut pas trancher l’utilité de tous les agents de codage disponibles aujourd’hui. [Expérience originale de METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).

En février 2026, METR a déclaré que son étude de suivi produisait une estimation non fiable des effets actuels sur la productivité. Les développeurs refusaient de plus en plus les tâches sans IA ou choisissaient celles qu’ils proposaient ; la présence simultanée de plusieurs agents compliquait aussi la mesure du temps. Les chercheurs jugeaient plausible une accélération plus importante, mais estimaient que les données n’apportaient que de faibles éléments sur son ampleur. Répéter l’ancien chiffre de ralentissement sans cette réserve induirait les lecteurs en erreur. [Étude de suivi de METR](https://metr.org/blog/2026-02-24-uplift-update/).

Pour un responsable, ces études justifient une approche pratique : conserver les outils utiles, examiner leurs effets et éviter de transformer l’enthousiasme ou le scepticisme en règle universelle de dotation en personnel. Une équipe peut gagner beaucoup de temps sur une catégorie de tâches et en perdre sur une autre. Son processus de livraison doit rendre cette différence visible.

## Apportez à chaque contrainte son propre remède

Avant d’acheter davantage de capacité d’intégration continue, suivez une modification, de sa première proposition jusqu’à sa mise en production. Distinguez le travail en cours du temps d’attente. Repérez la vérification qui retarde réellement une décision, le réviseur dont l’intervention est nécessaire et les conditions de publication qui restent à satisfaire.

Un relevé simple des délais suffit souvent à révéler un investissement mal orienté. Si la majeure partie du délai précède le début de la révision, gagner quelques secondes sur les tests ne résoudra pas le problème. Si les réviseurs attendent régulièrement une longue vérification obligatoire, l’améliorer a un objectif direct. Si les défaillances surviennent surtout après le déploiement, l’équipe doit examiner ce que les validations ne détectent pas.

La mise en cache des dépendances illustre pourquoi une optimisation familière doit être mesurée. GitHub décrit le cache comme un moyen de réutiliser des fichiers coûteux à recréer sur des runners vierges. L’entreprise indique également que les tâches doivent pouvoir recréer ou télécharger ces fichiers si le cache est indisponible. Il faut donc évaluer le comportement du cache aussi bien lorsqu’il est utilisé que lorsqu’il ne l’est pas. [Documentation de GitHub sur la mise en cache des dépendances](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching).

Pour le responsable, la question utile est de savoir si les retours deviennent plus prévisibles. Une excellente moyenne peut coexister avec des attentes occasionnelles assez longues pour perturber une publication. Suivez la partie la plus lente de la distribution et distinguez un échec légitime d’un test d’un téléchargement raté ou d’un manque de runners. Chacun exige une réponse différente.

Des retours fiables et rapides donnent aux personnes comme aux agents une occasion plus précoce de corriger les erreurs. Améliorer cette infrastructure commune peut bénéficier à de nombreux types de développement logiciel, y compris aux modifications écrites sans IA. C’est une raison de la financer, même si le choix des outils de codage évolue.

![One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.](/api/media/file/elapsed-aggregate-work-inline-v1.png)

## Les tests plus rapides doivent toujours détecter les erreurs

Certaines améliorations de performances modifient les conditions dans lesquelles un test s’exécute. Cela mérite un examen plus attentif que le simple fait de choisir un processeur plus rapide.

Vitest, un outil de test pour JavaScript et TypeScript, isole par défaut les fichiers de test afin d’empêcher l’état d’un fichier d’affecter celui d’un autre. Sa documentation décrit une désactivation sélective de l’isolation pour les tests adaptés, tout en signalant les états de modules modifiables, les variables globales modifiées et d’autres dépendances comme des raisons de conserver cette isolation. Un réglage qui réduit le temps de préparation peut donc modifier une limite de correction. [Recommandations de Vitest sur l’isolation](https://vitest.dev/guide/recipes/disable-isolation).

Linear a réservé le partage d’état aux cas où il était activé explicitement, a ajouté un nettoyage et conservé l’isolation pour les fichiers qu’il ne pouvait pas déplacer sans risque. Le gain de performance dépendait de sa capacité à déterminer quels tests pouvaient partager cet environnement sans danger. [Mise en œuvre chez Linear](https://linear.app/now/ci-bottleneck-reworked).

Un agent qui écrit à la fois une modification et ses tests pose un autre problème. Imaginons une règle de réduction qui ne s’applique qu’aux abonnements annuels. Un agent pourrait, à tort, l’appliquer aussi aux forfaits mensuels, puis écrire des tests confirmant sa propre interprétation. Le succès de ces tests prouverait que le logiciel est cohérent avec l’erreur.

Un réviseur a besoin de preuves ancrées hors de cette mise en œuvre : l’exigence convenue, des exemples du comportement attendu et des cas qui devraient échouer. Demander davantage de tests à un agent peut aider, mais un nombre supérieur de tests ne prouve pas à lui seul qu’une exigence mal comprise a été remise en question. Il incombe aux humains de décider ce que le logiciel doit faire et si les preuves répondent bien à cette question.

Les équipes qui récompensent le volume de tests sans examiner ce qu’ils démontrent risquent de fournir aux réviseurs davantage de matériel, mais moins de confiance. Un responsable devrait prévoir du temps pour cet examen au moment d’attribuer le travail, au lieu de traiter cette étape comme un retard inexplicable après la fin du travail de l’agent.

## Mesurez les changements qui parviennent aux clients

Les indicateurs de livraison de DORA offrent une vérification utile en aval. Ils comprennent le délai entre la validation du code et sa mise en production, la fréquence des déploiements, le rétablissement après un déploiement raté, la proportion de déploiements exigeant une intervention immédiate et celle des déploiements correspondant à des retouches imprévues liées à des incidents. Ils décrivent les résultats de livraison au-delà d’une exécution de tests réussie. [Définitions des indicateurs de DORA](https://dora.dev/guides/dora-metrics/).

Pour examiner le processus de codage par IA d’une équipe, nous associerions ces résultats à un petit nombre de mesures diagnostiques :

- Retours : temps écoulé jusqu’aux vérifications requises, y compris les exécutions longues et l’attente d’une capacité disponible.
- Consommation : travail total des runners et tentatives répétées liées à une modification acceptée.
- Révision : temps d’attente avant examen, révisions importantes demandées et raison de chacune.
- Impact client : le changement publié a-t-il produit le comportement prévu et exigé des travaux correctifs ?

Utilisez ces données pour examiner un processus particulier. Une petite modification de documentation et une migration de base de données ne sont pas des unités de productivité interchangeables. Dans la mesure du possible, comparez des tâches semblables au fil du temps et consignez les autres changements, par exemple un nouveau fournisseur de runners ou un processus de publication révisé. Une amélioration concomitante à l’adoption de l’IA n’en établit pas la cause.

Les responsables peuvent alors faire un choix concret : financer la contrainte qui empêche des changements utiles d’atteindre les clients avec un niveau de confiance suffisant. Cela peut parfois signifier augmenter la capacité de calcul. Dans d’autres cas, il faudra clarifier les exigences, améliorer les tests ou consacrer assez de temps de révision à des personnes expérimentées pour comprendre les propositions qui arrivent déjà.

## Sources

- [Linear : codage par l’IA et goulot d’étranglement de l’intégration continue](https://linear.app/now/ci-bottleneck-reworked) — 21 septembre 2026. Le compte rendu de mise en œuvre de Mufeez Amjad fournit les chiffres d’ouverture et l’exemple de désactivation sélective de l’isolation. Les mesures de première main décrivent le système de Linear ; elles ne constituent ni une estimation contrôlée de la productivité de l’IA ni de la dépense totale.
- [DORA : concilier les tensions liées à l’IA](https://dora.dev/insights/balancing-ai-tensions/) — 10 mars 2026. Distingue l’association relevée par DORA en 2025 de l’analyse qualitative des réponses d’ingénieurs de Google. Cette étude interne rapporte des expériences plutôt que des effets causaux mesurés ; des questions antérieures ont pu orienter les réponses.
- [METR : IA du début de 2025 et productivité des développeurs expérimentés](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — 10 juillet 2025. Expérience randomisée menée dans des dépôts de logiciels libres familiers avec les outils du début de 2025. Étaye le ralentissement observé dans ce contexte et l’écart avec la perception des participants. Ce n’est pas une estimation pour tous les développeurs ou les modèles de septembre 2026.
- [METR : évolution de l’expérience sur la productivité des développeurs](https://metr.org/blog/2026-02-24-uplift-update/) — 24 février 2026. La mise à jour explique la sélection des participants et des tâches, l’évolution de la rémunération et les difficultés de mesure du travail simultané. Les chercheurs jugent la nouvelle estimation non fiable ; nous ne présentons pas ses chiffres bruts comme une accélération actuelle.
- [GitHub : mise en cache des dépendances](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching) — Documentation actuelle consultée le 22 septembre 2026. Décrit la réutilisation sur des runners vierges et la nécessité pour les tâches de fonctionner sans cache. Ne permet pas d’établir les performances ou la facture d’un dépôt en particulier.
- [Vitest : paramètres d’isolation par fichier](https://vitest.dev/guide/recipes/disable-isolation) — Documentation actuelle consultée le 22 septembre 2026. Explique l’isolation par défaut, la configuration sélective et les dépendances d’état à protéger. Ces recommandations techniques éclairent le compromis ; BIG CHANGE n’a ni réalisé de test de performance ni modifié de suite de tests.
- [DORA : indicateurs de performance de la livraison logicielle](https://dora.dev/guides/dora-metrics/) — Mise à jour du 5 janvier 2026. Définit cinq indicateurs de livraison et leur application au niveau d’un service. Ils mesurent les résultats au-delà de la durée de l’intégration continue ; les exemples de diagnostic de l’article sont des analyses, et non les résultats d’une nouvelle expérience.