Est-ce la fin des codeurs ?

On se posait la question : faut-il craindre l’IA ?

Mais plus égoïstement, pour nous, pour nos métiers de développement logiciel, et plus généralement pour tous les métiers dont la fonction est de générer de l’information “abstraite”, “numérique”, “intellectuelle”… qu’en sera-t-il ?

Il est évident que les besoins en nombre d’employés sont bel et bien impactés, chez les traducteurs par exemple. Ce constat semble poindre aussi dans les métiers de l’informatique qui, ironie de l’histoire, sont à l’origine de l’IA et parmi ses plus enthousiastes utilisateurs ! Notamment, les jeunes qui doivent acquérir de l’expérience sont en difficulté sur le marché, comme s’ils n’étaient plus considérés comme un investissement rentable au sein des entreprises. Il suffit d’écouter les hauts dirigeants pour se rendre compte que les chiffres, et leurs discours affirmatifs, ne peuvent vraiment pas inviter à l’optimisme.

Mais l’IA est-elle vraiment responsable ? N’a-t-elle pas bon dos comme bouc émissaire, alors que les raisons peuvent être avant tout d’embaucher là où c’est le moins cher, dans une période un peu bousculée avec la montée en puissance de la Chine, de l’Inde, et dans un monde capitaliste guidé par la croissance sans fin et la recherche de profit pour satisfaire les actionnaires… en retraite…

Par contre, une crainte (très relative car il y a plus grave) qu’on peut raisonnablement avoir, c’est qu’il y ait moins besoin de développeurs. On le sait, on le vit tous les jours : une petite équipe dynamique est plus efficace qu’une grosse équipe qui passe son temps en réunion à se concerter. Il y a une taille critique des équipes que la méthode SCRUM a su définir. Dans ma petite boîte de service, il y a bien longtemps, on était parfois que deux ou trois par projet : un chef de projet, un dev, un testeur… Puis, on s’est rendu compte qu’on était quand même plus intelligents à plusieurs développeurs. Une équipe Scrum est donc souvent constituée de cinq personnes, ni trop, ni pas assez… en dessous, on ne peut pas s’aider, au-delà, ça crée trop d’inertie.

Est-ce qu’avec les assistants IA, on pourrait à nouveau réduire ces équipes ? Si oui, mathématiquement, une solution serait d’avoir plus de micro-équipes plutôt que de réduire les effectifs. Cela donnerait la possibilité de réaliser plus de choses, de modules, plus de logiciels dans le même temps imparti…

Rappelons quand même que le codage pur et dur ne nous occupe peut-être que 10 % d’une journée (certainement variable en fonction de la taille de l’entreprise). Il y a les temps de ‘refinement’, les brainstorming, les transferts de compétences, les présentations, la documentation, les revues de code, les bugs à corriger, les tests d’intégration parfois inconstants, les problèmes terrain que le support peut soumettre en dernier recours … Et si le logiciel est gros, répartir sa complexité entre plusieurs micro-équipes assistées par IA et travaillant en // nécessite quand même des points de synchronisation et une bonne gestion globale, ce qui peut déplacer l’inertie et ne pas garantir une livraison accélérée.

Mais en admettant qu’on aille plus vite, encore faut-il qu’il y ait encore et toujours des besoins ; or les budgets ne sont pas toujours extensibles et le logiciel est un outil qui n’a pas forcément toujours besoin d’être amélioré ou remplacé une fois qu’il fonctionne et que ses utilisateurs s’en accommodent (Quoique l’informatique sait très bien surfer sur les paradigmes du capitalisme, l’obsolescence programmée, la création du besoin et l’amélioration continue au prix d’un effort marketing plus élevé que la réalisation elle-même).

Ce qui est certain, c’est que jusqu’à présent, l’informatique a toujours été présentée comme un sacré vivier d’emploi ! Combien de fois a-t-on pu lire que la France manquait d’informaticiens et d’ingénieurs ! Ces métiers ont été fortement valorisés lors du parcours d’études, au détriment des métiers plus “manuels” : électriciens, plombiers, agriculteurs, etc…

Bouc émissaire ou réalité, l’IA est bien pointée du doigt aujourd’hui dans la conscience collective… Quand on me demandait ce que je faisais il y a peu et que je répondais informaticien, il y avait comme des petits $ qui apparaissaient dans les yeux de celui qui posait la question… Parfois avec une pointe d’envie ou de jalousie. Maintenant, la réaction se montre plutôt désolée, avec la mine de circonstance : “Ha ? Avec l’IA, ça va pas disparaître ? …”. Bah oui, sans doute, comme tout…

