TWAP vs VWAP vs POV : choisir un benchmark d'exécution (et savoir quand chacun vous ment)
Tout scheduler d'exécution est un pari sur une prévision de volume. Le TWAP parie que la liquidité est plate dans le temps. Le VWAP parie que la courbe de volume d'aujourd'hui ressemblera à celle d'hier. Le POV parie que le volume qui s'imprime sur la tape en ce moment même est une bonne raison de trader maintenant — y compris la part de la tape qui est vous-même. Aucun de ces paris n'est présenté comme tel dans la documentation des fournisseurs, ce qui explique pourquoi la plupart des comparaisons des trois ressemblent à un tableau de fonctionnalités : le TWAP est "simple", le VWAP est "intelligent", le POV est "adaptatif". Ce cadrage ne vous dit rien sur lequel vous fait perdre de l'argent, quand, ni combien.
Ceci est la deuxième partie d'un fil que nous avons commencé dans Types d'ordres en trading algorithmique, où nous avions construit des exécuteurs TWAP et VWAP jouets en ~40 lignes de Python chacun. Ces exécuteurs sont corrects en tant que plomberie. Cet article traite de tout ce que la plomberie dissimule : les hypothèses implicites, la politique des benchmarks, et une expérience reproductible confrontant les trois algorithmes sur des données de carnet d'ordres rejouées, qui montre qu'ils ne sont pas de "simples variantes" — ce sont des profils de risque différents avec des modes de défaillance différents.
Trois schedulers, trois paris cachés
Fixons la notation. Un ordre parent de taille doit être exécuté sur un horizon , découpé en intervalles. Soit la quantité enfant dans l'intervalle , le volume de marché dans l'intervalle , et le prix moyen dans l'intervalle . Le VWAP de marché sur l'horizon est
Le TWAP trade : des quantités égales sur des durées égales. L'hypothèse implicite est que la liquidité — profondeur, spread, volume — est uniforme dans le temps, de sorte que des tranches égales subissent un impact égal. C'est faux sur tout marché ayant jamais existé, mais l'échec est gracieux : le planning est déterministe, l'exécution complète est garantie par construction, et le pire cas est de trader une clip fixe pendant une heure creuse et de payer des spreads plus larges pour cela. La deuxième hypothèse, moins discutée, est que personne ne regarde. Un TWAP qui tire un ordre enfant toutes les 60 secondes pile est un métronome, et les métronomes se font front-runner. Tout TWAP sérieux randomise le timing et la taille des enfants ; le planning doit être un processus quasi-poissonnien dont l'espérance est plate, pas une horloge.
Le VWAP trade , où est la fraction prévue du volume journalier dans l'intervalle , . Le pari est désormais explicite : vous détenez une courbe estimée à partir de l'historique, et vous supposez qu'aujourd'hui la suivra. L'hypothèse n'est pas que le volume est plat, mais qu'il est prévisible et exogène — la courbe ne se soucie pas de savoir si vous tradez. Quand la prévision est bonne, le VWAP concentre votre trading là où le marché peut l'absorber et votre slippage par rapport au VWAP de marché est faible, presque tautologiquement. Quand la prévision est mauvaise — un événement d'actualité non planifié déplace 40% du volume de la journée dans une heure à laquelle votre courbe attribuait 6% — le VWAP continue sereinement de trader selon le planning périmé et vous encaissez la différence. Le VWAP convertit le risque d'exécution en risque de prévision de volume. C'est tout l'arbitrage, et c'est pourquoi l'ingénierie intéressante dans un moteur VWAP est le prévisionniste, pas le découpeur.
Le POV (percentage of volume, aussi "participation") abandonne la prévision : trader , une fraction fixe du volume observé dans chaque intervalle. Cela semble dominer le VWAP — pourquoi prévoir le volume quand on peut simplement le suivre ? Le piège est que le signal est désormais endogène. Vos propres fills s'impriment sur la tape. Si le reste du marché trade dans un intervalle et que vous ciblez une fraction du volume total de la tape, votre quantité résout , soit
À cette correction est légère (11,1% du volume des autres). À vous tradez 33% du flux de tous les autres ; à vous égalez tout le reste du marché un pour un et le point fixe diverge. Le POV abandonne aussi la seule garantie qu'offrent à la fois le TWAP et le VWAP : il n'y a pas d'heure de complétion. Si le volume meurt, votre planning meurt aussi. Nous reviendrons sur les pathologies du POV plus bas, car elles méritent leur propre section.
Un autre cadrage qui comptera plus tard : aucun des trois n'est "optimal" au sens formel. Le scheduler qui minimise réellement un objectif coût-risque est la famille Almgren–Chriss (Almgren and Chriss, 2000, "Optimal Execution of Portfolio Transactions," Journal of Risk 3, 5–39), que nous traitons proprement dans Almgren–Chriss et la théorie des plannings d'exécution optimaux. Le TWAP est le cas particulier d'Almgren–Chriss avec aversion au risque nulle sous impact linéaire ; le VWAP est la stratégie à erreur de suivi minimale contre un benchmark pondéré par le volume (Konishi, 2002, "Optimal slice of a VWAP trade," Journal of Financial Markets 5(2)) ; le POV est une heuristique qui ne correspond à aucune fonction objectif, ce qui explique précisément pourquoi ses modes de défaillance sont si étranges.
Estimer les courbes de volume quand le marché ne ferme jamais
La littérature sur les actions avait la partie facile. Le volume intraday sur actions a une forme en U — fort à l'ouverture, calme à midi, fort en clôture — documentée depuis Jain and Joh (1988, "The Dependence between Hourly Prices and Trading Volume," JFQA 23(3)) et justifiée théoriquement par Admati and Pfleiderer (1988, "A Theory of Intraday Patterns: Volume and Price Variability," Review of Financial Studies 1(1)), qui ont montré que les traders de liquidité discrétionnaires et les traders informés se regroupent de façon endogène dans le temps. La forme en U est ancrée par deux événements durs, les enchères d'ouverture et de clôture, donc la courbe est stable et une moyenne mobile sur 20 jours des parts de volume par intervalle vous amène à 90% du chemin.
La crypto n'a ni ouverture ni clôture, donc l'intuition naïve est que le volume devrait être plat et que TWAP ≈ VWAP. Cette intuition naïve est fausse. Le volume intraday crypto a une structure — elle est simplement ancrée à des horloges différentes :
Effets de session. Le volume suit les heures de veille des personnes et des desks qui le tradent. Sur les majors BTC et ETH, la bande la plus forte est l'après-midi US chevauchant la soirée européenne (environ 13h00–21h00 UTC), avec un plateau secondaire en Asie autour de 00h00–08h00 UTC et un creux prononcé autour de 04h00–06h00 UTC sur les majors. Les paires alt à propriété régionale concentrée penchent plus fortement vers leur session domestique.
Horodatages de funding. Les futures perpétuels règlent le funding à des heures UTC fixes — historiquement toutes les 8 heures à 00h00, 08h00, 16h00 UTC, avec Binance et d'autres passant de nombreux contrats à des cycles de règlement de 4 heures voire 1 heure depuis 2025–2026. Les minutes autour du règlement affichent de façon fiable un volume élevé : les traders de base ouvrent et ferment des positions de portage, et quiconque essaie de manipuler le snapshot du funding trade pile à la limite. Ce sont des pics, pas des plateaux — une courbe à buckets de 30 minutes les voit ; une courbe à buckets de 2 heures les moyenne et fait disparaître, si bien que votre VWAP sous-participe exactement quand la liquidité est la meilleure.
Saisonnalité hebdomadaire. Le volume du week-end sur les majors se situe structurellement en dessous du volume de semaine, et le dimanche soir UTC (lundi matin en Asie, plus la réouverture du CME pour les futures BTC) a sa propre signature. Une courbe unique heure-de-la-journée regroupée sur tous les jours est mal spécifiée ; vous voulez une grille jour-de-la-semaine × heure-de-la-journée.
Événements programmés. Les options Deribit expirent à 08h00 UTC (vendredis, avec des clusters trimestriels), les publications macro US tombent à 12h30/14h00 UTC, les règlements CME comptent pour les flux de base. Ce sont des caractéristiques calendaires, pas de la saisonnalité — traitez-les comme des variables muettes, pas en polluant la courbe de base.
Un estimateur fonctionnel, dans l'esprit de garder le prévisionniste honnête avant de le rendre astucieux :
import pandas as pd
def volume_curve(trades: pd.DataFrame, bucket="30min") -> pd.Series:
"""day-of-week x time-of-day volume shares from a trades tape."""
v = trades["qty"].resample(bucket).sum()
day_total = v.groupby(v.index.date).transform("sum")
share = v / day_total # fraction of that day's volume
key = [v.index.dayofweek, v.index.time]
curve = share.groupby(key).median()
return curve / curve.groupby(level=0).transform("sum") # renormalize per day
La médiane plutôt que la moyenne n'est pas un choix stylistique. Le volume crypto est extrêmement à queue lourde ; une seule cascade de liquidations peut représenter 15% du volume d'une journée en 10 minutes, et une courbe basée sur la moyenne s'attendra à jamais à un pic dans ce bucket. La littérature sur les actions est allée plus loin que les courbes statiques : Białkowski, Darolles and Le Fol (2008, "Improving VWAP strategies: A dynamic volume approach," Journal of Banking & Finance 32(9), 1709–1722) décomposent le volume par intervalle en une composante de marché commune et une composante spécifique au titre modélisée avec une dynamique ARMA/SETAR, et montrent que cette décomposition réduit sensiblement le risque de suivi VWAP par rapport à une courbe classique statique. La transposition crypto est directe : estimer une courbe de marché à partir des top-N paires (le facteur commun est fort — les horloges de funding et les sessions sont partagées), puis modéliser la déviation de votre paire comme un processus intraday à retour à la moyenne que vous mettez à jour en temps réel. Plus récemment, Genet (2025, "Deep Learning for VWAP Execution in Crypto Markets: Beyond the Volume Curve," arXiv:2502.13722) montre que des plannings appris de bout en bout battent le VWAP à courbe statique sur des données Binance — preuve qu'en crypto, la courbe de volume est le maillon faible du pipeline, pas le découpage.
Le résumé opérationnel : une courbe statique tous-jours-confondus est un VWAP épouvantail. Si votre comparaison montre que "le VWAP bat à peine le TWAP en crypto", vérifiez si le VWAP a été nourri d'une courbe qui contient réellement les pics de funding et le découpage semaine/week-end avant de conclure quoi que ce soit.

