L'écoconception au service de la robustesse, de la résilience et de la souveraineté

La transformation numérique a tenu toutes ses promesses… Enfin presque ! Elle a accéléré les processus, simplifié les usages, ouvert de nouveaux marchés. Mais, dans le même temps, elle a engendré une dépendance massive, entraînant une fragilité systémique. Plus nos organisations numérisent, plus elles s’exposent. Les solutions numériques sont ainsi devenues de plus en plus sensibles aux pannes, aux cyberattaques ou aux ruptures d’approvisionnement !

Face à cette réalité, les réponses sont souvent exclusivement techniques : redondance des serveurs, sauvegardes, plan de continuité, reprise d’activité, etc. Ces dispositifs sont évidemment nécessaires, mais certainement pas suffisants. Ils traitent les symptômes sans questionner la cause essentielle : la maîtrise de la complexité du système numérique lui-même.

C’est précisément là que l’écoconception apporte des réponses. Cette démarche est généralement menée pour anticiper les dispositifs réglementaires existants (loi REEN, RGESN, Stratégie nationale bas-carbone, etc.) et à venir ou comme levier d’action pour soutenir les engagements RSE et les trajectoires de réduction d’empreinte carbone. En réalité, en interrogeant la pertinence de chaque fonctionnalité, en supprimant les dépendances superflues, en favorisant les architectures sobres et interopérables, la démarche d’écoconception propose un cadre pour produire des systèmes numériques transparents, maîtrisés et durables.

Dans cet article, je vais détailler le rôle systémique de l’écoconception au service de la robustesse, de la résilience et de la souveraineté numérique.

Trois notions pour une même exigence

Robustesse, résilience, souveraineté ! Ces trois termes sont devenus tendances ces dernières années et entretiennent une certaine confusion sur leur signification. Avant de démontrer le rôle de l’écoconception, posons des définitions claires et opérationnelles.

La robustesse

Elle est souvent confondue avec la résilience. C’est pourtant une notion distincte, bien mise en lumière dans le livre blanc « Voyage vers la robustesse » d’Infogreen Factory. Elle peut être définie comme la capacité à ne pas tomber, à maintenir ses fonctions vitales, même en mode dégradé et potentiellement sans numérique.

Elle se construit en amont :

• cartographie des dépendances,
• identification des fonctions vitales,
• réduction de la surface d’exposition, y compris aux risques cyber.

Ce n’est pas une question d’infrastructure, mais plutôt de gouvernance.

La résilience

Elle est réactive. C’est la capacité à absorber un choc, à s’adapter et à se transformer après l’impact. Elle agit généralement à deux niveaux :

• technique (architectures qui tiennent la charge ou se rétablissent rapidement, plan de reprise après une cyberattaque, etc.)
• et organisationnel (adaptation des équipes, switch de processus, etc.).

Elle s’active quand un choc se produit, là où la robustesse cherche à éviter qu’il survienne.

La souveraineté

Elle est d’un tout autre ordre. Il s’agit de la maîtrise des choix qui constituent le système :

• qui contrôle les infrastructures ?
• où sont hébergées les données ?
• quelle est la capacité à changer de fournisseur ?
• quelle est la capacité à auditer les algorithmes ?
• etc.

Ces questions sont au cœur des enjeux de la cybersécurité autant que de la souveraineté. C’est d’ailleurs la logique de la qualification SecNumCloud portée par l’ANSSI. C’est un registre politique et économique, qui se joue au niveau des directions générales et des stratégies d’achat, autant qu’au niveau technique.

Ces trois notions ne forment pas une hiérarchie, ni une progression de maturité. Elles définissent des niveaux de lecture complémentaires d’un même enjeu fondamental : la capacité d’une organisation à maîtriser ses systèmes numériques face aux crises.

Le gras numérique est source de fragilité

On associe souvent la complexité numérique à la maturité d’une organisation. Un service numérique riche en fonctionnalités, interconnecté à de nombreux services tiers, hébergé sur des infrastructures redondées, ça rassure ! Ça donne l’illusion d’un système solide, bien outillé, prêt à toute éventualité.

