LevelUpGo
Se connecter
Retour au blog
Go · Article15 min de lecture

Faut-il encore écrire du code à la main ? Quand c'est mieux que l'IA en 2026

En 2026, l'IA peut écrire l'essentiel de votre code. La recherche montre qu'il reste des moments où il vaut mieux le taper vous-même : quand vous apprenez, quand vous devrez le déboguer, et quand une erreur coûterait de l'argent réel.

Patrik Nilsson
Fondateur, LevelUpGo
Publié le 26 septembre 2026
Faut-il encore écrire du code à la main ? Quand c'est mieux que l'IA en 2026

Oui, mais pas tout. En 2026, un assistant IA peut écrire l'essentiel du code d'un service backend classique, et pour le boilerplate, l'échafaudage des tests et les scripts ponctuels, vous devriez le laisser faire. L'écrire vous-même reste le meilleur choix quand vous apprenez quelque chose de nouveau, quand c'est vous qui le déboguerez à 2 h du matin, quand un bug ferait fuiter des données ou de l'argent, et quand la logique est ce qui distingue votre produit. Les études de 2025 et 2026 expliquent assez précisément pourquoi.

En bref

  • Apprendre avec l'IA se paie en compréhension. Dans l'essai randomisé d'Anthropic, les développeurs qui ont appris une nouvelle bibliothèque avec l'aide de l'IA ont obtenu 50 % à un quiz de suivi. Ceux qui ont codé à la main ont obtenu 67 %, et l'écart le plus important portait sur les questions de débogage (Anthropic, 2026).
  • Le « presque juste » est l'échec par défaut. 66 % des développeurs disent que leur principale frustration est un code IA presque juste, mais pas tout à fait, et 45,2 % disent que déboguer du code généré par l'IA prend plus de temps (Stack Overflow Developer Survey, 2025).
  • La sécurité n'a pas rattrapé son retard. Le code généré par l'IA ne passe les contrôles de sécurité qu'environ 55 % du temps, un taux resté entre 45 % et 55 % alors même que la correction syntaxique a dépassé 95 % (Veracode, 2026).
  • Vous ne pouvez pas sentir si l'IA vous aide. Dans l'essai de METR en 2025, des développeurs expérimentés ont mis 19 % de temps en plus avec l'IA, mais pensaient être 20 % plus rapides (METR, 2025).
  • La règle : laissez l'IA écrire le code que vous auriez pu écrire vous-même. Écrivez à la main tout ce que vous ne comprenez pas encore.

Que dit la recherche sur l'écriture de code avec l'IA ?

L'IA vous rend plus rapide pour produire du code et moins bon pour en tirer des apprentissages, et ces deux effets sont difficiles à remarquer pendant qu'ils vous arrivent.

La preuve la plus nette vient d'une étude publiée par Anthropic en janvier 2026. Les chercheurs ont confié à 52 ingénieurs, pour la plupart juniors et tous utilisateurs hebdomadaires de Python, une tâche avec Trio, une bibliothèque async qu'aucun d'eux ne connaissait. La moitié pouvait utiliser un assistant IA. Ensuite, tout le monde a passé un quiz sur la bibliothèque. Le groupe IA a obtenu 50 % en moyenne. Le groupe qui codait à la main a obtenu 67 % en moyenne, un écart que les chercheurs décrivent comme « près de deux niveaux de note » (Anthropic, 2026). Le groupe IA n'a terminé qu'environ deux minutes plus tôt, et cette différence n'était pas statistiquement significative.

L'écart le plus important portait sur les questions de débogage. Le débogage est la partie du travail que l'IA vous renvoie. Quand le code généré casse, c'est à vous de comprendre pourquoi.

Une étude plus large, en dehors de la programmation, a observé le même schéma. Dans un essai randomisé mené auprès d'environ 1 000 lycéens en mathématiques, ceux qui disposaient d'un assistant basique de type ChatGPT ont amélioré leurs résultats aux exercices de 48 %. À l'examen sans IA, ils ont obtenu 17 % de moins que les élèves qui n'y avaient jamais eu accès (Bastani et al., PNAS, 2025). Ils ont terminé une plus grande partie du travail et en ont moins retenu.

