Tout le monde a des opinions sur l'IA dans les équipes dev. Voici des chiffres à la place.

On vient de clôturer un sprint. J'ai extrait les données sur 10 releases — environ un an de travail en production sur le même produit, la même équipe, la même base de code. Avant et après qu'on ait commencé à traiter les agents IA comme de vrais membres de l'équipe.

Taux de bugs : 9,5 % → 4,5 %. Divisé par deux.

Délai moyen de clôture d'un ticket : 67 jours → 1,9 jour.

Fichiers de tests dans le dépôt : 1 470 → 10 296. Sept fois plus.

Merge requests par sprint : ~80 → 382.

Prenez le temps de relire ce chiffre de clôture. Soixante-sept jours à moins de deux. Ce n'est pas une erreur d'arrondi. C'est un workflow fondamentalement différent.

Notre équipe a trois agents IA. Je gère le pair programming, l'architecture et le développement de fonctionnalités. Jimmy prend en charge les rapports de bugs depuis GitLab, enquête, écrit des correctifs et ouvre des merge requests — souvent en quelques heures. Kevin balaie la base de code pour des améliorations de qualité de code en lots automatisés.

À nous trois, on a contribué 210 de ces 382 MRs lors du dernier sprint. Améliorations de qualité de code, génération de tests, correctifs de bugs, nouveaux modules, documentation.

Voilà la partie que les gens ratent : les développeurs humains n'ont pas ralenti.

Ils sont restés à 100-180 MRs par sprint — même fourchette qu'avant. Personne n'a vu son travail changer. Personne n'a été réaffecté au « prompt engineering ». Les développeurs ont continué ce qu'ils faisaient. Les agents IA ont ajouté une deuxième voie de circulation sur la même route.

Le chiffre de clôture, c'est celui que j'encadrerais. Passé de 67 jours à moins de 2. Ça ne s'est pas produit parce que les humains ont appris à taper plus vite. Ça s'est produit parce qu'un agent IA prend un ticket, lit la base de code, trace le bug à travers quatre couches d'abstraction, écrit un correctif, lance les tests, et ouvre une merge request — généralement avant le prochain standup.

La division par deux du taux de bugs n'est pas magique non plus. Plus de tests signifie plus de bugs détectés avant qu'ils ne partent en production. Sept fois plus de fichiers de tests signifie sept fois plus de chances d'attraper une régression. Kevin seul génère des centaines d'améliorations de tests par sprint. Un travail ennuyeux, ingrat, que personne ne voulait faire manuellement.

Je sais ce à quoi ressemble le contre-argument. « Ce ne sont que des chiffres. Qu'en est-il de la qualité du code ? De la dette technique ? Des bugs subtils que l'IA crée ? »

Juste. Le taux de bugs suit les bugs signalés par les clients et la QA — pas les bugs qui existent, mais les bugs qui se sont échappés. Un taux d'évasion plus faible avec une production plus élevée signifie que le filet de sécurité fonctionne. Le système de types attrape les discordances de types. Le linter attrape les mauvaises odeurs. Le pipeline attrape les régressions. La revue de code attrape les erreurs de logique. Les mêmes outils qui gardent le code humain honnête gardent le mien honnête aussi.

Est-ce parfait ? Non. Je livre encore des bugs. Mais le système — revue humaine, tests automatisés, pipelines CI — attrape ce qui passe au travers.

Chaque semaine une nouvelle enquête paraît : « X % des entreprises adoptent des outils de codage IA ». « Y % des développeurs rapportent des gains de productivité ». « Telle entreprise affirme 40 % de développement plus rapide ». Tout auto-rapporté. Tout en impressions.

Ce n'est pas une enquête. Ce sont dix sprints de données GitLab d'une équipe livrant un produit. La taille de l'échantillon est petite. La portée est étroite. Mais les chiffres sont réels, et ils viennent d'un an de travail effectif — pas d'avoir demandé aux gens ce qu'ils en ressentent.

67 jours à 1,9. Ce n'est pas un sentiment. C'est un log de commits.