Comment nous fonctionnons de façon écologique — et comment nous le mesurons

1. Efficace par son architecture

Le cœur de PeakSpitz s’exécute sous forme de code natif compilé, et non comme une pile applicative interprétée. Cela compte sur le plan énergétique, car le travail que le processeur effectue pour servir une requête est celui qui est mesuré — et émis.

• • Base indépendante : les études évaluées par les pairs qui classent les langages de programmation selon leur consommation d’énergie placent systématiquement les langages compilés parmi les plus sobres et les langages interprétés parmi les moins sobres — souvent d’un ordre de grandeur à tâche équivalente. Nous citons cela comme le fondement catégoriel de notre choix de conception. Nous n’en tirons aucun multiplicateur chiffré propre à PeakSpitz.
• ✓ Ce que nous affirmons : le moteur de PeakSpitz appartient par construction à la classe des logiciels sobres en énergie.
• ✗ Ce que nous n’affirmons pas : un chiffre du type « X % d’énergie en moins que le concurrent Y ».

2. Un hébergement dimensionné au juste besoin

Chaque client dispose d’un déploiement isolé et dédié, configuré pour son activité — et non un monolithe polyvalent partagé où tous les modules restent chargés.

Les capacités inutilisées ne sont pas maintenues en chauffe. Notre architecture est pilotée par la configuration plutôt que dupliquée par secteur : la surface active d’un client se limite donc à ce qu’il utilise réellement. Résultat : vous ne dépensez pas de calcul — ni d’argent — à faire tourner des fonctionnalités dont vous ne vous servez pas.

3. Infrastructure verte et choix de région

PeakSpitz peut fonctionner sur plusieurs substrats et plusieurs régions. Là où c'est géographiquement disponible, un client peut choisir un déploiement plus vert. La base factuelle, ce sont les données publiées par les fournisseurs eux-mêmes :

• • Efficacité des centres de données (PUE) : les opérateurs que nous utilisons publient leurs indicateurs de Power Usage Effectiveness. Certains opérateurs européens sur lesquels nous pouvons fonctionner se distinguent par un PUE bas obtenu grâce à des techniques telles qu’un refroidissement à eau propriétaire. Nous renvoyons vers les chiffres publiés à jour par l’opérateur plutôt que de reprendre une valeur susceptible de se périmer.
• • Intensité carbone du réseau et énergie décarbonée : les régions diffèrent fortement par la propreté de leur réseau électrique. Là où nous fonctionnons sur un grand cloud public, ce fournisseur publie par région les pourcentages d’énergie décarbonée et les données carbone du réseau ; nous nous en servons pour déterminer quelles régions comptent comme « plus vertes ».
• • Résidence des données dans l’UE : les options de régions plus vertes incluent des déploiements hébergés dans l’UE.

Nous renvoyons délibérément vers les données en direct des fournisseurs plutôt que de citer ici des valeurs PUE/CFE figées — citer un chiffre gelé est la façon dont une page méthodologie devient discrètement inexacte. Demandez-nous les chiffres actuels pour une région donnée. Nous maintenons toujours la réserve : « là où c'est géographiquement disponible. »

La pièce maîtresse de notre feuille de route, c'est l'efficacité pilotée par le client:

• • Eco Windows : un client pourra définir des fenêtres de basse consommation sur un calendrier à résolution journalière. Pendant ces fenêtres, l'instance fonctionne en mode réduit, ce qui abaisse sa consommation de calcul — et donc son coût de calcul.
• • Récupération en pool partagé : la capacité libérée pendant une fenêtre de basse consommation est rendue à un pool partagé plutôt que laissée inutilisée, afin qu'elle puisse servir ailleurs. La logique de durabilité se joue à l'échelle du parc : réutiliser la capacité signifie que l'ensemble du parc provisionne et alimente moins de matériel au total pour la même quantité de travail.

Statut et transparence : tant que cette fonctionnalité n'est pas livrée et que nous ne pouvons pas décrire le mécanisme exact de récupération, nous la présentons comme un engagement déclaré, et non comme une fonctionnalité disponible. Nous mettrons cette section à jour — avec le mécanisme réel et les éventuelles mesures — dès qu'elle sera disponible.

5. Comment nous mesurons

Nous sommes explicites sur notre maturité de mesure actuelle plutôt que de laisser croire à mieux :

• • Aujourd'hui : nous raisonnons à partir de faits structurels (classe de moteur, modèle de tenancy) et des données d'infrastructure publiées par les fournisseurs (PUE, CFE, intensité carbone du réseau).
• • En construction : une visibilité calcul/énergie par tenant, pour qu'un client puisse voir l'empreinte de son propre usage — et les économies liées aux Eco Windows — à la résolution journalière, la granularité même sur laquelle opère le calendrier.
• • Les référentiels que nous suivons : le reporting PUE/WUE des centres de données, la méthodologie d'énergie décarbonée des fournisseurs cloud et les approches reconnues d'intensité carbone logicielle. Nous nous alignons dessus plutôt que d'inventer notre propre notation.

6. Ce que nous n'affirmons pas (encore)

Nous ne dirons rien de ce qui suit tant que chaque point n'aura pas été mesuré et la méthode publiée :

Dès que l'un de ces points deviendra démontrable, il apparaîtra ici avec sa méthode, et seulement à ce moment-là, sur notre page durabilité.

Journal des modifications

• • 23 juin 2026 — Page créée (posture de positionnement ; référentiel méthodologique). Eco Windows et la récupération figurent sur la feuille de route.