La consultation de vidéos sur des plateformes de contenu comme YouTube ou Dailymotion est aujourd'hui une activité quotidienne pour une grande partie de la population.
Ces plateformes représentent une part importante du trafic Internet mondial et donc de la consommation énergétique du numérique.
Ce sujet nous semble particulièrement pertinent, car les services de contenu vidéo constituent un usage central du web moderne, à la fois informatif, culturel, mais surtout en tant que loisir. De plus, nous sommes tous deux consommateurs de Youtube, et passons plusieurs heures par semaine devant, ce qui nous a conforté dans notre choix.
Les plateformes de vidéos en ligne ont une utilité sociale forte :
- Éducation : mise à disposition de cours, tutoriels, documentaires et vulgarisation scientifique.
- Information et actualité : accès à des contenus indépendants (Hugo Decrypte en France par exemple) de manière beaucoup plus abordable pour les jeunes que les médias traditionnels comme les journaux ou la télévision.
- Bien-être : la vidéo est un outil de détente et peut être considéré comme un loisir à part entière.
- Accessibilité : elles permettent à chacun, même dans des zones isolées, d'avoir accès à des ressources éducatives et culturelles.
La diffusion numérique des contenus vidéo a progressivement remplacé les supports physiques comme les DVD, les CD ou la télévision.
Cette transition a permis de réduire certains impacts liés à la fabrication et au transport de ces supports.
Mais elle s'est aussi accompagnée d'une forte hausse de la consommation de données, notamment avec la généralisation de la haute définition et du visionnage en continu.
Chaque lecture d'une vidéo fait intervenir une chaîne d'acteurs énergivores :
- Les serveurs et data centers, nécessaires pour stocker et diffuser les contenus.
- Le réseau Internet, qui transporte d'importants volumes de données sur de longues distances.
- Et enfin, les appareils des utilisateurs, qui doivent décoder et afficher ces flux, souvent en qualité supérieure à ce que l'écran nécessite réellement.
Nous faisons l'hypothèse que les plateformes de vidéos en ligne comme YouTube ou Dailymotion sont consultées plusieurs fois par jour, souvent lors de moments de pause de quelques minutes (pendant les transports, après un repas, avant de dormir, etc.). Pour cette raison, nous prendrons en compte dans nos scénarios le visionnage de deux vidéos consécutives, afin de pouvoir observer l'impact d'un éventuel système de cache ou de mise en mémoire locale.
Nous distinguerons également deux types d'usages :
- La navigation aléatoire à partir de la page d'accueil (consommation de contenu recommandée).
- La recherche ciblée d'une chaîne ou d'un créateur spécifique.
L'utilisateur se connecte au site grâce à un favori (donc sans passer par un moteur de recherche). Si nécessaire, il se connecte. Puis il consulte les vidéos à la une. Il choisit une des vidéos et la regarde jusqu'à la fin. Il revient aux vidéos à la une et les consulte. Il choisit une autre vidéo et la regarde jusqu'à la fin.
L'utilisateur se connecte au site grâce à un favori (donc sans passer par un moteur de recherche). Si nécessaire, il se connecte. Puis il consulte les vidéos à la une. Il recherche un créateur de contenu via la barre de recherche. Il se rend sur la chaine du créateur de contenu. Il clique sur l'onglet "vidéos" du créateur de contenu. Il choisit une des vidéos et la regarde jusqu'à la fin.
L'EcoIndex d'une page (de A à G) est calculé (sources : EcoIndex, Octo, GreenIT) en fonction du positionnement de cette page parmi les pages mondiales concernant :
- le nombre de requêtes lancées,
- le poids des téléchargements,
- le nombre d'éléments du document.
Nous avons choisi de comparer l'impact de nos scénarios sur les services les plus populaires du marché, à savoir YouTube et Dailymotion, ainsi que sur un service utilisant des ressources de manière plus modérée : PodUtt.
| Service | Score (sur 100) | Classe | Détail des mesures |
|---|---|---|---|
| Youtube | 12.91 | F 🟥 | … |
| Dailymotion | 25.75 | E 🟧 | … |
| PodUTT | 59.14 | C 🟨 | … |
Tab.1 : Mesure de l'EcoIndex moyen des services de vidéo en ligne.
Cette analyse globale met en lumière des disparités frappantes entre les plateformes de streaming vidéo, révélant que la sobriété technique est le levier principal de l'écoconception.
Le benchmark réalisé le 30 décembre 2025 montre une hiérarchie claire dans la performance environnementale :
- PodUTT (59.14 - Grade C 🟨) : C'est le grand gagnant de ce comparatif. Sa force réside dans une architecture épurée avec seulement 27 à 38 requêtes par page. Son DOM léger (moins de 900 éléments) réduit drastiquement l'effort de calcul du terminal utilisateur.
- Dailymotion (25.75 - Grade E 🟧) : Bien que classé deuxième, ses résultats sont alarmants. On observe une instabilité critique avec des pics dépassant les 1 000 requêtes et des pages atteignant 35 Mo. L'impact est ici principalement lié au poids démesuré des ressources transférées.
- YouTube (12.91 - Grade F 🟥) : Malgré sa popularité, YouTube présente le score le plus faible. Son empreinte est plombée par une complexité structurelle extrême (plus de 7 000 éléments DOM) et un flux constant de requêtes (jusqu'à 200) pour maintenir ses fonctionnalités interactives.
| Indicateur | Observation Majeure |
|---|---|
| Poids des pages | Le facteur le plus discriminant, variant de 2 Mo (PodUTT) à plus de 35 Mo (Dailymotion). |
| Complexité (DOM) | YouTube sollicite le plus le processeur utilisateur, tandis que PodUTT privilégie une structure simplifiée. |
| Consommation d'eau | Directement corrélée au volume de données, elle est divisée par près de 1,5 entre YouTube et PodUTT. |
L'analyse démontre que les plateformes de streaming académiques comme PodUTT sont des modèles d'écoconception par rapport aux géants du divertissement. En limitant les trackers et les scripts superflus, PodUTT divise par deux l'émission de GES par rapport aux sessions les plus lourdes de Dailymotion ou YouTube.
Comme nous l'avons vu dans la section précédente, parmi les choix de conception ayant le plus d'impact environnemental, la plupart sont directement liés au modèle économique du service. C'est pourquoi il est nécessaire à ce stade d'analyser leur modèle économique et de définir notre propre modèle permettant une conception plus frugale.
| Service | Visiteur anonyme | Abonné |
|---|---|---|
| YouTube |
|
|
| Dailymotion |
|
|
| PodUTT |
|
Sans objet (service universitaire/libre) |
Tab.2 : Offre des services de vidéo en ligne.
Les offres de service numérique de vidéo (cf. Tab.2) reposent majoritairement sur un modèle de captation de l'attention pour maximiser les revenus publicitaires :
- un accès gratuit financé par une publicité omniprésente et énergivore
- un accès "Premium" payant permettant de supprimer la publicité et d'ajouter des fonctionnalités de confort.
Sur Youtube, on peut rencontrer différents types de pub :
- In-Stream désactivable : Pub classique qu'on peut ignorer après 5s, payée seulement si vue 30s+.
- In-Stream non désactivable : Pub de 15s obligatoire avant la vidéo, revenus garantis car impossible à passer.
- Bumper : Format éclair de 6s non désactivable, idéal pour la répétition à faible coût.
- In-Feed (Discovery) : Vignette suggérée en recherche ou accueil, payée uniquement si l'utilisateur clique.
- Masthead : Bannière géante en haut de l'accueil YouTube, louée à prix d'or pour 24h.
| Format | Durée | Ignorable ? | Tarification | Coût Annonceur (Moyen) | Part de YouTube (45%) |
|---|---|---|---|---|---|
| InStream désactivable | 15s à 3min | Oui | CPV (par vue) | 0,05 € / vue | 0,0225 € |
| InStream non désactivable | Max 15s | Non | CPM (1000 impr.) | 8,00 € / 1k | 3,60 € / 1k |
| Bumper | 6s | Non | CPM (1000 impr.) | 5,00 € / 1k | 2,25 € / 1k |
| Discovery | Variable | Oui | CPC (clic) | 0,10 € / clic | 0,045 € |
| Masthead | Jusqu'à 30s | Non | Forfait Journalier | 50 000 € / jour | 22 500 € |
Tab.3 : Estimation de la rémunération perçu par Youtube en fonction des différentes types de pub1.
Le modèle de PodUTT lui, se distingue par sa frugalité, aucune monétisation n'est recherchée, le service étant hébergé à des fins pédagogiques ou institutionnelles. Cela permet de supprimer les scripts de suivi et les flux vidéo publicitaires qui alourdissent considérablement le bilan carbone de chaque session de visionnage.
L'étude de l'offre des plateformes vidéo nous a permis d'identifier les sources de revenu communément utilisées (cf. Tab.2). Associées à un bref état de l'art (cf. Tab.3), nous avons pu établir que la majorité des publicités est peu rémunératrice à l'unité (mise à part Masthead), elle nécessite des millions de vues pour être viable. C'est ce constat qui pousse les plateformes à utiliser des algorithmes de recommandation addictifs, augmentant ainsi le temps passé en ligne et l'énergie consommée.
Le coût d'infrastructure est critique, contrairement au texte, le stockage et la diffusion de vidéo coûtent cher. Le modèle publicitaire classique "force" la surconsommation pour couvrir ces frais. L'abonnement offre une stabilité, il permet de financer le service sans avoir recours à des scripts de tracking tiers ou à l'affichage de flux vidéos publicitaires non désirés. Le sponsoring direct (ou régie intégrée), est beaucoup plus efficace et moins intrusif techniquement qu'une régie publicitaire programmatique.
Par conséquent, pour réduire l'impact écologique du service, nous proposons de renoncer aux publicités en vidéo qui multiplient les requêtes réseau.
A la place, nous avons opté pour un système d'abonnement premium. Cette solution est différente de l'abonnement Premium de Youtube qui consiste principalement en la suppression des pubs, et la possibilité de lire une vidéo même avec l'écran en veille à la manière de Spotify. En souscrivant à un abonnement Premium GreeTube, l'utilisateur aura accès à plusieurs avantages:
-
un tableau de bord personnalisé de son impact environnemental afin de visualiser l'empreinte de ses usages (volume de données consommées, estimation d'émissions de CO₂ et de consommation d'eau). On pourra aussi mettre en place une comparaison avec l'impact potentiel pour une activité similaire chez des concurrents (YouTube, Daylimotion).
-
Une option de téléchargement temporaire qui permettra à l'utilisateur de regarder ses videos en hors connexion (en basse qualité pour garantir une vraie plus value à l'abonnement tout en minimisant l'impact).
-
Un "droit de vote" sur les potentielles évolutions de la plate-forme afin que chaque utilisateur premium ai un réel impact, et passe de simple consommateur à acteur dans le développement d'une solution environementalement plus saine.
Nous souhations aussi incorporer une publicité masthead, sur chaque page du service, qui suffirait à financer l'infrastructure pour une large audience tout en restant statique, moins énergivore et moins contraignant que le flux vidéo publicitaire. Néanmoins, nous sommes conscients que ce type de publicité ne peut générer des revenus comparables à ceux de YouTube, dont les emplacements Masthead atteignent environ 50 000 € par jour. Dans la mesure où notre application doit encore s'imposer sur le marché et constituer sa base d'utilisateurs, nous estimons qu'un positionnement tarifaire compris entre 100 et 500 € par jour apparaît plus cohérent et réaliste.
Voici donc un résumé de notre modèle économique :
| Source possible de revenus | Montant unitaire | Quantité nécessaire pour financer un salaire2 |
|---|---|---|
| Abonnement Premium | 12,99€ | 275 |
| Pub Masthead | 100€ à 500€ / jour | 36 à 7 jour |
Tab.4 : Source de revenus possibles pour notre service de vidéo en ligne.
Au vu des différents services comparés, des exigences environnementales exprimées plus haut et des scénarios retenus, nous avons défini pour notre prototype une maquette de l'interface et un échantillon de données réalistes.
Les ressources Web possédant une représentation sur notre application seront de deux types :
- la page d'accueil (avec une HTTP-URI ayant pour chemin
/) permettant d'afficher les miniatures de vidéo ou de chaine. - la page de vidéo (avec pour chemin
/video/{id}). - la page de chaine (avec pour chemin
/channel/{id}).
Fig1: Maquette de la Frontpage
Fig2: Maquette de la page vidéo
Fig3: Maquette de la page d'une chaîne
Dans un objectif de sobriété environnementale, les vidéos et chaines de la page d'accueil seront affichées par paquet de 6, d'autre vidéo seront disponible via le bouton "Voir plus".
Pour des raisons de respect des droits d'auteurs, nous utilisons des données générées (avec dummy-json).
Contient les métadonnées de la vidéo et les informations essentielles de l'auteur.
{
"_id": "v0",
"type": "video",
"id_user": "u123",
"date": "2024-10-07 14:30:00",
"name": "Titre de la vidéo",
"desc": "Description courte du contenu...",
"path": "uploads/videos/videoTest.mp4",
"thumbnail": "uploads/thumbnails/default.png",
"views": 4500
}Profil complet incluant les accès et les statistiques d'abonnement.
{
"_id": "u0",
"type": "user",
"name": "Nom Prénom",
"email": "user@example.com",
"subscribers": 1250,
"date": "2014-10-07 09:00:00"
}Liaison entre un utilisateur et une vidéo pour les interactions textuelles.
{
"_id": "c0",
"type": "comment",
"id_user": "u123",
"id_video": "v456",
"date": "2025-01-12 10:15:00",
"content": "Message de l'utilisateur..."
}Document technique de synchronisation pour la gestion des identifiants uniques.
{
"_id": "counter",
"type": "counter",
"user_counter": 799,
"video_counter": 1999,
"comment_counter": 7499
}Pour cette première version du prototype (v1.0.0) :
- l'échantillon de données est encore chargé de manière statique via un fichier sample_data.json.
- les fonctionnalités implémentées ne sont que celles nécessaires pour suivre les scénario prioritaire ("Consulter une vidéo - accueil/chaine").
Ces scénario nécessite de pouvoir naviguer entre deux types de page : la page d'accueil, une page de chaine de et les pages des vidéos.
Nous avons développé la page d'accueil (cf. Fig.1) pour qu'elle affiche l'échantillon de données sous une forme proche de ce que prévoyait la maquette.
Fig.4: Prototype de la page d'accueil.
Pour ce projet, nous avons exclu les frameworks lourds comme Bootstrap ou Tailwind CSS en raison de leur empreinte numérique élevée. Après un essai non concluant avec PicoCSS, dont la rigidité imposait trop de surcharges CSS personnalisées, nous avons développé notre propre bibliothèque modulaire.
Inspirée de l'approche Atomic CSS, cette structure assemble des fragments de classes dans un fichier index.css unique. Si cette méthode minimise la duplication de code dans la feuille de style, elle densifie les attributs class au sein du DOM. Cette approche pose une question intéressante en éco-conception : le gain de poids sur le fichier CSS compense-t-il l'augmentation de la taille du HTML ?
Pour aller plus loin dans la frugalité, nous pourrions mettre en place une étape qui consisterait à intégrer un système de Purge CSS. Cela permettrait de supprimer automatiquement les classes inutilisées et de ne servir que le code strictement nécessaire à l'affichage, optimisant ainsi chaque octet transféré.
Dans l'état actuel du prototype, il est possible d'avoir une première idée de l'impact environnemental du frontend.
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| Mode "développement" | 78 B 🟦 | 1.43 | 98 | 42 | 1307 |
| Mode "pré-production" | 88 A 🟩 | 1.19 | 95 | 9 | 73 |
Tab.5: Évaluation de l'impact du prototype de la page d'accueil.
Cette première étape de prototypage est une réussite majeure, le passage en mode pré-production confirme que notre stratégie de sobriété semble porter ses fruits.
Points clés de l'analyse :
-
Le score de 88 (Grade A) semble valider notre choix d'avoir évité les frameworks CSS lourds. La structure est extrêmement rapide à charger et à interpréter par le navigateur.
-
La chute drastique du nombre de requêtes (de 42 à 9) est un excellent signal. Cela montre que le regroupement des ressources est optimal dès cette phase.
Conclusion de l'étape : Nous sommes très satisfaits de ce premier bilan. Le socle technique est sain, léger et déjà prêt à accueillir les futures fonctionnalités sans dégrader immédiatement son empreinte environnementale.
Les pages des vidéos ont pour HTTP-URI video/{id}.
De même que précédemment, nous avons tenté d'implémenter cette page (cf. Fig.2) conformément à ce que prévoyait la maquette.
Fig.5: Prototype de la page d'une vidéo.
Avec l'ajout de ce modèle de page et la mise en place de la navigation entre les deux modèles, il devient possible d'exécuter le scénario prioritaire complet et de mesurer son impact.
| Étape du scénario | EcoIndex | GES (gCO2e) | DOM | Requêtes | Taille (ko) |
|---|---|---|---|---|---|
| 1. Chargement de l'accueil | 80 A 🟩 | 1.40 | 92 | 6 | 2776 |
| 2. Choisir une vidéo | 90 A 🟩 | 1.19 | 95 | 4 | 226 |
| 3. Retourner au menu | 93 A 🟩 | 1.13 | 92 | 1 | 0 |
| 4. Choisir une autre vidéo | 90 A 🟩 | 1.19 | 95 | 4 | 226 |
Tab.6 : Évaluation de l'impact du scénario "Consulter une vidéo - accueil" dans le prototype v1.0.0.
Les résultats obtenus sur l'ensemble du scénario sont excellents, avec une note EcoIndex de A systématiquement maintenue. Le chargement de la page d’accueil (Étape 1) affiche un score de 80, ce qui constitue la valeur la plus basse du parcours. Ce chiffre s’explique par un poids de 2776 ko lié à l'affichage des miniatures vidéos. Bien que le nombre de requêtes soit très faible (6), le poids des ressources graphiques reste le principal levier d'optimisation à ce stade, même si la structure globale du site demeure très sobre.
La consultation des vidéos (Étapes 2 et 4) présente un score de 90, un résultat très performant qu’il convient toutefois de nuancer techniquement. En effet, l’outil de mesure capture l’état de la page au chargement mais ne reflète pas l’exécution du streaming vidéo sur la durée. Comme le navigateur télécharge les données par segments successifs, le poids initial mesuré (226 ko) est minime, ce qui favorise le score. La sobriété de l'interface, avec un DOM ne dépassant pas les 95 éléments, permet de limiter l'usage des ressources processeur lors de cette phase de lecture.
L’aspect le plus probant de cette analyse réside dans l’efficacité du cache, illustrée par l’étape 3. Le retour au menu affiche un transfert de 0 ko pour une seule requête, ce qui confirme une gestion optimale du cache navigateur. En réutilisant les assets déjà chargés lors de la première étape, le site annule quasiment son empreinte réseau pour les actions récurrentes, propulsant le score EcoIndex à 93.
Les pages des chaines ont pour HTTP-URI channel/{id}.
De même que précédemment, nous avons tenté d'implémenter cette page (cf. Fig.3) conformément à ce que prévoyait la maquette.
La maquette initiale (v1) n'est plus disponible. Une version mise à jour et plus détaillée est présentée dans la suite de ce document.
Ce second scénario mesure l'impact de la navigation vers une page de chaîne spécifique avant la consultation de vidéos.
| Étape du scénario | EcoIndex | GES (gCO2e) | DOM | Requêtes | Taille (ko) |
|---|---|---|---|---|---|
| 1. Chargement de l'accueil | 80 A 🟩 | 1.40 | 92 | 6 | 2776 |
| 2. Choisir une chaîne | 93 A 🟩 | 1.14 | 60 | 7 | 28 |
| 3. Choisir une vidéo | 90 A 🟩 | 1.18 | 94 | 4 | 2854 |
| 4. Retourner sur la chaîne | 95 A 🟩 | 1.09 | 60 | 1 | 0 |
| 5. Choisir une autre vidéo | 90 A 🟩 | 1.19 | 95 | 4 | 226 |
Tab.7: Évaluation de l'impact du scénario "Consulter une chaine - chaine" dans le prototype v1.0.0.
Ce second scénario va dans le sens de nos analyses précédentes en ajoutant l'étape de la page de chaîne qui, pour le moment, se content d'afficher les détails de la chaîne ainsi que des liens vers les vidéos.
La consultation des vidéos (Étapes 3 et 5) maintient un score de 90 grâce au chargement fractionné du flux, évitant tout transfert massif de données à l’ouverture. Enfin, l’efficacité du cache est optimale lors du retour sur la chaîne (Étape 4), avec 0 ko transféré et une seule requête, le score atteint 95. Ce mécanisme d’écoconception est particulièrement efficace pour les parcours d'exploration, car il annule l'impact réseau lors des allers-retours de l'utilisateur.
Pour cette nouvelle version du prototype (v1.0.1), identique du point de vue fonctionnel, les données sont désormais chargées proprement par le frontend à travers le réseau via des fetchs après un premier affichage à vide.
Ce comportement, plus réaliste, n'a pour effet qu'une requête supplémentaire par page affichée.
Concernant l'évaluation de l'impact environnemental du scénario, par rapport au tableau précédent (cf. Tab.6-7), à l'exception du nombre de requêtes qui est incrémenté de 1, les résultats sont strictement identiques.
Maintenant que notre prototype est réaliste en termes de nombre de requêtes, nous pouvons simuler les effets du "passage à l'échelle".
Les plateformes de vidéo en ligne permettent à tout type d'utilisateur de poster des vidéos de ce fait il est important d'analyser le comportement du service dans le cas ou le volume de vidéo, commentaires et chaine explose !
Nous avons ainsi mis en place les valeurs suivantes :
10 à 20=> 2000 vidéos10 à 15=> 7500 commentaires10 à 20=> 800 utilisateurs inscrits
Produites désormais de manière automatique lors de l'intégration continue, les mesures nécessaires à la production de l'EcoIndex, la simulation du passage à l'échelle retraduisent bien (cf. Tab.7) l'augmentation du poids des téléchargements, mais aussi de l'augmentation du nombre d'éléments de la page des titres.
Pour se faire nous avons analyser le scénario de chaine qui est similaire au scénario de vidéo avec des étapes supplémentaires.
| Étape du scénario | EcoIndex | GES (gCO2e) | DOM | Requêtes | Taille (ko) |
|---|---|---|---|---|---|
| 1. Chargement de l'accueil | |||||
| 2. Choisir une chaîne | |||||
| 3. Choisir une vidéo | 1.18 | ||||
| 4. Retourner sur la chaîne | |||||
| 5. Choisir une autre vidéo |
Tab.8: Effet du passage à l'échelle sur l'impact du scénario "Consulter une chaine - chaine" dans le prototype v1.0.1.
Le passage à une échelle supérieure montre une augmentation logique du poids des pages de listes (Accueil et Chaîne), qui passent d'environ 2,8 Mo à 5,8 Mo. Cette hausse s'explique par le chargement d'un plus grand nombre de miniatures et de métadonnées. Cependant, les scores EcoIndex restent très corrects (76 et 77, Note B).
L'impact du scale up sur le poids des pages est directement limité par l'implémentation d'un bouton de pagination "Voir plus". En ne chargeant qu'une partie du catalogue au clic, on évite une explosion du DOM et du transfert de données qui aurait lieu avec un défilement infini ou un chargement complet. Cette stratégie de "Lazy Loading" manuel permet de maintenir un DOM stable autour de 90 éléments, garantissant une fluidité constante pour l'utilisateur, peu importe la taille de la base de données.
Enfin, les pages de contenu (Vidéos) et la navigation via le cache (Étape 4) conservent d'excellentes performances (Note A). Le scale up n'affecte pas ces étapes, car une fois la ressource ciblée, le volume global de la plateforme n'influence plus la consommation de la page. L'efficacité du cache reste maximale avec seulement 1 ko transféré lors du retour sur la chaîne.
Par la suite pour évaluer plus précisément l'impact de la consultation elle-même nous utiliserons un autre outil de mesure : GreenFrame.
Le logiciel GreenFrame est capable d'estimer, pour les différents composants de l'architecture, la consommation énergétique :
- du CPU (à partir du temps de calcul),
- de la mémoire vive (à partir de la taille des données mémorisées),
- du disque (à partir de la taille des données lues et écrites),
- du réseau (à partir de la taille des données reçues et envoyées),
- pour le navigateur uniquement, de l'écran (à partir du temps d'exécution du scénario).
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.00084 | 0.000050 | 0.0 | 0.0016 | 0.080 | 0.083 |
| Serveur Web | 0.0000039 | 0.0000034 | 0.0 | 0.0016 | 0.0 | 0.0016 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.00072 | 0.000035 | 0.0 | 0.0016 | 0.056 | 0.058 |
| Serveur Web | 0.0000041 | 0.0000024 | 0.0 | 0.0016 | 0.0 | 0.0016 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0025 | 0.000093 | 0.0 | 0.064 | 0.092 | 0.16 |
| Serveur Web | 0.000030 | 0.0000039 | 0.0 | 0.065 | 0.0 | 0.065 |
Tab.9: Estimation de la consommation énergétique de la consultation de l'accueil (a) d'une chaine (b) d'une vidéo (c).
Par le biais de ces 3 tableaux, nous pouvons tiré plusieurs analyses :
- La consultation de l'accueil (a) est le plus coûteux en réseau (0.064 Wh).
- Lors des consultations de vidéo (b) et de chaine (c), la consommation réseau s'effondre (0.0016 Wh). Cela valide que notre application, une fois chargée, ne consomme presque plus rien d'autre que l'énergie nécessaire à l'affichage (écran).
- Dans les phases de navigation interne, l'écran représente près de 96% de la consommation totale du navigateur. La frugalité de notre code (faible usage CPU/Mem) déplace l'enjeu écologique sur le matériel physique de l'utilisateur plutôt que sur l'infrastructure logicielle.
Afin de réduire l'impact énérgétique du réseau, nous stockons désormais les données de l'application (v2.0.0) dans une base de données (CouchDB).
Cette évolution nous permet, lors de l'affichage d'une vidéo, de charger une seule vidéo plutôt que les plus de 2000.
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | 0.0016 | 0.080 | 0.083 | ||
| Serveur Web | 0.0000034 | 0.0 | 0.0016 | 0.0 | 0.0016 | |
| CouchDB | 0.00084 | 0.000071 | 0.0 | 0.00000013 | 0.0 | 0.00091 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | 0.0016 | 0.056 | 0.058 | ||
| Serveur Web | 0.0000024 | 0.0 | 0.0016 | 0.0 | 0.0016 | |
| CouchDB | 0.00061 | 0.000050 | 0.0 | 0.0 | 0.0 | 0.00066 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | |||||
| Serveur Web | 0.0 | 0.0 | ||||
| CouchDB | 0.0065 | 0.000085 | 0.0 | 0.024 | 0.0 | 0.030 |
Tab.10: Effet de l'ajout de CouchDB sur consultation de l'accueil (a) d'une chaine (b) d'une vidéo (c).
Le passage à une base de données CouchDB marque une étape cruciale. On abandonne le chargement local global pour une récupération de données "à la demande". Les chiffres (cf. Tab.10) révèlent un arbitrage technique très intéressant.
Au chargement de l'accueil (a), on observe une hausse du CPU Navigateur (0.0069 Wh vs 0.0025) et l'apparition du CPU CouchDB (0.0065 Wh). En effect, me système doit maintenant gérer une connexion à la base de données et traiter une requête structurée. C'est l'investissement nécessaire pour ne plus avoir à manipuler des fichiers de données "morts" et trop lourds.
L'objectif principal est atteint sur la consultation d'une vidéo (c) : Le réseau CouchDB tombe à un niveau quasi nul (0.00000013 Wh). En ne récupérant que les métadonnées de la vidéo consultée plutôt que l'index complet des 2000 titres, on réduit drastiquement la sollicitation des infrastructures de transfert. On évite ainsi le "bruit numérique" inutile sur le réseau.
Malgré l'ajout d'un composant supplémentaire (le serveur de base de données), l'impact total reste dans le même ordre de grandeur. Une fois la première requête passée, les étapes (b) et (c) montrent que CouchDB consomme moins de 0.001 Wh. légère hausse de consommation CPU est largement compensée par la précision des données transférées. On ne télécharge plus ce qu'on ne regarde pas.
Cette version v2.0.0 prouve qu'une base de données bien configuré est un allié de l'éco-conception. La base de données agit comme un filtre énergétique, elle consomme un peu d'énergie pour "réfléchir" (CPU) afin d'en économiser beaucoup lors du "transport" (Réseau).
Une fois notre scénario prioritaire établi, nous avons fait évoluer notre service pour répondre aux objectifs fixés initialement. Nous avons implémenté plusieurs fonctionnalités clés afin de transformer notre prototype en une véritable plateforme de vidéo en ligne.
Pour garantir la pérennité du projet, nous avons d'abord repensé notre architecture. Initialement, le frontend requêtait directement la base de données CouchDB. Cette approche présentait des failles de sécurité majeures, le client (accessible à l'utilisateur) ayant un accès trop direct à la couche de données.
L'introduction d'un backend est devenue indispensable pour supporter nos nouveaux besoins : le système d'authentification et l'upload de fichiers. Nous avons choisi Express (Node.js) pour remplir les missions suivantes :
- Intermédiation des données : Le backend récupère, trie et traite les données de la base avant de les transmettre au frontend, sécurisant ainsi les flux.
- Système d'authentification : Mise en place d'un tunnel Login/Register. La gestion de l'état utilisateur (via Context et LocalStorage) permet de conditionner l'ajout de vidéos, de commentaires et la personnalisation des profils.
Fig.6: Page d'authentification
- Gestion des médias : Prise en charge de l'upload des vidéos, des miniatures et des photos de profil.
Fig.7: Modal d'upload de vidéo
Voici les nouveaux tableaux d'analyse GreenFrame intégrant désormais le Backend en plus de CouchDB. Cette structure correspond à l'architecture finale.
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | 0.0016 | 0.080 | 0.083 | ||
| Frontend | 0.0000045 | 0.0000034 | 0.0 | 0.0016 | 0.0 | 0.0016 |
| CouchDB | 0.0 | 1.3e-7 | 0.0 | 0.00091 | ||
| Backend | 3.1e-7 | 0.000020 | 0.0 | 1.3e-7 | 0.0 | 0.000020 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | 0.0016 | 0.056 | 0.058 | ||
| Frontend | 0.0000024 | 0.0 | 0.0016 | 0.0 | 0.0016 | |
| CouchDB | 0.0 | 0.0 | 0.0 | |||
| Backend | 3.2e-7 | 0.000014 | 0.0 | 0.0 | 0.0 | 0.000014 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | 0.095 | ||||
| Frontend | 0.0 | 0.046 | 0.0 | 0.046 | ||
| CouchDB | 0.0 | 0.0 | ||||
| Backend | 0.00028 | 0.000034 | 0.0 | 0.000060 | 0.0 | 0.00038 |
Tab.11: Effet de l'ajout du backend sur consultation de l'accueil (a) d'une chaine (b) d'une vidéo (c).
L’ajout d’un backend pour faire l'intermédiaire avec la base de données a été un vrai tournant pour l'architecture du projet. Contrairement à ce qu'on pourrait penser, cette couche supplémentaire n'alourdit pas l'ensemble, elle sert de « pré-mâcheur » de données pour le client. Le gain est d'ailleurs flagrant sur le CPU du navigateur, qui chute de 60 % (de 0,0069 Wh à 0,0023 Wh). En bref, le terminal de l'utilisateur n'a plus à s'épuiser à formater des données brutes, le serveur s'en occupe pour lui.
Côté réseau, on observe notamment une chute drastique de la consommation de CouchDB. Comme la base de données communique maintenant en local avec le backend et plus directement avec le navigateur via internet, elle n'envoie au client qu'un JSON déjà nettoyé et optimisé.
Il est quand même important de nuancer ce choix. Multiplier les services (Frontend, Backend, DB) augmente forcément l'empreinte « dormante » des serveurs et complique la maintenance logicielle. Chaque échange entre ces couches crée aussi un petit surplus de consommation qu’une architecture plus directe n'aurait pas. Même si la consommation du backend reste dérisoire (0,000020 Wh), c’est un compromis, nous avons privilégié le confort du terminal utilisateur au prix d'une infrastructure globale un peu plus complexe.
Nous avons procédé à une mise à jour visuelle profonde en enrichissant notre bibliothèque CSS. Notre conviction est que l'éco-responsabilité ne doit pas se faire au détriment de l'expérience utilisateur.
Une interface soignée améliore l'accessibilité et la clarté de l'information. Cette refonte a permis d'harmoniser les parcours suivants :
- Pages d'accueil (Vidéos et Chaînes).
- Lecteur vidéo dédié.
- Espaces de gestion des chaînes.
Fig.8: Page d'accueil finale
Fig.9: Page de vidéo finale
Fig.10: Page de vidéo - commentaire
Fig.11: Page de chaine finale
Pour la manipulation des fichiers médias, nous avons intégré ffmpeg-fluent à notre image backend. La première fonctionnalité déployée est la génération automatique de miniatures.
Si l'utilisateur ne fournit pas d'image de couverture, le serveur utilise FFmpeg pour extraire une capture d'écran au milieu de la vidéo. Bien que pratique, cette fonctionnalité soulève des questions en matière d'éco-conception :
Note sur l'éco-conception : L'exécution de processus de traitement vidéo sur le serveur peut être énergivore. Bien que décidée dans l'enthousiasme du développement pour tester les capacités de l'outil, cette fonction mériterait d'être optimisée (par exemple, en limitant la résolution de l'extraction) pour rester cohérente avec nos engagements environnementaux.
Une fois le service fonctionnel, nous avons concentré nos efforts sur l'optimisation des ressources et la réduction de l'empreinte carbone de l'application, en intervenant sur deux axes majeurs.
Initialement, nos données suivaient un modèle relationnel classique. Cependant, ce choix architectural s'est révélé inefficace avec CouchDB, qui est une base de données NoSQL orientée documents ne supportant pas les jointures (JOIN).
Le problème identifié : Pour afficher une simple liste de 6 vidéos avec le nom de leur auteur, le backend devait effectuer :
- Une requête pour récupérer les 6 vidéos.
- Six requêtes supplémentaires (ou une requête filtrée complexe) pour récupérer les profils utilisateurs correspondants.
Cette multiplication des allers-retours entre le serveur et la base de données (I/O) augmentait inutilement la consommation énergétique du CPU et la latence réseau.
Comparaison des solutions :
| Solution | Avantages | Inconvénients |
|---|---|---|
| Design Views | Utilise les fonctions natives de CouchDB. | Exploite un comportement instable (include_docs), récupère trop de données inutiles et rend la recherche par Regex complexe. |
| Dénormalisation | Une seule requête suffit pour obtenir toutes les infos d'affichage. | Duplication des données et nécessité de mettre à jour plusieurs documents en cas de modification de profil. |
Arbitrage technique : Nous avons opté pour la dénormalisation. Les objets "Vidéo" et "Commentaire" embarquent désormais un objet "User" simplifié (nom, ID, avatar).
{
"_id": "v0",
"type": "video",
"user" : {
"id_user": "u123",
"name": "Nom Prénom",
"avatar": "uploads/avatars/default.png"
},
"date": "2024-10-07 14:30:00",
"name": "Titre de la vidéo",
"desc": "Description courte du contenu...",
"path": "uploads/videos/videoTest.mp4",
"thumbnail": "uploads/thumbnails/default.png",
"views": 4500
}{
"_id": "c0",
"type": "comment",
"user" : {
"id_user": "u123",
"name": "Nom Prénom",
"avatar": "uploads/avatars/default.png"
},
"id_video": "v456",
"date": "2025-01-12 10:15:00",
"content": "Message de l'utilisateur..."
}- Résultat : Le poids de la base est passé de 3.9 MB à 4.5 MB (+15%).
- Bénéfice Éco : Cette légère hausse du stockage est largement compensée par la suppression massive de requêtes HTTP et de traitements superflus côté backend, réduisant ainsi la charge serveur globale.
La vidéo est le média le plus énergivore du web. Pour répondre à cet enjeu, nous avons développez une fonctionnalité de Mode Podcast.
Fig.12: Mode podcast
L'idée est de dissocier le flux audio du flux vidéo lors de l'upload via FFmpeg. Cette fonctionnalité offre deux avantages majeurs pour l'éco-conception :
- Réduction de la bande passante : L'utilisateur peut choisir de n'écouter que l'audio. Le flux de données est alors grandement réduit, ce qui est idéal pour une écoute en mobilité ou avec une connexion limitée.
- Sobriété matérielle : La lecture d'un flux audio seul sollicite beaucoup moins le processeur (CPU/GPU) de l'appareil client, prolongeant ainsi l'autonomie de la batterie et réduisant la consommation électrique.
Cette option permet de transformer notre plateforme de streaming en un service hybride, s'adaptant au besoin réel de l'utilisateur tout en limitant son impact environnemental.
Voici l'analyse finale de notre projet.
| Étape du scénario | EcoIndex | GES (gCO2e) | DOM | Requêtes | Taille (ko) |
|---|---|---|---|---|---|
| 1. Chargement Accueil | 78 B 🟩 | 1.42 | 114 | 9 | 2875 |
| 2. Choisir une vidéo | 91 A 🟩 | 1.18 | 108 | 4 | 120 |
| 3. Retourner au menu | 91 A 🟩 | 1.76 | 114 | 3 | 1 |
| 4. Choisir une autre vidéo | 90 A 🟩 | 1.19 | 108 | 5 | 137 |
Tab.12 : Évaluation de l'impact du scénario "Consulter une vidéo - accueil" dans le prototype final.
| Étape du scénario | EcoIndex | GES (gCO2e) | DOM | Requêtes | Taille (ko) |
|---|---|---|---|---|---|
| 1. Chargement Accueil | 78 B 🟦 | 1.43 | 102 | 15 | 2938 |
| 2. Choisir une chaîne | 78 B 🟦 | 1.42 | 89 | 14 | 2855 |
| 3. Choisir une vidéo | 91 A 🟩 | 1.20 | 108 | 4 | 153 |
| 4. Retourner sur la chaîne | 92 A 🟩 | 1.14 | 89 | 2 | 3 |
| 5. Choisir une autre vidéo | 90 A 🟩 | 1.18 | 108 | 5 | 128 |
Tab.13 : Évaluation de l'impact du scénario "Consulter une vidéo - chaine" dans le prototype final.
L'aboutissement de ce projet valide l'hypothèse qu'une architecture rigoureuse limite drastiquement l'impact environnemental d'un service numérique. L'évaluation des scénarios "Accueil" et "Chaîne" démontre une efficience majeure, malgré la complexité des fonctionnalités, les émissions de GES stagnent autour de 1.4 gCO2e par étape. Le transfert de données est réduit à moins de 100 ko par page, soit une empreinte 30 fois inférieure à la moyenne du web (3000 ko selon HTTP Archive : https://httparchive.org/reports/page-weight).
Cette performance repose sur un backend agissant comme filtre, garantissant que seule la donnée utile atteint le client. L'augmentation du volume de données n'entraîne aucune croissance énergétique exponentielle, confirmant la scalabilité du modèle. De plus, avec un DOM maintenu sous les 200 éléments, l'application minimise la sollicitation matérielle.
L'obtention des scores EcoIndex A/B semble donc s'appuier sur ces trois leviers : la réduction des appels serveurs, l'optimisation des payloads JSON et une stratégie de mise en cache évitant les transferts redondants.
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | 0.0016 | 0.080 | 0.083 | ||
| Frontend | 0.0000034 | 0.0 | 0.0016 | 0.0 | 0.0016 | |
| CouchDB | 0.0 | 1.3e-7 | 0.0 | |||
| Backend | 0.00000017 | 0.000021 | 0.0 | 1.3e-7 | 0.0 | 0.000021 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.000036 | 0.0 | 0.0016 | 0.056 | 0.058 | |
| Frontend | 0.0000024 | 0.0 | 0.0016 | 0.0 | 0.0016 | |
| CouchDB | 0.0 | 0.0 | 0.0 | |||
| Backend | 0.00000018 | 0.000015 | 0.0 | 0.0 | 0.0 | 0.000015 |
| Composant | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0 | |||||
| Frontend | 0.0 | 0.0 | ||||
| CouchDB | 0.0 | 0.0 | ||||
| Backend | 0.00052 | 0.000040 | 0.0 | 0.044 | 0.0 | 0.044 |
Tab.14 : Estimation finale de la consommation énergétique de la consultation de l'accueil (a) d'une chaine (b) d'une vidéo (c).
L’analyse des mesures GreenFrame (Tab.14) confirme que l’architecture à trois couches est vraiment efficace. Contrairement à nos attentes, ajouter un backend n’a pas plombé le bilan énergétique, mais a permis de mieux répartir la charge de travail entre les composants. Le gain le plus parlant est sans aucun doute celui de la consultation vidéo (c) : le CPU du navigateur tombe de 0,0069 Wh à 0,0023 Wh. Ce déchargement massif montre que le backend fait bien son boulot de « pré-mâcheur », en gérant la logique métier sur le serveur, il évite au terminal de l’utilisateur de s'épuiser à faire des calculs inutiles.
Du côté de l’infrastructure serveur, les chiffres restent extrêmement bas notamment avec le Backend qui a un impact quasi invisible pendant la navigation (étapes a et b), avec une consommation dérisoire de l’ordre de
Finalement, sur les phases de navigation classique (a et b), on remarque que c'est l'écran qui pompe quasiment toute l'énergie (95 % du total). C'est la preuve que notre pile logicielle est devenue suffisament sobre que l'impact environnemental ne vient plus forcement de l'efficacité du code, mais en partie du matériel physique et de la manière dont l'utilisateur s'en sert.
Néanmois, il est intéressant de noter que les analyses précédentes présente certaines limites méthodologiques. Le périmètre étudié s'est concentré sur la consultation de l'accueil, des vidéos et des chaînes, laissant de côté des fonctionnalités comme l'upload ou les podcasts, susceptibles d'avoir des profils de consommation différents. De plus, les tests GreenFrame ont été réalisés sur des séquences de trente secondes. Si cette durée est pertinente pour observer le chargement et l'initialisation de l'application, elle ne reflète pas un usage réel sur la durée, où le streaming vidéo devient le principal poste de dépense énergétique.
Malgré les performances environnementales déjà obtenues, l'analyse du prototype met en évidence plusieurs axes d'amélioration, tant sur le plan technique que méthodologique. Ces améliorations n'ont toutefois pas toutes le même impact en termes de performance et de consommation de ressources.
Sur le plan logiciel, certaines optimisations relèvent d'ajustements relativement mineurs. La gestion du cycle de rendu côté frontend pourrait être affinée par une utilisation plus systématique des mécanismes d'optimisation fournis par React, comme useMemo ou useCallback. Leur absence dans certaines parties du code entraîne des re-rendus évitables du DOM, dont l'impact reste limité mais cumulatif. De la même manière, l'application ne met pas en œuvre de stratégie de purge des feuilles de style, ce qui conduit au chargement de règles CSS inutilisées, ce qui peut poser problème au vu de notre stratégie de CSS modulaire. La mise en place d'un tel mécanisme permettrait d'alléger légèrement les ressources chargées.
D'autres leviers offrent un potentiel d'amélioration plus significatif, notamment sur les formats et la compression des contenus multimédias. Les vidéos et audios sont encore diffusés majoritairement en MP4 et MP3, alors que des formats plus efficaces comme WebM ou Ogg permettraient de réduire sensiblement le volume de données transférées.
Cette optimisation pose toutefois la question du niveau de compression acceptable. Dans la mesure où l'audio et la vidéo participent directement à l'expérience utilisateur, une compression trop agressive peut dégrader la qualité perçue et nuire à l'usage. L'enjeu réside donc dans la recherche d'un compromis entre réduction des flux de données et maintien d'une qualité suffisante.
En parlant d'expérience utilisateur, la question de l'équilibre entre confort d'usage et sobriété peut aussi se poser. Les temps de chargement, notamment pour les vidéos, pourraient être mieux perçus grâce à l'utilisation de skeletons. Toutefois, ces éléments reposent souvent sur des animations CSS continues, dont le coût énergétique doit être évalué au regard du gain réel en ergonomie. Dans le même esprit, bien que le backend applique déjà des filtres, certains objets transmis au frontend contiennent encore des champs superflus. Une sélection plus stricte des données exposées permettrait de réduire la taille des échanges JSON et de limiter les transferts réseau.
Nous avons tous deux trouvé que ce projet a été une expérience particulièrement formatrice. On a appris à maîtriser une stack technologique moderne. L'utilisation de ReactJS a été un point clef, et même si nous avions déjà eu l'occasion de travailler avec, nous avons pu étendre nos compétences dans ce domaine. La création d'un backend solide avec Node.js et Express a également été très intéressante. Au-delà du code, l'intégration de Docker pour la conteneurisation et la mise en place de workflows de CI/CD via Git nous a sensibilisé aux exigences de déploiement et de qualité logicielle.
De plus, le coeur de cette UE résidant en l'éco-conception, nous avons pu apprendre à utiliser de nouveaux outils tels que GreenIT et GreenFrame. Cela nous a notamment appris à quantifier l'empreinte environnementale de nos choix techniques. Cette approche nous a forcés à remettre en question nos méthodes de développement pour privilégier une sorte de sobriété numérique, transformant ainsi un projet tel que nous en avons réalisé plusieurs dans le cadre d'autres UE, en une véritable réflexion sur la responsabilité de l'ingénieur. En effet, c'était pour notre part la première fois que nous devions porter autant d'attention aux impacts écologiques de nos codes. C'était donc une expérience très intéressante qui, en plus de nous avoir permis de nous améliorer sur un plan technique, nous a introduit à un sujet qui nous était alors que peu connu et qui s'est avéré être passionnant, mais surtout très important en vue de l'évolution de l'impact des technologies dans le monde. Grace à ce projet, nous avons tout les outils nous permettant d'être plus vigilant en matière d'éco-conception pour notre future projet. En nous questionnant sur l'utilité de certaines pratiques, pourtant ancrée dans les habitudes de développement de nos jours (comme par exemple l'architecture Back - Front qui peut se montrer désavantageuse dans certains cas).
Au terme de ce développement, GreenTube propose une plateforme de vidéo en ligne fonctionnelle et optimisée, couvrant un large éventail de fonctionnalités :
- Exploration et navigation : Consultation de vidéos via une page d'accueil dynamique ou par chaîne utilisateur.
- Gestion de contenu : Système d'upload de vidéos avec génération automatique de miniatures.
- Interactivité : Création de comptes, authentification simple et édition de profils personnalisés (avatars et descriptions).
- Recherche et filtrage : Tri avancé des contenus par date, popularité (vues/abonnés) ou via des expressions régulières (Regex) pour des recherches précises.
- Expérience utilisateur : Incrémentation automatique des vues au visionnage et mode "podcast" pour une consultation audio économe en ressources.
En conclusion, notre projet GreenTube démontre qu'il est possible de développer un service riche en fonctionnalités tout en maintenant un faible impact environnemental (Grade EcoIndex A/B). Ce projet marque pour nous une première étape réussie dans la conception de solutions numériques durables et scalables.
- Docker Desktop (installé et démarré)
- Node.js ( notre version étant la v22.20.0 )
- Un terminal bash (Git Bash sur Windows, WSL, ou terminal Unix)
Placez vous dans la racine du projet (cd ..) puis exécuter:
- ./setup_local.sh
Le script setup_local.sh vérifie que Docker est lancé, installe les dépendances du front-end et le build, génère des données de test, installe les dépendances du back-end, configure les variables CouchDB, puis démarre les containers Docker afin d'initialiser et lancer le projet en local.
Ouvrir son navigateur, et renseigner l'adresse de votre port 80 (http://localhost:80)
Le projet est normalement bien lancé et fonctionnel.
Footnotes
-
Estimation après part plateforme pour un créateur/diffuseur (source : https://agence-anode.fr/blog/marketing-digital/prix-google-ads-youtube/). ↩
-
Basé sur le coût total employeur du salaire médian 2025 soit 3569€ environ. (source : URSSAF) ↩