Mais bon, je me souviens avoir souvent entendu ça depuis 30 ans : “Il n’y aurait bientôt plus besoin de développeurs”. Or, le métier est toujours là, en perpétuelle évolution avec les technologies et les innovations. Au début c’étaient les cartes perforées puis l’assembleur, déjà plus accessible, mais ça restait long et fastidieux. Ensuite, les langages structurés de haut niveau sont arrivés, facilitant l’écriture, la maintenance et la fiabilité, le langage C par exemple, qui fait pourtant aujourd’hui office de langage machine ! On est toujours le langage machine de quelqu’un 😄 ! De même, on disait qu’avec le langage Basic, un enfant de 13 ans pouvait programmer comme un ingénieur barbu, velu et pointu en assembleur ! Ne dit-on pas un peu la même chose avec l’IA ? Tout le monde peut écrire un logiciel ! N’est-ce pas ?

Au début de ma carrière, je me souviens de séminaires Microsoft avec leurs lots de démonstrations “no code” à coup de Wizards faisant miroiter aux commerciaux de quoi se réconcilier avec leurs développeurs, dont la productivité allait enfin bondir en avant !

Ensuite, les frameworks réutilisables, open source, les forums sur Internet, tout ça a quand même simplifié le travail même de codeur… Simplifié ? Non, la difficulté s’est déplacée…

Car, avec cette panoplie immense de frameworks, pas facile de s’y retrouver, de choisir le bon, de savoir où porter l’effort. Sans même parler d’IA, on ne pourrait plus se passer d’Internet qui fourmille d’exemples de code, où l’on trouve presque toujours une réponse car quelqu’un s’est posé la même question avant nous. Il y a des choses qui ne s’inventent pas et réinventer la roue est même plutôt mal vu car perte de temps ! On ne peut plus être fier de penser avoir inventé un composant ou un bout de framework s’il existe déjà ailleurs, testé, documenté, libre (enfin sous licence MIT), voire même payant. Et heureusement ! s’il fallait reprogrammer systématiquement de simples tris ou des recherches dans des chaînes de caractères comme on le faisait à la grande époque en langage C, on n’avancerait pas beaucoup. Ce qui n’empêche pas de savoir le faire, de l’avoir déjà fait au moins une fois ou, à défaut, de comprendre comment ça marche.

Et puis, pas simple de rester à la page ! De nouveaux frameworks sortent régulièrement, chassant les plus anciens dans le triste tiroir de la dette technique. C’est pourquoi, au sein des entreprises, quand il s’agit de construire un logiciel au long cours, mettre en place une couche technique stable sur laquelle on puisse construire le fonctionnel (en séparant bien les responsabilités) est un gage de maintenabilité et d’évolutivité ! Et c’est loin d’être gratuit, même si cette couche technique “ne fait qu’encapsuler” des frameworks divers et variés venant de l’extérieur.

Reconnaissons-le ! aujourd’hui, avec l’IA, plus besoin de chercher trop longtemps ! Même sans poser la question au chatbot intégré dans l’éditeur Visual Studio, qui n’a pas été surpris de voir son code se compléter directement avec l’implémentation d’une routine entière correspondant pile-poil à ce qu’on désire ? Performant et bluffant.

Le rôle du codeur devient de plus en plus un métier d’assembleur de technologies. Je pense même que le terme Architecte, même s’il a été introduit surtout pour valoriser les plus expérimentés, correspond mieux à ce que fait et fera de plus en plus tout codeur. On aurait pu choisir metteur en TechScène de ce petit théâtre où jouent composants, services, bases de données, infrastructure, tests, documentations…

De là à promouvoir le vibe coding ?…

Vaste débat…

Ceux qui ne codent plus depuis longtemps le reconnaissent : on rouille très vite. Si l’on perd la maîtrise du code, saura-t-on comprendre ce qui dysfonctionne ? Corriger les bugs ?

Concevoir un programme, c’est être comme un compositeur qui écrit les notes de musique sur une partition, bien plus efficace que le langage naturel pour exprimer ce qu’il a en tête et pour le communiquer.

De même, rien que d’organiser le code, penser à sa maintenabilité, appliquer les principes de conception, c’est une démarche intellectuelle qui doit rester de notre ressort, au risque d’atrophier complètement ce fantastique ordinateur naturel embarqué dans notre boîte crânienne, en ne lui donnant plus suffisamment de grain à moudre.

Malgré ça, est-ce que le codage n’est pas voué à devenir un hobby de peintre du dimanche ? Et surtout, aimera-t-on encore notre métier ? La plupart des développeurs et architectes sont avant tout des personnes qui sont tombées dans la marmite étant petits, en codant !

Wait and see, seul l’avenir nous le dira…

En attendant, utilisons l’IA, mais raisonnablement, avec parcimonie, sans perdre le goût de l’effort intellectuel. Ne soyons pas fiers d’avoir fait travailler l’IA à notre place. Courir 5, 10, 20, 40 km, c’est plus dur que de prendre sa voiture, mais quand on y arrive, c’est une vraie source de plaisir et de satisfaction…