Interview avec On part en prod

Posté le - Podcast & Discussions Par Grafikart

J'ai récemment été interviewé par On part en prod au sujet de l'IA et de son impact sur l'apprentissage. L’IA permet de produire du code beaucoup plus vite, mais qu’est-ce que cela change pour le métier de développeur et son apprentissage ? Dans cet entretien, je reviens sur mon parcours de freelance et de formateur, sur ce que l’expérience nous apporte et sur la difficulté d’acquérir cette expérience quand on peut déléguer une grande partie du travail à un agent.

L'interview est aussi disponible en audio

Sommaire

00:00 Introduction
00:44 Formateur et freelance : deux métiers qui se nourrissent
02:55 La fin de Flash : ce qui reste quand les technos tombent
06:55 Un rm de trop et MongoDB : apprendre de ses erreurs
10:00 Les mêmes problèmes qu’avant, en 2 semaines au lieu de 2 ans
13:15 Senior ou junior : piloter l’IA ou être piloté par elle
15:54 Les fondamentaux à apprendre aujourd’hui
24:10 Specs et priorisation quand une fonctionnalité semble gratuite
30:01 Tech lead de ses agents ou passe-plat de l’IA
32:55 Une IA n’a pas peur : l’humain dans la boucle
36:12 Apprendre quand l’IA prend les tâches simples
42:15 Ce qu’un tuto apporte encore face à Claude
50:54 Ce sur quoi Jonathan a changé d’avis
54:32 Le conseil à contre-courant : apprendre en pratiquant
57:35 Veille, recos et origine du nom Grafikart

Formateur et freelance : deux métiers qui se nourrissent

Qu’est-ce que tes activités de formateur et de développeur freelance s’apportent mutuellement ?

Le freelance me permet d’acquérir de l’expérience sur des projets professionnels, avec des besoins concrets. La formation me donne du temps pour approfondir les outils et comprendre leur fonctionnement, ce qu’on ne peut pas toujours se permettre quand on a un impératif de production.

Si je ne faisais que de l’enseignement, je risquerais de m’éloigner de la réalité du métier. À l’inverse, en ne faisant que du freelance, je pourrais rester sur les mêmes technologies sans prendre le temps de faire de la veille, puisque ce temps n’est pas directement rémunéré. Avec Grafikart, je peux noter un sujet qui m’intéresse, réserver du temps pour l’explorer et partager ensuite ce que j’ai appris. Les deux activités se nourrissent : les projets apportent des situations réelles, et les vidéos me donnent une raison d’aller plus loin dans leur compréhension.

Développeur, un métier qui évolue en permanence

Comment as-tu vécu les changements de technologies au cours de ta carrière ?

Quand j’ai commencé, je m’intéressais surtout à l’animation. J’utilisais Flash et son langage ActionScript pour créer des interactions, des animations et des sites. L’arrivée de l’iPhone, qui ne prenait pas en charge Flash, a signé la mort de Flash et cela m’a obligé à bifurquer. Plus largement, les smartphones ont changé notre manière de concevoir les applications. Aujourd’hui, je n’utilise plus les mêmes technologies ni les mêmes méthodes qu’à mes débuts et peu des outils que j'utilisais existent encore...

Quelles compétences restent utiles malgré ces changements ?

Quand on débute, on se focalise souvent sur le langage à apprendre. Mais avec l’expérience, on se rend compte qu’on retrouve les mêmes concepts d’un langage à l’autre : des conditions, des boucles, des fonctions… Ce qu’on apprend surtout, c’est à décomposer un problème et à organiser son code pour le résoudre. Et ça, c'est de la connaissance transversale que l'on garde quel que soit le langage utilisé.

Chaque technologie permet aussi de découvrir des approches que l’on pourra réutiliser ailleurs. On se construit un ensemble de briques, un peu comme des Lego, que l’on peut ensuite assembler sur un autre socle. Ce qui persiste, c’est cette expérience de la logique, du découpage et de l’organisation du code.

La place de l'expérience

As-tu des exemples d’erreurs qui t’ont fait apprendre ?

La première concerne un serveur que je devais gérer. En cherchant des solutions sur Internet, et sans avoir une grande expérience, je me suis retrouvé à supprimer un dossier que je pensais inutile et qui contenait en réalité des éléments essentiels du système. Après la suppression, plus rien ne fonctionnait : j’avais cassé le serveur, juste avant de quitter le travail et j’ai dû passer une bonne partie de la soirée à essayer de remettre les choses en place.

