Daquota.io est un outil low-code qui veut promouvoir l’éco-conception. L’association de l’éco-conception et du low-code peut paraître antinomique, mais en réalité, elle ne l’est pas.
En effet, la raison d’être du projet Daquota.io part de deux constats.
Premier constat : les effets de deuxième ordre et de troisième ordre sont au coeur du problème
Quand on parle d’éco-conception du numérique, les impacts souvent considérés sont les impacts de premier ordre, c’est-à-dire la consommation directe de ressources, par exemple en électricité, mais aussi en ressources physiques et matérielles. Il est normal que ces impacts soient considérés en priorité, car ils sont facilement compréhensibles et mesurables. De plus, ils sont souvent liés à un coût financier direct pour les utilisateurs des services numériques.
Or, il existe aussi des impacts dits de deuxième ordre (effets de dématérialisation ou d’économie de ressources dans d’autres secteurs), ou de troisième ordre (effets de réorganisation et de changement d’habitudes), comme décrit par le modèle GreenSoft ci-dessous.
Dans de nombreux cas, les impacts de premier ordre peuvent être négligeables par rapport aux effets de second ordre. Par exemple, un service numérique de commande en ligne aura des impacts sur les transports (livraisons) qui peuvent être bien supérieurs aux impacts de l’usage de ce service. Autre exemple : un service qui permet d’optimiser une filière d’approvisionnement en nourriture, et ainsi d’éviter un gâchis inutile, peut avoir un impact positif sur le secteur de l’agro-alimentaire qui peut largement contrebalancer les impacts négatifs liés à la mise en place et à l’utilisation d’un tel service. Dernier exemple : la dématérialisation des cartes de paiement (carte bleue, mais aussi carte de transports, billets, ou carte de réduction) peut avoir des impacts positifs liés à l’économie de fabrication de carte plastiques ou d’impression de tickets papier devenus inutiles, surtout dans le cadre d’une population d’utilisateurs déjà équipée de terminaux mobiles.
En conséquence, on ne peut nier l’obligation d’éco-concevoir les services numériques en réfléchissant aux impacts de deuxième et troisième ordres, c’est-à-dire en ayant une approche systémique globale. Une bonne manière d’approcher le problème est de faire une analyse conséquentielle (un peu comme pour une analyse de risques). Pour mettre en place une telle approche, il est primordial que les métiers puissent être partie prenante dans la mise en place des services et des workflows métiers. Ce sont à partir d’arbitrages du métier que les impacts transverses négatifs pourront être minimisés, et que les impacts transverses positifs pourront être maximisés. De plus, il est indispensable de conserver une agilité dans la conception de ces services, car l’évolution des habitudes et des comportements liés à la mise en place de ces services peut entraîner des effets rebonds avec des impacts très largement négatifs, et il faudra alors adapter les services pour limiter ces effets (par exemple, en imposant des quotas, en modifier l’UX, ou à l’aide de mesures incitatives).
En éco-conception des services numériques, toutes les ressources utilisées ne se valent pas. Il n’est pas admissible de gâcher des ressources pour des impacts d’ordres supérieurs nuls ou négatifs. Mais il n’est pas non plus raisonnable de limiter un service numérique si les impacts d’ordres supérieurs sont largement positifs.
LA SOBRIÉTÉ ÉNERGÉTIQUE ET NUMÉRIQUE DOIT ÊTRE SÉLECTIVE SOUS COUVERT D’ECO-CONCEPTION.
Ainsi la proposition d’un outil low-code à la main du métier prend tout son sens dans une logique d’éco-conception des services numériques. La possibilité pour les métiers d’éviter les longs délais de mise en œuvre (effet tunnel), lié à un silotage entre les équipes métier et technique, est un élément clé pour l’éco-conception des services numériques. Daquota.io propose un continuum entre le no-code et le code, potentiellement en utilisant l’intelligence artificielle générative, ce qui permet au métier et rester partie prenante pendant la conception, le déploiement, et la maintenance des services, qui peuvent ainsi être éco-conçus de bout-en-bout.
Deuxième constat : le numérique consommerait 20% de l’électricité mondiale en 2030, avec une part croissante lié aux réseaux et aux datacenters
Même si l’éco-conception requiert une analyse globale pour prendre en compte les effets de deuxième et troisième ordres, ce n’est pas une raison pour négliger les effets de premier ordre, c’est-à-dire les impacts directs du service à éco-concevoir. Si on ne prend pas en compte les effets de premier ordre, on risque de perdre les potentiels bénéfices liés aux impacts positifs des effets d’ordres supérieurs. C’est d’autant plus important que les projections montrent que le numérique est voué à prendre une part de plus en plus significative de la demande en énergie. De nombreuses sources convergent vers des projections à 20% de la demande énergétique mondiale d’ici 2030.
Optimiser le service pour minimiser les impacts directs est particulièrement important dans le cas d’un service massivement utilisé et que les économies d’échelle deviennent significatives, comme c’est le cas pour les GAFAM. En 2010, Facebook avait par exemple économisé la construction d’un datacenter à 100 millions de dollars en compilant le réseau social de PHP vers C++. Ainsi, le “green coding” et le “GreenOps” sont essentiels pour réaliser ces économies d’échelle. La virtualisation des serveurs par exemple, utilisée dans une optique d’économie peut avoir des impacts positifs importants en évitant de fabriquer ou d’alimenter des serveurs sous-utilisés.
Malgré tout, le “green coding”, ou l’utilisation de langages de programmation ou d’algorithmes peu énergivores n’est pas en soi suffisant pour résoudre le problème des impacts de premier ordre. En effet, le problème de fond est aussi intimement lié à la manière de concevoir les logiciels. En particulier, dans le cadre des services numériques, nous avons assisté durant ces dernières décennies à une tendance de centralisation sur le Cloud, portée par l’augmentation de la puissance des réseaux et des serveurs. Les services sont donc pour la plupart développés en misant sur la puissance des infrastructures IT, ce qui explique l’augmentation rapide de la part d’énergie nécessaire en 2030 pour la partie datacenter (“Compute” + “Storage” + “DC infrastructures”) et la partie réseau/télécom (“Fixed networks” + “Mobile network” + “Network equipment use”) sur la figure ci-dessus.
Il faut donc admettre qu’une grande partie du est lié à notre dépendance massive au Cloud (réseaux + data centers). L’utilisation de langages de programmation peu énergivore est un axe d’optimisation, mais s’il réduit nos capacités à se dégager de notre dépendance au Cloud (par exemple en réduisant les capacités d’arbitrage des métiers comme expliqué plus haut), alors ces langages de programmation et ces optimisations auront un impact limité au final. C’est ce que j’essaye d’expliquer de manière humoristique avec la question suivante.
QUESTION : pour économiser de l’énergie, faut-il mieux envoyer un email en utilisant le langage de programmation Python, ou en utilisant Rust ? (*)
RÉPONSE : il vaut mieux ne pas envoyer d’email !
(*) Python est considéré comme un langage énergivore alors que Rust est peu énergivore, mais l’impact d’un email envoyé est d’un ordre de grandeur nettement supérieur à l’impact qu’il faut pour l’envoyer, quel que soit le langage utilisé.
Le phénomène de sur-consommation énergétique lié à la dépendance au Cloud, s’auto-amplifie malheureusement car il pose des problèmes de sécurité complexes. En effet, la protection des bases de données centralisées nécessite des mécanismes de sécurité de plus en plus complexes, et régulièrement mis-à-jour (patchs de sécurité), le fuitage de ces données critiques et/ou personnelles étant la bête noire des DSI et des organisations gouvernementales. Par exemple, la mise en place de protocoles d’authentification et d’autorisation (OAuth2, 2FA) augmente le trafic indépendamment du nombre d’usagers. Les mises à jour logicielles fréquentes, souvent déclenchées par des patchs de sécurité, induisent un trafic important, pourtant lié à aucun usage fonctionnel particulier. Et au-delà de la sécurité, il faut prévoir la redondance de ces données, la gestion des contraintes GDPR (avec l’archivage des preuves), l’archivage des données pour des raisons légales, etc.
Comment réagir face à ces constats?
Face à la complexité du problème, certains proposent des approches de green coding ou des innovations permettant de réduire l’impact énergétique des langages de programmation. Malheureusement, ces approches, même si elles sont utiles, sont limitées par essence, ce qui entraîne beaucoup d’acteurs à demander une sobriété numérique généralisée. Cette sobriété ne semble pas non plus raisonnable, car le numérique bien utilisé et bien conçu est générateur d’impacts positifs.
Avec le projet Daquota, nous proposons une approche que nous espérons à la mesure de l’ampleur des difficultés à résoudre. Cette approche s’appuie résolument sur une logique d’éco-conception qui doit être globale et systémique pour prendre en compte tous les types d’impacts. Nous pensons que cela n’est possible qu’en ré-intégrant les métiers et leurs arbitrages dans la boucle des projets, donc en évitant les silos entre les métiers et la technique (en particulier la sécurité), grâce à un continuum no-code/low-code tel que celui que nous proposons dans Daquota. Cela n’exclut en rien l’intégration d’une dimension green coding et Daquota a été conçu pour être facilement transposable dans des environnements natifs avec des langages de programmation bas niveau et à faible empreinte énergétique.
De plus, conscients qu’une grande partie du problème est posé par une dépendance accrue au Cloud, avec toutes les conséquences que cela implique, nous proposons avec Daquota une approche complémentaire (et quelquefois alternative), qui permet de concevoir les applications collaboratives avec des données locales. Cette approche “Local First“, implique de nombreux avantages en termes d’éco-conception.
Déférer la synchronisation pour économiser de l’énergie. Le Local First permet de minimiser l’empreinte énergétique du trafic réseau en ne synchronisant que lorsqu’un réseau basse énergie est à portée (typiquement un réseau 4G consomme 10 fois plus d’énergie que la fibre par utilisateur). Un exemple de synchronisation basse énergie est proposé par défaut dans Daquota.
Utiliser la synchronisation pour lisser le trafic et mieux dimensionner les infrastructures. Avec le Local First, on peut facilement lisser le trafic via des quotas ou des règles de mise à jour en heures creuses. Le lissage du trafic permet d’éviter les pics qui impliquent souvent de sur-dimensionner les infrastructures (réseaux et data centers), et donc une surconsommation de ressources matérielles et énergétiques liées à des équipements ou des serveurs utilisés à bas régime (par exemple, une antenne relai est généralement dimensionnée pour être en moyenne à 60% de charge).
Privilégier le travail déconnecté quand c’est possible pour économiser la batterie de terminaux utilisateurs. D’un point de vue des terminaux utilisateurs, le travail en local permet de moins solliciter la liaison WIFI ou 4G, ce qui est un poste important de stress de la batterie. Ainsi, en réduisant la dépendance au Cloud, Daquota a un impact positif sur la durée de vie des batteries des terminaux mobiles, ce qui est l’un des sujets principaux d’obsolescence.
Proposer une sécurité avec une approche “by design” plutôt que d’ajouter des mécanismes contraignants et coûteux. D’un point de vue de la sécurité, Daquota évite la dépendance à un serveur central délicat à sécuriser et permet le cryptage de bout. La sécurité de certaines informations personnelles est donc assurée par défaut et la sécurisation des serveurs et des protocoles d’authentification/autorisation devient moins critique, ce qui permettrait à terme de minimiser les mises à jour liées à la sécurité et d’alléger les protocoles de manière générale.
Partitionner plus naturellement les données et mieux maîtriser les cycles de vie. Enfin, l’approche “Local First” permet d’envisager une meilleure maîtrise des cycles des données avec une notion de propriété et de partage intrinsèque et “by design”. Cette organisation permet potentiellement de rapidement nettoyer ou archiver les données mortes (arbitrages à la main des métiers). L’objectif à terme est de proposer des outils pour les “Workflow Local-First”. Voir l’exemple de gestion des demandes GDPR et le cours Local First que j’ai donné au CNAM.
Conclusion et perspectives
Daquota n’est pas une fin en soi. C’est un outil qui joue sur le low-code et la minimisation des dépendances au Cloud pour promouvoir et aider l’éco-conception. Cependant, Daquota ne dispense pas de la nécessité d’inscrire les projets dans une logique d’éco-conception, ce qui nécessite une approche systémique globale et une analyse conséquentielle.
Nous espérons que Daquota puisse être adopté comme un outil participant à l’éco-conception des services numériques, avec à la clé des impacts d’ordres supérieurs positifs pour le RSE des entreprises et s’étendant rapidement sur tous les serveurs de l’économie.
La solution ne vient pas de la technologie, mais elle vient de la manière dont on choisit de l’utiliser.
Un Technophile souhaitant garder l’anonymat sur les réseaux sociaux 😉
Sans être technosolutioniste (la solution ne vient pas de la technologie, mais de la manière dont on l’utilise), nous pensons que le positionnement de Daquota apporte une note d’espoir dans un contexte environnemental pour le moins compliqué et peu réjouissant sur beaucoup d’aspects.