L'IA code, tu testes : pourquoi le testing est ta vraie valeur ajoutée en 2026

24 février 2026 par Benoit

Ou : Le jour où j’ai arrêté de faire confiance à mon copilote

Il y a un truc assez fascinant avec le code généré par l’IA : tout le monde le trouve « magique », jusqu’au jour où ça part en production. Et là, soudain, ce n’est plus magique, c’est juste cher.

Depuis deux ans, les équipes balancent du code sorti de Claude, Copilot, Cursor et consorts dans leurs bases de code avec la même insouciance qu’un étudiant qui copie un corrigé sur GitHub la veille de l’examen. Les métriques sont belles : plus de lignes de code, plus vite, plus de tests générés automatiquement, plus de couverture. Les dashboards brillent, les slides de roadmap aussi. Sauf qu’il y a un petit détail : un rapport CodeRabbit de fin 2025, relayé par The Register, montre que le code généré par IA produit 1,7 fois plus de problèmes majeurs que le code écrit à la main¹.

C’est un peu comme si on avait engagé un stagiaire hyper rapide, hyper obéissant, qui ne dort jamais… mais à qui on a aussi donné les clés du déploiement en production.

Ce premier article est le manifeste de la série. Il pose une thèse simple : en 2026, ton boulot en tant que développeur n’est plus d’écrire du code — c’est de dire non à du code. Et pour dire non intelligemment, il faut savoir tester.

Ce que disent les chiffres (et pourquoi tu dois les prendre au sérieux)

Les rapports commencent à s’accumuler, et ils ne sont pas tendres avec le code généré par IA.

• Veracode a constaté que 45% des tâches testées par leurs scans d’applications introduisent des failles de sécurité quand le code est généré par IA².
• Le rapport CodeRabbit montre que le code IA génère 1,4 fois plus d’issues critiques, 1,7 fois plus d’issues majeures et — accrochez-vous — 2,74 fois plus de vulnérabilités XSS que le code écrit par des humains³.
• Plusieurs analyses signalent un phénomène récurrent : les assistants IA génèrent beaucoup de tests, mais ces tests sont souvent superficiels, redondants, et couvrent mal les chemins critiques⁴.

Traduction : l’IA sait jouer au testing. Elle sait produire ce qui ressemble à une suite de tests. Elle sait faire monter la couverture. Elle sait impressionner un manager qui ne regarde que le pourcentage dans le rapport de CI. Elle ne sait pas, par défaut, faire la différence entre un test utile et un test décoratif.

Et c’est là que tu entres en jeu.

Le mensonge confortable de la couverture de test

Prenons un exemple concret en Go.

Tu as une fonction super banale :

1
2
3
4
5

package mathutil

func Divide(a, b float64) float64 {
	return a / b
}

Tu demandes à ton IA préférée : « Écris-moi des tests unitaires pour cette fonction. » Tu obtiens quelque chose du genre :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

package mathutil

import "testing"

func TestDivide(t *testing.T) {
	result := Divide(10, 2)
	if result != 5 {
		t.Errorf("expected 5, got %v", result)
	}
}

Tu lances :

1

go test ./...

Ça passe. Tu ajoutes la couverture :

1

go test ./... -cover

La sortie affiche :

1

ok  	mathutil	0.002s	coverage: 100.0% of statements

Magique. 100% de couverture. Tu te sens bien. Le dashboard de CI te félicite. Ton manager aussi.

Sauf que ce test est objectivement nul.

• Il ne teste qu’un cas « happy path » (10 / 2).
• Il ne teste pas la division par zéro.
• Il ne teste pas les nombres négatifs.
• Il ne teste pas les cas extrêmes (très grands, très petits).
• Il ne teste pas les arrondis, ni le comportement avec des floats non représentables proprement.

La couverture de test mesure les lignes exécutées, pas la pertinence de ce qui est vérifié. Tu peux avoir 100% de lignes exécutées avec zéro assertion utile. Et l’IA adore produire ce genre de tests, parce qu’ils sont simples à générer et donnent l’illusion de sécurité⁵.