Ce genre d’erreur laisse une trace. Depuis, je vérifie plusieurs fois les commandes sensibles et je préfère, quand c’est possible, passer par une corbeille avant de supprimer définitivement des fichiers. Ce sont aussi les conséquences d’une erreur qui nous apprennent la prudence.

Un autre exemple concerne MongoDB. À une époque, cette technologie suscitait beaucoup d’enthousiasme, sa souplesse nous semblait très intéressante : on pouvait enregistrer des données sans leur imposer une structure uniforme, ce qui permet plus de flexibilité et des itérations plus rapides qu'avec une base de données relationnelle classique. Mais cette flexibilité vient avec un coût que l'on avait mal évalué. Avec le temps, les données changent : on a accumulé beaucoup de données avec des structures trop différentes et faire évoluer le projet est devenu un vrai enfer.

Cela ne veut pas dire qu’une technologie est mauvaise dans l’absolu. Au début, on voit surtout les avantages mis en avant, mais il faut l'utiliser pour découvrir ses contraintes et comprendre les cas d’utilisation qui conviennent. Sans cette expérience, il est souvent très difficile d'être capable de trancher des choix techniques.

L'impact de l'IA sur le métier

Le besoin de bien cadrer le travail est-il nouveau avec l’IA ?

Pour moi, ce problème n’a rien de nouveau. Avant l’IA, quand un lead dev ou un responsable produit décrivait une fonctionnalité sans être assez précis, le développeur faisait des choix pour combler les blancs. Et à la livraison, on pouvait lui dire : "Ce n’est pas ce que j’avais demandé." Sauf que les attentes n’avaient jamais été clairement exprimées.

Il en va de même pour la cohérence du code. Si chacun réalise ses tâches sans qu’on vérifie l’organisation d’ensemble, on finit avec des morceaux qui fonctionnent différemment et au bout d’un certain temps, l’application peut devenir très difficile à maintenir, au point de vouloir tout réécrire.

L’IA accélère ce phénomène. Une demande imprécise lui laisse des blancs qu’elle va combler, sans forcément poser de questions. Et sans vérification, elle peut résoudre des problèmes similaires de façons différentes. On risque donc de retrouver en une ou deux semaines les difficultés qui apparaissaient auparavant après plusieurs années. La rapidité de production rend le cadrage et les tests d’autant plus importants.

Est-ce que seuls les développeurs expérimentés peuvent tirer leur épingle du jeu ?

On découvre encore tous ces outils, et je n’ai pas de réponse définitive. En revanche, un développeur expérimenté connaît déjà les structures, les méthodes d’organisation et les problèmes qui risquent de se présenter. Il peut préciser davantage sa demande et anticiper une partie des difficultés. Sa manière d'écrire un prompt aura un impact significatif sur la qualité de la réponse qu'il va obtenir.

Une approche intéressante que j'ai pu voir consiste à demander à l’IA de questionner l'utilisateur avant de commencer à générer du code.

Soumets l’utilisateur à un interrogatoire approfondi et sans concession sur un plan, une décision ou une idée.

Cela peut servir à une personne qui décrit un besoin métier comme à un développeur qui veut préparer l'approche technique. En posant des questions, l’agent va obtenir plus de précisions sur la demande et permettra au final d'avoir un résultat plus proche de ce que l'on attend. Mais, même avec cette manière de travailler, l’expérience va jouer un rôle significatif dans la capacité à répondre aux questions et à remettre en cause certaines recommandations.

Quand on débute, on risque davantage d’accepter la première réponse faute de pouvoir l’évaluer. C’est là que je vois une différence importante : le développeur expérimenté peut piloter l’IA, tandis qu’un débutant qui s’appuie trop sur elle risque d’être piloté par ses choix.

La place de l'apprentissage

Dans quelles compétences faut-il investir pour progresser durablement ?

Il est difficile de savoir ce qui aura le plus de valeur à l’avenir. À mon sens, la maîtrise très poussée d’un langage pourrait être moins valorisée si les IA prennent en charge une partie de l’écriture. En revanche, comprendre les grandes parties d’une application reste important.

