Interview de Tristan Nitot : faire tourner le numérique de demain sur le matériel d’hier, une qualité nécessaire

Bonjour Tristan, peux-tu rapidement te présenter ?

Je m’appelle Tristan Nitot, j’ai bientôt 59 ans et je suis tombé dans le numérique quand j’étais petit, il y a 45 ans. J’avais 14 ans, un ami de mon père m’a mis un ordinateur entre les mains, et j’ai appris à programmer comme ça. C’était le tout début de l’informatique personnelle, à l’époque de l’Apple II, du Sinclair ZX-81, du TRS-80. Par la suite, j’ai fait des études d’informatique et j’ai vécu des tas de “révolutions informatiques”, la télématique, le Web, le mobile, le Cloud, etc.

Par la suite, je suis allé travailler chez Netscape (l’un des premiers navigateurs Web), j’ai découvert l’importance des standards du Web et l’Open Source. C’était passionnant. Cela m’a permis de monter Mozilla Europe que j’ai présidé, de lancer Firefox en Europe, c’était incroyable ! Parallèlement à cela, je maintiens un blog depuis 23 ans standblog.org, où je fais une revue de presse de ce que je lis sur la technologie, ça me sert à préparer mes conférences et mes podcasts. Maintenant, je travaille chez OCTO Technology, une entreprise de conseil en systèmes d’information.

Qu’est-ce que le test et la qualité représentent pour toi ?

La qualité, c’est ce qui fait la différence entre le bricolage et l’industrie. Vue l’importance qu’a le numérique dans nos vies, on voit bien que c’est un sujet essentiel ! Et dans tout ça, le test, c’est un peu le bras armé de la qualité.

Dans ta keynote de la JFTL tu parles de « faire tourner le numérique de demain sur le matériel d’hier ». Est-ce vraiment possible ?

J’y crois, je crois que c’est fondamental, et je fais tout ce qui est en mon pouvoir pour que ça le soit ! Quand j’ai commencé l’informatique, le matériel était beaucoup moins puissant qu’aujourd’hui, donc quand on voulait faire faire un truc à l’ordinateur, il fallait être conscient de ses limites en puissance de calcul, en RAM, en stockage. Si un programme était trop gourmand en ressources, il ne pouvait pas tourner. Très logiquement, les informaticiens savaient où étaient ces limites et comment faire des logiciels bien pensés pour ne pas les dépasser.

La “Loi de Moore”, qui n’est pas une loi physique mais plus une façon de programmer l’industrie du semi-conducteur, dit “la puissance des processeurs double tous les 24 mois”. Elle s’est vérifiée pendant longtemps, mais maintenant elle est de moins en moins vraie. Cela a fait que les développeurs devaient moins se préoccuper de la consommation de ressources puisque la puissance disponible doublait tous les 2 ans. Donc l’habitude d’optimiser les logiciels s’est un peu perdue, elle est devenue réservée à des domaines comme le spatial, l’embarqué, les jeux sur consoles ou le High Performance Computing. D’autant que parallèlement, on avait besoin d’écrire de plus en plus de code pour “numériser” le monde, donc on est devenu moins regardant sur la qualité. On a écrit de plus en plus de fonctionnalités pour les logiciels pour donner envie aux gens de les acheter. Les logiciels, moins optimisés mais avec plus de fonctionnalités, se sont ralentis. Niklaus Wirth, informaticien de génie, inventeur de plusieurs langages dont le Pascal, disait en 1995 “les logiciels ralentissent aussi vite que le matériel accélère”. On a appelé cela la loi de Wirth. Malheureusement, cette loi se vérifie très régulièrement, c’est pour ça qu’on entend si souvent des gens dire “il faut que je change mon smartphone/PC, il est devenu trop lent”. Mais une machine, sauf rares exceptions, ça ne ralentit pas avec l’âge ! C’est juste qu’on met dessus du logiciel plus récent, moins optimisé, avec plus de fonctionnalités. Et ce logiciel est devenu trop gros pour le matériel de l’époque. Du coup on jette des smartphones et des PC qui marchent encore très bien juste à cause de la mauvaise qualité du logiciel.

Voilà, ça c’est le problème : on n’arrive plus à faire tourner le logiciel d’aujourd’hui sur le matériel d’hier. Pourtant, il faudrait !

Mais pourquoi le faudrait-il ?

Les lecteurs ont sûrement entendu parler du changement climatique, des émissions de gaz à effet de serre, de l’artificialisation des sols, de l’effondrement de la biodiversité. En fait, l’humanité, à force de fabriquer de nouveaux produits et de jeter les anciens, est en train de détruire la seule planète habitable de l’univers. Les scientifiques nous préviennent, mais nous sommes trop occupés pour les écouter. Produire plus, vendre plus, faire de la croissance pour gagner plus, tout ça nous préoccupe tous au point qu’on ne réalise pas qu’on est en train de scier la branche sur laquelle nous sommes assis.

