Nous le savons, le numérique n'a rien de virtuel même avec le web. En bout de chaîne, on trouve des terminaux utilisateurs, des serveurs web. Tout ce matériel a besoin de très nombreuses ressources minières. Sa fabrication demande beaucoup d'énergie, génère beaucoup de CO2. Son utilisation nécessite aussi de l'énergie même si c'est "presque" secondaire. En effet, l'équivalent CO2 de la fabrication d'un ordinateur portable est largement supérieure au CO2 généré pendant tout da durée de vie pour l'alimenter d'après les informations que j'ai pu trouver. Ceci dit, ce n'est pas une raison pour l'ignorer. Toutes les optimisations sont bonnes à prendre.
Je veux parler ici d'optimisation liée au web puisque c'est mon domaine d'activité mais les applications bureau et mobiles sont bien entendues concernées.
Mon travail consiste principalement à du développement web côté serveur.
On entend souvent parler des optimisations côté "front" (CSS, images, limitation des "tracker", utilisation intelligente de javascript, etc).
Je trouve qu'on ne parle pas assez du côté "back". Je ne dis pas que personne en parle mais pas assez à mon goût. C'est pourtant là que se passe la plupart des traitements d'une application web.
Une page html optimisée mais générée par une application serveur très gourmande ne peut pas être considérée comme écoconçue. Les géants du web ont besoin de tellement de ressources qu'ils font ce travail d'optimisation côté "back". C'est indispensable pour eux. En revanche pour les plus petits, j'ai l'impression que ce n'est pas toujours une priorité. Le prix d'une machine supplémentaire n'est pas forcément très important et il est parfois plus simple d'ajouter une machine (surtout dans le cloud où tout est extensible) plutôt que de chercher l'optimisation. C'est bien dommage.
En effet, si on cumule toutes les pertes engendrées mondialement, l'économie à faire est probablement énorme en terme d'énergie et surtout en serveurs. Ce sont des machines bien physiques qu'il faut construire. J'ai moi même ignoré ça pendant longtemps sans m'en ŕendre compte. Si le coût des ressources prenait en compte les dommages écologiques, on réfléchirait probablement différemment (et pour tous les domaines d'ailleurs).
Pour commencer à optimiser, je pense que le plus efficace est de répérer le code qui est exécuté le plus souvent. En effet, améliorer les performances d'un code gourmand mais appelé très rarement (je ne dis pas qu'il ne faut pas le faire) aura un impact bien moins important. Ensuite, il faut étudier précisément ce code et remarquer les portions gourmandes comme les nombreux échanges avec une base de données par exemple (c'est souvent là qu'on peut faire de grosses optimisations). Que pourrait-on faire ? Revoir les index ? Optimiser les requêtes SQL ? Est-ce possible si un ORM spécifique du marché est utilisé ? Faut-il gérer la requête manuellement ? Cette requête est-elle souvent identique et retourne-t-elle toujours les mêmes résultats (dans ce cas un cache serait efficace en mémoire par exemple) ?
Non seulement ces optimisations seront intéressantes pour vous car vos outils s'exécuteront plus rapidement en limitant l'ajout de ressources en cas de montée en charge et vous participerez à l'effort collectif pour l'environnement. Collectivement, on peut faire la différence.
Quand je regarde une partie du travail que j'ai écrit, je me rends compte aujourd'hui que je ne ferais pas du tout les mêmes choix quitte à limiter la souplesse de certains outils. Il faut trouver le bon dosage et savoir parfois renoncer à certaines fonctionnalités si un équivalent un peu mois souple offre une économie de ressource significative. Lorsque le développement est à réaliser pour un client, un employeur, c'est plus compliqué. Il faut essayer de convaincre. C'est aussi notre rôle.