name: ecocode-front
description: Use when analyzing the ecological impact of front-end code: assets weight, HTTP requests, JavaScript bundles, CSS, images, fonts, browser rendering, lazy loading, caching, or web performance from a green IT perspective.
EcoCode Front — Analyse éco-conception côté client
Vue d'ensemble
Sous-skill spécialisé dans l'audit éco-conception front-end. Mappe chaque problème détecté aux bonnes pratiques Green IT correspondantes via le MCP mcp-greenit.
REQUIRED PARENT SKILL: audits — ce sous-skill est délégué par le skill parent.
Collecte précise (obligatoire pendant l'analyse)
Pendant toute l'analyse, pour chaque problème détecté, noter immédiatement dans le contexte :
- Chemins exacts :
src/components/Hero/hero.png, public/assets/logo.png
- Valeurs mesurées : taille en KB, nombre de nœuds DOM, URLs de scripts tiers
- Extrait de code : la ligne ou le bloc précis qui pose problème
- Contexte d'usage : dimensions d'affichage, fréquence d'appel, etc.
Ces données ne sont pas affichées dans le rapport light mais servent à générer le guide de correction complet si l'utilisateur le demande — sans relire les fichiers.
Sources d'analyse
| Source | Méthode |
|---|
| Fichiers locaux | Lire les fichiers source (HTML, JS, CSS, configs) |
| URL fournie | Utiliser Playwright pour inspecter le rendu et le réseau |
| Les deux | Combiner analyse statique + analyse runtime |
Axes d'analyse
1. Design, UX et conception
Consulter : mcp-greenit : greenit_chercher_fiche avec "mobile", "parcours", "design", "fonctionnalités"
Vérifier :
2. Assets images, vidéos, sons et documents
Consulter : mcp-greenit : greenit_chercher_fiche avec "images", "vidéo", "son", "médias", "compression"
Vérifier :
3. Requêtes HTTP et réseau
Consulter : mcp-greenit : greenit_chercher_fiche avec "requêtes HTTP", "réseau", "domaines", "redirections"
Vérifier :
4. JavaScript — bundles et exécution
Consulter : mcp-greenit : greenit_chercher_fiche avec "JavaScript", "bundle", "dépendances", "bibliothèques"
Vérifier :
5. Rendu côté client — DOM et re-renders
Consulter : mcp-greenit : greenit_chercher_fiche avec "DOM", "rendu", "reflow", "repaint"
Vérifier :
6. Lazy loading et mise en cache
Consulter : mcp-greenit : greenit_chercher_fiche avec "cache", "lazy loading", "Service Worker"
Vérifier :
7. CSS
Consulter : mcp-greenit : greenit_chercher_fiche avec "CSS", "sélecteurs", "feuilles de style"
Vérifier :
8. Build, compression et déploiement
Consulter : mcp-greenit : greenit_chercher_fiche avec "minification", "compression", "build", "CDN"
Vérifier :
Analyse via Playwright (si URL disponible)
Protocole d'authentification
Avant toute analyse, détecter et gérer un éventuel mur d'authentification.
Détection d'un mur d'auth :
- URL redirigée vers
/login, /signin, /auth, /connexion, /sso, etc.
- Page contient
input[type="password"]
- Réponse HTTP 401 ou 403
- Redirection vers un provider OAuth externe (Google, Microsoft, Okta…)
Protocole de gestion :
1. Naviguer vers l'URL cible
2. Prendre un snapshot → vérifier URL + présence d'un formulaire de connexion
3. Si mur d'auth détecté :
a. Demander à l'utilisateur : identifiant + mot de passe
b. Remplir le formulaire et soumettre
c. Prendre un snapshot → vérifier si un 2FA est demandé
4. Détection du type de 2FA :
- Champ OTP (6 chiffres, label "code", "authenticator", "vérification") → TOTP
- Mention "SMS" ou "code envoyé par message" → SMS
- Mention "approbation", "push", "Duo", "notification" → push notification
- Clé physique / WebAuthn (mention "clé de sécurité", "FIDO") → non automatisable
5. Gestion par type :
- TOTP / SMS : demander le code à l'utilisateur, le saisir dans le champ, soumettre
- Push : demander à l'utilisateur d'approuver la notification, attendre la redirection (timeout 60s)
- WebAuthn : IMPOSSIBLE À AUTOMATISER — prévenir l'utilisateur, proposer de passer l'analyse URL
6. Vérifier le succès : URL revenue sur la cible, absence de formulaire d'auth
7. Reprendre l'analyse normale
Cas non gérés — arrêter et avertir :
- Clé physique WebAuthn/FIDO2 (impossible d'interagir avec le matériel)
- CAPTCHA visuel ou audio
- Authentification biométrique
Étapes d'analyse réseau
1. Naviguer vers l'URL (après authentification si nécessaire)
2. Intercepter les requêtes réseau → lister ressources, tailles, types, domaines
3. Mesurer DOMContentLoaded, Load, LCP, CLS
4. Capturer le nombre de nœuds DOM
5. Calculer : total des requêtes HTTP + taille totale transférée en KB
6. Appeler mcp-greenit : greenit_calculer_ecoindex avec {dom_nodes, requests, size_kb, url}
7. Lister les scripts tiers et leur poids
8. Vérifier les headers de cache (Cache-Control, Expires, ETag)
9. Vérifier le protocole (HTTP/1.1 vs HTTP/2)
10. Détecter les redirections (301, 302)
11. Vérifier la lecture automatique audio/vidéo
12. Contrôler la présence d'un Service Worker
Format de rapport
## Analyse Front-end
### EcoIndex
| Métrique | Valeur mesurée |
| ----------------- | -------------- |
| Nœuds DOM | XXX |
| Requêtes HTTP | XX |
| Taille transférée | X,X MB |
| **EcoIndex** | **XX/100** |
| **Grade** | **A** |
| CO2 / page vue | X,XX gCO2e |
| Eau / page vue | X,XX cl |
### Problèmes détectés
| # | Problème | Fichier/URL | Sévérité | Pratique Green IT |
| --- | --------------------------------- | ---------------- | -------- | ------------------------------------------------------ |
| 1 | Images PNG non converties en WebP | /assets/hero.png | Haute | RWEB_0049 — Optimiser les images |
| 2 | Bundle JS 450Ko non splitté | main.bundle.js | Haute | RWEB_0015 — N'utiliser que les portions indispensables |
### Détail par problème
**[Numéro]. [Intitulé du problème]**
- **Pratique Green IT :** RWEB_XXXX — [intitulé officiel]
- **Sévérité :** Haute / Moyenne / Faible
- **Constat :** [Ce qui a été observé]
- **Impact :** [Ressources gaspillées : bande passante, CPU, énergie]
- **Correction proposée :** [Action concrète]
### Bonnes pratiques déjà respectées
- [Liste des points positifs avec RWEB_XXXX correspondant]
Mapping sévérité
| Sévérité | Critères |
|---|
| Haute | Impact direct sur réseau ou CPU, visible pour tous les utilisateurs |
| Moyenne | Impact significatif sur une portion des utilisateurs ou des cas d'usage |
| Faible | Optimisation marginale, gain < 5% sur les métriques |
Erreurs fréquentes
- Analyser sans mcp-greenit : toujours mapper au numéro RWEB_XXXX officiel
- Sévérité subjective : baser la sévérité sur la fréquence d'exposition et le volume de données impliqué
- Oublier l'analyse runtime : l'analyse statique seule manque les requêtes dynamiques, les autoplay, les scripts tiers
- Confondre optimisation image et format : RWEB_0049 (optimisation/compression) ≠ RWEB_0048 (dimensionnement)
Format du guide de correction complet
Généré uniquement si l'utilisateur le demande, depuis les données collectées. Ne pas relire les fichiers.
Pour chaque problème du rapport light, produire une section dans cet ordre :
Problème N — [Titre du problème]
Pratique : RWEB_XXXX — [intitulé officiel de la fiche Green IT]
Sévérité : Haute / Moyenne / Faible
Éléments trouvés dans ton code :
chemin/exact/fichier.ext ([taille] KB) — [contexte : affiché en Xpx, chargé sur chaque page, etc.]
chemin/exact/autre-fichier.ext ([taille] KB) — [contexte]
Impact estimé : [chiffre concret, ex: -74% bande passante, -2 requêtes bloquantes]
Avant :
[extrait exact du code trouvé dans le projet, avec le chemin en commentaire]
Après :
[code corrigé, adapté au projet analysé — pas un exemple générique]
Étapes :
- [Action précise sur les fichiers listés ci-dessus]
[commande exacte si applicable, avec les vrais noms de fichiers]
- [Étape suivante]
- [Vérification : comment confirmer que le problème est résolu]
Outils recommandés :
[nom-outil] — [description en une ligne] : [commande d'installation]
Règles impératives :
- Les fichiers listés sont ceux réellement trouvés pendant l'analyse, jamais des exemples génériques
- Le code "Avant" est extrait du projet, le code "Après" est adapté à sa stack (React, Vue, Vite, etc.)
- Les commandes incluent les vrais noms de fichiers collectés pendant l'analyse
- Si plusieurs fichiers ont le même problème, les lister tous explicitement