Alors que si on faisait des logiciels optimisés, comme on l’a fait pendant des décennies, on gâcherait beaucoup moins de ressources informatiques, on produirait moins de matériel, sans pour autant arrêter de produire de nouveaux logiciels.

Quel est l’intérêt de cette démarche et est-elle vraiment possible sans « sacrifier » son confort ?

En bonne partie, oui. Bien sûr, cela nécessite de faire un travail de meilleure qualité, d’arrêter de bâcler le travail de développement. Aujourd’hui, on demande à un développeur de développer vite, mais pas de développer bien. Ce qui compte, c’est que la fonctionnalité soit livrée, pas qu’elle soit efficiente. Cette dimension est oubliée, et donc on gâche beaucoup de ressources.

J’ai un ami qui trouvait que son logiciel occupait beaucoup de CPU. Il a regardé où ça consommait, il s’est rendu compte que sa machine refaisait souvent les mêmes calculs. Il a modifié quelques lignes pour mettre en cache le résultat, il s’est rendu compte que son logiciel tournait dorénavant 60 fois plus vite. En fait, avant il gâchait 60 fois trop de puissance de calcul ! Tiens, un autre exemple. J’ai un collègue qui a fait un travail d’optimisation sur un algorithme de machine learning. Après cet effort, l’algorithme tournait 5400 fois plus vite ! Autrement dit, avant, il gaspiller 5400 fois trop de ressources. Donc oui, ça demande de se gratter un peu la tête, de ne plus travailler “vite fait mal fait”, mais par contre, ça apporte une énorme satisfaction, celle de faire un travail… de qualité !

Au final, peut-on donc voir cette démarche comme un travail sur la qualité ?

Absolument ! Et c’est incroyablement satisfaisant. Mais c’est une approche un peu différente de la qualité telle qu’on l’entend d’habitude : on ne se contente pas de mesurer si le résultat est juste, mais s’il est produit sans gaspiller des ressources. Cela implique de mesure qu’on ne régresse pas en performance au fil du temps. Parfois, ça peut être acceptable de régresser en performance, si c’est justifié, si ça apporte quelque chose niveau métier. Mais pas si c’est juste parce qu’on n’a pas essayé de faire les choses correctement.

Penses-tu que ce critère qualité devrait rentrer dans la stratégie de test des entreprises ? Si oui, comment ?

Pour moi, c’est une certitude, mais dans un sens plus large : oui, il est indispensable de tester la fonctionnalité, la non-régression dans les mises à jour du code, mais aussi tester la performance et s’assurer qu’elle ne baisse pas au fil du temps.

Comment expliques-tu la baisse assez impressionnante de la performance sur ces dernières années ? Je ne pense pas qu’un studio actuel serait capable de faire tourner Mario Bros 3 sur un processeur 8 bit.

En fait, on optimise que sous la contrainte. Ou plus exactement, on optimise toujours, mais quand on n’y prête pas attention, on optimise pour la facilité, pour la rapidité de développement. La loi de Moore, qui structure le numérique depuis plus de 50 ans, nous a habitués à ne pas prêter attention à la performance. Mais deux choses nous y contraignent dorénavant. D’une part, la loi de Moore est à bout de souffle. La puissance des processeurs en single thread est quasiment à l’arrêt depuis 2015 alors qu’elle doublait tous les deux ans jusqu’alors. D’autre part, on a pris conscience que notre mode de fonctionnement qui consistait à acheter des nouvelles machines pour pallier à notre fainéantise collective n’est pas durable. Les déchets numériques sont quasi-impossibles à recycler et très polluants, ils ont une empreinte environnementale disproportionnés par rapport à leur poids. Tout cela fait qu’on ne peut plus faire aussi mal qu’avant. Les anciennes approches nous conduisent dans le mur !

J’aime beaucoup la loi d’EROOM que tu as conceptualisé, peux-tu brièvement la présenter ?

Avec plaisir ! EROOM, c’est l’inverse de la loi de Moore. Si on repère les bouts de code qui sont très mal écrits et qu’on les optimise, on peut faire tourner nos logiciels deux fois plus vite en moyenne. Et donc libérer de la ressource informatique qui était mal utilisée. Si on fait ça tous les deux ans, on double la puissance informatique disponible. C’est comme la loi de Moore, mais sans changer le matériel, juste en faisant un travail de meilleure qualité, donc plus satisfaisant. Et comme l’empreinte environnementale de l’informatique elle se fait à 80% lors de la fabrication du matériel, tu viens de la diviser par 4 ou 5 si tu fais de l’EROOM ! Ah, et petite blague, EROOM, c’est MOORE à l’envers mais ça veut aussi dire “Effort Radicalement Organisé d’Optimisation en Masse” (désolé !). (Rires).

Souhaites-tu ajouter quelque chose ?

Je crois que si on fait de l’EROOM, tout le monde y gagne : on continue à innover dans le numérique avec la ressource libérée, les développeurs font du meilleur travail, plus satisfaisant, les testeurs voient leur rôle devenir plus important dans la chaîne, et tout le monde gagne à devenir plus respectueux de l’environnement.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.