Avant de parler de sobriété numérique, il faut décrire la place des systèmes informatiques dans leurs usages. Les premiers systèmes informatiques étaient de simples outils assistant l’utilisateur dans ces tâches. Les illustrations sont par exemple la calculatrice ou les systèmes experts. Se sont ensuite développés des systèmes pour automatiser des processus où l’utilisateur servait essentiellement à entrer ou à ressortir les données, à pallier au manque d’intégration du système entre ces différentes sous-parties ou avec l’extérieur, ou encore à complémenter ses fonctionnalités. Sont ensuite apparus des systèmes complets de gestion d’entreprise, comme SAP, dans lesquels l’utilisateur devient un simple servant de la machine qui lui indique les tâches à réaliser. Les systèmes sont donc passés de systèmes extrêmement locaux à des systèmes de processus et ensuite des systèmes d’entreprise, avec une intégration plus forte en interne et surtout avec l’extérieur, les clients et les fournisseurs.
Les éléments clés des systèmes sont sûrement :
- l‘interface homme-machine qui a évolué du mode terminal en ligne de commande à un menu qui permet de voir l’essentiel des commandes utilisables et de tableaux de bord qui permettent de comprendre l’état des processus ; cette interface est disponible pour l’utilisateur interne, puis pour le client ou le fournisseur en mode interactif ;
- l’interface machine-machine essentiellement en mode d’échanges de données, et l’interconnectivité entre les systèmes, d’abord locale, puis globale en grande partie grâce au réseau internet à partir des années 90 ;
- les capacités de calcul qui ont augmenté exponentiellement jusqu’à maintenant et qui semblent arriver en butée de la loi de Moore ;
- le stockage qui a connu une augmentation de capacité et de rapidité, et une baisse de prix spectaculaires.
La consommation énergétique et l’émission des gaz à effet de serre sont directement liées à la fabrication des équipements qu’il s’agisse des interfaces homme-machine, les capacités de calcul et de stockage, et évidemment à leur utilisation, c’est à dire à leur consommation énergétique, essentiellement électrique.
Au premier ordre, la consommation énergétique est liée au design et au code des applications, au volume de données, aux usages, et au niveau de résilience demandé ou exigé (disponibilité).
Design et code
Pour le design, c’est notamment le sujet des frameworks qui ajoutent une charge importante. Ainsi, l’interface graphique contribue à l’augmentation de charge.
Ainsi, pour mon article précédent, j’ai ajouté un graphique qui n’apporte rien au contenu mais qui engage à le lire. J’ai utilisé le framework d’édition de Linkedin (« Content Management System ») qui va alourdir significativement la page. Au total, pour un texte de 6 330 caractères utiles avec une image de 226 000 octets, Linkedin va envoyer une page de 3 940 000 d’octets, soit un ratio de 16.
Ensuite, pour un logiciel, le choix des bons algorithmes et un code optimisé ont aussi un impact significatif. Pour l’illustrer, la page Wikipedia sur les algorithmes de tri compare leur performance et indique que le nombre d’opérations peut être en nlog(n) ou n2. Cela signifie que pour trier un fichier de 100 données, cela peut être fait en 467 opérations élémentaires ou en 10 000, soit un ratio de 21 entre deux méthodes standards.
Le choix d’un framework gourmand et un code peu optimisé peuvent facilement multiplier par 10 le nombre de calculs et le nombre d’accès au stockage.
Données
La détermination des données utiles, des données importantes, des données chaudes ou froides, a un poids dans la consommation énergétique. L’abondance du stockage et son prix bas ont fait basculer toutes les données en données utiles à chaud.
Les procédures d’archivage des données hors lignes sont cruciales pour minimiser le volume de données chaudes et réduire la consommation énergétique. Ici encore, le maintien en ligne ou la sauvegarde de données redondantes ou superflues peut multiplier les volumes par 10.
Usages
La mutualisation des infrastructures a vraiment un sens pour les applications à usage intermittent, comme jour ou nuit, jour ouvrable (lundi-vendredi) ou fin de semaine (samedi-dimanche), ou à usage diffus (le volume n’est pas suffisant pour occuper complètement une machine)
En dehors de ces mutualisations claires, le recours à la mutualisation des infrastructures a plutôt pour objectif de simplifier la gestion des machines et éventuellement des frameworks.
Disponibilité
L’exigence d’un niveau disponibilité trop élevé risque d’entraîner des surconsommations importantes.
Par exemple, s’il est décidé de classer en disponibilité temps réel un système qui n’a besoin qu’une disponibilité mensuelle, une base de données comptable qui a une taille de 100 unités et un flux de transaction de 1 unité par jour, Il va falloir répliquer en temps réel sur 2 sites distincts l’ensemble des informations entre ces 2 sites, prendre une copie intégrale de la base et de l’historique des transactions tous les jours sur au moins une semaine glissante. Il y a donc 200 de données vives, un trafic additionnel d’au moins 1 entre les deux bases répliquées, et 707 de données sauvegardées. Si le système n’a qu’une disponibilité mensuelle, il suffit d’une sauvegarde par mois et de l’ensemble et de l’historique des transactions du dernier mois, soit 100 de données vives et 130 de données sauvegardées. Cela signifie un rapport de 2 sur les données vives et 5 sur les données sauvegardées.
Conclusion
En résumé, la conception (design, code, données, archivage) des systèmes et le niveau de disponibilité il peut facilement y avoir un facteur 500 en consommation entre un système optimisé et un système non optimisé.
De plus, cette mauvaise conception et cette sur-disponibilité vont augmenter d’autant le nombre de machines nécessaires au fonctionnement du système et donc augmenter la production de gaz à effet de serre pour leur fabrication, accaparer des ressources rares et créer des pollutions liées à leur extraction.
A titre individuel, revenir à des usages raisonnables
Au niveau individuel, la vidéo à la demande (Netflix, Youtube, Youporn et alia) utilise aujourd’hui plus de la moitié de la bande passante des réseaux internet. Comme le dit J-Marc Jancovici: « avez-vous besoin de regarder Netflix dans le métro en 5G ? ». Le retour à la télédiffusion hertzienne par exemple en taxant ou en limitant la vidéo à la demande permettrait de diviser par deux l’impact en gaz à effet de serre et en ressources rares d’internet.
De la même façon, les systèmes inutiles, les gadgets, sont un producteur de gaz à effet de serre et consommateur de ressources rares. Comme le dit Aurore Stéphant, « avez-vous besoin d’un système qui vous indique le nombre de bières dans le frigo ? Il suffit d’ouvrir la porte ».
Le nouveau smartphone propose un appareil photographique avec une meilleure résolution, donc des fichiers encore plus gros, grâce à ses trois objectifs et son lidar, donc autant de matériaux rares supplémentaires. A moins d’être un architecte qui l’utilise pour faire des relevés de bâtiment, il est difficile de justifier un tel achat qui relève uniquement d’un luxe ostentatoire.
Les régulateurs vont (devoir) mettre en place des limitations, en agissant sur les deux composantes : prix et volume.
Le premier archétype grand public va être l’arrêt de la commercialisation des voitures et camionnettes à moteur à essence ou diesel à partir de 2035. C’est une bonne illustration l’utilisation de la composante volume.
Et demain
Une partie de l’adaptation à la transition (énergétique, climat, sociétale) va consister à anticiper les règlementations en considérant que la règlementation des entreprises est, en général, plus radicale et plus rapide que la règlementation pour le grand public.
Pour réaliser cette anticipation, il faut commencer conduire une analyse extrêmement détaillée des dépendances de l’entreprise.