Le 2 août, l’ingénieur logiciel Ankur Sethi a publié une recommandation à contre-courant sur son blog : lorsque vous développez avec l’IA, ne copiez-collez pas le code généré, mais retapez-le ligne par ligne dans votre éditeur. Il a imposé une règle stricte à l’IA : interdiction absolue de modifier les fichiers directement, les propositions doivent s’afficher uniquement dans la fenêtre de chat. Le jour même, son billet a récolté 363 points et plus de 300 commentaires sur Hacker News, se hissant au deuxième rang des sujets les plus discutés de la journée.
Figure : Le fil de discussion sur Hacker News. Source : news.ycombinator.com
Les commentaires se sont rapidement scindés en deux camps. « C’est un nouveau rituel inventé par des gens incapables de décrocher de l’IA. » « La meilleure façon de garder la forme, c’est d’être assis à l’arrière d’une voiture. » « Cette idée est absurdement stupide. » Si les critiques ont été virulentes, les soutiens n’ont pas manqué. Une remarque a été particulièrement relayée : « Autrefois, on savait que les développeurs passant au management perdaient la main. Aujourd’hui, nous sommes tous devenus des managers. »
Accumuler une “dette cognitive” : le coût caché de l’IA
Pourquoi adopter une approche en apparence si archaïque ? Sethi affiche plus de dix ans d’expérience en programmation et utilise quotidiennement des assistants IA. En laissant carte blanche à l’IA, une fonctionnalité complète est rédigée en quelques minutes. Mais un malaise grandissant l’a envahi : le code intègre le dépôt Git, mais la compréhension n’entre pas dans son esprit. La fonctionnalité est en ligne, mais il se retrouve incapable d’expliquer son fonctionnement interne.
Il qualifie ce phénomène de dette cognitive (cognitive debt) — la dette accumulée d’une compréhension manquée. Le jour où ce code doit être modifié, il doit à nouveau demander à l’IA : « Que fait ce bloc de code ? ». Une situation similaire à l’étudiant qui recopie les devoirs d’un camarade avant l’examen et réalise qu’il ne comprend pas un traître mot de sa copie.
Sethi n’est pourtant pas resté sans essayer les méthodes conventionnelles. La démarche standard aujourd’hui consiste à laisser le bot proposer le code et à le faire relire ligne par ligne par un humain. Cependant, relire des centaines de lignes de code surdéfensif, mal commenté et truffé de bugs subtils s’avère fastidieux et rébarbatif. Sur son blog, il souligne que si l’on peut serrer les dents au travail pour son employeur, c’est inacceptable sur des projets personnels — le plaisir d’un projet personnel réside précisément dans le processus et dans chaque ligne écrite de sa propre main.
Cette impasse trouve un écho scientifique. Une étude du MIT a suivi 54 étudiants répartis en groupes pour rédiger un essai : un groupe utilisait ChatGPT, un autre des moteurs de recherche, et le dernier travaillait de manière autonome. Les mesures EEG ont révélé que le groupe IA présentait la connectivité neuronale la plus faible. Lorsqu’on leur a demandé de résumer leur texte quelques minutes après la fin de l’exercice, le groupe IA a obtenu les pires résultats — les étudiants avaient à peine l’impression d’avoir rédigé le devoir. Plus l’outil prend en charge le travail, moins le cerveau s’investit. Une alerte que les chercheurs jugent préoccupante.
Figure : Données EEG de l’étude du MIT (Kosmyna et al.) — plus les outils externes interviennent, plus la connectivité cérébrale diminue. Source : brainonllm.com
La solution de Sethi a été de fixer des règles claires à l’assistant. Dans son fichier de consignes, il a stipulé : « Je veux comprendre chaque ligne de code qui entre dans ce projet. Sauf demande expresse, tu ne dois ni créer, ni modifier, ni déplacer, ni supprimer le moindre fichier. Affiche toutes les suggestions dans le chat et j’effectuerai la saisie moi-même. L’installation de dépendances et l’exécution des commandes relèvent aussi de ma responsabilité. » L’IA devient un conseiller, non un nègre littéraire.
Retaper du code à la main : qu’entraîne-t-on vraiment ?
La méthode semble délibérément lente : l’IA génère le code dans la fenêtre de chat, Sethi le tape ligne par ligne dans l’éditeur, marquant une pause dès qu’une syntaxe lui échappe pour consulter la documentation ou demander une clarification à l’IA. Il estime que sa productivité est passée de « 10x » à « 2x » — un compromis qui garantit que chaque ligne est filtrée par ses mains et son esprit.
Ce choix s’appuie sur une règle d’apprentissage classique. Les développeurs ayant appris dans les années 80 ou 90 s’en souviennent : le code des livres ou des magazines ne pouvait pas être copié-collé, il fallait le taper soi-même, le compiler, puis le modifier. La saisie manuelle force naturellement à ralentir : au rythme de la frappe, les yeux parcourent la ligne et le cerveau analyse ce qu’elle accomplit.
La mémoire musculaire liée à la frappe grave la structure du code dans les doigts ; la fois suivante, les mains se souviennent du schéma avant même que le cerveau ne formule la pensée.
Ce processus de saisie fait également office de relecture active. Sethi observe qu’il repère bien plus facilement les hallucinations de l’IA et les mauvaises architectures en tapant : le mouvement des mains maintient l’attention en éveil, laissant peu de place aux inattentions. À la fin, une véritable « carte mentale du code » est établie : l’emplacement de chaque module et l’impact des futures modifications deviennent évidents. Cela affine également le guidage futur de l’IA. Dans les commentaires, un utilisateur s’est rappelé que l’écrivain Hunter S. Thompson avait tapé à la machine l’intégralité des romans d’Hemingway dans sa jeunesse pour s’imprégner du rythme du maître. Retaper du code relève de la même démarche.
Les arguments contre : mémoire musculaire contre intuition
La critique la plus virulente est venue de l’utilisateur f311a, affirmant que retaper du code équivaut à recopier un corrigé de calcul mental : cela exerce la mémoire mais n’aiguise pas l’intuition. Celui qui recopie comprend les étapes de frappe, mais ignore pourquoi cette solution a été retenue ou quelles alternatives existaient. Sa recommandation est inverse : coder soi-même d’abord, puis utiliser l’IA pour optimiser.
Cette vision résonne chez de nombreux développeurs. Certains ont ironisé en soulignant qu’avec cette logique, il faudrait aussi retaper le code assembleur généré par le compilateur. D’autres ont rappelé que « la vitesse de frappe est rarement le goulot d’étranglement » et que retaper fait perdre un temps précieux sur des tâches à faible valeur ajoutée. L’éventuel risque d’être perçu comme « lent » par ses collègues a également été évoqué. À l’opposé, les partisans ont cité des travaux en sciences cognitives démontrant que la consommation passive d’un résultat « syntaxiquement correct mais sémantiquement vide » altère l’apprentissage — lire ne signifie pas assimiler.
| Pour la relecture manuscrite | Contre la relecture manuscrite |
|---|---|
| Copier sans comprendre = illusion ; retaper = vraie assimilation | Recopier un corrigé exerce la mémoire, pas l’intuition |
| Ralentir permet de déceler les hallucinations et mauvais designs | Le goulot d’étranglement n’est pas la frappe ; perte de temps |
| Mémoire musculaire et carte mentale facilitent les futurs refactorings | Écrire d’abord soi-même puis optimiser avec l’IA est plus efficace |
| Règle classique : la programmation s’apprend en tapant le code | Les outils doivent libérer l’humain pour des tâches plus nobles |
La divergence illustre deux faces d’un même dilemme : après avoir délégué à l’IA, vos compétences s’enrichissent-elles ou s’étiolent-elles ? Les partisans redoutent l’atrophie des compétences, tandis que les opposants jugent le principe du rétapage manuel inefficace.
Au-delà du code : un dilemme universel à l’ère de l’IA
Si le débat est né chez les développeurs, il concerne l’ensemble des professionnels à l’ère de l’IA. Si l’IA rédige vos bilans annuels, saurez-vous encore les écrire vous-même ? Si l’IA génère vos présentations et tableaux, que reste-t-il de votre esprit d’analyse et de synthèse ? « Ne plus progresser parce que l’IA prend le relais » est un défi posé à l’ensemble du monde du travail, les développeurs étant simplement les premiers confrontés à cette réalité.
Les non-développeurs peuvent tirer trois enseignements pratiques de ce fil. Premier conseil : laisser l’IA produire un premier brouillon, puis le réécrire manuellement avec ses propres mots — le travail d’édition constitue la phase d’assimilation. Deuxième conseil : demander à l’IA une structure globale et compléter soi-même les détails. Troisième conseil, issu d’une remarque très appréciée sur Hacker News : une fois le travail accompli avec l’IA, lui demander de vous interroger sur le résultat. Chaque impasse révélera une dette cognitive non soldée.
Savoir si le rétapage manuel est la solution optimale reste un sujet ouvert malgré plus de 300 commentaires. Sethi reconnaît lui-même que cette méthode paraît « presque comiquement inefficace ». Pourtant, cet échange pose une question cruciale : Lorsque vos outils vous rendent 10 fois plus rapide, que céder-vous en échange pour préserver votre compréhension ? Aucune IA ne répondra à cette question à notre place. Aller vite est appréciable, encore faut-il ne pas oublier comment avancer par soi-même.
Références :
- Ankur Sethi : Prevent cognitive debt by manually retyping LLM-generated code
- HN Discussion (item?id=49153374)
