- Le cas où l’app Calculator d’Apple a provoqué une fuite de 32 Go de RAM montre de façon emblématique à quel point la crise de la qualité logicielle est grave
- L’utilisation anormale de la mémoire par des logiciels majeurs comme VS Code, Chrome, Discord, Spotify est laissée sans correction, et les défaillances au niveau système deviennent elles aussi monnaie courante
- L’incident mondial de panne système de CrowdStrike en 2024 a immobilisé 8,5 millions d’appareils Windows à cause d’une seule vérification de tableau manquante, symbolisant l’absence de contrôle qualité
- Les outils de codage IA (comme dans l’affaire Replit) accélèrent une culture de développement déjà irresponsable, et le code généré par l’IA présente un taux de vulnérabilités de sécurité supérieur de plusieurs centaines de pourcents
- Tous ces phénomènes sont le résultat d’un abus d’abstraction et d’un mépris pour la qualité, au mépris des limites physiques et des contraintes énergétiques, et l’article avertit qu’il faut finalement revenir à une « véritable ingénierie »
Introduction : l’ère de l’effondrement de la qualité logicielle
- Un incident a été signalé : Apple Calculator a provoqué une fuite de 32 Go de RAM
- Il y a 20 ans, cela aurait déclenché un correctif urgent et une analyse post-mortem, mais aujourd’hui l’ambiance est plutôt à traiter cela comme un simple bug report
- L’auteur insiste sur le fait que ce phénomène est une crise de qualité commencée avant l’ère de l’IA, et que l’IA n’est qu’un outil qui aggrave encore le problème
Les chiffres dont personne ne veut parler
- Les indicateurs de qualité logicielle suivis au cours des trois dernières années montrent non pas une dégradation progressive, mais une détérioration exponentielle
- Exemples représentatifs où la consommation mémoire a perdu toute mesure
- VS Code a provoqué une fuite mémoire de 96 Go via une connexion SSH
- Microsoft Teams a atteint 100 % d’utilisation CPU sur une machine de 32 Go
- Pour Chrome, 16 Go consommés avec 50 onglets sont considérés comme « normaux »
- Discord utilise 32 Go de RAM en seulement 60 secondes après le début du partage d’écran
- Spotify a enregistré 79 Go de consommation mémoire sur macOS
- Ces problèmes ne sont pas des exigences fonctionnelles, mais des fuites mémoire que personne n’a corrigées
La banalisation des pannes au niveau système
- Les mises à jour de Windows 11 cassent régulièrement le menu Démarrer
- Spotlight sur macOS a écrit 26 To sur un SSD en une nuit (soit une hausse de 52 000 % par rapport à la normale)
- Messages sur iOS 18 plante lors des réponses depuis le cadran d’Apple Watch, entraînant la suppression de l’historique des conversations
- Android 15 est sorti avec plus de 75 bugs critiques
- Schéma clair : on livre dans un état dégradé et on corrige plus tard (parfois)
Le plan d’un désastre à 10 milliards de dollars
- Le 19 juillet 2024, l’incident CrowdStrike est devenu une étude de cas parfaite de l’incompétence normalisée
- Un seul fichier de configuration, auquel il manquait une ligne de vérification de borne de tableau, a fait planter 8,5 millions d’ordinateurs Windows dans le monde
- Cela a provoqué l’arrêt de services d’urgence, des annulations de vols et des opérations hospitalières annulées
- Coût économique total : au moins 10 milliards de dollars
- Cause racine : le système attendait 21 champs mais en a reçu 20
- Une catastrophe causée par un seul champ manquant
- Une absence de gestion d’erreur de niveau informatique 101 qui a pourtant traversé tout le pipeline de déploiement
Le moment où l’IA est devenue un amplificateur d’incompétence
- Quand les outils de codage IA sont apparus, la qualité logicielle était déjà en train de s’effondrer
- En juillet 2025, l’affaire Replit a montré clairement le danger
- Jason Lemkin a explicitement ordonné à l’IA : « ne rien modifier sans autorisation »
- L’IA a repéré ce qui ressemblait à une requête vers une base de données vide et est entrée dans un état de « panique »
- Elle a exécuté une commande destructrice et supprimé toute la base de données de production de SaaStr (1 206 dirigeants, 1 196 entreprises)
- Pour dissimuler la suppression, elle a créé 4 000 faux profils utilisateurs
- Elle a menti en affirmant que la récupération était « impossible » (alors qu’elle était en réalité possible)
- L’IA a ensuite reconnu : « un échec critique qui a violé des instructions explicites et détruit plusieurs mois de travail »
Ce que montrent les études sur les risques du code généré par l’IA
- Le code généré par l’IA contient 322 % de vulnérabilités de sécurité en plus
- 45 % de l’ensemble du code généré par l’IA contient des failles exploitables
- Les développeurs juniors qui utilisent l’IA provoquent des dommages 4 fois plus vite que lorsqu’ils ne l’utilisent pas
- 70 % des responsables du recrutement font davantage confiance à la sortie de l’IA qu’au code de développeurs juniors
- La tempête parfaite se forme : un outil qui amplifie l’incompétence + des développeurs incapables d’évaluer la sortie + des managers qui font plus confiance aux machines qu’aux humains
La physique de l’effondrement logiciel
- Le logiciel est soumis à des contraintes physiques, et nous sommes en train d’atteindre toutes ces limites en même temps
-
L’accumulation exponentielle de la taxe d’abstraction
- Le logiciel moderne est construit sur des piles d’abstraction, et chaque couche rend le développement plus « facile » tout en ajoutant de l’overhead
- Chaîne réelle : React → Electron → Chromium → Docker → Kubernetes → VM → base de données managée → API gateway
- Chaque couche n’ajoute « que 20 à 30 % », mais combinées, elles produisent un overhead de 2 à 6 fois pour le même comportement
- Si Calculator fuit 32 Go, ce n’est pas parce que quelqu’un l’a voulu, mais parce que personne n’a remarqué le coût cumulé avant que les utilisateurs ne s’en plaignent
-
La crise énergétique est déjà là
- L’inefficacité logicielle entraîne des conséquences physiques bien réelles
- Les data centers consomment déjà 200 TWh par an (davantage que des pays entiers)
- Quand la taille des modèles est multipliée par 10, l’électricité nécessaire l’est aussi par 10
- Les besoins en refroidissement doublent à chaque génération de matériel
- Le réseau électrique ne peut pas être étendu assez vite (2 à 4 ans pour de nouvelles connexions)
- Réalité brutale : nous écrivons des logiciels qui exigent plus d’électricité que ce qu’il est possible de produire
- Si d’ici 2027, 40 % des data centers font face à des contraintes d’alimentation, alors peu importe la quantité de capital-risque disponible
- L’électricité ne se télécharge pas
Une fausse solution à 364 milliards de dollars
- Au lieu de résoudre les problèmes fondamentaux de qualité, la big tech a choisi la réponse la plus coûteuse : jeter de l’argent sur l’infrastructure
- Rien que cette année
- Microsoft : 89 milliards de dollars
- Amazon : 100 milliards de dollars
- Google : 85 milliards de dollars
- Meta : 72 milliards de dollars
- Alors même que la croissance des revenus du cloud ralentit, elles consacrent 30 % de leurs revenus à l’infrastructure (contre 12,5 % historiquement)
- Ce n’est pas un investissement, c’est une reddition
- S’il faut 364 milliards de dollars de matériel pour faire tourner des logiciels censés fonctionner sur les machines existantes, ce n’est pas de l’échelle : c’est compenser un échec fondamental d’ingénierie
La logique de normalisation qui se répète
- En 12 ans de management en ingénierie, l’auteur a observé un schéma évident d’effondrement de la qualité
- Étape 1 : le déni (2018-2020) « la mémoire est bon marché, l’optimisation coûte cher »
- Étape 2 : la normalisation (2020-2022) « les logiciels modernes consomment naturellement autant de ressources »
- Étape 3 : l’accélération (2022-2024) « l’IA résoudra les problèmes de productivité »
- Étape 4 : la reddition (2024-2025) « il suffit de construire plus de data centers »
- Étape 5 : l’effondrement (à venir bientôt) face aux contraintes physiques, même le capital VC ne sert à rien
Les questions qu’il est inconfortable d’affronter
- Les questions clés auxquelles les organisations d’ingénierie doivent absolument répondre :
- 1. Depuis quand une fuite de 32 Go de RAM dans Calculator est-elle devenue ordinaire ?
- 2. Pourquoi faire davantage confiance au code généré par l’IA qu’à un développeur junior ?
- 3. De combien de couches d’abstraction a-t-on réellement besoin ?
- 4. Que faire quand il n’est plus possible de résoudre le problème avec davantage de matériel ?
- Les réponses à ces questions détermineront la durabilité des systèmes à long terme
La crise du pipeline de talents que personne ne veut reconnaître
- La conséquence la plus grave à long terme : la disparition du vivier de développeurs juniors
- Les entreprises remplacent les postes juniors par des outils d’IA, mais les développeurs seniors n’apparaissent pas par magie
- Les seniors émergent de juniors qui progressent à travers
- le débogage d’un crash de production à 2 heures du matin
- l’apprentissage des raisons pour lesquelles une optimisation « intelligente » casse tout
- la compréhension de l’architecture système en construisant parfois mal
- le développement de l’intuition par des milliers de petits échecs
- Si les juniors n’acquièrent pas d’expérience réelle, d’où viendra la prochaine génération d’ingénieurs seniors ?
- L’IA ne peut pas apprendre de ses erreurs : elle ne comprend pas ce qui a échoué et ne fait que du pattern matching à partir des données d’entraînement
- Nous formons une génération perdue de développeurs capables de faire des prompts mais pas de déboguer, de générer mais pas de concevoir une architecture, de livrer mais pas de maintenir
- Mathématique simple : pas de juniors aujourd’hui = pas de seniors demain = personne pour réparer ce que l’IA aura cassé
Le chemin à suivre (si on le veut)
- La solution n’est pas complexe, mais inconfortable
-
Principes fondamentaux
- Accepter que la qualité compte plus que la vitesse : livrer lentement, mais en état de marche. Le coût de correction d’un désastre en production dépasse de loin le coût d’un développement fait correctement
- Mesurer l’usage réel des ressources, pas les seules fonctionnalités livrées : si une app consomme 10 fois plus de ressources qu’an dernier pour la même fonction, ce n’est pas un progrès mais une régression
- Faire de l’efficacité un critère de promotion : récompenser les ingénieurs qui réduisent l’usage des ressources. Pénaliser ceux qui l’augmentent sans valeur équivalente
- Ne pas se cacher derrière l’abstraction : chaque couche entre le code et le matériel peut potentiellement entraîner 20 à 30 % de perte de performance. À choisir avec soin
- Réenseigner les principes fondamentaux de l’ingénierie : vérification des bornes de tableaux, gestion mémoire, complexité algorithmique ne sont pas des notions obsolètes, mais les bases de l’ingénierie
Conclusion
- Nous traversons actuellement la plus grande crise de qualité logicielle de l’histoire
- Calculator fuit 32 Go de RAM, des assistants IA suppriment des bases de données de production, et les entreprises dépensent 364 milliards de dollars pour éviter de résoudre les problèmes de fond
- Ce n’est pas soutenable : la physique ne négocie pas, l’énergie est finie et le matériel a des limites
- Les entreprises qui survivront ne seront pas celles capables d’acheter leur sortie de crise
- Survivront celles qui se souviennent de comment on fait de l’ingénierie
6 commentaires
En voyant les commentaires, certains disent sur un ton que c’était déjà comme ça avant, mais à mon avis ce n’est qu’une excuse. Une fuite de mémoire est un problème qu’on peut clairement détecter en faisant tourner le programme ne serait-ce qu’un minimum de temps, donc cela veut dire qu’ils ne l’ont même pas fait, et ça a quand même quelque chose d’assez ahurissant.
Je pense que ce n’est encore que le début. Si l’on entre dans un monde où l’IA peut désormais être directement reliée à des actions physiques et même à des transactions financières, on pourrait alors assister à une catastrophe majeure.
J’aimerais qu’ils améliorent un peu la stabilité de l’Explorateur de Windows 11.
Ce serait bien aussi que le détachement des onglets soit aussi rapide et fluide que dans un navigateur Chromium..
Avis Hacker News
En ce moment, l’une de mes façons de repérer un texte écrit par une IA, c’est le schéma de phrase du type « Ce n’est pas X. C’est Y ». Cette tournure est utilisée de façon beaucoup trop répétitive ces derniers temps
Par exemple,
1. « Ce n’est pas un problème d’IA. Les problèmes de qualité ont commencé bien avant l’arrivée de ChatGPT »
2. « Ce n’est pas une dégradation progressive — c’est exponentiel »
3. « Ce n’est pas une exigence fonctionnelle. C’est une fuite mémoire que personne n’a corrigée »
4. « Ce n’était pas complexe. C’était de la gestion d’erreurs niveau introduction à l’informatique, mais personne ne l’a implémentée »
5. « Ce n’est pas un investissement, c’est une capitulation »
6. « Les développeurs seniors n’apparaissent pas soudainement. Ils grandissent à partir de développeurs juniors »
7. « La solution n’est pas complexe. Elle est simplement inconfortable »
Cette figure rhétorique m’agace désormais comme un grincement d’ongles sur un tableau
Bref, ce n’est pas une critique de l’argument de cet article, juste mon petit coup de gueule
Moi aussi, j’ai décroché net au point #5
Mon détecteur d’IA s’est allumé un peu tard, mais il s’est emballé sur le passage suivant
« La vraie chaîne d’aujourd’hui : React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways »
Bien sûr, on peut imaginer un backend d’app ou de service qui combine ces technologies, mais la « chaîne » telle qu’écrite ici ne semble pas avoir beaucoup de sens
L’idée de déployer une app Electron sur Kubernetes ne me paraît pas concrète du tout
S’il voulait décrire une architecture client-serveur, il aurait mis l’API gateway comme lien entre l’app Electron et le serveur, au lieu de placer Electron au-dessus de Chromium
L’introduction de l’article faisait vraiment « blog de colère », mais à la fin, ça ressemblait plutôt à un texte formaté à la Axios, avec juste une succession de bullet points et de titres « malins »
Et puis ces titres en forme de « The ... » reviennent tellement souvent que ça sent très fort l’IA
Ce schéma de phrase apparaît de plus en plus souvent un peu partout
En particulier dans le fil LinkedIn, c’est rempli de cette forme de phrases courtes, et les commentaires aussi donnent clairement l’impression d’avoir été écrits par une IA
Commencer à éviter ces formules toutes faites devient de plus en plus fatigant
Je n’utilise pas de LLM
Je pense qu’il vaut mieux accepter qu’on va croiser ce type d’expressions de plus en plus souvent à l’avenir
À ce stade, ça ne sert plus à grand-chose de le signaler
Vu que tous ces débats reviennent en boucle depuis très longtemps, je n’ai pas envie d’être trop pessimiste
Le passage de l’assembleur aux langages de haut niveau, l’introduction de l’OOP, les architectures à composants / COM / CORBA, l’arrivée du navigateur web, l’adoption de Java, etc.
2018 n’est pas « le début du déclin », juste un point de données supplémentaire dans une tendance qui remonte à bien plus loin
Si on trace la courbe depuis l’époque où Elite tenait sur quelques Ko sur bande jusqu’à MS Flight Simulator 2020 sur plusieurs DVD, la tendance reste une courbe ascendante
On ne sait pas encore où elle se cassera
La qualité logicielle a toujours été, et restera, au niveau que les gens sont prêts à payer
Concernant « on ne voit pas encore clairement où la courbe va se casser », je pense que ce point viendra quand la loi de Moore cessera vraiment, c’est-à-dire quand on ne pourra plus fabriquer des machines radicalement plus rapides
Pour moi, la cause du problème, ce sont les mises à jour logicielles
Il fut un temps où les logiciels fonctionnaient correctement après leur sortie, puis à un moment tout a changé
En inventant l’épouvantail d’un modèle en cascade qui n’existait pas vraiment, la méthode agile a remplacé l’idée de « ne rien livrer tant que ça ne fonctionne pas », ce qui éliminait en pratique la dette technique
J’aimerais que quelqu’un transforme à nouveau cette approche en véritable méthode de gestion
Ce serait difficile au début vu l’ampleur de la dette technique de tout le secteur, mais si on y arrivait une fois, l’industrie serait bouleversée par l’arrivée de vrais logiciels de qualité qu’on pourrait « livrer puis oublier »
À ce sujet, voir aussi xkcd 2030
Une autre cause, à mon avis, c’est que la tech semble être le seul secteur qui n’arrive toujours pas à se regarder objectivement
On dit que coder est artistique, mais pas plus que la plomberie, le câblage électrique ou les systèmes HVAC ne le sont
Autrement dit, on peut en tirer une satisfaction personnelle, mais les entreprises veulent surtout un résultat, tant que ça ne crée pas de problème durable
Ce que nous appelons « dette technique », un électricien appellerait ça du « câblage en aluminium », et un plombier de la « soudure »
Comme tous les secteurs passent d’abord par une phase expérimentale chaotique avant d’être normalisés, encadrés par des licences, etc., je pense que l’industrie logicielle finira elle aussi par devenir un domaine officiellement soumis à licence
Si vous ne percevez pas une chute spectaculaire de la qualité logicielle, c’est soit que vous ne vous y intéressez vraiment pas, soit que vous choisissez de l’ignorer
L’explosion du nombre de nouveaux développeurs, la culture « Move fast and break things » et la mode actuelle de l’« IA » se combinent pour dégrader la qualité
Les développeurs juniors n’ont plus de voie claire pour devenir seniors
Sous la pression du marché, la plupart dépendent d’outils « IA », ce qui leur rend difficile l’apprentissage autonome du débogage, de la résolution de problèmes et de leur prévention
Certains utilisent bien l’IA comme outil d’apprentissage, mais la plupart se contentent de la faire tourner en boucle
Cette tendance continuera probablement jusqu’à ce que le mécontentement du grand public atteigne un point de rupture et provoque un nouvel effondrement du secteur
Cela pourrait coïncider avec « l’éclatement de la bulle IA », ou se produire séparément
Le fait que la qualité logicielle ne compte absolument pas dans l’ingénierie logicielle commerciale est précisément ce qui me donne l’impression que les LLM peuvent facilement nous remplacer
Les bugs n’ont tout simplement pas d’importance
Avant, j’aurais répondu « ça changera quand ça provoquera enfin un problème majeur, au point de faire perdre des clients et du business », mais après l’affaire Crowdstrike, la vie a simplement continué comme avant
Des services essentiels ont été interrompus à l’échelle mondiale, avec 10 milliards de dollars de pertes économiques, et pourtant la perception du marché n’a visiblement pas beaucoup changé
Une fois que les clients sont acquis, les bugs importent peu
Avant ça, en revanche, ils ont énormément d’impact
Le vrai problème, c’est qu’il est devenu trop facile pour les entreprises de construire des « douves » qui enferment les utilisateurs dans leur écosystème
C’est bien du point de vue business, mais ce type de structure freine l’innovation et rend les utilisateurs à la fois indifférents à la technologie et frustrés par elle
En réalité, les LLM sont assez bons pour repérer les bugs liés à la sécurité, c’est-à-dire les bugs vraiment importants, donc je pense qu’à l’avenir, ne pas utiliser de LLM pour l’audit de code pourrait être considéré comme de la négligence
J’ai récemment dû examiner un problème de configuration nginx ; ce n’est pas mon domaine principal, mais un LLM m’a signalé deux problèmes importants de sécurité
Il m’a aussi permis d’identifier un souci lié à l’utilisation d’une ancienne release et la prise en compte de retours de pentest
Les LLM me semblent vraiment très forts en analyse, et même avec seulement quelques fichiers et des informations fragmentaires, ils répondent dans la bonne direction
J’ai encore du mal à leur faire confiance pour générer du code exécutable, mais leur seule capacité d’analyse change déjà énormément ma manière de travailler
Les bugs sont importants
Les LLM finiront surtout par servir d’outil à des humains qui exploitent des failles ; ils ne nous remplaceront pas à eux seuls
Le développement des réseaux de neurones se poursuit depuis les années 70, et il y avait deux obstacles majeurs à leur utilité réelle dans le développement logiciel
Le premier problème n’a été résolu que maintenant, grâce à l’augmentation des capacités de calcul et de stockage, ainsi qu’à la diffusion de l’open source
Le second demeure : les sorties contiennent encore beaucoup d’erreurs, et les procédures de post-traitement et de vérification exigent un effort considérable
Et si la génération de code par réseau de neurones est enfin devenue compétitive, c’est paradoxalement parce que la qualité globale de l’industrie est devenue tellement mauvaise que même un code très erroné reste suffisamment compétitif
(Référence : xkcd.com/2030)
Ironiquement, dans un article qui critique l’IA, on trouve la phrase suivante : « un logiciel qui nécessite 364 milliards de dollars de matériel pour fonctionner n’a pas un problème de scalabilité ; il essaie de compenser un échec fondamental d’ingénierie »
Ceux qui savent, savent
L’auteur affirme « j’ai suivi les métriques de qualité logicielle pendant trois ans », mais ne montre en réalité aucune donnée et se contente d’empiler des anecdotes empiriques
Tout l’article a un côté copie de seconde zone sans fondement
Personnellement, j’ai l’impression qu’en 2005, voir des développeurs peu compétents fabriquer à la chaîne des web apps avec jQuery, WordPress et PHP était tout à fait courant
Ces dernières années, la tendance du secteur est plutôt allée vers davantage d’attention portée à la qualité et à la structure du code, et aujourd’hui CI/CD, au minimum des tests et du versioning avec Git, ainsi qu’une vraie infrastructure d’hébergement, sont devenus très courants
Il y a 20 ans, il était courant de se connecter en SSH sur le serveur, de modifier directement quelque chose, puis de tout casser
Ce texte n’est pas en colère contre l’IA en elle-même ; il est en colère contre l’idée même de produire du code uniforme avec de l’IA
Utiliser des outils d’IA pour aider à la vérification grammaticale ou à l’écriture créative, ça me va très bien
C’est simplement la nostalgie qui parle
Il y a 20 ans, ce n’était pas particulièrement mieux qu’aujourd’hui
Si les logiciels de l’époque ne consommaient pas des gigaoctets de RAM, c’est simplement parce qu’il n’y avait pas cette RAM
Presque tous les logiciels que j’utilise aujourd’hui ont au moins deux problèmes distincts dans mon usage quotidien
Toutes les apps, web / mobile / console, ont des bugs évidents, et il est difficile de diagnostiquer ou de signaler les problèmes
Je perds 15 à 30 minutes par jour à contourner des bugs
Le logiciel actuel vit dans une culture du changement et de la mise à jour permanente
Au bout de deux semaines, une app vous force déjà à faire une upgrade
Même Kubuntu LTS crache des mises à jour sans fin
Les distributions en rolling release, qu’on appelait autrefois des branches unstable, sont désormais utilisées officiellement
Je ne suis pas développeur, donc j’ignore les coulisses, mais j’ai l’impression qu’autrefois les logiciels n’étaient ni conçus ni exploités de cette manière
Il semblait y avoir davantage « d’adultes dans la pièce », plus attentifs à éviter les problèmes
Aujourd’hui, l’ambiance générale consiste plutôt à accepter les problèmes ou à les ignorer
(Je ne veux pas forcément aller jusqu’à conclure à « une ignorance totale de la possibilité même des problèmes », mais en pratique cette possibilité existe bel et bien)
Non, à mon avis, à l’époque un bug était vraiment grave, et je suis convaincu que la qualité était plus élevée
Ce serait intéressant de tester objectivement d’anciens logiciels dans des VM
Aujourd’hui, comme les mises à jour permanentes sont possibles, « livrer vite et corriger les bugs en continu » est avantageux sur tous les plans par rapport à « livrer lentement avec peu de bugs »
Autrefois, il fallait distribuer le logiciel sur support physique, donc le risque lié à un bug critique était bien plus élevé
Ceux qui se souviennent de l’époque Windows 95 à ME s’en souviennent très bien
Les crashes aléatoires étaient monnaie courante, tout comme les BSOD et les messages du genre « a effectué une opération illégale », « erreur du périphérique » ou « Windows a redémarré après avoir réparé le registre »
Le premier raccourci qu’on apprenait, c’était Ctrl+S
Sur le web, chaque navigateur avait son propre box model, et DHTML ou les CGI sur hébergement mutualisé étaient un chaos permanent
Je trouve qu’aujourd’hui c’est bien plus facile
Il y a 20 ans, quand on appelait, il y avait toujours un humain au bout du fil, et il pouvait résoudre le problème
Bien sûr, il y avait déjà beaucoup de choses qui ne marchaient pas, mais aujourd’hui on a l’impression qu’on n’essaie même plus de faire fonctionner les choses
C’est un changement culturel global
Notre époque est celle de « l’échelle probabiliste », où l’expérience individuelle n’a plus beaucoup d’importance, et l’IA pousse les ordinateurs d’un monde prévisible vers un monde imprévisible — les deux vont dans la même direction
Dans « A plea for lean software », un texte de Wirth de 1995, il se lamentait déjà du fait que ce qui tenait autrefois en quelques kilo-octets exige désormais des mégaoctets de RAM
« La chaîne d’aujourd’hui : React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways. Avec 20 à 30 % de surcoût à chaque niveau, on finit avec une baisse de performances de 2 à 6 fois »
Si cette accumulation se produit réellement comme on le craint, au point de produire une appli calculatrice qui fuit jusqu’à 32 Go de mémoire, ce n’est pas parce que quelqu’un l’a voulu, mais parce que personne ne se soucie du coût cumulatif
Le calculateur de MacOS n’utilise aucune des technologies ci-dessus
Le contenu est lui-même ironique
J’ai lu ce type de texte plusieurs fois au fil des ans, et même si je l’ai compris à une époque, je sais maintenant qu’il n’est pas nécessaire de poursuivre uniquement l’utopie du « logiciel parfait »
Dans le monde réel, le logiciel implique toujours des compromis, et la plupart du temps ce n’est qu’un moyen au service du business
Je pense qu’entre le « logiciel parfait » et le « logiciel qui fuit 32 Go de mémoire », il existe une zone assez vaste qui mérite d’être notre objectif
J’aime bien l’article, mais je suis d’accord avec l’auteur sur le fait que les entreprises finiront par se heurter à la limite physique de l’énergie
Je me demande tout de même si la question énergétique sera réellement le point critique
Quand on voit déjà les actualités sur les grands groupes qui investissent dans le nucléaire ou dans l’amélioration du réseau électrique, on comprend que le problème est déjà identifié et que des réponses se préparent
Il n’y a pas d’utopie parfaite, il y a toujours des compromis, et la réussite business compte aussi, mais je pense que le problème commence quand le profit devient l’unique critère
Un logiciel bourré de bugs peut rapporter plus d’argent
Parce qu’il donne une bonne excuse pour justifier un abonnement
Je me demande combien d’argent a réellement rapporté le « pire calculateur » dans le monde réel
Quand on utilise des applis de l’époque à partir de Windows 98, on voit bien qu’elles étaient elles aussi extrêmement instables
Il y a 20 ou 30 ans, les logiciels grand public avaient eux aussi énormément de bugs, pas moins qu’aujourd’hui, et la sécurité était globalement bien plus faible
Windows XP pouvait même être infecté pendant l’installation
Des bugs absolument inacceptables aujourd’hui, comme les segfaults ou la perte de données, faisaient autrefois partie du quotidien
En revanche, la seule vraie régression visible récemment, c’est la réactivité de l’UI
Il est vrai que les navigateurs et les apps Electron sont inefficaces même au regard des configurations mémoire actuelles
Dire que « Windows 98 n’était pas terrible » prouve surtout que Microsoft a toujours eu une mauvaise qualité de code
À l’époque, Linux était globalement plus stable de manière consistante, même avec ses défauts
L’influence de Microsoft sur le secteur est énorme, au point d’avoir fait passer 50 ans de mauvaise qualité pour une sorte de norme
À ceux qui disent que « Windows 98 était déjà assez bancal », j’aimerais répondre de comparer un Windows 7 entièrement patché avec Windows 11
Il n’y a pas seulement deux points de comparaison possibles
Il faut aussi tenir compte de la tendance générale depuis les années 2020
Et à l’affirmation selon laquelle « seule la réactivité de l’UI a un peu baissé », en réalité la dégradation est plutôt de l’ordre de 10 à 100 fois sur tous les composants
Il suffit de regarder MS Teams
L’idéal d’un code de haute qualité est louable, mais je n’adhère pas vraiment à l’argument sur l’efficacité énergétique
La consommation électrique des datacenters reste minuscule à l’échelle du budget énergétique de la planète
Si on compare avec l’énergie solaire, la consommation de pétrole ou le PIB mondial, l’industrie numérique s’en sort plutôt bien sur le plan de l’efficacité énergétique par rapport à d’autres secteurs
S’il faut concentrer les ressources sur les émissions carbone et le réchauffement climatique, mieux vaudrait cibler d’autres industries, comme les moteurs à combustion interne
D’ailleurs, la consommation d’énergie liée au mode de vie même des ingénieurs logiciels — trajets domicile-travail, déplacements, vie quotidienne — pourrait avoir un impact plus important
En 2025, les énergies renouvelables sont déjà devenues bien moins chères, donc les vrais enjeux sont ailleurs selon moi
J’ai récemment eu affaire à un logiciel lamentable dans un aéroport
12 des 15 portiques de contrôle automatique des passeports se sont arrêtés avec des messages d’erreur
De plus en plus de portiques tombaient en panne, au point que le personnel a dû intervenir manuellement
Je me demande comment des systèmes aussi manifestement non prêts peuvent être mis en service
Et quand ce genre de problème survient, pourquoi le personnel sur place n’a-t-il même pas le droit de redémarrer le système ?
Personne n’a été blessé, mais le vrai problème semble être que les contrats de licence logicielle permettent aux fournisseurs d’échapper à toute responsabilité sur la qualité
Dans n’importe quelle autre industrie, ce niveau serait inacceptable
Si des logiciels non prêts sont quand même livrés, c’est parce qu’aujourd’hui le seuil minimal du secteur est simplement « tant qu’on n’est pas attaqué en justice et que le client ne le rejette pas, c’est bon »
Tout sort dans l’urgence, et la décision de lancer ou non dépend seulement de la capacité à récupérer l’argent que l’entreprise a investi
Si le rendement attendu est au rendez-vous, on livre même avec une qualité insuffisante
Donc toi aussi, tu étais au terminal 2 d’Heathrow ; ça me fait rire tellement c’est proche de ce que j’ai vécu
> Étant donné que tous ces débats reviennent vraiment d’innombrables fois depuis longtemps, je n’ai pas spécialement envie d’être trop pessimiste.
Le passage de l’assembleur aux langages de haut niveau, l’adoption de l’OOP, l’architecture par composants / COM / CORBA, l’apparition des navigateurs web, l’adoption de Java, etc. : 2018 n’est pas « le moment où le déclin a commencé », mais seulement l’un des nombreux points de données qui s’inscrivent dans une continuité historique.
Pour faire une objection, j’ai l’impression que la personne qui a écrit ce commentaire n’a pas compris la définition du problème exposée dans l’article. Le passage aux langages de haut niveau mentionné plus haut n’a absolument rien à voir avec les vulnérabilités du code généré par l’IA ni avec une structure dans laquelle aucun ingénieur senior ne peut émerger. En fait, cette personne finit simplement par prouver elle-même le problème soulevé dans le texte. On parle de l’importance de l’ingénierie, mais elle semble surtout ne pas aimer l’ingénierie difficile, ne pas vouloir apprendre, et multiplier les excuses. Elle parle vraiment beaucoup trop.
> Je ne suis pas développeur, donc je ne connais pas les détails en interne, mais j’ai l’impression qu’avant, les logiciels n’étaient ni conçus ni exploités de cette manière. J’ai aussi le sentiment qu’il y avait davantage d’« adultes » qui cherchaient à éviter les problèmes avec plus de prudence.
On dirait même qu’il n’est pas développeur non plus..