Déclaration d'écoconception

Université Numérique de La Réunionwww.unr.re

Université Numérique de La Réunion s'engage dans une démarche d'écoconception de ses services numériques. La présente déclaration rend compte de l'évaluation du service au regard des 78 critères du Référentiel général d'écoconception des services numériques (RGESN, version 2024 — Arcep / Arcom).

1. Établissement et périmètre

Maître d'ouvrage : Université Numérique de La Réunion

Service évalué : Plateforme média d'accès aux cours en ligne

Adresse : www.unr.re

Version du service : 2.0

Date d'établissement : 16 juin 2026

Type d'évaluation : Auto-évaluation

Référentiel : RGESN, version 2024 (Arcep / Arcom)

Référent écoconception : Rémi Voluer — SEYES

2. État de conformité

La pondération applique les niveaux de priorité du référentiel (Prioritaire, Recommandé, Modéré). Les critères en cours de traitement et les indicateurs perfectibles font l'objet du plan d'amélioration présenté à la section 8.

3. Résultats par famille de critères

Taux de conformité pondéré par famille
FamilleTaux de conformitéAppréciation
Stratégie100 %Conforme
Spécifications78.3 %Satisfaisant
Architecture71.4 %Satisfaisant
UX / UI94 %Conforme
Contenus93.8 %Conforme
Frontend90 %Conforme
Backend100 %Conforme
Hébergement42.9 %Insuffisant
Algorithmie

4. Détail de l'évaluation par critère

