Avec l'IA, je code plus lentement.

Série en 3 articles — Coder avec l'IA Article 1/3 — ce que les chiffres ne mesurent pas. À suivre : Ce que l'IA m'apporte vraiment (art. 2) · Quelle stratégie d'équipe ? (art. 3).

---

Une anecdote, pour commencer

Le 4 avril 2026, j'ai vibe-codé un outil en quelques heures pour gérer mes tâches quotidiennes. Il s'appelait daily-ops. Une glu en Python autour de mes TODO.md, capable de me faire passer d'un projet à l'autre sans friction. Ça marchait. J'étais content.

Le 25 avril, j'ai créé un vrai repo, ajouté trois fonctionnalités, et un peu de qualité — tests, structure, le minimum syndical. L'IA m'a proposé une abstraction élégante : séparer les items en blocks nommés alphabétiquement. Block A, Block B. Au premier coup d'œil, c'était propre.

▍ Figure 1 Cas zéro · 2026-04

4 h pour produire, 4 sem. pour stabiliser

Cas zéro : daily-ops, produit en quatre heures début avril 2026, a demandé quatre semaines de stabilisation.

Origine de la dette : abstraction « blocks alphabétiques » proposée par l'IA, élégante au premier coup d'œil, régressive ensuite (fusion accidentelle de blocks, report de blocks terminés, formatage concurrent).

• cas perso · 2026-04

  daily-ops

  abstraction « blocks alphabétiques » proposée par l'IA, élégante au premier coup d'œil, régressive ensuite

  4 h pour produire

  4 sem. pour rendre utilisable

Depuis quatre semaines, je corrige les bugs de cette élégance. Fusion accidentelle de blocks entre deux jours à cause du nommage alphabétique. Report de blocks dont tous les items étaient terminés, parce que l'état « fini » n'était pas explicite au niveau du bloc. Formatage concurrent entre deux projets qui partageaient les mêmes fichiers de configuration.

Bilan : quelques heures pour produire l'outil. Quatre semaines pour le rendre utilisable.

Pourtant, je suis depuis longtemps convaincu de deux choses : tout est logiciel — de la simple feuille Excel au script qui génère des PDF — et il faut très vite décider de le supprimer ou de le pérenniser avant qu'il ne se complexifie. Tout logiciel pérenne doit, au plus tôt, bénéficier d'un filet de sécurité pour ne pas baisser en qualité.

Avec l'IA, la complexité s'installe en silence. Plus vite, aussi, que le bon vieux Excel qui commençait à crouler sous ses six formules à références croisées.

C'est cette expérience, répétée sous plusieurs formes au cours des derniers mois, qui m'a fait basculer. Depuis, je code plus lentement. Et je produis plus.

---

Le paradoxe

Le discours dominant en 2026 est sans ambiguïté.

Ces chiffres sont sincères. Ils semblent mesurer la vitesse. En réalité ils n'en mesurent qu'une composante.

---

Ce que les chiffres ne mesurent pas

La mesure perçue n'est pas la mesure réelle

En 2025, une équipe de chercheurs de METR a conduit une expérience contrôlée randomisée ¹. Seize développeurs open source expérimentés, chacun avec en moyenne cinq ans de pratique sur les projets qu'ils maintenaient. 246 tâches réelles, pas synthétiques. Outils utilisés : Cursor Pro et Claude 3.5/3.7 Sonnet.

Avant de commencer, les développeurs prédisaient un gain de temps. Après l'étude, ils en percevaient un. La mesure objective, elle, raconte l'inverse — Figure 2.

▍ Figure 2 Étude METR · 2025

Perçu +20 %, mesuré −19 %

L'écart entre la perception et la réalité dépassait les 39 points. Ces développeurs n'étaient ni naïfs ni hostiles à l'IA. Ils étaient simplement convaincus d'aller plus vite quand ils allaient en réalité plus lentement.

J'ai moi-même vécu cet écart. Il y a deux ans, avec des modèles bien moins performants, ce qui m'aurait pris une ou deux heures me prenait souvent une demi-journée. Encore aujourd'hui, il m'arrive par réflexe de demander à Claude Code l'édition d'un fichier qu'il fera en trente secondes, là où j'aurais pu terminer en dix.

Les études antérieures, qui annonçaient 56 % ou 21 % d'accélération ¹, reposaient sur des tâches synthétiques. Or les conditions synthétiques masquent ce qui rend les vrais projets coûteux : la cohérence avec l'existant, la dette technique, les conventions tacites, les contraintes invisibles.

On mesure la rédaction, pas la livraison

