Optimisation des logiciels : interview croisée de nos trois experts
Dans l’un de ses articles[1], Tristan NITOT, co-fondateur de Mozilla, rappelle que les lois qui ont régi l’évolution de l’informatique depuis les années 70 (notamment la loi de Moore) sont désormais obsolètes et plaide pour un changement des habitudes dans le monde de l’IT.
Selon lui, il faudrait enfin cesser de négliger l’optimisation des logiciels par rapport au développement de toujours plus de fonctionnalités.
Digital Bay a souhaité faire réagir trois professionnels sur ce sujet de fond.
[1] La loi de Moore est morte et c’est une bonne nouvelle – OCTO Talks !
Nous avons interrogé Damien Archaimbault, développeur full stack indépendant, Jérôme ROUAIX, fondateur du portail immobilier wymmo.com et enfin Frédéric BERTRAND, enseignant-chercheur et responsable du master informatique de l’université de La Rochelle. Merci à tous les trois pour leurs éclairages précieux !
Etes-vous d’accord pour dire que l’habitude a été prise durant toutes ces années d’utiliser davantage le temps de développement à la création de nouvelles fonctionnalités plutôt qu’à l’optimisation du logiciel existant ?
Frédéric BERTRAND
– Oui, avec la pression existant généralement sur le développement de nouvelles fonctionnalités (et donc sur les développeurs), peu de temps est consacré à l’optimisation, et même souvent aux tests, ce qui est encore plus grave. C’est seulement à partir du moment où l’utilisateur final perçoit une certaine lenteur qu’on commence à y accorder de l’importance…
Jérôme ROUAIX
– L’optimisation de n’importe quel processus se heurte assez rapidement à un effet rebond. Et dans le cas du développement informatique, l’augmentation de puissance des machines a servi à faire beaucoup plus mais aussi souvent beaucoup moins efficace.
Damien ARCHAIMBAULT
– Totalement d’accord ! Quel que soit le projet, en startup comme en prestation pour des grands comptes, la pression est mise sur les délais et les fonctionnalités : il faut que ça marche ! Et ensuite on n’y revient pas, sauf s’il y a des retours client. On se contente trop souvent de corriger les bugs au cas par cas, on met des « rustines » sans aller plus loin.
Constatez-vous une évolution ces dernières années dans la pratique des développeurs (ou dans votre pratique) ?
Frédéric BERTRAND
– J’enseigne les « bonnes » pratiques notamment les tests mais si certaines entreprises les mettent en place d’autre souvent considèrent cela comme du temps passé au détriment du développement de nouvelles fonctionnalités.
On pourrait dire que les entreprises (souvent plus petites) travaillant au stade « artisanal » se sentent moins concernées. Pour les entreprises plus structurées et notamment lorsqu’elles deviennent « éditeur logiciel » et passent au stade « industriel », elles se sentent beaucoup plus concernées et conscientes que les méthodes de travail doivent évoluer…
Jérôme ROUAIX
– Non : La doctrine aujourd’hui est toujours de n’optimiser que lorsque l’effort (coût) d’ingénierie supplémentaire est rendu nécessaire par les contraintes opérationnelles : le coût aussi (en fonction de la taille/scale du produit) et autres (limites de batterie sur les mobiles, de puissance en embarqué).
Certains développeurs ne s’en préoccupent pas, d’autant plus qu’ils n’y sont pas encouragés par le business. Les autres développeurs sont tout simplement limités par leurs propres compétences et le temps qu’ils peuvent consacrer à l’amélioration des performances. Il y a un juste milieu à trouver ici.
Damien ARCHAIMBAULT
– Je ne constate moi non plus pas vraiment d’évolution, si ce n’est en terme d’organisation. Sur les gros projets, les équipes formalisent davantage la méthodologie. Les développeurs sont répartis par guildes et s’accordent en amont sur une charte de bonnes pratiques pour harmoniser les modalités et la structure du code. D’autre part, j’ai eu la chance de rencontrer dans mon parcours des développeurs séniors qui réussissent, malgré les pressions, à conserver une conscience de la nécessité d’optimiser le code à toutes les étapes et à obtenir des délais pour cela. Mais c’est assez rare.
Concrètement, que faire pour aller dans le sens de l’optimisation du code (afin d’augmenter la durée de vie du matériel) ? Connaissez-vous la méthodologie PLASMA citée dans l’article ou toute autre méthode ?
Frédéric BERTRAND
– Honnêtement l’optimisation du code arrive vraiment en dernière étape…
D’abord il faudrait choisir un langage adapté : C++ ou Rust offrent de très bonnes performances au prix d’une gestion « manuelle » de la mémoire. Ensuite on devrait optimiser les algorithmes en premier lieu (par exemple au lieu de faire deux boucles, ne peut-on pas tout faire dans la même ?), et enfin le code (par exemple allocation statique vs allocation dynamique).
Jérôme ROUAIX
– A mon avis, la question fait l’amalgame entre 2 problèmes :
– Oui un programme lourd, ça se voit plus sur une vieille machine, mais c’est loin d’être la raison principale pour laquelle une machine est obsolète. Une machine est obsolète lorsque les constructeurs et éditeurs arrêtent de la supporter ! Il y a des efforts en ce moment (augmentation de la durée des mises à jour chez Apple et les grandes marques Android), mais généralement le logiciel sur un appareil sera vraiment bien supporté uniquement le temps de sa garantie, et bien loin de la véritable durée de vie du matériel lui-même. Cela pousse à la consommation de nouveau matériel car les risques cyber à utiliser des systèmes sans mise à jour sont réels.
Damien ARCHAIMBAULT
– Selon moi, il faudrait déjà que nos clients acceptent de dédier du temps à l’optimisation, ça demande une prise de conscience. Côté développeurs, même si on travaille sur des machines récentes et puissantes, ne jamais oublier de tester sur des machines plus anciennes. Et toujours réfléchir en termes d’utilité pour alléger au maximum. Alléger les images, alléger le nombre de datas qui circulent… Bien écouter l’utilisateur pour choisir le dimensionnement adapté à chaque projet : par exemple utiliser WordPress pour un simple site vitrine, c’est inutile. En revanche pour un site sur lequel il y aura de nombreuses actualités et des billets de blog, là c’est justifié.
La méthodologie PLASMA citée dans l’article me semble intéressante pour les grandes entreprises. Si j’étais DSI, je m’y intéresserais de près.
Voyez-vous d’autres points à souligner ?
Frédéric BERTRAND
– J’aimerais rappeler une citation de certainement l’un des plus grands informaticiens toujours vivants :
« On devrait oublier les petites optimisations locales, disons, 97 % du temps : l’optimisation prématurée est la source de tous les maux. »
Autrement dit, les optimisations de haut niveau concernant le choix des algorithmes ou l’architecture d’un projet doivent venir avant celle de bas niveau (réécriture en assembleur, déroulage de boucle, etc.). Ainsi, ce n’est que vers la fin de l’écriture du programme, une fois que l’analyse montre
qu’un détail de bas niveau est critique qu’il peut éventuellement être nécessaire de le modifier.
Damien ARCHAIMBAULT
– L’idéal serait de définir autrement la maintenance informatique, en allouant plus de temps au prédictif pour faire en sorte que le code soit régulièrement réinterrogé et mis à jour, et non pas en catastrophe comme c’est souvent le cas.
Autre piste intéressante pour les TPE et startups : aller vers l’Open Source pour s’extraire de l’obsolescence programmée des GAFAM et être davantage maître à bord.
Jérôme ROUAIX
– Je peux mentionner que toutes les technos ne se valent pas en matière d’optimisation. Un code écrit en Rust sera à des ordres de grandeur plus performant qu’un code écrit en Python, Ruby, Javascript, C# ou Java, pour un effort d’ingénierie similaire.
Malheureusement réécrire les logiciels est l’une des activités les plus couteuses imaginable dans un projet, ce n’est donc pas demain que la majorité des logiciels seront développés dans les technologies les plus efficientes … mais … on … y … viendra !
Propos recueillis par Hélène Buisson – hbsolutionscomm.com