On n’a pas besoin de commencer par étudier tous les détails du protocole HTTP, mais savoir globalement ce qui se passe quand on saisit une adresse dans un navigateur aide à comprendre ce qu'il faut mettre en place pour créer un site. De la même manière, connaître le rôle du serveur, du frontend et de la base de données permet de suivre les propositions de l’IA et de savoir quoi lui demander.

Je retiendrais surtout trois axes :

Même si on choisit de déléguer entièrement l'écriture du code à une IA, il faut pouvoir vérifier que le résultat correspond à ce que l'on voulait. Aussi, on peut imaginer que dans le futur, on cherchera plus à créer des outils pour tester et cadrer qu’à créer l’implémentation. On crée des spécifications, des scénarios de test, et l'IA code l'implémentation.

Et apprendre à faire des prompts ?

Je ne suis pas convaincu de la valeur qu’il y a à apprendre à prompter car les prompts sont très spécifiques aux outils et ont tendance à évoluer avec les agents (qui changent assez rapidement). Une astuce nécessaire avec une version peut devenir inutile, voire contre-productive lors de la sortie d'un nouveau modèle. Ce qui rend un prompt efficace, c’est souvent la capacité à expliquer clairement le besoin technique ou métier avec un contexte pertinent (comme on le ferait avec un humain finalement).

Je privilégierais donc d’abord une compréhension générale du domaine sur lequel on souhaite développer, puis des approfondissements au fur et à mesure si cela est nécessaire.

Faut-il revenir à des spécifications beaucoup plus détaillées ?

Les spécifications ont de l’intérêt, mais elles ne permettent pas de tout anticiper. Sur mes missions, il arrive souvent qu’un client découvre de nouveaux problèmes à l'usage. Il réalise qu’un élément n’est pas pratique une fois l’application devant les yeux, et je ne pense pas qu’il aurait forcément pu le prévoir.

On peut demander à un agent de poser beaucoup de questions avant de commencer. Mais, pour certaines réponses, on a surtout besoin d’essayer. Il reste donc nécessaire de faire des allers-retours entre développeur et utilisateur.

Je remarque aussi une tendance qui est un peu contre-productive :

La capacité à produire plus vite permet-elle d’obtenir plus vite du feedback ?

Oui, mais je vois aussi un risque : un déplacement permanent de la fin. Dans les projets, les contraintes de budget imposaient de décider ce que l’on choisissait de livrer ou non au fil des versions. Avec les agents, une fonctionnalité peut sembler ne presque rien coûter, ce qui retire donc ce besoin de trier et on finit par vouloir ajouter toutes les idées qui viennent, sans vraiment les prioriser.

On se retrouve alors avec un produit qui peut grandement changer au fil des versions sans vision cohérente et cela impacte l’utilisateur final. On a tous déjà vu ces applications qui se remplissent de fonctionnalités plus ou moins utiles et qui finissent par devenir inutilisables avec le temps. Avoir une vision du produit devient essentiel quand la facilité apparente de réalisation encourage à tout implémenter.

Est-ce qu’on va tous devoir acquérir des compétences de tech lead ?

Je ne sais pas encore comment les organisations vont évoluer. Sur un projet important, une seule personne ne pourra pas forcément piloter les agents et relire / évaluer tous les changements : elle risque d’être rapidement débordée. On peut donc imaginer conserver une répartition du travail, avec des développeurs qui précisent un ticket, utilisent l’IA pour le réaliser et vérifient la fonctionnalité concernée.

Ce qui m’inquiète davantage, c’est le profil qui se contente de prendre le ticket, de le transmettre à l’IA, puis de renvoyer le résultat. On devient alors une interface entre les systèmes et l’agent, sans vraiment apporter de jugement sur le travail réalisé (un "meat proxy" comme disent les Anglais).

Les compétences de cadrage et de coordination vont probablement prendre plus de place. Mais cette valorisation existait déjà dans les entreprises où les perspectives d’évolution conduisaient systématiquement vers le lead ou le management.

Qu’est-ce qui distingue la prudence d’un humain du comportement d’un agent ?

Quand on fait une grosse erreur dans une entreprise, on sait qu’il y aura des conséquences, et cette peur a un effet sur notre manière d’agir et nous évite de faire n'importe quoi. Une IA peut supprimer des données et passer à autre chose en un clin d’œil et ne subit pas les répercussions comme nous.

