Glossaire

Demande de publicite emise par un site web quand un emplacement pub est disponible.

Chaque visite de page peut generer plusieurs AdCalls (un par emplacement).

Message envoye par le SSP aux DSP pour demander une enchere sur un emplacement publicitaire.

Format standardise par le protocole OpenRTB.

Reponse d'un DSP a une Bid Request, contenant le prix propose et la creative publicitaire.

Cout Pour Mille impressions. Metrique standard de tarification publicitaire.

CPM = (Revenus / Impressions) x 1000

Ecart entre les statistiques reportees par SmileWanted et celles du partenaire.

Un ecart < 5% est considere normal. Au-dela, une investigation est necessaire.

Demand-Side Platform. Plateforme d'achat publicitaire automatise cote annonceur.

Exemples : Criteo, Magnite, AppNexus, BidSwitch.

Pourcentage de demandes publicitaires auxquelles un partenaire repond avec une enchere.

Fill Rate = Bid Responses / Bid Requests x 100

Prix minimum qu'un editeur accepte pour un emplacement publicitaire. Toute enchere en dessous est rejetee.

Technique d'encheres cote client (navigateur) via un wrapper JavaScript comme Prebid.js.

Permet aux editeurs de solliciter plusieurs SSP simultanement avant l'ad server.

Evenement comptabilise quand une publicite est effectivement affichee a l'ecran d'un utilisateur.

Commission prelevee par SmileWanted sur chaque transaction publicitaire.

Protocole standard de l'IAB pour les encheres en temps reel (Real-Time Bidding).

Definit le format des Bid Requests et Bid Responses entre SSP et DSP.

Proprietaire d'un site web ou d'une application qui affiche des publicites pour generer des revenus.

Supply-Side Platform. Plateforme de vente publicitaire cote editeur. SmileWanted est un SSP.

Le SSP recoit les AdCalls et les transmet aux DSP sous forme de Bid Requests.

Transparency and Consent Framework. Standard IAB pour la gestion du consentement publicitaire (RGPD).

Version actuelle : TCF v2.2. Encode les choix de l'utilisateur dans un "consent string".

Pourcentage d'encheres remportees par un partenaire par rapport au nombre total d'encheres soumises.

Win Rate = Impressions / Bid Responses x 100

Liste de combinaisons (domaine + editeur) exclues des encheres pour un partenaire donne, par template/offre.

Stockee dans partner_offer_template. Format: domain#publisher_id, separe par virgules. Champ web = domain_blacklist, app = app_domain_blacklist.

Indicateur de performance d'une combinaison partenaire/domaine/editeur/template/offre. Calcul : (gross_revenues / bid_requests) x 1000.

Plus la rentabilite est basse, plus la combinaison est candidate au blacklist.

Combinaison d'une offre commerciale (ex: sans_algo, video_algo_vtr_70) et d'un template de rendu (ex: display_simple, display_video_full).

Chaque partenaire a des blacklists par couple offer/template.

Nombre moyen de bid requests envoyees par adcall. Mesure combien de partenaires sont sollicites pour chaque demande publicitaire.

Ratio normal : ~2.15 pour ce jour de semaine. Un ratio plus eleve signifie que le throttling profitability est inactif.

Mode d'encheres ou les appels aux partenaires sont effectues cote serveur (PBS) plutot que cote client (navigateur).

Plus rapide pour l'utilisateur (moins de latence) mais necessite une infra serveur dediee. Endpoint : POST /

Advanced Message Queuing Protocol. Protocole standard de messagerie utilise par RabbitMQ.

Supporte les concepts d'exchange, queue, binding et acknowledgement.

Architecture processeur utilisee par Apple Silicon (M1/M2/M3) et certains serveurs cloud.

Les images Docker x86 tournent en emulation sur ARM via Rosetta 2 ou QEMU.

Regroupement de plusieurs serveurs pour assurer la haute disponibilite et la repartition de charge.

RabbitMQ supporte le clustering natif. Gearman non.

Programme qui lit et traite les messages depuis une queue du message broker.

Chez SW : les workers stats-algos consomment les events de consolidation.

