Budgets de latence
Chaque workflow reçoit une limite de vitesse par écrit — c'est quoi, trop lent — imposée avant chaque sortie et surveillée en production, pour que la lenteur ait un nom et une adresse.
Une pizzéria ne promet pas « rapide », elle promet un chiffre — et quand une livraison dépasse, tout le monde le sait. Un budget de latence, c'est cette promesse pour un workflow IA : une limite écrite sur le temps que peuvent prendre les réponses, vérifiée avant chaque sortie et surveillée en production, pour que « ça semble lent » devienne un fait sur lequel agir.
Le problème, en mots simples
Un utilisateur vous dit que l'assistant semble lent. Lent comment ? Depuis quand ? À quelle étape ? Personne ne le sait, parce que personne n'a jamais écrit ce que rapide était censé vouloir dire. La plainte rebondit d'une équipe à l'autre — les gens du modèle disent que le modèle est correct, les gens de l'application disent que l'application est correcte — et elle meurt dans un canal quelque part. Pendant ce temps, un changement livré le mois dernier a ajouté deux secondes à chaque réponse, et aucune alarme n'a sonné, parce qu'il n'y avait aucune ligne à franchir.
Ce que nous mettons en place
Chaque workflow déclare un budget de latence : une cible p95 et une cible p99 (p95 veut dire que 95 requêtes sur 100 doivent finir dans le temps visé ; p99, 99 sur 100 — le but est de mesurer les lentes, pas la moyenne confortable). Le harnais d'évaluation (le banc d'essai) mesure les deux sur les cas de test sauvegardés avant qu'un changement soit promu ; un changement qui défonce le budget est bloqué à la porte. En production, la télémétrie (la mesure continue du vrai trafic) suit le respect du même budget, et quand il est brisé, une alerte part en nommant l'étape responsable à l'intérieur du workflow — pas juste « quelque chose est lent quelque part ».
Comment ça fonctionne, étape par étape
- Chaque workflow reçoit une limite de vitesse écrite
Des cibles qui couvrent presque toutes les requêtes (les marques p95 et p99), pas seulement la journée moyenne.
- Chaque changement est chronométré avant sa sortie
Le banc d'essai mesure chaque candidate contre le budget. Trop lente veut dire pas de promotion, comme un test de qualité échoué.
- La production est mesurée en continu
Du vrai trafic, de vrais chronos, vérifiés contre le même budget que les tests.
- Les ralentissements déclenchent une alerte nommée
Pas « c'est lent », mais quel workflow, et quelle étape à l'intérieur — la récupération, l'appel au modèle, l'outil.
- Le budget se renégocie volontairement
Si un workflow a légitimement besoin de plus de temps, le budget change exprès, par écrit — jamais par érosion silencieuse.
Ce qui change pour vous
Avant, « ça semble lent » était une plainte que personne ne pouvait acheminer, et la latence grimpait invisiblement, un changement à la fois. Après, la latence est un chiffre avec un responsable : les régressions sont attrapées à la porte de sortie, et les ralentissements en production arrivent en alertes qui pointent une étape précise, pour que la réparation commence en minutes plutôt qu'en débats. Ce qu'il ne fera pas : rendre quoi que ce soit plus rapide par lui-même. Il rend la lenteur visible et attribuable — exactement ce qui permet à quelqu'un de la corriger.