À 12:03 AM, la courbe des commandes sur l'écran de supervision est montée en flèche comme si quelqu'un avait allumé la mèche. À 12:07, le premier 429 est arrivé : l'API d'étiquettes du transporteur a commencé à limiter le trafic. À 12:12, l'API de récupération des commandes de la marketplace refusait elle aussi par intermittence. Sur le terrain, une douzaine d'emballeurs attendaient les étiquettes d'expédition pendant que les imprimantes gardaient un silence inquiétant. Le gars de l'informatique redémarrait des jobs et tapait « ne paniquez pas » dans le chat de groupe, et tout le monde voyait bien qu'il paniquait. Cette nuit-là, nous avons survécu deux heures avec des feuilles de picking écrites à la main, et le service client n'a pas arrêté de sonner le lendemain.
Ce n'est pas une histoire de logiciel mal écrit. C'est simplement ce que fait la haute saison : un système qui appelle une API tierce des dizaines de milliers de fois par jour peut atteindre plus de dix fois ce volume en une seule nuit. Chaque API tierce a des quotas, et quand vous les dépassez, l'autre partie ne négocie pas — elle dit simplement non. Les commandes cessent d'arriver, les étiquettes cessent de s'imprimer, l'inventaire cesse de se synchroniser, et toute votre opération s'arrête devant les serveurs de quelqu'un d'autre. Cet article saute la théorie. Voici ce qu'il faut vraiment faire avant la haute saison.
Les quotas que personne ne lit jusqu'à la nuit où ils vous tuent
D'abord : trouvez le quota de chaque API tierce que vous appelez et notez les chiffres. API d'étiquettes des transporteurs, récupération des commandes des marketplaces, synchronisation d'inventaire de l'ERP, notifications SMS — chacune limite différemment. Certaines à la minute, d'autres au jour, certaines par compte, d'autres par IP. Ne vous fiez pas à votre mémoire. Ne « pensez pas que c'est quelques centaines par minute ». Ouvrez la documentation officielle, copiez les chiffres, notez les unités.
Ensuite : faites le calcul. Prenez le pic de la haute saison de l'an dernier — ou une répétition plus modeste comme une vente de mi-année — multipliez par 1.5, et calculez combien d'appels vous lancerez pendant cette heure de minuit. Comptez les appels, pas les commandes : une seule commande peut signifier trois ou quatre appels d'API (recherche de tarif, étiquette, envoi du suivi, mise à jour d'inventaire), et ce multiplicateur surprend la plupart des gens la première fois qu'ils le calculent. Mettez le résultat à côté du quota et l'écart vous saute aux yeux.
Troisièmement : demandez les augmentations de quota tôt. Les grandes plateformes et les transporteurs acceptent tous des augmentations avant la pointe, mais cela passe par un processus et une file d'attente — deux à trois semaines à l'avance, c'est du bon sens. N'envoyez pas juste un chiffre ; joignez vos calculs. L'ingénieur qui examine votre demande réagit bien mieux à « volume d'appels en heure de pointe, durée, détail par endpoint » qu'à « veuillez augmenter notre quota ». J'en ai appris une à la dure : une année, nous avons augmenté le quota de notre transporteur principal et oublié la voie de secours. La nuit de pointe, le principal a vacillé, le trafic a basculé, et le quota de secours a explosé instantanément. Toute cette préparation, gâchée. Couvrez chaque compte et chaque route que vous appellerez vraiment — y compris les secours.
Les réessais ne sont pas censés être des poulets sans tête
Une augmentation de quota ne vous rend pas invulnérable. La nuit de pointe apporte toujours des surprises : les serveurs d'en face vacillent, des paquets se perdent, un endpoint se dégrade sans prévenir. La façon dont votre logique de réessai est écrite décide si vous passez en douceur ou si vous finissez le travail de les mettre à terre.
N'écrivez jamais de réessais bêtes à intervalle fixe. Chaque requête échouée qui réessaie toutes les cinq secondes ne fait que renvoyer le déluge contre le mur — dès que l'autre partie reprend son souffle, vous la remettez à plat. Utilisez le backoff exponentiel : attendez une seconde, puis deux, puis quatre, en doublant, avec un peu de jitter aléatoire mélangé. Les gens sautent le jitter et ils ne devraient pas : sans lui, tous les clients réessaient au même instant et vous obtenez un nouveau déluge synchronisé. Avec lui, les réessais se dispersent.
Le backoff a aussi besoin d'un plafond : un nombre maximal de réessais et une attente totale maximale, au-delà desquels vous abandonnez et dégradez. Le réessai infini est le modèle le plus dangereux qui soit. J'ai déjà vu une file de réessais grossir jusqu'à manger la mémoire du serveur d'application — notre propre système est tombé avant que l'API du fournisseur ne se rétablisse. Verrouillez le nombre de réessais et les délais dans la configuration pendant les tests de charge. Modifier la config la nuit de pointe, c'est jouer.
Et traitez les lectures et les écritures différemment. Réessayer une récupération de commandes, c'est bon marché. Réessayer une impression d'étiquette ou une décrémentation d'inventaire, non — alors renseignez-vous sur l'idempotence avant de réessayer une écriture. Si la même commande s'imprime deux fois, le transporteur la déduplique-t-il ou recevez-vous deux étiquettes ? Êtes-vous facturé deux fois ? Personne ne pose ces questions un mardi calme ; la nuit de pointe vous donnera la leçon à votre place. Les clés d'idempotence appartiennent à chaque appel d'écriture qui touche à l'argent ou aux marchandises physiques. Ne découvrez pas les doublons à la réconciliation.
Quand ça casse vraiment, dégradez avec dignité
Le backoff et les files achètent du temps. La dégradation admet la réalité : leur API est en panne et votre entrepôt ne peut pas s'arrêter. Le plan de dégradation s'écrit et se répète avant la haute saison — il ne s'invente pas à 12:12 AM.
Le mouvement de base, c'est « prenez la commande maintenant, synchronisez plus tard ». Impossible de récupérer les commandes de la marketplace ? Produisez à partir des commandes en cache local, imprimez les étiquettes avec le transporteur de secours, et rattrapez les données quand l'API revient. Synchro d'inventaire bloquée ? Continuez à expédier, consignez les écarts, réconciliez à la main après. Un principe : protégez la ligne vitale — la marchandise qui sort par la porte. Tout ce qui n'est pas temps réel peut prendre du retard.
La dégradation devrait avoir des paliers. Léger : tuez les appels non critiques — basculez les notifications SMS vers un lot post-pointe et libérez le quota pour l'impression d'étiquettes, l'appel qui vous maintient en vie. Moyen : basculez sur la voie de secours même si elle est plus lente ou plus chère. Lourd : passez en manuel — étiquettes vierges remplies à la main, picks pilotés par tableur. Ça semble primitif, mais quand vous y êtes, un plan primitif vaut mieux que de fixer un écran mort. Le déclencheur et les étapes de chaque palier tiennent sur une page imprimée scotchée au bureau d'astreinte. Personne ne réfléchit clairement à minuit la nuit de pointe.
Sous tout cela se trouve une file. Chaque appel qui va normalement directement chez un tiers devrait d'abord passer par une file locale pendant la pointe, consommée à un rythme régulier sous le quota. Mettez des seuils d'alerte sur la profondeur de la file : passé la ligne, la dégradation légère s'enclenche automatiquement. Construisez cela en temps normal, pas la semaine avant la pointe — la stabilité de la file elle-même et son suivi ont besoin de temps pour faire leurs preuves.
À deux semaines, parcourez cette liste
Voici la checklist pré-pointe, prête à cocher : chaque quota tiers noté ; le volume d'appels de pointe calculé ; les demandes d'augmentation déposées, voies de secours incluses ; la politique de réessai en place — backoff exponentiel avec jitter et plafond strict ; l'idempotence des appels d'écriture confirmée ; les trois paliers de dégradation écrits et répétés une fois ; la file de lissage active avec seuils d'alerte posés ; le planning d'astreinte et le chemin d'escalade affichés.
Une chose à faire demain : ouvrez la configuration d'intégration tierce de votre système, trouvez la limite de quota de chaque API, et construisez le tableau. Ce seul tableau fait la différence entre dormir la nuit avant la haute saison et revivre une nuit comme celle par laquelle j'ai ouvert cet article.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