File d'attente speciale ou sont envoyes les messages qui n'ont pas pu etre traites apres plusieurs tentatives.

Fonctionnalite native de RabbitMQ, absente de Gearman.

Mecanisme RabbitMQ qui route les messages vers differentes queues selon des regles (direct, topic, fanout).

Permet de dispatcher un meme event vers plusieurs consumers specialises.

Message broker leger utilise actuellement par SmileWanted pour dispatcher les events entre services.

Ultra-leger (~50 MiB RAM), simple, mais sans fonctionnalites avancees (pas de DLQ, pas de routing).

Java Virtual Machine. Environnement d'execution de Kafka. Consomme beaucoup de RAM (~400+ MiB).

C'est l'overhead JVM qui explique la RAM elevee de Kafka, pas le broker lui-meme.

Intermediaire logiciel qui transmet des messages entre producteurs et consommateurs de facon asynchrone.

Exemples : Gearman, RabbitMQ, Kafka, Redpanda.

FastCGI Process Manager pour PHP. Gere un pool de workers PHP qui traitent les requetes web.

Le bidder SmileWanted tourne sur PHP-FPM 8.3 derriere Nginx.

Programme qui envoie des messages dans une queue du message broker.

Chez SW : le bidder produit des events de tracking envoyes via Gearman.

File d'attente FIFO (First In, First Out) dans laquelle les messages sont stockes en attendant d'etre consommes.

Message broker open-source (Erlang) avec management UI, routing, DLQ et clustering natif.

Candidat principal pour remplacer Gearman chez SmileWanted.

Composant Symfony pour envoyer/recevoir des messages via un transport (AMQP, Redis, Doctrine...).

Envoie les messages un par un ($bus->dispatch()). Pas de batch natif.

CPU virtuel attribue a une machine virtuelle. Peut etre "shared" (partage) ou "dedicated" (dedie).

Shared = les voisins peuvent impacter les performances (noisy neighbors).

Processus en arriere-plan qui consomme des messages depuis un broker et execute des traitements.

Chez SW : workers Gearman pour consolidation stats, algos profitability, investment.

Algorithme qui evalue la rentabilite de chaque combinaison partenaire/domaine/editeur/template. Attribue un "level" (sampling rate) qui determine la frequence d'envoi de bid requests.

Level 0 = toujours envoyer (rentable). Level 999999 = quasi blackliste. Cache PSR-6 sur chaque front.

Standard PHP pour le caching (CacheItemPoolInterface). Sur les fronts bidder, utilise le filesystem (var/cache/prod/pools/).

Chaque entree a un TTL. isHit() retourne false si le TTL est depasse.

Nombre d'adcalls entre chaque bid request envoyee pour une combinaison domaine/partenaire non rentable.

Plus le sampling rate est eleve, moins de bid requests sont envoyees. 999999 = quasi-blackliste.

Queries Per Second. Limite de bid requests par seconde que SmileWanted peut envoyer a un partenaire DSP.

Configure par partenaire et par endpoint. NULL = pas de limite. Divise par serveur via un share calcule.

Fichiers comprimes generes par le back server a partir des tables SQL stats-algos, servis aux fronts via HTTP.

Stockes dans /cache/{version}/. Le back ne genere que pour SA version. Un cron purge les fichiers de plus de 24h.

Serveur dedie a la generation des fichiers cache gzip (profitability, investment, visibility, etc.) a partir des tables SQL.

Execute les commandes --generate-files via cron. Ne sert pas de trafic web.

Serveur bidder qui recoit les adcalls, appelle les partenaires, et renvoie la pub. ~100 serveurs repartis sur 3 regions (EMEA, US-East, US-West).

Telecharge les fichiers gzip du back server via HTTP et charge les donnees en cache PSR-6 local.

Composant server-side qui execute les encheres cote serveur au lieu du navigateur. Recoit les requetes des editeurs via Prebid.js ou en S2S direct.

Endpoints SmileWanted : prebid-server.smilewanted.com (EMEA), openrtb-us-east (US), prebid-server-us-east (US). Ecrit en Go.

