Ça y est, dès le premier paragraphe, le mot est lâché. Les IA vont nous remplacer. C’est en tout cas ce qui est annoncé pour l’année prochaine de manière tonitruante sur LinkedIn et Twitter, c’est donc forcément vrai ! Juste à côté des révélations sur ces pourcentages incroyables de productivité gagné grâce à ces nouveaux outils.

Mais quelle est donc la vérité vraie ? Quel sera le jour exact de notre mise à la retraite ? Qu’allons-nous faire ensuite ? Eh bien je n’en sais rien. Je n’ai pas cette compétence en divination que d’autres semblent avoir acquis.

Pour autant, je trouve qu’il y a des réflexions intéressantes sur notre métier face à l’IA, et j’ai envie de poser mes pensées et de les partager.

Les outils actuels

Avant de s’amuser à parler du futur, regardons ce que l’on a aujourd’hui en termes d’outils pour le développeur. Je ne vais pas faire une liste exhaustive, mais plutôt un rapide tour d’horizon de quelques types d’usages aujourd’hui possible afin d’être aligné - les nouveautés vont vite.

Des chats. Avec ChatGPT comme le plus répandu et Claude comme son concurrent le plus sérieux. Il nous est possible de générer du code à partir d’un énoncé, d’apprendre un concept, de donner du code pour le modifier, de résoudre un problème en collant un morceau de code voire même un lot d’erreur ou une stacktrace. Bref, beaucoup de possibilités pour être assisté.

De la complétion de code. GitHub Copilot a ouvert le bal de l’intégration d’une IA dans les IDE pour générer la suite du code que l’on est en train d’écrire. Tantôt une simple ligne, tantôt tout le contenu d’une fonction.

Des IDEs dopés. Explique-moi ce code, refactor ce morceau, créé cette fonction, intègre ma codebase, … Ce sont quelques exemples de nouveaux usages arrivés avec des IDEs construits autour de l’IA comme Cursor.

Des sandbox. D’abord des usages simples avec ChatGPT Canvas et Claude Artifacts pour prompter sur un fichier qui se modifie au fur et à mesure, on voit maintenant des solutions comme Bolt.new qui vont générer et assembler du code puis le déployer.

Des agents. Ici, on est encore plus dans l’expérimental avec de multiples tentatives d’avoirs des agents IA qui réalisent des tâches. Puis il y a Claude qui propose depuis peu de contrôler un PC à distance pour automatiser des tâches via des prompts grâce à sa fonctionnalité Computer Use.

Des intégrations à d’autres systèmes. Les données sont très importantes pour obtenir des réponses plus pertinentes. Très récemment, Claude MCP a été dévoilé : c’est un protocole pour connecter l’IA à des services externes (notre Filesystem, Google Drive, Slack, …) et agir dessus !

Notre métier va changer

Je suis convaincu que notre métier de développeur va évoluer. Deux choses me font penser cela.

Il y a un changement extérieur - l’arrivée de l’IA. Elle apporte des nouveaux outils, de nouvelles pratiques, de nouvelles façons de faire. Il y a et aura donc des impacts. On va s’y adapter, et on va donc évoluer.

Quand on regarde le passé, c’est au final ce qu’il se passe depuis que notre métier existe - il n’a cessé d’évoluer. Entre les cartes perforées et nos postes de travail actuel, il s’en est passé des choses ! Assembleur, langages bas niveau, modernes, éditeurs de texte, IDEs, linters, frameworks, gestionnaires de version, extreme programming, etc.

C’est d’ailleurs un des aspects que j’aime dans ce métier, il évolue en permanence et on a continuellement à apprendre.

Si on est plutôt confiant sur le fait que ça va bouger, la question suivante est vers quoi va-t-on se diriger ?

Plusieurs étapes de changement

On ne passera pas d’un coup de « les devs codent » à « les IA sont magiques, construisent un produit complexe entièrement et dominent le monde ». Non, il y aura au moins plusieurs étapes avant d’y arriver (si on y arrive).

Je verrais bien quelque chose de ce genre :

• Les humains codent,
• Les humains codent et sont assistés par des IA,
• Les IA sont assistés par des humains,
• Les IA sont autonomes.

Et il y aura plusieurs sous-étapes dans « Les IA sont autonomes ». On n’arrivera pas du jour au lendemain avec des IA et des robots qui fabriquent des choses avant même que nous humains ayons conscience d’avoir besoin de quelque chose.