C’est une des raisons pour lesquelles je pense qu’on a besoin de garder un humain dans la boucle : quelqu’un qui puisse mesurer les conséquences d'une action avant de l'accepter ou de la refuser. Si on laisse trop d'accès à un agent, une simple mécompréhension de l'objectif d'un prompt peut avoir des conséquences catastrophiques (et on a déjà vu cela se produire dans les labos d’OpenAI ou d’Anthropic). Il faut être en mesure de comprendre ce dont va avoir besoin l'agent mais aussi comprendre lorsqu'il va demander des permissions supplémentaires pour ne pas lui permettre de faire des actions qui auraient des conséquences catastrophiques.

Cela nous amène à un compromis difficile à trouver :

Et pour le moment, il n'existe pas à ma connaissance de système fiable pour contrôler finement les comportements des agents.

Comment acquérir de l’expérience si les tâches confiées aux débutants sont désormais réalisées par l’IA ?

La problématique de l'apprentissage se posait déjà par le passé avec les frameworks notamment. Pour apprendre, on réalisait des exercices qui représentaient des tâches que l'on ne fait pas au quotidien dans un cadre professionnel.

Par exemple, on apprend assez tôt les algorithmes de tri ou des structures de données spécifiques, mais dans les faits, il y a souvent des fonctions déjà conçues pour ça dans les différents langages de programmation. L’IA augmente considérablement la quantité de tâches que l’on peut déléguer, mais faire les choses à la main a toujours un intérêt d’un point de vue pédagogique.

Si votre objectif est d’apprendre, j’aurais tendance à conseiller de ne déléguer que ce que vous savez déjà faire. Une fois que vous comprenez un mécanisme et que vous êtes capable de le reproduire, vous pouvez choisir de l'automatiser avec l'IA. Si vous l'utilisez pour produire du code que vous ne comprenez pas, n'hésitez pas à demander des explications pour comprendre les parties qui restent floues.

Concrètement, on peut :

Je ne pense pas qu’il soit réaliste de demander à tout le monde d’apprendre sans jamais utiliser ces outils. Mais il faut distinguer l’objectif de produire une application de celui d’apprendre à la développer. Obtenir une application qui fonctionne ne garantit pas que l’on ait acquis des compétences pour la suivante.

À quoi servent les moments sans IA ?

Même avec plus de quinze ans d’expérience, je constate qu’en déléguant tout, je pratique moins et je perds certains réflexes. Pendant l’apprentissage, essayer de développer une fonctionnalité de manière autonome permet de vérifier que l’on a compris les choses de bout en bout. Cela évite de garder des zones d’ombre pour lesquelles on ne comprend pas l'organisation, la logique ni les choix techniques.

Comprendre son application peut aussi aider à guider l’agent plus précisément. Si je sais où se trouve un problème, je peux orienter sa recherche au lieu de lui demander d’explorer tout le code. Dans l’hypothèse où les tokens deviendraient plus coûteux, cette compréhension pourrait aussi avoir une valeur économique car elle permet d'être plus efficace pour un coût similaire.

Qu’apporte un tutoriel de 20 ou 30 minutes face à une réponse obtenue en quelques secondes ?

C’est une vraie difficulté pour un site comme le mien. Pendant longtemps, j’ai cherché, à travers mes vidéos, à expliquer ce que j’aurais aimé qu’on m’explique quand moi, j’ai appris.

Aujourd’hui, les IA permettent d’obtenir une réponse personnalisée et adaptée à sa problématique en un clin d’œil (réponse qui, ironiquement, peut s’appuyer sur des contenus comme les miens). Elles peuvent adapter une explication à chaque apprenant : reprendre un point, le détailler et répondre immédiatement à une incompréhension. Une vidéo ne peut pas offrir cette individualisation. L'apparition de l'IA a donc grandement diminué la valeur des tutoriels et ce qui est assez frustrant, en tant que créateur, c'est de voir ses contenus utilisés par ces modèles sans une rétribution correcte.

Malgré tout, ce que je souhaite continuer à apporter, c’est surtout un retour d’expérience. L’IA peut nous résumer les retours d’expérience qu’elle a trouvés sur Internet, mais elle n’a pas elle-même travaillé sur ces projets et elle ne fait que recracher les retours d'expérience d'autres personnes. De notre côté, on apprend en faisant : on rencontre des problèmes, on fait des erreurs et on en tire des leçons que l'on partage ensuite avec les autres développeurs. Sans ces sources d’expérience, l’IA serait incapable de trancher entre plusieurs choix.

