Détectez les I/O gaspillées de vos traces. Chiffrez-les en énergie et carbone.
Perf Sentinel repère les N+1, appels redondants, requêtes lentes et fanout dans vos traces OpenTelemetry, en quality gate CI ou en daemon OTLP, puis convertit chaque I/O évitable en énergie et en CO₂.
Un projet open-source porté parl’Institut du Numérique Responsable
CRITN+1 HTTPGET /api/cart/enrich12 appels → 1
11 appels évitables, corrigeable à inventory/enrich.py:88. Un finding de la démo ci-dessous, onglet Findings.
GET catalog-svc/api/products/{id} · 110 ms · 1 utile, 11 évitablesinventory/enrich.py:88endpoint batch
?ids=…, 12 appels → 1Le synoptique montre Perf Sentinel de l'intérieur, de la carte des environnements jusqu'aux règles de détection.
Pourquoi Perf Sentinel ?
Les anti-patterns d’I/O touchent toute application, monolithe comme microservices. En distribué, une requête traverse plusieurs services en cascade, et le gaspillage n’apparaît qu’en regardant la trace entière.
Perf Sentinel lit les traces que votre application émet déjà (SQL, HTTP, publications vers un broker), quel que soit le langage ou l’ORM : il voit les requêtes générées, sans avoir besoin de comprendre JPA ou EF Core.
Chaque I/O évitable est aussi chiffré en énergie et en CO₂, par le bas et attribuable au code.
Prérequis : vos services émettent des traces OpenTelemetry de leurs appels base de données, HTTP et messagerie, ou des traces Datadog via un Collector OpenTelemetry.
Vérifiez d’abord votre instrumentation : un appel base de données ou HTTP enregistré sans sa requête ou son URL est écarté. Un rapport maigre peut signaler une application saine ou une instrumentation lacunaire.
Ce que ce n’est pas : un APM complet, un profileur continu, ni (pour le moment) une plateforme autonome de comptabilité carbone réglementaire. Voir le comparatif.
Maturité : bêta, pré-1.0, les commandes et la configuration peuvent donc encore changer. En production dans une équipe depuis juin 2026.
Douze anti-patterns d'I/O, au niveau protocole
Sur les requêtes SQL et HTTP que vos services émettent déjà, quel que soit le langage ou l’ORM.
Huit patterns de répétition et de lenteur, par protocole :
Exemple : le N+1 de la démoinventory-svc · GET /api/cart/enrich · 12 appels → 1
GET /api/cart/enrich
inventory/enrich.py:88 avec un endpoint batch ?ids=…. Le même finding est dans la démo, onglet Findings.Et quatre patterns de structure :
Chaque finding embarque : type, sévérité, template normalisé, occurrences, endpoint source, suggestion, localisation source et impact GreenOps. En mode daemon, s’y ajoute la corrélation cross-trace.
Chaque finding indique sa sévérité, le template en cause, l’endpoint source, une suggestion de correction et son impact GreenOps.
Compatible avec vos langages, frameworks et ORM
La détection lit le protocole, elle fonctionne donc avec tout environnement d’exécution qui émet des traces OpenTelemetry. Ceux ci-dessous ont en plus un guide de mise en place ou des conseils de correction écrits pour eux.
Guides de mise en place par langage →1 binaire, 2 modes, 4 façons de le déployer
Avec un assistant de code IA
Un plugin amène Perf Sentinel dans le changement sur lequel vous travaillez. Il demande avant chaque modification.
Disponible aujourd’hui pour Claude Code.
- avant la production
/perf-sentinel:perf-testsÉcrit des tests d’intégration de performance pour votre changement en cours, les lance sous Perf Sentinel et, si vous le voulez, les branche dans votre CI.
- en production, avec le Hub
/perf-sentinel:prod-findingsLit dans le Hub les findings de vos services, les classe par I/O évitable et les corrige par petits lots, chacun prouvé par un test de non‑régression.
Publié par le projet Perf Sentinel, indépendant d’Anthropic. Claude Code est un produit d’Anthropic.
Un mono-binaire Rust, mesuré
Les chiffres ci-dessous chronomètrent le pipeline d’analyse seul (mono-thread, sur jeux de données synthétiques) : ils isolent le coût du pipeline, pas un débit de bout en bout.
Benchmarks détaillés dans la doc →Un Hub C#, pour l’historique des findings
SDK .NET 10.0.403
En mode daemon, Perf Sentinel garde ses findings en mémoire, les plus anciens évincés d’abord, et /api/findings répond au plus 1 000 lignes : l’état courant, pas l’historique. Le Hub, service séparé, collecte chaque daemon et garde ce qu’une éviction ou un redémarrage effacerait, comme la première apparition d’un finding. Il reçoit aussi les rapports périodiques qu’une tâche planifiée publie, les vérifie, rend leur PDF et les partage par un lien qui expire. Son récap classe ce qu’il faut corriger d’abord et ce qui a bougé, en vue technique et en vue pilotage, et une correction confirmée devient une carte signée à partager.
En mode daemon, Perf Sentinel garde un nombre borné de findings en mémoire : l’état courant, pas l’historique. Le Hub, service séparé, collecte chaque daemon et garde ce qu’une éviction ou un redémarrage effacerait. Il vérifie et partage aussi les rapports périodiques, classe ce qu’il faut corriger d’abord dans un récap, technique ou pilotage, et signe des cartes à partager.
Ce qu’il faut corriger d’abord, jusqu’à la ligne de code
Pour la revue d’équipe, le Hub classe les findings par I/O évitables sur la période et donne pour chacun son correctif, sa place dans le code et sa signature. Les tendances ne comptent que les jours clos. Aucune IA ne le rédige : chaque phrase vient des règles du moteur.
- 1N+1 SQLAfficher un panier
shopGET /cart/{id}Use
WHERE ... IN (?)to batch 41 queries into one1,9 millionI/O évitablesplus qu’en juinComment corriger
SELECT * FROM cart_item WHERE cart_id = ?
Correctif suggéréjava_jpaUse
JOIN FETCHon the relationship or annotate the repository method with@EntityGraphto load associations in a single query.Où dans le codeCartItemRepository.findByCartId shop/src/main/java/acme/cart/CartItemRepository.java:31
- détections
- 1 284
- confiance
- daemon_production
- signature
n_plus_one_sql:shop:GET__cart_{id}:09908701485122dcb9d5d84b7c653b7c
- 2N+1 messagingConfirmer une commande
checkoutPOST /orders/{id}/confirmSend 12 messages as one batch instead of one publish per item
412 000I/O évitablesnouveau ce mois-ci - 3Redundant HTTPOuvrir les réglages
accountGET /api/settingsIdentical operation executed 3 times: cache result or deduplicate
96 000I/O évitablesmoins qu’en juin
Le poids carbone du numérique,
et son angle mort : le code applicatif
Le numérique pèse déjà 1,8 % à 3,9 % des émissions mondiales de GES, à la hauteur de l’aviation civile et en croissance rapide. Mais la part due au code et aux applications web lourdes mal optimisées reste non quantifiée à l’échelle mondiale.
Les estimations publiées couvrent les data centers, les réseaux et les terminaux. Aucune ne descend jusqu’à une requête ou un endpoint.
L’approche bottom-up de Perf Sentinel face au top-down des outils actuels
Chaque I/O évitable a un coût,
en temps, énergie et carbone
Réduire les N+1 et les appels redondants améliore à la fois les temps de réponse et la consommation d'énergie. co2.total suit le numérateur Software Carbon Intensity v1.0 (ISO/IEC 21031:2024) : l’énergie consommée (E) multipliée par l’intensité carbone du réseau électrique (I), plus les émissions matérielles embarquées (M), le tout sommé sur les traces analysées.
Réduire les N+1 et les appels redondants améliore à la fois les temps de réponse et la consommation d'énergie. co2.total suit la méthode Software Carbon Intensity v1.0 (ISO/IEC 21031:2024), sommée sur les traces analysées.
co2.avoidable : la part due aux I/O évitables, hors fabricationScore d'intensité I/O (IIS)
Ratio de gaspillage I/O
co2.total multi-régions
cloud.region.Estimation directionnelle, assez pour prioriser et comparer avant et après. Une source d’énergie mesuréeUne source d’énergie mesurée (mode daemon) affine E. Activity data pour Watershed · Sweep · Greenly · Persefoni ou une démarche RGESN. Rapports publics périodiques énergie et carbone en option (trimestriels ou annuels, en JSON et PDF/A-3b, signature Sigstore optionnelle, vérifiables par hash).
Une estimation directionnelle, assez pour prioriser et comparer avant et après. Une source d’énergie mesurée l’affine. Elle sert de donnée d’activité pour vos outils carbone ou une démarche RGESN, et peut être publiée en rapport périodique.
De l'estimation à la mesure,
quand votre infra le permet
Par défaut, l’énergie est estimée depuis les I/O : un chiffre directionnel, à 2× près. En mode daemon, elle peut venir d’une mesure, avec l’intensité carbone du réseau en temps réel. Le rapport JSON nomme sa source.
Remplace l’intensité carbone embarquée par la valeur en direct de la zone où tournent vos services, le plus gros levier sur les gCO₂ quand le mix électrique varie.
Indépendant de la source d’énergie : se combine avec n’importe quelle option ci-dessus, ou avec l’estimation par défaut. Là où les deux couvrent une zone, Electricity Maps l’emporte. Là où aucun ne la couvre, la table embarquée s’applique.
Une mesure logicielle n’est pas un compteur : RAPL ne voit que processeur et mémoire, la moitié aux deux tiers de la consommation à la prise. Seul Redfish voit aussi ventilateurs, disques et cartes réseau.
Sources de mesure et précision dans la doc →Léger, agnostique, CI-natif, carbon-aware
« APM commercial type » : outils SaaS à agent, variables selon le produit, comme Datadog ou New Relic. Le chiffre d’agent, publié par Datadog pour l’Agent 7.34, exclut le traceur par service, comme celui de Perf Sentinel exclut l’instrumentation OTel qu’il lit. Pas un APM complet : il s’adosse à une suite d’observabilité sans la remplacer. Comparatif par outil (Sentry, Hypersistence, Digma, Pyroscope, OTJAE) dans la doc.
« APM commercial type » : outils SaaS à agent comme Datadog ou New Relic. Perf Sentinel s’adosse à une suite d’observabilité sans la remplacer.
Ce que Perf Sentinel n’est pas
Un rapport que chacun peut vérifier
Le daemon archive chaque fenêtre d’analyse. perf-sentinel disclose en tire un rapport trimestriel ou annuel, et disclose-pdf le rend en PDF/A-3b. Le Hub peut le recevoir et le partager, mais personne n’en a besoin pour le vérifier.
Un PDF de dix pages, lisible sans outil : les chiffres du trimestre et leur marge d’incertitude, le périmètre mesuré, les limites de la méthode, et une annexe de chaque champ du rapport. Le rapport source et sa signature voyagent en pièce jointe, et une commande suffit à tout revérifier.
- PDF/A-3b
- 10 pages
- signé (Sigstore)
- entreprise fictive
Vérifiez-le vous-même
Après le téléchargement, une commande recalcule le hash du rapport joint, vérifie que l’attestation le nomme et contrôle la signature, avec cosign dans le PATH.
Une commande, avec cosign dans le PATH, recalcule le hash du rapport joint et contrôle sa signature.
AGPL-3.0, ce que ça implique pour votre code
Un résumé lisible par un service juridique, sans fouiller le dépôt. Perf Sentinel est sous licence GNU Affero General Public License v3.0.
Faire tourner Perf Sentinel ne place pas vos propres services sous AGPL. C’est un processus autonome : vos applications lui envoient seulement des traces OpenTelemetry par le réseau (OTLP), une communication à distance et non un lien de compilation, qui ne crée donc aucune œuvre dérivée et n’impose aucune obligation de licence sur votre code.
L’AGPL couvre le code source de Perf Sentinel lui-même. Utiliser les binaires ou l’image officiels non modifiés n’entraîne aucune obligation de copyleft, d’aucune sorte.
La seule condition : si vous modifiez Perf Sentinel et proposez la version modifiée à des tiers via un réseau, l’article 13 vous oblige à mettre cette source modifiée à disposition de ces utilisateurs. Ceci est un résumé pratique et non un avis juridique. Consultez votre service juridique en cas de doute.
La seule condition : si vous modifiez Perf Sentinel et proposez cette version à des tiers par le réseau, l’article 13 vous oblige à en publier la source. Résumé pratique, pas un avis juridique.
Ce que votre DSI vérifiera, et où le trouver
Perf Sentinel et son Hub s’installent sur votre infrastructure, sans SaaS. Ce qu’une revue de sécurité examine en général : actif par défaut, ou à votre charge.
Requêtes normalisées en mémoire
Le moteur remplace en mémoire les valeurs SQL et les identifiants d’URL par des marqueurs, avec des exceptions documentées. Le Hub garde ces findings 180 jours par défaut, dans une base SQLite chez vous.
Valeurs SQL et identifiants d’URL remplacés, avec des exceptions documentées. Le Hub garde les findings 180 jours par défaut, chez vous.
Aucune télémétrie
Le moteur ne contacte que ce que vous configurez, comme une source de mesure d’énergie. Le Hub vérifie chaque jour la dernière version sur GitHub, et un réglage le désactive.
Le Hub vérifie chaque jour la dernière version sur GitHub, et un réglage le désactive.
Ce qui est ouvert, et comment le fermer
Le daemon écoute sur 127.0.0.1 par défaut, TLS en option. Ses lectures ne sont pas authentifiées : une NetworkPolicy ou votre ingress les filtre. Le Hub exige une clé par source et peut placer son interface derrière votre SSO.
Les lectures du daemon ne sont pas authentifiées : une NetworkPolicy ou votre ingress les filtre. Le Hub exige une clé par source.
Rust sans unsafe, images sans root
Le cœur du moteur interdit le code unsafe à la compilation. Les deux images tournent sans root, FROM scratch pour le moteur et chiselée pour le Hub, en lecture seule dans leurs charts Helm.
FROM scratch pour le moteur, chiselée pour le Hub, en lecture seule dans leurs charts Helm.
Tags signés, binaires traçables
Tags de release signés, provenance de build attestée via Sigstore et SBOM SPDX à chaque version. Actions épinglées par SHA, dépendances auditées chaque jour.
Provenance de build attestée via Sigstore et SBOM SPDX à chaque version.
Signalement privé, délais publiés
Les failles se signalent en privé via GitHub. Chaque dépôt publie ses délais de réponse et les versions qui reçoivent les correctifs.
Chaque dépôt publie aussi les versions qui reçoivent les correctifs.
Porté par l’Institut du Numérique Responsable
Né comme projet personnel, Perf Sentinel a rejoint l’INR, association loi 1901 issue du Club Green IT. Son créateur, Robin Trassard, continue de le diriger au sein de l’institut. Robin est par ailleurs développeur fullstack chez Onepoint, orienté back-end et spécialisé en performance et éco-conception. Le code reste sous AGPL-3.0 et se développe en public sur le GitHub de l’INR.