Discussion :

[pprem]

Hello

Encore vu passer sur LinkedIn un post sur un comparatif écologique entre applications compilées (Delphi ou autres, peu importe, ce n'est pas réellement le sujet) et applications web : https://www.linkedin.com/feed/update...86178681319424

Il était illustré avec cette étiquette écolabel que l'on trouve dans les magasins (et que certains aimeraient bien diffuser dans nos métiers après le débile calcul de CO2 de l'accès Internet) :


C'est une approche intéressante mais ça m'agace et j'aimerais avoir vos avis sur le sujet, votre ressenti sur votre impact sur l'environnement lorsque vous choisissez une techno et si vous vous posez la question.

Pour moi le vrai problème n'est pas de rappeler que le moindre site Internet ou application web est un désastre environnemental, c'est aussi de savoir pourquoi on repart sur des sites Internet au lieu de faire du client serveur. S'arrêter au coût environnemental des applications web c'est oublier le coût matériel et humain de la maintenance de "vrais" logiciels.

Application web, client serveur "database" ou client serveur "logiciel" (API), il faut un réseau et des sécurités sur ce réseau. Donc pas de différence entre les trois. Internet ou réseaux local sont utilisés partout.
Il faut aussi des serveurs (pas forcément dimensionnés de la même façon). Dire qu'un serveur est plus important qu'un serveur d'application client/serveur n'a aucun sens. Ca dépend beaucoup de l'application.
Il faut des ordinateurs chez les utilisateurs (pas forcément puissants).