Statut de conformité pour chacun des 78 critères
CritèrePrioritéStatutCommentaire
Stratégie
1.1 Le service a-t-il été évalué favorablement en termes d'utilité en tenant compte de ses impacts environnementaux ?PrioritaireConformeUtilité du service avérée; en cohérence avec les ODD sur le territoire.
1.2 Le service a-t-il défini ses cibles utilisatrices, les besoins métiers et les attentes réelles des utilisateurs-cibles ?PrioritaireConformeCibles définies (étudiants, enseignants, grand public) ; recherche UX menée.
1.3 Le service a-t-il au moins un référent identifié en écoconception numérique ?RecommandéConformeRéférent écoconception : Rémi Voluer (SEYES).
1.4 Le service réalise-t-il régulièrement des revues pour s'assurer du respect de sa démarche d'écoconception ?PrioritaireConformeRevues d'écoconception réalisées.
1.5 Le service s'est-il fixé des objectifs de réduction ou de limitation de ses propres impacts environnementaux ?PrioritaireConformeObjectifs de réduction définis ; suivi dans le temps (indicateurs / ACV).
1.6 Le service collecte-t-il la donnée de façon responsable et raisonnée ?RecommandéConformeCollecte de données limitée au strict nécessaire, en cohérence avec le RGPD.
1.7 Le service a-t-il recours à un niveau de chiffrement adapté à ses besoins ?ModéréConformeHTTPS / TLS en vigueur ; chiffrement proportionné aux besoins.
1.8 Le service a-t-il mis en place des efforts d'open source ?RecommandéConformeSocle entièrement open source (Drupal, Moodle, Open edX, Matomo, hébergement 100% opensource)
1.9 Le service a-t-il été conçu avec des technologies standard interopérables plutôt que spécifiques et fermées ?PrioritaireConformeTechnologies standard et interopérables (web, OAuth / CAS).
1.10 Le service repose-t-il sur des API documentées et ouvertes pour interagir avec le matériel ?RecommandéNon applicableLe service ne repose pas sur un objet connecté ou un périphérique matériel.
Spécifications
2.1 Le service a-t-il défini la liste des profils de matériels que les utilisateurs pourront employer pour y accéder ?PrioritaireConformeProfil matériel minimal défini et affiché (voir déclaration d'écoconception).
2.2 Le service est-il utilisable sur d'anciens modèles de terminaux ?PrioritaireConformeCompatibilité en mode dégradé visée jusqu'à 10 ans.
2.3 Le service est-il utilisable via une connexion bas débit ou hors connexion ?RecommandéPartiellement conformeUtilisabilité bas débit visée.
2.4 Le service est-il utilisable sur d'anciennes versions de système d'exploitation et de navigateurs web ?PrioritairePartiellement conformeNavigateurs supportés jusqu'à deux ans.
2.5 Le service s'adapte-t-il à différents types de terminaux d'affichage ?PrioritaireConformeResponsive design (thème Drupal adaptatif).
2.6 Le service a-t-il été conçu avec une revue de conception et de code intégrant la réduction des impacts environnementaux ?RecommandéPartiellement conformeRevues de code en place ; volet impact environnemental à intégrer formellement.
2.7 Le service a-t-il prévu une stratégie de maintenance et de décommissionnement ?PrioritaireConformeDurée de vie cible de dix ans ; stratégie de maintenance et de décommissionnement définie.
2.8 Le service impose-t-il à ses fournisseurs de garantir une démarche de réduction de leurs impacts environnementaux ?PrioritaireNon applicablePas de fournisseurs tiers
2.9 Le service a-t-il pris en compte les impacts environnementaux des composants d'interface prêts à l'emploi utilisés ?ModéréConformePas de composants d'interface prêts à l'emploi utilisés.
2.10 Le service a-t-il pris en compte les impacts environnementaux des services tiers utilisés lors de leur sélection ?PrioritairePartiellement conformeServices tiers justifiés et spécialisés ; évaluation environnementale comparative à documenter.
Architecture
3.1 Le service repose-t-il sur une architecture, des ressources ou des composants conçus pour réduire leurs propres impacts ?PrioritairePartiellement conformeChoix pérennes et open source ; analyse d'écoconception des frameworks à documenter.
3.2 Le service fonctionne-t-il sur une architecture pouvant adapter la quantité de ressources utilisées à la consommation ?RecommandéConformeArchitecture redondée à haute disponibilité, dimensionnée au besoin (ajout de serveurs front à la volée).
3.3 Le service est-il en mesure de supporter l'évolution technique des protocoles ?ModéréPartiellement conformeHTTPS / TLS récents en vigueur ; support IPv6
3.4 Le service garantit-il la mise à disposition de mises à jour correctives pendant toute la durée de vie des équipements et logiciels ?PrioritaireNon applicableService non commercialisé avec un terminal associé.
3.5 Le service propose-t-il d'installer des mises à jour correctives indépendamment des mises à jour évolutives ?ModéréNon applicablePas de mises à jour évolutives livrées à un terminal utilisateur.
3.6 Le service propose-t-il les mises à jour incrémentielles, afin de ne pas remplacer tout le code à chaque mise à jour ?ModéréNon applicableService web sans distribution applicative à mettre à jour côté terminal.
3.7 Le service optimise-t-il la sollicitation des environnements de développement, de préproduction ou de test ?ModéréConformeLes environnements hors production ne sont pas sollicités lorsqu'ils ne sont pas utilisés
UX / UI
4.1 Le service comporte-t-il uniquement des animations, vidéos et sons dont la lecture automatique est désactivée ?PrioritaireConformePas de lecture automatique de contenu par défaut.
4.2 Le service affiche-t-il uniquement des contenus sans défilement infini ?PrioritaireConformePas de défilement infini ; pagination / bouton « voir plus ».
4.3 Le service optimise-t-il le parcours de navigation pour chaque fonctionnalité principale ?RecommandéConformeParcours de navigation optimisés.
4.4 Le service permet-il à l'utilisateur de décider de l'activation d'un service tiers ?RecommandéConformeConsentemment sollicité, services non lancés automatiquement mais à la demande de l'utilisateur
4.5 Le service utilise-t-il majoritairement des composants fonctionnels natifs de l'OS, du navigateur ou du langage utilisé ?ModéréConformeAbsence de recours à des librairies tiers
4.6 Le service utilise-t-il uniquement du contenu vidéo, audio et animé porteur d'informations ?RecommandéConformeContenus médias à visée informative et pédagogique.
4.7 Le service opte-t-il pour les choix les plus sobres entre le texte, l'image, l'audio ou la vidéo selon les besoins ?ModéréPartiellement conformeArbitrage de sobriété entre texte / image / audio / vidéo à documenter.
4.8 Le service limite-t-il le nombre des polices de caractères téléchargées ?ModéréConformeOui (2 polices)
4.9 Le service limite-t-il les requêtes serveur lors de la saisie utilisateur ?ModéréConformeLimitation des requêtes serveur à la saisie (autocomplétion) strictement limitée et utilisant un cache serveur.
4.10 Le service informe-t-il l'utilisateur du format de saisie attendu, en évitant les requêtes serveur inutiles à la soumission ?ModéréConformeValidation des formats de saisie côté client
4.11 Le service informe-t-il l'utilisateur, avant le transfert, des poids et formats de fichier attendus ?ModéréConformeInformation préalable sur poids / format de fichier au téléversement,
4.12 Le service indique-t-il à l'utilisateur qu'une fonctionnalité a des impacts environnementaux importants ?RecommandéNon applicable 
4.13 Le service limite-t-il le recours aux notifications, tout en laissant la possibilité de les désactiver ?PrioritaireConformePas de notifications intempestives ; désactivation possible.
4.14 Le service évite-t-il le recours à des procédés manipulatoires (dark patterns) dans son interface utilisateur ?RecommandéConformeInterface exempte de dark patterns.
4.15 Le service fournit-il à l'utilisateur un moyen de contrôle sur ses usages pour suivre et réduire les impacts associés ?RecommandéPartiellement conformeL'utilisateur dispose de plusieurs leviers de contrôle : blocage des outils tiers de suivi via le consentement, lancement manuel des vidéos, et accès aux ressources pédagogiques conditionné à la connexion. Un mode d'affichage sobre dédié aurait peu d'impact sur un service aussi dense en contenus pédagogiques.
Contenus
5.1 Le service utilise-t-il un format de fichier adapté au contenu et au contexte de visualisation de chaque image ?RecommandéConformeFormats modernes côté thème ; médias téléversés par les contributeurs conseillés
5.2 Le service propose-t-il des images dont le niveau de compression est adapté au contenu et au contexte de visualisation ?RecommandéPartiellement conformeCompression à généraliser sur les médias des contributeurs.
5.3 Le service utilise-t-il, pour chaque vidéo, une définition adaptée au contenu et au contexte de visualisation ?PrioritaireConformeOui, à travers son titre et sa description
5.4 Le service propose-t-il des vidéos dont le mode de compression est efficace et adapté au contenu et au contexte ?PrioritaireConformeOui, validé par l'hébergeur tiers.
5.5 Le service propose-t-il un mode « écoute seule » pour ses vidéos ?PrioritaireConformeOui, validé par l'hébergeur tiers.
5.6 Le service propose-t-il des contenus audios dont le mode de compression est adapté au contenu et au contexte d'écoute ?ModéréNon applicablePas de contenus audios
5.7 Le service utilise-t-il un format de fichier adapté au contenu et au contexte d'utilisation pour chaque document ?ModéréConformeOui, y compris lors des contribution
5.8 Le service a-t-il une stratégie d'archivage et de suppression des contenus obsolètes ou périmés ?RecommandéConformeLes contenus sont des ressources pédagogiques pérennes, sans obsolescence par défaut. Les contenus sortant du cadre officiel de l'Université sont dépubliés : une stratégie de gestion des contenus existe bien.
Frontend
6.1 Le service s'astreint-il à un poids maximum et une limite de requête par écran ?RecommandéPartiellement conformeÀ la suite de l'audit RGAA et des optimisations associées, le poids moyen de page a été ramené de 9,7 à 2,2 Mo et le nombre de requêtes de 88 à 37 (sous la cible de 40, désormais conforme). Le poids reste supérieur à la cible de 1 Mo et fait l'objet d'une amélioration continue.
6.2 Le service utilise-t-il des mécanismes de mise en cache pour la totalité des contenus transférés dont il a le contrôle ?RecommandéConformeMécanisme de cache côté client en place.
6.3 Le service a-t-il mis en place des techniques de compression pour les ressources transférées dont il a le contrôle ?ModéréConformeMinification et compression des ressources (GZIP / Brotli).
6.4 Le service affiche-t-il majoritairement des images dont les dimensions d'origine correspondent au contexte d'affichage ?RecommandéConformeOui, vérifié au moment des contributions
6.5 Le service évite-t-il de déclencher le chargement de ressources et contenus inutilisés pour chaque fonctionnalité ?RecommandéConformeLazy loading et chargement des ressources à la demande.
6.6 Le service restreint-il l'usage des capteurs des terminaux utilisateurs au besoin du service ?ModéréNon applicableLe service ne sollicite pas les capteurs des terminaux.
6.7 Le service héberge-t-il toutes les ressources statiques transférées dont il est l'émetteur sur un même domaine ?ModéréConformeOui, via un système de cache à plusieurs niveaux
Backend
7.1 Le service a-t-il recours à un système de cache serveur pour les données les plus utilisées ?RecommandéConformeCache serveur en place.
7.2 Le service met-il en place des durées de conservation sur les données et documents (suppression/archivage) ?RecommandéNon applicablePas de politique de suppression des contenus pédagogiques
7.3 Le service informe-t-il l'utilisateur d'un traitement en cours en arrière-plan ?ModéréNon applicablePas de traitements en arrière-plan
7.4 Le service s'appuie-t-il sur un mécanisme de consensus qui minimise sa consommation de ressources ?PrioritaireNon applicableLe service ne repose pas sur une blockchain / mécanisme de consensus.
Hébergement
8.1 Le service utilise-t-il un hébergement ayant une démarche de réduction de son empreinte environnementale ?PrioritaireÀ traiterEngagements environnementaux de l'hébergeur (NXO La Réunion) à obtenir.
8.2 Le service utilise-t-il un hébergement qui fournit une politique de gestion durable des équipements ?PrioritaireConformeÉquipements de l'Université ; justificatif du programme PROTECTEUR : https://www.univ-reunion.fr/wp-content/uploads/2023/02/2023_ECOCAMPUS_PROTECTEUR.pdf
8.3 Le service utilise-t-il un hébergement dont le PUE (Power Usage Effectiveness) est minimisé ?PrioritaireÀ traiterPUE non communiqué par l'hébergeur ; demande de justificatifs engagée.
8.4 Le service utilise-t-il un hébergement dont le WUE (Water Usage Effectiveness) est minimisé ?RecommandéÀ traiterWUE non communiqué par l'hébergeur ; demande engagée.
8.5 Le service utilise-t-il un hébergement dont l'électricité est documentée et majoritairement d'origine renouvelable ?RecommandéÀ traiterMix énergétique de l'hébergeur à documenter.
8.6 Le service utilise-t-il un hébergement dont la localisation géographique minimise son empreinte environnementale ?RecommandéConformeHébergement local (proximité des utilisateurs réunionnais)
8.7 Le service utilise-t-il un hébergement qui traite efficacement la chaleur produite par les serveurs ?RecommandéÀ traiterTraitement / récupération de la chaleur fatale de l'hébergeur à vérifier.
8.8 Le service héberge-t-il de façon distincte les données « chaudes » et « froides » ?ModéréNon applicableVolumétrie inférieure au seuil de 10 To du critère.
8.9 Le service duplique-t-il les données uniquement lorsque cela est nécessaire ?RecommandéConformeRedondance des données dimensionnée au besoin (SLA ajusté).
8.10 Le service tient-il compte des contraintes externes pour minimiser l'impact des calculs et transferts asynchrones ?RecommandéConformePolitique de minimisation des requêtes externes (1x / j à 1x/ sem) et de récolte et mises à jour limitée aux nouveaux contenus
Algorithmie
9.1 Le service a-t-il interrogé la nécessité d'une phase d'entraînement pour éviter un usage non justifié et déraisonné ?PrioritaireNon applicableAucun traitement d'intelligence artificielle / phase d'entraînement.
9.2 Le service utilise-t-il une phase d'apprentissage avec un niveau de complexité minimisé et proportionné à l'usage ?PrioritaireNon applicableAucun traitement d'intelligence artificielle.
9.3 Le service a-t-il mis en place des mécanismes visant à limiter la quantité d'entraînement nécessaire à son fonctionnement ?PrioritaireNon applicableAucun traitement d'intelligence artificielle.
9.4 Le service limite-t-il la quantité de données utilisées pour la phase d'apprentissage au strict nécessaire ?PrioritaireNon applicableAucun traitement d'intelligence artificielle.
9.5 Le service optimise-t-il l'occurrence de mise à jour et de réentraînement des modèles selon ses besoins et cibles ?PrioritaireNon applicableAucun traitement d'intelligence artificielle.
9.6 Le service utilise-t-il des techniques de compression pour les modèles utilisés lors de la phase d'entraînement ?RecommandéNon applicableAucun traitement d'intelligence artificielle.
9.7 Le service utilise-t-il une stratégie d'inférence optimisée en termes de consommation de ressources et de cibles ?PrioritaireNon applicableAucun traitement d'intelligence artificielle / phase d'inférence.

5. Profil matériel et logiciel minimal

Le service est conçu pour rester utilisable sur des équipements anciens, afin de limiter sa contribution à l'obsolescence matérielle.

Configuration matérielle minimale

  • Ordinateur doté d'un processeur double cœur mis sur le marché il y a dix ans ou plus (≈ 2014), avec 4 Go de mémoire vive ;
  • Terminal mobile (smartphone, tablette) mis sur le marché il y a sept ans ou plus ;
  • Affichage complet garanti dans une zone de visualisation de 1 200 pixels de large ;
  • Utilisabilité maintenue sur connexion à bas débit (3G en mobilité, 512 kbit/s en fixe).

Configuration logicielle minimale

  • Compatibilité avec les principaux navigateurs (Firefox, Chrome, Edge, Safari) dans leurs versions actuelles et antérieures jusqu'à deux ans d'ancienneté ;
  • Aucune version récente de système d'exploitation n'est imposée pour l'accès aux fonctionnalités essentielles ;
  • L'authentification centralisée CAS/LDAP de l'Université est proposée, à titre optionnel, aux étudiants de La Réunion afin de leur éviter la création d'un second compte ; un compte local reste disponible pour tous les autres usages. Le recours à cette authentification ne constitue pas un prérequis d'accès au service.

En mode dégradé, aucune fonctionnalité critique (consultation du portail, accès aux cours Moodle et Open edX, lecture, soumission) n'est perdue.

6. Durée de vie cible et maintenance

Université Numérique de La Réunion et son prestataire s'engagent sur une durée de vie cible du service d'au moins dix ans, assortie d'un maintien en conditions opérationnelles et de sécurité sur l'ensemble de cette période. Cette stratégie s'appuie sur une politique de montée de version maîtrisée du socle Drupal, sur le suivi des versions supportées des plateformes Moodle et Open edX, et sur l'application systématique des correctifs de sécurité. En fin de vie, la réversibilité complète du service est garantie par l'export de la base de données, l'export de la configuration Drupal, la fourniture d'un manuel d'exploitation et l'accès intégral aux sources versionnées.

7. Indicateurs environnementaux mesurés

Mesures relevées au regard des cibles d'écoconception
IndicateurUnitéCibleValeur mesuréeVerdict
EcoIndex (note)A à GA ou BBConforme
EcoIndex (score)/1007565,86À améliorer
Poids moyen de pageMo12,2À améliorer
Nombre de requêtes HTTPreq.4037Conforme
Empreinte carbonegCO₂eq/page10,92Conforme
LCP (Largest Contentful Paint)s2,52,2Conforme
INP (Interaction to Next Paint)ms20035Conforme
CLS (Cumulative Layout Shift)0,10,004Conforme
Lighthouse Performance/1009085À améliorer
Lighthouse Accessibilité/1009092Conforme
Lighthouse Best Practices/10090100Conforme
Lighthouse SEO/1009092Conforme

À la suite de l'audit d'accessibilité (RGAA) et des optimisations associées, le poids moyen de page a été ramené de 9,7 à 2,2 Mo, le nombre de requêtes de 88 à 37 (désormais sous la cible) et la note EcoIndex portée de E à B. Le poids de page et le score de performance restent perfectibles et font l'objet du plan d'amélioration ci-dessous.

8. Plan d'amélioration

Les points identifiés comme non conformes ou en cours de traitement sont les suivants :

  • À traiter — 8.1. Le service utilise-t-il un hébergement ayant une démarche de réduction de son empreinte environnementale ?
  • À traiter — 8.3. Le service utilise-t-il un hébergement dont le PUE (Power Usage Effectiveness) est minimisé ?
  • À traiter — 8.4. Le service utilise-t-il un hébergement dont le WUE (Water Usage Effectiveness) est minimisé ?
  • À traiter — 8.5. Le service utilise-t-il un hébergement dont l'électricité est documentée et majoritairement d'origine renouvelable ?
  • À traiter — 8.7. Le service utilise-t-il un hébergement qui traite efficacement la chaleur produite par les serveurs ?

Ces points relèvent de la famille Hébergement et seront réévalués à réception des éléments documentés de l'hébergeur (PUE, mix énergétique, gestion durable des équipements), qui font l'objet d'une demande en cours.

9. Critères non applicables

Certains critères sont sans objet au regard de la nature du service et sont exclus du décompte de conformité : l'ensemble de la famille Algorithmie (le service ne met en œuvre aucun traitement d'intelligence artificielle), ainsi que les critères relatifs aux objets connectés, aux capteurs des terminaux, aux mécanismes de consensus de type blockchain et aux mises à jour applicatives distribuées sur un terminal.

10. Établissement et mise à jour de la déclaration

Cette déclaration a été établie le 16 juin 2026 sur la base d'une auto-évaluation appliquant les 78 critères du RGESN 2024. Elle est mise à jour à chaque évolution significative du service, et au minimum lors de chaque revue d'écoconception. Toute demande d'information peut être adressée au référent écoconception : Rémi Voluer — SEYES.

Déclaration d'écoconception — Université Numérique de La Réunion — 16 juin 2026. Référentiel : RGESN 2024 (Arcep / Arcom). Taux de conformité : 82.1 % (Conforme).