Réponse en deux secondes
Exemple fictif : un premier texte arrive en 2 s, mais les outils finissent à 12 s et la validation à 90 s. Publier ces étapes distinctes au lieu d’annoncer « tâche terminée en 2 s ».
Guides pratiques approfondis
Mesurer la latence utile d’un agent IA
Chronométrer une tâche complète, conserver les échecs et séparer rapidité apparente et résultat validé.
Mise à jour :
Illustration générée par IA · Poste de test et bouton d’arrêt. Scène illustrative.
Quand le résultat devient-il réellement utilisable ?
Le premier fragment affiché, la fin de génération et la validation humaine ne marquent pas le même événement. Une comparaison utile précise ses bornes et le résultat attendu. Ce protocole ne classe aucun fournisseur ; il organise une mesure locale reproductible sur des tâches documentées.
Définir les bornes
Écrire début et fin : demande envoyée, premier contenu, outils terminés, livrable prêt ou validation achevée. Utiliser une horloge adaptée à la mesure de durée. Ne pas soustraire des horloges de machines différentes sans synchronisation connue.
Fixer le scénario
Conserver entrée, consignes, version, permissions et état des caches. Séparer premier appel et appels répétés. Si un outil externe intervient, relever sa part du parcours plutôt que l’attribuer entièrement au modèle.
Répéter sans effacer les échecs
Noter durées, tentatives, reprises et délais dépassés. Publier effectif et distribution, pas seulement la meilleure valeur. Une tâche abandonnée doit rester visible, même si elle n’a pas de durée de réussite.
Comparer avec la qualité
Appliquer le même critère d’acceptation aux sorties. Comptabiliser corrections et relectures. Un résultat rapide mais invalide n’est pas un gain de temps utile ; préciser le temps humain nécessaire.
Situations et arbitrages
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
La moyenne exclut les délais dépassés
Un essai illustratif compte 9 réussites et 1 expiration. Les durées des réussites ne décrivent pas à elles seules les dix demandes. Publier taux de succès et règle d’exclusion.
Preuve à conserver
- Bornes et unité de durée
- Versions, entrée et état du cache
- Durées, échecs et reprises
- Critère de qualité et temps humain
Références officielles
Protocoles connexes
Points à vérifier avant de conclure
- Les bornes sont-elles identiques ?
- Le cache est-il documenté ?
- Les échecs restent-ils visibles ?
- Le résultat est-il validé avec le même critère ?
Un relevé de latence par étape, lié à la qualité, aux échecs et au temps de validation.
Questions fréquentes
Faut-il mesurer le premier fragment ?
Oui si la réactivité perçue est la question. Conservez aussi fin de tâche et validation afin de ne pas confondre affichage initial et livrable utilisable.
Peut-on comparer deux moyennes seules ?
Elles masquent dispersion et échecs. Ajouter nombre d’essais, conditions, médiane ou distribution et taux de résultats acceptés. Documenter la règle de calcul.
OUTILS / REGISTRES
Rédiger un relevé
Une mesure locale dépend de la tâche, de la charge, du réseau et des outils. Un percentile sur quelques essais est fragile. Ne pas transformer un essai contrôlé en promesse générale de disponibilité.
- Date de consultation et fuseau
- URL exacte
- Tâche / étape du parcours
- Version / révision
- Événements de début et de fin
- Durées par étape et unité
- Échecs, expirations et reprises
- Répétitions et dépendance entre observations
- Critère de validation
- Limite / incertitude
- Décision / prochaine action
- Responsable du contrôle
- Prochain contrôle