Je dirais qu’aujourd’hui on est dans « Les humains codent et sont assistés par des IA ». J’aime bien le nom que Microsoft a donné à GitHub Copilot d’ailleurs, ça représente bien cette étape.

J’explicite un peu avant de passer à la suite. J’ai en tête la création de produits complexes. Oui, aujourd’hui, on peut déjà créer des landing page ou des todo list basiques à l’aide de quelques prompts seulement, sans (trop) toucher au code. Mais on est loin de pouvoir faire créer le site de la Fnac, le système d’exploitation de nos smartphones, les systèmes bancaires, etc.

L’adoption est pour l’instant faible ?

Je me questionne sur le taux d’adoption auprès des développeurs. Si on met de côté le bruit créé par les influenceurs - forcément davantage en lumière que la masse - et qu’on regarde aussi de plus près la fréquence et les cas d’utilisation, j’ai l’impression que les développeurs adoptent lentement ces nouveaux outils.

J’imagine une pyramide, où plus on considère une utilisation régulière et avancée, moins il y a d’utilisateurs :

• Ceux qui connaissent,
• Ceux qui ont utilisé une fois ou deux,
• Ceux qui utilisent quelques fois chaque mois,
• Ceux qui utilisent quelques fois chaque jour,
• Ceux qui utilisent en permanence de multiples IA pour tout un tas d’usages.

C’est très subjectif par rapport à ce que je peux observer bien sûr, je n’ai aucune statistique. Mais je dirais que peu de développeurs ont un usage fort de l’IA. On est plutôt dans une phase Early Adopters. Beaucoup ont donc encore à s’équiper, apprendre, expérimenter.

Et ce n’est pas tout. Jusque-là, on parlait de l’IA à travers un prisme consommateur, mais il y a d’autres angles à considérer dans l’écosystème de l’IA avec également de moins en moins de personnes :

• Ceux qui consomment l'IA (clients),
• Ceux qui créent des fonctionnalités et des outils augmentés par de l'IA (développeurs),
• Ceux qui personnalisent une IA existante avec du fine-tuning, LoRA, RAG... (data/développeurs),
• Ceux qui créent l'IA (chercheurs).

La qualité du code sera moins importante

Les IA font aussi grincer quelques dents. « La qualité du code est nulle. Il y a des hallucinations. On va finir par ne rien comprendre. ». Il y a du vrai là-dedans. Ce n’est juste pas autant noir ou blanc comme certains laissent penser. Il faut nuancer, et ajouter une temporalité.

Je pense qu’il y a une partie d’ego qui est touchée. C’est nouveau, ça dérange, ça change, ça fait peur. Il y a de la résistance, les problèmes sont principalement mis en avant.

Mais ces problèmes existent bel et bien. Aujourd’hui, les IA génèrent des choses utiles tout comme elles vont écrire de belles conneries. Du code bien écrit, qui fonctionne mais illisible, qui ne compile même pas, qui provoque des bugs. On a un peu de tout.

Et il faut interagir avec ce code généré. On doit (un minimum) le comprendre, l’intégrer aux bons endroits dans une plus grande base de code existante. On devra le retoucher, le brancher avec d’autres composants. Il vit rarement tout seul dans son coin.

Même si on est un enthousiaste de l’IA, il ne faut pas se mettre des œillères et continuer à réfléchir. La qualité a son importance. Aujourd’hui.

Elle a son importance car on a encore besoin de lire le code, le comprendre, le manipuler. Une bonne qualité nous permet de faciliter le changement. On a besoin de faire évoluer et de maintenir notre base de code et nos fonctionnalités. Mais demain ?

S’il suffit d’écrire un prompt, ou modifier un fichier de « spécifications-prompt » pour effectuer un changement, et que l’IA est la seule à interagir avec le code, à quel point a-t-on besoin d’une grande qualité de code ?

D’un côté, le changement est facile, il suffit d’écrire des prompts. De l’autre côté, on ne met plus les mains dedans. De multiples fichiers et composants seront probablement régénérés à chaque fois par l’IA elle-même, qui n’aura pas les mêmes problématiques de compréhension de code que nous.

Un langage de programmation d’encore plus haut niveau ?

J’hypothèse qu’à un moment, la manière de communiquer avec les modèles d’IA deviendra notre nouveau langage de programmation. Quelque chose de très haut niveau, qui a de moins en moins d’aspect technique.