La couverture de test, sans esprit critique, est un mensonge confortable.

Pourquoi Go est un terrain de jeu parfait pour apprendre à tester

J’aurais pu faire cette série en Python, en PHP ou en JavaScript. Mais Go a une particularité : il a pris le parti du minimalisme.

• Le testing est dans la standard library (testing). Pas de framework externe obligatoire⁶.
• Les conventions sont simples : les fichiers *_test.go, les fonctions TestXxx(t *testing.T), la commande go test⁷.
• Les tests, les benchmarks, le fuzzing, et même certains outils de profiling sont intégrés dans les mêmes patterns.

Autrement dit : Go te force à comprendre ce que tu testes. Il ne te donne pas un framework magique qui transforme tout en boîte noire. Si tes tests sont mauvais, c’est ton problème, pas celui du framework.

C’est exactement ce qu’il faut dans un monde où l’IA peut générer du code et des tests sans rien comprendre à ce qu’elle fait.

Ton nouveau rôle : garde-fou de l’IA

On peut résumer ce qui se passe en une phrase : l’IA a déplacé la frontière entre « écrire du code » et « vérifier du code ».

Avant :

• Tu passais 70% de ton temps à écrire du code.
• 20% à écrire des tests.
• 10% à reviewer/debugger.

Maintenant :

• Tu peux laisser l’IA faire une bonne partie de l’écriture du code — l’étude METR de juillet 2025 montre que même les développeurs expérimentés passent nettement moins de temps à coder grâce aux assistants IA⁸.
• Tu peux aussi lui laisser faire les tests, si tu as un instinct suicidaire⁴.
• Mais ton vrai boulot, si tu veux rester employable, c’est de prendre le rôle du contre-pouvoir : le reviewer, le testeur, celui qui dit « non » quand le code a l’air propre mais sent mauvais.

Les rapports sur les compétences recherchées en 2025–2026 sont clairs : les entreprises cherchent de plus en plus des développeurs capables de relire, tester, auditer et sécuriser le code généré par IA, pas seulement de taper eux-mêmes des lignes⁹.

En gros, l’IA est le stagiaire qui code à toute vitesse. Tu es la personne qui signe en bas.

Le testing Go, ce n’est pas « écrire des tests » : c’est concevoir des preuves

La plupart des tutoriels de testing en Go tournent autour de « comment écrire un test unitaire » : créer un fichier _test.go, importer testing, utiliser t.Errorf et éventuellement faire une boucle sur quelques cas¹⁰. C’est utile, mais pas suffisant.

Dans cette série, l’ambition est différente : penser les tests comme des preuves.

Une preuve minimale que ton code :

• fait ce qu’il dit sur les chemins normaux,
• réagit correctement quand tout va mal,
• reste stable avec des inputs tordus,
• se comporte dignement quand plusieurs goroutines le maltraitent,
• ne s’effondre pas dès que quelqu’un change un détail d’implémentation.

Go te donne tous les outils pour ça :

• Le package testing pour les tests unitaires, les benchmarks et le fuzzing basique¹¹.
• Les table-driven tests pour systématiser les cas et documenter les comportements attendus¹².
• httptest pour tester tes APIs HTTP sans lancer un vrai serveur.
• Des flags comme -race pour détecter les race conditions.
• Le fuzzing intégré pour trouver des bugs que personne n’avait imaginés¹³.

Le problème n’est pas un manque d’outils. Le problème est un manque d’exigence.

L’exemple réaliste : quand l’IA teste… ce qu’elle comprend de travers

Prenons un cas un peu plus réaliste.

Tu écris une fonction qui valide des emails :

1
2
3
4
5
6
7
8
9

package validator

import "regexp"

var emailRegex = regexp.MustCompile(`^[^@]+@[^@]+\.[^@]+$`)

func IsValidEmail(email string) bool {
	return emailRegex.MatchString(email)
}

Tu demandes à l’IA : « Écris des tests unitaires pour IsValidEmail. » Tu obtiens quelque chose comme :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

package validator

import "testing"

