Cas 05 · Travaux choisis
Le socle technique : des milliards d’impressions et une place de marché autonome
- Production passée — propriété de l’employeur
Onze ans en deux passages dans la même société d’AdTech : quatre ans comme seul ingénieur frontend sur une conversion de plateforme, puis une place de marché publicitaire en libre-service construite de bout en bout, puis des services backend portant des dizaines de milliers de requêtes par seconde.
- Rôle
- Software Engineer, puis Senior Software Engineer
- Compétences
- Échelle · Plateforme · Développement direct
- Domaine
- Technologie publicitaire — éditeurs, ventes et campagnes
- Durée
- Deux passages, onze ans
Contexte
Une société de technologie publicitaire qui exploitait des plateformes pour les éditeurs, les ventes et la conduite de campagnes. J’y suis entré en 2011, parti en 2017 pour créer ma société, et rappelé deux fois dans les deux années suivantes ; je suis revenu en 2019 à un niveau supérieur et y suis resté pendant la pandémie.
Problème et zones floues
Trois problèmes différents sur onze ans, mais une forme récurrente : ce qui marchait à une échelle ne marchait plus à la suivante, et la correction n’était jamais dans la partie que tout le monde regardait.
Mon rôle
Mon rôle : années un à quatre, seul ingénieur frontend sur la conversion des interfaces d’exploitation de la plateforme, plus la recette. Cinquième année : j’ai demandé à mon responsable de passer au backend et je l’ai obtenu — ⛔ je n’ai pas été réaffecté, je l’ai demandé. J’ai ensuite construit la place de marché publicitaire B2B en libre-service de la société, rattaché au CTO. Au second passage, j’ai mené les améliorations backend et API ainsi que la migration vers une nouvelle surface d’API.
Recueil du besoin
Les interfaces d’exploitation n’étaient pas un exercice de design, mais un problème d’ergonomie à tranchant commercial : un tunnel de vente qui fait passer des opportunités par des paliers de confiance jusqu’à l’affaire signée puis vers le cycle de vie de la campagne, un gestionnaire de campagnes au-dessus de la hiérarchie pays, annonceur, campagne, vague, emplacement et création, et un portail éditeurs couvrant la configuration des emplacements publicitaires, l’accumulation des revenus et les demandes de paiement. Bien faire cela demandait de s’asseoir avec l’exploitation publicitaire et les ventes, ⛔ pas avec une spécification.
Architecture et arbitrages
Le travail d’échelle était une migration d’une architecture héritée vers une nouvelle surface d’API, et les deux moitiés se ramenaient à la même chose : sortir le travail du chemin de la requête. La télémétrie publicitaire — chaque impression, chaque clic, et quel élément à l’intérieur de l’annonce avait été cliqué — aurait noyé les serveurs si chaque événement déclenchait son propre appel, donc les événements étaient accumulés et envoyés à intervalle fixe vers un service de comptabilisation séparé, traités hors du système principal, puis réécrits. Les rapports étaient générés de façon synchrone, si bien qu’une page se bloquait pendant l’exécution du sien ; cela est passé sur des lots de workers, la page se chargeant immédiatement et le travail rendant compte à la fin.
Mise en œuvre et intégration
La place de marché était une surface commerciale complète : la publicité emballée en offres et en accords, une couche d’abonnement délibérément simple au-dessus d’un cœur complexe, reliée au moteur d’API de la société, avec commande et gestion en autonomie côté client, dépôt des créations, rechargement et débit de points prépayés côté acheteur, et accumulation des revenus et demandes de paiement côté éditeur. Les éditeurs pouvaient publier des offres, définir leurs emplacements et vendre.
Contrôles en production
L’envoi de rapport a été rendu idempotent — recharger la page ne pouvait pas relancer un travail déjà en cours, c’est la panne que chaque utilisateur trouve en une semaine. Cache multi-niveaux, réglage des requêtes en base et réécriture Node.js sur les chemins chauds.
Impact
Échelle de la plateforme : les services backend portaient des dizaines de milliers de requêtes par seconde et des milliards d’impressions publicitaires par mois. Ce chiffre décrit la plateforme, ⛔ pas un composant que j’aurais possédé seul — j’ai travaillé sur des chemins backend précis à l’intérieur. Sur ces chemins, l’envoi par lots, le réglage des requêtes, le cache multi-niveaux et la réécriture Node.js décrits plus haut ont amené les temps de réponse p95 sous les 100 millisecondes, mesurés sur les chemins modifiés.
Enseignement réutilisable
Les deux gains d’échelle sont venus du même geste — sortir le travail du chemin de la requête — et aucun n’a exigé de réécriture. Le chiffre de débit est une conséquence de cette décision, ⛔ pas une réussite en soi, et je préfère qu’on m’interroge sur le mécanisme plutôt que sur le nombre.
Preuves publiques
Tout ce qui précède peut être discuté publiquement. Ce qui est retenu, et ce qui est en préparation :
Cette décennie se porte mieux avec un jeu de diapositives qu’avec un dépôt — projet P8 — parce que le travail est trop ancien et trop propriété des clients pour être reconstruit honnêtement.
Voici la méthode derrière tout ça
Les réponses viennent de ce site. Il vous dira quand un projet ne vaut pas la peine d’être construit.