Pathologies du POV : l'algorithme qui poursuit sa propre queue
L'argument de vente du POV est l'adaptabilité : trader quand le marché trade. Trois pathologies distinctes le minent.
1. La boucle de rétroaction. L'endogénéité évoquée plus haut n'est pas une simple correction comptable. Vos ordres enfants créent du volume ; le volume élève votre cible ; votre cible crée du volume. À modéré, le point fixe est stable, mais la participation mesurée que votre rapport post-trade affiche ( du volume total de la tape) sous-estime votre empreinte par rapport à ce qu'aurait été le marché sans vous ( du reste des acteurs). Pire, une rétroaction de second ordre existe : vos fills font bouger le prix, le mouvement de prix attire du flux momentum et déclenche des stops, ce flux élève le volume de la tape, et votre moteur POV lit le volume qu'il a lui-même causé comme une invitation à accélérer. C'est exactement l'inverse du comportement optimal — les schedulers conscients de l'impact (Almgren–Chriss avec des paramètres raisonnables, et les estimations empiriques d'impact comme Almgren, Thum, Hauptmann and Li, 2005, "Direct Estimation of Equity Market Impact," Risk 18(7)) veulent que vous ralentissiez après avoir poussé le prix, pas que vous accélériez. Une cascade de liquidations est la limite pathologique : volume de tape énorme, carnet à sens unique, et un POV vanille achète le plus fort au sommet du squeeze parce que c'est là que se trouvent les prints.
2. Se faire piéger. Un algo POV est une machine à flux d'ordres déclenchée par le volume, et tout ce qui est déclenchable peut servir d'appât. Un prédateur qui soupçonne un gros acheteur en participation peut imprimer du volume — en s'auto-croisant là où les règles le permettent, ou simplement en tradant activement en petite taille — pour tirer le moteur POV en avant, puis lui fournir de la liquidité à des prix majorés. C'est une instance à petite échelle du mécanisme général décrit par Brunnermeier and Pedersen (2005, "Predatory Trading," Journal of Finance 60(4)) : quand votre demande future est prévisible à partir de votre comportement passé, d'autres tradent en avance sur elle et le chemin de prix que vous affrontez est pire que celui que vous aviez anticipé. Le TWAP fuit un planning dans le temps ; le POV fuit une fonction de réponse, ce qui est plus dangereux car l'adversaire peut l'invoquer à volonté.
3. La queue qui ne finit jamais. Le POV n'a pas d'horloge. Si vous devez acheter 500 BTC avant 16h00 UTC et que le volume s'évapore à 14h00, un POV pur attend — il est, par construction, incapable de finir de lui-même. Tout POV en production porte donc un plancher de taux minimal et un mode de rattrapage, et c'est dans ce mode de rattrapage que se cachent les pertes : vous passez la journée à trader passivement à 10% de participation, puis vous propulsez les 30% restants de l'ordre parent à travers une fenêtre de clôture étroite à un taux de participation triple de votre cible. La moyenne post-trade a l'air correcte ; le coût marginal de la dernière tranche est brutal. Si vos rapports POV n'isolent pas la queue séparément, vous n'avez pas vu son coût réel.
def pov_child_qty(tape_vol: float, gamma: float, remaining: float,
t_left_s: float, min_rate: float) -> float:
target = gamma / (1.0 - gamma) * tape_vol # exclude our own prints
floor = remaining / max(t_left_s, 1.0) * CHILD_INTERVAL_S
if t_left_s < CATCHUP_HORIZON_S: # deadline dominates
floor = max(floor, remaining * CHILD_INTERVAL_S / t_left_s)
return min(remaining, max(target, floor, min_rate))
Deux détails de cet extrait font un vrai travail : la cible utilise du volume de tape hors-nous (il faut soustraire vos propres fills de la tape à laquelle vous réagissez — un nombre surprenant d'implémentations ne le font pas), et le plancher de deadline transforme le POV en TWAP-sur-le-résiduel à mesure que le temps s'épuise, ce qui rend au moins le coût de la queue prévisible.

Benchmarks : pourquoi battre le VWAP peut quand même vous faire perdre de l'argent
Le scheduler et le benchmark sont des choix distincts, et les confondre est le péché post-trade le plus courant. Deux benchmarks dominent.
Le benchmark VWAP — comparer votre prix de fill moyen au VWAP de l'intervalle — a été introduit par Berkowitz, Logue and Noser (1988, "The Total Cost of Transactions on the NYSE," Journal of Finance 43(1)), qui proposaient le prix pondéré par le volume de la journée comme étalon neutre pour la qualité d'exécution institutionnelle. Il est devenu le défaut de l'industrie pour une raison autant sociologique que technique : il est facile à calculer, facile à expliquer, et difficile de mal paraître face à lui si l'on répartit simplement son trading sur la journée.
L'implementation shortfall (prix d'arrivée) vient de Perold (1988, "The Implementation Shortfall: Paper Versus Reality," Journal of Portfolio Management 14(3), 4–9) : mesurer tout par rapport au prix au moment où la décision a été prise. Pour un achat de avec une quantité exécutée à prix moyen , prix terminal :
Le point de Perold était que l'écart entre les portefeuilles théoriques et les portefeuilles réels est précisément cette quantité — et notez qu'elle vous fait payer pour ce que vous avez échoué à exécuter, ce que le benchmark VWAP ignore silencieusement. Ce terme de coût d'opportunité est ce qui fait de l'IS le seul benchmark honnête pour le POV, dont le mode de défaillance caractéristique est la quantité non exécutée.
Voici maintenant le piège. Le VWAP en tant que benchmark a deux angles morts structurels :
Il est autoréférentiel. Vos fills sont à l'intérieur du benchmark. Si vous représentez 30% du volume de l'intervalle, alors environ 30% du VWAP est votre propre prix moyen, et votre slippage mesuré par rapport au VWAP est mécaniquement réduit par votre propre participation — plus votre ordre est gros et impactant, mieux il note. À la limite où vous êtes le seul trader, vous battez le VWAP d'exactement zéro, indépendamment de la gravité avec laquelle vous avez fait bouger le prix. Le slippage VWAP mesure l'adhérence au planning, pas le coût.
Il ignore la dérive par rapport à la décision. Chiffres concrets : vous décidez d'acheter 100 BTC à un prix de décision de 60 000 $. Le marché monte tout l'après-midi ; le VWAP de l'intervalle affiche 60 320 $ et vous exécutez à une moyenne de 60 290 $. Rapport VWAP : –5 bps, benchmark battu, cellule verte pour le desk. Rapport à l'arrivée : vous avez payé 290 $ au-dessus du prix de décision sur 100 BTC — +48 bps, 29 000 $ d'implementation shortfall. Les deux chiffres sont corrects. Un seul d'entre eux est de l'argent. Et la corruption des incitations va plus loin : un trader noté sur le VWAP devrait ralentir un jour de tendance (étaler les trades suit mieux le benchmark), ce qui est exactement l'inverse de ce qui minimise le shortfall quand le prix vous échappe. Le benchmark ne se contente pas de mal mesurer le coût — il prescrit le mauvais comportement. Kissell (2013, The Science of Algorithmic Trading and Portfolio Management, Academic Press) traite ce problème de choix de benchmark en profondeur ; son cadrage vaut la peine d'être intériorisé : le benchmark encode le risque de qui vous gérez. Le VWAP gère le risque d'embarras du desk d'exécution. Le prix d'arrivée gère le P&L du portefeuille.
Résolution pratique : notez les stratégies sur l'implementation shortfall ; utilisez le slippage VWAP comme diagnostic (il isole la compétence de scheduling de la chance de timing, puisque la dérive affecte à la fois vous et le benchmark) ; et ne laissez jamais quiconque dont l'ordre représentait >10% du volume de l'intervalle citer un slippage VWAP sans également citer sa participation.
L'expérience : trois algorithmes, une seule tape
Les définitions posées, nous pouvons faire ce que les articles de comparaison ne font jamais : lancer les trois schedulers sur des ordres parents identiques sur les mêmes données rejouées et regarder les distributions de coûts, pas des adjectifs. Le harnais tourne sur le simulateur de fills événementiel décrit dans Simulation de fills : fills partiels, position dans la file, et pourquoi les fills de votre backtest mentent — profondeur L2 rejouée, les ordres limites enfants gagnent une position dans la file, les enfants agressifs marchent le carnet, et nos fills perturbent la tape que les schedulers observent (ce qui compte énormément pour le POV, cf. la section sur la rétroaction).
Setup, pour que vous puissiez le reproduire sur vos propres données :
- Instrument/données : BTCUSDT perpétuel, 90 jours de replay L2 (top 20 niveaux, 100 ms) + tape de trades.
- Ordres parents : 500 par algorithme, identiques entre algorithmes : heures de départ aléatoires, horizon h, taille 0,75% de l'ADV glissant sur 30 jours (assez grande pour que l'impact soit réel, assez petite pour que les trois puissent plausiblement finir), côté achat, prix de décision = mid au départ.
- TWAP : 48 tranches enfants, jitter de timing/taille ±30%.
- VWAP : courbe médiane jour-de-la-semaine × heure-de-la-journée en buckets de 30 min (estimateur ci-dessus), réajustée chaque semaine, sans mise à jour intraday — délibérément la version simple.
- POV : du volume de tape hors-nous, plancher de taux minimal, rattrapage TWAP dans les 30 dernières minutes.
- Métriques : IS en bps du prix de décision (frais inclus), slippage VWAP en bps, taux de complétion, et — celle que personne ne rapporte — l'IS du dernier quartile de chaque parent.
Résultats représentatifs de nos runs (vos chiffres différeront, la forme ne devrait pas) :
| Metric (bps vs arrival) | TWAP | VWAP | POV 12% |
|---|---|---|---|
| Mean IS | 11.8 | 9.6 | 8.9 |
| Median IS | 9.1 | 7.7 | 6.4 |
| Std of IS | 21.5 | 19.8 | 26.3 |
| 95th percentile IS | 46 | 41 | 58 |
| Mean VWAP slippage | +1.9 | +0.4 | –0.8 |
| Completion at T | 100% | 100% | 96.4% |
| Mean IS, final quartile of parent | 12.5 | 10.2 | 19.7 |
Trois lectures, par ordre d'importance croissant :
Les moyennes flattent le POV et les queues le condamnent. Le POV gagne sur l'IS moyen et médian — s'adapter à la liquidité réalisée vaut réellement quelques bps par rapport à une courbe statique. Mais son écart-type d'IS et son 95e percentile sont les pires des trois, son taux de complétion n'est pas de 100%, et son coût de dernier quartile fait plus du double de son chiffre affiché : la queue qui ne finit jamais plus le mode de rattrapage concentrent le coût exactement là où les moyennes le dissimulent. Si vos ordres parents sont pilotés par l'alpha avec un horizon dur, c'est cette queue qui compte, et l'avantage moyen du POV ne le compense pas.
L'avantage du VWAP sur le TWAP est exactement sa qualité de prévision. Conditionnez l'écart d'IS VWAP–TWAP sur l'erreur de courbe de volume réalisée (distance entre la prévision et les parts réalisées) et la relation est monotone : sur le tercile de jours à meilleure prévision, le VWAP bat le TWAP d'environ 4 bps ; sur le pire tercile, l'écart est dans le bruit et s'inverse parfois. En crypto, le pire tercile n'est pas aléatoire — ce sont les jours de cascade et les jours d'actualité, qui sont aussi les jours au coût global le plus élevé. Le VWAP améliore votre moyenne en surperformant sur les jours qui étaient de toute façon faciles.
Le slippage VWAP et l'IS classent les algorithmes différemment. Le POV affiche un slippage VWAP moyen négatif — bien sûr, il trade proportionnellement au volume même qui définit le benchmark, et ses fills se trouvent à l'intérieur de celui-ci. Selon le tableau de bord VWAP, le POV est le meilleur algorithme ici ; selon le tableau de bord à l'arrivée et le risque de complétion, c'est le plus dangereux. Même tape, mêmes fills, conclusion opposée — ce qui est exactement l'argument de la section précédente rendu sous forme de tableau.

