L’inefficience logicielle ou pourquoi votre ordinateur/téléphone est de plus en plus lent
Nos appareils, ordinateurs ou téléphones, ont aujourd’hui des puissances démentielles. L’ordinateur de la mission Apollo 11, qui a permis à l’Homme de poser le pied sur la lune, était doté d’un processeur tournant à une cadence de 1Mhz, appairé à une mémoire RAM de 4ko (et d’une ROM, faisant office de disque dur pour simplifier) de 70ko.
Aujourd’hui, un smartphone d’entrée de gamme tel que le Logicom Hello (prix en dessous de la centaine d’euros) intègre un processeur de 3GHz à 4 cœurs, une RAM de 1Go et un espace de stockage interne (qu’on pourrait rapprocher de la ROM, pour la comparaison) de 8Go.
En comparant ces deux appareils, on peut en déduire que n’importe quel téléphone du marché actuel dispose a minima d’une puissance de calcul 12000 fois supérieure à celle embarquée par la mission Apollo, un espace de mémoire de travail 250000 fois plus grand, et un espace de stockage de 100000 fois plus important. En se disant que l’ordinateur d’Apollo a réussi l’exploit de réaliser un trajet Terre-Lune, une puissance aussi démentielle que notre téléphone devrait au moins pouvoir résoudre le problème du voyage supraluminique en quelques secondes, non ? Et pourtant, quand je charge une page web lambda…
Attendez, quoi ? Comment est-il possible qu’une machine des milliers de fois plus puissantes soit des milliers de fois moins performante ? Est-ce qu’on nous aurait menti, est-ce qu’on produirait des appareils de moins en moins puissants avec le temps ? Que s’est-il passé entre 1969 et 2020 pour en arriver là ?
On pourrait être tenté de penser qu’il s’agit d’un complot des constructeurs qui ralentissent les appareils à mesure qu’ils vieillissent, à l’instar des téléphones d’Apple. Même si la justice a tranché en faveur de cette idée, c’est loin d’être le seul paramètre à prendre en compte. Quand j’ouvre mon navigateur, visite mon site web favori et constate qu’il met bien dix secondes à charger, le téléphone n’y est pas pour grand chose. Le problème réside dans l’application web elle-même.
L’Homme vs la Machine
Le numérique est omniprésent. Pour n’importe quelle tâche, il est possible de trouver une myriade d’applications qui peuvent y répondre plus ou moins bien. Tous nos services publics se numérisent; l’assurance maladie, la direction des impôts… Commander un menu se fait via une application web. Faire du running s’accompagne souvent d’un coach numérique. On diffuse de la musique dans notre voiture via une application de streaming. On recherche de l’information sur une célèbre encyclopédie en ligne. Le numérique est partout, et on imagine mal notre civilisation s’en passer aujourdhui.
L’omniprésence du numérique implique qu’il a fallu des équipes de développement pour mener à bien leur réalisation. Des développeurs qui écrivent des applications comme un écrivain écrit un roman. Le principe est le même. Au vu du nombre d’applications qui existent, les développeurs sont nombreux.
A l’aube du numérique, à l’époque où seules les banques et quelques entreprises étaient dotées d’un service informatique, les applications tournaient sur des mainframes, de grosses machines responsables d’héberger les données et d’automatiser les traitements. Les développeurs réalisaient des programmes sur ces machines. Elles coûtaient extrêmement cher, avec des performances très limitées. Les développeurs ne représentaient qu’une petite fraction de la facture finale.
Depuis, le cloud s’est démocratisé. N’importe qui peut déployer une application dans le cloud pour quelques euros par mois à peine en quelques minutes. La tendance s’est inversée. Ce n’est plus la machine qui coûte. C’est le temps de cerveau des développeurs. Cette inversion de perspective a des conséquences néfastes.
Puisque la majeure partie du coût provient de la durée de développement (de réalisation) d’une application et non plus à son fonctionnement, c’est le premier levier actionné par une entreprise. Sur le plan purement financier, pourquoi une entreprise demanderait à un développeur d’optimiser une application qui vient d’être écrite, alors qu’il suffit de déployer plus de machine dans le cloud pour la faire tourner pour une fraction négligeable du prix ? Quel directeur financier irait payer des journées de développements pour gagner secondes de temps d’exécution d’une application, alors que multiplier les serveurs coûtera des centaines de fois moins cher ?
La démarche, au final, revient généralement à devoir recourir le moins possible à l’expertise d’un développeur pour produire une application mieux finie, et à compenser la sous-optimalité des applications par une puissance de calcul supérieure, et donc plus de machines.
Cette approche se fait en revanche au détriment de l’utilisateur. Si la société qui propose l’application peut multiplier les machines pour compenser la voracité de son application, elle n’a en revanche que peu de levier pour agir sur les appareils de ses utilisateurs. Les serveurs de son application, toujours plus nombreux, tiennent le choc, mais pas les téléphones et les ordinateurs les plus modestes et les plus anciens de ses clients. C’est ainsi qu’on arrive toujours un jour à se dire : “Mais pourquoi mon téléphone rame comme ça ? Il doit être trop vieux, je vais le changer”. Pourtant, l’appareil n’a en général pas pris une ride au niveau matériel. Il est toujours capable d’accomplir la même quantité de travail. On lui en donne simplement de plus en plus, sans raison valable derrière.
Plus, toujours plus !
Quand j’ouvre une application, je suis perdu. Des boutons, des menus, des icônes, du texte, partout ! Je veux juste faire une chose simple, et je suis incapable de la trouver. Pourtant, je sais que cette application est faite pour ça. Alors pourquoi je dois aller le chercher dans le menu d’un sous-menu caché dans un onglet ?
Je m’imagine parfois rentrer dans ma voiture. A la place arrière, à droite, j’ai un frigo. A gauche, un fer à repasser. Au milieu, une cafetière. Sur le tableau de bord, la météo, la date, mon horoscope, les gros titres du jour, un évier. Sur la place du passager, des toilettes, avec une chasse d’eau qui fonctionne ! Dans le coffre, j’ai une machine à pop-corn et une autre pour les glaces à l’italienne. Je sors la clé pour démarrer la voiture, mais impossible de trouver le contact. Même pas à côté du manche à balai qui remplace le volant. Ah, si, derrière le frigo…
Ce que je décris ici, c’est le syndrome de l’obésiciel. Une application dans laquelle il est possible de faire tellement de choses qu’il devient impossible de comprendre à quoi elle sert vraiment. C’est comme si des fonctionnalités avaient été bourrées avec le pied pour la remplir le plus possible, comme si toutes le nombre de fonctionnalités était un critère de qualité de l’application ou une justification de son prix. Parmi ces fonctionnalités, la moitié ne servira qu’à une minorité d’utilisateurs avertis, et un quart de celles qui restent seront tellement cachées que personne ne saura qu’elles existent. Pour la plupart des utilisateurs, seules quelques-unes d’entre seront réellement utilisées. Et pourtant, toutes les autres viennent alourdir l’application, et donc la ralentir et lui faire consommer davantage de puissance de calcul.
C’est ainsi qu’en comparant la quantité de mémoire nécessaire pour faire fonctionner Microsoft Word (Et ce n’est pas pour cracher sur Microsoft, c’est simplement que l’application a le bon goût d’avoir eu une vie longue et profitable) a été multipliée par 100 entre la mouture de 1997 et celle de 2010. Et pourtant, tape-t-on des textes 100 fois plus vite qu’à l’époque ? Pas si sûr.
Et si on revenait vers des applications simples ? Des applications qui se concentrent sur une seule fonctionnalité, mais qui la font bien ? Un utilisateur souhaite généralement faire une seule chose sur une application, et il doit trop souvent se battre pour trouver la fonctionnalité qui va bien, et attendre que sa machine ait arrêté de ramer.
Et pourtant, rappelez-vous de ce petit Google, réalisé seulement par ses deux fondateurs. Dès 1998, avec sa simple barre de recherche en plein milieu de l’écran, Google a fichu une raclée si retentissante à tous les autres moteurs de recherche basés sur des portails illisibles que presque aucun ne s’en est relevé. Des fils d’actualité, des boutons, des menus, des images, du merdier, partout. Un vrai bordel à l’écran. Et le principal, la barre de recherche, perdue au milieu de toutes ces fonctionnalités inutiles et plombant la vitesse des sites.
Est-ce qu’on a vraiment besoin de toujours plus, quand on a l’essentiel ?
Un manque de maturité
D’après cette étude de Stackoverflow (un site d’entraide incontournable dans le milieu du développement) sur un panel de 87000 développeurs, un tiers des développeurs a moins de 5 ans d’expérience, un autre tiers entre 5 et 10 ans, et le dernier tiers plus de dix ans d’expérience.
En rapprochant ces résultats d’une courbe démographique, on constate un profil qui se rapproche de celle d’un pays en développement :
Dans une industrie majoritairement jeune, on a de l’énergie à revendre. Des idées qui fusent, des projets qui sortent de terre à toute allure, de l’innovation.
Et des erreurs du passé qui se répètent. Et comment pourrait-on en vouloir à une équipe de développeurs inexpérimentés de reproduire les erreurs célèbres du passé ? Or, le monde du développement est cyclique. On remarque assez facilement, avec du recul, que des idées très répandues à une époque finissent par tomber dans l’oubli pour émerger à nouveau quelques années plus tard dans une version légèrement améliorée. Un jeune développeur ne peut que penser avec les idées de son temps, sans imaginer qu’une idée du passé pourrait être bien plus adaptée dans son cas.
Cette tendance à la disparition des anciens est assez flagrante quand on regarde la nomenclature des métiers chez le développeur. De 0 à 3 ans d’expérience, il est junior. De 3 à 7 ans, il devient confirmé. Après 7 ans, il est senior. C’est le dernier stade de son évolution. Du haut de ses 7 ans, on le considère comme le sage, l’expert, celui qui sait. C’est un peu étrange, quand on sait que le stade de senior, dans les autres métiers de l’ingénierie (aviation, automobile, électronique, génie civile…) correspond à 20 ou 30 ans d’expérience. Évidemment, quand on considère qu’au bout de dix ans d’expérience, il n’en reste qu’un sur trois, on comprend mieux cette nomenclature. Tout comme il est rare de trouver des personnes très âgées dans un pays en développement.
Ce manque de maturité se traduit dans les méthodes de recrutement. Quand une fiche de poste est émise, on s’intéresse bien moins au savoir-faire d’un candidat qu’aux outils qu’il maîtrise. Imaginez donc une fiche de poste dans le bâtiment dans laquelle on recherche un candidat qui maîtrise bien la perceuse Black & Decker ou un autre qui est passé maître dans le maniement de la scie Bosch ? Et pourtant, cette situation caricaturale n’est pas si éloignée que ça de la réalité du monde du développement.
Cette tendance a des conséquences néfastes. Quand on a un marteau, tout ressemble à un clou. Un développeur, recruté pour sa maîtrise d’un outil, aura tendance à vouloir résoudre tous les problèmes avec cet outil, qu’il soit adapté ou non. Comment lui en vouloir ? Après tout, il n’a pas eu l’occasion d’expérimenter autre chose, de prendre du recul, de faire des erreurs et d’apprendre à ne plus les refaire.
Si tout ressemble à un clou quand on a un marteau, tout ressemble à un trou quand on a un tractopelle. Les outils numérique ont tendance à devenir de plus en plus riches et polyvalents, mais aussi en contrepartie de plus en plus voraces en puissance de calcul. Est-ce que j’ai besoin d’un tractopelle quand je veux creuser un trou pour planter un begonia ? Pas vraiment, et il faudra de gros efforts énergétiques pour parvenir au résultat qu’une pelle aurait pu résoudre à moindre frais. Or, la tendance actuelle est de sortir le tractopelle en toute circonstance, parce qu’il sait tout faire. Cela reviendrait exactement au même que se dire : un billet de 200€ suffit à acheter à peu près n’importe quoi, alors autant tout payer avec (sans récupérer sa monnaie). Pas très malin.
Récapitulons
Le monde du numérique souffre de nombreux travers, dont il serait bien trop long de décrire toutes les causes et mécaniques en un seul article. Mettons plutôt en évidence les dérives que tout ceci engendre.
- une surconsommation d’énergie et de matériel par rapport à ce que ça pourrait être avec une technique raisonnée (oui, une voiture consommant 100L/100km avance, mais est-ce qu’on ne pourrait pas faire un peu mieux ?). Dans un contexte où 75% de l’énergie mondiale provient de sources fossiles avec les conséquences qu’on leur connaît, il est inutile d’en dire plus.
- des inégalités sociales dans l’accès au numérique : si une application est gourmande au point de ne plus être accessible aux utilisateurs équipés modestement, alors ils seront mis sur le banc de touche et exclus de la sphère du numérique (sans parler de l’obsolescence logicielle qui n’est, par ailleurs, qu’un effet de bord superbement ignoré par beaucoup de sociétés).
- renouvellement exagéré des matériels encore en état de marche : rares sont ceux qui ont résisté à l’appel d’un nouvel appareil quand l’ancien commençait à donner la sensation de ramer. Pourtant, si nos applications étaient mieux conçues, mieux réalisées, il ne serait pas difficile de conserver nos appareils jusqu’à leur mort naturelle, voire même à les réparer pour leur donner une seconde vie (bien que le débat de la réparabilité des appareils soit bien présent, mais c’est une autre histoire). En conséquence, une surconsommation de matériaux et d’énergie qui nous rapproche trop rapidement de leurs pics de production, au-delà duquel le confort et mode de vie de chacun sera remis en question.
- expérience utilisateur déplorable : selon Google, le temps de chargement d’une page web est de 22 secondes en moyenne. Plus les années passent, et plus la sensation des utilisateurs est de faire face à des applications de plus en plus lentes avec pourtant en main des appareils à la puissance démesurée. Comment leur en vouloir pour leur résistance aux mises à jour applicatives, et même de leur méfiance vis-à-vis du numérique en général (“l’informatique, ça ne marche pas bien”) ?
Les solutions
Est-ce que le numérique est foutu ? Est-ce qu’il faut tout balancer à la poubelle et refermer le couvercle pour toujours ? (Au passage, je recommande de ne pas laisser une poubelle fermée aussi longtemps, le résultat pourrait être légèrement désagréable. Mais je m’égare.)
Les solutions sont pourtant juste sous notre nez. Il n’y a qu’à se pencher pour les ramasser.
Avant toute chose, il est nécessaire de lutter contre cette tendance destructrice du jeunisme dans le développement. Attention, je ne dis pas qu’il ne faut pas de débutants dans le domaine, mais simplement une proportion équilibrée avec les autres types de profil, de façon à ce que la connaissance des anciens se transmettent aux générations suivantes, et que les erreurs bêtes et coûteuses soient évitées pour enfin parvenir à une maturité du numérique. Qui plus est, un profil expérimenté maitrisera d’une part mieux la technique, mais sera également pertinent sur toute une série de connaissances et compétences connexes à son coeur de métier. Son coût horaire unitaire sera supérieure, mais sera généralement très largement compensé par la valeur qu’il apporte.
La disparition des développeurs expérimentés est hélas la conséquence du modèle hiérarchique pyramidal à la française. Le développeur est généralement vu comme l’ouvrier qui, pour évoluer dans la grille de salaire, doit devenir “chef” (je mets bien ici une paire de guillemets très gras), puis chef de chef, et ainsi monter dans la hiérarchie. La reconnaissance sociale et professionnelles est bien évidemment à l’allant. Pourtant, le modèle anglo-saxon est très différent, et même encore plus marqué outre-atlantique où les développeurs compétents sont des stars souvent mieux rémunérées que leurs managers. Le mode de pensée est à l’inverse du modèle français, puisque le savoir-faire est récompensé (et la valeur directement produite) bien plus que l’échelon hiérarchique. Pas étonnant que de nombreux développeurs français partent à l’étranger, en doublant leur salaire sans trop de difficulté.
Second point, le mode de pensée du “toujours plus” est à proscrire. Une application devrait se focaliser sur un atout et un seul. Savoir rester simple et efficient. Le moteur de recherche Google sert à rechercher. Pas à faire le café et laver le linge. Juste rechercher. Et rechercher avec une efficacité et une vitesse redoutables. les meneurs de projet ont hélas bien souvent tendance à se laisser entraîner dans leur élan. D’un autre côté, je reconnais qu’il n’est pas évident de dire stop. Si je m’arrête dans l’évolution d’une application, cela revient à déclarer haut et fort que je ne suis plus utile et qu’il faut se séparer de moi. Et pourtant, c’est la meilleure décision du point de vue de l’utilisateur, mais aussi de celui du financier derrière l’application. Continuer d’injecter de l’argent dans une application pour des fonctionnalités inutiles et qui dégradent de surcroît la qualité de l’application ? Qui ferait ça ?
Dernière chose, et pas des moindre : savoir revenir à la low-tech. Si je n’ai pas besoin d’un tractopelle pour creuser un trou pour mon bégonia, je n’ai pas non plus besoin d’une tronçonneuse pour couper une brindille. Même si une bêche ou un sécateur sont moins sexy pour celui qui les manie, ce sont pourtant des solutions bien plus rationnelles à tous les points de vue. Ils coûteront moins cher à l’achat et au fonctionnement, demanderont beaucoup moins de maîtrise et d’apprentissage, et parviendront même généralement plus vite au résultat. Pour ce qui est de la transposition aux outils du numérique, un outil plus simple sera plus rapide, moins gourmand en énergie (et en matériaux qui constituent les machines) et bien plus agréable pour l’utilisateur.
Et si on réapprenait le plaisir d’avoir une page web en moins d’une seconde ?