Sauf que cette complexité est précisément ce qui rend les systèmes fragiles. Plus un système numérique accumule de composants, de dépendances et de fonctionnalités non questionnées, plus les points de défaillance se multiplient… Et plus il devient opaque, coûteux à maintenir et vulnérable en cas de choc.

Règle des 3U

L’AFNOR SPEC 2201 (référentiel de bonnes pratiques auquel Temesis a contribué) nomme ce phénomène sans détour : l’obésité numérique. Pour la diagnostiquer, le référentiel propose la règle des 3U. Un service ou une fonctionnalité doit être

• Utile (répondre à un besoin réel),
• Utilisable (accessible et efficace pour l’utilisateur)
• et Utilisé (adopté dans la pratique).

Ce qui ne satisfait pas ces trois critères est considéré comme du gras. Une double dose de gras : environnemental d’abord, stratégique ensuite.

Exemple de dépendance non maîtrisée

L’incident CrowdStrike de juillet 2024 en est une illustration saisissante. La mise à jour défectueuse d’un seul composant tiers (Falcon Sensor) a suffi à paralyser plusieurs millions de machines Windows en quelques heures à travers le monde. Probablement la panne la plus coûteuse de l’histoire de l’IT. Des hôpitaux, des aéroports, des banques, des services d’urgence se sont retrouvés hors service. Et rien à voir avec une cyberattaque sophistiquée, il s’agissait simplement d’une dépendance non maîtrisée, dont la portée n’avait pas été suffisamment questionnée :

• cette dépendance est-elle justifiée ?
• peut-on en limiter la portée ?
• que se passe-t-il si elle défaille ?

Ces questions sont au cœur de la démarche d’écoconception et auraient certainement limité (évité ?) les impacts de ce dysfonctionnement.

Cette « anomalie » n’est pas isolée et les exemples ne manquent pas : panne de CDN suite à la mise à jour de l’outil de monitoring Fastly (juin 2021), pannes AWS et Azure (octobre 2025), panne du CDN Cloudflare (novembre 2025), rupture de câbles sous-marins en mer Rouge (septembre 2025), pénurie de composants liée à l’IA (2025 - 2026), expiration du certificat racine Let’s Encrypt (septembre 2024), fin de vie de Drupal 7 (janvier 2025), etc.

Ce n’est pas en ajoutant des couches qu’on gagne en solidité. La robustesse commence par la sobriété.

De l’écoconception à la robustesse : moins de dépendances, moins de points de défaillance

La démarche d’écoconception numérique ne produit pas de la robustesse par effet de bord. Elle la produit structurellement, parce que ses principes fondamentaux (questionner l’utilité, supprimer le superflu, favoriser la simplicité) sont exactement les mêmes gestes que ceux qui renforcent la capacité d’une organisation à tenir en cas d’aléa (pannes, cyberattaques, ruptures d’approvisionnement, décisions d’un fournisseur, etc.).

L’utilité comme fondation de la robustesse

Les référentiels d’écoconception numérique place l’utilité au cœur de la démarche :

• Le premier critère du RGESN (critère 1.1, classé prioritaire) s’assure que le service numérique est utile.
• L’AFNOR SPEC 2201 (étape 1, fiche 1) commence exactement de la même manière : avant de concevoir la solution, il convient de questionner la pertinence du besoin.
• La récente norme ISO 20125 le mentionne dès le premier chapitre : « Stage 1: Requirements gathering, prioritization and contextualization. » (En français : « Étape 1 : Recueil des besoins, priorisation et contextualisation. »)

Ce réflexe fondateur n’est pas qu’une bonne pratique environnementale : c’est le premier levier de robustesse.

• Moins de fonctionnalités superflues, c’est moins de composants.
• Moins de composants, c’est moins de dépendances.
• Moins de dépendances, c’est moins de points de défaillance.