On peut l’observer si on regarde dans le passé. On a aujourd’hui de multiples langages de haut niveau, qui embarquent davantage de possibilités (faire des fonctions, des classes versus faire des sauts) et qui permettent de cacher / moins se soucier de certaines problématiques techniques (gérer des registres, avoir des pointeurs).

Code machine, assembleur, C, Java, Kotlin. Le prompt (peu importe sa forme et son nom) serait-il un prochain nouveau langage encore plus haut niveau ?

Il faudrait connaître sa syntaxe - facile, c’est du français, anglais, etc - et on y ajouterait quelques concepts techniques. Qui seront d’ailleurs probablement de plus en plus abstrait.

Peut-être qu’au début il faudra guider davantage, avoir les concepts et certains mots-clés assez précis « Enregistres tous les appels réseaux entrant, les erreurs HTTP, les temps de réponse. Branches sur Datadog. Je veux un Dashboard. » Puis un jour simplement « Ajoutes du monitoring, je veux un Dashboard ».

Le futur est difficilement prévisible

Je vais finir sur ce que l’on ne peut pas finir, la suite. Le futur est difficilement prévisible. Je ne suis pas devin, et personne ne l’est. Ce ne sont ici que mes réflexions à voix haute.

Ça avance tellement vite que ça pourrait arriver demain. Les IA pourraient aussi être très différentes pour que toutes nos projections soient fausses. Ou il pourrait soudainement y avoir un énorme mur. Une grosse limitation technique très dure à franchir. Une énorme régulation mondiale. Ou une grande guerre, dans un monde avec encore moins de ressources et plus de problèmes.

J’aime considérer les principes (& co) comme des guides. Ils me donnent des indications sur ce que je fais pour prendre de la hauteur. Ça m’aide à réfléchir et à me questionner. Suis-je dans une bonne direction ? Pourquoi ce principe semble m’alerter ici ? Qu’est-ce que ça va m’apporter ? De quoi ai-je besoin ? En me posant des questions, je m’assure de prendre en compte mon contexte et de m’y adapter. Je cherche aussi à bien comprendre le principe, pour qu’il me guide au mieux. Peut-être que ça ne fait pas sens de l’appliquer ici.

Un exemple avec le principe DRY (Don’t Repeat Yourself). Je viens d’écrire du code qui ressemble à un autre morceau de code ailleurs dans le projet. Le voyant DRY s’allume et me dit d’éviter la duplication. En prenant du recul, je peux me demander si c’est réellement de la duplication. Est-ce qu’ils sont dans le même domaine métier ? Est-ce qu’ils ont les mêmes raisons de changer ? À quel point est-ce identique ? Ou même, est-ce trop tôt ? Même si le principe peut m’indiquer un comportement à adopter, je prends d’abord soin de réfléchir et d’analyser mon contexte.

À l’opposé, une approche plus dogmatique des principes. On arrête de réfléchir, on ne se pose pas (trop) de questions. On applique bêtement ce que le principe nous dit. En même temps il n’y a pas à réfléchir, si le principe le dit, c’est forcément vrai. Alors on le fait. On commence même à avoir une vision binaire : je respecte ou je ne respecte pas. D’ailleurs, si je ne respecte pas, c’est évidemment mal.

En reprenant l’exemple du principe DRY, j’aurais sûrement supprimé la duplication tout de suite. Sans questionnement. Deux bouts de code qui se ressemblent ? Oula, vite ! Qu’on me supprime cette duplication ! Pourtant, il s’agissait de règles métiers de deux domaines différents. Peu de temps après, j’aurais cassé le comportement d’un des deux domaines en modifiant ce bout de code non dupliqué. Espérons qu’un test unitaire soit passé au rouge et que ce ne soit pas les retours alarmants de la prod qui auront mis en avant le problème.

Continuons de réfléchir, de creuser les principes en profondeur et de prendre en compte notre contexte. N’appliquons pas bêtement et évitons les vérités absolues.

Ma réponse est NON (sans surprise, comme la plupart des articles qui commencent avec une grande question fermée). Un développeur doit être autonome et décider de lui-même pour ce genre de pratiques. Il n’a pas à demander l’autorisation à un manager, ni un chef, ni un PO, ni un SM, ni même à un tech lead ou un autre développeur.

Encore moins se voir interdire (anecdote récente lors d’un entretien technique, un développeur m’a indiqué que son client lui interdisait d’écrire des tests parce que ça prenait du temps). Au contraire, il faut promouvoir et pousser ces pratiques aux développeurs et aux équipes.

Ça fait partie du job

