sécurité, internet de confiance, chine, cloud souverain

Cloud Souverain & Internet de confiance – Comment copier le modèle chinois tout en garantissant les libertés individuelles ?

Cloud Souverain & Internet de confiance - Comment copier le modèle chinois tout en garantissant les libertés individuelles ?

25 septembre 2023

Thomas Jardinet

Manager Architecture

La question peut paraître saugrenue, car nous sommes habitués à dire que ce sont les chinois qui nous copient, et qu’en termes de libertés individuelles la Chine n’est pas nécessairement un modèle souhaité en France. Néanmoins, la Chine pense sur le temps long, avec une accumulation de plans quinquennaux qui au final peuvent s’étaler sur plus de 10 ans. Et le sujet de leur souveraineté numérique au sens large en fait clairement partie.

Pour revenir au sujet du cloud souverain, il est clairement d’actualité, avec l’amendement du député Philippe Latombe qui a été accepté, obligeant les opérateurs d’importance vitale pour la France à utiliser du cloud souverain plutôt que non souverain.

Mais avant de se comparer à la Chine, revenons aux basiques en retournant à l’étymologie du mot « souveraineté ».

souveraineté cloud et sécurité internet
Source : Pexels – Kevin Paster

La souveraineté, une proposition de définition.

Étymologiquement, et dans son sens premier, est souverain celui qui est au-dessus, qui est d’une autorité suprême.

Cela s’applique ainsi logiquement à un État, qui lui-même est chargé de défendre les intérêts français, que l’on parle de citoyens mais aussi d’entreprises. Citoyens, qui expriment leur souveraineté populaire (au sens rousseauiste du terme) dans le cadre d’élections.

Mais appliquons cela à ce qu’on entend alors par “cloud souverain”.

Ainsi, en déclinant cette idée de souveraineté au cloud, dont les clients potentiels sont l’état, les entreprises, les individus, il s’agit de placer l’état en garant des intérêts des citoyens et des entreprises, qui se mettent sous la coupe des lois françaises, lois assumés par tous par le mécanisme de souveraineté populaire.

cloud souverain
Source : Pixabay – The DigitalArtist

Le cloud souverain, une proposition de liste de principes.

Dis comme ça, cela reste flou. Alors soyons plus pratico-pratiques : 

Une réalité éloignée de ces principes

Or, un certain nombre de points ne correspondent pas avec les acteurs étrangers.

Alors quelle est la réponse de la Chine face à ces enjeux? 

Une utopie réaliste

Par rapport à cette liste à la Prévert, je n’invite pas à restreindre les libertés publiques mais à avoir une politique numérique très ambitieuse. Impossible n’est pas français comme je l’entendais dire dans ma jeunesse, et oui, un autre modèle est imaginable : 

Plus qu’un cloud souverain, un Internet de la confiance

Comme on peut le voir, je prends le contre pied de la Chine sur la vie privée et la confidentialité, et je cherche à démontrer que l’effort technologique n’est pas un mur infranchissable. 

L’effort pour les DSI, RSSI, architectes, consiste à sensibiliser, mais aussi à promouvoir l’usage de solutions et de clouders certifiés secNumCloud, qui soient bien de droit français. La liste est régulièrement mise à jour.

Et oui, il faut « franciser » son SI. Et/où l' »open-sourcer ». 

