Moi j'attends plutôt l'éclatement de la bulle IA en 2027. Mais je pourrais me tromper, ça pourrait se produite en 2026 en fait, il reste encore largement assez de temps. Les frasques de Jensen Huang pourraient avoir significativement accéléré les choses.
Il est probable que le financement circulaire par NVidia touche à sa fin. On voit certains projet d'infrastructure abandonnés avec des financiers qui voient leurs investissements partir en fumée (SoftBank récemment, qui avait surinvestit dans des turbines à gaz pour des datacenters par exemple). Donc les banques et les investisseurs vont être beaucoup plus regardant sur l'argent qu'ils prêtent ou investissent. Les taux d'emprunts des neoclouds crèvent déjà le plafond (si Coreweave doit emprunter aujourd'hui, ils le feront à un taux >15%). Il y a aussi les taux d'intérêt aux états unis qui vont remonter d'un cran, peut-être deux en décembre.
Je pense qu'à ce point là, plus personne ne considère qu'il est réaliste de pense que OpenAI et Anthropic ne justifieront des valeurs de plus de 1000 milliards de dollars. Jamais. (C'est à dire que la somme de leur bénéfice future imaginables, dépréciée de l'inflation, sur l'éternité, n'atteindra jamais leur "valeur" actuelle).
Cette bulle, ça me fait penser au scam Nigérien. Donne moi 100 euros pour que je sorte du Nigéria avec ma valise de diamants et je te donnerai un million d'euros. À peine plus sophistiqué.
Ça me rappelle aussi l'histoire de Ponzi. Quand il avait monté sa fameuse pyramide (supposée investir dans des timbres italiens), à un moment un analyste financier avait démonté tout ça à base d'arguments solides (aucune vente de timbres inhabituelle en Italie, aucune hausse des prix, le volume supposé de timbres dépassait déjà ce qui avait été imprimé, etc…). Les investisseurs sont venu voir Ponzi, il les a rassuré et il a même vu plus de nouveaux investissements que de départs ! Ce n'est que quand les journaux ont découvert qu'il avait déjà fait de la prison pour fraude que le run a eu lieu. Le parallèle est frappant, Ed Zitron et autres alertent sur la surchauffe et les magouilles depuis des années, mais c'est peut-être les relations extra-conjugales de Jensen Huang qui vont causer la chute!
La réponse est dans la question : le déterminisme.
Et aussi le côté exhaustif. Pour la majeure partie des logiciels vibe-codés, réutiliser le même prompt avec le même agent (ou un autre) produit un résultat radicalement différent. Pas juste dans le code, mais aussi dans le fonctionnement. Le code n'étant pas relu, impossible de savoir si il y a des backdoors, des bugs évidents, …
Les rares logiciels pour lesquels ça ne sera pas le cas sont ceux où l'on a donné soit une implémentation de référence à traduire (ou à copier), soit des specs très détaillées accompagnées de tests très complets. Ce dernier scénario est très rare.
Ce que j'ai vu faire aussi, c'est faire écrire les specs détaillées par le LLM. En théorie, ça devrait permettre de reproduire plus fidèlement le même comportement. Mais les specs ne sont pas vraiment connues de l'humain qui ne fait que les approuver sans trop lire. Avec les corrections de bugs, on se retrouve avec des incohérences qui peuvent facilement conduire à des absurdités dans le code qui persisteront puisqu'elles viennent de la spec.
Bref, le deuxième problème c'est la perte de contrôle. Avec les compilateurs, on perd le contrôle sur le détail de la traduction en assembleur, pas grave dans 99,9% des cas. Avec les LLMs, on perd le contrôle de la traduction de l'idée en logiciel, beaucoup plus gênant AMHA.
Le troisième problème, directement lié au deuxième : la responsabilité. Qui est responsable du résultat ? On voit de plus en plus de boîtes justifiant leurs erreurs par des "c'était un agent". C'est inacceptable. Mais si les utilisateurs doivent assumer les conséquences de ce que produisent leurs modèles, pas sûr qu'il y aura autant de preneurs…
Au final, je ne suis pas si sûr que le langage lui-même compte tant que ça
Alors là, pas d'accord du tout. Malheureusement, le monde est très ancré dans les langages procéduraux, et les plus connus se ressemblent effectivement pas mal. Donc effectivement, si tu compares python, c, c++, java, etc… tu trouves peut être que ça se ressemble (et encore). Mais la diversité des approches est bien plus grande que ça.
Et les propriétés d'un langage influencent la façon dont son écosystème est construit, la culture de ses utilisateurs, etc … (qui eux même viennent influencer la façon dont évolue le langage). Donc on ne peut pas vraiment séparer tout ça en pratique.
L'époque "pas si reculée" est justement l'absence d'équilibre que le commentaire précédent décrit.
Personne ne payait son téléphone parce que les opérateurs l'incluaient dans le forfait, du coup les consommateurs étaient incités à changer dès que possible, personne ne cherchait à acquérir un téléphone d'occasion.
Le découplage d'avec les forfaits a supprimé cette incitation financière, il ne reste plus que l'innovation technologique (dont l'effet s'est aussi réduit, maintenant les générations de téléphones se suivent et se ressemblent) et la casse pour pousser à acheter un nouveau téléphone.
Le leasing réintroduit cette incitation à changer régulièrement de téléphone. Sauf à réduire le prix de la location au fur et a mesure que le téléphone vieillit (ce qui semble être le cas), mais du coup, comme dit plus bas, on est juste sur du paiement étalé.
Je vois l'intérêt quand la maintenance est importante (leasing de vélo par exemple). Pour les téléphones, je suis beaucoup moins convaincu qu'il y ait un intérêt.
Et de notre côté (et dans le reste de l'Europe en général), on réagit ? Ou on se dit que ça va, c'est pas si grave de se faire couper les accès au bon vouloir d'un autocrate capricieux ? Auquel on paie des milliards pour le service, et à qui on envoie toutes nos données.
ça c'est complètement incompatible avec la philosophie du libre
Pas forcément. Beaucoup de logiciels libres ont lourdement besoin de financement. Si contracter avec le mainteneur d'un projet devient obligatoire pour l'utiliser, peut-être que ça permettra à des projets critiques, déjà utilisés par l'état, d'obtenir des financements.
Ah ben non, coucher avec un enfant c'est un crime. Mais coucher avec l'enfant de quelqu'un, du moment que c'est un adulte et que ce n'est pas le tien, ça va (enfin, y'a d'autres restrictions).
Dans 2 ou 3 ans, tu ne pourras plus acheter un PC haut de gamme ou même milieu de gamme : les constructeurs vendront tous leurs composants aux datacenters appartenant à des techno fascistes.
Non, dans 2 ou 3 ans la bulle aura éclatée et tu achèteras des cartes graphiques et de la RAM bradées, en provenance de datacenters en faillite.
Le plus inquiétant pour les logiciels propriétaires c'est que trouver des failles de sécurité dans des logiciels propriétaires va devenir aussi simple que dans des logiciels open source. Sauf que ces derniers ont eu beaucoup d'yeux qui sont passés sur leur code, alors que les logiciels propriétaires, un peu moins.
Il faut donc s'attendre à un déluge de failles exploitées.
Pas exactement pareil mais similaire dans l'esprit, le bread-board computer de Ben Eater. Il a fait une série de vidéos sur YouTube (en anglais) et vend des kits pour réaliser soi même son ordinateur 8 bit sur des breadboards: http://eater.net
Pour les performances évidemment. Si évaluer le second argument en premier permet de mieux paralléliser l'exécution (en cas de dépendance dans les données, d'utilisation de ports d'exécution limités, etc …)
La majeure partie des "undefined behavior" existent pour permettre aux compilateurs d'optimiser le code.
Et moi je me souviens d'un prof qui avait participé à sa création et qui nous en parlait sans arrêt comme du truc révolutionnaire qui aurait du conquérir le monde mais n'avait pas marché, faute à pas de chance !
Scrippy n'est pas né d'un week-end pluvieux. Il tourne depuis plusieurs années en production, sur des usages bien réels. Il a donc survécu à des mises à jour, des migrations et des vendredis après-midi, ce qui constitue une forme de certification assez exigeante.
Ah ben oui mais tout cela est vrai pour script_final_old_v3_OK_last.py qui tourne depuis plus de 10 ans en prod mon cochon! Alors ton truc kikoolol en couleur de djeuns tu peux te le garder, ça ne marche même pas avec perl (que tout vrai sysadmin préfère à python)!
Alors, ça doit faire 20 ans que je n'y ai pas touché mais pendant mes études on utilisait matlab. En libriste convaincu, j'utilisais octave personnellement, et j'en étais très content.
De ce qu'on m'a dit, octave + modelica est un excellent remplaçant à matlab + simulink. Pas exactement dans le même esprit, mais d'après certains retour plus puissant et plus flexible sur le long terme, même si un peu moins "user-friendly".
# Super Intelligence en 2030?
Posté par Colin Pitrat (site web personnel) . En réponse au journal Super intelligence : Cacophonie, bruit, Vibe coding et peut être la réponse à une question existentielle : Windows,Linux ou BSD ?. Évalué à 10 (+12/-1). Dernière modification le 15 novembre 2026 à 09:33.
Moi j'attends plutôt l'éclatement de la bulle IA en 2027. Mais je pourrais me tromper, ça pourrait se produite en 2026 en fait, il reste encore largement assez de temps. Les frasques de Jensen Huang pourraient avoir significativement accéléré les choses.
Il est probable que le financement circulaire par NVidia touche à sa fin. On voit certains projet d'infrastructure abandonnés avec des financiers qui voient leurs investissements partir en fumée (SoftBank récemment, qui avait surinvestit dans des turbines à gaz pour des datacenters par exemple). Donc les banques et les investisseurs vont être beaucoup plus regardant sur l'argent qu'ils prêtent ou investissent. Les taux d'emprunts des neoclouds crèvent déjà le plafond (si Coreweave doit emprunter aujourd'hui, ils le feront à un taux >15%). Il y a aussi les taux d'intérêt aux états unis qui vont remonter d'un cran, peut-être deux en décembre.
Je pense qu'à ce point là, plus personne ne considère qu'il est réaliste de pense que OpenAI et Anthropic ne justifieront des valeurs de plus de 1000 milliards de dollars. Jamais. (C'est à dire que la somme de leur bénéfice future imaginables, dépréciée de l'inflation, sur l'éternité, n'atteindra jamais leur "valeur" actuelle).
Cette bulle, ça me fait penser au scam Nigérien. Donne moi 100 euros pour que je sorte du Nigéria avec ma valise de diamants et je te donnerai un million d'euros. À peine plus sophistiqué.
Ça me rappelle aussi l'histoire de Ponzi. Quand il avait monté sa fameuse pyramide (supposée investir dans des timbres italiens), à un moment un analyste financier avait démonté tout ça à base d'arguments solides (aucune vente de timbres inhabituelle en Italie, aucune hausse des prix, le volume supposé de timbres dépassait déjà ce qui avait été imprimé, etc…). Les investisseurs sont venu voir Ponzi, il les a rassuré et il a même vu plus de nouveaux investissements que de départs ! Ce n'est que quand les journaux ont découvert qu'il avait déjà fait de la prison pour fraude que le run a eu lieu. Le parallèle est frappant, Ed Zitron et autres alertent sur la surchauffe et les magouilles depuis des années, mais c'est peut-être les relations extra-conjugales de Jensen Huang qui vont causer la chute!
[^] # Re: Différences entre un LLM et un compilateur ?
Posté par Colin Pitrat (site web personnel) . En réponse au journal Par la loi du bobsleigh de Lemmer-Webber, le code généré par LLM n'est à terme pas libre. Évalué à 9 (+9/-2).
La réponse est dans la question : le déterminisme.
Et aussi le côté exhaustif. Pour la majeure partie des logiciels vibe-codés, réutiliser le même prompt avec le même agent (ou un autre) produit un résultat radicalement différent. Pas juste dans le code, mais aussi dans le fonctionnement. Le code n'étant pas relu, impossible de savoir si il y a des backdoors, des bugs évidents, …
Les rares logiciels pour lesquels ça ne sera pas le cas sont ceux où l'on a donné soit une implémentation de référence à traduire (ou à copier), soit des specs très détaillées accompagnées de tests très complets. Ce dernier scénario est très rare.
Ce que j'ai vu faire aussi, c'est faire écrire les specs détaillées par le LLM. En théorie, ça devrait permettre de reproduire plus fidèlement le même comportement. Mais les specs ne sont pas vraiment connues de l'humain qui ne fait que les approuver sans trop lire. Avec les corrections de bugs, on se retrouve avec des incohérences qui peuvent facilement conduire à des absurdités dans le code qui persisteront puisqu'elles viennent de la spec.
Bref, le deuxième problème c'est la perte de contrôle. Avec les compilateurs, on perd le contrôle sur le détail de la traduction en assembleur, pas grave dans 99,9% des cas. Avec les LLMs, on perd le contrôle de la traduction de l'idée en logiciel, beaucoup plus gênant AMHA.
Le troisième problème, directement lié au deuxième : la responsabilité. Qui est responsable du résultat ? On voit de plus en plus de boîtes justifiant leurs erreurs par des "c'était un agent". C'est inacceptable. Mais si les utilisateurs doivent assumer les conséquences de ce que produisent leurs modèles, pas sûr qu'il y aura autant de preneurs…
[^] # Re: Loi du bobsleigh
Posté par Colin Pitrat (site web personnel) . En réponse au journal Par la loi du bobsleigh de Lemmer-Webber, le code généré par LLM n'est à terme pas libre. Évalué à 10 (+19/-0).
Un vrai programmeur ne commente pas, sauf sur Linuxfr!
[^] # Re: Campagne mal engagée
Posté par Colin Pitrat (site web personnel) . En réponse au journal Jeux & Stratégies - un magazine mythique en quête de résurrection.. Évalué à 2 (+0/-0).
Un de plus de mon côté. J'ai faillit en prendre 5 parce que je n'avais pas réalisé que c'était 5 fois le même numéro !
[^] # Re: Les véridiques et les menteurs
Posté par Colin Pitrat (site web personnel) . En réponse au journal Jeux & Stratégies - un magazine mythique en quête de résurrection.. Évalué à 4 (+2/-0).
En même temps c'est facile de s'y ramener : "Si il y avait une personne présente qui disait toujours le contraire de ce que tu dis"
[^] # Re: Les langages...
Posté par Colin Pitrat (site web personnel) . En réponse à la dépêche Découverte du langage Elixir. Évalué à 7 (+5/-0).
Alors là, pas d'accord du tout. Malheureusement, le monde est très ancré dans les langages procéduraux, et les plus connus se ressemblent effectivement pas mal. Donc effectivement, si tu compares python, c, c++, java, etc… tu trouves peut être que ça se ressemble (et encore). Mais la diversité des approches est bien plus grande que ça.
Et les propriétés d'un langage influencent la façon dont son écosystème est construit, la culture de ses utilisateurs, etc … (qui eux même viennent influencer la façon dont évolue le langage). Donc on ne peut pas vraiment séparer tout ça en pratique.
[^] # Re: «une autre manière de posséder un ordiphone»
Posté par Colin Pitrat (site web personnel) . En réponse à la dépêche Et si vous louiez votre prochain appareil électronique ?. Évalué à 7 (+5/-0).
L'époque "pas si reculée" est justement l'absence d'équilibre que le commentaire précédent décrit.
Personne ne payait son téléphone parce que les opérateurs l'incluaient dans le forfait, du coup les consommateurs étaient incités à changer dès que possible, personne ne cherchait à acquérir un téléphone d'occasion.
Le découplage d'avec les forfaits a supprimé cette incitation financière, il ne reste plus que l'innovation technologique (dont l'effet s'est aussi réduit, maintenant les générations de téléphones se suivent et se ressemblent) et la casse pour pousser à acheter un nouveau téléphone.
Le leasing réintroduit cette incitation à changer régulièrement de téléphone. Sauf à réduire le prix de la location au fur et a mesure que le téléphone vieillit (ce qui semble être le cas), mais du coup, comme dit plus bas, on est juste sur du paiement étalé.
Je vois l'intérêt quand la maintenance est importante (leasing de vélo par exemple). Pour les téléphones, je suis beaucoup moins convaincu qu'il y ait un intérêt.
# Bravo les Pays-Bas!
Posté par Colin Pitrat (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 42 de l’année 2026. Évalué à 4 (+2/-0).
Et de notre côté (et dans le reste de l'Europe en général), on réagit ? Ou on se dit que ça va, c'est pas si grave de se faire couper les accès au bon vouloir d'un autocrate capricieux ? Auquel on paie des milliards pour le service, et à qui on envoie toutes nos données.
[^] # Re: Patch
Posté par Colin Pitrat (site web personnel) . En réponse à la dépêche Logiciel libre: « Passer d’une logique d’encouragement à une logique contraignante ». Évalué à 2 (+0/-0).
Pas forcément. Beaucoup de logiciels libres ont lourdement besoin de financement. Si contracter avec le mainteneur d'un projet devient obligatoire pour l'utiliser, peut-être que ça permettra à des projets critiques, déjà utilisés par l'état, d'obtenir des financements.
Bon OK -> []
[^] # Re: problème de base
Posté par Colin Pitrat (site web personnel) . En réponse au journal Unicode, NDJSON et bug subtil. Évalué à 3 (+1/-0).
Je pense qu'il parle d'écrire ses fichiers CSV à la main. Du coup échapper les caractères est galère et source d'erreur.
# En Aurstralie
Posté par Colin Pitrat (site web personnel) . En réponse au journal Réseau mobile : une page se tourne. Évalué à 3 (+1/-0).
En Aurstralie ils font vraiment n'improrte quoi.
[^] # Re: et moi
Posté par Colin Pitrat (site web personnel) . En réponse au journal Et toi, tu résous comment tes requêtes DNS ?. Évalué à 5 (+4/-1).
Rust c'est dépassé, j'ai vibe-codé mon propre langage en demandant qu'il soit meilleur que Rust sur tous les tableaux. Je l'ai appelé rouille.
Mais même rouille est déjà dépassé car je travaille sur la version 2 qui va faire tout pareil mais en Très mieux, du coup je vais l'appeler t-rouille.
[^] # Re: Objection!
Posté par Colin Pitrat (site web personnel) . En réponse au journal C'est historique, le développement logiciel est entièrement automatisable. Évalué à 5 (+3/-0).
Ah ben non, coucher avec un enfant c'est un crime. Mais coucher avec l'enfant de quelqu'un, du moment que c'est un adulte et que ce n'est pas le tien, ça va (enfin, y'a d'autres restrictions).
[^] # Re: Denver le dernier dinosaure... c'est mon ami et bien plus encore
Posté par Colin Pitrat (site web personnel) . En réponse au journal 25 ans !. Évalué à 3 (+1/-0).
C'est clair, le vieux ! Moi ça ne fait que 22 ans.
[^] # Re: Il reste quoi alors ?
Posté par Colin Pitrat (site web personnel) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 4 (+2/-0).
Le logiciel prolétaire esclave.
[^] # Re: Le monde du logiciel libre va-t-il se scinder en deux ?
Posté par Colin Pitrat (site web personnel) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 3 (+1/-0).
Tu veux dire que c'est plus dur de coder des RPGs?
[^] # Re: Le monde du logiciel libre va-t-il se scinder en deux ?
Posté par Colin Pitrat (site web personnel) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 9 (+7/-0).
Non, dans 2 ou 3 ans la bulle aura éclatée et tu achèteras des cartes graphiques et de la RAM bradées, en provenance de datacenters en faillite.
Laissez moi rêver.
# Plus inquiétant
Posté par Colin Pitrat (site web personnel) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 10 (+13/-0).
Le plus inquiétant pour les logiciels propriétaires c'est que trouver des failles de sécurité dans des logiciels propriétaires va devenir aussi simple que dans des logiciels open source. Sauf que ces derniers ont eu beaucoup d'yeux qui sont passés sur leur code, alors que les logiciels propriétaires, un peu moins.
Il faut donc s'attendre à un déluge de failles exploitées.
# Version électronique
Posté par Colin Pitrat (site web personnel) . En réponse au journal Un CPU 8 bits construit à partir de portes NAND, un mini OS et un compilateur maison. Évalué à 5 (+3/-0).
Pas exactement pareil mais similaire dans l'esprit, le bread-board computer de Ben Eater. Il a fait une série de vidéos sur YouTube (en anglais) et vend des kits pour réaliser soi même son ordinateur 8 bit sur des breadboards: http://eater.net
[^] # Re: Intéressant !
Posté par Colin Pitrat (site web personnel) . En réponse au journal Un peu de fun C++esque. Évalué à 10 (+9/-0).
Pour les performances évidemment. Si évaluer le second argument en premier permet de mieux paralléliser l'exécution (en cas de dépendance dans les données, d'utilisation de ports d'exécution limités, etc …)
La majeure partie des "undefined behavior" existent pour permettre aux compilateurs d'optimiser le code.
[^] # Re: Standard Cocorico
Posté par Colin Pitrat (site web personnel) . En réponse au journal Un peu de fun polyglotte. Évalué à 4 (+2/-0).
Et moi je me souviens d'un prof qui avait participé à sa création et qui nous en parlait sans arrêt comme du truc révolutionnaire qui aurait du conquérir le monde mais n'avait pas marché, faute à pas de chance !
[^] # Re: Source
Posté par Colin Pitrat (site web personnel) . En réponse au journal Le président Forrest Trump inaugure l'ère de la super intelligence. Évalué à 5 (+3/-0).
Je pars réserver des noms de domaine en .hi alors!
[^] # Re: Slovénie
Posté par Colin Pitrat (site web personnel) . En réponse au journal Le président Forrest Trump inaugure l'ère de la super intelligence. Évalué à 5 (+3/-0).
Les nombres décimaux sont l'invention de satan. La bonne valeur pour pi c'est 3.
# Pas un prototype ?
Posté par Colin Pitrat (site web personnel) . En réponse à la dépêche Scrippy : en finir avec script_final_old_v3_OK_last.py. Évalué à 5 (+4/-1).
Ah ben oui mais tout cela est vrai pour
script_final_old_v3_OK_last.pyqui tourne depuis plus de 10 ans en prod mon cochon! Alors ton truc kikoolol en couleur de djeuns tu peux te le garder, ça ne marche même pas avec perl (que tout vrai sysadmin préfère à python)!# Octave
Posté par Colin Pitrat (site web personnel) . En réponse au journal Alternative libre à MATLAB. Évalué à 10 (+9/-0).
Alors, ça doit faire 20 ans que je n'y ai pas touché mais pendant mes études on utilisait matlab. En libriste convaincu, j'utilisais octave personnellement, et j'en étais très content.
De ce qu'on m'a dit, octave + modelica est un excellent remplaçant à matlab + simulink. Pas exactement dans le même esprit, mais d'après certains retour plus puissant et plus flexible sur le long terme, même si un peu moins "user-friendly".
Donc à essayer plus en profondeur peut-être ?