Comment garder le plaisir de coder à l'ère de l'IA ?
Chez INOCO, l'IA est un outil qu'on maîtrise, dont on se sert au quotidien dans nos missions comme à l'agence. Reste une autre question : que reste-t-il du plaisir de développer, de résoudre un problème par soi-même ? C'est un sujet qu'on a mis sur la table avec Camélia et Quentin, deux software engineers chez INOCO.
Alors pour commencer, on a voulu comparer nos deux visions : d'où vient exactement le plaisir de coder, et d'où vient celui de travailler avec l'IA ? Ce constat nous a amenés à vous proposer des tips pour garder le plaisir de coder sans se laisser dépasser par l'IA, et même pour rester au top des nouveautés et des manières de travailler.
D'où vient le plaisir de coder ?
La résolution de problème
Se challenger pour débusquer ce petit bug, cette ligne de code cachée au milieu d'un gros projet. Comprendre enfin la cause du problème et ressentir cette vraie satisfaction d'avoir pigé et appris. C'est un système de récompense bien humain. Si on délègue tout à l'IA, le métier de software engineer glisse vers autre chose : un rôle d'architecte ou de designer où l'on se contente de donner des consignes ("fais ceci, fais cela") sans vraiment réfléchir au problème.
C'est exactement le glissement qu'on détaillait dans notre article sur le passage de développeur à software engineer.
L'apprentissage
Il y a aussi une perte plus discrète : celle de l'apprentissage. Quand on retombe sur un problème déjà croisé, on se souvient souvent de l'avoir vu, mais pas de la solution. Pourquoi ? Parce que l'IA nous l'avait donnée sur un plateau au lieu qu'on la cherche par nous-mêmes. C'est en tâtonnant et en faisant des erreurs qu'on retient vraiment.
La fierté d'artisan et le sentiment de maîtrise
Le plaisir de coder, c'est aussi le côté "fait main" : la fierté d'avoir conçu une mécanique propre, élégante et optimisée par soi-même. Il y a un côté très satisfaisant à garder le contrôle total sur son code, à savoir exactement ce que fait chaque ligne et à sentir qu'on maîtrise son sujet de A à Z.
Le « Flow » et l'état de création
Et puis, il y a ce fameux état de "flow" : ce moment où on est tellement plongé dans son code qu'on ne voit plus le temps passer. On crée quelque chose en partant d'une page blanche, on voit l'idée prendre forme sous nos yeux. C'est un plaisir purement créatif qu'aucun prompt ne peut remplacer.
D'où vient la satisfaction de travailler avec l'IA ?
Corriger du code qu'on n'a pas écrit soi-même
Analyser une erreur perdue dans une procédure de 3 000 lignes qu'on n'a pas écrite, ou migrer une application vers des versions supérieures de Java ou de Spring pour corriger des failles de sécurité. Une opération qui prenait auparavant trop longtemps à vérifier dans tous les sens. Avec l'IA, "elle couvre déjà pas mal de choses [...] elle fait déjà une bonne partie du travail en une heure" Camélia. Mais elle ne fait pas tout : c'est là qu'un software engineer expérimenté repère ce qui a été oublié, ce qu'il faut encore vérifier et reste indispensable.
Le squelette d'un projet
Sur un nouveau projet, l'IA sert à poser rapidement le squelette de base : la structure, les premiers fichiers… pour aller vite sur ce qui ne demande pas vraiment de réflexion.
La documentation (parce que personne n'aime ça)
"Personne n'aime documenter son travail." Quentin. Sur ce point-là, l'IA a changé la donne : ce qui prenait un temps fou est devenu rapide et pratique.
Automatiser les tests
Même logique sur les tests unitaires : l'IA doit être utilisée pour accélérer et déléguer cette partie fastidieuse.
C'est le conseil qu'on donnerait à un collègue réfractaire : commencer par laisser l'IA gérer les tâches sans valeur ajoutée et chronophages documentation, tests unitaires, plans de migration.
D'ailleurs, plus un projet est gros, plus l'IA a besoin d'un contexte précis pour donner une réponse rapide et pertinente, et plus il redevient nécessaire de se creuser la tête.
En résumé, garder la valeur ajoutée, éliminer le chronophage
La solution : garder son terrain de jeu
Pour garder l'apprentissage et ne pas perdre la main, il reste utile de conserver une part de code qu'on écrit soi-même, sans demander à l'IA, surtout sur du nouveau code, quand la direction n'est pas encore claire. "Je découvre, je tâtonne le terrain, je vois mon bébé grandir et prendre vie", résume l'un des deux.
On peut y voir un intérêt du même ordre à se garder des projets sans urgence, sur lesquels on peut prendre le temps de comprendre au lieu de demander directement, et se laisser le temps de résoudre les problèmes.
Rester à jour sans se laisser déborder
L'IA n'est pas un effet de mode : elle est déjà incontournable pour un software engineer, et elle va continuer d'évoluer vite. Impossible de s'appuyer uniquement sur ce qu'on sait déjà : il faut faire sa veille, régulièrement, et comprendre ce qui se passe.
Faire sa veille IA
Quentin le fait mensuellement, c'est pour lui le minimum : newsletters spécialisées, sélection hebdomadaire d'articles Medium, et conférences comme la NG Baguette Conf ou Devoxx - pour ne pas se réveiller un jour avec dix ans de retard, tant les pratiques évoluent vite.
De nouvelles méthodes de management
Certains clients envisagent, ou ont déjà mis en place, des mesures pour analyser la part de code écrite par un software engineer par rapport à celle générée par l'IA. Un signal à ne pas ignorer pour les managers qui accompagnent leurs équipes sur le sujet : la façon dont l'IA est mesurée et valorisée en interne change aussi la façon dont elle est vécue par ceux qui l'utilisent au quotidien. C'est typiquement le type d'accompagnement qu'on retrouve dans notre stratégie IA : pas seulement outiller les équipes, mais les aider à garder ce qui fait le sel du métier.
Ce qu'on en retient
Il ne faut pas renoncer à l'IA et le plaisir de coder n'est pas obligé de disparaître pas avec l'IA, il se déplace : vers les projets qu'on garde pour soi, les problèmes qu'on choisit encore de résoudre à la main, et la veille qu'on continue de faire pour ne pas décrocher.