Le harnais lui-même fait ~50 lignes autour du simulateur de fills et vaut chaque minute investie, car il convertit le choix du scheduler d'un débat de goût en une mesure :
for parent in sample_parents(n=500, horizon="4h", adv_frac=0.0075):
for algo in (twap, vwap, pov):
sim = ReplaySim(l2_stream(parent.window), fees=TAKER_MAKER)
fills = sim.run(algo.schedule(parent)) # fills perturb the tape
report(parent, algo, is_bps(fills, parent.p0),
vwap_slip_bps(fills, sim.tape), fills.completion)
Choisir, en pratique
Les règles de sélection honnêtes qui ressortent de tout cela :
- Deadline dure, ordre parent piloté par l'alpha : TWAP ou un planning Almgren–Chriss front-loaded. Payez la taxe de liquidité plate ; achetez la garantie de complétion et la queue bornée. Randomisez les enfants.
- Flux piloté par benchmark (vous êtes littéralement payé sur le VWAP), ou grosse taille un jour normal : VWAP — et dépensez votre budget d'ingénierie sur le prévisionniste de volume : grille jour-de-la-semaine, résolution des pics de funding, mise à jour dynamique intraday à la Białkowski–Darolles–Le Fol. Un moteur VWAP avec une courbe paresseuse est du TWAP avec des étapes en plus.
- Opportuniste, pas de deadline dure, sensible à la liquidité : POV à modéré (≤15%), calculé sur volume hors-nous, avec un filtre anti-cascade (plafonner la participation quand les z-scores du volume de tape explosent) et un fallback de deadline dont vous mesurez le coût séparément.
- Quoi que vous exécutiez : notez-le sur l'implementation shortfall contre l'arrivée, selon Perold. Gardez le slippage VWAP comme diagnostic de la compétence de scheduling, jamais comme tableau de bord — le tableau de bord doit être libellé en argent, et seul le prix d'arrivée l'est.
Et la méta-règle que l'expérience ne cesse d'imposer : comparez des distributions, pas des moyennes, sur vos propres données rejouées. Un scheduler est un pari sur une prévision de volume, et on n'évalue pas des paris par leur gain moyen en ignorant les queues — c'est précisément ainsi que le marché vous vend du POV.
Authors
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.