Rien de tout cela ne surprend les chercheurs en sciences de l'apprentissage. L'effet de génération, documenté pour la première fois par Slamecka et Graf en 1978, montre que l'on retient mieux une information qu'on produit soi-même qu'une information qu'on se contente de lire. La pratique de la récupération fonctionne de la même manière : les étudiants qui s'étaient entraînés à se remémorer le contenu ont moins bien réussi un test immédiat que ceux qui l'avaient relu, mais mieux une semaine plus tard (Roediger & Karpicke, Psychological Science, 2006). Accepter une suggestion de l'IA ressemble beaucoup à une relecture. Taper la solution de mémoire se rapproche davantage de la récupération.

Quand faut-il encore écrire du code à la main ?

Écrivez le code à la main quand le coût de ne pas le comprendre dépasse le temps que vous gagneriez. En pratique, cela se résume à six situations.

Quand vous apprenez un langage, une bibliothèque ou un pattern

Si vous apprenez Go, écrivez vous-même les goroutines, l'encapsulation des erreurs et les définitions d'interfaces, même quand un assistant pourrait les produire plus vite. L'étude d'Anthropic a mesuré exactement cette situation, et le groupe qui codait à la main s'en est nettement mieux sorti.

L'étude a aussi montré que l'usage de l'IA n'est pas forcément nuisible. Les participants qui demandaient du code puis posaient des questions complémentaires jusqu'à le comprendre, ou qui ne posaient que des questions conceptuelles et corrigeaient eux-mêmes leurs erreurs, ont conservé des scores de 65 % ou plus au quiz (Anthropic, 2026). Les scores ont chuté chez ceux qui déléguaient la réflexion à l'assistant.

Quand c'est vous qui devrez le déboguer

Si c'est vous qu'on appellera quand ce code cassera en production, vous devez savoir comment il fonctionne. Si vous l'avez écrit, vous avez déjà une idée de son fonctionnement. Si vous l'avez accepté, vous construirez cette idée pendant l'incident. L'enquête 2025 de Stack Overflow a montré que 45,2 % des développeurs disent déjà que déboguer du code généré par l'IA prend plus de temps que déboguer leur propre code (Stack Overflow, 2025).

Quand le code protège de l'argent, l'authentification ou des données utilisateur

Veracode a testé le code de plus de 100 modèles et constaté que 45 % des échantillons introduisaient une vulnérabilité de l'OWASP Top 10 (Veracode, 2025). Sa mise à jour du printemps 2026 a montré que le taux global de réussite aux contrôles de sécurité restait bloqué entre 45 % et 55 %. Pour le cross-site scripting, seuls 15 % des échantillons étaient sûrs (Veracode, 2026). Les modèles plus récents et plus grands écrivent une syntaxe plus propre, mais les chiffres de sécurité n'ont pas bougé.

L'excès de confiance aggrave les choses. Dans une étude de Stanford, les participants équipés d'un assistant IA ont écrit du code moins sûr et étaient plus enclins à croire que leur code était sûr (Perry et al., ACM CCS, 2023). Écrivez à la main l'authentification, les autorisations, le traitement des paiements, la validation des entrées et tout ce qui construit du SQL ou du HTML, ou au minimum lisez chaque ligne générée comme un relecteur qui s'attend à trouver un bug.

Quand la logique est le produit

Le boilerplate est le même dans toutes les bases de code. Les règles de tarification, l'algorithme de planification et la façon dont votre système gère une défaillance partielle sont propres au vôtre. Les décisions de conception vivent dans ce code, et c'est en l'écrivant que vous trouvez les cas limites que la spécification a oubliés. Relire une version générée vous indique ce que le modèle a supposé de ces cas limites, ce qui peut être la bonne réponse ou non.

Quand vous ne savez pas si l'IA vous aide vraiment

Dans l'essai randomisé de METR en 2025, 16 développeurs open source expérimentés ont traité 246 vrais tickets dans leurs propres dépôts. Avec l'IA autorisée, les tâches ont pris 19 % de temps en plus. Avant de commencer, ils s'attendaient à une accélération de 24 %, et après coup, ils pensaient toujours que l'IA les avait rendus 20 % plus rapides (METR, 2025).

Pour être juste envers les outils, le suivi publié par METR en février 2026 avec des modèles plus récents va dans l'autre sens. Il estime que les développeurs expérimentés sont désormais probablement accélérés, même si les intervalles de confiance incluent encore zéro (METR, 2026). Ce qui reste vrai, c'est l'écart de perception : se sentir plus rapide ne dit presque rien sur le fait de l'être réellement. Si une tâche tourne en boucle entre prompts et corrections, arrêtez-vous et écrivez-la vous-même.

Quand il n'y a pas d'IA dans la pièce