Qu’est-ce qui aide les équipes que tu accompagnes à progresser ?

Là aussi, c’est le partage d’expérience. Une équipe qui découvre le web peut se retrouver face à une quantité de technologies et d’approches difficiles à appréhender. Mon rôle consiste à présenter les possibilités, leurs avantages et leurs contraintes, et à éviter de perdre du temps sur des pistes qui ne conviennent pas au projet.

L’architecture compte également : une organisation adaptée facilite la lecture, la maintenance et l’anticipation de problèmes de performance. Un code organisé de manière cohérente aide les humains, mais permet aussi de mieux guider les agents. On peut ensuite formaliser certaines conventions dans des skills pour automatiser des tâches récurrentes sans perdre en qualité. Ce que les entreprises viennent chercher, c’est notamment cette capacité à faire les choix plus rapidement et à éviter des erreurs déjà rencontrées ailleurs.

Quelle leçon tirer de mon expérience ?

Sur quels sujets as-tu changé d’avis au cours de ta carrière ?

J’ai longtemps cherché à rendre le code aussi flexible et réutilisable que possible. Avec l’expérience, j’accorde davantage de valeur à des solutions plus simples. Sur certains projets, les couches d’abstraction finissent par rendre le code plus difficile à déboguer et à faire évoluer pour une flexibilité que l'on n'utilisera finalement jamais.

Cela ne veut pas dire qu’il faut renoncer à toute abstraction, mais qu’il faut adapter la complexité à la situation. Je suis devenu plus pragmatique : rechercher immédiatement la solution la plus générique n’apporte pas toujours le meilleur résultat.

J’ai aussi changé d’avis sur des technologies. Par exemple, je n’aimais vraiment pas du tout React quand je l'ai découvert pour la première fois, alors que c'est une de mes technologies front-end principales aujourd’hui. Les outils et leurs usages évoluent, et il faut accepter de les réévaluer de temps en temps. On peut avoir des opinions sans rester campé dessus au point de se priver de nouvelles solutions.

Quel conseil donnerais-tu qui va à l’encontre de ce qu’on entend habituellement ?

Pour apprendre, je conseillerais de partir de la pratique. On entend souvent qu’il faut commencer par les fondamentaux, apprendre un langage de bas niveau et savoir comment tout fonctionne avant de passer à ce que l'on va finalement utiliser. Personnellement, les notions génériques prennent surtout du sens lorsque je les utilise pour résoudre un problème.

Donnez-vous un objectif que vous ne savez pas encore atteindre, puis décomposez les difficultés en cherchant à comprendre les éléments qui vous manquent à chaque fois. C’est de cette manière que j’ai commencé. Je voulais publier des vidéos de diabolo :

Cette méthode peut être frustrante. On se heurte régulièrement à des murs et ce n’est pas forcément le chemin le plus efficace pour tout le monde. Mais on avance vers un résultat qui est motivant, avec des problèmes concrets auxquels rattacher ce qu’on apprend. À l’époque, il n’y avait pas l’IA, mais j’imagine qu’aujourd’hui, ça peut être encore plus efficace car on peut l'utiliser pour s'aider à débloquer certaines étapes (à condition de garder cet effort de compréhension).

Il faut aussi accepter de mal faire au début. Nos premiers projets ne sont pas toujours propres, optimisés ou exempts de failles. Cela fait partie de l’apprentissage. Pour comprendre comment mieux faire les choses, il faut souvent les avoir mal faites plusieurs fois. Mon conseil reste donc de pratiquer en acceptant que ce que l'on fait ne soit pas parfait tout de suite.

Comment fais-tu ta veille ?

Je n’ai pas de méthode très organisée. Je pars du principe que si une technologie devient suffisamment importante, j’en entendrai parler, mais dans mon cas, la communauté joue un rôle important car on me demande souvent mon avis et ça me permet de découvrir des technologies plus rapidement (sur le Discord du site ou via les commentaires YouTube).

J’utilise aussi Twitter en suivant principalement des développeurs, ainsi que HackerNews. Ensuite, la préparation des contenus me donne l’occasion d’approfondir les sujets qui retiennent mon attention.