Nous l’avons vu dans les deux premiers articles de cette trilogie: la question du libre accès à l’information date d’avant l’ère informatique. Cette question, qui s’est transformée en obligation pour les acteurs ayant trait au service public, doit bénéficier d’une réponse adaptée. En France, la plateforme “data.gouv.fr” joue un rôle central en permettant aux administrations de publier et de partager leurs données de manière transparente avec le public. Cependant, pour garantir une publication de qualité et exploitable, les contributeurs doivent entre autres suivre trois étapes importantes.
Midjourney, prompt : A technical drawing of a computers and databases network. A pole with a French flag is located in the middle.
Étape 1 : Mise en gouvernance des données et des produits
La première étape du processus consiste à identifier les ensembles de données à publier, ou plutôt, vu que la règle est la publication, et l’exception est la rétention, identifier quelles données ne pas publier.
Cela suggère un prérequis important : Connaitre son patrimoine des données. Dans ce cas de figure, être capable de déterminer exhaustivement et explicitement quelles données possèdent des caractéristiques empêchant leur publication en open data (telles que des données personnelles ou des atteintes à la sûreté de l’État).
Un autre sujet important est celui de la connaissance et de la maitrise du cycle de vie des données. Où la donnée est-elle créée dans le Système d’Informations ? Où la récupérer dans son état le plus consolidé et certifié en termes de qualité ? A quelle fréquence la donnée devient-elle obsolète ?
Enfin, et sujet tout aussi majeur : quelle est la notion « Métier » (Ou « Réelle ») portée par cette donnée ? Quelle information interprétable et exploitable dans différents cas d’usages recouvre-t-elle ? En somme, quelle est sa définition ?
Afin d’arriver à cette connaissance et cette gestion systématique et qualitative des données, c’est toute une organisation qui doit être transformée, dotée de rôles et de processus adéquats. Et si l’Open Data est une bonne raison de se lancer dans une telle démarche, de nombreuses externalités positives (Par exemple, fiabilisation d’indicateurs, réduction du temps de traitement/recherches de données) sont à anticiper pour l’ensemble de ses usages basés sur les données, donc pour l’activité de la structure.
Enfin, un angle pertinent pour amorcer une transformation peut être de considérer le jeu de données à publier comme un « Data Product ». Même s’il n’y a pas de finalité financière directe attendue de la publication en open data, il est bénéfique de penser au jeu de données comme un produit. Responsabiliser des collaborateurs, tels que des Data Product Managers, autour de leur conception ou de leur suivi, au-delà des données qui les composent, permet d’aller vers une véritable gestion d’un portefeuille open data. La structure peut alors traiter les données comme un actif, et les produits qui en résultent permettent d’activer leur valeur.
Midjourney, prompt : An orchestra conductor in front of a computer assembly
Étape 2 : Préparer son jeu de données
Nous identifions les données, assurons leur qualité et déterminons leur point d’accès. C’est un bon début, mais il reste encore quelques étapes techniques avant de procéder au chargement des données.
Une des obligations légales de l’Open Data est de proposer un format exploitable par machine.
Data.gouv.fr détaille la liste des formats de fichier adéquats :
Formatage des Données : Les données doivent être formatées de manière à être facilement accessibles et exploitables par le public. Il est recommandé d’utiliser des formats ouverts et standardisés tels que CSV, JSON ou XML. Les données doivent également être bien structurées, avec des en-têtes explicites pour chaque information.
Documentation des Métadonnées : Nous devons accompagner chaque ensemble de données de métadonnées détaillées. Les métadonnées fournissent des informations essentielles sur les données, telles que la description de l’ensemble de données, la source, la fréquence de mise à jour, les licences d’utilisation, et les balises (tags). Ces informations, qui décrivent les données que l’on veut publier, permettent d’en assurer le suivi, la traçabilité, et de faciliter leur recherche, consultation, et réutilisation.
Organisation et Schémas de données : En parallèle de ces aspects techniques, les notions d’organisation et de schéma sont importantes à prendre en compte pour assurer une publication de qualité. L’organisation va permettre d’identifier un acteur (Une personne morale, une entreprise, un service de l’état), et de publier des jeux de données depuis plusieurs comptes « en son nom ».
La proposition et l’adoption d’une nomenclature particulière pour un type de données qui sera fréquemment mis à jour ou régulièrement complété par d’autres acteurs constituent le schéma de données. Par exemple, si des communes commencent à publier des jeux de données sur l’installation de défibrillateurs dans les lieux public, il existe un grand intérêt à converger vers un schéma de données commun afin de valoriser l’information.
Étape 3 : Publication des Données sur Data.gouv.fr et suivi
En fonction du type de données, de leur taille, de la fréquence de mise à jour de l’informations, il existe plusieurs possibilités pour les publier.
Du dépôt manuel de données à la mise à disposition par API , ou à l’import automatique en moissonnage, ces différents itinéraires techniques sont à examiner pour chaque situation, avec possibilité de consulter les collaborateurs administrateurs de datagouv.fr
En première partie, nous avons vu que dès les premières réflexions et bien en amont de la première publication, il est essentiel de penser à l’aspect « pérenne » d’un jeu de données, en commençant par une démarche de gouvernance des données. Il existe cependant un suivi possible à postériori, sur l’utilisation et la réutilisation des jeux de données. Là encore la plateforme datagouv.fr permet aux organisations d’accéder à des statistiques sur l’exploitation des données qu’elles mettent en Open Data.
Midjourney, prompt : A golden and shiny computer
Encore récent, et pour l’instant souvent « contraint », le sujet de l’Open Data pourrait voir un basculement de paradigme dans les années à venir. L’ensemble des acteurs socio-économiques pourraient s’engager à partager des connaissances, ce qui pourrait être inscrit comme un objectif RSE. Et au-delà de penser l’open data comme un centre de coût du fait de l’activité nécessaire à la mise à disposition des jeux de données, les acteurs économiques légalement contraints à la publication pourraient également en faire un centre de profit en tant que ré-utilisateurs.
“as Prompt” va-t-il devenir la norme ?
“as Prompt” va-t-il devenir la norme ?
15 avril 2024
Architecture d’entreprise
Clément Lefranc
Senior Manager Architecture
Impulsées par l’avènement du Cloud et du DevOps, les mouvances “as Code” et “Software Defined X” ont grandement amélioré la gestion du cycle de vie des assets informatiques (infrastructure, middleware, serveur d’application, …) avec principalement :
L’Infrastructure as Code (IaC),
La Configuration as Code,
Nous détaillerons dans un futur article le positionnement de chacun et les grands paradigmes en présence (procédurale vs déclaratif), qui reposent sur une caractéristique commune: l’utilisation de template/playbook au format normalisé (HCL, YAML, …) décrivant l’état final à atteindre ou le moyen d’y aller.
Même si la syntaxe est Human Readable, il peut être fastidieux à l’échelle d’un SI enperpétuelle évolution d’écrire et de mettre à jour ces fichiers de description.
Bien qu’il existe de plus en plus de plateformes simplifiant la création de ceux-ci sur base de conception visuelle en LowCode/NoCode ou de schématisation…Que diriez-vous de troquer d’un point de vue utilisateur le ”as Code” par du ‘as Prompt” ?
#GenAI à la rescousse
Le terrain de jeux des Large Language Models (LLM) et de la GenAI ne cesse de croître, en n’oubliant pas au passage l’ingénierie logicielle.
Imaginez pouvoir simplement demander “Provisionne un cluster de VM EC2 avec NGINX en exposition publique ainsi qu’une base Elasticache” pour voir votre souhait exaucé instantanément.
D’ailleurs, n’imaginez plus, car l’Infrastructure as Prompt (IaP) est déjà proposée par Pulumi AI, et bien d’autres en cours (depX) ou à venir.
Ce positionnement et les avancées rapides et significatives dans ce domaine ne sont pas étonnantes car nous sommes en plein dans le domaine de prédilection des LLMs: les langages.
Qu’ils s’agissent de langages parlés (Français, Anglais, …), de langages de programmation (Python, JavaScript, Rust), de langage de description (HCL, YAML, …), ils ont tous deux concepts fondamentaux:
Un dictionnaire, un vocabulaire, une liste de mots avec une (plusieurs) signification(s) connue(s),
Une grammaire et des règles syntaxiques plus ou moins strictes donnant un sens particulier à la suite de mots d’une phrase ou d’une ligne de fichier de configuration.
Plus le dictionnaire et la grammaire d’un langage sont dépourvus d’ambiguïtés, plus le degré de maturité et la mise en application de la GenAI et des LLMs sur celui-ci peut-être rapide.
L’Infrastructure as Prompt n’est pas une rupture totale avec le “as Code”, simplement une modernisation de l’interface “Homme-Clavier”.
En effet, peu importe le moyen (création manuelle, auto-génération via prompt) l’aboutissement de cette première étape est la disponibilité du fichier de description.
Le cœur du réacteur, à savoir la traduction du <fichier de conf> en actions pour <provisionner et configurer les ressources>, est toujours nécessaire.
A l’avenir elle pourra se révéler un parfait assistant pour faire des recommandations et propositions d’ajustement vis-a-vis de la demande initiale pour optimiser l’architecture à déployer:
Prioriser les services managés,
Prioriser le serverless,
Etre compliant avec les best practices des frameworks d’architecture des Clouders (AWS Well Architected Framework, …),
Security By Design,
RIght sizing de l’infrastructure,
Opter pour des ressources ayant une empreinte carbone et environnementale optimisées.
#La confiance n’exclut pas le contrôle
Bien que la baguette magique qu’apporte cette surcouche soit alléchante, nous ne pouvons qu’abonder les paroles de Benjamin Bayard dans son interview Thinkerview Intelligence artificielle, bullsh*t, pipotron ? (25min) : “tous les systèmes de production de contenus si ce n’est pas à destination d’un spécialiste du domaine qui va relire le truc, c’est dangereux.” Dans un avenir proche l’Infrastructure as Prompt // la Configuration as Prompt n’est pas à mettre dans les mains de Madame Michu (que nous respectons par ailleurs) qui ne saura pas vérifier et corriger le contenu de Provisioning, de Configuration ou de Change qui a été automatiquement généré. Nous vous laissons imaginer les effets de bords potentiels en cas de mauvaise configuration (impact production, impact financier, …) dont le responsable ne serait autre que la Personne ayant validé le déploiement. Impossible de se dédouaner avec un sinistre “c’est de la faute du as Prompt”.
Vous l’avez compris, la déferlante LLM et GenAI continue de gagner du terrain dans l’IT, le potentiel est énorme mais ne remplace en rien la nécessité d’avoir des experts du domaine. Le “as Prompt” se révèle être un énorme accélérateur pour l’apprentissage du sujet, ou dans le quotidien de l’expert .. qui devra avoir une recrudescence de prudence quant aux configurations qui ont été automatiquement générées.
Au cours des dernières décennies, l’évolution de la technologie a vu émerger une culture et une philosophie qui ont profondément influencé la manière dont nous développons, partageons et utilisons les logiciels et les données. Cette culture repose sur des principes fondamentaux de transparence, de collaboration et de partage. Pour faire suite à notre premier article, explicitant ce qu’était l’Open Data, nous aborderons ici l’histoire de la Culture Open Source et expliquerons en quoi l’open data en découle naturellement.
Qu’est-ce que la Culture Open Source ?
La culture open source est un mouvement qui promeut l’accès ouvert et le partage de logiciels et de ressources, permettant à quiconque de consulter, d’utiliser, de modifier et de distribuer ces ressources. Cela contraste avec le modèle de développement de logiciels propriétaires, où les entreprises gardent le code source secret et limitent les droits de modification et de distribution. Bien que le terme « open source » ait été popularisé au début des années 2000, les principes qui le sous-tendent remontent beaucoup plus loin dans l’histoire de l’informatique.
La Culture Open Source repose sur plusieurs principes clés :
Longtemps considérée comme une culture ne renfermant que des geek et informaticiens, l’Open Source s’est démocratisée et se retrouve dans de nombreux outils que nous utilisons tous (VLC, Mozilla Firefox, la suite LibreOffice, 7Zip…). Le partage des logiciels Open Source est favorisé par des plateformes de centralisation dont la plus connue est GitHub. Malgré une réputation de visuel dépassé et d’une utilisation parfois laborieuse et incomplète, le logiciel Open Source est souvent considéré comme plus sûr car ses failles sont rapidement identifiées, les mises à jour disponibles et l’adaptabilité favorisé (on n’est pas obligé de mettre à jour constamment son logiciel si on ne le souhaite pas, gardant ainsi la possibilité ou non d’ajouter des fonctionnalités).
Image générée par Midjourney: A picture of an orange firefox wrapped around an orange and silver traffic cone
L’Histoire de la Culture Open Source
L’histoire de la culture open source remonte aux débuts de l’informatique moderne. En effet, dans les années 1950 et 1960, les chercheurs construisaient souvent les premiers ordinateurs en tant que projets collaboratifs, et ils partageaient librement des informations sur la conception et le fonctionnement de ces machines, considérant le partage d’informations comme essentiel pour faire progresser la technologie.
L’une des premières incarnations de la culture open source telle que nous la connaissons aujourd’hui est le mouvement du logiciel libre, lancé par Richard Stallman dans les années 1980. Stallman a fondé la Free Software Foundation (FSF) et a développé la licence GNU General Public License (GPL), qui garantit que les logiciels libres restent accessibles à tous, permettant la modification et la redistribution. Cette licence a joué un rôle crucial dans la création d’une communauté de développeurs engagés dans le partage de logiciels.
Dans les années 1990, le développement de Linux, un système d’exploitation open source, a été un événement majeur. Linus Torvalds, son créateur, a adopté la philosophie du logiciel libre et a permis à des milliers de développeurs du monde entier de contribuer au projet. Linux est devenu un exemple emblématique de la puissance de la collaboration open source et a prouvé que des logiciels de haute qualité pouvaient être produits sans les restrictions du modèle propriétaire.
Plus récemment, le sujet de l’open source apparait comme un marqueur majeur de différenciation entre les différents acteurs AI :
Si l’on regarde du côté de l’entrainement de différents moteurs, une majorité des acteurs de l’IA utilise des données publiques issues d’espace de stockagedisponible tels que CommonCrawl, WebText, C4, BookCorpus, ou encore les plus structurés Red Pajama et OSCAR.C’est lorsque l’on observe l’usage et la publication des résultats que plusieurs stratégies s’opposent.
Le leader de l’IA générative Open AI a un positionnement “restrictif” dans la publication de ses avancées, au motif de protéger l’humanité de publications trop libre de sa création. Cela a par ailleurs contribué au feuilleton médiatique récent qui a secoué la direction de la structure.De l’autre côté du spectre, nous avons Mistral AI, que nous avons eu l’occasion de présenter auprès des journalistes de Libération et du site internet d’Europe 1. En effet, celle-ci propose l’ouverture totale de l’ensemble des données, modèles et moteurs, dans une orientation typiquement Européenne (Data Act).
Les données ouvertes dans l’histoire
Le développement de cette culture open source, par le développement des outils informatiques, marque le vingtième siècle. Mais l’humanité n’a pas attendu ces progrès technologiques pour se poser des questions sur la libre diffusion des connaissances.
Au premier siècle avant JC, Rome édifie une bibliothèque publique au sein de l’Atrium Libertatis, ouverte aux citoyens.
De plus, si le moyen-âge marque une restriction des accès aux livres pour la population, de nombreux ouvrages restent accessibles à la lecture, mais pas encore à l’emprunt ! Les livres sont attachés aux tables par des chaînes, et l’on trouve dans certaines bibliothèques des avertissements assez clairs : « Desciré soit de truyes et porceaulx / Et puys son corps trayné en leaue du Rin / le cueur fendu decoupé par morceaulx / Qui ces heures prendra par larcin » (voir plus)
Enfin, plus récemment, la révolution française provoque des évolutions significatives dans la diffusion des connaissances, et cette ouverture à tous des données: la loi fixe maintenant l’obligation de rédiger et de diffuser au public les comptes rendus des séances d’assemblées.
Qu’il s’agisse de processus de démocratisation, ou simplement d’outil de rayonnement culturel, on voit donc que la question du libre accès à l’information ne date pas de l’ère de l’informatique.
Image générée par Midjourney: A picture of an antic roman library, with people dressed in toga. There is several modern objects like computers and screens on tables.
L’Open Data : Une Conséquence Logique
L’open data est une extension naturelle de la culture open source. Cependant, comme nous l’avons déjà présenté dans notre premier article, l’Open Data est un concept qui repose sur la mise à disposition libre et gratuite de données, afin de permettre leur consultation, leur réutilisation, leur partage. Elle repose sur des principes similaires à ceux de l’open source, à savoir la transparence, la collaboration et le partage.
L’open data présente de nombreux avantages. Il favorise la transparence gouvernementale en rendant les données gouvernementales accessibles au public. Cela renforce la responsabilité des gouvernements envers leurs citoyens. De plus, l’open data stimule l’innovation en permettant aux entreprises et aux développeurs de créer de nouvelles applications et solutions basées sur ces données.
Par exemple, de nombreuses villes publient des données ouvertes sur les transports en commun. Cela a permis le développement d’applications de suivi des horaires de bus en temps réel et d’autres outils qui améliorent la vie quotidienne des citoyens.
En conclusion, la culture de l’Open Source repose sur des principes de transparence, de collaboration et de partage. Tout cela a permis la création de logiciels de haute qualité et l’innovation continue. L’open data, en tant qu’extension de cette culture, renforce la transparence, l’innovation et la responsabilité gouvernementale en permettant un accès libre aux données publiques et privées. Ensemble, l’open source et l’open data façonnent un monde numérique plus ouvert, collaboratif. Par conséquent, cette culture est quasi omniprésente de nos jours, en 2022, selon un rapport Red Hat. 82 % sont plus susceptibles de sélectionner un fournisseur qui contribue à la communauté open source. De plus, 80 % prévoient d’augmenter leur utilisation de logiciels open source d’entreprise pour les technologies émergentes.
Merci d’avoir pris le temps de lire ce second article de notre trilogie consacrée à l’open data. Retrouvez-nous prochainement pour le dernier tome, consacré aux modes opératoires et aux bonnes pratiques de la publication de données en open data.
Écoconcevoir des services numériques ce n’est pas (que) faire du Green Code !
Écoconcevoir des services numériques ce n'est pas (que) faire du Green Code !
Aujourd’hui, on entend de plus en plus parler de Green IT et de Numérique Responsable. Une des composantes principales de ces concepts vise à faire de l’écoconception dans le secteur du numérique (équipement ou logiciel).
Pourquoi faire de l’écoconception ? Quand doit-on le faire ? Qui est concerné ? Comment écoconcevoir concrètement nos services numériques ? Cet article a pour but de répondre à ces questions et briser quelques mythes qui circulent.
Qu’est ce que l’écoconception ?
L’écoconception dans le numérique, c’est concevoir des produits, services et équipements avec une démarche préventive consistant à intégrer la protection de l’environnement dès l’expression du besoin.
L’écoconception des services numériques n’est pas uniquement une recherche d’optimisation, d’efficience ou de performance mais une réflexion plus globale sur l’usage des technologies afin qu’ils soient le plus sobre possible.
Concrètement elle a pour objectif de réduire la consommation de ressources informatiques et l’obsolescence des équipements (augmenter la durée de vie), qu’il s’agisse des équipements utilisateurs ou des équipements réseau ou serveur.
On pourrait également parler d’éco-socio-conception qui ajoute la prise en compte de l’ensemble des utilisateurs du service numérique. On intègre alors des éléments d’e-accessibilité et d’inclusion numérique. Car pourquoi s’occuper de la planète et pas de ses habitants ? Nous publierons un article sur la socio-conception prochainement afin de montrer pourquoi cela nous concerne tous et comment prendre en compte la performance sociale dans nos projets.
Pourquoi parle-t-on de l’écoconception ?
Pour répondre à cette question, il est dans un premier temps important de faire face à ces constats concernant l’impact du numérique dans nos vies et sur l’environnement :
En 2022, un Terrien aurait en moyenne 8 équipements numériques contre 15 pour un Français (dont 10 écrans) selon l’ADEME. Il y a 10 ans ce chiffre était de 6,5. De plus, en 2018, il y avait 34 milliards d’équipements numériques sur Terre. Ce chiffre en augmentation constante se rapprocherait des 50 milliards en 2023.
Pour fabriquer ces différents équipements numériques, cela nécessite beaucoup de ressources naturelles. Par exemple, pour fabriquer un ordinateur de 2kg, cela nécessite 800kg de ressources naturelles (600kg minéraux, 200kg d’énergies fossiles) selon l’ADEME. Dans ces 800kg ne sont pas comptés les milliers de litres d’eau utilisés pour les différents processus industriels.
Aujourd’hui, un français change de téléphone tous les 2 ans. L’obsolescence en est la cause. Qu’elle soit technique avec des terminaux moins robustes et des services demandant toujours plus de performances, ou qu’elle soit psychologique avec l’envie d’avoir un appareil à la pointe, pas beaucoup plus performant mais vendu comme tel.
Derrière chaque nouvelle technologie se trouvent divers effets rebond. L’effet rebond désigne un phénomène observé lorsque les économies d’énergie attendues avec l’utilisation d’une ressource ou d’une technologie plus efficace énergétiquement ne sont pas obtenues, voire aboutissent à des sur-consommations, à cause d’une adaptation des comportements. Voici un exemple ci-dessous illustrant l’effet rebond causé par l’adoption de la 5G.
Explication de l’effet rebond : Exemple du passage de la 4G à la 5G
Dans ce diagramme n’apparaissent pas les multiples autres effets rebonds causés par le 5G comme l’obsolescence perçu d’un téléphone avec une antenne qui nous en fait racheter un nouveau, ce qui veut dire qu’il faut fabriquer une puce 5G, qu’il faut que le territoire soit couvert donc que des travaux soient menés pour installer des antennes 5G, elles même fabriquées et pas en France, etc.
Les équipements numériques sont donc le plus gros problème. En France, l’étape de fabrication représente 80% de l’empreinte carbone du numérique selon GreenIT.fr contre 44% dans le monde. Cependant, l’étape d’utilisation reste nécessaire à aborder car elle est de plus en plus hors de contrôle.
En 2023, entre 10% et 15% de l’électricité mondiale alimente le numérique et cela ne cesse d’augmenter. En France, notre énergie est certes en majorité décarbonée donc on pourrait se dire que ce n’est pas notre sujet. Cependant, la pollution et le réchauffement climatique n’ont pas de frontières et certains de nos voisins, parfois même très proches, ne produisent pas tous de l’énergie en majorité décarbonée donc nous en subissons également les conséquences. De plus, beaucoup d’entreprises françaises hébergent leurs données dans le monde entier que ce soit dans des data centers on premise ou sur le cloud.
D’après une agrégation d’étude effectuée par Statista, le volume de données échangées est passé de 6,5 Zettaoctet en 2012 à 97 Zettaoctet en 2022 (sachant que 1 Zo = 1 milliard de To). Ce chiffre devrait certainement atteindre les 181 Zettaoctet en 2025. Il est donc impératif de repenser nos usages de la données.
En résumé, si l’on parle d’écoconception, c’est qu’il est nécessaire aujourd’hui de cadrer le numérique, pas seulement sur un aspect économique mais aussi d’un point de vue environnemental. Pour cela, nous pouvons agir sur plusieurs points :
Le nombre d’équipements en utilisant des équipements existants le plus possible et mutualiser les usages sur un seul et même équipement;
Leur fréquence de renouvellement en développant des services interopérables sur plusieurs générations de systèmes d’exploitation et en permettant d’utiliser son service avec le moins de performance possible (client ou serveur) afin d’éviter l’usure des composants.
Leur consommation d’électricité en faisant tout pour que le temps passé sur le service soit le plus productif possible;
Les volumes de données consommées en ne générant et conservant que des données utiles, utilisables et utilisées.
Deux mythes à briser sur l’écoconception :
Le développeur peut régler ce problème en codant de façon plus écologique !
Que veut dire “coder de façon plus écologique” ?
Cela s’apparente à effectuer plusieurs actions au niveau des paramétrages serveurs et du code afin de réduire la charge sur le serveur et donc la consommation d’énergie lors de la navigation.
Comment ? En limitant le poids des éléments, le nombre de requêtes entre le site et le serveur, etc. Un ensemble d’optimisations permettant d’améliorer les performances d’un service afin d’être moins énergivores.
Le développeur pourra bien sûr optimiser votre service mais il ne pourra pas le rendre foncièrement plus sobre. Or, l’un ne doit pas aller sans l’autre, c’est en étant plus sobre que nous améliorons d’autant plus concrètement la performance environnementale.
Et pour être plus sobre, il faut agir en amont du développement et donc en amont de la phase de réalisation, au moment de l’expression du besoin et de la phase de conception pour de meilleurs résultats. En effet, le service numérique ayant l‘empreinte la plus faible est celui qu’on ne développe pas !
Faire de l’écoconception c’est du temps et de l’argent !
L’investissement de départ en argent et en temps est un peu plus important quand on fait de l’écoconception car l’on doit constamment questionner l’utilité de telle ou telle fonctionnalité et les inscrire dans un processus durable. Cela peut prendre du temps au début. Cependant, c’est en prenant ce temps dès la conception du service que nous parviendrons à rendre cet investissement de départ marginal et un facteur de réduction des problèmes de maintenance et d’évolutivité.
Le service écoconçu cible concentrera uniquement des fonctionnalités essentielles, dans un monde où 50% des fonctionnalités développées des services numériques ne sont pas ou presque jamais utilisées. Il aura des coûts de maintenance réduits et aura à sa disposition une infrastructure adaptée au juste nécessaire et donc plus économique.
Estimation des fonctionnalités utilisées ou non dans des développements spécifiques Exceeding Value – étude effectuée par Standish Group en 2014
Enfin, il sera plus simple à maintenir et à évoluer et donc aura une durée de vie plus longue.
J’achète ! Par où commencer ?
L’écoconception s’articule autour de toutes les parties prenantes d’un projet, tout le long de son cycle de vie. En phase de conception, de réalisation, d’exploitation et de maintenance, et même en fin de vie !
Voici donc toutes les équipes concernées :
Direction
Métier
Chefferie de projet
Design
Développement et Test
Architecture Métier et Entreprise / Architecture Solutions et Applicatives / Architecture Technique et Matérielle
En phase de conception les équipes de chefferie de projet sont mobilisées avec les métiers pour établir une stratégie qui permet de déterminer et de suivre la pertinence, les enjeux et le pilotage de la conception du service numérique. Dans le cadre de l’expression du besoin et de la réponse à ce dernier, un travail sur les spécifications du service sera également à faire. Les spécifications regroupent les éléments de cadrage projet, les moyens mis en œuvre, les objectifs et contraintes du projet sur toute la durée de vie du service numérique.
Une fois les spécifications fonctionnelles établies, les équipes de design auront pour but de définir les meilleures solutions d’interactions destinées aux utilisateurs. Pour ce faire, elles devront prendre en compte tous les documents et médias informatifs ajoutés au service numérique par des personnes contributrices et disponibles pour l’utilisateur final ainsi que leurs impacts environnementaux.
Ensuite, les architectes solutions auront pour objectif de concevoir des architectures en prenant en compte en particulier l’impact environnemental des solutions choisies et surtout leur durabilité. Les architectes techniques auront pour objectif de proposer une infrastructure au juste nécessaire sans surdimensionnement et de favoriser les hébergements les moins polluants. Les architectes matériels devront quant à eux pousser l’utilisation au minimum d’équipements et si cela est obligé, qu’ils soient durables et adaptés aux besoins de l’utilisateur final.
Enfin, pendant la réalisation, l’équipe de développement devra veiller à diminuer les besoins en ressources de ce qui est développé. Le frontend étant souvent plus gourmand en ressources, une attention particulière est exigée pendant son développement.
Pendant toute la vie de nos services numériques, il est donc nécessaire de les suivre pour savoir ce qui existe dans notre portefeuille d’applications, mutualiser certaines fonctionnalités avec des futurs projets, etc.
En fin de vie du service, il est important de le décommissionner afin de réduire les coûts (et donc la consommation d’énergie), de rationaliser et sécuriser le SI et même de valoriser des équipements ou des données.
Le Référentiel Général d’Écoconception des Services Numériques (RGESN) pour agir plus concrètement
Pour aller plus loin dans la démarche d’écoconception, n’hésitez pas à vous renseigner sur le RGESN, référentiel regroupant des actions concrètes à mettre en place.
Une corde à notre arc en plus pour combattre les effets néfastes de l’activité humaine sur le monde
Écoconcevoir des services numériques ce n’est pas que faire du Green Code pour ces 3 raisons :
Il s’agit d’embarquer toutes les parties prenantes du service, au-delà du projet seulement, de l’expression du besoin par le métier jusqu’à sa fin de vie, en passant par sa conception et son exploitation. Ce serait trop simple de placer tous nos espoirs sur une seule et même équipe alors qu’il n’y a qu’ensemble que nous pourrons avoir un impact significatif.
Si ce n’était qu’une histoire de code, nos leviers d’évitement et de réduction d’empreinte environnementale seraient trop peu nombreux et le cœur de notre action ne serait constitué que d’actions d’optimisation de la consommation de ressources informatiques. On oublierait donc les principaux : l’impact des équipements numérique et les effets rebonds additionnels.
Écoconcevoir c’est surtout essayer de ne pas développer ! On développe aujourd’hui tellement de fonctionnalités n’apportant pas ou peu de valeur que l’écoconception se doit d’être un catalyseur de développements de valeurs.
En conclusion, il est aujourd’hui indispensable de se mettre en marche dans la prise en compte de la performance environnementale dans vos projets de conception et dans l’exploitation de vos services numériques. Au-delà d’une démarche citoyenne, c’est une démarche pour nous même qui a pour but de ne délivrer que de la valeur utile et non destructrice.
De plus, dans un contexte légal en constante évolution dans ce domaine, faire de l’écoconception est une manière de respecter la loi REEN et d’anticiper toute loi ou mise à jour de cette loi à venir qui pourrait obliger d’afficher l’empreinte environnementale des activités des entreprises. C’est aussi une manière d’attirer de nouveaux talents, conscients des enjeux du monde de demain, à rejoindre des entreprises engagées pour la planète.
Chez Rhapsodies Conseil, nous proposons de vous accompagner dans la mise en place d’une démarche de Conception Responsable by design dans votre organisation.
Pour faire de cette démarche une réalité, nous pouvons intervenir à plusieurs niveaux :
La sensibilisation avec l’animation de Fresque du Numérique ou Fresque de l’Accessibilité Web
La formation avec nos modules entre 1 journée et 3 jours en fonction des profils de vos équipes et leur maturité sur le sujet (Chef de projet, Designer, Développeur, Architecte, etc.)
La stratégie, construction et le déploiement d’un cadre de Conception Responsable adapté à vos processus et gouvernances existantes comme nous l’avons déjà fait dans plusieurs organisations publiques et privées.
Si cela vous intéresse, vous pouvez nous contacter !
L’Open Data est un concept qui repose sur la mise à disposition libre et gratuite de données. Cela va permettre leur consultation, leur réutilisation, leur partage. C’est aujourd’hui un enjeu majeur pour la transparence gouvernementale, l’innovation et le développement économique.
Nous allons explorer ce qu’est l’Open Data, son contexte légal et son obligation pour certains acteurs publics. Mais aussi les pratiques de mutualisation de données hybrides telles que le data sharing et les plateformes data.
Enfin, nous aborderons les enjeux organisationnels et techniques nécessaires à prendre en compte avant de se lancer dans une telle démarche.
Qu’est-ce que l’Open Data ?
Tout d’abord, l’Open Data se caractérise, entre autres, par les principes suivants :
L’Open Data et la loi
Image générée automatiquement / Midjourney: A judge in a tribunal, surrounded by datas in assembly.
En France, l’Open Data a été promu par la Loi pour une République Numérique, adoptée en octobre 2016. Cette loi impose aux administrations publiques de publier certaines catégories de données de manière ouverte, à moins que des exceptions ne s’appliquent. Ces données incluent les données relatives aux marchés publics, aux prestations et services publics, aux résultats électoraux, et bien d’autres.
Cette loi a modifié le paradigme de publication de l’Open Data. Avant, la publication était souvent conditionnée à une demande d’accès à l’administration, avec des modalités de refus spécifiques à chaque demande qui étaient encadrées par la Commission d’Accès aux Documents Administratifs (CADA). Dorénavant, la publication en Open Data devient la norme, et doit anticiper une éventuelle demande par un citoyen, une association.
Les administrations peuvent toujours choisir de ne pas publier certaines données, en justifiant par exemple que leur publication porterait atteinte à la sureté de l’Etat. Ou bien encore qu’une anonymisation des données personnelles serait un effort disproportionné ou qu’elle dénaturerait le sens des données. Il convient de préciser que la publication des documents est obligatoire uniquement pour les documents dits « achevés» (a atteint sa version finale, à date : les brouillons, documents de travail, notes préalables ne sont pas considérés comme des documents achevés), c’est à dire validés et n’ayant plus objet à évoluer.
Il est également important de noter que les articles L. 300-2 et L. 300-3 du CRPA précisent que les acteurs privés investis d’une mission de service publique sont également soumis à ces obligations de publication.
Quels usages de l’Open Data
Image générée automatiquement / MidJourney: An anthropomorphic computer ingesting data and creating charts and plots.
Un des principes de l’Open Data est de permettre le “re-use” des données, à des fins d’analyses simples ou croisées, à titre non lucratif ou commerciales.
Le site datagouv.fr permet d’inventorier toutes les réutilisations des données liées à un data set, par exemple pour le data set des parcelles et agricultures biologiques :
Sur la page « Parcelles en Agriculture Biologique (AB) déclarées à la PAC » comprenant les données issues des demandes d’aides de la Politique Agricole Commune entre 2019 et 2021, on peut trouver des utilisations de ces données par l’agence bio elle-même, par l’Institut Technique et Scientifique de l’Abeille et de la Pollinisation ou par des sociétés privées de cartographies.
Ces exemples montrent la diversité des réutilisations de données, aussi bien en termes de cas d’usage, que d’acteurs impliqués.
Autres pratiques de Mutualisation de Données
Outre l’Open Data dans le sens “Obligation légale” auprès des acteurs publics, on trouve aujourd’hui des formes hybrides qui font du partage de la donnée un sujet transverse :
Le Data Sharing
Le data sharing, ou partage de données, implique la collaboration entre différentes organisations pour partager leurs données. Par exemple, des acteurs économiques ayant un domaine d’activité similaire mais n’étant pas en concurrence directe (Verticalité de l’offre, Disparité géographique) peuvent mutualiser des donner afin d’optimiser leur R&D, ou leurs études commerciales.
Les Plateformes Data
Les plateformes data sont des infrastructures qui facilitent le stockage, la gestion et le partage de données. On les retrouve au sein de structures, qui souhaitent mutualiser le patrimoine de leurs services, voire de leurs filiales. Il s’agit souvent de créer un point de référence unique, standardisé et facilement accessible des données pour toutes les parties intéressées. Cette plateforme n’est applicable que dans certain cas de figure (plusieurs filiales d’un même groupe par exemple).
L’Open Data s’adresse donc à la fois à la sphère publique et aux acteurs privés de par les obligations légales. Mais aussi par adoption volontaire du principe, ou par exploitation de données mises en open data. Et avec les pratiques liées (plateformes de données, data sharing), on retrouve des enjeux et des risques communs.
Image générée automatiquement / MidJourney: Three books on a table, one of them is open, the two others are closed
Cet article est le premier d’une trilogie consacrée à l’Open Data, qui se conclura par les modes opératoires et les prérequis de réalisation. D’ici-là, le second tome fera office de prequel, en s’intéressant aux origines culturelles de l’Open Data, notamment l’Open Source.
J’ai pu constater régulièrement que beaucoup de gens s’emmêlent les pinceaux quand il est question de définir et d’expliquer les différences entre Service Mesh, Event Mesh et Data Mesh.
Ces trois concepts, au-delà de l’utilisation du mot “Mesh”, n’ont pas grand chose de semblable. Quand d’un côté, nous avons :
Le Service Mesh qui est un pattern technique pour les microservices, qui se matérialise par la mise en place d’une plateforme qui aide les applications en ligne à mieux communiquer entre elles de manière fiable, sécurisée et efficace
L’Event Mesh, qui est un pattern technique d’échanges, afin de désiloter les différentes technologies de messaging
Et le Data Mesh qui lui, est un pattern général d’architecture de données, qui se matérialise par toute une série d’outils à mettre en place, et qui pousse le sujet de la productification de la donnée
On se dit déjà que comparer ces trois patterns ne fait pas sens ! Néanmoins, il y a peut-être un petit quelque chose, une évidence naturelle, qui peut découler de la comparaison.
Mais commençons donc d’abord par présenter nos trois protagonistes !
Le Service Mesh, ou la re-centralisation des fonctions régaliennes des microservices
Historiquement, l’approche microservice a été motivée, entre autres, par cette passion que nous autres informaticiens avons souvent, pour la décentralisation. Adieu horrible monolithe qui centralise tout, avec autant d’impacts que de nouvelles lignes de code, impossible à scaler en fonction des besoins fonctionnels réels. Sans compter qu’on peut quasiment avoir autant d’équipes de développement que de microservices ! A nous la scalabilité organisationnelle !
Cela a abouti, de manière simplifiée bien sûr, au schéma suivant :
Chaque microservice discute avec le micro service de son choix, indépendamment de toute considération. La liberté en somme ! Mais en y regardant de plus près, on voit bien une sous-brique qui est TRÈS commune à tous les microservices, ce que j’appelle ici la “Technical Logic”. Cette partie commune s’occupe des points suivants :
La découverte de services
La gestion du trafic
La gestion de tolérance aux pannes
La sécurité
Or quel intérêt à “exploser” cette partie en autant de microservices développés? Ne serait-ce pas plutôt une horreur à gérer en cas de mise à jour de cette partie? Et nous, les microserviciens (désolé pour le néologisme…), ne serions nous pas contradictoire dans nos souhaits de décentralisation? Oui! Car autant avoir une/des équipes dédiées à cette partie, qui travaillerait un peu de manière décentralisée, mais tout en centralisant sur elle-même ce point?
C’est ainsi qu’est apparu le pattern de Service Mesh, décrit dans le schéma suivant :
Dans ce pattern, les fonctions techniques sont définies de manière centralisée (Control Plane), mais déployées de manière décentralisée (Data Plane) afin de toujours plus découpler au final son architecture. Et cela se matérialise par des plateformes comme Consul ou Istio, mais aussi tout un tas d’autres plus ou moins compatibles avec votre clouder, voire propres à votre clouder.
Maintenant que nous avons apporté un premier niveau de définition pour le service mesh, allons donc voir du côté de l’Event Mesh !
L’Event Mesh, ou la re-centralisation pour désiloter
L’histoire informatique a eu l’occasion de voir tout un ensemble de solutions de messaging différentes, avec des origines différentes. Qu’on retourne à l’époque des mainframes, ou qu’on regarde de côté des technologies comme Kafka qui ont “nourri” les plateformes Big Data, les solutions se sont multipliées. Et c’est sans compter le fait de faire du messaging par dessus du http!
On obtient donc assez facilement des silos applicatifs qui sont freinés dans leur capacité à échanger, comme montré sur le schéma suivant :
Certes, les solutions de bridge existaient, mais elles permettaient souvent de faire le pont entre seulement deux technologies en même temps, le tout avec des difficultés à la configuration et l’exploitation.
Et si on rajoute le fait qu’un certain nombre d’entreprises se sont dit qu’il serait intéressant d’utiliser les technologies propriétaires de chacun de leurs clouders, on imagine bien les difficultés auxquelles elles font face.
Est donc apparu le pattern Event Mesh, imaginé entre autre, implémenté et popularisé par l’éditeur Solace, qui permet de centraliser sur une solution unique, capable entre autres d’avoir des “agents” locaux aux SI (selon la zone réseau, le datacenter, le clouder, le domaine métier, etc…). Digression mise à part, on notera que le terme Event Mesh a été repris aussi bien par le Gartner que par des solutions open-source.
Indépendamment des architectures de déploiement, cela nous donne l’architecture simplifiée suivante :
Son intérêt vient qu’on peut ainsi relier tout le monde, y compris du Kafka avec du JMS, ou avec des API.
Le Data Mesh, décentralisation ou relocalisation des compétences ?
Le Data Mesh, de son côté, vient de son côté en réaction d’une précédente architecture très centralisée, faite de Data Lake, de Datawarehouse, de compétences BI, d’intégration via ETL ou messaging, le tout géré de manière très centralisée.
En effet, il était coutume de dire que c’est à une même équipe de gérer tous ces points, faisant d’eux des spécialistes de la data certes, mais surtout des grands généralistes de la connaissance de la data. Comment faire pour être un expert de la donnée client, de la donnée RH, de la donnée logistique, tout en étant un expert aussi en BI et en intégration de la donnée?
Ce paradigme d’une culture centralisatrice, a du coup amené un certain nombre de grosses équipes Data à splitter leur compétences, créant toujours plus de silos de compétences. De l’autre côté, les petites équipes pouvaient devenir très tributaires des connaissances des sachants métiers. Si cela vous rappelle les affres de la bureaucratie, ce serait évidemment pur hasard!
Ci-joint une représentation simplifiée de l’architecture dont nous avons pu hériter :
C’est ainsi qu’est apparu le pattern Data Mesh. Dans ce pattern, ce sont aux équipes Domaine de :
Collecter, stocker, qualifier et distribuer les données
Productifier la donnée pour qu’elle ait du sens à tous
Fédérer les données
Exposer des données de manière normée
Ce qui impose en l’occurrence de :
Mettre en place un self-service de données
Participer activement à la gouvernance globale
Et d’avoir un nouveau rôle de Data Engineer, qui doit mettre en place la plateforme de données pour justement faciliter techniquement, et proposer des outils.
Nous avons donc en schéma d’architecture le suivant :
Mais alors quid des points communs ?
Et en réalité, le gros point commun de ces trois patterns, c’est leur histoire !
Les trois proviennent de cette même logique centralisatrice, et les trois cherchent à éviter les affres d’une décentralisation dogmatique. A quoi cela sert de décentraliser ce que tout le monde doit faire, qui est compliqué, et qui en vrai n’intéresse pas tout le monde?
Et à quoi cela sert de forcément tout vouloir centraliser, alors même que les compétences/appétences/expertises/spécialisations sont elles-même “explosées” en plusieurs personnes ?
Certes, la centralisation peut avoir comme intérêt de mettre tout le monde autour de la même table, ce qui peut être intéressant pour de gros projets qui ne vivront pas, ou quand on est dans des phases d’une maturité exploratoire…
Et cela pousse tout un ensemble de principes, dont entre autre (liste non exhaustive):
Découvrabilité : Il faut pouvoir retrouver les services et les données simplement, en les exposants via des « registry » dédiés simples d’accès
Flexibilité et évolutivité : Il faut qu’une modification dans l’infrastructure ou dans un domaine puisse être accueilli sans douleur
Sécurité : Les politiques de sécurité sont propres aux champs d’actions de ces patterns, et sont donc inclus dans ces patterns
Distribution et autonomie : On distribue les responsabilités, les droits et les devoirs, afin de construire un système robuste organisationnellement
Alors oui, je vous entend marmonner “Et oui, c’est toujours la même chose! C’est comme ça”.
Mais en fait pas forcément ! En ayant en tête :
Ces éternels mouvements de yoyo,
Le Domain Driven Design qui est aussi un point commun au Data Mesh et à l’Event Mesh,
