Tristan Nitot’s Post

View profile for Tristan Nitot, graphic

Entrepreneur, books and podcast author, I work on anthropocene and digital commons

"Faire fonctionner correctement ce qu'on a déjà plutôt que de mettre son énergie dans un truc nouveau qui ne marchera pas très bien". C'est vraiment raccord avec ce que je raconte sur la loi de Moore ("les ordinateurs doublent de puissance tous les 2 ans") et la loi de Wirth ("les logiciels ralentissent plus vite que le matériel n'accélère") et qui ont fait que le numérique court très vite pour faire du sur-place et qu'on jette nos smartphones qui marchent encore très bien au bout de 2 ans et demi parce qu'on a l'impression "qu'ils sont devenus plus lents". 🤓 Mais un smartphone, comme un ordinateur, ne ralentit que très rarement ! Par contre, on rajoute du logiciel pas optimisé dessus donc plus lent, logiciel qu'il a du mal à faire tourner. C'est l'obsolescence programmée qui fait tourner le numérique depuis 50 ans. 😨 J'ai trouvé ça sympa pendant 45 ans d'avoir du matos nouveau qui sortait régulièrement. Sauf que depuis, j'ai compris que les ressources de la terre, les minerais, l'eau, l'énergie, n'étaient pas infinis. Contrairement à ce qu'on pense de la croissance. Comme l'empreinte carbone du numérique provient à 75% de la fabrication du matériel, il faudrait optimiser massivement le logiciel écrit à la va-vite qu'on empile depuis 50 ans. Ca permettrait de diviser par 4 l'empreinte du numérique et de ne plus renouveler le matériel ! J'explique tout cela ci-dessous, dans la notion de "principe d'erooM", Effort Radicalement Organisé d'Optimisation en Masse (ou Moore à l'envers, oui, désolé ! 😂 ) Mon article sur la loi de Moore : https://lnkd.in/ehxAvjK8 Celui sur Niklaus Wirth : https://lnkd.in/eJ_AUD7D

Pensée du jour sur le dev logiciel : si aujourd'hui on appelle “innovation” le fait de suivre la dernière tendance, il est peut-être temps de mettre moins d'énergie dans ce qu'on appelle innovation, et un peu plus dans le fait de faire fonctionner correctement ce qu'on a déjà. Out : il faut se dépêcher d'intégrer la nouvelle tendance le plus vite possible, les premiers vont récolter toutes les parts de marché (j'ai pas d'exemple récent de ça d'ailleurs) In : on va réparer l'existant, et mettre le budget “innovation” dans une vraie campagne marketing (le vrai nom de ce qu'on appelle innovation en passant) sur notre produit qui marche du tonnerre maintenant. Hypothèse non vérifiée : pour beaucoup de produits ce serait moins cher et plus efficace ? Autre hypothèse non vérifiée : il y a tellement de logiciels qui sont mauvais en ce moment parce qu'on passe de nouveau projet en nouveau projet. Crazy idea: n’embauchons pas des ingénieurs pour travailler sur de nouveaux produits innovants, finito la disruption. Embauchons des ingénieurs pour maintenir et corriger nos produits existants, les faire fonctionner aussi bien que ce qu'on imaginait. Chasser les bugs, les incohérences, les lenteurs qui font partir nos utilisateurs. Autre crazy idea: réveillons notre empathie vers les personnes qui utilisent nos produits actuels. Elles ont plus besoin d'un produit qui fonctionne correctement aujourd'hui que d'aller sur Mars demain.

Pascale Fournier

Ingénieur logiciel expérimenté - Java

3mo

Chasser les lenteurs, bien sûr, mais aussi les failles de sécurité ! C'est tout autant dans l'intérêt des utilisateurs. Mais on peut rapidement se trouver limité : les librairies et frameworks intégrés il y a 5, 10 ou 15 ans n'offrent pas forcément la possibilité de sécuriser dans de bonnes conditions. On peut alors se retrouver face à un dilemme : dois-je tout péter, avec le coût écologique associé (le build logiciel a lui aussi son coût) pour sécuriser ? Ou patcher encore et encore, dans la limite du possible et jusqu'à ce que plus personne ne puisse (veuille) maintenir le code ? La question se pose sur de nombreuses applications, qui tournent bon an mal an sur de vieux OS, qui font le job, avec des perfs potentiellement correctes, mais avec un risque de sécu élevé, qui s'accroît avec le temps au fur et à mesure de la découverte des failles.

Cyril Clemenceau

Ingénieur d'études et de développement slow tech

3mo

Rien qu'en supprimant tout le code mort qu'on n'a pas le temps de supprimer lors d'une phase de dev parce qu'il faut vite sortir une nouvelle version avec la fonctionnalité qui fait que l'écran lance un feu d'artifice lorsqu'on termine un paragraphe... Je plaisante un peu mais parfois on n'est pas loin de la réalité sur les nouvelles fonctionnalités. Pendant un temps, il y avait la mode des bureaux 3D sur certains système d'exploitation. ça consommait un max de ressource pour un rendu plus que discutable. Aujourd'hui, j'essaie juste de garder mon vieux PC avec un linux qui tourne pas trop mal dessus. Ce que j'aimerai, c'est qu'on arrête d'avoir un PC et un téléphone. Au final, on retrouve les mêmes composants sur un smartphone qu'un PC. On pourrait donc avoir un affichage correct sur écran externe si les constructeurs le voulaient (je n'ai pas les compétences suffisantes pour le faire moi même) (à l'image d'un motorola atrix pour ceux qui ont connu! ) Bref oui, il faut arrêter avec ses mises à jour qui tuent nos smartphones ou même nos PC. Mais également arrêter d'avoir deux équipements pour un usage similaire

Fabrice Galliot

Free-lance Chef de projet informatique / Consultant / Développeur de systèmes d'informations avec IA

3mo

Oh que ça me parle !

Je partage complètement. Les développements sont en général "rushés", (budget négociés à la baisse, ainsi que les délais, etc.), pour ajouter la prochaine fonctionnalité qui brille... Mais est-ce que la base est là, fiable, solide, rapide, sécurisée ? Ou balaie-t-on la question sous le tapis ?

Mélissa Diakité Kaba

Designer d’Expériences et Leader en transformation spécialiste de la performance • Prospective • UX designer • Management Team • Conférencière // Publication en cours 📚

3mo

J'adore. Merci à Sébastien Roccaserra et Tristan Nitot pour leurs posts. Si seulement il pouvait y avoir plus de post en ce sens. Je rajouterai mon grain de sel en parlant de la place que doivent prendre/et qu'on doit laisser aux designers pour améliorer l'existant. (la place, le temps et le budget alloués)

See more comments

To view or add a comment, sign in

Explore topics