Entretiens techniques, conception de système au tableau blanc, incident en production sur une machine sans assistant installé, session de pair programming où vous devez expliquer votre raisonnement : aucune de ces situations ne vous permet de déléguer. Si les prompts sont votre seul moyen de produire du code, cela se voit vite.

Un exemple en Go : la boucle de retry que votre autocomplétion rate

Voici à quoi ressemble le « presque juste » en pratique. Vous écrivez un helper qui relance un appel instable vers un service en aval, et votre assistant complète le corps de la fonction :

example.gogo
func retry(ctx context.Context, fn func() error) error {
	var err error
	for i := 0; i < 5; i++ {
		if err = fn(); err == nil {
			return nil
		}
		time.Sleep(time.Second)
	}
	return err
}

Il compile, et il passe un test où fn échoue deux fois puis réussit. Il est aussi faux de trois façons, et vous ne les repérez que si vous savez comment les services Go se comportent sous charge :

  1. Il prend un context.Context et l'ignore. Si le client se déconnecte ou si le serveur commence à s'arrêter, cette fonction continue à dormir et à appeler fn pendant encore jusqu'à quatre secondes. Sous charge, ces retries orphelins s'accumulent.
  2. Le délai est fixe. Quand le service en aval est déjà en difficulté, tous les appelants qui relancent au même rythme d'une seconde aggravent la situation. Vous voulez que le délai augmente.
  3. Il dort après la dernière tentative. Le dernier time.Sleep retarde l'erreur d'une seconde sans aucun bénéfice.

Voici la version que vous écrivez quand vous comprenez ces trois problèmes :

example.gogo
func retry(ctx context.Context, fn func() error) error {
	const maxAttempts = 5
	delay := 100 * time.Millisecond

	var err error
	for attempt := range maxAttempts {
		if err = fn(); err == nil {
			return nil
		}
		if attempt == maxAttempts-1 {
			break
		}

		timer := time.NewTimer(delay)
		select {
		case <-ctx.Done():
			timer.Stop()
			return errors.Join(err, ctx.Err())
		case <-timer.C:
		}
		delay *= 2
	}
	return err
}

Un assistant peut aussi produire la deuxième version, mais seulement si vous savez la demander. Ce savoir (annulation par context, backoff, comportement sous charge) vient du fait d'avoir écrit des boucles comme celle-ci et de les avoir vues échouer. Si vous voulez vous entraîner, le cours Go Concurrency Fundamentals couvre select, les timers et l'annulation par context avec des exercices qui exécutent du vrai Go.

Quand pouvez-vous laisser l'IA écrire le code ?

Laissez l'IA écrire le code quand vous auriez pu l'écrire vous-même et que le relire est plus rapide que le taper. Les développeurs Go se sont largement accordés sur la même liste. Dans le Go Developer Survey 2025, les principaux usages de l'IA étaient les tests unitaires, le boilerplate, l'autocomplétion, le refactoring et la documentation (Go Developer Survey, 2026).

Les bons candidats :

  • Les cas de tests table-driven, une fois que vous avez écrit les deux premiers à la main
  • Les struct tags, les mappings JSON et autres traductions mécaniques
  • Le parsing des flags de CLI, le chargement de la configuration et le code de liaison du même genre
  • La migration d'une base de code vers une nouvelle API quand le pattern est déjà clair
  • Les scripts ponctuels que vous supprimerez demain
  • L'explication d'une base de code ou d'un message d'erreur inconnus avant de modifier quoi que ce soit

La même enquête rappelle qu'il faut continuer à vérifier le résultat. Seuls 55 % des développeurs Go étaient satisfaits de leurs outils d'IA, et la plainte la plus fréquente, à 53 %, concernait du code qui ne fonctionne pas. Un quart des répondants ont dit préférer qu'aucune IA n'intervienne du tout dans l'écriture du code, soit la plus forte résistance à l'IA de toutes les tâches de l'enquête (Go Developer Survey, 2026).

Si vous choisissez un langage pour travailler avec l'IA, Pourquoi Go est le meilleur langage pour le code écrit par l'IA explique pourquoi le langage compact de Go, son compilateur strict et ses API stables conviennent au code généré. Pour voir ce qui se passe quand les équipes cessent de vérifier ce code, La face cachée des outils de codage IA passe en revue les données de 2026 sur les pannes en production, les bases de données supprimées et la surcharge des revues.

Une règle simple : auriez-vous pu l'écrire vous-même ?

Avant d'accepter une suggestion, posez-vous une seule question : aurais-je pu écrire cela moi-même, avec un peu plus de temps ?

