Faut-il laisser les juniors utiliser de l'IA pour coder ?

J’adore coder avec une intelligence artificielle. J’en ai déjà parlé dans un article sur mon blog (article qui a un peu mal vieilli) : l’intelligence artificielle, pour coder, donne un peu plus de sens à mon métier.

Vous pourriez alors penser que j’encourage tout le monde à utiliser de l’intelligence artificielle pour coder ? Ça dépend !

Jusqu’à assez récemment, j’ai toujours été plutôt contre l’utilisation d’assistants de code par des développeuses et développeurs junior, celles et ceux avec pas ou peu d’expérience professionnelle.

Je faisais partie de ces gens qui pensaient que pour avoir le “droit” d’utiliser une IA pour coder, il fallait avoir de l’expérience. Mais deux personnes sont venues troubler ce jugement.

La première personne, c’était mon stagiaire en fin d’études que je mentorais : il n’utilisait pas un assistant de code comme Github Copilot, mais posait beaucoup de questions techniques à ChatGPT. Et il se débrouillait plutôt bien car le sujet de stage n’était pas non plus simple.

La deuxième personne, c’est un de mes collègues de travail qui a environ 2 ans d’expérience professionnelle. Nous avons accès Github Copilot et il s’en sert régulièrement. Il se débrouille vraiment bien…

Tout cela a un peu changé mon point de vue, et j’en viens à me poser la question du titre : Faut-il laisser les juniors utiliser de l’IA pour coder ? Voyons le pour et le contre !

Pourquoi j’étais contre l’utilisation des LLMs pour les profils junior ?

La réponse simple, c’est que j’ai projeté ma façon d’apprendre : j’ai appris à coder en codant. À mon premier job, je devais écrire des générateurs de code pour faire de la transpilation de code Cobol. Je n’y connaissais rien mais j’ai appris grâce à mon ancien tech lead : il découpait l’implémentation de l’algorithme en de plus petites tâches, fournissait un environnement de travail et guidait l’architecture du projet.

Mon tech lead aurait pu tout faire lui-même, mais c’était assez chronophage et assez technique donc il me faisait confiance pour implémenter tout l’algorithme petit à petit.

Comme cela a plutôt bien marché pour moi, j’ai toujours voulu projeter cette façon un peu artisanale d’apprentissage. Mais il y a deux gros problèmes :

• Cette façon d’enseigner ne permet d’apprendre que ce que le mentor connait déjà. (embêtant)
• Dans mon exemple, un LLM m’aurait totalement remplacé aujourd’hui. (très embêtant)

Faire et refaire n’est pas une façon efficace d’apprendre, car elle ne prépare pas aux problèmes du futur, et si les progrès des IAs sont avérés, bientôt des micro-tâches qu’on aurait pu soumettre à des développeuses et développeurs juniors seront réalisables par des IA, surtout dans des catégories de problèmes que j’appelle “je sais déjà faire et j’ai besoin de le refaire mais avec des subtilités”.

J’ai tendance à croire que le futur aura de moins en moins de place en ces tâches “je sais déjà faire et j’ai besoin de le refaire mais avec des subtilités”. Je n’ai jamais été fan des missions “on veut notre propre <chose qui existe déjà>”, car la valeur ajoutée de ces applications est faible, et la coupure de budget tombe souvent de nul part.

Ce que coder avec IA implique pour les seniors aujourd’hui

Revenons à ces deux personnes qui m’ont fait changer d’avis. Qu’est-ce qui me faisaient dire qu’elles se débrouillaient bien ?

Tout d’abord, c’était la qualité d’implémentation des feedbacks : souvent, quand je faisais un retour, non seulement il était fait, mais il était fait bien plus globalement que je ne l’imaginais. La fameuse persons scout rule¹ était respectée mais sous stéroïdes. Je ne vous dis pas la quantité de dette technique traitée par des retours de relecture comme “suggestion: peux-tu en faire un Enum” et voir la-dite suggestion généralisée proprement à toute l’application.

Quand je posais volontairement des questions du genre “pourquoi as-tu utilisé ceci ?”, les discussions suivantes étaient intéressantes et plusieurs fois j’apprenais des choses.

D’autre part, je remarquais que je n’avais souvent rien de bloquant à signaler techniquement : bonne utilisation des frameworks, gestions d’erreurs “ok”, pas trop de console.log("coucou") oubliés², tests automatisés logiques. Pas mal !

