Le SaaS multi-tenant rend la mesure carbone plus difficile que la formule — parce que vous devez répondre à des questions d'attribution : « Quel usage de quel tenant a généré quelles émissions ? » Pour les workflows orientés CSRD/ESRS E1, une allocation cohérente est souvent ce qui transforme un dashboard en artefact de reporting.
Suivre ce poste en production →
Envoyez les volumes de tokens vers notre API — mêmes coefficients que cet article. Offre gratuite, sans carte bancaire.
1) Attribuer les données d'activité via tenant_id (ou équivalent)
Votre meilleur levier est le même qu'en facturation et en analytics : une clé stable qui relie les événements d'inférence au contexte client/tenant. Dans de nombreuses architectures, il s'agit du tenant_id.
Si votre pipeline d'utilisation ne comporte pas d'attribution par tenant, vous pouvez toujours calculer des totaux — mais l'allocation devient une étape manuelle ultérieure (et l'assurance sera plus difficile).
2) Séparer test et production (si votre périmètre l'exige)
De nombreuses équipes exécutent des évaluations, du staging et des expérimentations. Si ceux-ci doivent être exclus (ou traités différemment), conservez des agrégations séparées :
- événements de test (QA, benchmarks, R&D) vs
- événements live (inférence de production à destination des clients)
3) Gérer le trafic partagé de manière délibérée
Tous les appels d'inférence n'appartiennent pas clairement à un seul tenant. Exemples courants :
- tâches d'arrière-plan au niveau système
- routes « copilote » partagées qui mélangent des contextes
- appels fournisseurs servant plusieurs tenants avant séparation
Définissez votre règle d'allocation une fois et documentez-la. Même si vous commencez par une règle « au mieux », c'est la documentation qui maintient l'auditabilité du processus.
4) Maintenir la cohérence du mapping des coefficients
L'allocation est en aval de l'exactitude. Si deux événements partagent le même tenant_id mais correspondent à des lignes de coefficients différentes en raison de changements d'identifiant de modèle, vos totaux par tenant seront bruités. Utilisez des clés de modèle stables et conservez une table de mapping versionnée.
Conseil pratique : lorsque vous publiez des totaux par tenant, incluez un court « en-tête de méthodologie » afin que la même table de coefficients puisse être reconstruite ultérieurement.
5) Transformer l'allocation en artefact de reporting
Le travail d'allocation n'a de valeur que s'il fait partie de votre workflow de reporting. Par exemple :
- Produire des totaux par tenant pour la même fenêtre de reporting que celle utilisée dans votre divulgation climatique.
- Conserver une annexe d'hypothèses (incertitudes, limites, et comment le trafic partagé a été traité).
- Ajouter optionnellement une note de contexte de classification pour les discussions Scope 3 (cadrage catégorie 1 vs 11).
- S'assurer que la sortie est reproductible (mêmes entrées → mêmes totaux, avec les versions de coefficients enregistrées).
Conclusion
Dans un SaaS multi-tenant, le défi du « reporting carbone » est essentiellement un défi d'ingénierie des données : attribution, séparation test/live, et mapping stable vers les coefficients. Une fois que ceux-ci sont cohérents, le calcul tokens-vers-CO₂e devient simple — et votre narrative ESRS E1 devient crédible.