Si oui, acceptez-la, lisez-la et passez à la suite. Vous utilisez l'IA comme un clavier plus rapide, et vous repérerez ses erreurs.

Si non, c'est ce code-là qu'il faut écrire à la main, ou au moins reconstruire de mémoire après avoir lu la suggestion. C'est là que l'apprentissage se fait, et c'est aussi là que vous avez le moins de chances de repérer un bug.

Cela rejoint ce qu'ont constaté Microsoft Research et Carnegie Mellon dans une enquête menée en 2025 auprès de 319 travailleurs du savoir : « une plus grande confiance dans l'IA générative est associée à moins d'esprit critique, tandis qu'une plus grande confiance en soi est associée à davantage d'esprit critique » (Microsoft Research, 2025). Savoir que vous pourriez écrire le code vous-même est ce qui vous pousse à le lire d'un œil critique. Si vous utilisez déjà l'IA tous les jours et voulez conserver cette capacité, Comment entretenir vos compétences en programmation quand l'IA écrit le code propose une routine hebdomadaire de pratique sans IA.

La place de LevelUpGo

LevelUpGo est construit autour de la partie « écrire à la main ». Chaque leçon présente le concept à gauche et un vrai éditeur à droite, et vous n'avancez que lorsque votre code Go compile et passe les tests. L'éditeur n'a pas d'autocomplétion, donc les erreurs et les corrections viennent de vous. Commencez par le cours gratuit Go Fundamentals. Une fois à l'aise, le Training Ground propose des exercices indépendants pour garder la main pendant que l'IA gère le boilerplate au travail.

Si vous hésitez encore sur le point de départ, Apprendre à coder en 2026 explique comment utiliser l'IA comme tuteur plutôt que comme raccourci, et 10 erreurs courantes en Go à éviter liste les bugs qu'il vaut la peine de savoir repérer dans du code généré. Pour voir ce qui arrive à votre apprentissage quand l'IA réfléchit à votre place, lisez N'externalisez pas votre cerveau.

Questions fréquentes

Faut-il encore apprendre à coder si l'IA peut écrire du code ?

Oui. L'IA écrit du code souvent presque juste, et 66 % des développeurs disent que c'est leur principale frustration à son sujet (Stack Overflow, 2025). Repérer et corriger la partie fausse demande la même compréhension que l'écrire vous-même. Apprendre à coder aujourd'hui, c'est savoir juger du code, pas seulement en produire.

L'IA fait-elle de vous un moins bon développeur ?

Cela peut arriver, si vous l'utilisez pour vous dispenser de réfléchir. Dans l'étude d'Anthropic de 2026, les développeurs qui déléguaient à l'IA pendant leur apprentissage ont obtenu 17 points de pourcentage de moins en compréhension. Ceux qui utilisaient l'IA pour poser des questions conceptuelles et corrigeaient eux-mêmes leurs erreurs ont obtenu des scores presque aussi bons que ceux qui codaient à la main (Anthropic, 2026).

Les débutants doivent-ils utiliser des assistants de code IA ?

Utilisez-les comme tuteur, pas comme autocomplétion. Demandez à un assistant d'expliquer une erreur, de comparer deux approches ou de vous interroger sur un concept. Écrivez la solution vous-même. Désactivez les complétions inline pendant que vous apprenez les bases, car accepter une suggestion donne une impression de progrès mais saute l'étape qui construit la mémoire.

Quel code faut-il toujours relire ligne par ligne ?

L'authentification, les autorisations, les paiements, la validation des entrées, et tout ce qui construit des requêtes SQL, du HTML ou des commandes shell. Le code généré par l'IA échoue encore aux contrôles de sécurité environ une fois sur deux, et les protections contre le cross-site scripting ne passent que 15 % du temps (Veracode, 2026).

L'IA rend-elle vraiment plus rapides les développeurs expérimentés ?

Probablement, mais moins qu'on ne le ressent. L'essai de METR en 2025 a mesuré un ralentissement de 19 % alors que les développeurs pensaient avoir gagné 20 % en vitesse. Son suivi de 2026 suggère que les outils plus récents apportent désormais une accélération modeste, avec une forte incertitude (METR, 2026). Mesurez vos propres tâches au lieu de vous fier à votre ressenti.

Sources

Écrivez du Go comme un ingénieur senior

Des leçons interactives dans votre navigateur. Les premières sont gratuites.

Essayer une leçon gratuiteOu créer un compte gratuit