Il est de notoriété publique que l’IA est une technologie énergivore, et il est usuel de penser que l’IA n’est pas compatible avec l’éco-conception des logiciels.
Mais évidemment, comme attendu, rien n’est aussi binaire qu’il n’y paraît.
D’abord, il va sans dire que la technologie est récente et va être améliorée, optimisée, voire révolutionnée dans les prochaines années (de la même manière que la blockchain a vu sa consommation énergétique drastiquement diminuer au fil des générations successives). On peut par exemple noter cette approche consistant à réinventer le hardware pour qu’il soit intrinsèquement conçu pour l’apprentissage automatique. Ou encore de nombreuses approches visant à améliorer la phase d’entraînement des modèles (par exemple l’approche JEST). Evidemment, certains diront que cela n’en fait pas un bon argument pour l’éco-conception, du fait de l’effet rebond, et ils auront bien raison de le souligner.
Mais surtout, c’est sans compter les capacités de raisonnement des LLM et la possibilité de créer des agents IA spécifiques capables de traiter automatiquement des tâches complexes ou d’assister efficacement l’humain dans ces tâches. Déjà, l’approche ReAct (Reasoning and Acting), permet de mieux contrôler l’IA (typiquement d’éviter les fameuses “hallucinations”), mais elle permet surtout que l’IA soit “décideuse” dans l’usage de l’information nécessaire pour résoudre un problème, et ainsi de minimiser sa consommation (en termes de données, de tokens, et donc potentiellement en termes énergétiques).
Ainsi, il y a fort à parier que dans les années à venir, dans la lignée de l’AI for Green (voir ici, ou là), “l’AI for Green IT” devienne incontournable, et que l’on voit proliférer tous types d’agents, et en particulier des agents pour aider à l’éco-conception des logiciels ou des infrastructures. Et j’ai envie de dire que je suis assez impatient que cela arrive, car l’éco-conception est une activité extrêmement complexe et itérative.
L’éco-conception logicielle nécessite en effet un effort sur le long terme et implique des incertitudes dans les arbitrages et des capacités d’adaptation importantes. Les choix à faire ne sont jamais gravés dans le marbre, et évoluent sans cesse en fonction des usages, des volumes de données, des contraintes “métier”, et des technologies hardware et software sous-jacentes.
Le Compilateur LLM de Meta, par exemple, montre qu’il est intéressant d’envisager les agents IA comme un outil pour Green IT. Ce compilateur utilise en effet un LLM pour optimiser le code et aider à compiler des versions plus efficaces des logiciels. A noter que Meta s’est déjà adonné à ce type de sport avec le fameux HipHop, un compilateur de PHP vers C++, qui a permis en 2010 à Facebook d’optimiser la consommation énergétique de son réseau social d’environ 50%, ce qui correspond à une économie d’énergie significative, ayant permis d’éviter à l’époque la construction d’un nouveau Data Center. Mais c’était sans l’aide des LLM et on peut espérer qu’il sera possible de faire encore mieux avec.
Bien sûr, tout cela prendra du temps et beaucoup de R&D et de REX sont encore nécessaires. Mais les premiers tests que j’ai pu mener avec Daquota.io et un agent ReAct construit en Python avec Llama et le LLM d’OpenAI (qu’on ne présente plus) sont très prometteurs, au moins pour assister l’utilisateur pour construire des applications en low-code, en maîtrisant mieux la complexité.
La prochaine étape sera d’assister le développeur dans le respect de certains critères d’éco-conception, à générer des applications éco-conçues, et surtout à les faire évoluer en temps réel pour s’adapter au mieux aux usages et aux contraintes des métiers.
Et il y a longtemps que je n’ai pas été aussi impatient de voir ce qu’une approche donnera concrètement en termes de résultats… et surtout pourra-t-on répondre à la question que tout le monde est en droit de se poser à ce stade : les économies énergétiques induites par l’AI for Green IT viendront-elles compenser les dépenses nécessaire à sa mise en oeuvre ?
Sur ce sujet, il est à noter qu’on a déjà quelques éléments de réponses. On peut se référer par exemple à cette étude Goldman Sachs, qui prévient que les bénéfices de l’IA pourrait être déceptifs car largement amputés par les coûts financiers nécessaires à sa mise en oeuvre.
Comme le souligne Rodney Brooks dans cet article Tech Crunch, ceci peut s’expliquer aussi par un optimisme démesuré à penser que l’IA est capable de remplacer l’humain sur de nombreuses tâches alors qu’en réalité, 1/ les limites de l’IA vont rapidement être atteintes en termes d’autonomie, 2/ les générations à venir des LLMs seront sûrement plus efficaces mais pas fondamentalement plus autonomes ni nettement meilleures à résoudre des problèmes ou effectuer des tâches que les générations actuelles.
Il y a donc fort à parier que ceux qui essayeront de tout faire avec l’IA (y compris remplacer des technologies spécifiques) s’en mordront les doigts assez rapidement, et qu’ils devront gérer une facture énergétique salée, ainsi qu’une dose de non-déterminisme qui coûtera cher aux métiers.
A ce stade, il semble donc que la voie à suivre est celle de l’hybridation, dont une approche possible est d’implémenter, avec une logique ReAct, des agents RAG (Retrieval-Augmented Generation), qui s’appuient sur des services “classiques”. L’objectif étant de garder le meilleur des deux mondes et de limiter ainsi les coûts associés à l’IA.