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.</caption>
Ce que les métriques ratent</th>	Chiffre-clé</th>	Source</th> </tr> </thead>
Perception ≠</span> réalité</th>	−19 %</span> vs +24 % attendu</span> </td>	METR ^{3</a></sup></span></td> </tr>}
Rédaction ≠</span> livraison</th>	+91 % / +98 %</span> revue · PR créées</span> </td>	Faros ^{4</a></sup></span></td> </tr>}
Dette technique invisible</th>	8,3 % → 12,3 %</span> part de copy-paste, 2020 → 2024</span> </td>	GitClear ^{5</a></sup> + DORA 6</a></sup></span></td> </tr>}
Success ≠</span> incident</th>	45 %</span> du code IA = ≥ 1 CVE OWASP</span> </td>	Veracode ^{9</a></sup></span></td> </tr> </tbody> </table> Quatre lignes, quatre études indépendantes : METR (expérience contrôlée), Faros (télémétrie 22 000 devs), GitClear + DORA (211 M lignes + benchmark décennal), Veracode (audit GenAI 2025).</span> </figcaption> Voir la figure 7 sur le site ↗</a> </figure> La vitesse n'est pas la précipitation</h2> 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 :</p> Précipitation</span> =</span> accélération</span> −</span> attention</span> </span> </p> Vitesse</span> =</span> accélération</span> +</span> réflexion</span> +</span> qualité</span> </span> </p> </div> 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.</p> Ce qui vient ensuite</h2> 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.</p> 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</em> ? Ce sera l'objet du second article.</p> Note méthodique — quatre biais</h2> 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 :</p> Early-adopter</strong> : 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.</li> Temporalité</strong> : 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.</li> Sélection des incidents</strong> : 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.</li> Mes croyances et connaissances</strong> : 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.</li> </ol> Notes et références</h2> ^{1</sup> Second Talent, AI Coding Assistant Statistics & Trends [2025]</em></a>, secondtalent.com, 2025.</p> </div> ^2</sup>Stack Overflow, Developer Survey 2025</em></a>, stackoverflow.co.</p> </div> ^3</sup>Becker, J. et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity</em></a>, METR, arXiv:2507.09089, juillet 2025 (résumé METR</a>).</p> </div> ^4</sup>Faros AI, The AI Productivity Paradox Research Report</em></a>, faros.ai, 2025.</p> </div> ^5</sup>GitClear, AI Copilot Code Quality 2025 Research Report</em></a>, gitclear.com, février 2025.</p> </div> ^6</sup>Google, Accelerate State of DevOps Report 2024</em></a>, dora.dev.</p> </div> ^7</sup>Solar-Lezama, A., interview au Wall Street Journal</em></a>, citée dans DevOps.com</a>, AI in Software Development: Productivity at the Cost of Code Quality?</em>, 2025.</p> </div> ^8</sup>Vibe Coder Blog, Security Researchers Sound the Alarm on AI Code Vulnerabilities</em></a>, blog.vibecoder.me, avril 2026 ; voir aussi CVE-2025-48757</a>.</p> </div> ^9</sup>Veracode, 2025 GenAI Code Security Report</em></a>, veracode.com.</p> </div> ^10</sup>SoftwareSeni, analyse de Veracode 2025 et Apiiro</a>, softwareseni.com, février 2026.</p> </div> ^11</sup>Futurity, AI-generated code is vulnerable</em></a>, futurity.org, 2026.</p> </div> Pourquoi ce site, et pourquoi maintenant 2026-05-22T00:00:00+00:00 Un été, à 9 ou 10 ans, je tenais un hors-série du magazine Tilt</em> avec des listings en BASIC. J'ai encore la couverture en tête. Avec mon frère, nous avons copié plusieurs pages de code sur notre Thomson TO9. Par séances de trente minutes à une heure, l'un dictait et relisait pendant que l'autre tapait ce programme que nous ne comprenions qu'à moitié. On a fini par abandonner. Vers la fin des vacances, j'ai repris le hors-série et j'ai terminé seul. J'ai enfin pu lancer le programme. La forme du billard et quelques billes s'affichaient. Mais un grand trait au milieu de l'écran montrait qu'il y avait eu des erreurs de recopie. Le jeu ne répondait à rien.</p> FIG. 1 · Couverture Tilt — Micro-Jeux</em>, HS 05, août 1987 · scan abandonware-magazines</a></figcaption> </figure> Patiemment, j'ai relu et comparé, me rendant compte que certains numéros de ligne en BASIC avaient été décalés. Je démarrais le programme à nouveau, voyant parfois un changement, parfois des erreurs de syntaxe nouvelles. J'ai corrigé avec le listing. Il était plus fiable que mes déductions. L'erreur venait de la transcription. Le programme, lui, fonctionnait. La rentrée approchant, j'ai laissé tomber. Je n'avais plus envie de revenir dessus.</p> Le décor de cet été-là s'était posé quelques années plus tôt. J'apprenais à lire et à écrire quand mes parents nous ont offert ce Thomson TO9</a>, sur lequel j'ai découvert le BASIC. À cet âge, je pouvais lire tout seul Un éléphant ça compte énormément</em> d'Helme Heine. Je collais une étiquette en minuscules cursives garage de clarke</em>, et racontais « Clarke a accéléré droit vers le tremplin. Il a pris son envol et atterri de l'autre côté de la rivière. Il avait échappé à l'avalanche. »</em> Je tapais à deux doigts des GOTO infinis, un jeu « nombre secret »</em> avec des IF/PRINT/INPUT. J'essayais de dessiner un polygone avec POINT/LINE — il s'avérait mal fermé à l'affichage.</p> FIG. 2 · Helme Heine, Un éléphant ça compte énormément</em>, Gallimard Jeunesse, coll. folio benjamin.</figcaption> </figure> Ce qu'un enfant ne pouvait pas deviner, c'était comment ces trois gestes allaient n'en faire qu'un. Le code, la lecture, l'écriture : une seule discipline.</p> Cette discipline est l'alignement de la pensée avec l'écrit</mark> . J'en ai appris l'exigence par le code, mais elle dépasse le code. Ce site existe pour incarner cette exigence, par des objets concrets : outils, écrits, prises de position.</p> LISTING 1 · ARBORESCENCE</span>TREE</span> </figcaption> experiments/ ├── ai │ ├── assist │ ├── audiobook-pipeline │ ├── autopreneur │ ├── bmad-context-viewer │ ├── mercurai │ ├── notebooklm-py │ ├── rhetorix │ └── SDD ├── autopreneur │ └── voice-notes ├── games │ ├── drop-escape-clone │ ├── lab-doku │ └── mdr-serious-game ├── lang-tools │ ├── carbon │ └── lean4 ├── media │ └── music-gen └── misc 22 directories</code></pre> </figure> J'ai l'habitude de tester la moindre idée qui me passe par la tête. Je stocke ces expériences dans un dossier experiments/</code>. Je le trie systématiquement, impitoyablement : je compare chaque chantier 2 à 2. Seuls les plus pertinents restent. C'est le death-match</em> des prototypes pour gagner le droit d'être promu au rang de projet. Et le prochain sur la ligne d'arrivée est Rhetorix</a></strong> : décrypter la rhétorique d'un article de presse. En novembre 2025, pour ma recherche d'emploi, j'ai bricolé quelques scripts et prompts. J'en ai extrait inflecv</a>, qui transforme une offre d'emploi en CV adapté. Toujours pour piloter l'IA, /glance</code></a> formate les retours IA pour les rendre simples à lire et à survoler. Pour vérifier qu'un projet évolue dans le bon sens, /feature-torture</code></a> est un banc de dissection d'une fonctionnalité pour juger si elle survit, mute ou disparaît. Jusqu'ici, j'ai créé pour m'amuser ou me faciliter la vie. J'ai partagé afin de m'imposer un standard de qualité — la qualité minimum pour ne pas m'en vouloir, dans quelques semaines ou quelques mois, quand je voudrai reprendre le travail. C'est de cette matière que naissent les billets qu'on lit ici.</p> Pourquoi tenir à ce soin-là en 2026 ? Face à des projets et créations uniformes, l'impression que quelqu'un a repris, remanié et perfectionné 100 fois son travail me manque. Le danger de la génération automatique n'est pas le remplacement pur et simple, mais que notre contenu devienne indiscernable de celui de l'IA. Il y a un an, une vidéo IA montrait 3 bras par personne. En 2026, la différence de forme entre les contenus automatiques ou manuels s'amenuise. Quand je mets en pause lucid-lint</code></a>, /feature-torture</code> ou un article, je veux être sûr qu'ils sont utilisables et que je pourrai les reprendre plus tard avec plaisir</em>. Lorsque je les démarre, l'IA me sert à construire plus vite les filets de sécurité, la documentation lisible, le suivi du projet. Demain ou dans un an, je saurai où j'en suis sur chaque projet, et chaque projet me racontera son histoire.</p> LISTING 2 · LUCID-LINT</span>v0.2.0</span> </figcaption> $ lucid-lint check examples/sample.md ~~~~~ ⟨ • ⟩ ───── lucid-lint v0.2.0 cognitive accessibility linter · prose · EN / FR ──────────────────────────────────────────────── warning sample.md:3:1 Sentence is 29 words long (maximum 22). warning sample.md:46:1 Sentence has 4 commas (maximum 3). info sample.md:1:1 Kandel-Moles ease score 72.9 (target ≤ 9.0). summary: 7 warnings, 1 info. score: 50/100 structure ▓▓▓░░░░░░░░░░░░░░░░░ 5/20 rhythm ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 20/20 lexicon ▓▓▓▓▓▓░░░░░░░░░░░░░░ 10/20 syntax ▓▓▓▓▓▓░░░░░░░░░░░░░░ 10/20 readability ▓▓▓░░░░░░░░░░░░░░░░░ 5/20 exit: 1</code></pre> </figure> Cet article est une première page. Les personnages sont présentés : des expérimentations, des outils et des recherches. Je les mettrai en scène, les ferai parler, au fil des chapitres à venir : certains conteront l'échec d'un prototype ou l'excitation face à une idée prometteuse ; parfois, vous suivrez un seul protagoniste de bout en bout ; enfin, des séries analyseront les enjeux du code et de ce qu'on en fait. La table des matières vous interpelle ? Écrivez-moi. Je prendrai le temps de vous lire et de répondre.</p> Références</p> FIG. 1 — Tilt — Micro-Jeux</em>, hors-série n°5, août 1987, Éditions Mondiales. Scan : abandonware-magazines.org</a>.</p> FIG. 2 — Helme Heine, Un éléphant ça compte énormément</em>, Gallimard Jeunesse, coll. folio benjamin.</p> Matériel — Thomson TO9</a> (Wikipédia).</p> </div> Outils cités</p> lucid-lint</a> — linter d'accessibilité cognitive pour la prose.</p> /feature-torture</a> — banc de dissection pour une fonctionnalité.</p> /glance</a> — formater les retours IA pour la lecture-survol.</p> inflecv</a> — d'une offre d'emploi à un CV adapté.</p> Rhetorix</a> — prototype, décrypter la rhétorique d'un article de presse.</p> </div> </aside>}}

Avec l'IA, je code plus lentement

2026-05-28T00:00:00+00:00

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). </blockquote>

Une anecdote, pour commencer</h2>
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</code>. Une glu en Python autour de mes TODO.md</code>, 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 </header> 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</h3> 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 </li> </ul> Voir la figure 1 sur le site ↗</a> </figure> 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</h2> Le discours dominant en 2026 est sans ambiguïté. 126 % de projets complétés par semaine avec Copilot GitHub1</a> 84 % d'adoption chez les développeurs, plus de la moitié quotidienne Stack Overflow2</a> 78 % déclarent que l'IA améliore leur productivité GitHub1</a> </div> 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</h2> La mesure perçue n'est pas la mesure réelle</h3> En 2025, une équipe de chercheurs de METR a conduit une expérience contrôlée randomisée3</a>. 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 </header> Perçu +20 %, mesuré −19 %

Ce que les chiffres ne mesurent pas</h2>

La dette technique devient invisible</h3>

Pourquoi ce site, et pourquoi maintenant

Écrits — Bastien Gallay

Avec l'IA, je code plus lentement