Erreur HTTP 500 renvoyee par le serveur d'origine (PBS) a Cloudflare. Indique un crash ou un bug applicatif cote serveur.

Contrairement a un 5xx genere par Cloudflare (ex: 522 timeout), un Origin 500 vient du code applicatif lui-meme.

CDN et reverse proxy devant tous les endpoints SmileWanted. Fournit cache, protection DDoS, analytics et WAF.

Zone SmileWanted : c3dd290d41bd866cd84d0893b7129af7. API GraphQL pour les analytics.

Pourcentage de requetes retournant une erreur HTTP 5xx par rapport au total des requetes.

Calcul : (erreurs 500 / requetes totales) x 100. Seuil critique : > 1%.

Mesure statistique indiquant combien d'ecarts-types une valeur est eloignee de la moyenne. |z| > 2 = anomalie significative a 95%.

z = (valeur_observee - moyenne) / ecart_type. Utilise pour la detection d'anomalies.

Time To Live. Duree de validite d'une entree en cache avant expiration automatique.

Les caches bidder ont des TTL de 5 min (real-time) a 24h (semi-real-time) selon le type.

Skill Claude Code qui capture l'etat de la session, valide la proprete du workspace, met a jour les fichiers de suivi, et prepare la reprise.

Declencheurs : /close-session, "on close", "fin de session".

Skill Claude Code qui initialise un nouveau sujet structure (labs, investigation, exploration, audit) avec placement intelligent et preparation multi-sessions.

Cree README.md + PRIMER.md/HANDOVER.md + sous-dossiers selon le type de sujet.

Bloc YAML en tete d'un fichier Markdown (entre deux ---). Contient les metadonnees : title, description, tags, status, etc.

Utilise par /new-subject pour le matching semantique et par l'index pour la generation des tables.

