Sécurité technique : conformité, sous-traitants, audit
Documentation technique pour le RSSI, la direction des achats et les commissaires aux comptes. Tout est daté ; les engagements futurs portent une cible trimestrielle. Les documents de revue RGPD, le DPA et la roadmap SOC 2 sont centralisés. Pour une vue commerciale « pourquoi nous faire confiance », voir /trust.
L'application et l'API tournent sur Cloudflare Workers (OpenNext) ; Supabase pour les données métier.
L'estimation utilise les comptes de tokens. Le texte des conversations ne traverse jamais nos systèmes.
Les clés API sont hachées, les webhooks peuvent être signés, et la méthodologie de calcul reste publique et reproductible.
Documents techniques et DPA pour accélérer votre analyse interne, sans remplacer votre validation juridique.
Hébergement & cohérence carbone
L'application carbon-llm tourne sur Cloudflare Workers (déploiement via OpenNext) plus une base Supabase. Cloudflare se déclare net-zéro Scope 1+2 depuis 2022 , pertinent pour la cohérence du discours d'une plateforme qui mesure le carbone IA. Cela ne remplace pas votre propre déclaration Scope 3 (l'hébergement de carbon-llm relève de notre Scope 1+2, pas du vôtre), mais cela évite l'ironie d'une application climat hébergée sur une infrastructure carbonée.
Mesures techniques en place
- Estimation sans prompt.
POST /api/v1/estimate,/batch-estimateet/trackn'acceptent que des nombres (modèle, tokens, tenant_id). Aucun corps de prompt requis ni stocké. - Clés API hachées (SHA-256 du poivre concaténé à la clé). Ce n'est pas un HMAC. Le poivre est
API_KEY_HASH_PEPPER. Les colonnes en clair ont été retirées par la migration 003. La recherche se fait sur l'empreinte. - Journal d'activité. La table
account_activity_logest créée par la migration 015. Aucun code du dépôt n'y insère de ligne, la route /dashboard/security n'existe pas, et aucun trigger n'interdit la modification. Ce n'est pas un journal immuable en service. - Méthodologie reproductible. Nos coefficients sont publics et datés (
method_version) : vous pouvez recalculer nos estimations à partir du CSV des événements, voir /methodology/standards. - Secrets des connecteurs. Les clés fournisseurs sont chiffrées dans l'application en AES-256-GCM (
lib/connectors/encrypt.ts), avecCONNECTOR_MASTER_KEYqui ne va pas en base. Le commentaire de la migration 016 mentionnepgp_sym_encrypt: ce n'est pas le mécanisme du code.
Sous-traitants (Article 28 RGPD)
Liste des sous-traitants que le code appelle vraiment. Les traceurs publicitaires (LinkedIn, Meta) et PostHog ne sont des sous-traitants effectifs que si leur variable d'environnement est renseignée. Voir aussi /legal/dpa. Il n'y a pas de page /security/subprocessors : cette liste est la liste.
| Sous-traitant | Rôle | Région | DPA | Mis à jour |
|---|---|---|---|---|
| Cloudflare Workers | Exécution de l'application (OpenNext) et du CDN. Les routes de carbon-llm.com sont servies par le Worker. | Anycast Cloudflare. Le dépôt ne fixe pas une région unique pour le calcul. | DPA | 2026-11-11 |
| Supabase | PostgreSQL, Auth (session et connexion Google) et stockage métier. Les politiques RLS des tables sensibles refusent anon et authenticated (migrations 029 et 031) : l'API passe par la clé service. | Région du projet Supabase, à lire dans le tableau de bord du projet. Le dépôt ne la redéclare pas. | DPA | 2026-11-11 |
| Connexion OAuth (via Supabase Auth) et, après consentement, mesure d'audience Analytics (identifiant présent dans le code : G-XV8TSMEKM4). Les pixels LinkedIn et Meta et PostHog ne partent que si leur variable NEXT_PUBLIC_* est définie, et seulement après le même consentement. | Selon le contrat Google. Non précisée dans le dépôt. | DPA | 2026-11-11 | |
| Resend | E-mail transactionnel, lorsque l'envoi est configuré. | Selon le contrat Resend. Non précisée dans le dépôt. | DPA | 2026-11-11 |
| Stripe | Paiement, lorsque les clés Stripe sont configurées. Le paiement hébergé est créé côté serveur (Checkout), le navigateur n'embarque pas Stripe.js. | Selon le contrat Stripe. Non précisée dans le dépôt. | DPA | 2026-11-11 |
Roadmap SOC 2 Type II
SOC 2 Type II n'est pas certifié. Les dates qui figuraient ici (2026-Q3 pour le MFA, 2027 pour SOC 2) ne correspondent à aucun travail en cours dans le code : elles sont retirées plutôt que repoussées. Ce qui est « en place » est vérifiable dans le dépôt.
| Contrôle | Statut | Cible |
|---|---|---|
| TLS terminé par Cloudflare sur les routes publiques (le dépôt n'impose pas TLS 1.3 seul) | En place | n/d |
| Secrets des connecteurs chiffrés AES-256-GCM dans l'application (lib/connectors/encrypt.ts), clé CONNECTOR_MASTER_KEY hors base | En place | n/d |
| Clés API stockées en SHA-256(poivre + clé), jamais en HMAC et plus en clair (migration 003) | En place | n/d |
| RLS en refus par défaut sur les tables sensibles (migrations 029 et 031) | En place | n/d |
| Journal account_activity_log : la table existe, aucun code n'y écrit, aucune page /dashboard/security, aucun trigger n'interdit UPDATE | Planifié | non daté |
| MFA des administrateurs : aucun facteur n'est exigé par le code | Planifié | non daté |
| Pen-test annuel par un tiers | Planifié | non daté |
| SOC 2 Type II | Planifié | non daté |
Énoncé de reproductibilité
Le dashboard expose la période, les modèles, les coefficients utilisés et la version de méthodologie. Un commissaire aux comptes peut prendre le CSV des événements + la table de coefficients à la version verrouillée et relancer le calcul pour comparer les totaux. C'est une base de discussion pour une assurance limitée ISAE 3000, pas une signature de tiers. Voir /methodology/standards.
Documents juridiques
- Politique de confidentialité (Privacy)
- Accord de traitement des données (DPA, Article 28 RGPD)
- CGU
- Support DPIA, disponible sur demande pendant la phase d'accès anticipé
- Page de statut (sans pourcentage de disponibilité)
Questions ? Nous contacter · Sources · Crosswalk standards · Tokens côté demande