Et le meilleur constat : souvent ça marchait bien !

Les seuls moments ou la junioritude³ apparaissait, c’était plutôt sur la notion d’être prod-ready. Toutes les questions de scalabilité, de séparation fonctionnelle au top, d’observabilité ou d’industrialisation de la solution n’étaient pas forcément résolues : c’est normal, c’est difficile 😮‍💨.

Quand j’ai remarqué cela, je me suis rendu compte que peut-être les juniors ont tout intérêt à savoir rapidement coder avec IA, et c’est à nous les profils senior de changer.

Je pense que nous devons adapter notre façon de travailler et changer de casquette : je suis de moins en moins convaincu par le rôle de senior en tant que “personne experte technique dans son domaine”, mais plutôt comme un profil qui alterne les responsabilités, piochant dans le management, la facilitation ou l’architecture logicielle.

Alors, faut-il recommander à fond l’usage d’assistants de code pour les juniors ?

Un peu d’antithèse

Je pense malgré tout qu’il y a des limites. Déjà, j’ai essayé de faire des recherches de l’impact des assistants de code, ou de l’IA, sur l’apprentissage ou la productivité, mais globalement je trouve tout et son contraire. Cela me donne un indicateur que la façon d’utiliser un assistant de code compte plus que l’utilisation en elle-même.

Une autre chose importante, c’est que j’ai tendance à croire que la vitesse d’évolution d’un logiciel sera toujours limitée par la capacité cognitive globale de la team : trop de changements provoqueront forcément des bouchons dans les étapes de qualité, de relecture, de tests manuels.

Une force d’une équipe, c’est sa capacité à maitriser ce qu’elle livre.⁴ Produire plus de code n’aide pas à maitriser sa delivery, et c’est pour ça que je ne suis pas totalement à fond pour recommander l’usage d’assistants de code pour absolument tout.

De plus, ces outils ne sont pas nos amis. Par exemple, connaissez-vous le concept de psychose due à l’intelligence artificielle ? Le concept est nouveau et encore peu étudié, mais c’est l’idée qu’une utilisation excessive d’un assistant conversationnel peut rendre les personnes psychotiques. Huit heures⁵ par jour de code assisté par intelligence artificielle peuvent-elles faire perdre les boulons ? Le temps va nous le dire, mais parfois je me demande si la version sans IA ne nous rend pas déjà maboules.

En plus de ne pas être nos amis, il y a un risque que ces outils ne deviennent juste plus accessibles. Comment faire quand il faut coder sans accès internet ? Ou quand votre politique sécurité interdit d’envoyer vos données à un fournisseur d’IA ? Ou juste, si votre assistant préféré disparaît du jour au lendemain, que faites vous ?⁶

La reconversion et les nouveaux entrants

Il reste une voie que je trouve totalement non explorée aujourd’hui, c’est dans le domaine de la reconversion. Pour l’instant, je n’ai pas vu de personnes qui n’étaient pas du tout développeuses dans une entreprise qui se sont mises à coder car les assistants de code le permettent. Pourtant, qui n’a jamais rêvé voir son PO corriger tout seul des bugs ? Ou qu’un de vos key-users⁷ se mette à contribuer en autonomie sur une fonctionnalité nichée ? Ou que votre designer code spontanément toutes les interfaces ?

Je pense aussi que les processus de recrutement de profils junior devraient beaucoup moins cibler les compétences techniques pures des candidats et chercher plutôt à voir la capacité à comprendre le business de l’entreprise, le genre de problématiques à venir, et voir comment les candidats appliquent leurs quelques compétences techniques à ces problématiques (avec ou sans IA).

Et pour les personnes qui commencent, ne soyez pas parnassiens. Ne pensez pas “le code pour le code”. Pensez “le code, mais pourquoi faire ?”. Cherchez à fabriquer des choses avec ce que vous apprenez. Je pense que cela vous distinguera bien plus dans un marché du travail bien en berne en ce moment…

Alors, faut-il laisser les juniors coder avec de l’IA ? De mon côté, la réponse est un “oui”. Tout le monde, quel que soit leur niveau de séniorité, peut utiliser des assistants de code pour travailler, et je pense que cela reste une bonne chose sur le moyen et long terme pour la montée en compétence des profils junior.

Mais vu comment tout change en ce moment, rien ne m’interdit de changer à nouveau d’avis plus tard…

Et vous, quel est votre avis sur cette question ? Faut-il laisser les juniors coder avec de l’IA ?