Sur le web les données transitent plus ou moins en format texte (JSON/XML, généralement compressé de façon transparente par le serveur si le navigateur l'y autorise) alors que sur un logiciel client / serveur les mêmes données peuvent être transférées directement en formats binaires (éventuellement compressées si serveur et client ont été codés pour).
Dans les deux cas on peut (= doit) avoir des traitements effectués côté serveur afin de ne récupérer que les données utiles.

Les deux vraies différences se font au niveau de la consommation de bande passante et du travail sur le poste client :
=> faire transiter les codes sources des programmes/pages web (plus ou moins) à chaque fois qu'on y accède contre avoir transféré le programme exécutable une fois et envoyer ses mises à jours quand c'est nécessaire
=> les ressources nécessaires à l'exécution des navigateurs web à opposer à celles nécessaires à faire tourner un programme qui ne fait que ce qui a été prévu dedans et peut être optimisé pour le faire correctement

Je suis plutôt dans le camp de ceux qui font des logiciels compilés parce que j'ai les outils pour ça et que je n'ai pas trouvé d'équivalent permettant de faire des application web de façon confortable (et franchement, faire du web "front", ça me saoule) mais je peux comprendre que certains trouvent le web plus facile et plus pratique. Après tout n'avoir que le serveur à maintenir pour que tous les utilisateurs soient à jour et puissent utiliser une application depuis n'importe quel poste partout sur la planète, c'est quand même plus sympa que leur imposer d'installer un programme, sur un OS précis et ne pouvoir l'utiliser que sur des ordinateurs à eux.

Alors oui, écologiquement les applications en ligne sont une vraie saloperie (et je ne parle même pas des applications mobiles qui utilisent des moteurs d'affichage web), mais faudrait peut-être s'attaquer à la vraie raison de ça : les navigateurs qui bouffent des ressources de façon aberrante pour afficher la moindre page ou exécuter du JavaScript !

Il faut aussi en comprendre raisons qui expliquent que les navigateurs sont de telles calamités : pour afficher des pages ils doivent interpréter du texte qui peut prendre tout un tas de formes et être très complexe (notamment avec les CSS ou des fichiers sources écrits n'importe comment, parfois syntaxiquement délirants).

Dire "arrêtez de faire des trucs en web, faites des programmes compilés pour sauver la planète" est trop simpliste (même si c'est vrai) par contre on devrait tous être conscients qu'en choisissant la facilité de déploiement et de maintenance en faisant du web, on choisit aussi la moins bonne solution en terme de consommation énergétique.

Reste à voir si ce sujet fait partie des programmes scolaires en écoles spécialisées et si les intervenants dans des formations de développement (quelle que soit la techno) abordent le sujet. Et d'ailleurs est-ce un vrai sujet ?

[electroremy]

Bonjour,

Je suis entièrement d'accord avec cette réflexion

C'est bien connu : on a du matériel de plus en plus performant mais des logiciels de plus en plus gloutons. Conséquence :
- aucun gain ou un gain de performance sans rapport avec le nouveau matériel
- les anciens matériels deviennent inutilisables

Je garde précieusement certains "vieux logiciels" ; c'est comme pour les outils "mécaniques" ou électroniques quand c'est bien conçu, pas besoin d'en changer.

Je peste contre les langages trop gourmands ou, plus sournoisement, les nouvelles bibliothèques de plus en plus obèses...
Même un "bon" langage comme le C++ permet de faire des logiciels lents et obèses.

On peut le constater très clairement dans le domaine de l'embarqué.
J'ai démarré un projet il y a 2 ou 3 ans avec Arduino Uno. C'est un classique... mais déjà "dépassé"
En effet, les nouveaux équipements embarqués ont beaucoup plus de RAM, de ROM, de vitesse de CPU... mais il y a des inconvénients aussi.

Mon projet était "perdu d'avance", car ce que je voulais faire ne tiendrais pas dans les 32ko de flash de l'Arduino, et ses 2Ko de RAM étaient trop justes, sans parler de la vitesse.
J'ai tracé ma route petit à petit, et surtout, j'ai optimisé le code.
J'ai réécrit et optimisé les bibliothèques.
J'ai réussi à avoir quelque chose qui soit à la fois plus compact, plus rapide, et même avec plus de fonctionnalités !

Certes, le revers de la médaille, c'est que mon code est optimisé pour l'Arduino UNO et pour les périphériques que j'ai choisi.
Par rapport aux bibliothèques d'origine, il faudra faire un travail d'adaption non négligeable pour utiliser mon code avec un autre matériel.
Mais la performance est à ce prix.
Et la portabilité à tout prix a bon dos... certaines bibliothèques étaient clairement inutilement trop grosses
Un exemple concret : j'ai un capteur d'hygrométrie dont la précision est de 3%
La bibliothèque d'origine lit la valeur sur 20 bits (ce que l'interface du capteur délivre) puis fait des calculs en virgule flottante pour obtenir le résultat de 0 à 100.
C'est très gourmand en ressources pour un microcontrôleur 8 bits... et totalement inutile étant donné la précision du capteur !
Ma version ne prends que l'octet de poids fort et fait un calcul n'utilisant que des opérations sur des entiers pour avoir un résultat de 0 à 100.

Mon projet sera bientôt publié en open source, j'espère qu'il permettra de réutiliser les Arduinos UNO qui dorment dans les tiroirs, ça sera mieux que l'achat des cartes derniers cri.

Dans le monde de l'informatique de bureau et grand public, c'est pareil.
J'ai débuté avec un Amiga 1200, le système d'exploitation avec interface graphique pouvait tenir sur une disquette basse densité (~800ko sur un Amiga).
Les programmeurs de logiciels et de jeux vidéos de cette époque faisaient des merveilles avec cette machine... et encore, beaucoup de programmes étaient écris pour l'Amiga 500 nettement moins puissant.
Ils savaient programmer et optimiser... en fait, étant donné les ressources matérielles limités, ils n'avaient pas le choix.

C'est preserver avec mes Arduino UNO - plutôt que de céder à la tentation d'acheter une carte plus puissante - qui m'a permis de m'améliorer en programmation embarquée et d'optimiser mon code jusqu'au bout.

Aujourd'hui sur PC beaucoup de logiciels sont lents, car on a pas donné le temps aux programmeurs d'approfondir leur code, et la puissance des ordinateurs actuels ainsi que les débits des réseaux "ne justifient plus" qu'on perde du temps à optimiser un code.
J'ai créé un logiciel de CAO/FAO en VB.NET, avec une partie assez lourde en matière de calculs, de traitement d'image 2D et 3D.
Si on utilise les fonctions de base de VB.NET, on code rapidement mais c'est lent. Le VB.NET permet de faire du code rapide, car c'est avant tout du .NET
J'ai creusé, optimisé, le résultat est là.
Quand je compare les fonctions de mon programme à celles d'autres logiciels qui font la même chose, c'est aussi bien et parfois plus rapide.
Et mon programme reste léger : les binaires et DLL ne pèsent que quelque Mo (mais bien sûr il faut le framework .NET)

Dans ma vie professionnelle, je n'en finit pas de pester contre la lourdeur et la lenteur des logiciels du commerce, ou pire, des logiciels "maison" utilisé par mon employeur
Genre des logiciels de saisie de texte, associés à une base de donnée, qui patinent parfois trente secondes pour afficher une page de texte... et même en local...
Ca plante régulièrement, plusieurs fois par mois il faut appeler au secours le help desk... tout ça pour un logiciel qui n'est qu'une machine à écrire améliorée...
C'est fait en JAVA, ça tourne dans un onglet de Chrome...

A bientôt