Sur le sujet de la sécurisation pour tous, être contre c’est être pour que n’importe qui dans la vie réelle puisse écouter ce que vous dites. On me rétorquera que la collecte d’adresse IP est nécessaire pour la lutte contre le harcèlement en ligne par exemple… Alors renforçons les pouvoirs et les moyens de la CNIL. Exigeons de nouvelles certifications plus sévères et plus contraignantes. Ce sujet de collecte d’ip pour des crimes graves (https://twitter.com/laquadrature/status/1658012087447085056) peut être la limite acceptable et contrôlable de notre vie privée et de notre sécurité. Car être contre notre sécurité et notre vie privée c’est être contre la protection de nos intérêts vitaux et économiques (https://twitter.com/amnestyfrance/status/1658449051296186369). La liberté individuelle et la liberté d’entreprendre sont ici parfaitement compatibles, elles vont même de pair. Croire l’inverse, c’est laisser la porte ouverte à tous vents, aux inconnus, aux belligérants. Et nous devons tous comprendre qu’il en va de l’intérêt général.

cloud souverain sécurité
Source : Pixabay – PixelCreatures

La souveraineté n’étant que l’exercice de la volonté générale ne peut jamais s’aliéner, et le [peuple] souverain, qui n’est qu’un être collectif, ne peut être représenté que par lui-même ; le pouvoir peut bien se transmettre, mais non la volonté.” Jean-Jaques Rousseau

Les autres articles qui peuvent vous intéresser

Le GraphQL : des usages qui s’étendent !

Le GraphQL : des usages qui s’étendent !

10 août 2023

– 5 minutes de lecture

Le GraphQL : des usages qui s’étendent !

Erik Zanga

Manager Architecture

Le GraphQL, technologie introduite il y a maintenant une dizaine d’années, permet de changer les paradigmes de l’API. Pour une présentation et une analyse plus précise, je vous invite à consulter notre précédent article écrit par Erik : https://www.rhapsodiesconseil.fr/api-graphql-on-casse-encore-tout-on-recommence/

Qu’en est-il aujourd’hui, le GraphQL est-il réellement une alternative concrète aux APIs standard ?

Mais déjà, qu’est-ce que le GraphQL ?

Le GraphQL se définit par la mise à disposition d’une interface de “requêtage” qui s’appuie sur les mêmes technologies d’intégration / les mêmes protocoles utilisée par les API REST.

Ici, nous restons sur le protocole HTTP et par un payload de retour (préférablement au format JSON) mais la différence principale du GraphQL, pour le client, repose sur le contrat d’interface.

Le contrat d’interface façon GraphQL devient variable, tout comme la réponse. En effet, dans la requête nous pouvons spécifier ce que nous souhaitons recevoir exactement dans la réponse.

Nous mettons ainsi le doigt sur un gros avantage de cette interface GraphQL qui, par essence, va grandement diminuer le “overfetching et le “underfetching” (comprendre ici le fait de récupérer trop peu ou au contraire trop d’informations jugées inutiles dans le contexte) d’API

Autre avantage, ce besoin en données spécifiques pourra être différent à chaque appel et donc permettre une grande flexibilité d’usages à moindre effort.

Le GraphQL s’est fait sa place !

A l’époque de l’écriture de notre premier article, le GraphQL commençait à s’introduire dans certains cas d’usage, très souvent en mode POC et découverte, avec un concept attrayant mais sans preuve réelle de plus value.

Aujourd’hui nous observons une vraie adhésion à ce nouveau mode d’interfaçage, bien que nous en constatons encore des points d’amélioration.

Ce qui est intéressant à remarquer est qu’il se développe sur des métiers très variés. Non seulement au niveau des éditeurs de logiciels mais également dans le cadre de développements spécifiques, de plateformes dédiées.

Les usages à date : quelques exemples

Netflix, qui utilise le GraphQL pour unifier les accès aux différentes APIs.Dans le retail, Zalando, pour récupérer les informations sur les différents produits et pour gérer les consentements.MonEspaceSanté, le service lancé par l’ANS en début d’année, et qui effectue de requêtes GraphQL à partir du navigateur.

Le GraphQL comme réponse à un besoin d’uniformisation ?

Avant la naissance du GraphQL, le besoin d’uniformisation de ce type d’interaction était dans la ligne de mire de certains acteurs. Aujourd’hui le GraphQL peut apporter une réponse concrète et standardisée à ces problématiques.

Deux exemples d’envergure : 

Microsoft : Microsoft a par le passé essayé de fournir des APIs “flexibles” pour adresser certains cas d’usage. Cette tentative s’est matérialisée par la création de l’OData et de l’API Microsoft Graph. 

Ne vous trompez pas, l’objectif reste similaire mais l’approche est, à ce stade, différente. Dans une logique d’uniformisation et standardisation, nous voyons difficilement Microsoft s’affranchir d’une réflexion autour du GraphQL pour atteindre ces objectifs.

Salesforce : Salesforce propose également depuis plusieurs années, une API bas niveau qui pourrait, par ses caractéristiques et son besoin de flexibilité, être adaptée à la technologie GraphQL.

Constat actuel sur les usages du GraphQL

Quand nous regardons les cas d’utilisation de GraphQL, nous pouvons constater qu’il est majoritairement utilisé côté Front-end. 

En lien avec ce cas d’utilisation, nous observons également que le GraphQL est souvent vu comme un agrégateur d’API, et pas comme un moyen de requêtage directement lié à une vision pure données. 

Mais pourquoi ce type d’usage ?

Nous listons trois arguments principaux pour expliquer la prédominance de ce type de cas d’usage.

  1. La restitution de format est très adaptée au monde du web : une réponse simple, toujours vraie et personnalisable ; le protocole HTTP et des concepts proches des APIs REST, le GraphQL s’adapte très bien aux couches front.
  1. Chaque API derrière GraphQL gère son propre périmètre, si nous faisons la correspondance avec les architectures DDD (Domain-Driven Design), nous pouvons affirmer que l’API bas niveau adresse un domaine particulier, alors que le GraphQL est là pour pouvoir “mixer” ces différents concepts et donner une vision un peu plus flexible et adaptée à chaque cas d’usage. Dans ce cas nous allons faire de l’overfetching sur les couches bas niveaux, et faire un focus utilisation au niveau de la partie frontale.
  1. Le cache, éternelle question autour du GraphQL. Dans ce cas d’usage le cache reste possible au niveau des APIs de bas niveau, qui iront donc moins solliciter les bases de données, alors que sur la couche GraphQL, de par sa variabilité de réponse, nous en avons peut-être moins besoin. Pour rappel, le cache sur une requête GraphQL, bien que possible, devient naturellement plus complexe à gérer et donc perd un peu de son intérêt. 

Pourquoi ne faut-il pas limiter le GraphQL à ces usages ?

Pour nous, c’est notre conviction, le GraphQL a de nombreux atouts et doit se développer sur ces usages de prédilection, mais pas que !

UN ARGUMENTAIRE FORT : L’ACCÉLÉRATION DE LA CONCEPTION !

Un des grands atouts de la mise en place d’une API GraphQL reste le côté, si vous m’autorisez le terme, “parfois pénible” de la définition des API Rest : des discussions infinies entre le métier et l’informatique pour définir ce dont nous avons besoin, le découpage, etc.

Une API GraphQL par définition n’a pas une structure ou un périmètre de données définis, mais s’adapte à son utilisateur.

Le GraphQL comme moyen d’accélérer les développements ? 

UNE DISTINCTION CLAIRE : ATTENTION AUX CAS D’USAGE !

Nous ne visons certainement pas tous les cas d’usages, mais l’objectif ici est de casser un peu certains mythes.

Si utiliser des mutations (en gros l’équivalent de l’écriture) intriquées, nous l’avouons, peut être très complexe, dans les cas de requêtage de bases de données ayant comme objectif principal l’exposition en consultation, nous disons “pourquoi pas !”. 

Vous auriez probablement reconnu le pattern CQRS, avec, par exemple, une Vision 360 Client qui expose les informations avec une API GraphQL.

CÔTÉ TECHNIQUE

Les améliorations dans la gestion des caches, ces dernières années, permettent de gérer ce sujet, tout en restant plus complexe qu’avec une API REST standard. 

Attention aux autorisations

Nous n’allons pas nous attarder sur ce sujet, que nous avons déjà traité dans notre précédent article (que nous vous invitons à parcourir ici), mais nous souhaitons le rappeler car il est crucial et extrêmement critique. 

Si nous souhaitons traiter les sujets d’accès à la donnée avec une API GraphQL, une logique RBAC avec rôles et droits définis au niveau de la donnée (matrice d’habilitations rôles / droits proche de la donnée elle même) nous semble à ce stade la meilleure solution : N’AUTORISONS PAS L’ACCÈS UNIQUEMENT AU NIVEAU DE L’API, MAIS ALLONS AU NIVEAU DATA !

Conclusion

La technologie continue de s’affirmer, un standard semble se définir et s’étoffe de plus en plus. Dans un monde API qui se complexifie de jour en jour, les enjeux autour de la rationalisation et de l’optimisation des usages API restent au cœur des débats sans pour autant trouver de solution directe et efficace via la technologie REST. Et c’est encore plus vrai quand le besoin de base n’est pas clairement défini…

Le dynamisme apporté par le GraphQL, dans certains cas de figure, permet de simplifier ces discussions en apportant des réponses cohérentes avec le besoin.

Ce n’est pas une solution magique faite pour tous les usages, mais une réelle alternative à considérer dans les conceptions API.

Et vous ? Avez-vous pris en considération cette alternative pour vos réflexions API ?

Ne vous en faites pas, il n’est pas trop tard, parlons-en, ce qui ressortira de nos discussions pourrait vous surprendre.

Architecture-Entreprise-Agilite-Les-formations-Architecte-Agile

Quoi de nouveau dans la version 6 de SAFe pour l’architecte solution?

Quoi de nouveau dans la version 6 de SAFe pour l’architecte solution?

25 juillet 2023

– 4 minutes de lecture

Architecture

Thomas Jardinet

Manager Architecture

Salomé Culis

Consultante Architecture

Cet article est le deuxième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version du framework SAFe. 

Après avoir étudié le System Architect, nous allons donc voir en détail les différences pour le Solution Architect avec la précédente version de SAFe.

Une position de “pivot” de l’architecture 

Le Solution Architect, positionné entre l’Entreprise Architect et le System Architect, a cela de de particulier qu’il est un réel pivot d’architecture : 

Il n’est pas pour autant un simple passe-plat, et encore moins une boîte mail générique, mais un acteur qui doit insuffler une direction technologique à l’ensemble du SI.

Il définit ainsi une vision technique, qu’il définit, cadre, met en place et partage. C’est par exemple à lui d’identifier les futures technologies à mettre en place, et à les instancier en les industrialisant.

Mais revenons un peu à ce rôle de pivot. Il est en effet extrêmement marquant pour moi de voir une citation du livre de Donella H. Meadows “Thinking in Systems”: 

“You think that because you understand ‘one’ that you must therefore understand ‘two’ because one and one make two. But you forget that you must also understand ‘and.’ “

Cela ne vous parle peut-être pas, mais cette phrase est une très bonne synthèse (certes très raccourcie) de la théorie des Systèmes développée par l’autrice et son mari. Pensée systémique qui influença l’émergence de l’agilité, en expliquant que la complexité des systèmes se mesure dans le nombre d’acteurs et de leurs interactions.

Théorie des systèmes qui m’est personnellement très chère, considérant à titre personnel comme faisant partie de ma liste de livres à lire absolument. Cette théorie apporte en effet une grille de lecture très intéressante de l’environnement qui nous entoure, en cela qu’elle explique que nous sommes tous liés à ce qui nous entoure, et que nous réagissons par rapport à ce qui nous entoure. N’ayant pas toute la sagacité de ses penseurs, je vous laisserais creuser vous-même cette théorie qui inspire fortement entre autres les travaux du GIEC.

Et cerise sur le gâteau pour moi, certe déjà présente dans la version 5 du framework Safe, nous retrouvons l’idée de “démarche inverse de Conway”, qui consiste à calquer l’organisation sur l’architecture souhaitée, et non l’inverse. Démarche qui ferait de l’Architecte Solution un Architecte d’Entreprise qui s’ignore? Néanmoins, on retiendra que cette démarche inverse de conway fonctionne de manière plus fluide dans une organisation réellement agile et se voulant fluide, comme le recherche le framework Safe.

Et comme cette position d’architecte pivot de solution mais aussi de l’organisation ne provient pas non plus de nulle part, nous allons nous entâcher d’abord à réexpliciter son rôle.

Les responsabilités clés de l’architecte solution

Si nous devions chercher à être synthétique, nous pourrions dire que l’architecte solution est l’architecte “support” de l’Entreprise Architect en définissant avec lui la roadmap solution. 

Roadmap solution qui est aussi défini en support avec le System Architect, mais lui en apportant des facilitations, des enablers, et le déchargeant des contingences techniques transverses.

Ainsi les différentes responsabilités du Solution Architect sont les suivantes : 

Les nouvelles relations du Solution Architect

Le rôle du Solution Architect dans la version 5 était peut-être réductrice. En effet il était auparavant quasiment aggloméré avec les architectes systèmes (vision assez réductrice à mes yeux, comme si un architecte solution ou un architecte system était la même chose). Il n’avait ainsi que des échanges avec l’équipe de Solution Management.

De cette modélisation bi-latérale du rôle du solution architect, la version 6 du framework Safe jette cela par la fenêtre pour le remplacer par un rôle de pivot de 4 équipes distinctes : 

,

Le tout bien évidemment dans une logique de collaboration, et non d’une simple logique purement top-down ou bottom-up.

Si ces sujets vous intéressent…

Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.

Les articles 1 et 2 peuvent en particulier se révéler utiles : 

Et évidemment, je ne peux que vous conseiller la lecture du livre mis en référence par le framework safe 6

Quoi de nouveau dans la version 6 de SAFe pour le système architecte ?

Quoi de nouveau dans la version 6 de SAFe pour le système architecte ?

11 juillet 2023

– 5 minutes de lecture

Salomé Culis

Consultante Architecture

Cet article est le premier d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version du framework SAFe.

Nous allons donc voir en détail les différences pour le System Architect, en particulier sur les sujets d’interactions avec les autres parties prenantes et les responsabilités du System Architect.

Changement de nom pour un nouvel architecte

Un premier point qu’il est important de souligner est le changement de nom de cet acteur lors du passage à la version 6 du framework. Celui-ci passe de “System Architect / Engineering” à “System Architect”, tout simplement. 

Cela permet d’éviter une éventuelle confusion avec le Release Train Engineer ou même avec certains concepteurs fonctionnels qui sont plus proches d’un rôle de PO.

Mais ce changement de nom cache un changement beaucoup plus profond du rôle et de la posture de l’architecte système.

La compétence clé de l’architecte système, la collaboration

Dans cette nouvelle version du framework, la notion de collaboration est mise en exergue comme une compétence clé de l’architecte. 

En effet, l’architecte système collabore avec différents groupes de parties prenantes : 

Ainsi, l’architecte système doit être capable de travailler avec des acteurs très variés, de les aider à remplir leur rôle et de partager sa vision de l’architecture afin que le Train avance dans la bonne direction. 

Nous voyons ici apparaître une notion de base de l’agilité, présente dans le manifeste agile (que vous avez tous sur votre table de nuit ou encadré au-dessus de votre bureau, j’en suis certaine !). 

Cette nouvelle version du framework positionne très clairement l’architecte système comme un acteur qui sort de la tour de verre de l’architecture et va s’intégrer au quotidien dans les équipes. 

La proximité favorise la collaboration

A titre personnel, en tant qu’architecte sur un programme de refonte de la relation client, j’avais fait le choix d’aller m’installer dans l’open space avec les équipes agiles. Cela permettait de :

Au-delà des aspects cités précédemment, je me suis ainsi sentie comme faisant partie du projet à part entière. Je m’étais bien sûr assurée de garder une proximité forte avec mes collègues architectes (nécessaire pour s’aligner aux différents niveaux si vous avez bien suivi !).

Les responsabilités clés de l’architecte système

Vous vous dites peut-être que l’architecte système échange avec beaucoup d’acteurs. Et vous vous demandez peut-être en quoi consiste véritablement son rôle. 

En effet, son rôle évolue pour assumer les responsabilités ci-dessous : 

Les deux derniers points notamment impliquent un véritable changement d’état d’esprit. Le travail de l’architecte ne s’arrête pas au moment de la présentation de la Vision d’Architecture, il doit continuer à accompagner le Train opérationnellement au quotidien pour pouvoir remplir l’ensemble de ces responsabilités. 

Auparavant définies sous la forme d’une liste à la prévert, les tâches du System Architect deviennent à présent un nombre limité de responsabilités clés. 

C’est un vrai shift pour la position de System Architect. 

D’un architecte système qui s’assoit sur les “fauteuils pré-positionnés” par ceux qui ont défini le cadre de gouvernance SAFe, nous passons à un vrai acteur et “modeleur” de l’itération locale du framework SAFe. 

Il n’est pas cantonné à des tâches définies de manière top-down, mais devient un acteur/décideur/influenceur du système.

Si ces sujets vous intéressent…

Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.

Les articles 1 et 4 peuvent en particulier se révéler utiles : 

numérique durable suv

SUV et Numérique : Les 2 fléaux environnementaux de l’ère moderne

SUV et Numérique : Les 2 fléaux environnementaux de l'ère moderne

26 mai 2023

– 7 minutes de lecture

Pascal Ly

Consultant Senior Architecture

Note préalable à la lecture : ce billet d’humeur est une cascade réalisée par un professionnel de la boutade, n’essayez pas de tout interpréter au premier degré.

SUV : L’empreinte écologique qui grandit à chaque kilomètre

Arrête-moi si tu peux

Tyre Extinguishers, Extinction Rebellion, dégonfleurs de pneus, si vous n’avez jamais entendu parler de la nouvelle mode des activistes sur ces derniers mois, c’est que vous êtes à côté de la plaque !

L’objectif de ces collectifs est simple : dégonfler un ou plusieurs pneus des 4×4 et SUV pour sensibiliser les propriétaires de ces véhicules contre la pollution et le réchauffement climatique, et les inciter à favoriser les transports en commun.

Pour mener leurs actions en toute discrétion, les militants écologistes agissent habituellement la nuit, en arpentant les rues des grandes villes en quête de pneus à dégonfler. Grâce à une méthode bien rodée, ils s’attardent peu sur une voiture et partent sur les chapeaux de roues quand ils se sentent surveillés ou lorsqu’ils sont démasqués.


pollution suv

Le lendemain, les propriétaires constatent, impuissants, que leurs véhicules ont été la cible de ces justiciers noctambules. Ils découvrent un tract apposé sur leurs pare-brises qui explique la démarche du collectif, mais également pour dénoncer la pollution de ces tanks en milieu urbain.

Un acte militant qui gonfle les automobilistes

« Ne le prenez pas personnellement. Vous n’êtes pas notre cible, c’est votre véhicule »

Le message semble clair : le propriétaire n’a rien à se reprocher dans cette histoire et inutile de monter dans les tours.

Seulement voilà, le désagrément, lui, est bien présent et a de quoi irriter le conducteur qui doit utiliser son véhicule au moment de la découverte du message.

Comment l’automobiliste peut-il bien accepter cet « acte de sensibilisation » au moment où il doit prendre le volant pour son besoin professionnel ou personnel ?


suv empreinte écologique

Difficile de prendre parti pour cette cause juste lorsque vous vous sentez victime d’une injustice… Bien au contraire, la réaction sera bien souvent à l’opposé de l’effet attendu : le propriétaire aura de quoi péter une durite et se désintéresser des conséquences de sa voiture sur un plan écologique !

Les SUV, derniers de la classe ?

Certes, les SUV trustent le podium en termes d’émissions mondiales de CO2 car le nombre de véhicules en circulation ne cessent d’augmenter. Mais il est aussi important de rappeler que les voitures de sport et berline de luxe peuvent polluer jusqu’à 2 fois plus que les plus gros SUV.

En toute logique, les ardents défenseurs de l’écologie devraient poursuivre leurs activités en allant également dégonfler les pneus des jets privés ou siphonner le carburant des yachts privés, sans oublier de déposer le message de sympathie sur les vitres !


empreinte écologique suv

Il semblerait que dégonfler les pneus des véhicules ne soit pas suffisant pour retirer les SUV du catalogue des constructeurs automobiles. Au contraire, les SUV sont devenus les chouchous des Français, et représentent près de la moitié des ventes de véhicules neufs.

S U V, 3 lettres qui divisent un monde et qui font débat, à tort ou à raison.

Le militantisme bruyant est-il la seule façon de sensibiliser à la lutte contre le réchauffement climatique ?

Les actions individuelles ne pourraient-elles pas également avoir un impact significatif sur la réduction de notre empreinte environnementale ?

Au-delà des claviers et des écrans : les conséquences écologiques de notre dépendance numérique

L’empreinte numérique : un acteur méconnu de la crise climatique

Trier les déchets, consommer localement, privilégier les moyens de transport moins polluants, acheter des produits recyclés ou réutilisables, et réduire leur consommation globale : ces gestes modestes, cumulés, ont un impact significatif sur l’environnement.

Plutôt que de pointer du doigt les autres, nous pourrions tous agir de manière responsable pour réduire notre empreinte environnementale et contribuer à la lutte contre le réchauffement climatique. Il ne s’agit pas de juger les actions des uns et des autres, mais plutôt de promouvoir une prise de conscience collective, à commencer par son entourage, qui encouragera chacun à agir selon ses convictions et ses moyens pour préserver notre planète.

En particulier, il est intéressant de noter que l’utilisation croissante des objets numériques dans notre vie quotidienne a également un impact significatif sur l’environnement.

Le coût énergétique et environnemental caché de notre utilisation numérique

L’arrivée d’Internet dans nos foyers a marqué une véritable révolution numérique, et aujourd’hui, il est rare de trouver une personne qui n’a jamais été en contact avec une technologie numérique (vous visualisez bien vos grands-parents avec une tablette multimédia ?).

En 2022, Google enregistre plus de 8,5 milliards de requêtes par jour, générant ainsi un coût énergétique non négligeable à l’échelle mondiale. 

Ce Cloud-là n’est pas composé de petites gouttelettes d’eau ou de cristaux de glace, mais plutôt de racks de serveurs et d’infrastructures techniques nécessaires pour les héberger.


empreinte écologique numérique

Malheureusement, l’utilisation croissante d’objets numériques a un impact significatif sur l’environnement.

Selon l’organisation Carbon Literacy Project, un email génère entre 0,03 g et 26 g de CO2 sans prendre en compte les pièces jointes. 

Le cabinet d’études Radicati Group a révélé que chaque jour, en 2022, 333 milliards d’emails ont été envoyés dans le monde entier


pollution numérique
L’empreinte carbone en quelques chiffres

En prenant une moyenne basse de 4 g de CO2 par email, cela représente environ 486 millions de tonnes de CO2 générés pour cette année.

Imaginez l’empreinte carbone que peut générer un appel personnel ou professionnel en visioconférence !

Par ailleurs, une étude de l’ADEME a démontré que la fabrication d’un ordinateur pesant 2 kg mobilise 800 kg de matières premières, et génère 124 kg de CO² sur un total de 169 kg émis tout au long de son cycle de vie.

À partir de cette constatation, il est facile de comprendre que limiter le remplacement fréquent de nos objets électroniques, tels que les ordinateurs, les téléphones portables ou les téléviseurs, permet de réduire leur impact environnemental. 

Ensemble, réfléchissons à notre façon de consommer et prenons conscience de l’impact de nos utilisations quotidiennes des technologies numériques.

Il est important de se demander si nous avons réellement besoin de posséder plusieurs modèles d’appareils différents qui risquent souvent d’être laissés de côté. 

Alors, prêt à évangéliser cette pratique autour de vous et à faire de la place dans vos placards ?

Pascal, podomobiliste chevronné et fervent croyant de la sobriété numérique

archimate 3.2 nouveautés

Toutes les nouveautés d’ArchiMate 3.2

Toutes les nouveautés d'ArchiMate 3.2

12 avril 2023

– 4 min de lecture

Ariane Chassagne

Consultante Architecture

ArchiMate est un langage de modélisation développé par l’Open Group, basé sur les concepts TOGAF, qui permet de partager un langage commun pour décrire, analyser et visualiser l’architecture d’entreprise. Le but ?  Aider à la prise de décision des transformations de l’entreprise.

Résultat d’années de réflexions (travaux débutés en avril 2020), la nouvelle spécification ArchiMate 3.2 est publiée le 18 octobre 2022. 

L’objectif de cet article est de montrer l’exhaustivité des modifications apportées par la spécification 3.2 d’ArchiMate.

Voici une synthèse de ces modifications qui seront détaillées plus bas :

La couche physique devient un composant de la couche technologie

Jusqu’ici indépendantes, Archimate 3.2 intègre la couche Physique dans la couche Technologie.

couches physique et technologie archimate 3.2

Les modifications de la notation

Deux changements majeurs dans la notation ArchiMate sont apportés par la spécification 3.2 :

Nous avons fait le travail de synthèse des modifications de la notation dans le tableau suivant :

modifications notations archimate 3.2
Modification de la notation ArchiMate 3.2

Voici donc la nouvelle notation Archimate 3.2 :

Notation ArchiMate 3.2
Notation ArchiMate 3.2

La modification de définitions

ArchiMate 3.2 clarifie et simplifie les définitions des concepts Outcome, Constraint, Business Function, Product et Technology Interface.

Issu de la spécification ArchiMate, nous avons synthétisé l’ensemble des modifications de définitions dans ce tableau (rouge : supprimé ; vert : ajouté) :

CoucheÉlémentArchiMate 3.1ArchiMate 3.2
MotivationOutcomeRepresents an end result.Represents an end result, effect, or consequence of a certain state of affairs.
MotivationConstraintRepresents a factor that limits the realization of goals.Represents a limitation on aspects of the architecture, its implementation process, or its realization.
BusinessBusiness FunctionRepresents a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization.Represents a collection of business behavior based on a chosen set of criteria such as required business resources and/or competencies, and is managed or performed as a whole.
BusinessProductRepresents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.Represents a coherent collection of services and/or passive structure elements, accompanied by a contract, which is offered as a whole to (internal or external) customers.
TechnologyTechnology InterfaceRepresents a point of access where technology services offered by a node can be accessed.Represents a point of access where technology services offered by a technology internal active structure can be accessed.

La modification des méta-modèles

La spécification 3.2 modifie les méta-modèles des couches Business, Technologie, Physical, et des liens entre la couche Implémentation et Migration et l’aspect Motivation. 

Voici les évolutions de ces méta-modèles :


Business Composite Elements Archimate 3.2
Business Composite Elements

Technology Layer Metamodel Archimate 3.2
Technology Layer Metamodel

Technology Passive Structure Elements Archimate 3.2
Technology Passive Structure Elements

Physical Elements Metamodel Archimate 3.2
Physical Elements Metamodel

Implementation and Migration Elements with Motivation Eléments Archimate 3.2
Relationships of Implementation and Migration Elements with Motivation Eléments

En synthèse, les modifications des méta-modèles apportent les changements suivants :

Évolution des relations dérivées

Dans le but de réaliser des analyses d’impacts plus poussées, la spécification ArchiMate 3.1 avait introduit la notion de relation dérivée :

Si on a deux relations p(b,a):S et q(b,c):T avec a, b, c des éléments, p et q des relations respectivement de type S et T, alors on cherche à connaître la relation r de type U tel que r(a,c):U.

relation dérivées archimate 3.2

ArchiMate 3.1 définit :

En complément, Archimate 3.2 : 

évolution relation dérivées archimate 3.2

Conclusion

Les modifications du langage de modélisation Archimate apportées par la spécification 3.2, bien que mineures, permettent d’homogénéiser la notation, d’améliorer le méta-modèle et de supprimer des ambiguïtés par la clarification à la fois des définitions et des règles de restrictions des relations dérivées.

Pour approfondir le sujet, vous pouvez consulter la spécification d’Archimate 3.2.