func TestIsValidEmail(t *testing.T) {
	tests := []struct {
		name  string
		input string
		want  bool
	}{
		{"valid email", "test@example.com", true},
		{"missing at", "testexample.com", false},
		{"missing domain", "test@", false},
	}

	for _, tt := range tests {
		if got := IsValidEmail(tt.input); got != tt.want {
			t.Errorf("%s: expected %v, got %v", tt.name, tt.want, got)
		}
	}
}

À première vue : c’est propre. Table-driven test, quelques cas simples, tout passe. Tu pourrais t’arrêter là.

Sauf qu’en vrai, ce regex est ultra simpliste. Il va :

• accepter des emails avec des espaces dans le local part (hello world@example.com),
• accepter a@b.c comme valide (un domaine d’une seule lettre avec un TLD d’un caractère),
• rejeter des emails valides avec des plus (user+tag@example.com), des sous-domaines, etc.

Le problème n’est pas que l’IA a écrit un mauvais test. Le problème est qu’elle a testé ce qu’elle a compris du problème, pas ce que tu voulais vraiment. Et si toi-même tu ne sais pas vraiment ce que tu veux, tout le monde est content… jusqu’au jour où un client ne peut pas s’inscrire.

Encore une fois : ce n’est pas du testing, c’est du théâtre.

Ce que couvre cette série (et pourquoi tu devrais t’y coller)

Cette série va te prendre par la main et t’emmener d’un point A (je lance go test et je suis content quand ça affiche ok) à un point B (je suis capable de démonter en 5 minutes une suite de tests générée par IA et de dire si elle vaut quelque chose).

En gros, on va voir :

• La philosophie du testing en Go : pourquoi la standard library suffit pour 80% des cas¹⁴.
• Les table-driven tests : comment structurer tes cas de test, et comment reviewer ceux que l’IA te crache¹⁵.
• Les subtests et t.Run : comment organiser des tests lisibles et ciblés.
• httptest : tester une API HTTP sans monter un serveur complet.
• Mocking avec interfaces, Testify, GoMock : isoler les dépendances sans perdre la tête¹⁶.
• Le fuzzing natif : laisser Go casser ton code pour toi¹⁷.
• Les benchmarks et le profiling : vérifier si l’optimisation de l’IA est réelle ou cosmétique¹⁸.
• Les tests d’intégration avec Docker/Testcontainers : tester avec de vraies bases de données.
• La coverage : apprendre à l’utiliser comme thermomètre, pas comme KPI.
• La concurrence et le -race flag : trouver les bugs que l’IA adore introduire sans s’en rendre compte.

Tout ça, en français, avec du code réel, des cas extraits du quotidien d’un développeur qui bosse avec de l’IA, pas des exemples jouets.

Ce que tu peux faire dès maintenant

Si tu as lu jusqu’ici, tu peux faire un truc très simple aujourd’hui, avant même le prochain article :

1. Prends un projet Go où tu as déjà utilisé de l’IA pour générer du code ou des tests.
2. Lance go test ./... -cover.
3. Ouvre un des fichiers _test.go générés par l’IA.
4. Pour chaque test, pose-toi trois questions :
   • Est-ce que ce test casserait si j’introduisais un bug réaliste dans la fonction testée ?
   • Est-ce qu’il couvre un cas intéressant, ou juste le « happy path » trivial ?
   • Est-ce qu’il documente clairement un comportement attendu, ou est-ce incompréhensible dans 3 mois ?

Si tu te surprends à répondre « non », « pas vraiment » ou « bof » plus de deux fois, félicitations : tu viens d’identifier ton vrai boulot pour les prochains mois.

La suite

Dans le prochain article, on rentre dans le vif du sujet : les table-driven tests en Go, le pattern que tout le monde utilise, que l’IA sait vaguement imiter, et que toi tu vas apprendre à maîtriser vraiment. On parlera de noms de cas, d’edge cases, et de la différence entre un tableau de tests utile et un tableau de tests décoratif¹⁹.

Parce que oui, l’IA code. Mais toi, tu testes. Et en 2026, c’est ça qui fait la différence.

À lire aussi