Faut-il encore apprendre à coder ?

C'est la question qu'on nous pose le plus souvent, généralement par un parent dont l'enfant hésite sur ses études, parfois par un chef d'entreprise qui se demande s'il doit encore recruter des développeurs. La formulation varie, l'inquiétude est la même : à quoi bon apprendre une compétence qu'une machine exécute mieux et plus vite ?

La réponse courte est oui, mais pas pour les raisons qu'on avance d'habitude, et pas de la même manière qu'il y a cinq ans.

Pourquoi la question est mal posée

« Apprendre à coder » désigne deux choses très différentes qu'on confond systématiquement. La première est la syntaxe : savoir écrire une boucle, connaître les méthodes d'un tableau, se rappeler comment on ouvre un fichier. La seconde est le raisonnement : décomposer un problème flou en étapes exécutables, anticiper ce qui va casser, décider ce qu'on ne fait pas.

La première compétence perd effectivement de sa valeur, et c'est une bonne nouvelle : elle n'en avait jamais beaucoup. La seconde en gagne, parce qu'elle devient le seul endroit où un humain apporte quelque chose que la machine n'apporte pas.

Juger est plus difficile qu'écrire

On sous-estime à quel point relire est exigeant. Écrire du code impose sa propre discipline : on avance pas à pas, chaque erreur bloque, le compilateur proteste. Relire du code déjà écrit, cohérent et bien présenté ne déclenche aucun de ces signaux. Il faut aller chercher activement ce qui manque.

Or ce qui manque est précisément ce qu'on ne pense pas à chercher quand on n'a jamais eu à le construire soi-même. On ne remarque l'absence de gestion d'erreur que si on a déjà passé une nuit sur une panne due à une gestion d'erreur absente. La capacité de jugement se construit par l'écriture, même si elle finit par la remplacer.

C'est le paradoxe de la situation actuelle : il faut avoir écrit beaucoup de code pour pouvoir se permettre de ne plus en écrire.

Ce qui change dans l'apprentissage

Nous ne pensons pas qu'il faille apprendre comme avant. Trois choses nous semblent avoir changé de poids.

• Mémoriser la syntaxe ne sert plus à rien. Le temps passé à retenir l'ordre des arguments d'une fonction est du temps perdu, et il l'était déjà avant.
• Lire du code devient l'exercice central. Un bon exercice aujourd'hui consiste à faire générer une solution, puis à trouver ce qui cloche — et il y a toujours quelque chose.
• Les fondations comptent davantage, pas moins. Ce qu'est une requête, ce qu'est une transaction, pourquoi un cache s'invalide : ces notions expliquent les erreurs que l'IA produit, et elles ne se déduisent pas du code généré.

Et pour recruter ?

La question sous-jacente est souvent : peut-on remplacer un développeur par un non-développeur équipé d'une IA ? Notre expérience dit non, mais pas pour la raison attendue. Le non-développeur produit très bien la première version. Il bloque à la deuxième, quand il faut modifier l'existant sans tout casser, et il n'a aucun moyen d'évaluer si le résultat est sûr.

En revanche, la composition des équipes change. Un développeur expérimenté couvre aujourd'hui un périmètre que trois personnes couvraient hier. Ce n'est pas la disparition du métier, c'est sa concentration : moins de postes juniors sur des tâches d'exécution, et un besoin accru de gens capables de dire non à une architecture séduisante.

Notre réponse

Oui, il faut encore apprendre à coder, en acceptant que l'objectif a changé. On n'apprend plus pour produire du code : on apprend pour être capable de juger celui qui est produit, d'en comprendre les défaillances et de décider ce qui mérite d'exister.

Autrement dit, on apprend à coder pour la même raison qu'on apprend à cuisiner alors qu'on peut commander : pas pour se nourrir, mais pour savoir ce qu'on mange.