Cartographier les composants métier selon leur niveau de dépendance au numérique et leur nécessité pour la pérennité de l’organisation permet de visualiser concrètement ce qui doit tenir… Et ce qui pourrait s’effondrer en cas d’événement imprévu. Ce travail d’inventaire est le même travail que celui demandé par les référentiels d’écoconception (identifier ce qui est vital, ce qui est utile, ce qui est superflu). Les deux démarches posent la même question de départ, avec des vocabulaires différents.

Interopérabilité et open source

Les critères du RGESN sur l’open source (critère 1.8) et les standards interopérables (critère 1.9) ne visent pas seulement à réduire l’obsolescence logicielle : ils garantissent qu’un service numérique peut être maintenu, audité et transmis sans dépendre d’un éditeur unique. Si ce fournisseur change ses conditions contractuelles ou fait défaut, le service reste entre les mains de l’organisation. C’est une forme concrète de robustesse : la capacité à tenir sans avoir à tout reconstruire.

Identifier ce qu’on peut éteindre

Enfin, la stratégie de décommissionnement (critère 2.7 du RGESN et chapitre dédié sur la norme ISO 20125) est généralement perçue comme une contrainte environnementale : éteindre ce qui ne sert plus pour réduire l’empreinte. C’est aussi un acte de gouvernance. Une organisation qui a formalisé quels services pouvaient être arrêtés connaît lesquels sont vitaux. En cas de crise, elle sait quoi sacrifier sans compromettre ses fonctions essentielles.

La robustesse n’est pas un objectif à ajouter par-dessus la démarche d’écoconception. Elle peut en être un résultat, à condition d’interroger ce que l’organisation peut vraiment se permettre de perdre.

De la robustesse à la résilience : savoir ce qui tient en mode dégradé

De fait, la robustesse protège contre les risques anticipés, les dépendances identifiées, les scénarios connus… Mais elle ne prémunit pas contre l’imprévu : un dysfonctionnement qui n’a pas été modélisé, une défaillance d’un composant dont la complexité a été sous-estimée, etc. Face à ce type d’événement, un SI robuste peut tout à fait s’effondrer.

Marge de manœuvre

C’est dans cette situation qu’intervient la notion de résilience. Il ne s’agit pas d’un prolongement de la robustesse, mais d’une capacité distincte : absorber l’inattendu, s’adapter en temps réel et se transformer pour continuer à fonctionner. On passe ainsi de l’anticipation à la gestion de crise en temps réel.

Un SI robuste a nécessairement réduit sa dette technique, supprimé des dépendances, etc.. Cette maîtrise de l’environnement numérique offre une marge de manœuvre nouvelle pour réagir lorsqu’un événement inattendu se présente, sans être freiné par sa propre complexité.

Exemple de convergence règlementaire

Le règlement européen DORA (Digital Operational Resilience Act), entré en application en janvier 2025 vise à renforcer la sécurité informatique et la résilience opérationnelle du secteur financier. Il impose de cartographier et documenter les dépendances aux prestataires tiers critiques. Cette exigence fait clairement écho à ce que demandent les critères du RGESN sur l’évaluation des services tiers (critère 2.10) et des fournisseurs (critère 2.8).

Cette réglementation illustre que maîtriser ses dépendances numériques est devenu un enjeu opérationnel, réglementaire et environnemental.

De la résilience à la souveraineté : reprendre la main sur les choix technologiques

La robustesse permet de ne pas tomber. La résilience permet de rebondir. La souveraineté est la capacité à choisir. Une organisation souveraine ne subit pas ses dépendances technologiques, elle les décide. Ce choix suppose d’avoir préalablement réduit les dépendances contraintes.

L’écoconception comme condition du choix libre

Les critères du RGESN sur l’open source (critère 1.8) et les standards interopérables (critère 1.9) permettent de limiter l’obsolescence logicielle. Respecter ces critères contribue également à la création de solutions numériques dont on maîtrise les modalités de fonctionnement et de sortie. C’est d’ailleurs une des exigences SecNumCloud portée par l’ANSSI pour qualifier les solutions Cloud de confiance : maîtrise des données, des infrastructures et des accès. Un service écoconçu sur des bases ouvertes et interopérables contribue naturellement à ces conditions.