Une étude conduite sur la télémétrie de 22 000 développeurs et deux ans d'historique a documenté une déconnexion entre productivité individuelle ressentie et performance de l'entreprise ². Les développeurs disent travailler plus vite. Les entreprises ne voient pas d'amélioration mesurable de la vélocité de livraison ni des résultats business.

Le rapport explique pourquoi : les métriques de vendeurs traquent l'activité — commits, pull requests, lignes de code — qui gonflent mécaniquement avec l'usage IA. La vélocité de livraison, elle, dépend d'une chaîne complète : revue, tests, intégration, déploiement, opérations. Cette chaîne n'a pas accéléré au même rythme.

▍ Figure 3 Étude Faros · 2025

Le gain individuel disparaît en file d'attente

L'étude Faros sur le même sujet est encore plus précise (Figure 3) : le gain individuel s'évanouit en file d'attente d'équipe ². Les gains se transforment en files d'attente.

La dette technique devient invisible

▍ Figure 4 GitClear · 2020 → 2024

Crossover 2023 : copy-paste passe devant refactoring

{#- Légende des courbes : autrefois passée via le paramètre `legend_html` du shortcode ; vit désormais en tête du corps colocalisé (la macro l'émettait juste après le titre, avant le SVG — même position). -#}

• copy-paste +4 pts
• refactoring −14,6 pts

L'étude GitClear, qui a analysé 211 millions de lignes de code modifiées entre 2020 et 2024 chez Google, Microsoft, Meta et plusieurs entreprises cotées, mesure une transformation des pratiques ³. La Figure 4 trace l'inversion : la part de copy-paste monte, celle de refactoring chute, les deux courbes se croisent en 2023. Au-delà de cette inversion, un autre signal : le code « churned » — réécrit dans les deux semaines suivant son commit — a doublé, de 3,1 % à 5,7 %.

Lorsque j'ouvre les projets en audit de code, je découvre de plus en plus souvent des fonctions de 800 lignes, empilées au fil des commits automatiques, et des tests unitaires identiques dans trois fichiers différents.

Le rapport DORA 2024 de Google, qui suit la performance de livraison logicielle depuis une décennie, confirme la tension : une augmentation de 25 % de l'adoption IA accélère les revues de code mais diminue la stabilité de livraison de 7,2 % ⁴.

▍ Figure 5 MIT · WSJ 2025

Citation d'Armando Solar-Lezama (MIT) comparant l'IA à une carte de crédit toute neuve qui permet d'accumuler de la dette technique inédite.

Source : Wall Street Journal, cité dans DevOps.com 2025.

«

L'IA est comme une carte de crédit toute neuve qui va nous permettre d'accumuler de la dette technique d'une manière qu'on n'avait jamais pu auparavant.

Une citation d'Armando Solar-Lezama, professeur au MIT, résume mieux que je ne saurais le faire : « L'IA est comme une carte de crédit toute neuve qui va nous permettre d'accumuler de la dette technique d'une manière qu'on n'avait jamais pu auparavant » ⁵.

Le terrain change avant qu'on ait fini d'apprendre

Une dimension manque presque toujours dans les études : à quel stade d'apprentissage sont les développeurs mesurés ? Les outils évoluent à un rythme qui rend la stabilisation d'une pratique difficile. Entre Cursor début 2025, Cursor mi-2025, Claude Code à l'automne 2025, et les agents autonomes qu'on déploie en 2026, ce ne sont plus les mêmes objets.

J'ai commencé par l'autocomplétion intelligente, avec Tabnine en 2018, puis Copilot. Codium — devenu Qodo — a été mon premier reviewer IA. Au printemps 2024, je faisais mes premiers Code Katas en ping-pong avec une IA. L'été suivant, un collègue m'a dit qu'il avait codé un projet entier sans écrire la moindre ligne lui-même. J'ai voulu essayer et j'ai constaté très vite que c'était plus efficace que de mixer ma production et celle de l'IA. À chaque transition, j'ai dû réapprendre à faire du vélo.

La success story est visible, l'incident l'est moins

Le dernier biais est statistique : on entend ceux qui réussissent avec l'IA. On entend moins ceux qui ont stabilisé pendant trois semaines un outil construit en trois jours.

▍ Figure 6 Incidents · 2025-2026

Deux fuites emblématiques

Deux incidents 2025-2026 emblématiques du trade-off vitesse↔sécurité de l'IA générative.

Lovable, faille CVE-2025-48757 : schémas de base de données générés sans politique de sécurité au niveau ligne, plus de 170 applications en production exposées. Moltbook, faille 2026 : endpoints API générés sans contrôle d'autorisation, 1,5 million de tokens d'authentification leakés.

• CVE-2025-48757

  Lovable

  schémas DB générés sans row-level security

  +170 apps exposées en prod

• incident · 2026

  Moltbook

  endpoints API générés sans contrôle d'autorisation

  1,5 M tokens d'auth leakés

Et pourtant, les incidents s'accumulent. La CVE-2025-48757 a exposé une faille chez Lovable, plateforme de codage IA, qui générait des schémas de base de données sans politiques de sécurité au niveau ligne. Plus de 170 applications en production affectées ⁶. La faille Moltbook a leaké 1,5 million de tokens d'authentification, parce que les endpoints API générés ne vérifiaient pas les autorisations ⁶.

Plus structurellement : selon Veracode, 45 % du code généré par IA contient au moins une vulnérabilité OWASP ⁷. Une autre étude mesure que ce code contient 2,74 fois plus de vulnérabilités que le code écrit par des humains ⁸.

Les méthodologies varient, les chiffres se discutent. Le signal, lui, converge : produire vite avec l'IA coûte en qualité de livraison, et les métriques d'adoption ne le voient pas.

▍ Figure 7 Synthèse

Quatre angles morts du discours dominant

Tableau de synthèse de la section : quatre angles morts du discours dominant sur la productivité IA, chacun avec son chiffre-clé et sa source.

Ce que les métriques ratent	Chiffre-clé	Source
Perception  ≠  réalité	−19 % vs +24 % attendu	METR 3
Rédaction  ≠  livraison	+91 % / +98 % revue · PR créées	Faros 4
Dette technique invisible	8,3 % → 12,3 % part de copy-paste, 2020 → 2024	GitClear 5 + DORA 6
Success  ≠  incident	45 % du code IA = ≥ 1 CVE OWASP	Veracode 9

---

La vitesse n'est pas la précipitation

Lorsqu'on compare le temps de trajet en avion ou en voiture, on compare de porte à porte plutôt que le temps passé dans le véhicule. C'est la vitesse. Sauter dans le premier bus arrivé et se rendre compte que ce n'est pas la bonne direction, c'est de la précipitation. Automatiser une tâche de développement peut relever de l'un ou de l'autre. L'IA ne fait pas la différence entre les deux. C'est le développeur qui décide où et comment l'utiliser. Personne n'aime s'apercevoir que la mémoire de Claude Code a mélangé le nom d'un client avec un autre le jour de la démo. Cet arbitrage régulier prend du temps. Un temps incompressible mais indispensable qui se prend avant d'écrire. C'est le temps nécessaire à la qualité. Si je devais résumer en deux formules :

Avant l'IA, nous passions 10 % de notre temps à écrire du code, et 90 % à le relire, le concevoir, y réfléchir, le réorganiser et aller lire de la documentation. Si nous possédons un outil qui peut accélérer ces 10 %, le gain est faible à long terme. Il ne peut être pérenne qu'à deux conditions : savoir accélérer une part des 90 % et investir plus de temps sur ce qu'on n'accélère pas.

---

Ce qui vient ensuite

Avec daily-ops, j'avais identifié le logiciel accidentel et ajouté la structure dès le 25 avril. Ce matin encore, quatre semaines plus tard, je corrigeais un bug né des premiers jours. La discipline ne suffit pas à effacer la précipitation initiale.

Si la vitesse mesurée n'est pas la productivité réelle, et si la discipline n'efface pas la précipitation, alors la question devient : qu'est-ce que l'IA m'apporte vraiment ? Ce sera l'objet du second article.

---

Note méthodique — quatre biais

Article basé sur mes recherches personnelles, dont je partage les sources. J'attire l'attention sur quatre biais qui peuvent creuser un écart entre nos points de vue :

1. Early-adopter : la nature et le nombre d'années de mon expérience ont une influence. Nos domaines, niveau de responsabilité et organisation varient. J'essaie de me renseigner et de prendre en compte le panel le plus large possible, et suis conscient que ma vision a des angles morts.
2. Temporalité : certaines études citées ont plus d'un an en mai 2026. Le domaine de l'IA change assez vite pour que les données aient déjà perdu du sens. J'ai sélectionné les sources qui sont, à ma connaissance, toujours valables.
3. Sélection des incidents : je ne traite pas ici les incidents où l'IA n'est qu'un démultiplicateur d'une faute humaine évidente — supprimer la base de prod sans backup, exposer des credentials sans audit. Ces cas existent en abondance, mais ils racontent moins l'IA que la pratique qui l'entoure.
4. Mes croyances et connaissances : j'écris en faveur d'une pratique que j'ai adoptée. Y adhérer ou pas peut donner une compréhension différente de mes propos. Sur ce biais en particulier, à vous de faire la part des choses.

---

Notes et références