- ▸ Le mythe du 10x s'est dégonflé en silence
- ▸ Cent lignes de code défensif, mal commenté, subtilement faux
- ▸ Recopier chaque ligne à la main : une méthode inefficace, et un peu comique
- ▸ Pourquoi je défends la lenteur
On nous avait vendu la vitesse. Dix fois plus vite, promettaient les démonstrations : un développeur, sa machine, et le rendement de dix. Puis quelqu’un a fait ses comptes. Le chiffre réel tient en deux caractères. 2x.
Ce qu’il faut retenir – Le gain de productivité réel d’un assistant de code s’établit autour de deux fois, non de dix, selon le témoignage du développeur Ankur Sethi (2 août 2026). – Laisser un assistant produire librement du code laisse derrière lui une « dette cognitive » : du code défensif, mal commenté, subtilement faux, que personne ne comprend vraiment. – La parade proposée est contre-intuitive : demander le code dans le chat, puis le réécrire soi-même, ligne à ligne, à la main. – L’enjeu dépasse le confort : sur un projet personnel, comprendre son propre code n’est pas un luxe, c’est la raison d’être du projet.
Le mythe du 10x s’est dégonflé en silence
Il faut lire ce billet publié le 2 août 2026 par Ankur Sethi, développeur qui tient un carnet de notes en ligne. Pas un manifeste. Un aveu.
Il utilise des assistants IA sur ses projets personnels, pour les tâches qui l’ennuient. Et il constate une chose que peu osent formuler aussi nettement : au lieu d’être dix fois plus rapide, il l’est probablement deux fois plus. La promesse marketing et la réalité de l’établi ne parlent pas la même langue.
Je trouve ce chiffre plus précieux que toutes les courbes d’adoption. Parce qu’il vient du terrain, d’un praticien qui n’a rien à vendre. Deux fois, ce n’est pas rien. Mais entre deux et dix, il y a un facteur cinq d’écart — l’écart entre une aide et un miracle. Et cet écart, personne dans les salons ne l’affiche.
Ma lecture : ce n’est pas l’outil qui déçoit. C’est le récit qu’on a construit autour.
Cent lignes de code défensif, mal commenté, subtilement faux
Laisser l’assistant courir seul dans un projet, écrit Sethi, laisse derrière lui une dette cognitive colossale. L’image est juste. Le code apparaît, il tourne, la fonctionnalité s’affiche — et pourtant vous ne savez pas ce que vous venez d’ajouter à votre propre maison.
Relire des centaines de lignes de code trop défensif, mal commenté, subtilement incorrect, ce n’est pas plaisant. Sethi le dit sans détour, et quiconque a validé une pull request générée par une machine le sait dans ses os. On attend cet exercice de nous, dans le métier. On l’accepte. On ne l’aime pas.
Voilà le paradoxe que je veux nommer. L’assistant vous fait gagner du temps à l’écriture pour vous en reprendre à la relecture. Il déplace l’effort. Il ne le supprime pas. Et il le déplace vers l’endroit le plus pénible : la vérification d’un texte que vous n’avez pas pensé, dont vous devez reconstituer l’intention après coup.
La dette a ceci de traître qu’elle est invisible tant que le programme fonctionne. Elle ne se paie pas le jour de la génération. Elle se paie six mois plus tard, quand il faut modifier une ligne dont plus personne — pas même son auteur humain — ne connaît la raison d’être.
Recopier chaque ligne à la main : une méthode inefficace, et un peu comique
La solution de Sethi, il la qualifie lui-même de grossièrement inefficace et légèrement comique. Elle mérite pourtant qu’on s’y arrête. Il demande à son assistant de générer le code dans la fenêtre de discussion. Puis il fait toutes les modifications lui-même, à la main, ligne après ligne.
Recopier. Littéralement. À l’heure du copier-coller instantané, un développeur choisit de retaper.
L’objection saute aux yeux, et je la partage : quelle absurdité de disposer d’une machine qui écrit à votre place et de refuser le fruit qu’elle vous tend. C’est du gâchis. C’est réintroduire à dessein la friction que l’outil était censé abolir.
Sauf que la friction, ici, n’est pas un défaut. C’est le mécanisme. En retapant chaque ligne, le cerveau ne peut pas décrocher. Il lit, il comprend, il valide ou il corrige au moment même où le doigt frappe la touche. La compréhension n’est plus une corvée reléguée à la relecture : elle est cousue dans le geste d’écriture. C’est le prix explicite de la méthode — deux fois plus rapide au lieu de dix — et Sethi le paie en connaissance de cause.
Je vois dans ce petit rituel manuel quelque chose de plus intelligent que bien des théories sur l’« IA responsable ». Une discipline, pas une posture.
Pourquoi je défends la lenteur
Résumons la mécanique dans un tableau, parce qu’elle mérite d’être vue d’un coup d’œil.
| Approche | Vitesse | Ce qu’il reste dans la tête |
|---|---|---|
| Assistant en autonomie | ~10x affiché | Dette cognitive : code non compris |
| Réécriture manuelle | ~2x réel | Compréhension ligne à ligne |
| Sans assistant | 1x | Compréhension, mais lenteur totale |
Le compromis se lit à la deuxième ligne. On abandonne cinq unités de vitesse théorique pour récupérer la seule chose qui compte à long terme : savoir ce qu’on a écrit.
Sethi le formule avec une honnêteté désarmante. Il déteste l’idée de s’enfoncer dans la documentation de Django pour ajouter un système d’étiquettes à son site — mais il veut fondamentalement comprendre comment cela fonctionne. Ces deux désirs cohabitent. L’ennui de l’apprentissage, et le besoin de maîtrise.
L’IA règle le premier. Elle ne doit jamais confisquer le second.
Voilà pourquoi la lenteur assumée n’est pas un aveu de faiblesse. Un développeur qui comprend son code à 2x battra toujours, sur la durée, celui qui empile à 10x un code qu’il ne relira jamais. La dette cognitive est un emprunt à taux variable, et le taux grimpe précisément quand vous n’avez plus le temps de le rembourser.
Le projet personnel ne se juge pas au résultat
Reste une frontière que ce billet trace avec finesse, et que je veux défendre à mon tour. Sur un projet personnel, la joie vient du processus, pas du résultat. Un projet personnel doit être amusant avant tout.
Cette phrase change tout le calcul. En entreprise, le résultat prime : livrer, corriger, tenir la deadline. La délégation à l’IA s’y justifie souvent. Mais le projet du soir, celui qu’on bricole pour soi, n’a pas de client. Son livrable, c’est le plaisir de comprendre. Optimiser sa vitesse revient à optimiser la mauvaise variable — à traverser en courant le seul endroit où l’on voulait flâner.
Retaper à la main devient alors parfaitement rationnel. On ne sacrifie pas de la productivité : on protège la raison d’être de l’exercice.
Ce que la promesse marketing a fait disparaître
On nous avait vendu la vitesse. Dix fois. Un développeur seul valant dix.
Le chiffre honnête, celui d’un praticien qui note ses comptes en 2 août 2026, dit deux fois — et encore, à condition de retaper chaque ligne pour ne pas s’endetter cognitivement. Je préfère mille fois cette comptabilité modeste aux démonstrations triomphales. Parce qu’elle rend au développeur ce que le récit du 10x lui avait retiré sans le dire : la compréhension de son propre travail.
La vraie question n’a jamais été combien de fois plus vite. Elle a toujours été qu’est-ce que je comprends encore de ce que je produis. Retapez. Une ligne après l’autre. Le débat est ouvert.
Questions fréquentes
Faut-il toujours réécrire à la main le code généré par l’IA ?
Non, pas partout. En production sous contrainte de délai, la relecture rigoureuse d’un code généré reste souvent le meilleur compromis. La réécriture manuelle vise surtout les contextes — projets personnels, apprentissage — où comprendre le mécanisme prime sur la vitesse de livraison.
Cette méthode a-t-elle un intérêt pour un développeur débutant ?
Oui. Elle laisse l’IA débroussailler les parties fastidieuses tout en imposant une assimilation ligne à ligne. On avance plus vite qu’en partant de zéro, sans troquer l’apprentissage réel contre un code qu’on ne saurait ni relire ni corriger.
Voir aussi notre analyse des assistants de code en entreprise et Anthropic et la course au million de tokens de contexte.
Cet article est une tribune et reflète l’opinion de son auteur.
