Sommes-nous à l'ère du code de merde ?

Il n’y a pas un jour sans qu’on découvre en ce moment une faille de sécurité majeure ou une fuite de données quelque part.

Hier encore, c’était Github, qui a manifestement ouvert une partie de son code en open source. Involontairement, certes, mais on peut quand même saluer l’initiative.

A côté de ça, en France, c’est 3 vols de données en moyenne par jour selon cet article. Mais rassurons-nous, apparemment notre premier ministre a une solution, virer le directeur de l’ANSI…

Faut dire que l’ouverture de l’ANTS (agence nationale des titres sécurisées) dans les grandes largeurs par un hacker de 15 ans via une faille triviale c’était un peu la nouille qui a fait déborder le bol de ramen.

Et selon certains, l’IA serait responsable de la baisse de qualité générale des logiciels, par exemple chez GitHub où le taux de disponibilité serait en baisse constante depuis GPT3 sur ce graphique (et l’arrivée de Microslop mais on va se concentrer sur un seul coupable).

Bon, ici, c’est du troll. Mais certains se demandent premier degré, est-ce que vraiment, l’IA serait la source de tous ces problèmes ?

C’est ce qu’on va essayer de voir. On va parler des vrais raisons de la hausse des CVE mais ce sera surtout un prétexte pour se demander si vraiment nous sommes à l’aube d’une ère du code de merde généré par IA ?

La hausse des CVE

Déjà pourquoi je parle des CVE, et c’est quoi une CVE ?

Une CVE (Common Vulnerabilities and Exposures) c’est un standard, qui recense toutes les vulnérabilités connues dans un gros catalogue. Chaque CVE est listée sous un petit nom hyper sexy, genre CVE-2024-12345.

(Oui ça fait frissonner n’est-ce pas ?)

Alors vous allez me dire, dans le monde du logiciel on parle de bug, pas de CVE et vous auriez bien raison. Mais il n’existe pas de recensement des bugs de tous les logiciels connus.

Donc ici je prends le nombre de CVE annuelles comme une sorte de révélateur du nombre de bugs dans les logiciels parce que je me dis qu’il y une petite corrélation entre baisse de qualité et augmentation des trous de sécurité. Enfin, à première vue, mais on va y revenir.

Et si on regarde ça, eh bien l’accélération pourrait dater de 2022 avec cependant une première étape vers 2017.

Si on prend l’année 2017 comme l’année de rupture, ça devient plus difficile d’imputer le problème à l’IA même avec la mauvaise foi d’un supporter marseillais (coucou Max, si tu me lis).

Dans les grandes lignes la hausse des CVE depuis 2017 s’explique probablement par un mix de facteurs :

• une plus grande pression sur les logiciels auxquels on demande désormais une nouvelle version par jour
• une explosion du numérique de façon générale
• beaucoup plus de programmes de sécurité (les bug bounty)
• une augmentation du nombre de logiciels dédiés à la sécurité informatique.
• des conflits géopolitiques importants et des attaques cyber plus fréquentes

En fait, il serait pas impossible qu’on mesure, le nombre de thermomètre (et pas uniquement le température), donc l’essor de l’industrie cyber, et d’un autre côté, l’essor du numérique qui devient un enjeu économique et géopolitique dans un contexte plutôt instable depuis des années.

Maintenant on peut quand même se poser la question pour la période post 2022 parce que la pente semble monter aussi vite que le nombre de dossiers judiciaires de Nicolas Sarkozy.

Cependant j’ai envie de dire que les CVE c’est pas le meilleur proxy pour mesurer la qualité logicielle parce qu’on l’a vu, les CVE peuvent augmenter pour des raisons plutôt exogène. C’est pas parce qu’on contrôle mieux qu’avant et qu’on scrute davantage, qu’il y a vraiment plus de bugs.

Donc on va revenir au point de départ et s’intéresser à une phrase que j’entends très souvent : l’IA c’est la mort du craft.

Avec l’IA, c’est la mort du craft

Le craft, pour ceux qui suivent pas au fond, c’est une sorte de mot valise pour regrouper tout un ensemble de pratiques qui vise à produire des logiciels de “qualité”. Si tant est qu’on sache définir la qualité d’un logiciel mais c’est un autre sujet.

