Comment éco-concevoir un logiciel ?

La soutenabilité numérique est souvent vu, limitée à l'impact des centres de données. L'effectivement, 4% de la consommation électrique mondiale est liée au centre de données. On estime que, d'ici quelques années, on aura plus de 10% de la consommation électrique des États-Unis qui sera liée au centre de données. Ce domaine n'en fait, un impact carbone fort aussi, en train de dépasser l'aviation civile. Pourtant, en fait, les centres de données ne sont qu'un objet matériel, mais qui supportent des applications. Et en fait, une grande problématique de l'impact d'une numérique, c'est que ces centres de données sont là, parce qu'on a besoin des applications qui tournent de suite que nous utilisateurs utilisons au jour le jour. Et donc, une question qui va se poser, c'est pas seulement comment améliorer les centres de données, mais comment faire des applications qui aient besoin de moins de centres de données qui soient plus frugales, plus économes. C'est ce que l'on appelle l'éco-conception logicielle. Donc, pour ce qui concerne les logiciels, assez souvent, on va s'arrêter à j'ai programmé, ça marche, c'est terminé. Alors que dans la réalité, c'est comme la plupart des autres objets. On va se poser la question, de quelles sont les fonctionnalités dont on a besoin, donc on va devoir concevoir l'application. Puis, bien sûr, ensuite, on va devoir la développer. Une fois qu'elle est développée, contrairement aux autres objets, on va pouvoir un peu l'améliorer et continuer à la faire vivre. Mais, et c'est quelque chose qu'on oublie souvent, et que l'on n'oublie pas sur les objets, c'est qu'à un moment, il va falloir penser au recyclage de l'application. C'est-à-dire, se poser la question de la terminer et peut-être d'en changer ou peut-être signer un appui d'usage, de vraiment l'arrêter. C'est ce qu'on va appeler le décomissionnement de l'application. On va, justement, regarder la fin de vie de cette application. Et donc, l'objectif, en fait, finalement, la conception et de l'éco-conception, c'est dès le départ de se poser la question de comment va se terminer la vie de cette application. La première étape consiste à concevoir l'application, définir donc les différentes fonctionnalités dont on aura besoin, et qu'elle est l'utilité, à quel problème répond l'application. Un des points importants consiste à limiter le nombre de fonctionnalités pour éviter l'obésiciel, c'est-à-dire d'avoir des fonctionnalités qui en réalité sont présentes, mais ne sont pas utiles. On peut prendre, comme exemple, les logiciels de type traitement texte, tableur, on a 20% des fonctionnalités qui sont souvent au toujours utilisés. Mais, par contre, quand on regarde plus précisément, on se rend compte que 45% des fonctionnalités ne le sont jamais. Et donc, on se dit, mais pourquoi est-ce qu'on les garde ? Parce qu'en fait, les machines récentes, elles sont puissantes, elles sont rapides, et donc finalement, on se dit, on peut les laisser, ça n'a pas d'impact. Et donc, on se permet de temps en temps de rajouter des fonctionnalités qui servent peu, parce qu'en fait, il y a assez de place pour que ça marche quand même. On se retrouve vraiment dans le cas classique de l'effet rebond où, plutôt grâce à l'évolution technologique des machines, et des logiciels, on va dire de meilleure efficacité, finalement, plus de fonctionnalités avec une efficacité qui ne va pas s'améliorer. Et donc, la conception initiale consiste à regarder quelle sont les fonctionnalités qui vont vraiment avoir un but, un usage, une nécessité. Et dès cette conception, il va falloir aussi prévoir le recyclage. Mais ce qu'en fait, il va falloir se poser la question de, comment prendre les données qui sont à l'intérieur de l'application, pour pouvoir les sortir. Et donc, il va falloir priviléger des facilités d'extraction des données, des formats ouverts et documentés. Et donc, vraiment ce qui est important lors de la conception, c'est ce choix, frugal des fonctionnalités, et de se poser la question de l'utilité de ces fonctionnalités. L'étape suivant, c'est le développement effectif du logiciel. Il y a beaucoup de décisions que l'on doit prendre lorsqu'on commence à développer un logiciel sur sa conception, sur les choix que l'on va faire, des logiciels qu'on va utiliser des bibliothèques et du langage de programmation. Typiquement, on va essayer de priviléger les logiciels libre et ouvertes. Les logiciels libre et ouverts sont accessibles, on peut accéder à leurs cultures, à mettre en opposition des logiciels fermés, où on va être tributaire, par exemple, d'une entreprise qui va fermer, qui va avoir un changement de politique interne sur lequel on n'a pas prise. Donc, utilisez les logiciels libre et ouverts, permet d'avoir cette pérénnité dans le temps sur une utilisation future, garantie des codes que l'on utilise, mais aussi d'y contribuer, si on trouve des bugs, si on veut rajouter des fonctionnalités, on pourra le faire dans le futur, et ça permettra de participer au commun, en redonnant à la communauté, finalement, ce qu'elle nous a donné. Au-delà de ça, on pose souvent la question du langage de programmation en lui-même. On peut utiliser des langages de programmation très bas niveaux, très complexes, mais très efficaces. Ou des langages de programmation beaucoup plus haut niveaux, moins complexes, plus faciles à programmer, mais moins performants, tels que le Python, le Java. Et en fait, souvent les gens se disent, Ah, pour faire de l'éco-conception, je vais plutôt devoir privilégier la performance. Alors qu'en réalité, le temps de développement peut être important, surtout, si votre programme principalement consiste à faire de la glue entre différentes bibliothèques logiciels existantes, la performance, en fait, sera dans cette bibliothèque, pas dans votre code. Il faudra donc privilégier plutôt, justement, le côté efficacité de programmation, qualité de développement, et garantie d'absence de bugs, plutôt que d'essayer de chercher la petite performance en plus. Une fois qu'on a fait ces choix, bah, il faut bien sûr développer l'application, et essayer d'évaluer la qualité de ce développement. Pour cela, on utilise, par exemple, des méthodes d'analyse statique. L'analyse statique consiste à utiliser des outils logiciels ou mathématiques, qui permettent de prouver que certaines parties du code sont efficaces,non pas de bugs. Par contre, on ne peut pas tout faire avec de l'analyse statique. Donc, on va aussi lors du développement, se poser la question des informations dont on va vouloir récupérer in vivo sur l'application, quelles sont les fonctionnalités utilisées, quelles sont les parties du code qui sont les plus lentes, de façon plus tard, à savoir ou à louer du nouveau temps de développement pour pouvoir faire évoluer le code. C'est donc la partie éco-conception logicielle du point de vue du développement. La plus grande partie de la vie de l'application va consister à être utilisée par des utilisateurs bien sûr. Et donc, il va falloir se poser la question de comment garder des fonctionnalités pertinentes durant toute la vie des applications, et donc de la faire évoluer et potentiellement un moment de la faire mourir. Ce qu'on appelle l'amélioration continue, consiste justement à essayer de comprendrequelles sont les fonctionnalités qui sont utilisées, celles qui ne le sont pas, celles qu'on peut améliorer, de façon à justement garder une application qui soit le plus efficace possible d'un point du fonctionnalité, et le plus utile possible. Si je reprends l'exemple, des 45% de fonctionnalités sur les tableurs,textes et autres, qui sont non utilisés, on pourrait dire, c'est pas grave, elles ne prennent pas de place puisqu'on les utilise pas. Alors qu'en réalité, il faut quand même vérifier qu'elles n'ont pas de bugs, il faut les déployer, elles prennent de la place sur les ordinateurs, et du temps quelque part pour les programmes. Et donc, il faut se poser la question à avoir la capacité pendant la durée de vie de l'application,d'enlever des fonctionnalités, qui sont peu ou pas utilisées, ou peu utiles d'ailleurs. Si l'on se retrouve dans le cas, par exemple, du métro de San Francisco, ou certaines de lignes de métro sont gérées par des logiciels, qui n'ont pas été mis à jour depuis 1998, parce qu'on ne sait pas le faire. On n'a pas gardé les documentations, la conception initiale ne permettait pas de les mettre à jour. Et donc, on est dans le cas où ils vont devoir dépenser plusieurs millions de dollars de façon à repartir de zéro pour tout mettre à jour. Au-delà de ça, il faut se poser la question de quand arrêter le logiciel. Un logiciel parfois n'est plus utile, où les technologies ont tellement changé qu'on ne peut pas simplement le faire évoluer. Pour pouvoir arrêter un logiciel, et avoir cette capacité, il faut être capable d'en extraire les données. C'est pour ça qu'il faut que dès la conception, se poser la question des données ouvertes documentées que l'on pourra extraire du logiciel en fin de vie, soit pour créer un nouveau logiciel à partir de ces données, soit simplement pour les archiver, pour avoir une trace dans le futur. Au-delà du développement, qui est souvent le focus, lorsqu'on fait de l'éco-conception de développement logiciel, ce qui est très important, c'est de garder la frugalité des fonctionnalités. Se focaliser sur les fonctionnalités qui sont utiles de façon à ce que l'application, par effet rebond par exemple, ne grandissent pas avec des fonctionnalités inutiles qui vont prendre de la place. Et donc, de garder à l'esprit, que l'on veut avoir un faible nombre de fonctionnalités utiles et pérennent dans le temps.