Je ne peux qu’être assez d’accord sur le problème du gaspillage d’espace disque...
J’exploite AKS, et chaque fois que je vois une appli Python avec une image de conteneur qui dépasse 1 Go, j’ai mal à la tête.
Pour l’instant, je récupère juste le Dockerfile, je réduis moi-même la taille puis je remets en ligne, et si je n’arrive pas à descendre sous les 500 Mo, j’abandonne tout simplement lol
Waouh... ! Le premier projet sur lequel je l’ai utilisé, c’était parce que c’était du Python...
Le temps a bien passé !
J’aimerais bien pouvoir retravailler dans un environnement où je peux l’utiliser à nouveau :) haha
Je devrais peut-être en faire un petit projet perso...
Vers 7 h 00, heure de Corée, le service a été interrompu pendant environ 50 minutes, mais il fonctionne bien maintenant.
CMD> nslookup news.hada.io 1.1.1.1
J’ai aussi continué à recevoir des notifications push Android indiquant qu’il était impossible d’accéder au serveur DNS.
Je me suis temporairement rabattu sur Google DNS. https://developers.google.com/speed/public-dns/…
Oui, je pense aussi que plus on creuse en profondeur la question de l’objectif et de la raison pour laquelle il faut le faire, plus une solution claire émerge.
Il suffirait sans doute d’une sacrée machine à un prix imbattable ? Un gros cabinet d’avocats l’achèterait sans hésiter. Mais bon, ce serait comme faire tourner une machine d’usine 24 h/24, lol.
L’intention du texte original n’est pas simplement de critiquer les frameworks JS devenus trop complexes.
Pour plus de commodité, je vais citer la traduction coréenne en lien ci-dessus.
> Aujourd’hui, il faut jusqu’à 4 ingénieurs, 3 frameworks et un pipeline CI/CD rien que pour changer un simple titre. Publier une page web est devenu absurdement complexe.
> Peu à peu, le web est ainsi devenu quelque chose qu’il faut compiler avant de le publier. Non pas parce que les utilisateurs en ont besoin, mais parce que les développeurs voulaient avoir l’impression d’être modernes.
> Tout a été optimisé pour les développeurs, et c’est devenu hostile à tous les autres.
> Nous ne nous contentons plus de tolérer la complexité : nous la considérons comme normale. Nous partons du principe que chaque site a besoin d’une étape de build, d’un bundler, d’une stratégie d’hydration, d’une couche de routing, d’une couche API, d’un design system et d’une logique sophistiquée d’invalidation de cache. Nous construisons en microservices, nous hébergeons sur des réseaux edge et nous déployons des pipelines pour livrer du contenu pourtant simple.
> Nous sommes en train de recréer les fonctionnalités de plateformes comme WordPress, mais avec un résultat 10 fois plus lourd et bien moins utilisable. Pire encore, chaque nouvelle couche introduit de nouveaux bugs, de nouveaux problèmes de compatibilité et une nouvelle charge cognitive. Nous en sommes maintenant à maintenir une logique d’hydration, une stratégie de cache et un pipeline de build simplement pour mettre en ligne une page d’accueil.
> Les campagnes marketing prennent du retard parce que la bibliothèque de composants n’est pas assez flexible. Les tests A/B sont annulés parce que la couche d’analytics n’est pas compatible avec la stratégie d’hydration. Les mises à jour de contenu doivent parfois attendre des jours que le build se lance. Les ajustements SEO les plus basiques se perdent dans le backlog.
> Les marketeurs ne peuvent ni mettre à jour un texte ni lancer une expérimentation sans créer un ticket. Ils ne peuvent pas prévisualiser le contenu, tester une mise en page ni publier une page. Chaque changement doit passer par des développeurs, un pipeline, des validations et une reconstruction.
> Les marketeurs, les éditeurs de contenu, les responsables SEO, les designers : tous sont exclus du processus. Car désormais, même les tâches simples exigent une aisance technique. Si vous voulez modifier une balise title, on vous dira d’en parler à un ingénieur ; si vous voulez publier une campagne, on vous dira d’ouvrir un ticket et d’attendre deux sprints.
> Tout passe par l’équipe de développement. Cela signifie que c’est elle qui décide de ce qui est important, de ce qui est déployé et de ce qui est repoussé indéfiniment dans les priorités. Et plus elle ajoute de la complexité, plus elle devient indispensable.
Je partage le constat du texte original sur le problème de la « complexité excessive du web ». En revanche, j’ai du mal à accepter un diagnostic qui en attribue la cause uniquement à la culture des développeurs ou à l’abus de frameworks. Aujourd’hui, la complexité du web est en grande partie l’ombre portée des fonctionnalités et des exigences de sécurité imposées inévitablement par les modèles économiques. Laisser de côté cet aspect ne peut conduire qu’à une analyse incomplète.
Le web n’est plus une « galerie gratuite ». À l’exception des sites publics, la plupart des services web actuels ont pour objectif de générer des revenus. Dès lors, la question centrale dans le choix technique ne devrait pas être « ce code est-il pur ? », mais « cette technologie permet-elle à notre activité de réussir ? ».
Vu sous cet angle, le « web de contenu léger » idéalisé par le texte original se heurte au mur des exigences économiques du monde réel. Par exemple, une activité qui vend du contenu ne peut pas fonctionner avec de simples pages statiques. Pour gérer les abonnements payants et les paiements, il faut une logique à états comme l’authentification utilisateur, la vérification du statut d’abonnement et la gestion des autorisations ; pour protéger le contenu, une couche de sécurité comme la validation en temps réel des tokens afin d’empêcher la copie illégale ou les accès non autorisés est indispensable. De plus, pour améliorer l’expérience utilisateur et le taux de conversion via la personnalisation et les tests A/B, un traitement dynamique des données est également nécessaire.
Tout cela relève du domaine de l’« application sophistiquée », et les frameworks sont des outils pragmatiques pour le mettre en œuvre.
Bien sûr, toute complexité ne peut pas être justifiée. Nous devons distinguer deux types de complexité.
Complexité inévitable : c’est la complexité, au ROI clair, qui apparaît pour implémenter des fonctionnalités métier (authentification, paiement, personnalisation, etc.). C’est un coût qu’il faut accepter.
Complexité accidentelle : c’est la complexité inutile créée par la commodité du développement ou par une abstraction technique excessive. C’est une dette technique et un gaspillage qu’il faut mesurer en continu et éliminer.
Les services qui réussissent distinguent ces deux dimensions pour construire une architecture réaliste. Autrement dit, ils allègent au maximum la couche de front où le marketing et le SEO sont essentiels, tout en s’appuyant sur des frameworks dans les zones internes qui nécessitent des transactions critiques ou des fonctions de personnalisation, afin d’assurer la fiabilité : une stratégie hybride qui permet de concilier rapidité et richesse fonctionnelle.
Le texte original se concentre sur la culture des frameworks comme seule cause de la dégradation de l’expérience utilisateur, en écartant les « exigences inévitables engendrées par le modèle économique ». Parler du développement web sans cet élément, c’est un peu comme parler uniquement du fait de servir au client un « plat rapide et savoureux » à sa table, tout en faisant comme si la cuisine complexe où ce plat est préparé et la caisse où l’on encaisse n’existaient pas.
Parce que le web est lourd, on ne peut pas simplement abandonner les frameworks sans réfléchir. À mon sens, le vrai sujet est de savoir comment implémenter le plus efficacement possible, au coût minimal, les fonctionnalités exigées par l’activité afin de délivrer de la valeur à l’utilisateur.
Pour un service de type chatbot qui doit proposer une fonctionnalité de streaming, lors du traitement simultané, l’étape de prefill est affectée jusqu’au decode ; ainsi, même si la VRAM est suffisante, du point de vue de l’utilisateur, on a l’impression que les performances se dégradent fortement.
J’ai aussi testé les options liées au chunk prefill ainsi que la fonctionnalité expérimentale de Disaggregated Prefilling proposée par vLLM, mais dès qu’une nouvelle requête arrive, les réponses déjà en cours de génération continuent de se couper par à-coups. En tant que développeur débutant, je me demande donc s’il existe une méthode plus efficace que d’augmenter simplement le nombre de GPU ou de nœuds.
N’est-ce pas plutôt une manière d’assumer ses responsabilités ? Pour ma part, j’ai l’impression de partager globalement l’orientation prise par Google.
J’aurais aimé qu’on montre par des chiffres à quel point c’est nettement amélioré, performant et précis.
Je me demande en quoi la Corée est différente.
Je ne peux qu’être assez d’accord sur le
problème du gaspillage d’espace disque...J’exploite AKS, et chaque fois que je vois une appli Python avec une image de conteneur qui dépasse 1 Go, j’ai mal à la tête.
Pour l’instant, je récupère juste le Dockerfile, je réduis moi-même la taille puis je remets en ligne, et si je n’arrive pas à descendre sous les 500 Mo, j’abandonne tout simplement lol
Waouh... ! Le premier projet sur lequel je l’ai utilisé, c’était parce que c’était du Python...
Le temps a bien passé !
J’aimerais bien pouvoir retravailler dans un environnement où je peux l’utiliser à nouveau :) haha
Je devrais peut-être en faire un petit projet perso...
Comparer Claude 3 au moment où Claude 4 est déjà sorti, ce n'est pas presque de l'arnaque...?
Vers 7 h 00, heure de Corée, le service a été interrompu pendant environ 50 minutes, mais il fonctionne bien maintenant.
CMD> nslookup news.hada.io 1.1.1.1
J’ai aussi continué à recevoir des notifications push Android indiquant qu’il était impossible d’accéder au serveur DNS.
Je me suis temporairement rabattu sur Google DNS.
https://developers.google.com/speed/public-dns/…
waouh...
Oui, je pense aussi que plus on creuse en profondeur la question de l’objectif et de la raison pour laquelle il faut le faire, plus une solution claire émerge.
Merci d’avoir apprécié l’article !
Merci pour ces belles paroles !
Il suffirait sans doute d’une sacrée machine à un prix imbattable ? Un gros cabinet d’avocats l’achèterait sans hésiter. Mais bon, ce serait comme faire tourner une machine d’usine 24 h/24, lol.
Une personne qui ne pense qu’au prix d’une Porsche sans accorder la moindre attention aux frais d’entretien, au carburant, à l’assurance, etc.
L’intention du texte original n’est pas simplement de critiquer les frameworks JS devenus trop complexes.
Pour plus de commodité, je vais citer la traduction coréenne en lien ci-dessus.
> Aujourd’hui, il faut jusqu’à 4 ingénieurs, 3 frameworks et un pipeline CI/CD rien que pour changer un simple titre. Publier une page web est devenu absurdement complexe.
> Peu à peu, le web est ainsi devenu quelque chose qu’il faut compiler avant de le publier. Non pas parce que les utilisateurs en ont besoin, mais parce que les développeurs voulaient avoir l’impression d’être modernes.
> Tout a été optimisé pour les développeurs, et c’est devenu hostile à tous les autres.
> Nous ne nous contentons plus de tolérer la complexité : nous la considérons comme normale. Nous partons du principe que chaque site a besoin d’une étape de build, d’un bundler, d’une stratégie d’hydration, d’une couche de routing, d’une couche API, d’un design system et d’une logique sophistiquée d’invalidation de cache. Nous construisons en microservices, nous hébergeons sur des réseaux edge et nous déployons des pipelines pour livrer du contenu pourtant simple.
> Nous sommes en train de recréer les fonctionnalités de plateformes comme WordPress, mais avec un résultat 10 fois plus lourd et bien moins utilisable. Pire encore, chaque nouvelle couche introduit de nouveaux bugs, de nouveaux problèmes de compatibilité et une nouvelle charge cognitive. Nous en sommes maintenant à maintenir une logique d’hydration, une stratégie de cache et un pipeline de build simplement pour mettre en ligne une page d’accueil.
> Les campagnes marketing prennent du retard parce que la bibliothèque de composants n’est pas assez flexible. Les tests A/B sont annulés parce que la couche d’analytics n’est pas compatible avec la stratégie d’hydration. Les mises à jour de contenu doivent parfois attendre des jours que le build se lance. Les ajustements SEO les plus basiques se perdent dans le backlog.
> Les marketeurs ne peuvent ni mettre à jour un texte ni lancer une expérimentation sans créer un ticket. Ils ne peuvent pas prévisualiser le contenu, tester une mise en page ni publier une page. Chaque changement doit passer par des développeurs, un pipeline, des validations et une reconstruction.
> Les marketeurs, les éditeurs de contenu, les responsables SEO, les designers : tous sont exclus du processus. Car désormais, même les tâches simples exigent une aisance technique. Si vous voulez modifier une balise title, on vous dira d’en parler à un ingénieur ; si vous voulez publier une campagne, on vous dira d’ouvrir un ticket et d’attendre deux sprints.
> Tout passe par l’équipe de développement. Cela signifie que c’est elle qui décide de ce qui est important, de ce qui est déployé et de ce qui est repoussé indéfiniment dans les priorités. Et plus elle ajoute de la complexité, plus elle devient indispensable.
Ça ne semble pas applicable aux entreprises coréennes.
Je partage le constat du texte original sur le problème de la « complexité excessive du web ». En revanche, j’ai du mal à accepter un diagnostic qui en attribue la cause uniquement à la culture des développeurs ou à l’abus de frameworks. Aujourd’hui, la complexité du web est en grande partie l’ombre portée des fonctionnalités et des exigences de sécurité imposées inévitablement par les modèles économiques. Laisser de côté cet aspect ne peut conduire qu’à une analyse incomplète.
Le web n’est plus une « galerie gratuite ». À l’exception des sites publics, la plupart des services web actuels ont pour objectif de générer des revenus. Dès lors, la question centrale dans le choix technique ne devrait pas être « ce code est-il pur ? », mais « cette technologie permet-elle à notre activité de réussir ? ».
Vu sous cet angle, le « web de contenu léger » idéalisé par le texte original se heurte au mur des exigences économiques du monde réel. Par exemple, une activité qui vend du contenu ne peut pas fonctionner avec de simples pages statiques. Pour gérer les abonnements payants et les paiements, il faut une logique à états comme l’authentification utilisateur, la vérification du statut d’abonnement et la gestion des autorisations ; pour protéger le contenu, une couche de sécurité comme la validation en temps réel des tokens afin d’empêcher la copie illégale ou les accès non autorisés est indispensable. De plus, pour améliorer l’expérience utilisateur et le taux de conversion via la personnalisation et les tests A/B, un traitement dynamique des données est également nécessaire.
Tout cela relève du domaine de l’« application sophistiquée », et les frameworks sont des outils pragmatiques pour le mettre en œuvre.
Bien sûr, toute complexité ne peut pas être justifiée. Nous devons distinguer deux types de complexité.
Complexité inévitable : c’est la complexité, au ROI clair, qui apparaît pour implémenter des fonctionnalités métier (authentification, paiement, personnalisation, etc.). C’est un coût qu’il faut accepter.
Complexité accidentelle : c’est la complexité inutile créée par la commodité du développement ou par une abstraction technique excessive. C’est une dette technique et un gaspillage qu’il faut mesurer en continu et éliminer.
Les services qui réussissent distinguent ces deux dimensions pour construire une architecture réaliste. Autrement dit, ils allègent au maximum la couche de front où le marketing et le SEO sont essentiels, tout en s’appuyant sur des frameworks dans les zones internes qui nécessitent des transactions critiques ou des fonctions de personnalisation, afin d’assurer la fiabilité : une stratégie hybride qui permet de concilier rapidité et richesse fonctionnelle.
Le texte original se concentre sur la culture des frameworks comme seule cause de la dégradation de l’expérience utilisateur, en écartant les « exigences inévitables engendrées par le modèle économique ». Parler du développement web sans cet élément, c’est un peu comme parler uniquement du fait de servir au client un « plat rapide et savoureux » à sa table, tout en faisant comme si la cuisine complexe où ce plat est préparé et la caisse où l’on encaisse n’existaient pas.
Parce que le web est lourd, on ne peut pas simplement abandonner les frameworks sans réfléchir. À mon sens, le vrai sujet est de savoir comment implémenter le plus efficacement possible, au coût minimal, les fonctionnalités exigées par l’activité afin de délivrer de la valeur à l’utilisateur.
Pour un service de type chatbot qui doit proposer une fonctionnalité de streaming, lors du traitement simultané, l’étape de prefill est affectée jusqu’au decode ; ainsi, même si la VRAM est suffisante, du point de vue de l’utilisateur, on a l’impression que les performances se dégradent fortement.
J’ai aussi testé les options liées au chunk prefill ainsi que la fonctionnalité expérimentale de Disaggregated Prefilling proposée par vLLM, mais dès qu’une nouvelle requête arrive, les réponses déjà en cours de génération continuent de se couper par à-coups. En tant que développeur débutant, je me demande donc s’il existe une méthode plus efficace que d’augmenter simplement le nombre de GPU ou de nœuds.
N’est-ce pas plutôt une manière d’assumer ses responsabilités ? Pour ma part, j’ai l’impression de partager globalement l’orientation prise par Google.
Je suis d’accord aussi. Je ne sais pas si c’est de la duplicité. Ils semblent laisser tranquilles ceux qui sont bien faits.
Je ne vois pas en quoi on peut parler d'une attitude contradictoire...