Avec l’IA on ne ferait plus de qualité et l’expertise technique, l’intérêt du métier pour beaucoup, aurait disparu.

Attention, ici on a deux sujets différents :

• l'intérêt du métier disparaitrait parce qu’on ne ferait plus de craft
• le code produit par IA serait à l’informatique ce que la cuisine anglaise est à la gastronomie mondiale, c’est à dire pas terrible.

(Bon déjà rétablissons la vérité sur le second point, non la cuisine anglaise est largement pire)

Alors, il y a des personnes qui ont cherché à déterminer si le code produit par des IA était nécessairement moins “durable” que du code produit par un humain, bref si nous étions vraiment en train de construire des montagnes de dette technique à vitesse lumière.

IA slop et maintenance logicielle

Est ce que vous connaissez Dave Farley ?

Dave Farley est un des auteurs notamment du livre Continuous Delivery sorti en 2010.

Ca a été l’un de mes livres professionnels de référence pendant des années à une époque où on parlait beaucoup d’usine logicielle, de qualité et de déploiement continu. J’ai bossé des années sur ces sujets, notamment dès 2006 sur des concepts de CI distribués. J’ai bossé ensuite à partir de 2010 sur des thématiques d’industrialisation, puis à partir de 2012 sur le sujet du déploiement continu.

(ok papy mais continue ton histoire)

Eh bien Dave Farley a participé à une étude qui visait justement à déterminer quel était le code le plus maintenable entre le code produit par IA ou le code produit par des humains. Est-ce qu’il y avait plus de dette technique dans le code produit par IA ? Et la réponse est… non.

Pour être franc, même moi je suis surpris, et en même temps, pas du tout.

Je suis surpris parce que je sais l’effort d’ingénierie nécessaire pour qu’une IA marche bien. Sans ces efforts, le code ressemble vite à un Frankenstein un peu boiteux.

Mais, j’imagine que l’étude porte sur des professionnels qui ont eu le temps de mettre en place leurs outils habituels.

Construire une usine logicielle agentique

Je vous l’ai dit, j’aime créer des usines logicielles, je bosse sur ce sujet depuis des années.

L’usine logicielle c’est rien de plus qu’un procédé de fabrication, plus au moins industrialisé et automatisé.

Un générateur de code, aussi puissant soit-il, c’est pas une usine logicielle, c’est uniquement une des machines de l’usine.

Et si vous laissez juste tourner une des machines, c’est pas suffisant.

Quand un dev fait uniquement du copier coller de ChatGPT depuis un navigateur, c’est à peine 10% du travail et oui, le résultat est pas terrible et nécessite souvent beaucoup d’ajustements manuels.

Or, en étant un peu provoc, je dirais que retoucher au code produit c’est un échec. Imaginez la même chose dans une usine de voiture. S’il fallait des artisans qui se mettent à retoucher chaque voiture produite ce serait un peu surprenant. Et, je suis pas spécialiste, mais je crois que c’est pas comme ça que ça marche.

Bref, il faut les autres machines outils.

Dans notre métier ça consiste à construire des harnais de test et de validation, de définir les règles à respecter et de trouver des moyens de vérifier que c’est bien fait, de créer des skills pour guider le travail des IA et leur éviter de se planter, de leur permettre de vérifier eux mêmes avec des outils et donc de corriger etc… etc…

Et ça, en fait, c’est du craft. L’usage d'agents IA rend obligatoire les fameuses bonnes pratiques dont tout le monde parle mais qu’on voit pas si souvent dans les faits.

Tous les gens que je vois en ce moment dans la communauté DevWithAI c’est des crafteurs qui essaient d’améliorer leur usine logicielle. C’est des gens qui bossent sur des outils de compression de tokens comme rtk, des outils pour simplifier et uniformiser l’usage à l’échelle d’une équipe comme packmind, des guides d’usage comme celui de Florian.

Le craft n’a pas disparu. Il a changé.

