Éco-conception web : comment nous limitons l'empreinte numérique de nos projets CRM, ERP et sites sur mesure

Qu'est-ce que l'éco-conception web, concrètement ?

L'éco-conception numérique consiste à réduire l'empreinte environnementale d'un service numérique sur l'ensemble de son cycle de vie, de la conception jusqu'à l'hébergement, en passant par le développement et la maintenance. Le numérique représente aujourd'hui près de 4% des émissions mondiales de gaz à effet de serre, un niveau comparable au transport aérien. Chaque requête serveur inutile, chaque image mal compressée, chaque fonctionnalité qui n'a jamais servi consomme de l'énergie et mobilise des ressources matérielles.

Chez Revolucy, l'éco-conception s'appuie sur deux référentiels reconnus : le RGESN (Référentiel Général d'Écoconception de Services Numériques), piloté par l'Arcep et l'Arcom, et les 115 bonnes pratiques du collectif GreenIT.fr. Nous ne les appliquons pas comme une checklist administrative à cocher en fin de projet. Nous les traitons comme n'importe quelle autre exigence technique : intégrée dès la phase de conception, sur nos projets CRM, ERP et sites sur mesure.

Concevoir sobre, c'est concevoir mieux. Une application plus légère charge plus vite, coûte moins cher à héberger, reste plus simple à maintenir dans le temps. L'éco-conception et la performance ne sont pas deux objectifs concurrents, ce sont souvent la même chose vue sous deux angles différents.

Concevoir juste, dès la première ligne

L'éco-conception commence avant le code, dans la réflexion sur le besoin réel et le choix de la stack. Nous ne choisissons pas nos technologies par habitude ou par mode. Chaque projet fait l'objet d'une analyse du besoin fonctionnel pour déterminer la stack la plus sobre et la plus adaptée.

Pour la majorité de nos clients, un rendu serveur avec Django et HTMX suffit largement, sans avoir besoin d'un framework JavaScript lourd. C'est ce que nous avons mis en place pour un client éditeur d'ERP pour le secteur du spectacle vivant, qui gère plus de 120 000 contacts avec une stack Django + Tailwind + HTMX, sans framework JS lourd. Même logique chez une association nationale de la filière apicole, dont le CRM gère 15 000 apiculteurs sur une stack Python/Django sans aucune SPA. Et chez un client spécialisé dans les rapports d'inspection technique, toutes les librairies CSS/JS sont chargées en local, jamais via un CDN externe.

Chaque fonctionnalité est aussi pensée dans sa globalité avant d'être développée. Nous identifions les sous-cas, les cas limites et les évolutions probables dès la phase de spécification, ce qui évite les refontes coûteuses plus tard. Un client du secteur de l'imprimerie a vu son module devis / commandes / bon à tirer conçu d'emblée pour gérer des grilles tarifaires complexes, sans avoir eu besoin d'une refonte depuis. Un acteur de l'assurance collective a bénéficié du même principe : l'architecture multi-tenant a été pensée dès le premier jour du projet, pas ajoutée en rustine plus tard.

L'éco-conception s'applique aussi au design. Nous conseillons des polices système ou légères plutôt que des polices décoratives lourdes, des palettes de couleurs réduites et des composants réutilisables. Sur revolucy.fr, nous ne préchargeons que les trois polices réellement critiques et chargeons le reste des CSS en asynchrone. Sur une plateforme multilingue développée pour un client, un système d'internationalisation natif évite de dupliquer les contenus par langue, ce qui allège considérablement le poids total du site.

Un code back-end sobre et rigoureusement optimisé

Le back-end est le moteur invisible de toute application, et c'est là que se jouent les plus gros gains. Un algorithme mal pensé ou une requête base de données superflue peut consommer des centaines de fois plus de ressources que nécessaire. Nous développons exclusivement en Python/Django, un framework mature et reconnu pour ses pratiques durables, sur l'ensemble de nos projets ERP sur mesure et CRM sur mesure.

Nos pratiques concrètes, sur chaque projet :

• Complexité algorithmique maîtrisée : nous analysons systématiquement la complexité de nos traitements. Un tri en O(n log n) plutôt qu'en O(n²) sur 120 000 contacts, c'est une différence significative en consommation CPU.
• Minimisation des données stockées : nous ne sauvegardons que ce qui est strictement nécessaire. L'outil django-dirtyfields détecte les champs réellement modifiés et n'écrit en base que le delta.
• Cache intelligent : sur la Plateforme Opale, Redis met en cache les résultats de requêtes coûteuses ; sur revolucy.fr, WhiteNoise sert les fichiers statiques avec un cache immuable de dix ans.
• Limitation des appels base de données : select_related et prefetch_related sont utilisés systématiquement pour éviter le classique problème des requêtes N+1.
• Principes SOLID respectés : un code modulaire et réutilisable réduit la dette technique et évite les réécritures inutiles, donc les ressources gaspillées à refaire deux fois le même travail.
• Tâches asynchrones : les traitements lourds (emails, exports, compressions) sont délégués à django-q2 en arrière-plan, ce qui libère le serveur pour les requêtes utilisateur.

Nous mutualisons aussi du code entre projets. Notre package interne module-retour-client-revo, dédié à la gestion des tickets SAV et distribué via PyPI, est déployé sur l'ensemble de nos projets clients : un seul code source à maintenir, zéro duplication.

Chaque octet compte côté navigateur

Le front-end est le point de contact avec l'utilisateur final, et souvent le plus gros poste de gaspillage numérique. Un site web moyen charge aujourd'hui plus de 2 Mo de données et effectue plus de 70 requêtes HTTP. Nous faisons le choix délibéré de rester bien en dessous de ces seuils.

Nos images sont converties automatiquement en WebP via django-webp-converter sur la quasi-totalité de nos projets, avec un lazy loading natif sur toutes les images sous la ligne de flottaison et un fetchpriority="high" réservé à l'image hero. Le CSS et le JS sont minifiés puis compressés en Gzip via django-compressor ; sur la Plateforme Opale, nous poussons jusqu'à Brotli et Zopfli pour des ratios de compression encore supérieurs.

Notre choix technique le plus structurant reste HTMX plutôt qu'un framework SPA. HTMX ne pèse que 14 Ko gzippé et permet des mises à jour partielles de page sans télécharger un runtime JavaScript de 300 Ko et plus. Sur nos interfaces métier, CRM et ERP en particulier, nous appliquons une règle simple : zéro carrousel, zéro animation superflue. Chaque pixel doit être fonctionnel. Sur les sites vitrine, les animations restent mesurées et servent la lisibilité, jamais la décoration pour elle-même. Et sur tous nos projets, les librairies front comme Tailwind, Alpine.js ou Chart.js sont servies en local, jamais depuis un CDN tiers : zéro requête réseau supplémentaire vers des serveurs externes.

Sur un projet de rapports d'inspection technique, cette convention est même documentée noir sur blanc dans le fichier CLAUDE.md du projet : les librairies CSS et JS sont toujours chargées depuis static/lib/, jamais via CDN. Sur notre outil interne Core Revolucy, la classe abstraite BaseHTMXListView réutilisable pagine par 20 éléments (100 maximum), filtre et trie côté serveur, et ne retourne que le fragment HTML strictement nécessaire via django-render-block, pas la page entière.

Un hébergement dimensionné, pas surdimensionné

L'infrastructure est souvent le parent pauvre de l'éco-conception. Pourtant, un serveur surdimensionné qui tourne à 5% de charge consomme presque autant qu'un serveur chargé à 50%. Chez Revolucy, nous dimensionnons nos infrastructures au plus juste du besoin réel, pas à ce qu'on pourrait vendre de plus impressionnant.

Nos projets sont hébergés en France à 100%, ce qui réduit la latence réseau et le nombre de sauts entre le serveur et l'utilisateur final. Nous choisissons un VPS avec 2 Go de RAM plutôt qu'un cluster Kubernetes quand la volumétrie réelle du projet ne justifie pas davantage. Nos containers utilisent une image Python allégée d'environ 50 Mo plutôt que l'image standard qui pèse près de 900 Mo, ce qui se traduit par des images Docker de 150 à 200 Mo au lieu d'un gigaoctet et plus sur nos projets récents.

Côté déploiement, nous limitons volontairement les pipelines : un script de déploiement simple, un test local, une mise en production ciblée. Chaque build CI consomme de l'énergie, nous ne déclenchons donc des builds que lorsque c'est nécessaire. Selon les projets, nous utilisons Caddy comme reverse proxy, qui gère le HTTPS automatiquement via Let's Encrypt sans configuration complexe : moins de couches logicielles, moins de consommation. Sur revolucy.fr par exemple, une configuration Nginx dédiée applique un cache longue durée (expires 1y, Cache-Control: public, immutable) sur l'ensemble des fichiers statiques, avec un score PageSpeed cible de 90 à 95 en desktop.

Nous restons aussi attachés à une philosophie monolithique. Un monolithe Django bien structuré, avec des applications modulaires et des responsabilités séparées, est plus performant et moins gourmand qu'une architecture microservices pour la grande majorité des cas d'usage de nos clients PME et ETI. C'est parfois moins impressionnant sur un slide, mais c'est ce qui fonctionne. Sur un projet de gestion des alternants pour un opérateur de formation en alternance, où la charge varie fortement selon les périodes, nous avons fait le choix inverse et déployé une infrastructure Kubernetes dimensionnée à la demande chez un cloud français, avec des pods auto-scalés selon la charge réelle. L'éco-conception, ce n'est pas une seule recette appliquée partout, c'est le bon dimensionnement pour chaque projet.

L'IA, oui, mais seulement quand c'est justifié

L'intelligence artificielle est un outil puissant, mais aussi l'un des plus gourmands en ressources du numérique. Une seule requête à un grand modèle de langage consomme 10 à 100 fois plus d'énergie qu'une recherche classique. Nous intégrons l'IA dans nos projets d'IA sur mesure avec la même rigueur que le reste : uniquement quand il n'existe pas d'alternative plus sobre.

Notre grille de décision est simple et nous nous y tenons :

1. Le besoin peut être couvert par une règle métier ? Pas d'IA.
2. Un algorithme classique, comme une regex ou un traitement statistique, suffit ? Pas d'IA.
3. Du machine learning classique avec scikit-learn répond au besoin ? On y va, sans passer par un LLM.
4. Un LLM est vraiment nécessaire ? On choisit le modèle le plus petit possible, avec mise en cache des résultats.

Quand l'IA est justifiée, nous privilégions les fournisseurs français ou européens, Mistral AI en tête, ou au minimum un hébergement en Europe. Et pour les tâches de classification, de scoring ou de détection d'anomalies, nous préférons le machine learning classique avec scikit-learn à un LLM surdimensionné pour le besoin.

Sur notre module de gestion des tickets SAV, le chatbot IA aide les agents à rédiger leurs réponses, mais le routage et la classification des tickets restent gérés par des règles métier simples, pas par de l'IA. Sur notre outil de veille technologique, l'API Anthropic synthétise des articles en traitement batch, jamais en temps réel : les résultats sont stockés en base et réutilisés plutôt que régénérés à chaque consultation.

Qui fait quoi sur un projet éco-conçu

L'éco-conception n'est pas un chapitre qu'on ajoute à la fin d'un cahier des charges. C'est une manière de poser les questions dès le premier atelier de cadrage : quel besoin fonctionnel réel, quelle stack la plus sobre pour y répondre, quel hébergement pour la charge réellement attendue. Nous l'appliquons depuis 2014 sur nos projets, et ça reste, encore aujourd'hui, la meilleure manière que nous connaissions de livrer des outils qui durent. Retrouvez l'ensemble de nos réalisations ou notre approche complète sur la page agence.