La dépendance aux hyperscalers

Les hyperscalers facilitent le déploiement de services scalables (évolutifs en fonction des besoins). Certes ! Mais, en contrepartie, ils créent des dépendances massives et coûteuses : migration difficile, formats propriétaires, contractualisation favorable à l’éditeur, données hébergées hors juridiction européenne. La démarche d’écoconception questionne chaque dépendance externe et c’est précisément l’objet de la souveraineté. Les deux démarches partagent le même principe : ne pas subir ce qu’on aurait pu choisir.

Choisir ses dépendances

La souveraineté numérique ne signifie pas rejeter le cloud ou les solutions externes. Les hyperscalers peuvent répondre à des besoins réels et légitimes. Ce qui est en jeu, c’est la capacité à choisir, à négocier et à changer. Une organisation dont les services sont légers, interopérables et documentés peut migrer, renégocier ou internaliser sans tout reconstruire.

Une organisation qui a fait le travail d’écoconception n’a pas seulement réduit son empreinte environnementale. Elle a prédéfini les conditions d’un choix libre sur ses infrastructures numériques.

Pas si simple ?

Évidemment, passer de la théorie telle que je viens de la présenter à la réalité terrain ne se fait pas sans difficulté.

Le coût initial de la cartographie

Engager une démarche d’écoconception suppose de commencer par un travail d’inventaire :

• quels services existent ?
• lesquels sont vraiment utilisés ?
• lesquels sont critiques ?
• lesquels peuvent être arrêtés ?

Ce travail révèle généralement des décisions passées non documentées, des dépendances non assumées, des fonctionnalités maintenues par inertie plutôt que par besoin réel (le fameux « on ne sait jamais »). De nombreuses organisations n’ont pas la maturité et les moyens de mener cet inventaire et d’en assumer les conclusions.

Le conflit avec les cycles de delivery

Les équipes sous pression de livraison n’intègrent pas naturellement les critères d’écoconception. Questionner l’utilité d’une fonctionnalité en cours de sprint, refuser une dépendance tierce jugée trop risquée, documenter les arbitrages. Autant d’actions qui nécessitent du temps, des référents / équipes formés et une culture d’entreprise qui accepte de ralentir pour construire plus durablement. Le RGESN prévoit d’ailleurs un référent écoconception (critère 1.3) et des revues régulières (critère 1.4) pour inscrire cette démarche dans le temps.

Le paradoxe de la souveraineté

Les solutions sobres, interopérables et maîtrisables ne sont pas toujours les plus matures fonctionnellement. Un outil open source peut demander plus d’effort d’intégration qu’un service propriétaire clé en main. L’arbitrage entre souveraineté et efficacité opérationnelle est réel : il doit être assumé sans idéaliser la sobriété ni diaboliser la dépendance.

Ces frictions ne remettent pas en cause les liens entre écoconception, robustesse, résilience et souveraineté numérique. Elles en définissent les conditions de réussite. La sobriété numérique est un choix organisationnel autant qu’un choix technique et il engage donc une gouvernance capable de l’assumer dans la durée.

Un seul et même objectif de durabilité

Au fil de cet article, j’ai prêté à l’écoconception une fonction qui va au-delà de la réduction de l’empreinte environnementale : celle d’un outil de maîtrise du numérique par les organisations. En questionnant l’utilité, en réduisant les dépendances superflues, en favorisant les architectures maîtrisables, la démarche d’écoconception produit mécaniquement de la robustesse, de la résilience et les conditions d’une souveraineté numérique réelle.

L’idée principale de ce lien entre toutes ces notions peut se résumer en une seule question :

Si demain vos principaux fournisseurs numériques deviennent indisponibles (panne, rachat, faillite, conflit géopolitique), quelles fonctions vitales de votre organisation tiennent encore ?

Si la réponse est floue, c’est peut-être le bon moment pour engager une démarche d’écoconception.