Interview Tristan Nitot, découvrez la loi d'erooM
Rédigé le 20/06/2024 par Youen Chéné
Bonjour Tristan, on va combler les impatients, mais c’est quoi donc cette loi de erooM ?
C’est une nouvelle approche du numérique qui permet trois choses qu’on pensait incompatibles : diviser l’empreinte environnementale du numérique tout en permettant la création de nouveaux usages. J’ai appelé cela « erooM » parce que c’est comme la loi de Moore, mais à l’envers ! Mais pour que tu puisses comprendre, il faudrait que je t’explique la loi de Moore et la loi de Wirth.
On va y venir, mais pour ceux qui ne te connaissent pas, c’est quoi l’histoire et l’œuvre de Tristan Nitot ?
Oulah ! C’est l’histoire d’un gamin qui a eu la chance de se faire prêter un ordinateur alors qu’il était tout jeune, et donc d’apprendre à programmer à 13/14 ans, et qui a eu envie de faire carrière dans ce métier. J’ai travaillé chez Netscape, j’ai eu la chance d’être impliqué dans le projet Mozilla dès ses débuts, j’ai co-fondé Mozilla Europe que j’ai longtemps présidé. Donc j’ai lancé Firefox en Europe avec plein de bénévoles. Après, j’ai continué dans le logiciel libre, la protection des données personnelles et les moteurs de recherche. Et puis depuis un an, je suis chez OCTO Technology, où je m’occupe de deux sujets, les communs numériques (open source, open data contenus ouverts) et l’anthropocène. C’est à dire qu’avec mes collègues, on aide nos clients à faire que leurs entreprises ne dépassent pas les limites planétaires, qui « restent dans le donut », pour ceux qui connaissant les travaux de Kate Raworth.
Revenons au sujet, quelle est l’origine de la loi de Moore ? Quel impact cela a eu sur le développement logiciel ?
Ça part de la loi de Moore, nommée d’après Gordon Moore, co-fondateur d’Intel, qui a observé dès 1965 qu’il était possible, si on s’en donnait les moyens, de doubler le nombre de transistors dans les semi-conducteurs tous les 24 mois. Ces semi-conducteurs, ce sont les « puces informatiques » (processeurs, mémoire) qui sont le cœur de nos ordinateurs, de nos smartphones, et à peu près tout ce qui est électronique. On l’a résumé en « la puissance des ordinateurs double tous les deux ans ». En faisant de la R&D, en créant de nouvelles usines régulièrement avec les résultats de cette R&D, ça a permis la révolution numérique qu’on vit en ce moment depuis les années 1970.
Peux-tu nous en dire plus sur la loi de Wirth ?
C’est une autre loi, qui décrit un aspect moins glorieux et moins connu de la loi de Moore. Elle a été édictée par Niklaus Wirth (inventeur du langage Pascal, détenteur du prestigieux prix Türing) et aussi valable que la loi de Moore. Elle dit « le logiciel ralentit aussi vite que le matériel accélère ». À une époque, on disait « ce qu’Intel vous donne, Microsoft vous le reprend ». Et c’est vrai, on a pu le vérifier au fil du temps. C’est l’effet rebond du numérique. Par exemple, pour faire tourner Office sur Windows en 1998, il fallait un 486 à 66 MHz et 16 Mo de mémoire. 20 ans plus tard, il faut 171 fois plus de mémoire et un processeur 750 fois plus puissant pour faire tourner Office 2019 sur Windows 10. Alors oui, ces logiciels sont mieux aujourd’hui, mais nos documents Word et Excel sont ils 750 fois mieux ou 750 fois plus rapides ? J’en doute ! En 25 ans, les pages Web ont vu leur taille multipliée par 150 en 25 ans. Sont elles 150 fois mieux ? Je continue de douter…
Mais comment cela se fait-il ?
En fait, c’est assez simple : quand on fait un travail de programmation pour la première fois, on ne le fait pas de façon optimale, de façon parfaite. On essaye juste de le finir le plus rapidement possible. On peut donc presque toujours améliorer sa performance, mais ça demande de passer plus de temps sur ce problème. Tout cela se fait dans le contexte de la loi de Moore, qui fait qu’on a régulièrement de nouveaux ordinateurs (ou smartphones ou serveurs) plus rapides qui sortent. Alors pourquoi passer un temps précieux à optimiser du code alors qu’automatiquement, grâce à la loi de Moore, il va tourner plus vite dans le futur ? D’autant plus que le temps du développeur pourrait être utilisé à développer de nouvelles fonctionnalités qui rendront le logiciel plus désirable. Donc de façon quasi-systématique, on choisit le développement de nouvelles fonctionnalités plutôt que l’optimisation. C’est ce qui fait qu’on a un peu une double peine : non seulement le logiciel n’est pas optimisé, mais en plus il devient au fil du temps de plus en plus lourd, de plus en plus consommateur de ressources, avec les fonctionnalités qu’on lui ajoute. C’est pour ça qu’on entend souvent les gens dire « il faut que je change mon ordinateur (ou mon smartphone, mon serveur) : il est devenu trop lent ». Pourtant, sauf exceptions, un processeur, ça ne ralentit pas ! Par contre, un logiciel devient de plus en plus lourd, gourmand pour un matériel qui a une vitesse constante. Et donc on jette du matériel qui fonctionne encore très bien (le silicium s’use très peu !) juste parce qu’on ne prend pas le temps d’optimiser nos logiciels.
Tout ça, ça fait plus de 50 ans que ça dure ! Mais voilà, on finit par se rendre compte que cette approche n’est absolument pas durable et qu’il faut consommer moins de ressources, réduire massivement nos émissions de gaz à effet de serre (GES) et d’énergie. Parce que la fabrication de nouveau matériel, c’est ce qui est le plus consommateur de ressources, d’énergie, d’eau et le plus émetteur de GES. C’est encore plus vrai en France, où l’électricité est très peu carbonée.
Comment-peut on inverser la tendance en tant que développeurs ?
En fait, ça fait depuis le début de la micro-informatique (née avec les ordinateurs personnels) que collectivement, on fait du code pas optimisé, avec les conséquences que je viens de décrire : consommation insensé et non-durable de matériel, pour faire à peine mieux. Je dis à peine mieux, parce que oui, c’est mieux, bien sûr ! Mais il faut réaliser que les processeurs d’aujourd’hui sont 50 milliards de fois plus puissants que ceux de 1971. Et à l’époque, on envoyait des gens sur la lune, avec tellement peu de moyens. Parce qu’on optimisait le développement, à l’époque. En fait, on ne se rend pas compte à quel point l’optimisation permet d’éviter du gâchis. J’en parlais avec un ami, Pierre Beyssac. Pierre avait développé un logiciel en Python qui mettait 6 heures à tourner. Il trouvait ça long, alors il a passé un peu de temps à l’optimiser. Résultat, ça tourne en 6 minutes ! C’est 60 fois plus rapide ! (Bravo Pierre). Ça m’a bluffé, alors j’ai commencé à chercher d’autres exemples. Un collègue chez OCTO qui fait du machine learning m’expliquait comment il avait optimisé l’entraînement de son modèle en divisant par 5400 le temps utilisé. 5400 fois plus rapide ! (Bravo Aurélien !). Et puis je suis tombé sur le meilleur du pire, cette vidéo de Matt Parker, qui voulait résoudre un problème logique. Son logiciel moulinait pendant 32 jours ! Alors il en parle dans un podcast, et ses auditeurs ont commencé à travailler sur le problème en cherchant à faire de meilleurs algorithmes. Le premier est arrivé à résoudre le problème avec un logiciel qui tournait… en 15 minutes ! Le pauvre Matt était effondré, mais pas au bout de ses peines : d’autres ont fait encore plus rapide, au point que le meilleur tournait en 6,7 millisecondes. Soit 408 millions de fois plus rapide ! Bon, nous sommes là dans un cas exceptionnel, je te l’accorde, mais ça donne une idée de ce qu’on peut faire avec l’optimisation.
Alors comment on s’y prend ?
Je te l’explique de façon simplifiée : on regarde là où nos logiciels consomment beaucoup trop de ressources, et on optimise ces parties-là. On ne se casse pas la tête à tout optimiser, ça n’aurait pas de sens. De même, on ne cherchera pas non plus à optimiser au maximum. Pour reprendre l’exemple de Matt Parker, c’est pas sûr qu’il faudrait essayer d’atteindre 6,7 millisecondes. Mais déjà, passer de 32 jours à 15 minutes, c’est aller 3.072 fois plus vite, et c’était vite fait, sans trop d’effort.
Si je parle de Matt Parker, ça n’est pas pour me moquer de lui. Matt n’est pas un bon développeur senior. Il est plutôt débutant, et nous avons tous été débutants, à écrire du code difficile à maintenir et en prime peu performant. C’est donc un deuxième truc sur lequel travailler : faire du code de qualité, monter en compétence, faire du craft, comme on dit. Il y a un cadeau là-dedans : tu es fier du travail que tu fais. Ça n’a pas de prix. En montant en compétence, ton code devient de mieux en mieux, plus facile à maintenir et plus performant.
Mais alors, la loi d’erooM, c’est juste optimiser son code ?
En fait, ce qu’il faut savoir de la loi de Moore, c’est que c’était en décision de planification industrielle : ils ont décidé, chez Intel, de programmer la R&D et le financement de la construction des usines pour permettre que la loi de Moore continue. Fondamentalement, c’est une décision.
Alors la loi d’erooM (Moore à l’envers !), c’est la décision d’optimiser le logiciel existant d’un facteur deux tous les deux ans.
Donc ça veut dire que tous les deux ans, t’as libéré la moitié de tes ressources informatiques. Et avec ces ressources libérées, tu peux inventer de nouveaux usages ! Donc c’est comme la loi de Moore, mais sans changer le matériel… Et comme justement, la fabrication du matériel, c’est en gros les trois quarts de l’empreinte environnementale du numérique, si t’arrêtes de fabriquer du matériel parce que tu fais durer celui que tu as déjà fabriqué, tu viens de diviser l’empreinte du numérique par 4. Juste en faisant du boulot de qualité sur le développement logiciel.
Et ça, c’est extraordinaire et ce pour 3 raisons :
-
tu es fier de faire du travail de qualité
-
tu divises par 4 l’empreinte environnementale du numérique (en gros, tu deviens écolo dans ton boulot !)
-
tu peux continuer à innover dans le numérique.
-
(bonus) : tu ricanes en apprenant que erooM, ça veut dire « Effort Radicalement Organisé d’Optimisation en Masse » :-D
Mais pourquoi on ne l’a pas déjà fait ?
Je l’expliquais tout à l’heure : on n’optimise que sous la contrainte. Jusqu’à présent, la loi de Moore fonctionnait, donc on n’était jamais contraint. Maintenant, on a deux bonnes raisons d’optimiser. La première, c’est une obligation morale, celle d’éviter de plonger la planète dans le chaos. Bon, c’est une contrainte qui n’est que morale, donc pas visible dans un bilan comptable, donc invisible pour beaucoup trop de gens. L’autre raison, c’est que la loi de Moore est morte. Depuis 2015, la puissance des microprocesseurs X86, produits par Intel et AMD et qui équipent les PC et les serveurs, ne progresse quasiment plus, genre 3 % par an. C’est bien loin du doublement tous les deux ans promis par Moore ! Ça veut dire que pour gagner en puissance, il va falloir doubler le nombre de machine. Coté exploitation, ça revient deux fois plus cher ! Le Cloud permet ça, mais quand on reçoit la facture, on réalise que c’est devenu très coûteux de scaler. Il devient économiquement intéressant d’arrêter le gaspillage avec une approche loi d’erooM.
La startup nation est-elle soluble dans la loi d’erooM ? En effet, en tant que CTO de scale up/entreprise dans la phase de croissance de la société on nous demande de faire une usine à fonctionnalités (feature factory). La performance, elle, se règle en glissant à droite le curseur dans le cloud.
Il y a un truc super intéressant quand je parle de la loi d’erooM aux gens, c’est qu’ils entrevoient une façon de continuer à faire ce qu’ils aiment, de la tech, tout en prenant en compte l’environnement. Tout le monde sait — plus ou moins — que ça ne peut pas durer comme ça, qu’à force de gaspillage de ressources, on hypothèque le futur de l’humanité. C’est angoissant, et on ne peut pas passer sa vie dans le déni, car le déni est toxique. Par contre, se mettre en action pour lutter pour le respect des limites planétaires, ça c’est positif, ça donne la pêche ! Bref, il va falloir que la startup nation prenne conscience qu’il faut arrêter le gâchis, ne serait-ce que pour être attractif pour les collaborateurs !
Et l’IA, ça va pas annuler erooM ? En effet, on insiste à une guerre à l’armement entre OpenIA, Microsoft, Mistral, Salesforce, Google, Apple et très probablement des entreprises chinoises.
La consommation de ressources par l’IA est en effet très préoccupante. J’ai bon espoir qu’on réalise que déployer de l’IA générative à l’échelle de plusieurs milliards d’internautes n’est pas compatible avec l’accord de Paris. La quantité d’électricité nécessaire est hallucinante. Google souhaite déployer Google Search avec de l’IA pour un milliard d’internautes d’ici la fin de l’années. De son coté, Mark Zuckerberg parle de mettre une centrale nucléaire derrière chaque nouveau datacenter. Mais comme ça prend du temps, il faudra rallumer les centrales à charbon. Collectivement, on marche sur la tête ! J’ai un peu l’impression de voir un concours de celui qui arrivera le plus vite à scier la branche sur laquelle l’humanité est assise…
Où-est-ce que l’on peut te suivre et tout particulièrement les sujets autour de la loi de erooM ?
Je publie un peu partout, sur mon blog, standblog.org, sur le blog d’OCTO, blog.octo.com, (de nouveaux articles sur le sujet arrivent !), sur le blog Binaire, où je parle de Niklaus Wirth. Ou encore sur LinkedIn, par exemple sur cet article à propos de la mort de Gordon Moore.
On peut voir des vidéos de conférences que j’ai donné, par exemple à DevoxxFR. Et je vais donner des variantes de cette conférence dans différents endroits, par exemple Sunny Tech à Montpellier ou DevFest à Lille et là où on voudra bien m’accueillir ! Et puis bien sûr sur les deux podcasts auxquels je participe, L’Octet Vert et Frugarilla, où j’ai publié un épisode en commun sur erooM.
C’est quand le prochain épisode de l’Octet Vert (un vrai, pas une rediffusion de Frugarilla) ?
Aha, je n’en sais rien ! Pour l’instant, après trois saisons qui se ressemblaient beaucoup, avec les mêmes questions, j’ai eu envie de changer. Parallèlement, j’ai commencé à participer au podcast d’OCTO, Numériques Essentiels 2030. Et puis j’ai voulu parler d’erooM, explorer ce qu’il y avait autour. Alors j’ai commencé une série d’épisodes sur le thème, avec le ton de l’Octet Vert, mais publié à la fois sur l’Octet Vert et Frugarilla.fr. Pour l’instant, je vais avancer comme ça, mais qui sait où ça va m’amener ? Dans tous les cas, il est assez clair qu’il est nécessaire et important d’expliquer à nos contemporains qu’on ne peut pas continuer à gaspiller les ressources comme ça si on veut limiter le changement climatique et l’érosion de la biodiversité. Mais il y a plein de façons de faire, d’initiatives à mener, de trajectoires enthousiasmantes et c’est ça que je veux documenter et partager !
Merci Tristan