Outil Claude Code pour chercher des fichiers par pattern (ex: **/*.md). Equivalent a find mais optimise pour le contexte agent.

Chaque appel Glob est un aller-retour outil — d'ou l'interet de consolider en 1 commande find.

Outil Claude Code pour chercher du contenu dans les fichiers par regex. Base sur ripgrep.

Plus rapide que grep classique, supporte les regex avancees et le filtrage par type de fichier.

Format de serialisation de donnees lisible par l'humain. Utilise pour les frontmatters, configs, et fichiers de definition.

Syntaxe cle: valeur avec indentation significative.

Complexite lineaire — le temps d'execution croit proportionnellement au nombre d'elements. Ici : 1 Read par sujet = 75+ Read pour 75+ sujets.

A comparer avec O(1) (temps constant) : un edit cible prend le meme temps quel que soit le nombre de sujets.

Premiere dimension de scoring (/10). Evalue si le POURQUOI est clair : probleme concret, frequence, impact, qui, gestion actuelle.

Chaque critere vaut 0 (absent), 1 (vague), ou 2 (explicite). Score max 10.

Deuxieme dimension de scoring (/10). Evalue si le QUOI est clair : entites concernees, perimetre geo/format, exemples, criteres d'acceptation, recurrence.

Score max 10. Combine avec D1, le score total est sur 20.

Detection automatique : le ticket decrit-il une solution technique ("cree un dashboard") au lieu d'un besoin ("j'ai besoin de voir X") ?

Flag binaire (oui/non), pas un score. Declenche des questions de clarification pour extraire le besoin reel derriere la solution proposee.

Systeme a 2 niveaux de modeles LLM. Tier 1 (nano, pas cher) traite les cas evidents. Si le score tombe dans la zone grise (6-16), escalade vers Tier 2 (sonnet, precis).

Economise ~60-70% des appels au gros modele. Les extremes (clairement ROUGE ou VERT) sont identiques quel que soit le modele.

Couche d'abstraction API qui permet d'appeler n'importe quel modele LLM (OpenAI, Anthropic, Google) via un seul endpoint.

Changer de modele = changer une variable d'env, pas le code. Fallback automatique si un provider est down.

Protocole de marquage des decisions selon leur origine : [H - High] (humain), [AI - High] (IA validee), [AI - Medium] (fonctionne mais non maitrise), [AI - Low] (suivi aveugle, a challenger).

Defini par le DR transfert de connaissance. Permet au repreneur de savoir quelles decisions challenger en priorite.

1 Producer, 1 Consumer. Configuration de base d'un benchmark broker : un seul emetteur, un seul recepteur.

Represente le use case le plus simple — pas de parallelisme.

4 Producers, 4 Consumers en parallele. Simule une charge moderee avec parallelisme.

Montre comment le broker gere la concurrence et la distribution de messages.

8 Producers, 4 Consumers. Configuration de charge elevee — plus de producteurs que de consommateurs.

Teste le comportement du broker en situation de backpressure.

Mesure de reference (idle) avant le debut du bench. Permet de calculer le delta sous charge.

On mesure la RAM et le CPU du broker au repos avant d'envoyer des messages.

Envoi de N messages en un seul appel reseau au lieu d'un message par appel.

batch=50 ajoute ~18% au produce throughput. Au-dela, les gains sont marginaux.

Jeu de donnees genere avec une graine fixe (seed=42). Identique a chaque execution pour des resultats reproductibles.

Messages par seconde. Unite de mesure du throughput d'un message broker.

Calcule : nombre de messages / temps ecoule en secondes.

Pic de consommation memoire du broker mesure pendant l'envoi des messages (phase produce).

Gearman: ~50 MiB, RabbitMQ: ~244 MiB, Kafka: ~449 MiB.

Quality of Service dans RabbitMQ : limite le nombre de messages envoyes a un consumer avant acknowledgement.

Sans QoS + no_ack, un seul consumer recoit tous les messages. Avec QoS, la distribution est equitable (round-robin).

Acquittement manuel : le consumer confirme explicitement avoir traite chaque message.

Necessaire avec QoS pour le fair dispatch. Ajoute un leger overhead vs auto-ACK.

Profil de charge avec 10,000 events. Le plus representatif pour mesurer le throughput reel.

Autres profils : smoke (10 events), standard (1,000), endurance (50,000).

Debit de messages traites par unite de temps (msg/s). Mesure la capacite du broker + client.

Produce throughput = envoi, Consume throughput = reception.

Plafond de throughput atteint quelle que soit la charge. Le broker ou le client ne peut pas aller plus vite.

RabbitMQ sature a ~55K msg/s en produce (PHP client bound).

Execution sur un seul coeur CPU. Ajouter des vCPU n'ameliore pas les performances.

Notre bench PHP est single-thread : le bottleneck est le client, pas le broker.

Micro-graphique inline (sans axes ni labels) qui montre une tendance sur une periode.

Utilise dans les KPI Cards pour montrer l'evolution sur 30 jours.

Matrice de couleurs ou chaque cellule represente une valeur. Plus la couleur est intense, plus la valeur est elevee.

Diagramme de flux ou la largeur des liens represente le volume. Montre comment les donnees transitent entre etapes.

Utilise pour visualiser le funnel AdCall → Bid → Win → Impression.

Serie de petits graphiques identiques, un par categorie, permettant de comparer visuellement les patterns.

Preferable a un seul graphique avec 10+ courbes superposees.

Graphique en barres centree sur zero. Les barres positives vont a droite, les negatives a gauche.

Ideal pour montrer des ecarts (ex: variation revenue vs mois precedent).

Visualisation hierarchique ou la surface de chaque rectangle est proportionnelle a sa valeur.

Utilise pour voir la repartition du revenu par partenaire ou par editeur.

Carte resumant une metrique cle : valeur actuelle, delta vs periode precedente, tendance (sparkline).

Graphique avec deux echelles Y differentes (ex: revenu a gauche, CPM a droite).

A utiliser avec precaution : peut induire de fausses correlations.

Graphique montrant la distribution statistique : mediane, quartiles (P25/P75) et extremes.

Utile pour comparer la dispersion des CPM ou latences entre partenaires.

Librairie de visualisation open-source (Apache). Standard retenu chez SmileWanted pour toutes les dataviz.

Alternative a Chart.js, D3, Plotly. Choisi pour sa richesse fonctionnelle et son theme systeme.