Pour une boite, il y a un effort substantiel à faire pour introduire ces outils, construire une usine logicielle par dessus, créer de l’outillage, faire du platform engineering et il faut des gens pour ça, de la même façon qu’il faut des gens pour concevoir, maintenir, et faire évoluer les chaines de production dans les usines.

Bref, non, l’intérêt du métier n’a pas disparu selon moi, pour les gens qui aiment le craft et la technique.

Et si on parle de qualité, je vais vous surprendre mais, à mon échelle, je vois des bonds importants de qualité sur mes applications.

L’exemple de Writizzy

Je développe plusieurs produits, Hakanai et Writizzy. J’ai passé récemment Bloggrify en mode maintenance.
Bloggrify a démarré en 2022, Hakanai en 2023 et Writizzy en 2025.

Les deux premiers, j’ai presque pas utilisé l’IA au début puis j’ai progressivement introduit quelques copiers coller venant d’un usage très discret d’agents en lignes. C’est donc plus de 90% du code que j’ai produit à la main.

Eh bien aujourd’hui je dirais, que, ça se voit.

Attention, je suis fier de ce que j’ai fait avec Hakanai et Bloggrify. Mais pour faire une application en solo faut être très bon partout : sur la construction de l’application, sa logique, son ergonomie, son UI, sa robustesse. Or c’est pas mon cas. Donc parfois il y a des endroits où c’est un peu moins bien et ça se ressent.

Et puis au delà de ça, faire tout très bien, ça prend du temps. Quand on construis un produit, on doit toujours faire un choix entre le “parfait” et le “assez bien pour la majorité des usages”. Le modulo entre les deux étant le temps à disposition.

Parfois on capitule, on sait que c’est pas nickel, mais on vient d’y passer 1 semaine, et franchement pour une amélioration de 5% de la qualité, tant pis, on y passe pas une semaine de plus. Ce sera pour la prochaine fois. Cette fameuse prochaine fois qui n’arrive jamais.

En fait la qualité de Hakanai et Bloggrify était à géométrie variable. Il y a eu des raccourcis de pris, des pages avec une ergonomie digne du web des années 2000, et c’est pas grave, c’est comme ça qu’on construisais des produits jusqu’à présent.

Sur Writizzy, c’est plus du tout le cas. Je ne fais pas de raccourcis. Déjà pour la simple et bonne raison que pour produire du code correct avec de l’IA, il faut une usine logicielle qui tienne la route, et ca inclus des gardes fous, genre tests, linter etc… Donc ce n’est pas négociable, alors que finalement ça l’était avant pour Hakanai et Bloggrify.

En plus de ça, le cout du refactoring est devenu quasi nul. Le petit truc qui manquait pour qu’une fonctionnalité soit parfaite, désormais je peux le faire.

En fait aujourd’hui je peux prendre le temps de traiter les cas aux limites, ces fameuses petites exceptions qu’avant tu laissais sur le côté parce que “ça n’arrive jamais”. Je peux profiter du temps gagné sur le dev pour penser davantage à la sécurité, la robustesse, la scalabilité.

Produire du code est devenu une commodité. Donc j’en profite pour produire du très bon code.

Bref, je fais toujours du craft, mais il a changé de nature.
Et ce que je produis est de meilleure qualité. Alors je suis pas convaincu qu’on soit entré dans une ère du code de merde.

Maintenant il y a quand même une nuance à apporter. L'IA baisse drastiquement la barrière à l'entrée. C'est bien, mais ça veut dire qu'on se retrouve avec une marée de logiciels morts nés, de trucs qui vont pas survivre plus longtemps qu'une shitcoin promue par un influenceur de Dubaï, et des boites qui vont couper sévère dans les couts de R&D parce que… flemme, et si on augmentait les marges. Donc oui, dans ces conditions là, on va avoir un nombre de logiciels produits de mauvaise qualité qui va augmenter, des logiciels qui vont crever au bout de 3 mois parce que leur créateur vont se lasser très vite devant la réalité de gérer réellement un produit informatique. Mais les bons produits seront eux par contre bien meilleurs parce que le craft sera une condition sine qua non pour pas se crasher dans un monde où tout va aller beaucoup plus vite.