Par Ludivine Crépin, doctoresse en intelligence artificielle et auteur aux Editions ENI

Au fur et à mesure des années, je prends de plus en plus peur sur le niveau des développeurs et surtout sur celui des prochains développeurs, qu’ils soient front, back, fullstack ou autre qualificatif à venir. Non pas qu’ils seront incapables de faire leur travail, juste que la plupart risquent de mal de faire, avec un code non performant, un code non maintenable, des effets de bords sans même sans rendre compte.

Nous pouvons trouver plusieurs raisons à cette baisse de niveau et une des premières vient que les développeurs se reposent trop sur la machine et oublie leur compétence première : leur réflexion ! Gavé d’outils dit intelligents, notre métier ne nous encourage plus à prendre du recul ou même à réfléchir.

Je conçois parfaitement que l’évolution de notre métier nous facilite énormément la vie et nous permet de développer plus rapidement grâce notamment aux frameworks pour ne pas réinventer la roue, à l’auto-complétion, à l’IntelliSense et grâce à des solutions comme Copilot. Seulement il nous faut vraiment mesurer les risques de ces outils.

Ne nous mentons pas, il est plus qu’agréable de ne plus à avoir coder les algos de tri (bon je pousse le bouchon un peu loin ici), de ne plus se soucier des coquilles dans nos identifiants, d’avoir nos boucles prémâchées, etc… Mais je me rends compte depuis quelques années des dérives de ces outils si pratiques qui sont mal utilisés par manque de maîtrise sur la base du développement, l’algorithmie, et les langages de programmation.

Je vais étayer mes propos avec quelques exemples que j’ai pu rencontrer en tant que consultante freelance, qui vont faire hurler les « vieux » développeurs et pour lesquels les « jeunes » développeurs ne verront pas forcément de problèmes. Je n’en citerai que quelques-uns mais je rencontre ce type de problèmes quasiment tous les jours :

Récemment, il m’est arrivé de poser une simple question à un développeur : quelle est la différence entre un for et un while ? Une bouche bée en guise de réponse, aucune explication de quand utiliser un for et quand un while… Pourtant, cela concerne la base du développement : un for pour compter ou itérer, un while pour respecter une condition. Ce développeur a même pris connaissance du do while ce jour-là…

Autre cas,un refacto de code car l’application étaient très lente. Ici encore un problème de boucles très basique : aucune boucle for, uniquement des while(true) avec un break pour casser la boucle… Non, je ne mens pas… Ce développeur est bien en poste et il est même considéré comme compétent par ses supérieurs, et heureusement pas par ses collègues…

L’IDE, vrai faux ami ?

Continuons avec l’IntelliSense et l’auto-complétion ou pire les outils comme Copilot. Combien de code dois-je déboguer car le développeur a instauré, par manque de recul et de compétences, la règles : si l’IDE le propose, l’IDE a forcément raison ? Dernier exemple en date, bug sur une chaîne de caractères : les premiers caractères qui sont des espaces sont supprimés. Je reprends donc le code avec le développeur lui laissant le clavier et là c’est moi qui suis restée bouche bée.

Je lui demande simplement d’afficher cette chaîne au fur et à mesure des traitements pour voir quelle instruction devait être corrigée. Au lieu de commencer à taper les instructions, je le vois s’acharner sur la touche tab jusqu’à ce qu’une proposition lui semble correcte. Je rappelle, il devait juste coder un simple print.

Au bout donc de quelques minutes, on trouve la ligne et là, au lieu de la relire, il l’efface et recommence avec ces satanées tabulations. Il écoute tellement bien l’Ide qu’il ajoute un trim à la fin. Je luis demande ce que fait le trim, et il me répond « je ne sais pas c’est l’IDE qui le propose donc c’est forcément juste ». Syntaxiquement, oui aucune erreur, mais l’IDE ne peut pas savoir ce que doit faire le code au niveau business, arrêtez de penser que l’ordinateur ou les IA sont intelligentes… Oui, le problème est toujours entre le clavier et l’écran surtout lorsque l’on code…

Un jour, nous sommes lancés un défi de code avec un ami « vieux » développeur avec la contrainte d’utiliser uniquement un éditeur de texte, IDE interdit. Il s’agissait d’un simple programme utilitaire de tri de fichiers et répertoire avec renommage. Se servant abusivement de copilote au travail, mon ami n’a pas réussi à coder ce programme sans d’énormes difficultés : ses réflexes de codeur avaient tous disparu et le simple fait d’écrire une boucle for était devenu long et compliqué. Encore une conséquence lourde de trop se reposer sur la machine : l’oubli de ses propres compétences.

Je ne rentrerai pas dans les exemples des codes fournis par les outils comme ChatGPT qui fournissent une très bonne base de programme mais demandent au développeur de bien le relire et le corriger, ce qui est rarement fait.

Ces anecdotes plus au moins drôles soulèvent les possibles causes et les conséquences à long terme de cette « idiocratie des développeurs ».

De l’importance de la formation à l’algorithmie

Enseignante et formatrice, je constate que la formation en informatique devient totalement illogique dans certains établissements.

Certaines formations exigent que nous formions des développeurs fullstack en moins de six mois (front back et DB), donc le programme fait généralement l’impasse sur l’algorithmie de base. On se retrouve donc à former des gens qui n’ont pas la moindre idée de ce qui tourne derrière, qui ne savent pas faire un requête SQL car il y a l’ORM, qui ne savent pas faire un traitement business, juste un CRUD, etc.

Dans les établissements plus classiques, on peut constater un phénomène typiquement plus français : l’algorithmie est assimilée aux maths et comme en secondaire, elle est dénigrée car trop abstraite ou trop difficile. Or il n’y a quasiment aucune différence entre l’algo et le code, seul le pinceau et la peinture changent, le tableau reste le même au final.

Puis j’entends souvent de la part des juniors : l’IDE code pour nous donc plus besoin de réfléchir… En tant que consultante, je me rends compte de ces phénomènes lorsque j’interviens sur du code et que je discute avec les développeurs qui ne savent plus pour la plupart ce qu’est un tri ou un pointeur.

Il n’est pas nécessaire de maîtriser et de savoir coder tous les grands principes de la programmation, comme les listes, les arbres ou encore les tris, mais il est nécessaire d’en connaitre le fonctionnement pour créer le programme le plus propre et le plus maintenable possible. Un bon programme donc.

À long terme, ces mauvaises pratiques, ces dérives et cette mentalité vont provoquer une nuée de logiciels ne fonctionnant pas correctement, ramant à souhait et surtout absolument pas maintenable vu le manque de propreté et de logique du code. La dette ne sera plus une dette technologique mais une dette intellectuelle.

Si vous voulez en savoir plus sur le sujet, consultez le dernier livre de Ludivine Crépin, « Algorithmique – Techniques fondamentales de programmation – Exemples en Python »

Disponible également dans la Bibliothèque Numérique pour les professionnels.

Vidéo