Anaïs Sparesotto : « On a habitué les internautes à des centaines de fonctionnalités inutiles »
Questionner le besoin
Comment expliquer que le poids des logiciels et pages web s’est démultiplié à mesure que les performances du matériel numérique augmentaient ? Comment écoconcevoir des services numériques ? Dans le cinquième épisode d’Écosystème, Anaïs Sparesotto décrypte les enjeux environnementaux du développement logiciel et web.
Le 23 juillet 2025 à 17h22
5 min
Société numérique
Société
Entre 2010 et 2020, le poids des sites web a été multiplié par dix, selon GreenIT. Au moment même où, côté matériel, la « loi » de Moore s’essouffle, la partie logicielle et web de nos équipements numérique, elle, continue de prendre ses aises. Avec pour effet d’empêcher la réduction des impacts environnementaux des équipements numériques.
Mais comment, concrètement, la fabrication d’un logiciel ou d’une page web joue-t-elle sur la consommation énergétique ou les autres effets environnementaux du numérique ? Qu’est-ce qui fait que telle page est légère, quand telle autre contribue à l’effet rebond propre au numérique, celui qui empêche de profiter des améliorations techniques du matériel pour aller vers plus de sobriété ?
Ce sont ces questions que nous explorons dans le cinquième épisode d’Écosystème. Développeuse web chez Toovalu et formatrice à l’Ada tech School, Anaïs Sparesotto nous expose aussi le fonctionnement des logiques d’écoconception, qui visent à développer des services numériques aussi respectueux de l’environnement que possible.
Des fonctionnalités démultipliées
« Aujourd’hui, il paraît évident que sur n’importe quelle plateforme, on renseigne une photo de profil, quel que soit le logiciel ou le site web auquel vous allez vous inscrire. » Anaïs Sparesotto illustre son propos avec l'exemple des plateformes de vente de particulier à particulier.
Il reste 68% de l'article à découvrir.
Déjà abonné ? Se connecter
Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.
Accédez en illimité aux articles
Profitez d'un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Anaïs Sparesotto : « On a habitué les internautes à des centaines de fonctionnalités inutiles »
-
Des fonctionnalités démultipliées
-
Revenir à l’essentiel
Commentaires (39)
Le 23/07/2025 à 18h01
Je crois que c'est ici-même que j'avais lu un article qui analysait le poids de certaines pages d'accueil connues pour lesquelles il y avait 0 optimisation : des images de qualité bien trop grandes par rapport au besoin, des JS à n'en plus finir pour la floppée de régies pubs et d'outils de metrics qui doivent être consultés tous les 3 ans...
On a surtout pris l'habitude qu'un code crade reste fluide parce qu'un appareil lambda peut largement encaisser la charge associée, et la connexion 8Gb-pour-aller-lire-lequipe aussi.
Mais aller grappiller un petit avatar (d'ailleurs je viens de voir que vous ne chargez plus la version HD désormais
Modifié le 24/07/2025 à 09h18
- avec un navigateur "à poil"
- avec le même navigateur + adblock
- avec le même navigateur + adblock + Noscript
Grosso modo, le poids d'une page web était divisé par presque 10 sans trop de difficulté sur bcp de sites. Il y avait une extension de FF qui indiquait d'ailleurs le poids des images, des scripts et des éléments HTML dans la barre d'information du bas (qui a disparu)
De nos jours, si on "inspecte" une page avec Firefox, et qu'on se rend dans "Réseau", on peut avoir une idée du poids d'une page et de son temps de téléchargement (et donc quantifier l'efficacité d'un bloqueur de pub).
Par exemple, chez clubic (qui n'est pas dans les pires, à mon avis) :
- avec un FF à poil : 4.34 Mo / 988 ko transféré et 1.9s de traitement
- avec un FF + Mublock (avec bcp de listes) et Adguard Home : 3.48 Mo / 684 ko et 1.9s de traitement
- avec un FF + Mublock (avec bcp de listes) et Adguard Home + Nocript (domaine principal autorisé) : 3.48 Mo / 684 ko et 1.45s de traitement
Les écarts peuvent être bien plus conséquents sur certains sites (là, c'est assez modéré, donc Clubic n'abuse pas, en tout cas en 2025)
Le 24/07/2025 à 09h56
Le chargement d'une page de 4,34 Mo ne va pas consommer plus au niveau des infrastructures réseau modernes à être transportée - c'est pas forcément intuitif mais c'est vrai - elle ne va pas consommer plus à être affichée, le terminal et l'ensemble du matériel utilisé pour la servir sur toute la chaine est le même et ne s'use pas plus à servir 10 fois plus d'infos, et 4,43 Mo vont consommer environ 0,1W côté serveur pendant une seconde à être délivrés.
En gros, si vous n'allumez pas une heure un radiateur de 1 000 W l'hiver prochain, vous allez compenser l'ouverture de 36 millions de pages de 4,34 Mo.
Mettons que vous consultez 150 pages web par jour, ça nous donne 240 000 jours de compensés, soit 657 ans de vie. Pour une heure de chauffage d'une surface de 50m².
Est-ce qu'il n'y a pas des économies de ressources plus évidentes à aller chercher ?
Est-ce que ce sujet n'est-il pas un vaste abus à l'encontre des diptères ?
A l'inverse, quelles seraient les ressources nécessaires pour optimiser toutes nos ressources web ?
C'est très compliqué à calculer, mais si je devais parier quelque chose, je dirais que cet effort aurait un résultat net négatif pour la planète par rapport aux ressources économisées.
Le 24/07/2025 à 10h32
Modifié le 24/07/2025 à 11h00
Hélas, c'est faux. Toute information traitée/manipulée par un système numérique induit des transistors qui vont changer d'état, et donc une consommation élémentaire, peu importe la nature du circuit. Pareil dans le transport de l'information. Alléger tes data de 80%, c'est donc alléger la consommation électrique de l'ensemble de la chaine d'un coefficient non négligeable (un peu moins de 80% car il y a des consommations constantes, mais généralement prévues pour être faibles).
L'impact sur les ressources est donc immédiat : si pour faire transiter la même information, il te faut 5x moins de ressources matérielles, tu peux te contenter de moins d'équipements, et donc pas besoin de les fabriquer.
Reste la consommation sur le terminal et le serveur aux deux bouts de la chaine : des données compressées peuvent nécessiter plus de ressources aux deux extrémités par exemple. Cependant, dans le cas de la pub, ne plus l'afficher, c'est gagner sur toute la chaine : plus d'émission depuis un serveur, plus de transport, et plus de traitement.
NB : l'exemple de clubic n'est pas le meilleur, car le gain est étonnement faible sur leur site (en tout cas, ils ont dû faire des efforts). Le ratio de 10% de poids utile pour 90% de trackers/pubs n'est pas tiré d'un mouchoir.
Le 24/07/2025 à 11h22
Si on construisait tout de zéro aujourd'hui on pourrait en discuter (à la marge en vrai, si ça doit pouvoir transporter un film c'est pas la page à 4Mo qui fera la diff) mais en l'état c'est peine perdue.
Un réseau optique consomme à peu près la même chose qu'il soit utilisé à 0% ou à 100%.
Le 24/07/2025 à 11h15
et il faut prendre en compte le réseaux électrique qui est dimensionné aussi pour pouvoir absorbé les pics de consommation, les pertes de transformation et je ne sais quoi d'autre.
Je ne suis pas spécialiste, je ne sais pas être plus précis, je remarque juste que ton calcule est biaisé et largement sous estimé.
Le 24/07/2025 à 11h30
Nous opérons des serveurs, des réseaux optiques, et du transit, et c'est nous qui payons la facture d'élec à la fin.
Le calcul que je fais est globalement correct, je crois, il n'est évidemment pas précis, il est schématique, mais les ordres de grandeurs sont là.
Je pars du principe que la charge est parfaite sur le serveur, car si elle ne l'est pas, c'est encore pire, le serveur consomme à ne pas servir de données - ce qui ne va pas dans le sens de la nécessité d'optimiser les requêtes.
D'ailleurs, dans le cas d'une grosse portion de services web aujourd'hui, ce sont des VM derrière, ce qui est optimal en termes d'efficacité chez les gros CSP.
(Ce qui n'est pas optimal pour le client financièrement parlant, mais c'est un autre débat.)
Le 24/07/2025 à 11h57
De ton côté, tu parles en fonction des infra existantes. Un peu plus ou un peu moins de données ne change rien.
De l'autre côté, @neod ou @WarMachine, j'ai l'impression qu'ils prennent en compte l'influence de la consommation sur le dimensionnement de l'infrastructure. Une consommation de data moindre ne nécessiterait pas un réseau dimensionné comme il peut l'être aujourd'hui, ce qui induit donc une consommation supplémentaire car on pourrait se contenter de moins d'équipement.
Autrement dit, une infra pouvant supporter 10Go/s ou 100To/s ne va pas consommer la même chose rien que par le fait d'être allumé, et ceci, indépendamment du trafic qu'il peut y avoir à un instant T.
Modifié le 24/07/2025 à 12h39
Déjà, les réseaux fibre en place suffiront pour des décennies, il fallait bien la déployer une fois cette infra - qui ne sert pas qu'à afficher des avatars, je le rappelle.
Je donne des chiffres précis en développant mon raisonnement, basé sur mon expérience professionnelle, de ce que consomment les infras en place sur la base de vrais chiffres.
On peut débattre de la façon de calculer l'empreinte, de la durée d'amortissement des matériels, mais la contradiction ici ne vient pas du calcul, elle vient plus d'une posture IMHO.
Je pense que la réalité exacte se situe - tous facteurs confondus - quelque part autour d'un facteur 10 de mon résultat.
En worst case, scenario, quand bien même on serait à 65 ans de vie de pages toutes à 4,34 Mo pour une heure de chauffage, est-ce que la conclusion n'est-elle pas la même ?
Si c'est un facteur 100, et qu'on parle d'une heure de chauffage tous les 6 ans et demi, pareil non ?
Mon point c'est qu'à chaque fois qu'on parle de sobriété de contenu (vidéos 4k, grosses pages web, sobriété logicielle...), on parle plus d'idées que de faits, et les infras sont d'une efficacité rarement retranscrite par des interlocuteurs qui sont souvent loin de la réalité opérationnelle (et cette efficacité va en s'améliorant, alors que l'usage tend globalement à se stabiliser).
Edit : je précise ici que je n'ai pas d'infos particulières sur la conso des réseaux cellulaires, on part sur un delivery full fibre jusqu'à l'abonné.
Le 24/07/2025 à 12h56
Je suis d'accord avec toi sur la topologie, et d'autant plus que la fibre a une durée de vie extrêmement longue (sauf accident ou sabotage !).
Par contre, peut-on dire de même des équipements actifs tout autour ? Je ne suis pas spécialiste (tu l'es bien plus que moi à ce sujet ;) ), mais les répéteurs & co. ça consomment aussi et cela a aussi une durée de vie, que je dirais de bien moindre dans la mesure où il s'agit d'appareils électroniques.
Plus il y en a, plus cela consomme, et plus on changent / réparent. Je ne crois pas (mais tu m'arrêteras là dessus) que quand on a des liens à 100To/s par exemple, et qu'il faut mettre un répéteur, que tu vas mettre le même si le lien est un simple lien à 10Go/s. Je ne suis même pas certains qu'un seul puisse suffire, et qu'il faudra sans doute en agréger plusieurs. On aurait besoin de moins de débit (je ne parle pas de couverture, juste de débit), on pourrait peut être avoir moins d'équipements qui traitent le tout non ?
Après, c'est peut être mon parallèle foireux à la dimension d'une entreprise, mais quand on arrive aux limites de bande passante d'un switch, ben on en met un deuxième (ou un plus gros, mais qui consomme plus aussi).
Je te rejoins là dessus. On peut entendre beaucoup de connerie sur le sujet. Non, 1h de Netflix ne va pas tuer la planète en tant que tel (je crois que c'est l'équivalent à 200m en voiture thermique de mémoire). Je préfère largement ne pas prendre ma voiture, j'ai un bien meilleur impact sur mon environnement ainsi ! (mais je regarde Netflix)
Mais ça, c'est pour une vision à l'échelle instantanée d'une personne. Si on prend un peu de recul, on voit bien que la consommation de data ne fait que croitre d'année en année, incitant toujours à investir plus dans les infra réseaux. Et là, si on commence à répercuter de manière comptable (= en parlant d'amortissement), en prenant en compte les équipements sur toute la chaine, alors non, je ne suis pas certains que le réseau soit toujours aussi négligeable que cela. Sauf qu'à l'échelle individuel, on n'a aucun impact là dessus. C'est dans le collectif que cela se joue...
Et encore faudrait-il aussi définir ce que l'on entend par infra. Est-ce juste le réseau ? Est-ce aussi les serveurs qui desservent les pages web ? etc. Car bon, faut pas se leurrer non plus, mais si tu as besoin de 5 serveurs pour ton site ou d'un seul, ce n'est clairement pas la même chose en terme d'impact, que ce soit d'un point de vue alimentation ou même fabrications des serveurs.
Je suis d'accord pour dire que ce n'est pas les avatars pour un site comme Vinted ou Le Bon Coin qui vont changer grand chose, fasse aux nombres de photos qu'ils doivent stocker pour les articles. Mais je pense que s'interroger sur ce qui est nécessaire ou pas, c'est quand même quelque chose d'important. Et là, pour le coup, perso, ce qui ne me parait pas nécessaire dans la grande majorité des cas, et que pourtant on est en train de nous foutre partout, c'est bien l'IA... Elle a même débarqué dans le bloc note. Dans le bloc note...
Modifié le 25/07/2025 à 06h22
On a trois postes de conso élec :
- Le datacenter
- Le transport backbone & last mile
- Le LAN
Il est entendu que les serveurs sont utilisés à fond, pour que l’optimisation du code soit synonyme de moins de ressources utilisées sinon ça ne sert à rien.
Également, nous tenons compte du fait que l’usage de l’infra en général est utilisée par des millions de services en parallèle, d’une façon relativement constante - comme c’est le cas dans la vraie vie.
Le datacenter, c’est la partie compliquée, on va dire que le site est hébergé sur un serveur de moins de 5 ans, que le PUE du site est de 1.5, que c’est un VPS avec plein de VMs, que le serveur crache 10 Gbps en moyenne pour 300W de conso (ça peut monter bien plus haut sur ce budget énergie, mais soyons conservateurs).
Ce serveur est relié à trois switchs successifs avant d’arriver sur le backbone, chaque switch consomme 400W en moyenne, mais il y a 48 machines sur le premier, 500 sur le second, et 4000 sur le core (restons sur des pizzabox pour faire simple).
400/48+400/500+400/4000=10W
Pour une ressource de 4,34 Mo, on a donc 4,34/10000x8x(300+10)/3600=0.000297222 Wh.
Si on tient compte du PUE, on arrive à 0.0004458 Wh pour une page servie.
Parlons backbone.
Imaginons que le datacenter est à 1 000 km de l’usager - ce qui est conservateur pour la France qui a globalement ses ressources en son centre, mais qui tient compte des quelques ressources hébergées en dehors de son territoire.
L’usager est client d’un des 4 gros opérateurs de FTTH, qui a ses propres backbones, avec de la charge.
Un équipement de transmission optique moderne crache plusieurs dizaines de Tbps de capa en OTN, mais imaginons que le backbone est très peu chargé, et qu’il n’envoie que 500 Gbps en moyenne.
On va consommer environ 300W tous les 100km, soit 3000W pour les 1000km, pour 500 Gbps.
On refait le calcul, 4.34/500000x8x3000/3600=0.00005786 Wh.
Des clopinettes, là encore.
LAN du client, relou, ça dépend d’énormément de paramètres.
Je le mets pudiquement de côté, pour ne faire le calcul que sur ce que l’usager ne voit pas, mais fantasme, les infras.
D'ailleurs, l'empreinte de la fabrication des terminaux est infiniment supérieure à celle des infras mutualisées - ce qui n'est pas particulièrement agréable à entendre si on aime se défausser de sa propre responsabilité sur le cloude, je le conçois. On est tous humains.
Revenons à nos agneaux, hors LAN, on a donc 0,000506 Wh pour la page web.
On prend les 1000 W du radiateur, on les divise par notre conso ridicule, on obtient un facteur 1 974 983.
On divise ce facteur par 150 pages web par jour, on arrive à 13 166 jours de navigation.
On divise par 365, ça fait 36 ans.
Les paramètres modifiés par rapport à tout à l’heure c’est qu’on n’envoie que 10G par serveur (au lieu de 100G initialement) et qu’on tient compte de la conso backbone et du PUE du DC.
Donc c’est 36 fois plus efficace de couper son radiateur une heure par an que d’écoconcevoir toutes les pages web de 4,34 Mo.
A noter, une page web en moyenne est de 2,5 Mo aujourd’hui. On est donc plutôt sur un facteur 62, dans l’hypothèse où on arrive à réduire la page à quelques ko.
Si on se dit qu’on fait seulement un -50%, on arrive à 124 années de pages à 2,5 Mo pour une heure de chauffage.
L’écoconception des pages web, c’est de la flute sur le plan environnemental, c’est au mieux plus fluide pour l’usager.
Ce raisonnement n'est pas valable pour tous les services IT, il est infiniment plus complexe sur le sujet de l'IA, et oui, le numérique a une empreinte réelle sur l'environnement.
Mais faut arrêter de raconter n'importe quoi.
Modifié le 24/07/2025 à 17h13
Parce que sur le fond, je suis entièrement d'accord avec toi. Il y a des choses bien plus utile et impactante que de simplement arrêter de mettre des avatars.
Là où perso je trouve la démarche utile, c'est qu'elle incite à se poser des questions ! Pas de bol, pour les avatars, c'est peanuts, mais cela ne veut pas toujours dire que c'est le cas. Est-ce qu'on a autant besoin des avatars partout que des IA partout ? La même question amène, toujours de mon point de vue, la même réponse. Par contre, l'impact sera radicalement différent.
Surtout que les fonctionnalités inutiles (l'IA, tousse tousse) incite à avoir des équipements toujours plus puissants, donc participe au renouvellement anticiper de terminaux tout à fait fonctionnel.
Mais sinon, un gros poutou pour toi pour cette démonstration
[edit] un ajout mineur juste pour éclaircir mon propos, quand je dis IA, c'est un énorme raccourci pour les LLM et les IA génératrices.
Le 25/07/2025 à 21h56
Il y a des portables qui ont 200 Mpixels ( https://www.frandroid.com/produits/smartphones/capteur-photo-200-mpx ). On peut franchement douter de la pertinence d'un tel capteur, un APN pro a moins de pixels et est déjà limité en finesse par son objectif pourtant haut de gamme. Toujours est t'il que cela fait 200 Mpixels 3 couleurs 8 bits/couleur = 600 Mo pour juste décompresser le jpeg avant de faire le redimensionnement en genre 120x120 !
Bien sûr un utilisateur avisé va redimensionner l'image sous Gimp ou autre. Une appli peut faire un redimensionnement local (enfin si elle est bien faite) mais si c'est en web et que l'utilisateur n'a pas conscience de cela (comme + de 95% de la population) bah, va bien falloir traiter l'image sur le serveur.
C'est 600 Mo.
Le 24/07/2025 à 17h43
La quantité de données transférée n'est pas le cœur du problème écologique, loin de là.
Le 31/07/2025 à 09h10
La comparaison au chauffage me laisse dubitatif : le chauffage est essentiel (c-à-d on peut mourir de froid), les librairies JS complètes, et images HD pour faire une miniature, ou pour le cas de clubic la requête GraphQL toutes les minutes de 1,91Mo ! récupérant ad-nauseam les mêmes données en mode annule et remplace : ça n'apporte pas de fonctionnalités c'est simplement mal codé.
Le fait que le transport (en fibre) ne coûte plus grand chose, ne justifie pas de faire n'importe quoi. Tu raisonnes côté infra server (normal c'est ton boulot), mais tu sembles oublier le reste de la photo :
les CDN payent une partie de ta facture d'électricité à reservir le cache des ressources qui ne sortent qu'une fois de ton server,
sur les 5 millions de visiteurs uniques de Clubic :
- combien sont en cuivre ? (ADSL, ou cable), ou pire wireless (satellite, WiMax...)
- combien surconsomme leur box Wifi qui ne se met pas en veille à cause du "ping" toutes les min pour un onglet Clubic +/- oublié ?
- quid de la charge CPU du JS qui va toutes les minutes réclamer l’entièreté de la page, parser un GraphQL, et reconstruire le DOM.
- qui dit charge CPU, dit conso batterie et donc usure prématuré de la batterie du laptop...
Tout ça ce n'est pas grand chose... x5 millions, pour 1 seul onglet d'1 seul site...
Le pire dans tout ça c'est que Clubic n'est pas si mal codé...
Le 31/07/2025 à 09h59
Vous pouvez faire toutes les circonvolutions intellectuelles que vous voulez, ces chiffres sont les plus proches de la réalité que nous ayons.
La comparaison avec le chauffage c’est que c’est simple d’éteindre le radiateur une fois dans une vie pendant une heure, alors qu’optimiser l’ensemble du web serait un effort considérable (évangélisation + optimisation).
Le 01/08/2025 à 11h37
Concernant l'évangélisation, je pense qu'il faut la faire : en formation informatique pour les techniques et en indicateur / reporting "green IT" obligatoire (voir taxe) côté décideur. Même si entre Trump et la folie tout-IA, j'ai peur que le green IT soit le cadet des soucis de nos décideurs... L'optimisation suivra avec la maintenance ou les refontes où ce sera demandé explicitement directement dans l'expression de besoins.
Et je réponds que l'un n’empêche pas l'autre ;)
Il aurait été très simple que le dev de Clubic code un algo en delta qui n'aurait demandé que les nouveaux articles : ça n'aurait transporter / recalculer la page qu'en cas de nouveau contenu publié, la conso aurait été moindre à tout niveau, et l'usage parfaitement identique.
Le 23/07/2025 à 18h27
Modifié le 24/07/2025 à 10h55
Le 23/07/2025 à 18h52
Non, les véritables sources de l'alourdissement, c'est :
1. L'abstraction. Sous des prétextes de facilitation de développements, les devs vont inclure une bibliothèque qui pèse son poids alors qu'ils utilisent 1 % de ses fonctions. Au lieu de développer un site à la main, ils vont utiliser Wordpress pour un site vitrine statique.
2. La multiplication des publicités et trackers. Si vous allez sur les sites de journaux par exemple, sans adblock, vous multiplier le nombre de requêtes par 10 et le poids par 5 (je viens de tester sur le figaro). L'ordre de grandeur avec/sans adblock sur le bon coin est plus ou moins le même.
Bref, les fonctionnalités ne sont pas la cause des problèmes, si problèmes il y a.
Le 23/07/2025 à 23h01
Et là, je lui ai dit : notre application n'est pas internationale et n'a que des numéros français à 99,9%. Donc, tu me vires ça, et tu me fais une simple regex.
Le truc, c'est que ces abstractions rendent aussi les technos accessibles. Un site vitrine statique avec Wordpress, quasiment n'importe qui peut le faire (surtout que bon nombres d'hébergeurs propose de l'installer pour toi). Un site vitrine statique sans Wordpress, c'est déjà beaucoup plus complexe et nécessite des compétences que tout le monde est loin d'avoir.
Le 24/07/2025 à 08h13
Le 24/07/2025 à 20h11
C'est fou le nombre d'éléments de composition qui reposent sur des tonnes de JS quant ils peuvent être faits avec quelques lignes de CSS et du HTML.
Modifié le 24/07/2025 à 20h52
Et hautement configurable. On ne prend que ce dont on a besoin.
Le 24/07/2025 à 21h14
Perso je sais pas dev en JS et ça m'intéresse pas. Mes sites web n'en contiennent pas, en dehors d'un fait viteuf à coup de chat bot pour afficher un feed mastodon on se basant sur le RSS (celui de Bluesky est un trouvé sur le Web).
Et j'ai quand même réussi à faire des éléments sympa genre un carousel sans JS. Bon, il bouge pas tout seul, mais en même temps, j'aime bien les trucs qui ne gigotent pas dans tous les sens
Le 23/07/2025 à 19h55
Le 23/07/2025 à 21h01
Et à CHAQUE fois, le SEUL truc qui pète tout, que ça soit en terme de lourdeur, de compatibilité, de rapidité ou de sécurité, c'est ... LES PUBS GOOGLE ! (parce qu'il faut bien bouffer).
Le 23/07/2025 à 21h08
Le 23/07/2025 à 22h23
Modifié le 24/07/2025 à 09h48
Bref, s'il y a des efforts à faire, c'est d'abord de ce coté là, et personnellement cela fait des années que je bloque tous ces éléments, à la fois :
- par déontologie et respect de ma vie privée. Ce n'est pas parce que je n'ai rien à cacher que j'ai envie qu'on m'analyse comme une bête de foire
- par action citoyenne : tout ce qui sort de l'information utile d'une page, ce sont des octets qui transitent et sont traités par des machines. Ne pas avoir à traiter ce qui est inutile, c'est donc agir pour la nature car c'est limiter la consommation des machines sollicités (terminal, serveurs, switchs etc.)
- par économie personnelle : tout ce qui n'est pas traité sur MES machines, c'est de la batterie en moins de gaspillée pour les appareils mobiles, et autant de consommation électrique en moins.
En cela, cela fait donc des années que j'utilise des bloqueurs (mublock Origin et NoScript)... et désormais, c'est carrément un serveur DNS à la maison (installé sur ma domotique) qui vient compléter le travail pour tout ce qui n'est pas "navigateur". Bon, je pourrai me contenter de DNS4Euro, mais là, je peux bloquer très nettement davantage de choses : presque plus de pub, presque plus de tracking, sur TOUS les appareils.
EDIT : cependant, je rejoins les propos de Anaïs Sparesotto sur d'autres exemples qui me paraissent plus judicieux : le poids des applications (PC, smartphone). Désormais, un driver, ca peut peser plus lourd qu'un OS complet comme windows XP : est-ce raisonnable ? Ou bien, pour afficher une carte GPS, il faut une application qui pèse des centaines de Mo (je ne parle pas des datas en elles-mêmes) ??? Indirectement, c'est faire le jeu de l'obsolescence programmée, car on finit par saturer le stockage de certaines machines.
Le 24/07/2025 à 11h51
Ce qui est plus gênant ce sont les applications mobile qui ne sont que des antichambres de navigateur. Je ne vois pas l'intérêt. Egalement dans les applications mobile (Android), avoir une icone pour plusieurs résolution d'écran ne m'a jamais semblé crédible. T'en mets une grande et on "resize" à la volée.
Pour le reste, il est vrai que le marketing est un poids atrocement élevé dans le web. Il n'y a que la vidéo qui soit plus consommatrice de bande passante (brute, hors proxys).
Bon maintenant, il y a les vendeurs de data center qui ne sont pas d'accord avec la miss. Et ces datacenter sont des infrastructures du marketing... Bref on a beau discuter ce sera une fin de non recevoir in fine.
Ces fameuses bonnes pratiques ne se retrouvent pas dans nos services public français. On pourrait même dire que c'est l'inverse en ce moment. Va montrer l'exemple avec ça.
Le 31/07/2025 à 09h38
D'un côté on a une appli légèrement plus grosse (contenant une icône de chaque taille), dont le redimensionnement n'a été fait qu'une fois par le graphiste
De l'autre on a une une appli légèrement plus petite (ne contenant que la version grosse définition des icônes) pour laquelle le resize et fait à chaque affichage.
L'appli n'est installée (téléchargée) qu'environ une fois par utilisateur, par contre ses icônes seront affichées un nombre de fois incalculable pour chaque utilisateur: Je pense qu'il est plus rentable écologiquement de fournir une appli légèrement plus grosse (mais chargée une seule fois), qui contienne les icônes redimensionnées aux résolutions standards des périphériques, et qui n'aura pas besoin d'être redimensionner à chaque affichage.
En fait,la vrai raison est que les icônes ne sont pas qu'un resizing d'une même source: ça serait flou et illisible, elles sont en générale visuellement simplifiées par le graphiste pour rester lisible en basse résolution.
Le 31/07/2025 à 11h04
1 Il y a le stockage sur la ou Les plateformes de distribution (Google Play, Apple, etc.). Ca coute du serveur mais aussi du temps de service pour la publication. Qui aime la Play console??? (nan répondez pas, on sait).
2 les transferts qui correspondent non seulement à la première installation mais aussi aux mises à jour que tout le monde met en automatique (vu que c'est proposé d'amblé ou même préconfiguré suivant le constructeur / opérateur). donc il n'y a pas qu'un seul transfert mais plein.
3A Prendre soin de la lisibilité sur ces résolutions est clairement négligeable tant ce sont des résolutions parfois supérieures au moniteur de base (ca va jusqu'à 8k quand même). Même pour des téléphones à petit budget on aura du mal à trouver moins que HD/FHD (supérieur / égal 1080p). Un RedMi contemporain s'inscrit dans ce cadre. Après les gout et le couleurs...
Mais aussi du fait que bien souvent on ne fait pas plusieurs icones visuellement différents. Temps, coût… autant utiliser les solutions en ligne et hop c'est réglé. Une recherche google "online Android app icon generator" plus tard et on fait ça dans l'heure.
3B C'est seulement pour l'app launcher. Les reste des icônes dans une application mobile sont souvent la même image mais redimensionnée dans le document. Et pour ne pas avoir de flou on prend les plus grandes résolutions (raisonnablement ou pas). Seules les grosses boites se prennent la tête à faire du multi résolution quand elles en ont envie. Ce n'est pas forcément possible dans tous les cadriciels non plus. Il faut maintenir tout ça aussi.
La consommation énergétique d'un "resizing" d'icone est complètement négligeable tellement l'accélération matérielle fait cela comme l'éclair. En fait de ne rien faire gaspille l'énergie. Un chip consomme (comme celui un pc) plus de courant en charge mais ne rien faire avec l'écran allumé est autant d'énergie perdue. Il y a toujours un minima de consommation. Celui-ci permet d'embarquer ces quelques traitements sans surplus de consommation visible.
Le 24/07/2025 à 13h54
Sérieux, 512mo c'était la taille d'un CD-ROM. On y mettait Encarta dessus, une encyclopédie avec des images...
Le 24/07/2025 à 20h11
Le 14/11/2025 à 11h01
Le 25/07/2025 à 22h29
Le 14/11/2025 à 11h02
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?