L’écriture de tests, le TDD, le Refactoring, le Pair Programming, et j’en passe, ce sont des pratiques répandues dans l’industrie. Elles sont reconnues et proviennent de mouvements comme le Software Craftsmanship, l’eXtreme programming, ou le Domain Driven Design. Ce n’est pas le n-ième nouveau super framework à la mode.

On parle ici de pratiques qui améliorent la qualité du code et du produit, qui facilite le changement, qui permettent de mieux collaborer, de mieux retranscrire le métier. Elles font partie intégrante du métier de développeur.

Un développeur n’est pas un exécutant. Il n’est pas là juste pour pisser du code. Il a un (grand) rôle à jouer pour concevoir un produit de qualité. Il existe de nombreux ouvrages sur ces pratiques et également sur la posture de développeur. Pour en citer un, Sandro Mancuso en parle très bien dans son livre The Software Craftsman.

Just do it

Je donnerais comme conseil aux développeurs de faire, de passer à l’action, d’utiliser ces pratiques. Sans attendre une permission officielle, sans aller chercher une approbation quelconque. Faites-le, tout simplement.

Il y a un proverbe qui dit Il vaut mieux demander pardon que demander la permission. Je l’aime bien, et je trouve qu’il a du sens dans cette situation. Vous êtes développeur et vous hésitez ? Lancez-vous, essayez, montrez par l’exemple. Probablement, quelque chose de bon en sortira et on ne viendra pas vous taper sur les doigts. Ce n’est pas parfait ? Vous deviendrez meilleur en continuant d’essayer et de vous améliorer.

Rappelons que le développeur a l’expertise. Il sait comment travailler, il connaît sa boîte à outils. Mon propos n’est pas d’enfermer le développeur dans sa vision - il doit rester ouvert, comme tout le monde - mais de lui faire confiance et de lui donner de l’autonomie.

Ce qui n’empêche pas de le challenger. Et quand on touche à ses limites, à sa zone où il ne maîtrise pas, on se penchera plutôt sur comment former, comment apprendre, comment expérimenter, plutôt que d’empêcher.

Former les équipes

Ça fait partie du job, d’utiliser ces pratiques, ça fait également partie du job de se former. Elles ne tomberont pas soudainement du ciel. Avis aux développeurs qui doivent faire l’effort autant qu’aux managers qui doivent investir ;)

On se forme, on forme les équipes, on expérimente, on s’améliore en continue. Le retour sur l’investissement est positif, on ira plus vite, on délivrera mieux. On veut démarrer un cercle vertueux (on apprend, on améliore le code, on change plus facilement, on livre plus vite, on satisfait davantage l’utilisateur) plutôt que vicieux (on empêche, on n’apprend pas, le code se détériore, les évolutions deviennent difficiles, on cumule des problèmes, on met du temps à livrer à l’utilisateur).

Il y a un tas de moyens pour apprendre. Quelques idées : inviter des personnes à faire un BBL, l’intervention de coachs, faire des katas seul ou en groupe, du mob-programming sur le projet, assister à des conférences, lire des livres, etc.

Casser les idées reçues

Et s’il y a du blocage, des interdictions, des permissions à demander pour utiliser ces pratiques ? J’essaierais de comprendre pourquoi, de challenger, de rappeler que ça fait partie du job, et de casser certaines idées reçues.

En rappelant la vision, la philosophie de certaines pratiques. Le refactoring, ce n’est pas un chantier de 3 mois en tunnel. Ce sont des petites étapes, ce sont des améliorations que l’on fait au quotidien, qui facilitent le changement, qui améliorent la qualité.

L’écriture de tests et le TDD, ce n’est pas plus long. C’est une aide pour le développeur, un guide pour bien retranscrire le métier, le comportement. On obtient en plus de la sérénité quand il faut effectuer des changements. On entre dans des situations où l’on ira plus vite.

Le Pair-Programming, ce n’est pas juste deux ressources humaines qui se mettent sur un poste pour travailler sur un seul problème à la fois. C’est une collaboration poussée, c’est un feedback rapide, c’est une transmission de connaissances, d’informations, c’est de l’amélioration en continue. Là aussi on entre dans des situations où l’on ira plus vite.

On améliore la qualité, on gagne du temps, on gagne de l’argent. Trois arguments que l’on peut aligner en fonction de l’interlocuteur. On pourrait citer en touche finale Accelerate, un livre qui montre, via une étude sur plusieurs années incluant de très nombreuses entreprises, qu’il y a une corrélation entre la performance technique et la performance business.